CIS Ph.D. program

Met w/ the chair of the UH CIS Ph.D. program and it sounds promising.

---

There are 3 required courses that need to be passed with a B or better:

CIS 701: Communication/Information Theories of Society: A critical review of major theoretical and empirical traditions in communication and information sciences. Focus on European, American, Third World, and applied research.

CIS 702: Communication/Information Technologies: Technological concepts underlying data communications; information processing and computers; communication channels and networks, information storage and retrieval, and computer hardware and software.

CIS 703: Communication/Information Research Methods: Current research methodologies in decision sciences, computer science, library science, and communication. Emphasis on methodologies suitable for interdisciplinary analysis.

There is also a requirement to take CIS720, Interdisciplinary Seminar every semester while enrolled.

---

You are required to take 3 exams that you choose from a list of 7. 1 exam will be declared your "Primary" while the other 2 will be your "Secondary" exams. Each exam typically runs about 3 hours (6 for primary) and generally consists of a list of questions from which you choose three.

Exams I will likely take:

• Human Computer Interaction(discourse)At least two courses from:
  
  
  
  • ICS 464 Intro. to HCI Design: Application of concepts and methodologies of human factors, psychology and software engineering to address ergonomic, cognitive, and social factors in the design and evaluation of human-computer systems.
  
  
  • ICS 469 Intro. to Cognitive Science: Introduces basic concepts, central problems, and methods from cognitive science. Identifies contributions from disciplines such as cognitive psychology, linguistics, artificial intelligence, philosophy, and neuroscience.
  
  
  • ICS 664 Human Computer Interaction: Studies of human performance in designing and using information systems. Emphasizes concepts and methodologies from human factors, psychology, and software engineering relating to human performance
  
  
  • ICS 665 User Interfaces and Hypermedia: Advanced concepts in construction of interfaces between computers and their users. Hypermedia information structures, guidelines, problems, and tradeoffs. Discussion of selected readings, implementation of prototypes.
  
  
  • ICS 667 Advanced HCI Design Methods: Advanced analytical and empirical methods for the design and evaluation of usable, useful, and robust human-computer interfaces. Students will apply selected methodologies to a major system design project.
  
  
  • ICS 668 Social Informatics (also used for the Social Informatics area): An advanced introduction to the design of human-computer systems and other technological artifacts for supporting human collaboration in learning, work and social contexts, and to theoretical perspectives and empirical studies of collaboration that inform such design.
  
  
  • LIS 677 Human Dimension in Information Systems: Lecture/discussion on human element in information systems, including physical, cognitive and affective behavior in interaction with information systems. Information retrieval, human-computer interaction and cognitive science research, quantitative and qualitative research methods. Research component.
  
  
  • certain 491/691 courses, ask if they will count
  
  
  
  



• Communication and Information Theories
  Requirement: CIS 701
  Talk to the Chair of the exam committee to form a reading list.
  
  
• Social Informatics
  Taken as a secondary, this requires one of the following courses:
  
  
  
  • ICS 668: Social Informatics (one of the options for the HCI requirements)
  
  
  • ICS 691: Social Computing
  
  
  • COM 634: Social Media
  
  
  
  Talk to the Chair of the exam committee regarding a reading list, the site has nothing listed.
  

---

Deadlines:

• first year: you must attempt at least one area exam, take 720, take any courses required for the exams, and take whichever of 701, 702, or 703 that is offered


• second year: you must pass at least two area exams and submit a research paper for publication or review, take 720, take any courses required for the exams, and take whichever of 701, 702, or 703 that is offered


• third year: all area examination and research paper requirements should be completed, take 720, and take whichever of 701, 702, or 703 that is offered


• fourth year: you must have completed 701, 702, and 703, and complete the proposal defense


• seventh year: you must finish the dissertation

Plan of attack:

1. Sit in on any of the classes required for the exams whenever they are offered. Verify that sitting in will count and that I don't need to take it in an official capacity. Focus on getting the minimum set to take each targeted exam: 2 for HCI, 1 for SI (if I take ICS668 it covers both HCI and SI), CIT only requires 701 which is part of the CIS set of required courses. In theory, ICS 668 and one other will do the trick.


2. Talk to the exam Chairs to work out reading lists and set up a schedule to work through them.


3. Once the classes are completed and the reading list has been dented, officially apply for the program (target: Feb. 2013 enrollment deadline) and follow their timeline


4. Keep sitting in on courses relevant to interests.


5. Look for interesting papers at relevant conferences and start following the authors on twitter to get exposed to what the current topics of research are.

First attempt at a page redesign

Before:


The problem here is too much text! The eye doesn't know where to look. On this page, these are the primary actions the user would want to accomplish:
- log in
- view published results (does not require a log in)
- find out if they can use the system, and if so, how to get started
- get information regarding deadlines

