2. Overview Problem: SJSU Library lacks a mobile version Disabling CSS creates a functional workaround Many ways to create a mobile website; which is best? Solution: Pattern 15 (One-Window Drilldown) Separate each original webpage into small chunks Organize chunks into PDA-sized webpages Show each new webpage in a single window Keep header for recognition value
3. Recruitment Two User Ideals: SJSU library students Everyone else Two Recruitment Methods: E-mail Attached .ppt file of prototype in inquiry Low rate of success: 2 recruits Go ask in person High rate of success: 6 recruits People less likely to refuse if asked in person
4. Users User #1 SJSU Library Student Web savvy, familiar with SJSU Library website Familiar with library concepts such as reference questions User #2 Librarian at South El Monte Public Library Little familiarity with websites Familiar with library concepts such as reference questions User #3 College undergraduate Web savvy in general, but not with SJSU Library website Unfamiliar (but curious) about library concepts
5. Testing Methods Via E-mail As stated earlier, inquiry contained PowerPoint version of prototype Users to work through prototype on own Users to answer post-session questionnaire on own In-Person Approached user with paper printouts of prototype Walked user through the tasks Wrote down paths, jotted down replies Noted body language Interviewed and thanked user afterwards
6. Tasks You’re exploring this website for the first time. Where do you go first? What is your rationale? You need to find an article on a certain topic for school, and fast. What do you do? You wonder if the library is open on Sunday night. How do you find out? You have a reference question. Where do you go? You want to see if the library has a copy of a book in which you are interested. How do you find out? You want to know if the library subscribes to a certain journal. How do you go about this? You wonder, are there any upcoming library exhibits? You want to contact the library by e-mail. Is this possible?
7. Interviewing Users How does the prototype compare with the normal website? Are you familiar with mobile websites? How does the prototype stack up to them? / Are you familiar with mobile websites? How does the prototype stack up to them? When navigating the prototype, did you encounter any mental hesitations? If so, where? Any other problems? Thoughts: Did not plan interview thoroughly enough Not enough questions Questions that exist are too vague
8. Feedback User responses: User #1: No problems whatsoever Agreed prototype is better than original website Users #2 & #3: Some navigation problems Suggested following changes Put Quick Search on top, followed by Library Hours Rewrote Contact page Added more pages Revised some testing and post-interview questions
13. Lessons Learned Double-check due date! I misread it for the 29th, not the18th. I had to complete this assignment in a week! Follow-up on e-mail inquiries! Don’t be hesitant! Most people are happy to help Also, make sure you actually sent the e-mail Don’t be too polished! Remember Moggridge: bare-bones prototypes invite more honest remarks.
Hi, welcome to my presentation. Let’s get started, shall we?
The website lacks a mobile version. Users can view the website just fine on a standard browser, but what if they need to access it from a PDA? This lack of web usability is easily amendable – simply create a new CSS style sheet for mobiles.Pattern 15 (one-window drilldown): “Show each application page in a single window. As a user drills down through a menu of options, or into an object’s details, replace the window contents completely with the new page” (Tidwell, 2006, p. 36).Line elements into a listSeparate lists into window-sized chunks.Unknown to me, website has already partially solved mobile problem: no CSSCSS-free version of main page easily navigated, but requires scrollingUse CSS to jazz up each boxed section (Quick Links, Spotlight) and put them into separate pages
I had two ideas types of testers in mind. The first is the SJSU library student, for whom the final product would be intended. The second is everyone else, representing the outside user who stumbles upon the website. Perhaps they can pick out flaws librarians automatically bypass due to their training. Out of all my classmates whom I asked, one responded, because I used e-mail. Asking in person is a whole different story; everyone I asked agreed. Lesson learned here, people are less likely to refuse if asked in person.
Though I ended up with 8 users, I picked 3 for my report: a SJSU library student, an older librarian, and a college undergraduate.User #5 is a SJSU Library student. She has ample experience with the SJSU Library website, and is familiar with concepts such as reference questions.User #4 is a librarian who works at a mid-sized public library. She has little experience with mobile phones or Web 2.0.User #6 is currently an undergraduate who is interested in library science. As such, she has slightly more knowledge of libraries than users #1 and #2.
Here I go into more detail on how I recruited users. To recruit SJSU library students, I e-mailed my classmates in other courses, asking if they wish to participate. To those who answered yes, I e-mailed them a copy of the PowerPoint file for them to work through.In retrospect, I should have followed up on the other inquiries. To recruit everyone else, I simply approached and asked – at the library where I volunteered, then at a family dinner. Of course, I tested the user using printouts of the PowerPoint slides I created. I wrote down paths, jotted down replies, noted body language, and thanked the users afterwards.
Here is the list of tasks I had users do. They are all tasks commonly undertaken by visitors to the SJSU library website – help for reference questions, accessing databases, and more. This task put more stress on breath than depth, I admit. Note that all the tasks are short, needing only a few clicks from the main page to their intended destination – unless the user was unusually hesitant or off the rails. But given that the purpose of my prototype was to test basic navigation and appearance, a series of short, simple tasks is fine
I admit, I didn’t think my post-session interviews thoroughly, so I had only 4 questions. Also, I think my prototype was too polished. The users were hesitant to point out flaws. Maybe my prototype was perfect the first time. More likely not: Moggridge states a polished appearance impedes negative criticism. I think he was right.
User #1 is familiar with the SJSU Library website, and thus has no problems with the prototype. To her, the prototype is ideal; it has relevant information, little crowding, and better organization than the CSS-free version of the normal website. User #2 has little experience with mobile websites. Nonetheless, she finds most tasks executable – except one, where she fails to note the bottom toolbar and contact the library. She also has problems with reference questions and where to seek help for them. Size and graphics aside, she concludes that prototype is pretty good for a mobile website. User #3 has experience with mobile websites. She too has problems with finding the Contact link on the bottom toolbar, as with where to go for reference questions; she also uses Quick Search a lot. Ultimately, she finds the prototype pretty straightforward.