Specific replies by section:
Search / Create
- I've wondered if the "create box that looks like search" is a usability problem. Things we can do:
- add a search box above it
- change it to a dual-action form
- move the highlighting
One of the next things I want to look at for this assignment is the relationship between the primary (CITY, UNIVERSITY, RECENT, etc.) navigation and the secondary (Article, Discussion, Edit, etc.) navigation. In general, the primary navigation is browsing or reader oriented, and the secondary navigation presents all the wiki crap. That search box on the home page is interesting because it's the main call to action, where we are asking people to move from one kind of relationship w/ the wiki to another. watch this space :)
Brian, you mentioned in our last meeting that the "create/search" problem stuck out in the search analytics for the Welcome page. Can you put up some numbers for this?
- sure -- the analytics brain dump is part of what I'm working on now, but it'll probably go up after the xsgiving holiday --BrianKerr
I'm thinking of adding a section for miscellaneous design annoyances (I've accumulated a few). This could be a good way of doing "in-situ usability testing" - i.e., encourage casual users to submit a "bug" when they find it. Would this be more effective as a separate article? - Jake
- I'll begin a 'random navigation annoyances' section -- if nothing else, we can cherrypick from those annoyances when making specific recommendations. --BrianKerr
- Good plan to get credit for this sort of work...
- One darn thing that's hard about wikis is pagination. Hmph. -MH
- Any ideas for color?
re: 70% bounce, but 20% for "main nav" pages.
The obvious (not nec. correct) explanation would be that "recent changes" users are more often experienced wikiers using it to get to other pages, and "main page" users have followed a link from someplace and take a look around, while people who enter other pages, are more likely to be coming from google or the latest Livejournal, "Hey, where was that list of birthday specials again?" query? Looking at that page, as an example, there seems to me to be very little that tells the unfamiliar visitor what else is available on ArborWiki. "Hey, cool, a list of birthday deals." Maybe something like ArborWiki:About should be worked into the header - and made into less sad of a page. Or maybe (not considering browser width at all) a "Recent Changes" box could be shown on the right side of the header, showing the 3-4 most recently changed page titles in order to pique curiousity and give people something immediate to click on? Just throwing out some ideas to make the popular "reference" pages have some highly visible context, and not just look like lists.
Yeah, this is one of the trees I'm barking up for our recommendations. There are a few MediaWiki extensions which could be effectively used to surface some related pages (by popularity, categorization, etc.), but this -- along with the meta or about arborwiki stuff -- is also somewhat at odds with the spare, one/two column design for ArborWiki. Thanks! --BrianKerr
bk notes to self on 'Categories, browsing affordances' section
- bounce rates (analytics)
- navigation paths (analytics)
- global navigation
- Civic Wikis @ aboutus (competitive analysis (sorta))
Goal: make it tantalizing to click through to other wiki pages, encourage browsing behavior
Scan in or serialize thumbnails and sketches from 11/28.
- Improve global navigation
- including metacrap ("about" page)
- some take on local navigation
- Category browsing
- Category stemming
Have you taken any screenshots of AW recently? I'll probably start making large changes again during December, and that would take away a lot of the context from your analysis. -MattH 20:41, 3 December 2006 (GMT)
- And possible comps of your ideas? (this is pretty time-consuming) -MattH
- Yep, I'd grabbed screen shots of some of the basic parts of the interface ahead of the project. --BrianKerr
- Also, we met tonight, lots of ideas on paper, and need to get them into the wiki. We really want to have everything in the wiki page, so that may require some creativity in presentation, and/or scanned and uploaded doodles --BrianKerr
I like how SyrWiki presents the list of interesting pages:
Jake's notes to self on 'Categories, browsing affordances' section and search
Search Stuff: Various nitpicks (to be tied in to 3 main strategic goals):
1. "Go" vs "Search" - labels are indifferent, but which functionality to keep? (Probably Search) - Does automatically redirecting to the appropriate article / category page match users' expectations, and does it save time? Or does it prevent people from investigating other interesting pages that might crop up in the search results? We are trying to encourage browsing, so maybe an efficient search isn't necessarily a good thing.
2. Namespaces: they're obscure, they don't seem all that useful, and they look gross all bunched together down there at the bottom of the results page. If anyone's going to use them it will be "power users" (read: frequent contributors), so maybe they should be hidden from normal people.
3. Results page: the all-text theme is really pushing the limit here. I think this is one area where we might actually have to resort to wireframes / comps.
1. Map interface needs to be designed to accord with the rest of the wiki.
2. Enriching the connectedness of pages: one good idea I've gotten from WikiPhilly is the "what links here" feature. Might be an easy way to encourage browsing for pages with sparse out-links.
3. Consistent location of functionally similar navigation features. The lack of geometric elements in the design forces the user to rely on consistent location of text as an indicator of functionality, but locations are not always consistent. For example, for top-level headings the secondary nav consists mostly of wiki operations (Category|Discussion|Edit|History|Watch|Attach Map), but in the search results page the same location is taken up by Special|Attach Map. I would like to do an inventory of secondary nav links and separate them into functional categories that can be delimited by well-defined design elements.
4. "Any structure is better than none" - unlike most IA projects we don't have the luxury of specifying a rigid category structure, but we can devise a means of ensuring there is some path from A to B. This can tie in with the Dynamic Page Lists strategy: first identify the densely linked content areas, then provide a means of linking the more sparse areas into those hub categories. You know the small town phenomenon where you can't walk two blocks without running into someone you know? A civic wiki should have that same effect.
5. General guidelines for visual design: current design is very open / whitespacey / texty as compared to other MediaWiki sites. This looks nice but provides very few guidelines (in the literal sense) for navigating on the page. The search results page is I think especially egregious - I just see text, text, text. Maybe putting some navigation features in little boxes isn't such a bad idea.
6. Encourage basic cleanup of categories. Here's a great example: Politics > Human Companionship for Goldfish > Iggy Pop (!)
7. Semantically consistent labels. Is it "Discussion" or "Talk"?