Hi Rosa, Hong and Bin

I review from yesterday. I would say that the results were great, and

that we would not make it without the active participation of every one,

and without the great Chinese homemade food brought by Rosa and

Hong, and the availability of everyone to work so hard until late. I

think we learned a lot.

1. Rosa made a list of the things we need to do in the project site, and

for this assignment, as well as a usability testing, and purpose some

changes that we are going to implement for this assignment; she also

organized the folders for the files. All those things will help us to

achieve more productivity. Her notes are available at Administering (or

something like that) folder at P4.

2. Rosa, Hong and Monica reviewed all the scenarios that we created last

meeting. We read again Bin' three scenarios, since I, myself, couldn't

hear well last time. We changed all the Persona's scenarios, and we

realized that although Bin's second scenarios was very good for the

persona, we would need some persona to perform the registration process,

and Chris would be the better one.

a. We decided not to have : "Search like Favorite" (the concept still

confused); "Visit Next" (it would be incorporate in Favorite Venues);

"Avoid list" (it make more sense Send the Review to friends than to make

an not interactive Avoid list. People also tends to not forget bad

experiences, but they like to spread the bad experiences around. And

when Rich was telling what he would do after having a bad experience in

a venue, the first thing that came to his mind was to write a review and

send to his friends. He forgot about putting this bar in a Avoid list.

Maybe because it would not add much value to his experience. He never

wrote in his agenda anything such that.

b. Other things like invitation, although will exist in the site, we

would not focus. There are already many features to take care.

c. The Add to My List feature is not clear for users regarding the name

and what they going to achieve with. So we would like to review later

the name. The idea is to translate the concept of "sending some thing to

someone" to the name. It was suggested "planning", but it has a static

view. Leonardo per example would like to create a list of the bars that

he should try next, so do Rich, and they might use this feature if it

has another more clear name. Stefan already use this feature. He

included there his Favorite venues. He is not an explorer.

d. Review. Rich for example should be able to write, read, send, and

have a quick access to his review

3. By doing this, we checked at the table of features the ones that one

be performed by the personas.

4. Initial design: some of us brought some initial drafts, but "First

things firsts", so we started to review the registration process, and

each one did his concepts. Some of us went back to the computer to check

other sites practices. Those elements were important in our decision:

a. Preserve anonymity: We would not require address, real name, but

e-mail was necessary to give the Rick or Stefan a unique identity. Also

e-mail would be a way to provide the user his password in case in forget

it.

b. Password: we tried not to use this word, since people like Chris

would be confused with their private e-mail password. A way to solve

this was to say something like "Create a mySFnight password" or "Create

a mySFnight code"

c. Newsletter: it became an option, instead of mandatory thing. Stefan

don't want to receive. He prefers to check the site, or receive by

mobile.

d. Things that were Optional, should be transparent to the user, special

to our Stefan and Rick that does not like to give much information.

e. For business strategy and for better meet its user needs, SFnight

needs to know "gender, age". But those are optional. If, per example,

SFnight is focused in people of 27-35 years old, and its users are more

likely 18-23, the SFnight strategy might be change to achieve its goal, or

be redesigned to meet its current users. How to understand if they are

more like Chris or more Stefan?

f. Newsletter [shot cut]. We created an easy way to register for

newsletter, for those users who does not want any personalization at all.

We discussed a lot how this could be simple, and what kind of feedback

it would be need, besides the next steps if users change their minds.

Specially the feedback pos-signup, and the e-mail confirmation,

g. Register No! Hong brought his experiences about this word, that does

not sound so friendly. We decided not use it, and we are preferring the

word "Sign up" or "Create". And also this remind us that Stefan hate

this word. He feels like been in a cashier, and he wants to have

entertainment when he comes to SFnight!

h. We also decided that if some one would buy a ticket, would have a

complementary form for the user first buy/or promotion. But these

information would not be part of registration process. Stefan and Rich

would not sign up if have to ask personal information. Chris for been

inexperience would easily put her info, but we would like to protect

our users, and provide them anonymity.

i. We discussed issues related with ways of recognizing the user, how

the backend would treat this: if the Stefan has to sign up in two

computers, if the computer does not allow user to create a cookie. We

decided to follow the standard practices. For Leonardo this would not be

a problem since he carries his laptop everywhere, but for the Stefan

and Rick having to sign up every time would be a pain.

k.. We concluded that the Registration Process is not a simple design:

there is business, privacy, technology issues that should be taken into

account.

l. Another last thing: we decided that it would be better drive the

players to the network, and let the consumers have a separate process.

It would be annoying for consumers have to choose if they are "normal

people" or "promoters" etc.

5. SFnight Personal are: "MySFnight at a Glance" and MySFnight

a. We maintained the Amazon model. And we decide that an user would need

to know what is going to find after customize its area. We discussed two

solutions for that: (1) give a page preview to users, showing

graphically what would happen; and (2) incorporate the elements (such

does Amazon) that the user will find at MySFnight at Glance, already in

the non-personalized area. The main difference would be that without

sign up, the user would top recommendations for any event type, for

example.

b. The differentiation between MySFnight for consumers and Network for

Players should be clear. Although the final project people should check

how they could provide MySFnight to players also, at the same time of

Network.

c. If we disappear the Network button for consumer, once they are

registered, the final project should think about this: in case a

consumer become later a player how this would work?

d. "Sign up", should be achieved by several points in the site, not only

by a button.

e. We decided to maintain the "Favorites Venues and Events" at the

MySFnight at a Glance, and let more detail to the internal page.

f. For business reasons, and also analysis of the different goals to be

achieved by My..., we decide not allow users to go to a

www.mysfnight.com page without been in the homepage. We are following in

this case the News/Amazon approach. They are relevant search functions

at the main page that we would not like to repeat in the mySFnight page.

g. Terminology. We were tired enough to not come up with new terms, but

alert enough to recognize that (a) "Favorite Venue", might be used in

different ways (for put my favorites or for creating a list to Visit

Next); in this case we decided not to create a new feature, but to see

if we can find a better name that could incorporate those two different

ways of using.

h. At the main mySFnight, we would have the other features (My review

list, Favorite DJ (but would not be part of our project) .

i. We also evolved to a simple calendar: we mixed the Favorite Events

type with a way of presenting in a week layout. This would be great for

the users if implemented, and would solve the need of calendar feature,

since some people might have different calendars and do not have other

ones. It would be more one thing you start with and then you give up

soon. At this new formulation of "Favorite Events", Rick, Stefan and

Leonardo, as well as Chris, would need to be able to pick some of them

and send to friends what ever.

If I forgot something, please let me know, since when posting the

designs we will include also our design process and thoughts.

Again, I think that we did a great work!

cheers!

monica