Update: I've refactored this topic to be more of a specification document with screenshots of the latest mock ups and accompanying documentation of planned features. It now contains the latest mock ups only. The design studies and the discussions related to the visual design have been moved to
DesignStudiesForNewSkin.
--
CarloSchulz - 10 Jan 2010
Overall Goals
- facilitate workflows (see RethinkingTopicInteraction)
- reduce the number of screen changes required to perform an action like
attach
for instance
- allow beginners to move faster from being a beginner to being an intermediate user
- Do not limit power users
- reduce the mouse movements required to perform a certain action
- allow horizontal (like on foswiki.org) and side bar navigation (like in current pattern skin)
- a much better user experience
Background
On
RethinkingTopicInteraction and
RethinkingTopicInteractionPrototype the
UserExperienceTaskTeam discussed and defined a new concept for a more user friendly and workflow orientated way of interacting with topics. This topic documents the specific screen structure and states in more detail.
Mock up / wireframe for view screen
Just sketches by now so we can avoid the discussion about colors, paddings and stuff
. See
DesignStudiesForNewSkin for something more colorful.
click to enlarge
...and the same style just with a newly created topic:
click to enlarge
--
CarloSchulz - 06 Jan 2010
Specification of view screen components
Top bar
The top bar consists of the sections:
- Logo and tagline,
- search box,
- (optional) horizontal navbar,
- breadcrumbs,
- topic interaction menu
- "my account" area.
Logo
We need to make it easier for our users to change the logo and tag line. Therefore I'd like to introduce a temporary "change logo" link next the logo.
Ideas for implementation:
- Link is visible to the site admin only
- Link is removed after logo is changed for the first time (and after that the admin needs to go to web prefs)
click to enlarge
Search Box
Again, we need to think about the old jump vs. search issue and decide what we want as default in the new skin.
click to enlarge
Horizontal Navigation
Meant to be optional.
Open issues:
- What is the default? Horizontal menu activated or deactivated?
- How do we make customization easier? Or is the way it is done in our current website skin sufficient?
- What are the initial nav items? Webs like in this mock up or something else?
click to enlarge
Location Indicator / Breadcrumbs
Not much to say right now. Please add thoughts and ideas.
click to enlarge
Menu bar for topic interactions. Currently, menu items are: edit, create, view, history and help. The menu bar, in conjunction with the „my account area“ works as a kind of control area and remains visible on most screen. Each button can be clicked (which triggers the default action). In addtion a mouse-over over each button opens a drop down menu.
The drop downs interaction design should follow these guidelines:
http://www.useit.com/alertbox/mega-dropdown-menus.html
See
RethinkingTopicInteraction for background information on the general concept.
Wording definitions are managed on topic
MenuItemsForTopicInteraction
click to enlarge
My Account
The „my account area“ features links related to the users activitis on the wiki. The account area would be a natural place for adding a "customize this area" link - which would then include a means to customize the edit buttons and the links.
click to enlarge
Side bar
The actual default contents are not defined yet.
Ideas:
- sub navigation / list of webs
- Changes?
- ...
click to enlarge
Content area
Contains the rev info, the h1 and the body text.
We still need to agree on how to manage the whole
page title vs. < h 1 > vs. name identifier issue.
Action item: Find and link to regarding proposal topics.
The rev info will be linked to the latest changes of the topic. See
WireframesHistoryScreen
click to enlarge
A tabbed box for meta data. Each tab section has specific edit actions. The idea is that the box is also there during edit with fields/contents editable.
A „Comments“ section might be another candidate for the box.
There are three possible states.
- form attached
- no form attached
click to enlarge
The exact copy is tbd. I think we need to have a basic introduction immediately visible for those who have no idea what a form is. Something friendly which does not give the user the impression that a missing form is a bad thing.
click to enlarge
Attachments
Attachment handling is largely improvable. Currently the rather user unfriendly manage screen is needed. The idea is to get rid of that screen by providing the possible actions in an unobtrusive way directly next to the attachment.
For an attachment the following actions are defined: "update", "move", "delete", "rename", "display options".
A possible implementation would be using the mouseover mechanism as one can see on
http://pipes.yahoo.com/pipes/pipes.popular. For "edit description" we could use a pencil icon, perhaps on mouse over as well.
Action item: Display (in edit) and handling of 'hidden' attachments.
n files attached
click to enlarge
no files attached
click to enlarge
Permissions
Definition of who's allowed to view or edit the current topic.
Two states need to be adressed: permissions defined, permissions not defined.
permissions defined
click to enlarge
permissions not defined
click to enlarge
Topic Settings
Note: this was labeled "View" respectively "Edit Settings" and handled across two tabs. I think this adds just another tab without adding that much value. So I joined them on one tab called "Topic Settings".
Topic Settings contains the topics prefs plus definition of what is displayed and what's not (breadcrumbs, meta data box [or just specific tabs], sidebar, header, etc.).
settings defined
click to enlarge
settings on default
click to enlarge
The bottom bar features the contents of the topic interaction menus. Handy on large topics.
An alternative approach would be using this area for navigation links.
click to enlarge
The copyright note:
I thing this can be left as is.
Discussion
I needed a bit more structure to better assess what I've mocked up already and what is still missing.
Most remarks are integrated in above documentation or have been moved to
DesignStudiesForNewSkin..
--
CarloSchulz - 10 Jan 2010
Don't forget the "change form" state.
--
MichaelDaum - 11 Jan 2010
Btw found this write up:
The case against vertical navigation.
- Interesting that this article is on a website which is designed exactly the way I hate websites. I love my left bar, and looking at how it is used and tailored in practical use, it actually works well in a wiki context. It is wrong to just dismiss it like this. The horizontal navigation bar suggested in these wireframes is nice and the right way to go. But that should not prevent ALSO having a left bar that can be added per web basis and be used actively. And for sites with many webs it is a hard to live without. It is a pain having to use a pulldown to navigate from web to web. For single purpose wikis you do not have the same need for a side bar. -- KennethLavrsen - 22 Jan 2010
--
MichaelDaum - 11 Jan 2010
On customizing the horiz. navigation: how about making it a "my webs" feature similar to the "my workplaces" concept of
03spaces.
--
MichaelDaum - 11 Jan 2010
I added the empty states of the tabbed meta data box plus an empty view screen.
--
CarloSchulz - 20 Jan 2010
Have been watching quietly, this is great work!
Thought I might link to something that was brought to my attention by a colleague -
http://gomockingbird.com/mockingbird/ - a collaborative UI wireframing thing.
--
PaulHarvey - 22 Jan 2010
Thanks Paul.
WRT mockinbird: I heard of it but never tried it.
Actually, I'm thinking about building the whole thing in HTML using some kind of css framework like
http://960.gs or maybe YUI. That way we would have something reuseable and collaborative.
--
CarloSchulz - 22 Jan 2010
YUI is not the fastest, nor the best, but it is handy.
In my experience, YUI will increase the loading time for a topic, just by downloading the .js needed for it to work. Also it is very intrusive.
All in all, i'm not against YUI (we use it in our product). Just wanted to point out some things we found that might affect Foswiki.
--
RafaelAlvarez - 22 Jan 2010