1. Page Width: Text that spans the width of a page is not easy to read. Most--maybe all--online publications have multiple columns to make the page more interesting and easier to read. Some guidelines for good page design are available here. Should we consider a fixed width page or a template with sidebars?
    1. This was a quick design / technical tradeoff.  You'll note that Wikipedia and Davis Wiki also do not have fixed-width text.  If we fixed the width at a good, maxinmally-readable width then images and tables wouldn't work well inside the body of the text.  Because the wiki is so free-form this becomes challenging.  It's probably good to experiment with this down the road, even if it means more radical design changes. --philip
  2. Mapping Page: It's currently a challenge to work with the mapping page. It's hard to find a location quickly. The contrast seems poor. I'm guessing this has something to do with the mapping layer. Help / guidelines are needed. For example, when should an author use lines versus a polygon?
    1. The map stuff is just a first draft.  We are planning much more on that front.  We just wanted to get something functioning that would allow editors to add map information to pages.  The next big thing we'll look at is the ability to search the map.  RE: Contrast, the colors were chosen so as to compliment the overall localwiki style, but we haven't really done much, design-wise, to refine this yet (for instance, we've just been looking at things on our two screens here and haven't done much design testing on other displays yet).  Anything can be changed, of course!  --philip
  3. Create Page Button: Using the search box to create a new page is not intuitive. A [Create New Page] button after [All Pages] would be more intuitive.
    1. Chatted with Reid about this.  We will have a big "create a page about ____" on the front page.  For more mature projects, like Davis Wiki, it actually makes a lot of sense to force people to also do a search to create a page, as what they're looking for is likely stashed away somewhere on the wiki already. --philip
  4. Map Placement: The map consumes too much real estate on a page. Options are needed for sizing and placement. A thumbnail next to the page title might be a good default.
    1. We'll have an "embed map" option in the editor at some point which I think will help. --philip
  5. Ease of Use: This is an imperative; otherwise, it will be a challenge attracting and retaining good authors. Many good content providers will not be tech-savy and will walk away quickly if posting content is not easy.
    1. I completely agree.  This is our top priority.  Often there are tradeoffs between simplicity and options.  For instance, the map stuff is really simple, but it's not incredibly flexible.  So far we've just been sticking with simple. --philip
  6. Breadcrumbs/categories: From inside a page, (example Baguettaboutit), there is no way to tell where the heck you are, or how that page is related to its siblings/parents/children. Are there any plugins that will allow us to specify these? In the case of Baguettaboutit, the categories would be Food Trucks / Chapel Hill. --vic
    1. Yup -- the tags functionality (which will be coming in the next week) will accomplish this.  So for Baguettaboutit, the tags would be Food Trucks, Chapel Hill.  And clicking on those tags would bring up more info.  --philip
Add tags