The entire text of the report is here. Please use this space to comment on it. You can add specific requested changes to The To Do List and see what has happened on Meta Recent Changes. Discussion of the draft has been incorporated in this page and the full text archived at
Talk:Information Architecture Analysis/Draft Discussion.

Introduction

Our analysis takes the form of three core strategies for the wiki. Each strategy is addressed in turn, with specific recommendations following a general statement of the strategy, and a description of the research and resources that led us to it. At the end of this document, we suggest how to get recommendations out of this project and onto the ArborWiki To Do List.

Overall, we are very impressed with the quality of ArborWiki, and the attributes of its information architecture -- categorization, navigation schemes, etc. -- which have developed organically over its existence. We hope that this analysis provides a helpful combination of higher-level strategic thinking and more ready-to-hand recommendations for improving the wiki.

  • DK COMMENT: I think the structuring principle you developed for your assignment serves your content super super well. The three core strategies approach is all the more apt when you throw in the dogfooding aspect of how you created this deliverable. I'm experiencing the situation you articulate these improvements for as I ingest your report :)

Connective tissue

Promote longer visiting sessions by exposing related pages where possible. Separate pages for navigation are important, but clearly labeled and enticing inline navigation is the connective tissue that encourages serendipitous browsing and advertises the breadth of the wiki's contents.

Broadly speaking, ArborWiki pages come in two flavors: navigation and content. Navigation pages include the Main Page, category indexes, search result pages. Content pages are the individual wiki pages that comprise the bulk of the wiki. The spartan, single-column layouts used throughout most of the wiki have six links and a search bar across the top. Four of those six links comprise global navigation (Arbor Wiki, CITY, UNIVERSITY, and RECENT) with the two remaining being links to ArborWiki's 'sister sites' (The Communicator and ArborSpeech). This global navigation is the only prominent, persistent connection back to the rest of the wiki that most content pages have. Navigation pages, on the other hand, provide a rich set of links to appropriate navigation and content pages. Take the Category:Restaurants page as an example -- while it might be easy to locate a genre of food or a specific restaurant in the listing and click through to that page, it's not so easy to browse back to Category:Restaurants, or other pages in the same category. It's far too easy to land on an interesting page at Arborwiki (via a search or direct referral) and not have any clear, enticing navigation links to click on next.

  • DK COMMENT: It's a fun problem you identify: interestingness versus aboutness...
  • COMMENT: I like how SyrWiki presents the list of interesting pages:

The wiki's web analytics (Google Analytics) describe a stark contrast between bounce rates for navigation pages (around 20%) versus content pages (around 70%). Regardless of other factors at play, the majority of visitors arriving at a content page do not click through to other wiki pages, following -- if anything -- a link offsite. Manually or automatically surfacing interesting, relevant links to other parts of ArborWiki represents a major opportunity for increasing the engagement and participation of visitors.

  • DK Comment: the auto-surfacing of related stuff is a great idea. I'm curious why you didn't include it in your recommendations below. Probably because realistically... the engine to create this auto-aboutness feature is not within easy reach of the client?

In a competitive analysis of ten other civic wikis, we noted that the Category:Streets_of_Ann_Arbor project at ArborWiki is unique in both its scope and its level of detail. Several recommendations suggest methods for building on this project to facilitate browsing through wiki pages.

Recommendations

Global navigation

An example of a help box from PhiliWiki

Add prominent links to:

  • an About page
  • a page introducing wiki editing (WikiPhilly has a good model on its home page)

Clean up terminology used in navigation. "CITY" and "ArborWiki" both go to the home page. Only the second link title is clear, relabel "CITY" to "Home" or "Welcome to ArborWiki." "UNIVERSITY" is problematic for reasons related to the third core strategy -- there are multiple colleges and universities within the ambit of ArborWiki. Additionally, "Discussion" and "Talk" are used interchangeably.

  • DK Comment: I think this would be a big improvement, this subtle cleanup of terminology. Is this what we might call a 'textbook IA' sort of enhancement to the wiki? Changing the language to better support the strategy... Very polarbear

Navigation pages

Interesting pages on SyrWiki.

Devote space on the home page for promoting content outside of the directory-style topical navigation. One model is SyrWiki's Interesting Pages, which is a rolling list of unrelated, interesting pages that are surfaced right to the home page. Other approaches include listing a handful of recently-changed pages, or featuring pages that relate to the news of the day, potentially in partnership with Arbor Update.

  • COMMENT: 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
  • DK Comment: perhaps i'm reading this wrong, but it's odd that the content pages are the bouncey ones that seem to cry out for relatedness or in-site links to keep incoming traffic on the site... yet the auto-surfacing feature is pinned to the navigation pages. I like the serendipity factor of rolling list of unrelated pages in lieu of a smart system to understand a page's context and intelligently place links there.