The first two actions are small links with no real method of attracting the user's eye. They're lost in the sea of text. The third action is right at the top, but the header for it is not obvious and is easily missed to a roving eye. The last action is buried at the bottom of the page and easily missed by users with smaller screens.

After:


The first two actions are immediately obvious. These are the first places the eye goes. The third action could still use improvement. The "who can use it" part is presented right at the top, but it doesn't really attract the eye. A header is needed. Also, the part about getting started got moved to the bottom of the page where it might be missed by those with smaller screens. Still, it's clearly labeled and has much less text. The last action has been moved up to where it will appear on smaller screens and has explanations added to the different time-frames to help the user get a clearer idea of how the system works and what their responsibilities are.

I think there is still room for improvement, particularly with the third action, but it's much cleaner and hopefully answers all four issues better than before.

Wizards vs. Forms

From: http://www.uxmatters.com/mt/archives/2011/09/wizards-versus-forms.php

When to use a wizard:
- When actions need to happen in a specific order.
- When there are many tasks to be done and it would be less stressful to the user to break it up into manageable parts.
- When the actions performed differ depending on what data has already been given.

When to use a form:
- When the user should know all the data they need to provide to get a task done (like when you see a form, think it's simple enough to proceed, and then the next form asks for far more. If you knew that amount of time or data was going to be required, you never would have started at that point in time.)
- When you likely have "power users." If someone is going to be using your form repeatedly, it's better to allow them to tab through the form quickly than use a wizard and have to wait for each new step to load.
- When speed/performance is an issue. One form is one hit on the server while a wizard can be many hits and many times back and forth across the network. People with slow networks will appreciate the form over the wizard.

The general guideline (not a rigid rule): "novices and infrequent users like wizards, but frequent and power users prefer forms."

While wizards can be useful, don't forget to consider the option of allowing the user to select from multiple forms.

When deciding between forms and wizards for a user's experience, don't forget to consider coding difficulty, maintainability, and efficiency.

Paper: Visual Appeal vs. Usability: Which One Influences User Perceptions of a Website More?

Visual Appeal vs. Usability: Which One Influences User Perceptions of a Website More?
Christine Phillips and Barbara Chapparo
Usability News
Software Usability Research Laboratory (SURL) at Wichita State University
Vol. 11, Issue 2, October 2009

Paper: Aesthetics, Visual Appeal, Usability and User Satisfaction: What Do the User's Eyes Tell the User's Brain?

Aesthetics, Visual Appeal, Usability and User Satisfaction:
What Do the User’s Eyes Tell the User’s Brain?
Gitte Lindgaard
Australian Journal of Emerging Technologies and Society
Vol. 5, No. 1, 2007, pp: 1-14

Summary: looks are more important than usability, but why?

Exploring the reasons why "people may be more satisfied with a beautiful product that performs suboptimally than with a more usable by less appealing product."

This paper really is almost a literature review unto itself. Mostly a grouping together of different studies into a cohesive narrative. No actual new research is discussed in this paper.

Compares seeing a website for the first time to meeting a person for the first time. Right from the start you have an instinctual like or dislike that has nothing to do with reason.

"Exposure effect" People prefer things that they've seen before, even if they don't recall seeing them - illustrated by Zajonc (1980). In web terms could mean people like things that they already know and understand, standards.

"Confirmation bias" Once a person has made up their mind, they tend to search for things that confirm that bias while rejecting things that disprove it. (Mynatt, Doherty, & Tweeney, 1977)

Lindgaard, 1999 illustrated the importance of color in determining "visual appeal, perceived usability, and user satisfaction in web sites. Color was cited as the main reason for disliking a web site and content was the reason stated for favoring a web site." White and blue were the most favored while yellow and black were the least. Pastels were also deemed favorable while most dark shadings were least.

Reading time: 25 minutes

------

I re-read this post on 6/8/2012 and the part about the most favored/least favored colors really caught me.  Just this morning I had a choice of two gas stations.  Whenever they have the same price on gas, I always favor one over the other and I was pondering why.  At first I though "it looks friendlier" but that's very vague.  Going further I thought about the colors and the one I favored was blue and white while the other, which I had deemed "ugly", was yellow and black.  Just a surprise to see those exact colors listed in the exact favorable/unfavorable scenario in a totally different context.

Paper: Attention Web Designers: You have 50 milliseconds to make a good first impression!

Attention Web Designers: You have 50 milliseconds to make a good first impression!

Behaviour & Information Technology, Vol. 25, No. 2, March-April 2006, 115 – 126
GITTE LINDGAARD, GARY FERNANDES, CATHY DUDEK and J. BROWN
Human-Oriented Technology Lab, Carleton University, Ottawa, Canada

3 studies to determine how fast people form an opinion about web page visual appeal and the reliability of those judgments.

Study 1: Participants rated the visual appeal of web pages presented in two phases for 500ms each. Purpose: "to determine the reliability of visual appeal ratings and select a subset of the pages to use in the second study."

Study 2: Same as first, but added a 3rd phase where participants viewed each page for as long as they liked while rating each web page on 7 visual design dimensions (bolded items had high correlation to visual appeal: simple-complex, interesting-boring, clear-confusing, well designed-poorly designed,good use of color-bad use of color, good layout-bad layout, imaginative-unimaginative). Purpose: To determine the reliability of visual appeal ratings of the subset of pages and to begin to explore visual characteristics that may be related to visual appeal."

Study 3: Same as first, but some saw the pages for only 50ms while other saw them for 500ms. Purpose: determine whether the first impression may be formed in an even shorter amount of time than 500ms.

Visual appeal ratings were highly correlated from on phase to the next as were the correlations between the 50ms and 500ms conditions and the 7 factor ratings.

"Halo Effect" or "Confirmation Bias": When users ignore evidence contradictory to their initial impression and pay attention only to evidence that confirms the impression.

Visual appeal factors may be detected first and these could influence how users judge subsequent experience and enjoyment of the site. (Jennings 2000, Tractinsky et al. 2000) (Lindgaard and Dudek 2002).

Even if a website is highly usable and useful and presented logically, if the first impression is not a good one, the user may not be willing to see the site positively. Therefor, it's crucial to make the first impression a good one regardless of usability or content.

TODO: Test eCAFE to see if increasing our "visual appeal" has an effect on our completion rates. Could try a different design for each campus and compare against historical numbers.

1/20/11 (12 pgs, 70m = 5.8 mpp) minutes per page

Book: Rocket Surgery Made Easy, by Steve Krug

Krug, Steve. Rocket Surgery Made Easy. Berkeley, CA: New Riders Publishing, 2010. Print.

"Usability Testing:" Watching people try to use what you're creating/designing/building (or something you've already created/designed/built), with the intention of (a) making it easier for people to use or (b) proving that it is easy to use.

