Design

After GR4, we basically scrapped our entire codebase and decided to start fresh. Our largest concerns in the site redesign were consistency in browsing behavior, clear and emblematic icons, calling out the major behaviors available to users and minimalism(both usertime spent on site and design).

Page layout

The image above shows a typical view of page in Jobious. The layout has three main components to it(starting at the top of the page): the account/search bar(red), the navigation pane(blue)and the content pane(green). The former two are reused on every page of the site and the content pane changes according to where you are currently located on the site.

The account/search bar and navigation pane are on every page and the content pane changes depending on the part of the site you are currently accessing.

Account/Search Bar

As pointed out in our early computer prototype, it made more sense to have an always-present search bar affordance in a consistent location. We attempted to be consistent with the placement of the search bar with other websites and placed this in the upper right of our application.

Additionally this bar contains the login, log out and account management affordances as that is the consistent spot that users expect these functions to be in as this is their location on most websites.

We chose not to allow for autocomplete in our search bar despite our TA's suggestion for it. This decision was made because we perform full-text search over everything in our website and it was not clear whether populating a person's name in autocomplete would result in a link to the person's profile(Facebook-esque) or to their reviews. While it may have been a nice function to have, it seemed to violate our simplicity policy and so we avoided it.

Navigation Pane

The navigation pane was created in response to our prototype testing and heuristic evaluation reports that we needed to callout the major functions of our site more. We made decided that the primary functions of our site were to cataloging favorite reviews, View Suggested Reviews, Alter your Reviews and Post Reviews. Contacting a user for additional information fell out of browsing through reviews and so was removed from this part of the interface.

The links themselves have a hover attribute so you know they are more than just text. Further when you click on them in addition to redirecting they clicked on one becomes highlighted with the same tone as the hover color to give additional visibility to where the user is located.

We chose this model over a side-hovering tab as we proposed in the paper prototyping model because users thought that it didn't call enough attention to itself nor that it promoted the behaviors the actions that we wanted users to perform(search, post, favorite, contact).

Content Pane

The content pane is the primary location of information put on the site. It's contents vary depending on the page being viewed. Specific features are listed in Pages.

Pages

We decided that the correct level of encapsulation for presenting these to the user was at the review level as this is a review driven site. This will possibly result in multiple reviews of the same company, however it is likely that only a few results for a company will impact your decision and we are trying to get to those immediately.

There is also the ability to favorite each review from this page by clicking on the star next to the review. This will cause the star to turn golden and any view of this view the star will be gold. Further it will be visible from the user's favorite page

Search

Exhibits the same display and navigation behavior as Recommended page because during our computer prototyping we were criticized for changing the interface so radically between browsing methods.

Favorites

In an attempt to maintain consistency between browsing behavior, the favorites page mirrors the format of the Recommended page except that it only shows reviews that the particular user has previously favorited.

In an attempt at error prevention unfavorite-ing a review does not immediately remove it from the page as the icon is large and it is possible to errantly click on it. Instead the gold favorite icon goes to gray. Then when the user leaves the page and comes back it is no longer shown. This way there is still a visual feedback that you have changed the state of the review while also provide for user error.

My Reviews

This page lists all of the reviews that the logged in user has added to the site following in the format of the Recommended page. The link from each of these takes the user to the View Review page where they may modify their responses as they are the original poster. Stylistically similar to the

View Review

There are three functions of this page: read the user's account of their time at the company, view the review and send a question to the user.

We attempted to humanize our application on this page because elsewhere there is not any real-time interaction between users because we do not want busy MIT students or alumni spending outrageous amounts of time on our application. We tried to do this by giving a conversational sentence to when the user worked at the positon the way a common friend would describe it. Further this sentence increases the visibility of the important information of what year in their MIT career they worked there and whether it was an internship, part-time or full-time.

The second task of contacting a user we decided to only provide a the poster's email. This is primarily for two reasons. First it maintains the minimalism of our site as recreating the inbox is not something that provides much functionality over email. Additionally, if you graduated you will probably not be visiting Jobious as often as the undergraduate body so you are unlikely to check your messages on Jobious(and we hate the 'You have a message!' emails) but you will likely check your email inbox multiple times a day. Secondarily, this site is designed to be closed to MIT students and alumni. When looking for information about a position while in the job hunt you may also be trying to solicit contacts within the company from the reviewer, in which case having a known working email to forward is far more valuable than a closed system.

