tjduavis.JourneyMan

weblog dedicated to software development, philosophy, and theology


Leave a comment

The Coop with Twitter Support: Release 0.3

For release 0.3, I performed another “polishing” iteration on what I had produced from the previous release.

This iteration was divided into two objectives: The first was to resolve known bugs or unexpected results that carried through from the previous releases and the second was to continue enhancing the user interface / user experience.

The following is an outline of the changes with additional personal comments describing my overall process, experience and lessons learned during this release. For information on obtaining the source code and installation please refer to the Desktop Social Networking Integration project wiki page.

Bugs that have been resolved based on release 0.2:

timestamp-fix.jpg

  • The timestamp is now synchronized with twitter.com. I originally thought that the timestamp of their messages were converted into local time but I believe they are all converted into UTC format. The problem that I did in the previous release was not include the timezone into my Date.parse function.
  • Logging into Twitter upon a first install caused the the main panel to be blank. The user would have to close/hide the side bar and re-open it in order to populate their list of friends. This problem forced me to further investigate how Ajax processes events. Although I have a solution, I still do not fully understand how events work with Ajax. It seems to be like a stack that is generated from a recursive function, as the next line of code can be called and processed despite not completing.
        this._fbs.updateFriends(); //uses an ajax call that processes based on events
        this.buildFriendsPane();
  • Logging into Twitter on the same browser and profile but with a different account would create a problem of displaying the previous logged in users friends. This has been resolved and been tested. I ensured that the correct user id drove the relationship of data being used in the database upon logging in.

User interface and user experience enhancements:

main-console-release03.jpgfriend-console-release03.jpg

  • Replaced the textbox xul element used for displaying the status update messages of the user’s friends with a description xul element. This was the original design but I had stuck in trying to wrap the text value. The problem was that I was setting the text value as an attribute instead of a children of the description xul element. I researched examples on programmatically creating a child “node” for an xul element and the a little snippet can be seen below:
          var timeStampDescripElement = createXULElement("description", { width: "80" } );
          var timeStampTextNode = document.createTextNode(msgTimeStamp);
          timeStampDescripElement.appendChild(timeStampTextNode);

          statusMessage.appendChild(timeStampDescripElement);
  • Once the description element was in place, I noticed that it needed to further esthetics enhancements as it was very plain and dull. The textbox revealed how it looked with straight borders so I wanted to try something new. To be consistent with the theme I used the existing design scheme of the fade and added that CSS class for the description xul element.
  • The last touch up was the aligning / spacing of the messages and the timestamp. For the main friends view I placed the timestamp from the bottom and aligned it to the right as it seemed like a more pleasing appeal and balanced the existing composition. For the friend view I made the timestamp and messages structured row by row, with the timestamp being the first column and the second is the actual message. I wrapped both timestamp and messages in order to have a clean spacing desite the length of the content.
  • During my testing I noticed that my friends in Twitter posted hyperlinks on their status messages. I noticed that these hyperlinks did not wrap around despite it being included as text node. I thought that the problem was the hyperlink needed to be set in a proper anchor tag element so then I did so more overtime work. I have to give credit to Start IT Up and a couple of MozDevs (Ted and Mfinkle) for helping me generate ideas and tips to solve my dilemma. Despite the solution for setting the hyperlink in an anchor tag the problem still occured. So my next idea for a solution was to determine if the hyperlink was greater than the space allowed and if so I would cut in half the text and appended a “…”. The code for this is really ugly but I just wanted to mockup this up and see if it provides any value or could be elaborated.

coop-release03-hyperlink1.jpgcoop-release03-hyperlink2.jpg

I recognize that there still needs to be a lot more testing and further feedback on the existing user interface / usability is needed, so please feel free to try to break my release or butcher me with comments on the overall appeal and usability… Happy “hacking”!


Leave a comment

Brainstorming for Release 0.3 – Polishing Iteration 2

For this release I will focus on providing user interface / usability enhancements. I will also look to resolve any development bugs or unexpected results that have occurred.

