...
In the backend we have a few different models in our database to hold on to things like contacts and their info, and associated history items. More importantly, we integrate with the twitter api on the backend. This is the same place where we would implement with other apis (like gmail, facebook, and linked in) to provide multiple sources of contact for our site. We had to make the important decision to not integrate with any networks other than twitter because doing so would have caused significant increase in the complexity of our database design and backend decisions. Because the focus of this class was not to work on a hard data integration problem, we figured our efforts would be better spent working on the design. One problem this caused was explained above, where the lack of history items from different sources prevented us from investigating interesting ways of sorting and organizing the history items across different networks. It also effected the usability of the interface because users could not actually interact with users across multiple networks, which may or may not have effected their use of the product.
Evaluation
Reflection
One of the major lessons learned through implementing ContactLens was the balance of breadth and depth. Because of the vast number of APIs we were accessing, we quickly realized that we would not be able to implement a fully functional product in the timeline given. One of the difficult design decisions was to leave several of the APIs unimplemented. However, there was a large sunk engineering cost in the first week of the project setting up the product to be ready for use with all of the APIs.
One of the things we would have done differently would have been to decide earlier on to implement a single API fully, rather than trying to implement integration with 6 APIs at once. This design decision boiled down to the fact that we did not spec out the engineering guidelines of the project, or estimate the amount of time it would take to build the product, before jumping in heads-first and beginning to code.
We also should have gotten user feedback on the live site earlier on, since one of the screens which we invested engineering time into ended up getting entirely scrapped from the entire product. The team should have kept in mind KISS (Keep It Simple Stupid), and implemented the Minimum Viable Feature Set to test the product with potential users, rather than adding on bells and whistles before putting the product out in the wild.