Show a hierarchy of categories and subcategories, rather than flattened lists. Category:Stores is a good example. Only 12 content pages are listed in the 'Stores' category, but drilling down into subcategories Category:Bookstores, Category:Groceries and Category:Hardware yield 11, 26, and 4 content pages. Showing a hierarchical listing of categories, subcategories, and the content pages they include would make it easier to scan the whole set of pages, as well as making it more visually obvious when a content page is miscategorized.

The pink shaded area is beneath the fold at a 1024x768 screen resolution.

One challenge with adding to the Main Page is that fully half of the ArborWiki readership is at fairly low screen resolutions (1024x768) -- meaning that many of the topical indexes are beneath the fold. Ruthlessly elevate the most important elements on the Main Page to the top, whether that involves rearranging elements that already exist, or integrating new elements from the previous recommendation.

  • DK Comment: I'm going to be stealing this turn of phrase you use here... "ruthlessly"... Sometimes IA is a brass knuckles business

Content pages

Where possible, use the Streets of Ann Arbor project to show adjacency. Many pages in ArborWiki represent one or more physical locations; if these pages are linked into the Category:Streets of Ann Arbor, it would be possible to generate a Dynamic Page List of other wiki pages representing locations along the same street. A less granular grouping could be accomplished by sorting pages into Category:Neighborhoods. Although integrating these forms of spatial navigation could be tricky, we feel that they could enable a powerful, intuitive form of browsing through the wiki.

  • Comment from Jake: 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.
  • DK Comment: a related feature that might bolster this excellent idea about showing adjacency might be to make geotagging of new and existing nodes something that's fun and easy to do. The more geotagging there is, the more awesome this feature you've suggested becomes
Wireframe of a standardized sidebar

Develop a standardized sidebar for navigation links. This is an area used on some pages for Google Maps or tables of contents. There are several opportunities for promoting organic browsing through the wiki by pulling some links into this space. Using a MediaWiki extension such as DynamicPageList2 in concert with MediaWiki templating, it is possible to surface lists of several kinds of links in a sidebar:

  • Links to pages that link to the currently-displayed page (backlinks)
  • Links to other pages in the same category
  • Links to related categories or subcategories -- as an example, a page for a Korean restaurant could list other Korean restaurants, or other restaurants in the same price range.
    • Comment from Jake: 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.
    • DK Comment: Aahh. Here's the content page enhancement I was wondering about earlier in your discussion. Rockin.
A very good discussion page

I'd like to see better discussion pages -- ones that include the original text and relate it to the commentary.

An inviting space

Use content, copy, and layout to create an inviting space which helps visitors feel at home. Explicitly and warmly encourage visitors to browse and read the wiki, and invite visitors to suggest and make improvements wherever they see fit.

Nearly all of the civic wikis we examined in our competitive analysis devoted significant space on their home pages to overview or introductory pages. These pages, with labels like "Help," "Overview," or "Don't know how to wiki? Learn here," directly serve the goal of creating an open, inviting space.

  • DK Comment: does the fact that the kinds of people who're inclined to edit this wiki haven't created this invitingspace-ness already mean that making these sorts of changes might not be cool with the core users?

An important dimension in which ArborWiki can be an inviting space is the work of setting expectations and conveying an appropriate level of credibility through visual and structural design. Within the framework fo the SI course, we adopted material from BJ Fogg to emphasize the concept of appropriate -- and variable -- levels of credibility. The material on the wiki is not authoritative. It respects, and demands, a human voice. After all, one important goal of a civic wiki is to convince visitors that it is OK to write what they know about the place they live. This is a gambit which works well for a civic wiki, where the stakes are low: the ideal material for a civic wiki is information or opinion which is interesting enough to capture, but not so critical that a reader feels it's risky to trust in or act on the material. At the same time it is important that visitors be able to distinguish between reliable factual information and "unreliable" or opinionated content. Achieving a balance between these goals is difficult, and Matt and other contributors to ArborWiki should be commended for the care with which they have refereed actions or projects in the wiki that have pushed pages too far to one extreme or another.

  • DK Comment: extending this riff on credibility and why it matters here ... part of the "about us" stuff you'd enhance the site with to help create this invitingness can end up furthering the credibility effort if you make it easy for newbies to see and understand the quality control that people like Matt are providing in the wiki