Quantitative test: Attempting to prove something through measurement.
Qualitative test: Attempting to gain insights to improve something.

These tests are of the qualitative kind.

I watched the demo he mentions in chapter 2: http://www.sensible.com/rocketsurgery/index.html
- Most tests last about an hour
- Have a simple site up like Google, something that won't distract the user while he introduces himself and explains the process.
- Use his script for the introduction.
- Bring up the site you want to test.
- Ask user to say what they're initial thoughts are, what the site is for, what it does, who it's for, what they would likely learn from the site. Don't click on anything.
- Ask user to do specific tasks. Read it aloud and give them a printed copy. Give them a scenario so they know "who they are supposed to be." Let them go through the process, clicking and all. Remind them to verbalize if needed.
- If they suggest a new feature, ask them how they would visual it working.
- Ask them to look around to see if there's anything else that might be relevant (if there is, and they missed it).

I noticed that while I watched the demo, and the woman was clearly going down the wrong path, I kept trying to tell her what to do in my head, even though I had nothing at stake. This could mean bad things for when I do a test for my own system. I'll have to watch that my frustration doesn't get displayed. It turned out her straying was useful in finding other issues. You have to let them reach their own conclusion, but if they get off topic, you can prompt them to revisit the issue once they reach the end of the thought process they were following.

Testing an existing site:
- Useful because you'll learn what you are currently doing wrong so you don't make the same mistakes as you redesign.

Testing other peoples sites (like other instructor evaluation sites):
- It's a free learning resource to see what works and what doesn't in the same genre.

Testing the sketch on a napkin:
- Hand someone, anyone the sketch and say "Can you tell me what to make of this? What do you think this is supposed to be?" Don't ask "Do you like this?" or "What do you think of this?" Ask them what they think it IS. Listen to what they say, and you can ask a few probing questions like "What do you think term 'x' means?"
- Lets you know if people "get it."

Testing wireframes:
- Wireframes are schematic diagrams of a page. Shows where different kinds of content will go, the relative prominence of things like headings, and the navigation devices like menus and search.
- Wireframes tests focus on interaction.
- Make up tasks, usually all related to navigation.
- Ask "How would you find..." or "What would you expect to see when you click on this link?"
- Tells if things are where people expect to find them, if the category names make sense, if the navigation is clear, etc.

Testing page design:
- Checks to see if the visual design has introduced any usability issues after we know the navigation, etc works via the wireframe tests.
- Start with home page, lead user through visual treatments of the pages and ask them to do a narrative of each one.

Testing working prototypes and beyond:


