• 1. Don't close "Live" tickets -- put them in "testing". Those should always go through QA.
• 2. For other tickets (requirements and development entered tickets) should be closed, unless developers need them for their development process.
• 3. When a milestone goes into QA testing, a notice will be sent out to developers. If developers have put any tickets in to testing, they should close them at this time, unless they are specifically requesting that they be QA tested.
• 4. Developers should not close tickets that were opened (or reopened) by the testing team. Put them in testing instead.

Jared Spool's article, http://www.uie.com/articles/search_results_part2/, has some interesting results from researching various companies' search results pages.

1. Provide a lot of info in the results to support user tasks. He gives the example of price, distance, and room amenities for hotel searches, to support various types of customers. For us, I think that means providing axes of information about the content in the initial results page, which we do fairly well. At some point, including lens information, ratings and reviews will probably be important.
2. No one ever complains that the page has too many results -- 10 per page can be limiting, but I think right now performance issues force us to limit the UI.
3. Most relevant results should be first. Well that is obvious. But the interesting result is that people stop searching down if irrelevant results appear (relevancy threshhold). As we get textbook searchers, we really need to reconsider how often modules are obscuring collection results that may be more relevant to the searcher.
4. Eliminate wacko results. Just thought the psychology here was interesting. Programmers see wacko results as a weird corner case of an algorithm, but searchers see them like Tourette's syndrom (Spool's term) -- random results inserted into an otherwise sane response -- and it makes them not trust the other results.
5. Prevent pogosticking -- The more times someone goes to look at content and comes back to the search results (which Spool calls pogosticking), the less likely they are to ultimately find what they want. (I think that this would be a good stats problem for our new book -- probability of success given Y pogos) Preventing this is related to the "Provide a good scent in the initial display).

Rob Rhyne (UPA-DC 2007)

Rhyne’s talk was about using common design patterns and everyday metaphors to achieve consistent and usable interfaces without demanding strict uniformity. He says uniformity is problematic if it is being invoked to justify a design that is one of the following:

• easier to build but is actually less useful,
• a substitute for a more useful creative solution, or
• when it simply results in something that is boring and undistinguished.

He showed Google search results, Yahoo search results, and Microsoft Live search results and without the header these look nearly identical, but the two catch up searches really need  to distinguish themselves visually without breaking the understandability. Conventions can be broken when they are immediately obvious. He cited successful examples that broke away from conventions: the iPhone interface and a CD burner called disco that uses drifting smoke on the desktop to indicate that it is still working while allowing the user to do other stuff.

An audience member working for a medical site told a story about trying to develop websites of information for diabetics and for breast cancer survivors. The pointy haired bosses (ooh that’s me) wanted uniformity, but these two communities are actually very different in how they approach finding information (no details given unfortunately). I retell that story, because I think it has some parallels with our communities of authors and readers. The Connexions stylesheets were the first design for allowing communities to relate to content as communities. The stylesheets controlled the entire look and feel of the navigation, content, CNX and branding which turned out to be very hard to understand for readers, and difficult to maintain for development. We are now moving toward supporting styling in the content area, but preserving CNX navigation. We plan to provide style parameters that can be applied by module authors, collection authors, lens makers, and readers (in that order). Will that be enough? And will it really be easier to maintain?

• Yahoo! Pattern Library
  http://developer.yahoo.com/ypatterns
• “Web Patterns”, John Allsopp
  http://westciv.typepad.com/dog_or_higher/2005/11/webpattenrs_and.html
• Flickr Design Pattern Photo pool

I heard a brief talk by Angela Colter (UPA-DC 2007) on a study of breadcrumb usage. The researchers wanted to know how people think of them, and how they use them.

Three types of breadcrumbs:

1. Location model – single breadcrumb path to any resource
2. Path model – shows exactly how this user got to the page
3. Attribute model --  gives metadata information (categories, subcategories) – this model is used by Amazon and results in multiple breadcrumbs paths showing on a single page.

Results:

• Users describe breadcrumbs as paths, but think of them as locations.
• Novice users are very likely to use them, and understand they are links.
• Most commonly used to find something related. While heading back to the search box the user trips over the breadcrumbs and see that something in the breadcrumb trail might be useful.

Breadcrumb problems:

• If the breadcrumb link label is named something different than the page you get to that is a problem and users never use the crumbs again if that happens to them. (In this study)

From Jared Spool at UPA-DC-2007 again: These are the things that his company is actively researching – the unsolved problems of Web 2.0 usability.

• What does it mean to produce a usable API?
• RSS – When chronologically isn’t the right organization, what then?
• Tagging – How do you unify things that are intended to be the same, but aren’t such as misspellings and alternates (NY, NYC, New York etc.)?  The big search engines have made headway in this area somewhat.
• Quality: What is the role for the editorial with regard to user-generated content and how to support that role?
  
  This quality question is exactly the same question that Connexions is asking and trying to answer with lenses. The corresponding business question is how do we support an economy of editors while preserving open content? Related to the quality of content is the quality of tagging. Audience members brought up the need for expert generated ontologies and subject vocabularies in addition to completely user generated tags.
• Social networking -- How to avoid mobs?