Design
Stuff...
Implementation
Stuff
Evaluation
Stuff
Reflection
We revamped the design many times throughout the whole iterative process and, to our best efforts, improved the user-experience on the Car-sharing website. The following discusses some of the major design decisions we made.
Username/Password Portability:
After our iteration through paper-prototyping, we got rid of username and passwords completely for users. When our test subjects saw the login/password form on the homepage, many just threw up their hands in frustration/disgust (we had demanding users). We then realized that the average hates putting down a username and password they have to remember just for a website they might just use once a year (e.g. birthday card).
We proceeded to use uniquely hashed URL links to identify returning users and invited users automatically. This smoothened the process tremendously and made card-signing as much of a breeze as if not more than starting a poll on doodle. Then, reading our heuristic evaluations, we realized that invited users had even less patience than the user who created the card. We tried to simplify the card-signing process as much as possible. We started out generating a unique link for each invited user but then switched to a public invite link that can generate a private edit-card-link for each invited user after they fill out a name+email form. Even this proved too much of a hassle and we merged the registration form together with the card message form and gave the private edit-card-link to the signer at the last page if they ever decide to come back and edit their message again. This streamlined the process even more and simplified the card-signing ordeal down to one form, three input boxes with instant feedback onsubmit.
Visual Aid/Feedback:
From popular demand during the paper-prototyping stage, we added in more visual aid to sweeten the card-signing process even more. For the front page, we added iconic graphics to represent and reinforce the three steps to card-creation:
- Create Card - Picture of flower to represent user preference/creativity
- Invite Friends - Picture of two people
- Send - Picture of a letter
In addition, based on TA recommendations, we simplified the form descriptions down to the title level. So instead of giving the user a verbose description in small font: “Recipient - The person you’ll be sending this card to”, we had one big subject title with lines like “Who are you?” or “Who is this card for?” that made the form instructions much more visible, humane, and easy to process cognitively.
Finally, we added a collaborator’s list to the actual to give co-signers as well as the card-creator more visual feedback to identify other people who’ve signed the same card. This helped not only to inspire ideas in signers but simplified the editing process for the card author when censoring the card at the end (We did not have time to implement the edit feature of the card).
Redundancies:
We also added redundancies to the to catch user mistakes. The front page has three links to the first step of card-creation. The flower icon, the text underneath and a giant green start button on the very bottom so the user can start the process in any of three ways and not get hung up/stuck on the home page. This, to our findings, helped warm up user cognitive skills in the beginning since you can not expect everyone to bust through a giant html form correctly on the first page of a website.
Furthermore, we broke up the card-creation form into two segments: recipient info, creator info to lower the cognitive load and avoid username/email confusions. This, however, led to some annoying edit problems. If the user wanted to change a field in the previous form, the automatic behavior is to hit “backspace” which caused the whole page to reload to the homepage and lose all the data they’ve entered. We, instead, added javascript keystroke events that caught all “enter” and “backspace” keypresses and redirected the user to the right form without losing all the information they’ve typed and submits the form correctly at the end of the two forms.
Simplifications:
Finally, we simplified the whole site many times throughout the design process and cut down one useless feature after another until we had only the minimum set of features a user would need. We cut out the initial step for picking the card styling and chose to put it at the very end of card creation if the user has time (and we have time to implement it).
We also split the message signing form for invited users from the animated card to minimize confusion. Since the card takes up a big portion of the screen, users had messy feedback to what they typed into the message box as words flew out of no where and collided with the tag cloud underneath. We broke up the steps discretely so the user can focus more on their message than on the distracting fancy wheel on the bottom.
Implementation
We used, for the backend, Django, an MVC model-based python framework for agile application development. This fit the description of an UI project quite nicely since we just wanted to quickly raise up a working prototype of our design rather than releasing the software to the market or intense optimization and scaling. Also, because Django used an MVC model, it separated out the templating, UI-design, end nicely from the rest of the database and controller logic in the middle so we can port the UI we designed easily to other frameworks later as needed. The engineering trade-off we made here speed for flexibility. Django, a fairly-heavy framework, probably won’t crunch through your application as fast as Perl or C but offers the flexibility to change any part of your design - DB, controller logic, templates - very seamlessly.
For our setup, we have a MySQL db, django controller, and the standard django templating engine running on a scripts server. Thus, all the html, db logic were straightforward and easy to implement.
The biggest mistake we made in terms of implementation was choosing to prototype the tagcloud wheel in flash. The hope was to leverage the powerful and optimized flash engine to implement some sweet animations for the user. However, we ended up spending more time debugging the flash program than actually doing the “sweet animation”. After many hours of grueling debugging, we could only produce a minimally styled skeleton wheel that barely displayed the message the user inputted. Having lost half of our development time with flash, we then switched to javascript, a familiar framework to all the team members and reimplemented the whole wheel using jquery. This made development and styling via CSS much easier but at the cost of efficiency. Javascript engines for the most part can handle heavy animations without burning up the CPU cycles. However, for our UI prototyping purposes, it supported a moderate load of ~20 people message per wheel without over-consuming CPU resources (>50%).
Finally, because we switched from login-driven site to URL-driven site, we had to support auto-mailing lost/new URL links to users. While we prominently display the links on the same page as the card signing page, if the user forgets or chooses not to save the URL links, they won’t have another way to remember the links since we didn’t have enough time to hook up a mailing server that can auto-mail the links to users for future reference. This can be done as a future extensions of the project given more time.
Evaluation
stuff...
Reflection
Overall, we found users much less excited and/or responsive towards our idea than we were. To our surprise, very simple and mundane tasks like filling out a form proved so difficult for the average user if we didn't go out of our ways to make the process easier.
As a result, we spent a large amount of time on the form design: getting the tabindex correct and binding correct events to keystrokes like "backspace" and "enter" to ensure the correct behavior and auto-save functionalities in case the user made a mistake.
We started out with a very simple premise to allow multiple people sign the same greeting card but we found out very quickly that the user-interface design for the project simply had no bottom. We easily came up with upwards of 30 complete different designs just for the presentation of the card and struggled for weeks to find the "correct" and "best" one to use. There's a lot of trick to designing a fail-safe interface even a dummy can use but an expert won't be insulted while using.
We semi-tested the efficiency of our interface when we debugged the code and had to click through all the forms every time we made an edit to the wheel. I personally must have clicked through the form process at least 500 times. This helped me, the programmer, understand the pain a frequent user might experience and helped me implement as many short-cuts and optimizations into the process as I possibly could.
In terms of implementation, we made a big mistake writing the wheel in Flash in our first release. Flash is impossible to debug and difficult to hook up with the rest of the website when 2-way communication was required. We spent an obscene amount of time trying to hack around security walls browsers put around a flash video so we can get a simple httprequest out. This took much precious energy and time away from the actual design of the wheel. So when we finally finished, we had a minimally-styled wheel barely usable when we intended it to have a lot of fancy features by writing it in flash. Also, since the flv was written in action-script completely, styling it involved much more complications than just designing the graphics in a flash studio. We gave up on the flash video approach for the final release and rewrote the whole wheel in js. This smoothened out development cycle since styling html with css and ajaxing with js was a breeze compared to flash. With the js implementation, we had more time to style and design the wheel for better user-interface on top of its minimal feature.
If we can go back and redesign the project, we definitely would have involved the user more in the process. We only talked to users in the beginning of the project (GR1) and middle for paper-prototyping. we wished we had talked to users as we coded up the wheel so we could get better feedback before the heuristic evaluation. Towards the end of GR5, we wanted to revamp the whole form system to streamline things even more but ran out of time since we were already so late in the development cycle. Had we consulted users earlier, we would've noticed the hassle of filling out so many forms and started redesigning the whole process in the beginning stages.
Overall, we made conservative decisions and stayed away from very risky designs for the form-filling process. We did a fairly good job in fulfilling the narrow problem scope we defined from the out-start. While there may exist still rough edges, the final prototype can most likely withstand a standard beta release to the general population.Stuff