The People:
- It generally isn't important to test with people who are representative of your target audience. It's nice, but valuable data can be had from anyone.
- Three people per round is enough.
- He has a discussion on how to recruit users, screen them, & follow up.
- Tell users ahead of time what to expect, and schedule the time place. Send an email confirming the session along with reiterating the details and providing the non-disclosure agreement.
- After the meeting, send a thank you note.
- Have a backup "emergency" user in case one doesn't show.
- You cannot reuse the same people. One test per person unless it's a different application or site.

The Tasks:
- First, choose the tasks.
- The trick is making sure your list of important tasks are the things your users really want to do.
- Decide which ones to test in this month's round of testing.
- Typically a session lasts 50 minutes with 35 minutes of the participant actually doing tasks.
- There may be just one long task or as many as 10 small ones.
- If a given user is particularly fast, have "filler" tasks, like doing something on a competitor's site.
- To decide which tasks to try, ask yourself: What are your most critical tasks? What keeps you awake at night? What does you other user research suggest may not be easy to use?
- Second, expand the tasks into scenarios. Little stories that add context. It gives your user character, motivation, what they need to do, and a few details. "You are..." and "You need to..." and provides information they need to complete the task (like the username and password to the test account).
- Don't give any clues in the scenario. Avoid terms they will encounter on the site.
- You may want to place two restrictions: "Don't use search" and "Stay on this site"
- Pilot test the scenario to make sure they are clear, complete, and unambiguous. Use a co-worker, family, or friends. Anyone will do.
- Print out the scenarios in two formats: All on one page for yourself, and one per sheet for participants. Don't number the tasks.

Action:
- Use the checklists he provides so details don't get missed
- Facilitator: The person in the room with the participant. Part Tour Guide, part Therapist.
- Observer: Watch, learn, take notes. Write down the 3 most important usability problems they saw in that session. Suggest questions for the facilitator to ask the participant. Come to the debriefing session.
- The computer and screen recording software.
- A standard computer mouse, people shouldn't have to figure out how to move the pointer.
- Will likely need a microphone as the participant won't always face the computer.
- Follow his pre-test prep checklist (pg 68)
- Be aware of your biases and don't let them influence the participant in either direction.
- Participants should leave the room in no worse shape than when they entered.
- We may need to get permission from our Institutional Review Board to ensure we're meeting ethical standards.
- Make it a spectator sport. Seeing is believing. Watching as a group generate more ideas and discussion.
- Could use "Go To Meeting" for screensharing with observers.

The Debriefing:
- Prioritize the most important issues that can be fixed in the next month.
- Summarize the tests, issues, and decisions in a follow-up email.

Recommendations:
- KEEP IT SIMPLE!
- Do a round of testing one morning a month with three users. Debrief over lunch, spend the month fixing the issues, repeat next month.
- It needs to be a regularly scheduled thing or it won't happen.
- Tweak, don't redesign. Then verify.
- First impulse is to add something, consider taking something away.

Most common problems:
- Starting off on the wrong foot. The home page does a bad job of orienting the user.
- Failure to shout. People are moving too fast to notice subtle visual cues.

Summary:
- Keep it simple, this is quick and easy testing.

Remote Testing:
- Use screen sharing software and speakerphone for the participant (or VOIP)
- GoToMeeting is a good option for screen sharing.
- Could use "UserTesting.com" to test with just a user or two. Send them a task.


Maxims:
- A morning a month.
- Start earlier than you think makes sense.
- Recruit loosely and grade on a curve.
- Make it a spectator sport.
- Focus ruthlessly on a small number of the most important problems.
- When fixing problems, always do the least you can do.


TODO:
- Look into software that will record everything the user does on the site, like where they move their mouse and what they clicked on, etc. If it can record sound too, that'd be perfect. Don't need to record the actual user, so they don't need to worry about being identifiable.
- Set up a regularly scheduled test day once a month. Use co-workers, student help, and instructors, staff, or advisory board members who have volunteered. Take my laptop over to them with the test site up and recording software and just do the test. Do it on paper if needed and record with my iPhone.
- Look at and test other related sites that evaluation University instructors. Like RateMyProfessor. We can see what works and what doesn't. (follow process from chapters 5-9). Have each user do the same task on 2 to 3 different sites.
- Look into "remote testing" (chapter 14)

1/09/11 pg 1 - 13 didn't record time.
1/10/11 (10pgs, 13m = 1.3mpp) minutes per page
1/10/11 (11pgs, 15m = 1.4mpp)
1/11/11 (13pgs, 40m = 3.1mpp)
1/12/11 (26pgs, 16m = .6mpp)
1/13/11 (17pgs, 17m = 1mpp)
1/18/11 (45pgs, 36m = .8mpp)
Total: ~150m = 2h 30m