Another dimension in which ArborWiki can act as an inviting space is in its invitations to readers, and invitations to authors, who are often the same people. These roles, overlapping yet distinct, must receive different forms of support from the ArborWiki interface and layout. Navigation throughout ArborWiki is targeted at one or both of these roles: the global navigation discussed in the first core strategy is used by everybody, but there is an additional layer of contextual navigation that comprises the wiki tools primarily useful for authors (the "Article," "Discussion," "Edit", etc. thru "Attach Map" bar near page titles). ArborWiki already achieves a degree of functional separation by using global navigation for browsing-oriented functions and secondary navigation for contribution-oriented wiki tools. The intended effect is to hide and streamline as much of the wiki interface as possible, so that somebody landing on an ArborWiki page can read it without necessarily knowing or caring that it's a wiki.

  • DK Comment: heh.. with the name ArborWiki.. that careful hiding of complexity in the UI is kindof undermined IMO. You could extend this discussion into an argument for chaning the name of this site to not include the dubya word.

A potential downside of this approach is that hiding the "contribution layer" may discourage visitors from contributing to the wiki; hence the goal is to make the two layers distinct but equal. Many of our recommendations here are intended to maintain and reinforce this functional separation. For example, the ArborWiki search engine is clearly biased towards wiki markup and wiki authorship, whereas, as part of the global navigation, it should be a tool helpful to all wiki visitors.

  • DK Comment: realistically.. one side is gonna win,right? Which isnt to say that you can't steer your work in ways that supports separate-but-equalness for the contribution layer and the browse layer. You do this now. Very effectively. But tactically, it might be a stronger or more interesting position to say that one layer is actually slightly more important and therefore deserving of additional focus and features

Recommendations

Overview or introductory content

The Help:Editing page is empty. This page is linked with the label "Editing help" on wiki edit pages. Either remove the link or generate some editing help for that page. (We believe that the MediaWiki foundation has generic help pages in the 'Help' namespace that could be imported in, although something specifically tailored to ArborWiki would be more appropriate.)

Navigation pages

The yellow "Type a title to add a page:" box on the Main Page is too prominent. We observed visitors gunning for the yellow box, instead of the search box, for searches from the home page. This error is compounded by the poor behavior of the 'Create page' feature when the page entered already exists. (Try submitting the name of an existing page: it will open that page in edit view -- not an encouraging sight for the first-time, casual visitor.)

  • COMMENT: 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
    •  ?
  • COMMENT: "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.

Categories that contain content pages (but are themselves empty) yield an edit page when clicked on. For an example, go to the Special:Categories page and click on any category with a red link-hover background. This behavior implies that there are no content pages in that category, even though there are (and they are visible beneath the editing box and toolbars). This is a problem without easy solutions. Suggestions include stemming or eliminating superfluous categories, and/or developing a category stub template to be entered into category pages without actual copy or content.

  • DK Comment: this is indeed a sticky problem. I suppose wiring the wiki to listen for events like empty category pages with populated child nodes and render them for editing in a special way that's different than how we present a content-bearing category page is impractical..

Remove "Special Page | Attach Map" toolbar on special pages. There is no need to attach a map to Special:Recentchanges or Special:Search pages. Once this is removed, the only link remaining is "Special Page," which is a superfluous link to the current page.

  • Done on search pages MattH 16:46, 18 December 2006 (GMT)

Group the items in the editing toolbar to reflect functional separation. Break the toolbar above each content page's title ("Article | Discussion | Edit | History | Move | Watch/Unwatch | Attach Map") into two chunks:

  1. "Article | Discussion | History"
  2. "Edit | Move | Watch/Unwatch | Attach Map"

Use ordering or whitespace to separate the chunks -- remember that they are to be related yet distinct.

  • DK Comment: Nice. The related yet distinct thing is well served by this regrouping and repositioning of elements

Encourage basic cleanup of categories. Here's a great example: Politics > Human Companionship for Goldfish > Iggy Pop (!)

Search

Remove or hide the "Search in namespaces:" tools at the bottom of search pages. Until and unless ArborWiki uses namespaces, this section of the page is a source of confusion and clutter.

  • DK Comment: ugh!
  • COMMENT from Jake: 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.
  • Done on results pages, but not the default search page. MattH 16:48, 18 December 2006 (GMT)

Do not show wiki markup in search results. As it stands, search results show the line numbers and surrounding text (in wiki markup) of search terms. This clearly violates the functional separation principle, and in practice, wiki markup out context is visually noisy even for wiki aficionados.

  • Excerpts have been removed until I can strip the markup.

