Developing the Prototype
In this phase we coded an interactive prototype in PHP and AJAX
Revised Interface Design
When developing the prototype, we knew we had to include the
Adding Content task,
because the entire point of the portal is to bring relevant information
to the user. This would be impossible without the ability to customize
the interface. Most of the other tasks were very easy to implement,
especially since some required no more functionality than just having
clickable links. We chose not to implement the login/logout functionality,
since that would have required more of a backend than we cared to implement.
We did make some changes since the last phase, however:
The search bar is now the same width as each column of the page, instead of
spanning columns. We did this because some of the users we interviewed for the
lo-fi prototype wanted to resize their search bar. We didn't really have an
interface for doing that, and we asked them what they would prefer. The users
said that there really wasn't a reason to differentiate the search bar from the
other content, so we just made it a regular box.
The add content box is not treated as a regular content box anymore. We went
out of our way to make it extremely apparent, since some of our lo-fi users had
trouble with the box. None of our users had a huge problem with the add content
box coming up as a content box, but we felt that we should make it even more apparent
to avoid any confusion.
In the same vein, we wanted to emphasize state changes in the portal. It can be
hard to identify new content items, especially if the content is text-based, like most
of the content in the portal. In order to rectify the problem, when the portal loads
in a webpage, new content items are highlighted in yellow. To ensure that the highlight
is not distracting, it fades over time until it dissapears entirely.
In the lo-fi prototype, we didn't have an interface for recovering closed content boxes.
To make sure that users can recover their content if they accidentally close it, we've added
an interface to add boxes back in after they've been closed.
The interactions we wanted to provide the user are really no different than the ones we described
in our original storyboards. The added functionality of being able to
recover content boxes is simple enough to describe in words:
- If a user closes a content box in error, all they have to do is click the "Configure Me!"
link, and they will be offered a list of closed boxes to recover. When clicked, the closed
content box will fade back in.
As far as interfaces we didn't implement, we didn't implement a real backend, of course,
which meant we have no user database. As such, we didn't implement the login/logout
functionality. We also didn't implement the ability to edit individual boxes, mainly because
we ran out of time. Below is a short description and sketch of the features we didn't implement.
We didn't implement the login functionality. If there isn't a logged in user, all of
the user-specific fields are left blank, i.e. no calendar events, no emails, etc. Once
the user logs in, all of that information is filled in. Logging in and out of a system
is something our users do all of the time, so we weren't particularly concerned with
testing that aspect of the functionality of the portal.
We also didn't implement the ability to edit boxes. A good example of this is the weather
content box. If a user wanted to add, say, their hometown to the weather box, they'd click on
the [Edit] link, type in the appropiate zip code, and the weather for their hometown would
appear in the box. Removing weather information is as simple as clicking [Edit] then clicking
an [X] next to the weather entry the user no longer wants.
And now for what we actually implemented. As we mentioned earlier, we didn't do any sort of
backend, so all of the content for the interactive prototype is flat and pre-defined. We have
flat content email, coursework, calendar, and weather boxes that don't do much but look pretty.
You can add two more content boxes, one for a fake CNN RSS feed, and another with a bookmark to
the HFID website. There are two interactive boxes, the login/logout/configure box, and the
All of the boxes are drag and droppable within a fluid three column layout. Instead of
having to drag the entire box into a new column, only the mouse cursor has to enter the
desired column when performing a drag and drop operation, resulting in a fast, intuitive model.
We've provided an affordance for this operation as well. The title bar of each box serves as the
drag and drop handle, and as a feedback element, the mouse cursor tranforms into a four-way arrow
when hovering over the title bar. If you don't want a particular box, all you have to do is
click the [X] in the top right corner of the box, which is the ubiquitous standard nowadays for
closing windows/boxes. The box responds by fading from view then disspearing entirely, showing that
you actually did close the box. An important thing to note is that the [X] is inside the title bar,
which typically shows a four-way arrow cursor, but we've explicitly declared that the cursor return
to normal when hovering over the [X]. For added visual feedback, the [X] changes color when you're
hovering over it. In fact, all of the interactive elements in our system visually change when the
cursor hovers over them, either by changing color, having the actual cursor change, or both.
The interactive content boxes are also flat, but they can change state when you click on buttons.
The search bar, for example, displays canned search results. The login/logout/configure box is an
entirely different animal. As we mentioned before, logging in/out is impossible in our prototype,
but the configure function works. When a user selects "Configure Me," the add content box appears
and prompts the user for what type of content they want to add.
Again, we purposefully didn't include the ability to edit individual content boxes, because
we didn't want to build the logic routines behind that. Also, we have a lot of canned data and
content because we didn't want to actually code a backend for content generation. This especially
was a big deal when dealing with searching, adding RSS feeds, and adding bookmarks.
Other than forcing the evaluators to enter canned queries and data, we didn't really pull the wool
over their eyes. Most other features are fully functional.
Tools We Used
We used PHP as our backend language, because it was supported by
the server architecture, and the team already knew it. For the AJAX and other visual effects, we used
prototype and script.aculo.us.
The tools basically allowed us to make AJAX calls and do all kinds of pretty visual effects with very little
learning curve. PHP is a language, so that didn't limit us in any specific way, and prototype/script.aculo.us
There weren't any real problems with the tools, other than the slight learning curve for script.aculo.us.
Back to Top
For the cognitive walkthrough, we followed the instructions detailed by Gregory Abowd here.
Our prototype focuses on two important user values: the need to have customizable, personalized web space, and the ability to get necessary information quickly from the web space. We achieve these goals while minimizing the input from the user, pulling the necessary information from pre-existing services at Olin (for courses, etc). The first thing the user would normally see is the login box. For demonstration purposes, and because we assume that our users are adept at the completion of this task (see: Indication of Users, below), we have omitted this step. Users also have the option of storing the password temporarily (approximately 2 weeks) if they are accessing the portal from their private computer. Once the user logs in (for this walkthrough, the user is Gordon Baker, username: gbaker, password: Oakenf0ld) e-mail, calendar, and other Outlook information is loaded from the Exchange server. Any new e-mail or calendar information is temporarily highlighted. Additionally, course information is loaded from SIS. Assignments for each of the classes is loaded from a central location and, as with e-mail, new assignments are temporarily highlighted.
Information is segregated into individual boxes, which are movable on the screen. The user sees this when they mouse over the top bar of each box. The mouse pointer changes to the "four-arrow" pointer, the indicator that an object is movable. The primary interaction we've written for the site is the process for adding new content. Other portal sites make it difficult and require a certain knowledge base to add a news feed. Instead, we allow users to click through and type in just the base URL for the site, and auto-find the website on the backend. Visually, we represent that the user is making a change to the site by dimming the site, except for the dialog box, during the configuration process. The dialog box provides the ability to easily exit at any point without making changes, and feedback is given to the user in plain english, not technical jargon or codes. High-level users will discover shortcuts and quick-steps, such as adding many sites at once, through small text that does not distract the basic user.
Overall, we've tried to make this accessible to the entire breadth of the Olin student community, providing a location people can quickly access relevant information.
Adding Content (Bookmarks/RSS) -- The point of the portal is to consolidate information in a kind of "one-stop-shop" for our users. No two users are exactly the same, so it comes as no surprise that each individual user will have different interests, and may want to keep track of these interests on the portal. We want our users to be able to customize their portals with minimal knowledge of web technology, so we've tried to make the process of adding content as simple as possible.
The content added can be as simple as a bookmark, or as complex as an RSS feed. We've tried to abstract away the difference between RSS feeds and bookmarks in our interface, again to minimize the amount of required knowledge about web technology.
List of Actions for Task Completion
For the "Keep Track of a Site" option:
- Find and click on "Configure Me" Link
- Click on "I want you to keep tabs on a website."
- Enter address of desired website and click "Hook Me Up!"
- The backend polls the address.
- If the address is an explicit RSS feed, the user chooses from one of three options: "Yes, add the RSS feed," "No, just add a bookmark," or "No, that's not what I wanted."
- If the address is a website with an RSS feed, the user chooses from one of three options: "Yes, add the RSS feed," "No, just add a bookmark," or "No, that's not what I wanted."
- If the address is a website with multiple RSS feeds, the user has one additional option "Kinda, show me more," which will show the user the next RSS feed that the backend found until the user either exhausts all the RSS feeds found, or the user chooses the desired feed.
- If the site does not contain any RSS feeds, the site will tell the user as such, and ask the user for an explicit RSS feed URL. The site will also ask the user if adding a bookmark instead of a feed is okay, or if the user doesn't want to add anything at all.
For the "Adding a Bookmark:" option:
- Find and click on "Configure Me" Link
- Click on "I just want a bookmark."
- Enter address of desired website and click "Hook Me Up!"
- The backend creates a bookmark and adds it to the bookmarks section, and offers confirmation to the user.
- The user clicks "Done."
We anticipate that the average Olin student is technically confident and competent. They may not be intimately familiar with the "idea" of portals, but, at a minimum are adept at basic and intermediate Internet navigation. We therefore assume that our users are familiar and comfortable with logging in and out of a web service, the concept of hyperlinked pages, and filling out and handling forms.
Given this information, the evaluators step through the action sequence to critique the system and tell a believable story about its usability. To do this, for each action, the evaluators try to answer the following four questions.
Will the users be trying to produce whatever effect the action has?
Are the assumptions about what task the action is supporting correct given the user's experience and knowledge up to this point in the interaction?
For the adding new content interaction, the straightforward, linear action sequence is complemented by the fact that, given what is indicated about the users, they should be making the correct assumptions about what they're doing. Each of the intended actions has a clear link to be clicked on.
Will users be able to notice that the correct action is available?
Will users see the button or menu item, for example, that is how the next action is actually achieved by the system? This is not asking whether they will know that the button is the one they want. This is merely asking whether it is visible to them at the time when they will need to invoke it. An example of when this question gets a negative supporting story might be if a VCR remote control has a hidden panel of buttons that are not obvious to a new user.
The potential problem with the portal depends on how capable the users are at finding the "configure me" text. Other than that, most items have good definition and there is little to distract from task completion, especially since the rest of the portal fades out to emphasize the intended focus of attention.
Once users find the correct action at the interface, will they know that it is the right one for the effect they are trying to produce?
This complements the previous question. It is one thing for a button or menu item to be visible, but will the user's know that it is the one they are looking for to complete their task?
We've done our best to keep the language jargon free and as converstional as possible. Most of the decisions are "yes," "no," or "give me more options, " making each decision very clear.
After the action is taken, will users understand the feedback they get?
Assuming the users did the correct action, will they know that. This is the completion of the execution/evaluation interaction cycle. In order to determine if they have accomplished their goal, the user needs appropriate feedback.
We try to provide as much visual feedback as possible, along with actual wordings about what the user is doing. By showing them what's changed with visual feedback and confirming with text, we figure that the user will understand the change.
Back to Top