The brainstorming list of possible enhancements are:

  • For the current message display of friends and friend view, should I invest time in getting the messages as a description XUL element or should I leave it that way and try to beautify it a bit more?
  • I think I should try to find away of translating the timestamps from UTC to local time? My original assumptions are that Twitter’s API is translating the time a message is published, from local time to UTC. (Basically blaming Twitter’s API) Would there be a way to convert this back? Or is my assumptions wrong (And I’m the one to blame :P)
  • Drag and Drop. Any comments? Room of improvements? (Always I know but I’m up for it!) I notice that when you drag the person to a textbox in the actual browser it drops its Coop user number, should it drop its home page link? But if it drops its home page link then what about multiple accounts. Maybe it should drop something else? Or maybe we should let the user decide? But I think we got to build a managing use case for that.
  • Login? Thoughts on the new design? (I have to give credit to my coworkers for helping me brainstorm this!)
  • One known bug or unexpected results is the Facebook service currently being down. That needs a certain amount investigation but it would be cool to include the Facebook service with the drag and drop feature!

    Food for Thought: brainstorming ideas to stimulate both the Coop and the Desktop Social Integration project for DPS909:

  • In regards to researching and reflecting on the future of this generic social engine API …thingamabugger… based on my own experiences writing release 0.1 and 0.2, and the community ideas found in the Coop Mozilla Labs forum:
  • I agree with Myk Melez statement about differentiating the core functionality of the Coop from the services that integrate with it but I still stand with being cautious about overkilling the Coop and the concerns of raiph. But maybe a good action item is to compile a table of possible features in Coop and features with social services and their features that could be integrated with the Coop. So that it easy to communicate and manage this to both technical and non-technical users. This table should be interactive where editing is available. Maybe it could be built in a wiki! Because I agree with Myk Melez statement and also based on my own experiences that “…The challenge, of course, will be designing that core functionality and aggregation interface in a way that makes it possible to integrate all those sites and useful to do so.”

    I am also wondering how the architectural highlights of AllPeers resource framework could help and if there are any steps for the concerns of remote service-provided content from feeds. I haven’t had a chance to explore it but the the original discussion initiated from a post by an AllPeers team member but I thought I should mention this to stimulate ideas.

    Discussions of Service Manager from Stevo Bengston and lilmatt is another good place to do some researching and exploring in terms of reflecting on building a generic social API. Which brings me to my next point that I would like to share.

  • I casually got in contact with a developer/supporter of Flock couple nights ago and pointed me to the Flock code base and its IRC community. I want to share this resource as well.
  • <jeremy>    tjduavis: i still have to read scrollback here, but fyi, we have our own 
    IRC server (irc.flock.com). feel free to come by and make inquiries ...    
    
    <jeremy>    tjduavis: also, we have lxr @ lxr.flock.com and 
    viewvc / trac @ svn-mirror.flock.com

  • In terms of looking forward to the future of Desktop Social Networking Integration, in my attempts to frame the problem and solutions by researching and reflecting about RH’s Online Desktop Project I would like to share some thoughts and findings.
  • One idea for the involvement of The Mugshot project is to provide some sort of server aggregator for the Coop handling content management.

    For my own reflections I would like to see personal information management type applications like Chandler, Thunderbird/Sunbird, or other vendor based products (Windows, Linux, Mac) get integrated. I think its important not only in the realm of network socializing but also in terms of organizing and managing contacts and its associated content (photos, videos, etc.) with daily workflows back into the browser. Building up on the idea of AllPeers’ view on contact lists being based on the browser as oppose to the IM, the desktop should be the intermediate between native desktop applications and browser based applications. Therefore the Coop and its generic API provides a bridge or adapter (not getting into the actual specific design pattern) to the browser.


    2 Comments

    Unleashed: Release 0.2

    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.

    display-aesthetics1.jpg

    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.

    merge1.jpg

    merge2.jpg

    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.

     

    login.jpg

     

    login2.jpg

     

    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.

     

    I had exposure in ajax technology and advanced “hacking” using Javascripting when trying to resolve a bug. One of the bugs that I had to look into was suppressing the authentication prompt dialog when an unsuccessful authentication login was made and a twitter service call was attempted since Twitter currently uses basic http authentication scheme (so don’t use password reuse on Twitter as it is sent over clear text). I did my initial research and I found few articles suggesting that Ajax could not suppress this as the browser reads the authentication response before Ajax performs handling. I then attempted to research for a component in XPCOM that could provide this sort of handling. I found one but before attempting to test this I wanted to discuss my issues and research within the Mozilla developer community via IRC. Luckily Myk Melez knew a hack and pointed me to a piece of code within the Mozilla code base via LXR which was ironically implemented within the Coop.

     

    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.

     

    For the next release what can have the most value? Will implementing the core service in other online desktop projects provide measurable project value in creating a generic social engine? Or should work be allocated to either refactor existing code to be component centric or should scope creeping remain a feasible approach. How would the final core engine look like? An XPCOM component written from an OO language such as C++/Java or would it the remain as a Javascript component – if so how would external applications access the engine? I know personally I would like to perform more unit testing and assistance / feedback in code review for not only in effectiveness but also efficiency purposes.

     

    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.


    Leave a comment

    Ready for Release 0.2!

    So I’m ready to get this release 0.2 started and on the way so I just wanted to update you all on whats going down.

    Got my requirements and specs drafted:

    • Fix bugs introduced in release 0.1
    • Fix bugs informed by stakeholder during their attempt to test release 0.1
      • After the login dialog, login process fails and produces a blank sidebar
    • Clean up features and functionalities
      • Order list of friends alphabetically
      • Use XUL description element for messages
      • Remove icons in The existing Coop
      • Replace release 0.1 timestamp format with user-readable timestamp (ex: “2 Days ago”)
      • Provide ability to merge users existing in different social services, with the same identity using drag and drop.

    And I got the mozilla lab community to provide support.

    Now want to get the Seneca Computer Studies open source community to get involved, so here are is another formal invitation to get on The Coop band wagon and sign up to contribute.

    Get in contact with me in anyway!

    Thanks and best regards!


    Leave a comment

    Milestone 1 – Release 0.1a Deliverable Outline

    The following needed to be changed as unexpected results were encountered with how I provided twitter messages during feedback for release 0.1.

    Feature 2 now includes a status message per corresponding friends I have in Twitter.

    Feature 3 now includes 20 most recent status messages. The maximum limit the Twitter API returns for a user’s status messages is 20.

    coop-twitter-viewmessage-friend.png

    Notes and Thoughts:

    I have an issue in listing the status messages. I would imagine the timestamp and status messages per friend would be arranged in a descending order but I have some design issues to consider that could affect my current logic in adding my friend’s messages. The first issue is whether or not the messages is going to be deleted in the sqlite database since the friends do not get deleted. My tests in determining if the database contents get deleted upon exiting the program is when I tried to login into the twitter account unsuccessfully, (both The Coop authentication dialog and the http dialog) my twitter friends are displayed and the coop loads the main pane.

    My second issue is with the user interface. I just used a textbox to simply display the messages for protoype purposes, but in terms of visual design and usability the textbox just does not work.

    Lastly, there needs to be a visual and usability design in how various network services like Twitter should get initiated. Currently the user must select login from the “friends” menu (I have to find out how to change Login to be more distinct to Twitter as I used existing code for the default login name value for Facebook). Should the Coop refresh the sidebar panel to reflect the friends per social service, should it completely aggregate all friends for any successful logged social services, or should it be combination of both where the user can hide and un-hide friends per social service?

    The above are my major design issues that became relevant to me once I started developing, so if you have any ideas or suggestions please let me know. The first applies directly to The Desktop Social Networking Integration project since the goal is to create a generic API/engine for The Coop and the other two just strictly applies to The Coop.

    You can find the latest source code and patch from my project wiki. The code is very rough and requires a lot of refactoring.