Development History

The last 3 weeks has been interesting for me and perhaps the most workload heavy in the course. First week was mainly used for coming up with an idea for the artefact and discuss amongst ourselves the pros and cons of everyone’s ideas. During the first week, I partitioned my time on 50% research and 50% prove of concepts for my idea. My proposal was completed and posted to our artefact proposals discussion thread (https://landing.athabascau.ca/pg/forum/topic/76527/artefact-proposals/).

Without repeating too much detail in my proposal, my original proposed artefact was to create a web based / mobile application to collect traffic condition information based on user’s GPS coordinates that were sent to the server in a specific interval. The idea is to create a social traffic reporting system that puts the users as both passive and active road reporters; depending on the amount of participation partake by the users. The end result is a socially enabled system with real-time traffic information both publish and use by the system users to get a sense of the traffic condition so a better route can be used to save time on commute.

The following two weeks after the proposal; starting from the second week, I have revised and expanded my idea to incorporate a “base platform” which was not initially thought of. The reason being is to help ease the cold start problem I will have to come up with something more practical while still feasible to be completed by the deadline. In addition, to develop a fully functional traffic report mobile application will be an impossible task given the timeline I have. Not to mention the publishing wait time (i.e. App Store) and platform fragmentation (i.e iOS, Android, WP7, BBOs, etc) problems.

As a result, I decided to go with a traffic report simulator (for demo video go to http://au.dicksonlam.com/COMP650/Artefact/TrafficSimTraining.wmv) written in PHP and HTML 5 to address the aforementioned issues (web app vs mobile app). The simulator component will be supported by the base platform of my choice “Drupal” as a complete package of the system with higher accessibility and time-to-market factors. Drupal is a great open source CRM platform not only it is a highly popular system (meaning that it is easier to get support and plugins), but also it is supported by my existing webhosting company minimizing the initial setup time. The decision was then, for the traffic report simulator component, to deploy it as a “Drupal” module as it is de facto standard in extending Drupal functionalities and plugin development. The majority of the programming was done in PHP and used HTML 5 for geolocation support (HTML 5 supports getting the current geolocation of the user within the browser).

Setting up Drupal took me half a day to get the base system deployed and the rest of my time was spent on programming the module and configuring the site to meet my requirements which include setting up the subdomain at http://au.dicksonlam.com/. I have since put in some Blogs, Forums and Polls related to the theme of my proposal to give the site some context.

All in all, I have spent most of my time in learning PHP and Drupal module development platform. PHP was a logical choice for Drupal module development even though I have no prior experience programming in that language. However, I had enough past ASP classic development experience that makes understanding the PHP architecture/framework quickly and soon started development. I have to adjust myself to the unfamiliar syntax and the script base language nightmare of PHP + Javascript. I realize that there are many development frameworks available for PHP as well as Javascript such as Zend Framework and JQuery. However, I opted out of these frameworks knowing that the added learning curve will not be worth it for a relatively small traffic simulator component. I had decided to go with raw PHP 5 + Javascript + HTML 5.

Design Philosophy

I was at many crossroads during the development of artefact. Looking back at the decisions I made I realized that they were highly influenced by the material I have learnt in this course. The most apparent of all is the intrinsic social aspect of the app. Thought about the social/group model (many to many), the delivery medium (internet), Web 2.0 lightweight technologies (html/js) and even business model (thinking about monetizing the site via ads), etc.

Effective analysis of needs 

The needs were briefly mentioned in my proposal. The primary needs are:

·         Avoid traffic congestion.

·         Centralized location for traffic information including latest road construction notices.

·         Quickest route to destination.

·         Car accident reporting and avoid certain roads.

·         Viewing Driving Legislation changes.

·         Report Drunk Driver or dangerous driving.

·         Etc.

The needs arise from the constant frustration commuters have to face every day driving on city streets. It is not always easy to have real-time traffic condition readily available when needed. A social app that passively sends signals the server to report current conditions help build the foundation of a social system. Participants who are more active can post information on the site whenever an accident/pothole is signed. The information was then gathered in the system and will be seem by all members of the system.

Appropriate choice of software to match those needs (note that there is usually no point in building your own version of something that already exists) 

As mentioned previously, the requirements necessitated the choice of base platform software Drupal for its wide-spread adoption and an open source platform with many ready-to-use components. As well as the plug-in architecture to extend custom functionality that integrates into the site.

There are other similar traffic reporting systems available such as Waze (http://www.waze.com/). However, Waze has its focus in the US and Israel. My traffic reporting portal has its focus in Canada and so I see a void in the market in that respect. Serving Canadian make sense because it is country with large geological surface and many roads (nearly 900,000 km of road (http://www.tc.gc.ca/eng/road-menu.htm)).

In my research, I also come across CTN (Canadian Traffic Network) at http://www.trafficnet.ca/. There are certain aspects that are similar to my site such as displaying Accidents/Incidents/Construction/Traffic Flow, etc. along with mobile app support. However, it lacks the social aspect because it is a traditional one-to-many media where users are unable to actively participate in the creation of the traffic information at a scale that is appropriate to be called many-to-many media (I assume CTN accepts phone calls from public reporting traffic problems).

Appropriate design, in accordance with needs (this has the highest weighting - we seeking a creative, thorough, reflective approach in which each decision is justified and related to developing a system to meet the needs of the community and that makes use of theoretical and practical understanding of social computing systems) 

To address the aforementioned needs, the implementation aggregates the use of Blogs, Polls, Forums and the Traffic Simulator. The core component is the Drupal platform that makes use of many well understood social software such as Blogs and Forums to facilitate many-to-many communication.

A lot of build-in Drupal features are used but they were selectively chosen to meet the needs. I used Forum for reporting Road Contraction and Car Accident separated by different major cities. I also used Polls to collect social intelligence on various topics such as “Roads to avoid in winter”. In addition, Forum topics are categorized accordingly by their common topic (http://au.dicksonlam.com/?q=forum) using the Drupal object “Forum Container”.

All data collected are made publicly viewable by default without the need to sign onto the system. To contribute content such as Forum topic, the user must first log into the system. The permission settings on all objects in the system have been configured to respect the above goal. It is done because the site is a community based system that all collected data are easily accessible by the public without first gone through the registration process (a large percentage of people give up on the site if it requires registration especially with the new sites.). However, to control the quality of the people who produce the content, a registration is required as a way filter out the impulse vandals.

I had initially thought about using RIA (Rich Internet Application) such as Silverlight to deliver the traffic simulator component because I am familiar with the technology already especially with respect to the Silverlight Bing map control. The problem with Silverlight is that it is limited to Windows and MacOS computers and it is not cross-platforms like HTML/JS. The switch from Silverlight to HTML/JS increased my development significantly because: First I am not a big fan of script-based language because JS is weakly-typed language. Second, the diverse framework that is available on the internet, especially open-source framework like JQuery, took me longer to research on a suitable framework and the time to learn it. This problem extends to PHP when I decided to deploy it as a Drupal module. Without too much hesitation, I went ahead and develop it without any development framework such as Zend, Rain, JQuery, Dojo, Rico, etc. However, I would have definitely invest the time in the framework had I been given more time to develop the artefact to increase the maintainability of the system.

A working system (on a scale of fully working, partially implemented, barely working, not working) 

I would consider the system is fully working within the scope defined for the artefact and partially implemented as production grade product. For production grade software, there are a lot of factors to be considered and checks and balance to be implemented which is currently lacking in the current version. From the simulator perspective, the user inputs are not validated and therefore it can corrupt the traffic data. Also, there are a few bugs that I have noticed from the out-of-the-box deployment of Drupal 7.x which of course are inherent problems that can’t be addressed within the timeframe.

Clear and well-selected documentation 

I spent a fair bit of my time browsing through the following documentation:

·         http://drupal.org/documentation

·         http://dev.mysql.com/doc/refman/5.5/en/index.html

·         http://www.w3schools.com/php/default.asp

·         http://books.google.com/books?id=LVz8q2qYQNUC&printsec=frontcover#v=onepage&q&f=false

Reflective analysis of other students' systems (on a scale of purely descriptive to insightful)

Artifact: Twitter tweets and LinkedIn update sorter

https://landing.athabascau.ca/pg/bookmarks/read/78332/artifact-twitter-tweets-and-linkedin-update-sorter

Buturab’s artefact works as promised. The component that filters LinkedIn and Twitter feeds has many practical usages. The ability to filter feeds from these prominent online services is a big plus in my opinion. We are all concerned about the information overload, making important and relevant information buried deep within a pile of junk messages. And so I can see the artefact produced by Buturab can be seen as the email equivalent of Junk Email filter for social media. I would like to see his implementation to be offered as an option for social networking sites to limit the amount of “noise” over relevant information. The potential for growth in terms of filtering is huge. One of the extended functionality is perhaps to control the scope (or circule) of your information boundary. For example, I often get email from facebook about someone who is selling an item who happens to be linked up through a common friend which I am not interested. Buturab’s feed filter has the potential to tap into our social graph and size the social circle to include and exclude information that flow our way, in a generic way. Or from a different angle, say, to select your tolerance level, low, middle and high, to generically adjust all sources of online social media.

Artifact: socialitsm.ning.com

https://landing.athabascau.ca/pg/blog/read/77192/week-11-project-artifact-guts-created

The first thought that came through my mind is Cory’s choice of community building platform. I have never used NING before so this learning experience for me right of the bat in terms of understanding the capabilities of NING. Since NING focuses on Social Network management, many of the gadgets are very familiar to me such as activities, blogs, friends list, forum, news feed, etc.  Another thing I notice immediately is the injection of ads in various areas of site. Upon further research, the ads can be turned off on a pay account so there is an option to choose. NING seems to have many build-in features that are very valuable today for social site. The ability to seamlessly link with other popular social site as well as user account integration with Gmail is a nice touch to induce users to sign up without too much trouble.
There are three base roles of End User, Service Provider and IT Service Management Team that the site is intended to bring together. I recommended the addition of Service Promoter and Legal Service Professional as there may be a need for these intermediary services. I like the concept of common platform that brings the people with similar interests together. I am not certain if the intent of the site but the service transaction between service provider and end user can be made as part of the business plan to generate revenue. And so the site can become a market for IT related services and products.