These are the icons we chose to represent our user's ratings of overall, pay, hours and difficulty respectively. We decided that the most relevant reports should be colors that followed the theme of our site (the colors of Curious George: yellow, green, brown) as opposed to the more traditional grey tones because the rest of our site had so much white and grey already that we wanted to make these pop out.

We did not think difficulty was as significant as the others(hence the less dramatic color) because we saw the greatest variance in reporting how difficult a position was because it meant a variety of things to users. Perhaps better labeling of what we were trying to measure would have improved results, but we found it hard to say what was difficult so we left it up to users to decide and clarify in their comments.

The fields are affords editing when the entry is viewed by the original poster. This is in case a review was filed in haste after a bad day at the office and later the user regrets their review.

Create Review

Posting a review is a simple form that uses widgets that are common to the web. In retrospect we should have used a clickable bar graph of the icons(shown below) but time was a factor and this did not make it. As it turns out this causes catastrophic problems so we misallocated our resources.

We chose to do a side-by-side data entry method because comments during computer prototyping were that we had too much white space that did not serve a purpose.

Registration and Account Updating

We went with a fairly basic registration and account updating page. However we do require email verification.

Updating your account you can set what all of the relevant data about your contact information, your courses and biography.

Implementation

Our implementation is a Django-powered website connected to a PostgreSQL database. We chose to use jQuery to help us implement some javascript. While we avoided much the the Ajax cruft that appears on many web 2.0 sites today we utilized it where in-page feedback was needed by the user.

We briefly investigated using additional plugins to jQuery like jQueryUI to help format the page. However we chose not to use many of the standard widgets that are available with it as early iterations using them were judged wrong for the theme. In retrospect we should have spent more time attempting to skin these to match the look-and-feel that we were after as it was far more difficult to implement them ourselves.

Evaluation

We conducted our test in the conference area of the Student Center Reading Room using a group member's late-generation Apple laptop. No additional peripherals were provided. The team members each brought one user and functioned as an observer for that user.

Finding Users

We found users to test our product from within our living groups or were classmates outside of 6.831. All users were undergraduate men and women enrolled at MIT aged between 18 and 23 in non-6 majors. All had previously used MIT CareerBridge to search for jobs or applied to internships using a similar service. They all claimed competence in online tasks.

Briefing

We gave the users the following briefing. It is identical to what we gave users during paper prototyping. We did not think a demo was necessary due to the background of our users with job review sites and their fluency with technology.

Jobious is a web-based internship and job review service specifically designed for MIT students that combines aspects of both MIT's CareerBridge and InfiniteConnection.

Common tasks that a user may perform after logging in are:

Reviewing positions you have held

Browsing for internship positions recommended to you based on your preferences

Marking certain positions as your favorites for later review

Sending messages to other users to request additional information about positions they have held.

While participating in this study you should assume that you have previously created an account on the site and are already logged in.

Tasks

Our tasks mirrored those from paper prototyping as the major goals of using the site did not change. We removed or reworded some of the tasks to better fit the the implementation behaviors.

Task Number	Text Prompt
1	Favorite a review that is recommended for you.
2	Read a recommended review and contact the user that wrote it.
3	Post a review about the position you held last summer.
4	Find out what positions John Curtice has held.
5	Review your favorites and decide you no longer like one of them.
6	View jobs that pay "a lot".

Methodology

We brought the users in one at a time placed them in front of the computer that was already logged in. The team member who led them in then became an observer while another(facilitator) handed them the briefing. The facilitator asked if the user had any questions about the purpose of the site. After clearing up any confusion the user had we handed them tasks 1 to 6 one at a time as they completed the previous one. At the conclusion we thanked them for their time and asked for any additional feedback they would like to give

Usability problems

