...
This design makes reading long lists of comments confusing since it requires reading up the page, but at the same time that may be better than the alternative of needing to scroll to the bottom of the page just to see the most recent comment, which very well may be all the user is looking for. In that case though, the user would need to scroll all the way back up to make his own comment in response, which is very annoying. Overall, neither option is wonderful but we figured this design was slightly less frustrating for long list of comments and easy to figure out for a small number of comments. One other thing worth noting is that we did not include a timestamp of the comment next to the comment, so it is not even clear which way the comments are sorted until after a user makes a comment himself and sees the page update (not ideal).
Implementation
Evaluation
Briefing: "This is EventHub. It's a website for finding, scheduling, and posting events in the near future in your vicinity. So for example, if you have a couple hours to kill after class, you can come here and find something cool to do; or, if you want to organize a dinner with friends, instead of emailing everyone and juggling replies, you can organize it here. You're entering this situation in the middle of a user 'state': you already have friends, events in your calendar, all that. We're going to give you some tasks a normal user would do, and it would be extremely helpful if you would think aloud while performing these tasks. If you become confused or frustrated, please let us know because that means that we did something wrong, and need to fix it. You are free to leave the user test at any time for any reason. Any questions before we start? <wait for response> On that note, thank you for helping us improve EventHub!" (This is unchanged from the paper prototyping briefing)
Tasks
Task 1: Log in!
Task 2: RSVP for the event “Awesome Event” taking place on 5/12/11
Task 3: Uh oh, you’re going to be late for “Awesome Event”. Leave a comment letting people know.
Task 4: You want to play chess this afternoon. Create a chess game event for 4:00pm today.
Task 5: Log out.
User 1: MIT senior, fits target audience as a college student in the Cambridge area. Has no user interface experience. User was briefed as described above and given the tasks above one at a time. The test went smoothly: the user completed all tasks without problem; the only intervention required was to explain how things should work if they had been fully implemented (in this case, the RSVP button on the "Awesome Event" page didn't visually toggle like it was supposed to). User was unsure about the difference between the Calendar and Browse Events tab; perhaps we should change the title of the Calendar tab to "My Events" or something more descriptive.
In order to implement EventHub, we decided to use Google App Engine for several reasons:
- It's really really easy to set up the environment and database, and we wouldn’t have to worry about technical problems and incompatabilities with our various systems without using a Virtual Machine.
- We were able to use python for the back-end, which made it easier for all of us to ramp up
- Databases/filters are not difficult to implement
- For the front end, we can use the Django templating engine, and templating engines are awesome because they make it easy to separate back end from front end and cut down on code duplication.
- We wouldn't have to worry about accounts and login information because we’d be able to take advantage of google login.
- Easy to put up on the web at the end. No worrying about configuring servers.
Overall, we think App Engine was the right way to go. It was extremely easy to set up and get a database/templating engine set up on all of our machines. We also were able to do server-side operations without having to worry about learning a new language. The biggest problem we faced was that not everyone on the team completely understood what the templating engine actually did behind the scenes. This lead to a lot of bugs and frustration.
We also realized way too late in the game that App Engine wasn’t magical and wasn’t going to make everything as easy as they lead us to believe in the tutorials. Don’t get me wrong -- it made everything easier -- just not ridiculously easy. Why? Well it turns out that App Engine has all these really annoying technical intricacies that we hadn’t anticipated. And the database/filtering wasn’t as advanced as we thought it was. And, ironically enough, App Engine doesn’t already implement full-text search... even though... you know, Google happens to be really good at search. So we spent several hours trying to figure out how to make various undocumented packages we found online work for us. We also had to cut the filters because they wouldn’t play nice with our full text search (and frankly, full-text search was cooler than filtering.) Technically we could make it work, but it would have taken more time than we had.
We also took advantage of BlueprintCSS for the front-end layout. We thought it would make alignment much easier because it allowed us to use a grid-based system. However, once again, not everyone on the team was completely familiar with it, and while it made certain elements easier, it really crippled others in a way that pure CSS wouldn’t have. It also cluttered the code and made it more unreadable than it should have been because it used HTML element classes to enforce formatting.
Additionally, we abandoned the feature involving integration with the Google Maps API for auto-completion of location because it was much more difficult than we originally thought it would be.
Evaluation
Briefing: "This is EventHub. It's a website for finding, scheduling, and posting events in the near future in your vicinity. So for example, if you have a couple hours to kill after class, you can come here and find something cool to do; or, if you want to organize a dinner with friends, instead of emailing everyone and juggling replies, you can organize it here. You're entering this situation in the middle of a user 'state': you already have friends, events in your calendar, all that. We're going to give you some tasks a normal user would do, and it would be extremely helpful if you would think aloud while performing these tasks. If you become confused or frustrated, please let us know because that means that we did something wrong, and need to fix it. You are free to leave the user test at any time for any reason. Any questions before we start? <wait for response> On that note, thank you for helping us improve EventHub!" (This is unchanged from the paper prototyping briefing)
Tasks
Task 1: Log in!
Task 2: RSVP for the event “Awesome Event” taking place on 5/12/11
Task 3: Uh oh, you’re going to be late for “Awesome Event”. Leave a comment letting people know.
Task 4: You want to play chess this afternoon. Create a chess game event for 4:00pm today.
Task 5: Log out.
User 1: MIT senior, fits target audience as a college student in the Cambridge area. Has no user interface experience. User was briefed as described above and given the tasks above one at a time. The test went smoothly: the user completed all tasks without problem; the only intervention required was to explain how things should work if they had been fully implemented (in this case, the RSVP button on the "Awesome Event" page didn't visually toggle like it was supposed to). User was unsure about the difference between the Calendar and Browse Events tab; perhaps we should change the title of the Calendar tab to "My Events" or something more descriptive.
User 2: MIT senior who also fits the target demographic and has no previous experience with EventHub. User was briefed on tasks and was able to complete them all successfully without any need for guidance. As with User 1, User 2 had a number of questions regarding unimplemented features like the RSVP button that toggles and the Friends tab that does not show any people. User mentioned that he really likes the idea for the site and liked the "feel" of the site.
User 3
Task 1: Log in! -- User successfully logged in with google credentials
Task 2: RSVP for the event “Awesome Event” taking place on 5/12/11
- user looked at list of events quickly, after a couple seconds, user searched for event in search bar, found awesome event, and successfully RSVP’ed. says that events didn’t clearly display the date (they are labeled, today, tomorrow, etc.)
Task 3: Uh oh, you’re going to be late for “Awesome Event”. Leave a comment letting people know.
- user was already in my calendar, clicked awesome event, and left a comment.
Task 4: You want to play chess this afternoon. Create a chess game event for 4:00pm today.
- user first moves mouse around page seemingly searching for a button, doesn’t find one, then looks in toolbar, clicks create, fills in necessary information.
Task 5: Log out.
- user immediately moves to ‘logout’ button in header.
Thoughts on User 3: dates in list of events unclear, and we should probably use a calendar box like we do in the event page itself next to each event. Search bar has great visibility, though. Perhaps putting ‘Create Event’ in header with all the other tabs isn’t the best choice. More user testing would be required to find the best place for itUser 2: MIT senior who also fits the target demographic and has no previous experience with EventHub. User was briefed on tasks and was able to complete them all successfully without any need for guidance. As with User 1, User 2 had a number of questions regarding unimplemented features like the RSVP button that toggles and the Friends tab that does not show any people. User mentioned that he really likes the idea for the site and liked the "feel" of the site.
Reflection
The biggest thing we learned was that making a good implementation takes a lot longer than we expected. Everything was moving very smoothly for us until it came time for implementation. We had initially come up with a big idea for our project and over the course of GR1 through GR3 we narrowed our vision into something that seemed like a good idea and very achievable. The team seemed very optimistic about working together and everyone was communicating well and making compromises to their ideas in order to accommodate other’s ideas into the prototyping. Unfortunately, the biggest issues for us seemed to focus around coming together as a group on an aesthetic vision for the site and then implementing.
...