:::::::::::::::::::::::::::::::::::::::::::::::::::

A. PROTOTYPE

::::::::::::::::::::::::::::::::::::::::::::::::::

Rosa: Part A - prototype design

I think we all agree that at least we should come out of the first   meeting knowing what type of prototype we want to use. So if people have   ideas based on reading and have some kind of material  (Different color   post its, index cards, markers... HONG can you actually bring something?)  we can start playing to see what may work.   I have a bunch

 of sheet protectors, maybe I can get construction paper booklet with all   kinds of colors and of course glue.  Perhaps EVERYONE can bring ruler, whatever markers/crayons and scissors...

 

Monica: I already brought to SIMS: glue, scissors, some post its and paper. I will try to find other stuffs till Tuesday.

 

Rosa: The tasks we want the participants to test are fairly straight forward since we can just use the scenarios we created and focus on those tasks. If we need to prioritize the tasks to figure out which ones to do first, here's my priority list and why

1) registration, everyone who wants an account needs to do that

2) email friends a list of options,  most people would use that and may even register because of this feature

3) customize the favorites area   

4) write a review (If we need to cut something, I would say this one)

 

So when we are trying to figure out what prototype to use, we should have these tasks in mind and the process can even help us design/determine the procedure to use.

 

Monica: Yes, we need the tasks according to our scenarios and a script based on them. So continuing your thoughts, here are some scripts, prototype preparation list, and suggestions:

 

1. Registration, everyone who wants an account needs to do that

 

TASK 1: REGISTRATION TO SIGN UP A NEWSLETTER
(We need to give a reason for registration. Can be to create MySFnight or to have a Newsletter/both)
 

Specific recruiting tester requirement: none

 

Script for tester: You just heard from a friend that you could receive information about free nightlife events and promotions by e-mail. All you would need to do is to sign up for a newsletter at the SFnight website. You are in the homepage already.

 

Prototype preparation: Homepage, Registration page, Feedback, Pos-registration for the two options: the short cut  Newsletter and Customization/Newsletter

 

What to observe: if the user see the two kinds of newsletter/registration; how confusing this might be; and the process; if the user has doubts, feeling expressions [bored, smiling etc]

 

Measurement: time to perform the task; number of clicks in the wrong place.

 

2. Email friends a list of options,  most people would use that and may even register because of this feature

 

TASK 3: PLANNING AN EVENT [we need to create a context; I am proposing this be the third task]

 

Specific recruiting tester requirement: know their favorite kind of music, if they like dancing, if they have any favorite venue at SF.

 

Script for tester: You are already a member of SFnight. And you have at MySFnight, your personal page, some options of  your favorite kind of music  [the music the person said like most on the recruiting].  It is Thursday evening, and some friends ask you to find ….. options [should we specify how many, to be able to compare?] and send to them. They would like to have fun.

 

Prototype preparation: Homepage customized, two Bar Profiles, two Event Profiles, the Add to My List thing [whatever is the name], the List Result, the possible changes, the feedback

 

What to observe: If the user would use the personal area, or would tend to go to the other areas; how ease is to user to pick their choices, and send to friends; what other needs would come up when performing the option.

After finishing the task: Ask the user what he would like his friends to receive.

 

Measurement: Time to perform the task [but I have a doubt here: people may take time to make their choices independent of the system, so maybe we can have two separate measures: (a) for making the choices (b) after clicking the button to View the List until send it]; how many time they clicked at the wrong place.

 

 

 

 

 

 

 

 

3. Customize the favorites area [I would say this is very interesting, specially to play with all the options. In this case I would change the task position with Planning and Event]

 

TASK 2: CUSTOMIZING PERSONAL AREAS

 

Specific recruiting tester requirement: know their favorite kind of music, I they like dancing, if they have any favorite venue at SF to be able to make it more real.

 

Script for User: You are visiting SFnight home page, when you noticed that you can create your personal page.[This would happen if the user has chosen the short cut Newsletter; If the user has chosen the deep registration, then we would continuous from this point, a mean after having registred, and having some options already at MySFnight at a Glance.]

 

Prototype preparation: Homepage not customized, MySFnight at Glance customized, MySFnight homepage with the options of events

 

What to observe: If the user would use the personal area, or would tend to go to the other areas; how ease is to user to pick their choices, and send to friends; what other needs would come up when performing the option.

 

Measurement: How many time they clicked at the wrong place. I would not measure time here, since users might take their time to make decisions of music etc. The most important would be to measure the wrong clicks.

 

 

 

4. Write a review (If we need to cut something, I would say this one)

