this is about 8 months old
I took a first shot at wireframes for the OSM website. Right now they're incomplete but the major concepts are there, so I wanted to take some time to outline my intentions and open things up for feedback.
Basically, I am introducing two new concepts: a revised information architecture, and a new, combined activity feed.
I scrapped the old navigation. No more tabs, and no more persistent sidebar. I wrote down all the components of the OSM web app, and thought about how best to categorize them. I ended up with 5 basic uses of the site, and buit the UI around those functions. Rather than tabs, these sections are more like overlays, with a more-or-less persistent map underlying everything.
The sections include:
Home - "I want to use the map for navigating/exploring the world"
- Search
- Conditional content, like ads for conferences & an introduction for news users
- Someday, routing
Social - "I want to participate in the community"
- User profiles
- History (renamed "activity", part of new activity feed)
- Diary (diary entries are now called "notes", part of activity feed)
- Traces (part of activity feed)
- Messaging system (Not Done)
Editor - "I want to edit the map"
- iD. Ideally we just have one good editor. You click the editor tab and you've got an editor interface for the current map view right away.
About - "What is this / I need help!"
- Most of the stuff in the current sidebar should go here
- New help landing page (yet to be mockups up
- User settings / Notifications
- Donate button
- Map controls
Figuring out where to put the data browser is a problem. Right now it is in a tab under the "data" section. That kind of makes sense for users who just want to inspect data, but when accessing the data browser through the activity feed, this placement makes less sense. This would be a common scenario:
- I navigate to the activity feed.
- I am curious about a changeset, so I click the changeset and the changeset details page appears.
- I want to see more specifics about a new node that has been added, so I click on a particlar node in the changeset details page.
- Then, I end up in a the data browser, leaving behind the social section of the site and essentially losing my place.
There should be a smooth flow between users, changesets, and the data browser. Instead of jumping to a different section of the site, node/way/relation pages could be accessible either through data->data browser->node or through social->changeset->node.
Instead of separate, disconnected pages for all user-generated content, like changesets, traces, & diary entries, I propose a single feed. This dramatically simplifies the site and takes the formerly somewhat random placement of these separate pages and places them all in a single, accessible, and easy to find location. The feed is filterable, so if you want dedicated section for blogposts, the feed will get you what you want.
Firstly, In these mock-ups, the feed is always just a skinny sidebar, except on the User Profile page, and there might not be enough space for how heavily the site will rely on this feed. There could be an expanded version of the feed. Especially for notes, where having more text to preview before looking at full posts is helpful. Working in a full-width feed or even only using a full width feed might be better. Need to experiment more.
Secondly, there is some tension between showing activity related to the current map view, and showing global activity. Right now there's only a map-view based activity feed. Where do notes that aren't geo-tagged go? Should all notes be geo-tagged? Lots of questions about how map-reliant everything in the feed should be. Maybe there should be a toggle or button to show a "global" feed, separate from the normal map-dependent feed?
Short term, there is still a lot of polishing of what I have now to do. Once I finish up a few more screens and make these more complete, I will either present them to the wider OSM community as wireframes, or do a visual design pass on everything to make things look more presentable.
Other outstanding questions that could be addressed with wireframes include: how do we address mobile? What should the first experience walkthrough look like? Can we incentivise more mapping with badges, leaderboards, stats dashboards? What can we do to aggregate the changesets and present them in a useful way? Not sure if these need wires for any of these things this point though.