For release 0.2, display aesthetics were placed to increase the user interface appeal, additional features were included based on the first release and resolving bugs were also accounted for.
I changed the timestamp to be more reader friendly and the I disabled the textbox as I had issues getting the description element formatted properly. The current twitter api sets the timestamp as a UTC with the following format “Thu Nov 22 20:05:49 +0000 2007”. So the current parsing will be UTC instead of local time.
Drag and Drop Features
The drag and drop feature was motivated by release 0.1 and how multiple services could look like. Myk Melez, Dave and I agreed that the Coop with multiple services should not have a feeling of separation but rather give a sense of coherence, so that when one network services connects the Coop will aggregate the list of friends to the existing friends.
Our idea in giving a sense of coherence was to allow the user to merge identical users in different social networks by dragging and dropping one friend icon to another. Then the next time the user logs-in, the Coop will recognize this relationship. If a friend has multiple accounts associated to them then in the “friend view” you will see a drop down menu called “detach accounts” allowing the user to unmerge associated accounts.
Unfortunately the Facebook service in the Coop is down which also appears in the current production test release therefore I could not perform testing for Facebook friends so the merging/unmerging only happens with Twitter friends (as it is still possible to have friends in one social network acting as one person).
Lastly I changed the the method of logging-in by replacing the login button with a drop-down menu and including a the two services in the “friends” drop down menu.
Process, Interesting Observations and Challenges
This release gave me an exercise in researching and understanding the existing Coop code as I had to resolve bugs and include more features. Editors, such as Visual Studio that have a bookmarking tool are a great asset in tracing various function calls.
Another interesting note was to see how the observer pattern was effectively implemented in the Coop and how mozilla created XPCOM to help facilitate – the drag and drop feature was a prime example. The drag and drop benefited me in two ways: (1) allowed me investigate how dragging events are used with XUL components and (2) get into the details of the database design.
For my investigation of the dragging events I was a bit more confident in researching and testing out my assumptions as I had experience with events in the past with various programming languages (.NET / Java) which allowed me to approach my problem more systematically. I also used LXR to help find code samples in restricting data values that are not url’s being passed from the drag to the drop as each friend in the “Friends List” sends its ID to drop for the merge processing. For the database design I built a simple cross reference table that joined the multiple to multiple relationship of the friends table and accounts (social network) table. I originally had issues with the query which prompted me to look for support with SQLite database (which I got immediate feedback from the author) but upon closer examination the issue was the query itself and not the mechanism of Sqlite. Although I want to examine further into the Mozilla’s XPCOM storage wrapper as I want to know exactly how the method/attribute .params.[parameter variable] functions. Currently I am getting unexpected results when passing values that contain a “,” and it used within the IN operator. I have a current work around but in terms of remaining consistent with the existing code layout I would like to get it to work.
One last bug that seemed to surface (I don’t recall testing this during release 0.1) was the refresh of friends upon a new install of the Coop. During an install a Sqlite database has not been created so therefore when upon a successful Twitter login the Coop will update the friends and messages and proceed with generating them in the corresponding tables of the newly create Sqlite database file, and lastly populating them in the sidebar panel. However the sidebar panel does not get populated and it takes a closing of the Coop (not necessary logging off or shutting the browser) to get a successful populated sidebar.
Final Thoughts: Reflections of the Coop
Contrasting from release 0.1 this project had numerous unknowns in terms of how the generic social engine would be designed and developed. Scope creeping was the strategy agreed for the solution to the dilemma. Some progress was made by providing a more detailed look on how the persistence layer could look like. What else is surfacing are component patterns that could appear in a social network engine. They are: authentication management, user and content management.
On the last note I think the best value for the Coop as an extension application would to act as a bookmarking tool for friends connected through various social networking tools from Facebook, Twitter, to your email and personal information management applications. Although I envisioned emailing to be aggregated, my discussions about the Coop with my coworkers changed some of my perceptions. While I received positive and enthused feedback on the idea and concept of the Coop, they both expressed concerns of overkilling it with features and creating knockoffs of existing messenger applications.