[I agree that it is going to be too much for the testers, and for ourselves, since the others have too many details to deal with. We would do only if we have time]

 

 

TASK 4: WRITING AN REVIEW

 

Specific recruiting tester requirement: none

 

Script for User: You just came back of a bad experience in a venue at SF. You were there with some friends from New York. You noticed two things: (a) first the venue was allowing people smoking in the common area; (b) then, the drinks looked like mixed with water (c) you complained, by the waiter didn’t care about. You decide to visit again my SFnight home page and express your dissatisfaction writing a Review, also you would like your friends to know about it.

 

Prototype preparation: Homepage customized, MySFnight at Glance customized, MySFnight homepage, a Venue profile with the Review section, the writing Review interface with the categories [as suggested by Hong], the View option, Send to a friend, My Review list at the personal page.

 

What to observe: If the user find easily the way to write a review. If gets bored/pleasure; points of doubts; identify other needs. Which options the user few like using.

 

Measurement: How many time they clicked at the wrong place.

 

 

:::::::::::::::::::::::::::::::::::::::::::::::::::

B. BUILDING AND REFINING THE PROTOTYPE

::::::::::::::::::::::::::::::::::::::::::::::::::

Rosa: Part B - building and refining our prototype and test procedures After the first meeting then we each should take a task and be responsible for the necessary items in the prototype, and do whatever corresponding writing/scripting...

 

I think since there are four of us, if we each get a participant that would be ideal.  The first participant will help us work out all the bugs in our "system" during our 2nd project meeting.  I don't know if this is possible, we would need to bribe someone hard :)  (If the   results are good, we should use it.)

 

 

Monica Now that I have a better comprehension of the process after reading some stuff, I would change the steps. I think we need FIRST to define the Task Scenarios for the Testers [and on my opinion, we can advance this item by exchanging e-mail], and see what prototype interfaces we need to create.

 

Recruiting Tester Requirements: Here are my suggestions:

 

1.      Has to be a Internet user. Our audience has a good use of Internet. But not necessarily a “information expect”. We want to know a simple user how difficult the system seem to the person.

2.      Has to like to go to bars / clubs, otherwise affects the test results (bias). People who does not go usually, feel testing the system something boring.

3.      Don’t need to be a SF experience, necessarily. We are testing the features of the system and not the content itself.

4.      Has to be older than 18 years. Can be a student.

5.      Try to have both sex. But it is not so necessary.

 

1 and 2 are very important.

 

 

Regarding the writing is quite more easy this time. She specified:

 

 

MARTI’S REQUIREMENTS

……………………………….

1.Introduction

Introduce the system being evaluated (1 paragraph)

State the purpose and rationale of the experiment (1 paragraph)

            

2.Prototype

Describe your prototype (1 page plus sketches & A photo of the test "computer" is recommended – you can borrow the digital camera from the computer lab)

            

3.Method Participants (who -- demographics -- and how were they selected) (1 paragraph)

 

Task Scenarios (1/2 page) escribe each task and what you looked for when those tasks were performed

Procedure (1/2 page)  describe what you did and how

           

4.Test Measures (1 paragraph) describe what you measured or looked for and why (bulleted)

            

5.Results (1 page) Results of the tests (summary of what you saw)

           

6.Discussion (1 page) what you learned from the low-fi evaluation; what you will change in your interface from these results; what the evaluation could not tell you

            

 

7.Appendices (as many pages as necessary - link from text into the appendices)                     Materials (all things you read --- demo script, instructions read -- or handed to the participant – task instructions)

                   

 

Raw data (i.e., entire merged critical incident logs - typed up!)

 8.Assessment of who did what work.

 

 

 

:::::::::::::::::::::::::::::::::::::::::::::::::::

C. TESTING AND WRITE UP

::::::::::::::::::::::::::::::::::::::::::::::::::

Rosa:  Part C - testing and write up   Then the rest of the testing (by nature of the testing we will all be together and can meet) should happen right after midterm, like Monica had suggested after class.  During those testing/meeting I think it should become clear what else still needs to be written.  It would be fair to say that we write about the task that we choose to be responsible for during Tuesday's meeting.  If we should decide to cut out a task or two, then the people would be responsible for putting things up on the web, doing what ever extra writing and proofreading, editing.... If we don't cut out a task or two for testing purposes then I'm sure we can still split up things so everyone helps somehow to get everything in on time.  It seems like we will be putting Bin's digital camera to good use for this one :)

 

  So remember to read, bring some "toys" for Tuesday, and Have a good

  weekend!   (or get lots of other work done, uggg.)