Severity	Task	Description of Problem	Times Encountered	Possible Solution(s)
Catastrophic	2	User was unsure about the level of encapsulation of the results. He wanted them to be aggregates and clicked on the returned result expecting to be taken to a list of reviews	2	Aggregate the reviews for the same company together and make an intermediary page showing all reviews for that company.
Catastrophic	3	User was uncertain of whether 1 or 5 was a better review	2	Our paper prototyping model has this right. Our last version should have included the same icon language as the rest of the site in the same fashion as in the paper prototype.
Major	1	User believed that the recommended reviews were aggregates for a position rather than an individual review.	2	List the name of the user that wrote the review to reinforce that one individual created this
Major	4	User was unclear what was returned by search for term "John Curtice"	2	List users in separate return area on the search screen
Major	6	Users searched for the words "a lot"	2	Give sort-by controls to results rather than "best matching" result returns.
Major	6	User looked for sort-results-by button. Did not find it and gave up on the task	3	We already have ordering and filtering capability built in, just put the fields to order by at the top of the search results.
Minor	1	"Does the star do anything else?"(User expected additional functionality based on the size of the star)	1	Make the star smaller or display some information within the star such as the total number of people that have favorited the review.
Minor	2	Grammatically incorrect sentence describing when a user was employed at the job	2	We would make a grammatically correct sentence for each possible output. There are only on hte order of 15 so it would not be difficult.
Minor	3	User misspelled Microsoft and did not catch it before submitting	1	Autocomplete based on company name
Minor	3	User could not remember exact position title	2	Autocomplete the position field
Minor	5	The user was distressed that clicking on the star didn't make it immediately disappear from the favorites page as it is no longer marked as a favorite.	1	Fire an AJAX reques to remove the div element from the page
Cosmetic	2	Icon rankings on View review page are not consistently spaced	3	Make each of the rankings be 5 equal-width icons with those that are not included grayed out or translucent. This would also be redundant encoding of the scale and we could forgo the (*/5) that follows it.
Cosmetic	4	User looked to pagination for how many results retuned but only found number of pages	1	Display the number of results as an integer in addition to the number of pages

We have a lot of major usability problems, several that we did not have previously. We should have foreseen some of them, or at least the magnitude of problem that they would have caused. Our risk of minimalism clearly didn't pay off(at least our implementation of it) and this was the source of many of our problems. The reflections section will cover how we would have avoided the more meta problems if we were to do it again.

Reflection

Easy in paper prototype does not mean easy in code

Our paper prototypes displayed a lot of beautiful behaviors that are really, really difficult to achieve in software. This set our expectations really high based on the ease with which these things were said to be accomplished using modern tools. We did not find that to be the case so when we encountered problems and could not solve them after repeatedly banging our head against the problem we cut corners on usability to make the behavior function.

Get the model right first

We spent a lot of time going back and forth with the data model about what the correct way to represent all of the data and we ended up at a level that caused a lot of user distress. We do not believe that we ended up at the right modeling of the system for the presentation that we wanted to do, but if we had generated a more robust model initially we would not have had much trouble changing between them.

The Waterfall Model Doesn't Work

Perhaps the largest failure that we had was using the waterfall approach to design as opposed to spiral model. Even though we did have several iterations of prototypes, with each one we made some rather sweeping changes that were inferred to be better based on user feedback from the previous test. Unfortunately some of these decisions were headed just in a different direction rather than the right one and we would have noticed this if we had spent the time . We should have then gone and prototyped those and tested them before deciding that was the right way.

User test aggressively

We made the cardinal sin of assuming we are our users. We didn't really ask people what they thought of our incremental implementations along the way choosing instead choosing to assume we could make the decision for them. While that might work for experts we learned that we do not yet have that level of fluency in design language and user behavior and that the only way to get there is to actively test and retest to verify your assumptions until they begin to match user behavior.

Project Management Decisions impact Design Decisions

We had a very basic working version in a different language early in the process but we then decided to scrap that code and start afresh with something we thought would work better. While it did make it easier to do many things(particularly database queries), unfortunately none of us was as well versed in it as we hoped. This lead to a us often scratching our heads as to how to do something with Django when we could have written the script ourselves and moved on, though it would not have been as maintainable. Thus for the scope of our project it wouldn't have mattered.

Child pages

Jobious GR6