FINAL
REPORT
..................................................................................................................................
I Problem
Statement
SFnight is
an information-centric web-site that focuses on nightlife information
of San Francisco bars/clubs and their events. The target audience
falls into two categories: consumers and players (bars owners,
promoters, and DJs etc). The 213 MySFnight team is focusing on
personalization and customization of information related to consumer
needs.
II Solution
Overview
The MySFnight
team has worked on several areas of customization. Any user can
store venues and events in a list that can be emailed to other
friends for planning purposes. Users can sign up quickly for a
generic newsletter with announcements of upcoming events and venue
highlights. To receive more customized information in the newsletter,
users need to sign up and create a MySFnight account. In addition
to a customized newsletter based on a user's preference, the user
with an account will have a customized MySFnight area in the homepage,
and access to the main MySFnight area. Main features of the MySFnight
areas include: recommendations based on the users preferences,
a calendar displaying the recommendations, a second calendar allowing
the user to add his/her own venues/events for planning purposes.
There are also separate areas storing user's own venue choices
and events
III Personas
and Scenarios
Personas
In our Personas design we analyzed different methods of knowing
and gathering information from nightlife consumers and potential
users. The methods' choice were based in time and resources constraints,
as well as its effectiveness for the project purpose.
We spent
more than 8 hours in the Personas creation. We went back several
times to refine the persona description. After talking about them
for so long time, we started to think they were real, at the point
that is difficult to 'kill' them, or not designing for them. First
the original group members started creating their personas. Then
after the merging, the male perspective refined them and brought
a new persona. Our persona creation methods include structured
interview protocol, interview record and notes and face-to-face
interview with friends. Our interviews lead us to define four
subjects: a male around 30 years old, Internet savvy, a graduate
student from Berkeley; a male Brazilian PHD student, around 30
years old, have been using Internet for 5 years, but is not connected
all the time; a male graduate student of more than 31 years, Internet
savvy and highly connected, and a female Internet savvy, but not
highly connected.
Based on
the definition of subjects, we conceived the following personas:
Stefan
Kizmiaz, an aesthetical pragmatic32, enjoys quiet mood music,
sometimes explores live jazz, and also likes music from the
50's and 60's. Well educated, and computer savvy, consultant
who works for Accenture in financing/statistics, usually very
busy. His Personal Goals include to socialize selectively, to
relax and not be bored. His practical goals include going to
the right place, where he can expect the right people and atmosphere,
does not like to waste time and likes to know what he expect.
Comfort and convenience is highly important. He does not like
to be overwhelmed with irrelevant information.
Chris
Roberson, the easy going, doesn't care much about organizing
her room, but like to organize parties. Chris for short. 22,
but looks older, and has a cheerful personality. Community College
student got another year or two to go. Works part-time at a
restaurant/cafe without door seating, right next to some clothing,
bookstores. Her personal goals include being happy, having fun
and meeting lots of people. Her practical goals include not
spending too much money and going to several places in one evening.
Leonardo
Varella, the explorer. He is a 37-year-old PHD anthropology
student at Berkeley, from Venezuela, fluent in some Romantic
languages -- French, Italian and Spanish (his mother tongue).
He likes Latin and World music and enjoy dancing, so does his
significant other. On a regular workday he grabs whatever is
available, but when he goes out he likes to try different cuisine.
His personal goals include having a good time, being surprised
and explore. His practical goals include experiencing different
things
Rich
Liaw, getting to be more sociable. He is 30, born to a conservative
oriental family, relocate to the states for education. Had a
MS degree from New Jersey Institute of Technology and since
graduation been working for various Silicon Valley firms. Job
is intense and remunerative, on the hardware side, and usually
immune to the dot-com roller coaster. His personal goals include
escaping from the work pressure, relaxing with his girlfriend
and/or other friends, discovering new and interesting things
and having a good laugh. His practical goals include finding
something interesting in American pop culture and have a good
for refreshment; relying on the reviews except for food. Budget
flexible and willing to pay a fair price if thinks fair. Does
not want to be surprised if with girlfriend, but yes with colleagues.
Being conservative after a long week, but more aggressive if
slow season. Does not worry parking.
These personas
are representatives of typical bar/club goers. They represents
the most part of the visitors to Mission street. Each of them
demonstrates characteristics of one focus group. These groups
are differentiated by work, income, origin and culture background.
They reflect the diversity of the SF nightlife consumers.
Task Scenarios
In defining
persona tasks, we find that most personas will need to do the
some of the same tasks to achieve different goals. We choose Stefan
as someone representative of all users. He has a cosmopolitan
perspective, is very particular, does not like to be overload
with information; receives visitors and therefore need to share
information with others; has music preferences; likes good reviews.
He is connected to the Internet wirelessly. By working in the
dot.com environment as a consultant, he is also the ultimate audience
for SFnight.
Scenario
is a concise description of a potential user (persona) performing
some tasks in an information system to achieve the user goal.
It helps to test validity of the design and its assumptions. Building
scenarios requires an immersion in the Personas "inner goals and
behaviors", a context and task details. It is important
to remember that the tasks are fluid and changeable.
In our design
process, each group member was responsible for creating a scenario
based on a persona and the persona's Primary Tasks analysis. Since
some tasks are common to more than one persona, we delegated specific
primary tasks based on how well the primary task matches the persona's
needs. We then refined the scenarios, redefining a context and
the tasks that would suit it.
We choose
Chris to initiate the registration process. Chris just
heard from a friend that she could receive information about free
events and promotions by e-mail. All she would need to do is to
sign up for a newsletter at the SFnight website. Chris types sfnight.com
and glances at the home page to find something about the newsletter
and signing up. She saw some thing about signing up MySFnight
and also the newsletter. She clicks on something and the registration
process starts.
For
event planning, Leonardo will be sharing some information
with friends. He might use some customized features or general
ones. The context is that in Thursday eveing, Leonardo is at
SO's [significant other] apartment, plugged into the Internet
with his laptop, when he receives a message from the SO about
the evening. Leonardo goes to SFnight web site, where he usually
finds a couple of things and sends the options to SO and colleagues.
Planning a future event task is based on Stefan. In this scenario,
Stefan is still at work on Wednesday evening. There is a project
deadline Stefan needs to meet before the weekend. One of Stefan's
friends from New York is coming to SF with his girlfriend for
the weekend. Stefan will be spending Saturday evening with them
. He wants to take a quick break from work and logs on to his
MySFnight to get some quick ideas of things to do on Saturday
evening.
For
After-Event task, we selected Rich. On Friday evening, Rich's
group has just completed a project and send the code to NEC.
Everyone is in the mood for a wilder night in the City. The
boss has promised everyone a free drink before dinner and all
follow the boss to a bar. No sooner than stepping inside the
door Rich discovers it's the very one where he and his friends
once had a bad experience. Too late. Perhaps things have changed
a bit, Rich hopes secretly. No way. Service is still pretentious;
drink poor - watery and tasteless; and the wine list limited.
Everyone shrugs it off. On the way back, Rich's boss suggests
they should let the words spread as a retaliation. 'Why bother,'
says Rich, 'I just jot down something on SFnight website and
everyone will know. Maybe they then take service seriously.
When designing tests involving users, we decided to not test
the after-event task of writing a review. Having more than three
tasks would make the test very long. We did not want to wear
out our participants and wanted to focus on the most critical
of SFnight customization features.
IV
The Final Interface Design
Current
the functionality
Users can
register to MySFnight. In the registration page, a user can choose
her login information, select personal preferences and opt for
receiving SFnight newsletter and coupons.
After registration
to MySFnight, event calendars are displayed for user to choose
and schedule her events. She can review editor's picks, read about
event profile, update her preferences, choose multiple events
to send to her friends, and plan events for future weeks.
From the
personalized area of SFnight home page, user can also enter an
event profile page directly. On event profile page, user can read
about the event description, send the event to a friend, or add
the event to MySFnight event list.
For existing
members, they can log into MySFnight from SFnight main page. After
login, MySFnight main page is displayed with top event description,
minimized event calendar, which can be expanded into full event
calendar. User can also search venues by date, location, type
and name. ·
See
SFnight Flowchart, focused on customized features.
What was
left unimplemented?
According
to our initial plan for the scope of this 213 project, the only
thing left was: personalized email newsletter and event calendar
for current month.
Tools
used to develop the system
Tools
for prototyping and implementing the UI For developing low-fi
prototype, we used paper clips, pencil drawings, laser printer
and stickers to make interface mock-ups. We also used Microsoft
Word to design the Calendar and other parts. These mock-ups
were organized into a test kit, which was used in low-fi prototype
usability test.
For
most of the interactive prototypes, the MySFnight pages
were developed with a combination of web authoring and graphical
design tools, which includes Macromedia Dreamweaver, Adobe Photoshop,
Macromedia Fireworks. Dreamweaver was used to manage the website
file system and link structure, as well as page layout, format,
tables, hyperlinks and fonts. Photoshop and Fireworks were used
to design graphical icons, images, banners and buttons.
The first
interactive prototype consisted of all static pages. The ensuing
prototypes were connected to a live backend. For the backend,
the current site prototype is developed in Perl and the backend
database is Mysql (33 tables).
How the
tools helped and how the tools did not help
For the
front end parts, the tools were convenient and easy to use.
They helped to implement our design ideas, make quick change
and improvement based on user feedback, without needing to consider
the impact to the backend system. They are great tools for making
mock-ups and prototype. All these tools include hyperlink management
function, which allows us to structure the process of user interaction
with the website, without actually implement the whole system.
The tools
did not help with developing in a more flexible way. Some of
the pages were implemented with templates in Dreamweaver. It
is a good approach to reduce workload and simplify web page
authoring process. However, templates sometimes became a constrain
to modifications. When a component needed to be changed according
to user feedback, it was not easy to make the change due to
template constrains. Many times, significant change was needed
in the template to accommodated change of components.
For the
back end, Perl programming is very heavy (more than 11,000 lines
of codes), partly because Mysql doesn't support stored procedures
and Perl have to handle all functions. The 213 group was fortunate
to have Jason Chen, the other member of the SFnight masters
project, to do the backend implementation. For real development,
it is recommended that larger database system like Oracle or
Sybase be used. Perl programming will be relatively light then
and site performance will be also greatly improved.
Other
technical considerations
The whole
current site is template-driven and allows interface designer
and programmer to work independently but well combine their
efforts. Cascade-style sheet is widely used across the whole
site and assure the site-looking consistency. Javascript also
applies on some pages and enable some user interaction on client
side. SFnight will consider using XML in near future and also
think wireless access to our site is not desirable in the near
future. For more detailed discussions of the technologies used
and considered for the entire SFnight project, check the Technology
section in the SFnight project writeup.
V
Design Evolution
The design
of MySFnight features has undergone major changes following each
of several prototypes. Each prototype served as a milestone for
the design process. Each iteration also helped us explore different
design concepts by validating some concepts while revealing problems
and potential new solutions.
From Low-Fi
Prototype to 1st Interactive Prototype
The Low-fi
Prototype Instead of a 'full-blown' HTML-based prototype, we used
a paper-based low-fi prototype at an early stage of the design
process. The paper prototype is easy and cheap to create and change.
When interacting with a rough model that can be changed immediately
to reflect their input, users testing the system are more comfortable
discussing their thoughts and ideas. A 'primitive-looking' prototype
helped us overcome the user's resistance to change the design.
The designers were able to quickly gain a good understanding of
the desired interactions and information or features needed to
accomplish defined tasks.
The low-fi
prototype evaluation allowed us to discuss and explore important
issues that were not clear at the Initial Design stage. Following
are some major problems and potential solutions considered in
next design stage.
Terminology
on labeling: "Add to My List", or? Our planning tool for sending
event or venue options to friends via e-mail has a touchy labeling
problem even from first sketch. Several names were tried before
the prototype. We decided to use the original name and made changes
along the way with our participants. Choices include "Add to My
List", "Start a List to My Friends", and "Create a List". None
worked very well with our users, and one participant expressed
that a more complete description can make user's life easier,
such "Add to a list to send to your friends". This may be an accurate
description of the feature intended, but it is too lengthy.
After
thoughts: User input is important even though they did not
bring up a straight solution. A possible solution now is based
on the description user can understand and our idea of creating
an icon to be used with each element (event, venue etc). Lengthy
description can be used in legend and popup tool tip to enhance
users understanding of the icon. The icon can then be used in
all relevant contexts. The current design only provides the Add/View
functionalities in the individual profile page of a particular
venue of event. This solution could also allow us to include the
feature in the search results and other places without taking
up too much screen real estate.
Users
are always right: "MySFnight" improvements
MySFnight page is the most complicated one and we expect most
user feedback from that. Users made fairly extensive comments
and suggestions on the content, function, scope, navigation and
even new needs:
- Add Bands,
with music sample, not only DJ.
- Review
should be clearer for them. Not reading their own reviews, but
other's reviews should be of main interests.
- Distinction
between Editor's Pick Events & Your Pick Events: A better explanation
or redesign should be considered to facilitate user comprehending
the difference and make better use of the two. Users should
also be allowed to have second thoughts and change their preferences.
- Changing,
Picking, Marking and Adding! Those actions were responsible
for testers perplexity. Changing preference, picking up events,
adding to a list, etc, should be subject to more close study
to improve the recognition and ease of use. Using icon, as proposed
before, is one solution.
- Calendar-based
Information: Better organization of information should be always
a priority for users. Since our calendar is a monthly view of
about 30 days, from the current day to the next 30 ones, users
demand to have a better perception of the month representation
and change. 4-week calendar may be an alternative. Also prompt
be the testers, we decide to use the word Calendar explicitly
as the title of the feature.
From Heuristic
Evaluation to 2nd Interactive Prototype
Overview
of Heuristic Evaluation The BESS project development team
made valuable evaluation of MySFnight project prototype. Their
findings provided insight into the effectiveness of the prototype
design, the usability of the user interface, as well as the
integrity of information architecture of the MySFnight features.
BESS project
team evaluation report specified some general problem areas
that persisted across the interface. The report listed several
overarching themes, rather than specific violations, which include
confusing labeling of cons, buttons, and pages, misleading design
of calendars and lack of user task feedback. There are totally
33 heuristic violations listed in their report, with 16 of severity
3, 11 of severity 2 and 4 of severity 4. Heuristic violations
are scatters among nine of the ten violation categories suggested
by Neilson, with 7 violations in matching between system and
real world, 6 in error prevention, 5 in user control and freedom,
4 in consistency and standards. Only the category of helping
user recognize, diagnose, and recover from errors received no
violation. The clear listing and severity ranking of these violations
greatly helped our team to identify the issues that need to
be addressed and the priority of improvements in future development.
Specific
Issues Specifically, BESS team found that icons, buttons,
and pages were labeled inconsistently. Sometimes icons had explanatory
text, but other times only the graphic appeared. Also, the placement
and labeling of buttons or icons did not always clearly indicate
their function. They had a hard time figuring out what were
"submit" buttons and which were icons that represented a link
to another page. They feel that using more traditional-looking
buttons might fix this problem. Also, using text links as opposed
to graphical links would make the results of clicking more obvious.
The evaluation team members all had difficulty with the way
that certain pages and functions were named. They did not understand
the function of "View My List" from its title or icon. This
also held true for functions like "Send to Email List." This
label seemed to imply that an email function would occur immediately.
In reality, it actually meant "add an event to a running list."
Some team members believe that the use of the word "list" is
too vague. For example, distinguishing between a list of friends
and a list of events is crucial for this interface. The evaluating
team liked that the site contained editors' picks. However,
they did not like the display of those picks on the My SFNight
page. The two calendars, with identical design and size, confused
them. They competed for user attention: it was difficult to
distinguish between the two. The team suggested three alternatives
1. move
the editors' picks to another page
2. integrate
them into a single, larger calendar
3. or
add the picks to the page in a smaller, but graphically distinct
manner.
In their
positive feedback, the BESS team expressed that they like the
idea that the user can add multiple items to his/her SFNight
Calendar and Email List with one icon click. They appreciate
that the user can choose events according to venue and geographical
location. The maps and directions are useful. They also like
the photo on the Event Profile page. The ranking of venues on
the home page is very useful. They like how the top picks of
the week are on the home page. Besides, they like the functionality
of receiving email advertisements for future events, based on
events user attended in the past. They think that the search
results page has a lot of useful content in a compact format.
The graphic design is very professional looking.
How Heuristic
Evaluation and Other Factors Affected 2nd Interactive Prototype
In order
to address these heuristic violation issues, the 213 project team
needed to coordinate with the schedule of the overall SFnight
project. When redesigning the interactive prototype for the second
time, priorities of which issues to address first took into consideration
the overall SFnight project needs as well as heuristic violation
comments and suggestions from the SIMS Textbook Exchange Team.
Given the
overall SFnight project priorities and schedule, issues such as
a comprehensive help system and spell checking of the entire site
are held off for the next prototype even though they were ranked
as high severity. Some issues requiring further research and experimentation
were held off due to time constraints. For example, some websites
used a welcome page as feedback and a chance to provide additional
membership/account information to users instead of simply returned
the customized page, as in the SFnight homepage in the prototype.
The
team wanted to see if this is a practice used by most info-centric
websites before implementing. A new button design that will be
standard throughout the site is also being explored. The evaluators
also found issues in areas that are mostly not within the customization
focus of the 213 project, such as in the search page, the events
and venue pages. The issues may or may not be addressed depending
on the priorities of the overall site.
The term
"E-mail list" is standardized across the site to establish the
temporary list that can be sent to friends. The team decided on
the site standard of using relevant icons with each "item" instead
of a check box that can be used for various purposes by depending
on which button is selected. This interaction style is prominent
in the MySFnight page, the E-mail list, and the search results.
Other significant design changes were made in the MySFnight and
E-mail list pages. Changes were made in the Sign Up page. A new
update preference page is created. Many minor changes such as
the use of radio buttons instead of check boxes were implemented.
Specifically,
we made the following changes in our design to address heuristic
violations:
- For
global violations View My List is changed to View Email
List. The design of the page is changed so that the list is
on top, and add on email features on the bottom. Changes are
made to maintain the consistency of the terms. The team has
agreed on Email List as the main term. Comprehensive help and
documentation will be developed later in the project. For this
prototype, it is only partially developed.
- For
violations in Home Page Welcome message is not supposed
to replace the main page. It is displayed only in the personalized
area, together with change of icon and color to signify successful
registration. The team has discussed the use of a separate welcome
page for user feedback. Users of the low-fi prototype did not
find this to be a problem. We decided to investigate how other
info-centric sites, not necessarily ecommerce product sites,
handle the situation.
- For
violations in Email List The "Send to Email List" button
is changed to "Add to Email List". We decided on using a button
instead of graphical icon. The textbox for email address is
enlarged to allow multiple email addresses separated by coma.
A remove button is added to each item, allowing user to delete
a select item individually. There is no need to select all the
items to delete and then click remove. The convention would
be used other places throughout the site, such as in MySFnight.
For functions where buttons are still required, a redesign was
considered. The ability to save a list for later will be represented
by a button indicating: Save for Later. Also decided to add
a Clear List button.
- For
MySFnight sign-up page Confusing text of "light weight"
email newsletter was changed. More informal verbalization was
considered. § A cancel/clear page button was implemented. Also
reconsidered the wording and how to provide better feedback.
Ambiguous checkboxes were changed to radio button for deciding
email newsletter options. A welcome message was removed before
user finishes sign-up process.
- For
MySFnight main page Different colors for the calendars were
considered. An alternative calendar design where only one week
is displayed at a time is being explored due to some design
and technical implementation advantages. We also changed the
design to the convention where a remove icon and a move-to-my-pick-area
icon will be next to each item. Same convention as in Email
list page. An option for minimizing a calendar was added for
some users who would want, especially frequent users. The Preference
Box was re-considered. We also experimented with color to make
numbers bigger and bolder.
From Usability
Test to Final Interactive Prototype:
In the usability
testing we focused on areas requiring the most user interactions,
or the personalization process of the 3rd interactive prototype
design. User evaluation allowed us to examine whether our improvements
since the previous prototype are truly improvements and whether
we are working in the right direction. The test results tell us
that as far as usability there can never be too much iteration.
Labeling,
again:
Labeling
is still a problem. After much struggling with the alternatives,
the current prototype we are testing uses "Add to E-mail List"
and "View E-mail List". It turns out to be some users confuse
it with "mailing list". The suggestion from the first user testing
"Add to a list to send to your friends" might be the only solution
for this case, though we still somewhat reluctant to implement
since it's very long. The current icon, without mouse-over tip
did not solve the problem.
Possible
improvement: At the legend we will change to the long name for
"Add to a list to send to friends". We also will make the icon
a little bigger to improve visibility.
This solution
could also allow us to include the feature in the search results.
MySFnight
Registration: the more access, the better
When testing
the registration process, we provided users with a SFnight home
page that has 3 entries for them to sign up. The process is
considered easy, but to find the right place to sign up is not
yet straightforward enough to users.
Possible
Improvements: re-organize our information by 1. We will create
a link such as "Not a member? Sign up Now!" in the sign-in area
under "Forgot your Password?". Besides we will create a logo
like the Sign-In, and reorganize the information of the three
different sign ups.
Feedback,
Feedback, and More Feedback Although testers noticed that
they have sign up (it is provide Welcome etc), but two of them
would prefer to have a confirmation page.
Possible
improvements: We decided to create a confirmation page, where
besides saying "Thank you for sign up SFnight", we would present
an abstract of what users might find at the homepage personal
area, and at MySFnight; as well as the possibility of saving
lists etc, the user profile.
User
Initiatives: The idea of providing recommendations also
based on people who have similar profiles can be interesting
for further development. To use it based on picks, would imply
in use together a way to confirm or not the usefulness of that
recommendation.
Calendar
Features: Again our precious input is from our user. Again
MySFnight was considered interesting to users, especially the
idea of providing in advance a calendar with Editor's Pick to
user's preferences. One user would like to have a month view,
especially to track hot events.
Process,
Labeling and Layout: The labeling of MySFnight manipulation
buttons this time was not a problem: the idea of remove icon
and an arrow icon to move were clear.
The idea
of offering 'minimize' and 'maximize' was not questioned by
testers, although one suggested to provide some kind of feedback
(like including (...)) in the days that have some information
there.
Distinction
between Editor's Pick Events & Your Pick Events: still not clear
at the first instance. Once user clicked at the arrow, the idea
becomes more clear.
Feedback
and contextual help: no observation was made this time. The
site provided some explanations to help users better understand
the context.
Changes
Implemented for the Final Prototype: Don't be Afraid of Repeating
- MySFnight
button and View My List button have been redesigned to be
more like a cyber button.
- When
a calendar is minimized, three dots were added if there is
any event on a certain day, to provide a sense that there
is content there.
- We now
include the user's name at "My Picks": e.g. Monica's Picks.
Other subtle changes are made to create clearer distinction
of the two Calendars: My Picks will have a default size if
nothing is there. ·
- We made
use of the tool tips to help explain some of the button functions
when the user mouses over any button.
- We created
a new page for after Sign up, which also gives a overview
of MySFnight features. From this page there is a button to
go back home or go to the MySFnight.
We will
also study the idea of a monthly calendar view, which was contemplated
and then dropped during the previous study for not finding a
design solution that could be presented the amount of information
we had before for each event.
Low-fi,
HE, and usability tests: Which one is the most rewarding???
The low-fi
prototype helped the team better understand the interaction
process for the tasks of sending options to friends, signing
up for a newsletter, and signing up for an SFnight account.
It helped us realize that the MySFnight page was still not well
defined in our own minds. It was not clear how MySFnight page
adds value to the user's experience. The discussions with the
users at the end of the test session helped us better define
the MySFnight page.
The heuristic
evaluators did a wonderful job with our 2nd interactive prototype.
Unfortunately, we were already aware of many of the problems
that they have found. Due to time constraints we were not able
to make adequate design changes and implementation in time for
the evaluation. Their input did validate some of the concerns
we had. The evaluators also found many consistency problems
due to version control issues. Those problems were non-issues
in the actual design for prototypes that followed.
The usability
test conducted with the 3rd interactive prototype was the most
revealing and rewarding. Enough of our concepts were implemented
at that stage. Seeing how users interacted with a live system,
where they experienced problems, and how they used the system
in manners that we did not anticipate, gave us a much better
sense of where the system and designs are still problematic.
Post test discussions with the users again gave us a clearer
understanding of the shortcomings of the system and possible
solutions. Our formal usability test design was also a direct
result of discovery of users' different cognitive styles made
during the testing
|
