Eloha - User Testing

Design

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:

1. Create Card - Picture of flower to represent user preference/creativity
2. Invite Friends - Picture of two people
3. 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

User #1:
An EE professor at MIT with a daughter named Nancy, who wants to make a birthday card and share it with family members in China. Since Nancy was only 4 yrs old, User 1 had to use her own email address in the form for Nancy and hers again for her own creator form. We should make the recipient email field optional and auto-populate it with the creator’s email if left blank. All the steps to card creation was super intuitive and proceeded smoothly.

User 1, from an older generation, had lots of trouble figuring out the invite-link. She clicked on the invite link and proceeded to type in her husband’s information, name/email, thinking the invitation will be sent to her husband automatically through the website. She also had trouble distinguishing the Invite link from the Administration link. Finding the link took a 2 second delay as she scrolled carefully down the edit page. She finished all other tasks perfectly: receiving invitation and sending the final card after figuring out where the links are.

Proposed solution:
We should probably put the links on top for easy access, add visual redundancies to reinforce the link’s meaning. Using the flower icon for the administrative link, the two people icon for the invite link and the envelope icon for the send card link. As an added measure, we should add those icons to each of the forms to clearly indicate which “step” the user is on currently. This way, the links won’t become that much of a mystery. If that still doesn’t work, we can always put in screen shots of copying the link and sending via email to other people signing the card so the user can visual learn how to accomplish each of the 3 tasks.

User #2:
Taylor, an international college student from Sri Lanka, is hoping to get a card for her dad, who often travels a lot due to his business.  Because her family is often not together in one place, with her mom working in her home country and her sister off to college, she wants to find a way for everyone to be able to sign a card and write his or her own personalized message.  Taylor was very excited to see something like Eloha, simple and easy to set up a card to send to her family and and finally to her father.

Taylor had a fairly simple experience in creating the card.  She mentioned how simple the forms were to fill out, and how easy it was to update and change her message for the card.  She didn’t have too much trouble distinguishing between the invite link and admin link.  From just reading the line description she figured out that the invite link was the link she would have to send to her sister and mother and from there they would be able to sign the card.  Taylor was especially impressed with the tag cloud display of messages.  She found it unconventional to normal paper cards, in that one would be able to click on the name of a person and then the message would fly in to the top of the page with the birthday greeting.

Possible Improvement:
There was one suggestion Taylor made that would improve user experience.  She would like to have a button next to the invite link so that instead of copying and pasting the link into an email composer, she could just click on the button, which would open a text box where she could enter emails of the people she would like to send the card to.  The message would automatically include the link to the card as well.  She said this would not only be convenient, but also error proof because sometimes the link might be too long and she may have copied just short of the actual link.

User #3
Yue’s birthday is coming up and Steven just bought a card for everyone to sign. Both are college students on campus during the summer. Not everyone is going to be around to sign the card since it’s during the summer. Steven decides to use Eloha to create a birthday card for Yue to compile messages from friends at internships..

Found the calendar widget for the birthdate selection somewhat surprising, but a pleasant surprise. However, it was unclear whether the birthdate given is the actual birthdate of the recipient or the date of the birthday celebration. When signing the message, Steven, was unsure whether or not he should sign his name in the message. But he ended up not since he remembered that the service asked for his name earlier. The tags were confusing as he was expecting his message to be intact. Additionally, he was clicking on them but didn’t know what they did (and he never dragged them either) since they had a pointer cursor on them. Once he clicked on his name, he realized that they would create his message. He wanted to click his name again to undo the message building. Also, since the messages appear at the top of the ring of contributors, he assumed it belonged to the user at the very top, not the user who was highlighted.

Improvements:
Remove the link affordances on the tags and possible remove the ability to drag them since no one uses that feature. This includes removing the underlining  and the pointer cursor that appears on the tags. Also, users may not be expecting tags as the representation of their messages, so it may help to make it explicit that their message is in tag form. The affordances for which user is currently selected should be made more obvious such as adding drop shadow or changing the hue of a selected message to something more different than blue to green. Additionally, we should move the generated message elsewhere so that it isn’t associated with the topmost user in the ring. We should also implement word wrapping for longer messages as well as a cap on how big tags can become. We should also allow users to click on the user whose message is being displayed to return the tag cloud to normal.

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.