Rethought Topic Interactions - Prototype

Prototype for ideas developed in RethinkingTopicInteraction

Scope of the prototype

Although this prototype features some new designs / design ideas this is clearly not the focus. When reviewing or playing with the prototype please try focus on the interactions (the button, the menus and its contents, the indented behaviour).

Review the concept, not so much the visual surroundings

Each button leads to a default action / a screen.

Featured contents on those screen are just for illustrating the general idea not the final look and feel of those screens.

Limitations of the prototype

• The prototype is a clickable PDF documents
• Unfortunately the wireframing tool I used to create this prototype is not able to display hover effects. Something I found out too late . Each interaction within the prototype requires a click. To demo the intended hovereing effect I established a workaround which goes like this:
  • Next to each button in the menu bar is a small arrow. Clicking that arrow in the prototype would be the same like hovering in a real interaction.
• The buttons on the view and edit screen are all clickable, for all other screens just the current menu / action works.
• Anyway, I'm quite sure you will get the general idea...

Download / view the prototype

• clicking a button issues a default action
• clicking the little arrow next to a button opens the regarding menu (actually the menu should open with a little delay on mouse-over - you'll have to imagine that part )

Prototypes based on brainstorming in RethinkingTopicInteractions:

Type	Download / Description
PDF based prototype	Action menu above content area
PDF based prototype	Action menu on top of view port

-- CarloSchulz - 02 Nov 2009

Discussion

Thanks for the follow-up. So obviously you are not using InDesign as tool (it has rollover states...)

But this helps.

My first idea was to have this menu at the very top, above the logo. So it doesn't conflict with a horizontal navigation. For a side navigation this toolbar works ok.

Having all pages inside the tiny view frame gives less space for for example editing, but now that (WYSWIWYG) edit has a fullscreen mode it is probably not such a big problem anymore. Except for raw editing when you want the full screen. WYSIWYG warns when you are clicking a different link (navigating away) but raw edit doesn't.

For other pages, the smaller screen estate is less of a problem.

Now we also have to work on the landing pages. For example History lacks all the options we offer in the menu pane.

-- ArthurClemens - 02 Nov 2009

• The reason I put the menu bar not on the very top is that in my opinion it would conflict too much with the browser bar. Too many controls on one place then.
• On the other hand it might make sense to give your approach/idea a try as well. But I think this interaction schema works in both cases.
• On the limited space: The idea is to make those screens expandable where space is an issue. Something like "always expand "

• Landing pages: yes I left that one open as it better to separate that from the button/menu context as its easier to handle then

-- CarloSchulz - 03 Nov 2009

I am ambivalent wrt positioning the menu either on top of the content area or part of the view port of the browser window:

Viewport pros:

• allows it to stay there no matter where you scroll to
• does not interfere with the information architecture of the real site
• in a way is consistent with the browser menu itself (manipulating the current topic / url)

Viewport cons:

• might not be expected to be there or even get ignored
• far away from the thing it influences - the wiki content (probably not a problem for mac users)

Above-content cons:

• probably heavily interferes with a horizontal navigation as part of the site's info structure

Above-content pro:

• all controls wrt topic interaction are gathered in one place next to the topic content itself

Overall I am not sure if I like this heavy weight wiki menu (less of it would be better?). Any wiki of that kind will - well - look like a wiki. Similarly a MediaWiki always looks like a MediaWiki. People do use wiki technology for a lot more than "just" wiki. There's a consistent demand to make Foswiki look more CMSish and hide wikiness ... which obviously is tricky.

-- MichaelDaum - 03 Nov 2009

• right, this makes it even more important that we have such prototypes to be able to discuss this. Maybe we need a viewport prototype as well...

• wrt "heavy weight wiki menu": I was thinking of having just the "edit" in there and a "expand menu" item next to it. This would greatly reduce the menu bar when you dont need it

-- CarloSchulz - 03 Nov 2009

I am in favor of a twisty approach. See Apple's dev documentation page "Table of Contents" link.

-- ArthurClemens - 03 Nov 2009

Sidenote: this proposal also has a high impact on existing VIEW_TEMPLATEs and EDIT_TEMPLATEs last but not least wrt compatibility of existing wiki apps.

-- MichaelDaum - 03 Nov 2009

I think this not only a sidenote, what we do here will lead to a more or less complete redesign/new skin. The whole subject is so damn complex that you can not treat such things as if they were isolated.

"Rethinking" and thus redesigning such an important thing as the way we interact with topic is by definition just part of a greater picture.

Nevertheless, I believe our current approach will lead to a be much better project / product. Problem is, that what we do here is the easy part. Implentation and enough buy in from the dev community to help building what we are designing is the tough part.

-- CarloSchulz - 03 Nov 2009

Just had a look at your PDF prototype Carlo. Looks promising and must have been a bunch of work. How long did it take you to design that? Will try to give more detailed feedback till weekend, regarding grouping and naming. First impression is: we should go for it as it is, cause it looks and feels great.

-- FranzJosefGigler - 03 Nov 2009

One note regarding Michael's comment Similarly a MediaWiki always looks like a MediaWiki. - the controls will be skinnable, as much as our current topic action menu is. Hardly any MediaWiki site is skinned.

-- ArthurClemens - 03 Nov 2009

I'd like to here some more feedback from the non-gui folks among us... maybe we need to give 'em a little extr-ping

@ Franz: The current prototype is appr. the 4th iteration (including the mock ups in RethinkingTopicInteraction), so definately more than just a few hours - especially if you count in all the brainstorming between Arthur, Micheal and me.

-- CarloSchulz - 04 Nov 2009

We have been struggling with the "Manage" ("Change") menu item. Perhaps the "Manage" options could also be placed in the Edit menu.

It could mean that we enhance the edit page with these additional actions: set parent, change topic name, move to web and trash.

-- ArthurClemens - 04 Nov 2009

It also makes sense thinking about whether to have certain options in edit only. Otherwise we duplicate things in menus and screens...

-- CarloSchulz - 04 Nov 2009

Sure. We should not have duplicates.

-- ArthurClemens - 04 Nov 2009

Stellar mockup. One option for those who don't want these controls front and center at all times would be to hide them from unauthenticated users. Although I also like the idea of a Twisty.

-- DrewStevenson - 05 Nov 2009

Just uploaded the version of the prototype I demo'ed at the summit in Hannover.

-- CarloSchulz - 01 Dec 2009

Commenting is disabled while not logged in