Better group or chunk search results. Individual page results are currently shown in an ordered list. Separate search results with whitespace, and increase the prominence of page titles. Remove the page sizes, or display sizes in words or lines, rather than bytes.

  • DK Comment: again, super smart fixes of the patently polarbear variety
  • Comment from Jake: 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.
  • Done in groups of 5. Need better vocabulary for pages sizes. A work in progress. MattH 16:48, 18 December 2006 (GMT)

The Searching ArborWiki help should not redirect to the The Gargoyle campus magazine. This link appears at the top of search result pages, with the prompt "For more information about searching ArborWiki, see Searching ArborWiki."

  • Removed useless help link. MattH 16:48, 18 December 2006 (GMT)

Clarify the distinction between "Go" and "Search" in the search bar. This is a behavior inherited from the MediaWiki wiki engine, where "Go" searches will attempt jump to a matching page title if possible, and default to the regular full text and title "Search" if not. For the purposes of ArborWiki, it is appropriate to use only the "Go" feature, but relabel the button "Search."

  • DK Comment: but won't conflating these things create a situation where all no results searches will result in a prompt to create a page called <no results query>? I mean, that's proabably cool, but it does tip the search results page more toward the contributor layer than the browsing layer, no?

A bigger tent

The name and overall structure of ArborWiki should be realigned with the geographical area it encompasses. What began as a resource about Ann Arbor now includes Ypsilanti and other cities and towns throughout Washtenaw County, and this broadened scope may require the wiki to pitch a bigger tent.

(For this core strategy, we do not make specific recommendations. Since it has to do with the overall frontier and heading of ArborWiki, we are trying only to get the conversation started.)

In February 2006, Murph championed YpsiWiki, an offshoot of and sister to ArborWiki. In the months that followed, ArborWiki grew rapidly, whereas YpsiWiki did not. In October 2006, all pages from YpsiWiki were merged into ArborWiki.

Meanwhile, as ArborWiki grew, so did the number of content pages dealing with matters local to Washtenaw County or the general area, and not just Ann Arbor. Category:Eat_Local is a good example of this sort of content -- there are pages for farms and businesses throughout the County.

Since both of these changes occurred organically, the Main Page and many of the basic categories, such as Category:Politics, do not reflect this widened geographical area. Even the "UNIVERSITY" link in the global navigation predates this shift -- it points to the University of Michigan, which is the largest, if not the only, university discussed in ArborWiki. The Category:Streets of Ann Arbor now overlap the Streets of Ypsilanti -- there is a page for Huron Street and a page for Huron Street (Ypsilanti).

We are not the first to suggest a the idea of a new name for ArborWiki. To the extent we can tell from the ArborWiki history, that honor goes to Murph. Previous name suggestions include "HuronWiki" and "WashtenawWiki" or "WashtenaWiki."

This is a problem which could be explicitly addressed in several ways, or it could be left to the organic process which has brought ArborWiki so far already. However, ArborWiki may develop into a stronger "community brand" if it pitches a bigger tent.

Other reference points for this line of thought are the nascent DowntownYpsi.org project, and the now-defunct Ypsilanti Eyeball wiki.

  • DK Comment: tactically I think your reticence to suggest what the new name ought to be is wise.. you've got a big pack of ideas to sell and opening up the 'what's our name and why' can of worms could jeopardise focus and action on lots of the nuts and bolts you've assembled in your report. I'd posit that you could take a babystep toward suggesting a new name in a way that fits fairly snugly into the bigger tent argument and into the more inviting strategy. I suggest that you suggest that the word wiki be banned from the new name, whatever it is...

Where to? What next?

Recommendations have been made here regardless of the difficulty of implementing them with the MediaWiki wiki engine. Several recommendations are already part of The To Do List; others are not yet, but could be; and a final group -- while good recommendations -- are likely not feasible in the short term.

We suggest that another ArborWiki Work Session convene in early 2007 and chip away at the the to do list. Before the meeting is held, recommendations from this analysis should be decomposed into the task-sized chunks that are appropriate for the to do list, and moved to that page.

  • DK Comment: this is a fantastic assignment youse guys. Super well reasoned, argued and executed. I'll email you with your grade

Issues not in the original analysis

Semantically consistent labels. Is it "Discussion" or "Talk"?

  • Comment from MattH: Talk is the MediaWiki namespace, and I don't know if I can easily change this. I feel that "discussion" makes a lot more sense in a community context.

suggested edit

If someone could put this into Category:Arborwiki maintenance it would be useful to find a way to incorporate that into this process.

Edit tags