March 27, 2006
I was reading over O'Reilly's 'What is Web 2.0' article, and I came across this line:
Imagine if MapQuest had done the same thing, harnessing their users to annotate maps and directions, adding layers
of value. It would have been much more difficult for competitors to enter the market just by licensing the base data.
Cool idea, right? But where do you start?
One way would be to allow users to adjust estimated travel time. If
MapQuest comes back with 45 minutes, and you know you always do it in 30, type in your estimate, press submit, and it goes into the
database. When enough get compiled, the user's average response is
displayed alongside the algorithmic one.
Another way would be to allow user submitted pictures of difficult
intersections, or landmarks to watch out for. Maybe even things to
check out nearby?
As far as implementation, itd be nice if you could get this service
to ride on somebody else who has already paid for the data. Query
MapQuest for the directions, and retrieve the annotations alongside it.
March 14, 2006
Unsynchronized Communication Over the AOL Instant Messenger Protocol
Users of AIM cannot send messages to receivers who don't have 'presence'. If the other user's internet connection goes down, or if they decide to leave the service, senders have no recourse within the AIM framework. For many users of the service, this can represent a time consuming or even impossible dilemma. Possible reasons for this include:
- Lack of familiarity with other message software, such as email, icq, or msn. For many users, especially younger ones, AIM is the only service they understand.
- Lack of contact information in other software. If a sender doesn't have the receiver's email address, the existence of email as an alternative is irrelevant.
Even for those who do have other software and the relevant info, switching to a different medium makes the AIM software less useful. It takes time to switch programs and enter the person's contanct info, and for the short messages that AIM is often used for, the sender will often give up.
My system creates a new, always-on screenname, that holds messages until the receiver is available. The sender can continue to use the same software, and needs only remember one additional piece of information – the screenname AIMSweringMachine. Furthermore, the system will register popular misspellings (this was misspelled mispellings before) of the name, in the style of domain parking, that will redirect to the correct name.
The system will be implemented in Perl, since it is lightweight, common, and has already existing AIM interfaces. There are three main components:
- Parser/Receiver – When the bot receives IMs, it check if its formatted properly (send )
- Buddy List Manager
- Send Queue
-to be continued…
March 13, 2006
Finally getting myself properly on the internet. Check the about page for now, I’ll add a more substantive post tomorrow.