Rethinking topic interaction

No matter how cool your interface is, less of it would be better.

Motivation

We have gotten used to our decade old topic interaction model. Since TWiki Bejing (version 2.0) nothing much has changed in the way we interact with topics:

• we have bunch of unsorted 'topic actions' at the bottom of the page
• all other stuff is in 'More' that new users never find
• if we offer help, we explain the interface, not by first creating the concepts overview, and then "how-to's" in solving problems (this is a (tm)wiki legacy but has hardly improved)

The way topic interaction is organized just raises the bar for new users, and does not help in getting them to intermediate users: there is no way to find out what you can do with a topic (and who reads documentation anyway).

We can improve by:

• grouping actions
• get rid of the More screen
• provide help with each group (focus on how to solve a problem, not explaining the interface)

Let's do this step by step. The problem can be split up in these parts:

1. Define the most logical groupings of topic actions
2. Define task flows and how these can be supported best
3. Define the user interfaces for these task flows

Goals

• Do not overwhelm beginners with too many default options
• Allow beginners to become intermediates more easily - give them clues, direct them towards the power foswiki has to offer
• Allow intermediates and experts to customize the interactions according to their needs

Summary of past opinions and discussion

see rev=38 for all the comments thus far.

Summary of stated opinions:

• focus on the most essential actions
  • - I think these are the essential actions for default use: Edit, Attach, History, Manage, New topic. But of course it should be made easy to change that setting, either by expanding or by limiting it. (AC)
• Make buttons context sensitive so that if a user is not entitled to perform an action, it just doesn't show up in the menu (grayed out?)
• Make it easy to configure the links
  • For instance to remove all edit buttons, for admins configure a menu that only shows admin accessible actions - move web, rename web, log out.
• Plugins should have a simple way to add to or replace items in the menus
  • The PDF plugins could add a view PDF action. PDFLatex, a Latex button.
• How do extended operations fit into this overall scheme, for instance "Subscribe"?
• Daily links should be directly accessible
• Combine quick links and dropdown menus
• Menu labels should preferably be verbs
• Some groupings are not that logical: do we expect Print under View? Same goes for History, Link, reparenting.
• Some of the actions might fit better into the "Edit" workflow itself, so a separate menu item is not necessary
• While a menu structure might be well thought out to cover all actions, the top level does not make up a good toolbar.
• We should optimize the interface towards the intermediate users. Repeated actions need to be fast and efficient.
• Some clients/users prefer a UI which is limited to absolute minimum, eg. "Edit, Attach, New"

We need to further differentiate between no-click features and click-features to come up with the final list of candidates. Currently this is based on heavy wiki users feedback... so this is not a final list of requirements yet.

• No-click:
  • seeing the topic revision, date, author
  • breadcrumb
• 1-Click:
  • diff between this and previous version
  • Edit Raw
  • View Raw
  • Edit Wysiwyg
  • compare rev's
• 2-click *...

Also consider the context and what information is needed in a given context:
When I'm doing more advanced modifications I'm likely to need more info about macros and stuff. Something not yet integrated in our set of interactions. This Is a regular task which is not at all suported by our interface. Mainly because we treat them as navigation items and we are not particulary good in providing great information architecture. Of course, this is a behaviour pattern of a user somewhere between intermediate and expert. Nontheless we should think about how to support this.

3rd party examples

An application that has the same intention, namely grouping related actions on the screen: the application menu of Adobe Acrobat (not the textual menu at the top of the screen):

GMail has a mixture of "direct" buttons and flyout buttons (with arrow):

Possible Solution 1

I have taken a shot at designing the interaction. The menu is really simple now, but that is also the result of removing Print (should be elsewhere on the page), Backlinks (ideas?) and the < < < history links.

Also I found the label History to cover the contents well, and making a verb from it would stretch it ("Compare versions" for instance). "New topic" instead of "Create new topic" also works fine.

-- ArthurClemens - 28 Sep 2009

Possible Solution 2

I have taken a slightly different path...

Some thoughts:

• We promote Foswiki as a tool to build or integrate applications including build-in wiki functionalities (which is not the main focus of development anymore).
• When we look at how we interact with foswiki it becomes obvious that our needs as a user pretty much depend on the context of the topic we are looking at.
• A discussion topic, a template topic, a topic which powers a wiki application - they all require different interactions and more important, they require knowledge about all the things Foswiki has to offer.
• Infos about Macros, plugins, help resources, etc. they are all more or less hidden behind a rather crappy information architecture - but to become an intermediate or expert user I need to know and be able to find them in the context of my interactions.
• Desktop applications feature such an interface in the form of menus and toolbars...
• What about styling the interactions in such an application orineted way? This would greatly allow us to show that there's more than just "edit" without creating a too complex UI for our beginners...

Possible default view:

• revision info and breadcrumbs visible
• a basic set of one-click interactions
• a standard set of menus introducing the remaining interactions
• a customize link in the top right would lead to a screen which lets you customize your menus and buttons

---

Possible extended view:

• Menu and buttons expanded
  • eg. with an export menu which only shows up when export functionalities are enabled via plugins.
  • additional buttons are just examples... - we will need mouse-over explanations of course
  • odering would be handled via to be designed "customize" screen
• When logged in as admin user (or when user is part of Admin Group) an additional admin menu shows up.

---

"Topic" menu

---

"History" menu

• second sketch shows examples of a possible sub-menu integration

---

"Location" menu

• "Change location" would be a unification of re-parent and move. Although different from a technical perspective they are really really similar from a non-techie perspective.

---

"Foswiki Tools" menu

• The idea is to feature the most important foswiki tools in this menu to allow learners quick and context fitting access to our daily toolset.
• This menu behave differently than the others as all items in this menu are links.
  • question 1: is this much of a problem after learning it in the first place?
  • question 2: how to solve this? New window / tab? Modal overlay?

---

"Help" menu

• I very well remeber how much I struggled to even find out about the support forum or IRC and other resources...
• Why not offer this as part of the interaction menu?

---

"Export" menu

• a menu which would only show up once "exporting" plugins have been enabled:

---

"Admin" menu

• Shows up only when logged in as admin or when user is part of admin group
• gives access to prefs, configure, security topics...

---

Bottom line:

Menus and their content may need fine tuning and the ones among us that lived in fossy-land for too long may need to get over the fact that the interface and wording do not reflect the implementation model 1:1 anymore.

However, I think this interface would far better...

• demonstrate the underlying power of Foswiki without disturbing beginners.
• follow existing interaction patterns and thus providing a already familiar apperance
• allow admins/experts to extend the interaction menu without breaking everything visually

Again, above screenshots are meant to illustrate the overall concept, no to define a final structure or content.

-- CarloSchulz - 05 Oct 2009

Discussion

see rev=38 for all the comments before 5th Oct 2009.

-- CarloSchulz - 05 Oct 2009

I like it: users easily recognize a more application-like interface.

One first thought: how does the topic interaction part itself "interact" with the rest of the site, that comes with its own navigation, like sidebars and horiz menus? If you continue to add the rest of a normal webpage around, it might create confusion which parts implement interaction with the site and which part enable interaction with the current topic. Just try adding a horiz site menu.

-- MichaelDaum - 05 Oct 2009

I have a version with those sorrounding elements like nav and sidebar already. I just need to play with them a bit more to find out what fits best. Just thought it would be better to discuss the general idea first.

Besides your valid points, there is a whole lot more we need to address. The edit screen and others needs to fit into that concept as well. So you are right, no interface part should be treated as single entity

-- CarloSchulz - 05 Oct 2009

Some wikis design topic interaction at the very top of the html viewport. So it looks more like a part of the browser than part of the web application. This would distinguish it from site navi at least...

-- MichaelDaum - 05 Oct 2009

Carlo, great you are extending and improving upon my line of thought.

Nice style BTW, the hand drawn look.

A couple of remarks:

• A lot of wiki content is meant for viewing. When viewing, the app interface is in the way - it takes up a lot of space and just looks complicated. Having it at the bottom (when viewing) moves it out of the way.
• An app menu - by its nature - is expected to be consistent, unchanging. So I am not sure how that we can extend this to other screens.
  • Having this application menu does not solve the need to have inpage buttons (like "Save" and "Cancel") on other screens.
  • The application menu also cannot completely do away with inpage structures. For example, for a long time I want to change the interface of the attach screen to have tabs "Upload", "Delete" and so on. The app menu command may be too much hidden for a web page.
  • Or perhaps the app menu design has to be taken further towards webpage land, with larger buttons and elements like tabs.
  • Google has a lot of web apps that do not look like desktop apps at all.
• I am not convinced that we need to split menu items and one-click buttons. I think a lot of web 2.0 interfaces show these can be combined in multi-buttons (as sketched above).
  • I also find the icons problematic (but it may be we have too many of them on the site).
  • But icons work in the fold out panes, where they enhance the menu labels.
• View previous version: that can be just one item: the previous one. All other revisions belong to History view and just may not be available as shortcut.
• Foswiki Tools feels too generic (not a solution to an information need).
  • Of course we do need to link to macros, but mainly when editing.

-- ArthurClemens - 05 Oct 2009

Another app like interface: http://getballpark.com/

-- ArthurClemens - 07 Oct 2009

Thinking about Carlo's application menu it occurred to me that we haven't looked well enough at supporting workflows. Instead we have had a tunnel vision on the view screen.

If you look at Foswiki as an application supporting an editor (everyone who edits pages), the view screen is often in the way. Let's take a number of workflows where actions are chained - and these are not uncommon:

• If you want to add an attachment to a topic (and you often find out while editing), you:
  • In edit mode, save the topic
  • Go to attach, and upload a file
  • In view mode, click on edit
  • Put the attachment someplace
• To correct a mistake or vandalism, you:
  • Check in raw view what the problem is
  • Check previous revisions, until you find one where the topic is still ok
  • Go to More, restore revision
  • Verify the restored revision in edit mode, and save
• Setting the location (parenting) of multiple topics is a pain, because you have to go from view to More to view again for each topic

Why are these flows more difficult than they should?

• Screens are set up in an inconsistent way, so you have to look for your action links (especially for those hidden on the More screen)
• The action buttons on the view screen are displayed such that they do not hinder reading the page. But it means that they are inconveniently placed when in a workflow. Looking for links breaks the workflow.

All these flows could be much improved by having a consistent application like menu, at the same location, across all screens.

Compare for instance how WordPress or Content Management Systems deal with this: the view is the live site, somewhere out there, while all the action takes place in a workflow environment.

My proposal is similar to Carlo's but has some differences.

Similar:

• Have a constant app menu across all screens
• Provide folding out menus with additional commands

Differences:

• Only provide commands, no content links in the menu
• Only show the app menu when having performed an action, so it is not visible on the view screen at first
• Provide the option to hide the app menu again from the view screen
• Print and RSS are not part of the app menu, instead should be offered near the content

This is a simple flow, on a view page clicking on an edit button. On the edit screen the top menu becomes visible. After saving, the top menu stays in place above the view screen. It can be hidden with a button click.

The action menus are evolved from the previous versions.

• I have added the View menu
• I have copied Carlo's idea of having icons in the fold out menus-- JtHolmes - 25 Dec 2009
• To reduce the number of menu items, I have folded Attach under Edit

-- ArthurClemens - 08 Oct 2009

Some tasks that might need a place on the app menu as well even though they are not topic actions.

• new web
• rename web
• delete web

• configure foswiki
• WebPreferences
• SitePreferences

These are all actions that are of interest to an admin only. So they should be hidden from non-admins.

-- MichaelDaum - 09 Oct 2009

This is an example of an admin menu, that would appear once logged in as admin, or if you are member of the admin group:

-- ArthurClemens - 09 Oct 2009

I would like to float an idea of an alternative organization for all of these menus. Rather than organize them around functions, I'd propose organizing them around the locus of action. So at the top level, I would have only 3 items: topic, web & site. One additional item might me a personalized menu. All the above mentioned menu items could easily be organized under these top menus, with differing levels of complexity based on the role/permissions of the user. However the top level would remain consistent while being compact and unobtrusive.

• You need to take into account the frequency of use. How many times will a user (not admin) do something with web settings/publish/rename a web, let alone a site? I am afraid you end up with 2 unused buttons, and one "topic" button that does not reveal the meaning. In a way it is categorized hierarchically correct, but not optimized for use. -- ArthurClemens - 09 Oct 2009

-- LynnwoodBrown - 09 Oct 2009

expanding the menu over more than just the view screen is a good approach.

Still, I feel "Manage" is not the right term for actions like move, rename and so on. Manage is not a good trigger

-- CarloSchulz - 09 Oct 2009

What about "Change"?

-- ArthurClemens - 09 Oct 2009

Users have problems to decide when to go to "Manage site preferences" and when to "Configure this site". That's very closely matching the same thing. Web Preferences might interleave as well. I know this has technical reasons. These inconsistencies carry over to the interface now.

"Logout admin" might become redundant as soon as we take the complete page under consideration.

I am not sure if we should stuff every task into the app menu. The advantage of an admin shell is to give this different role a place of its own more adequate for it. It seems as if we should start to cut down the menus again. It is getting too complicated for the most common roles: page hoppers and drive-by wiki editors.

-- MichaelDaum - 10 Oct 2009

I see the problem with the admin menu, because the labels are a bit confusing.

The intention of these menus is to have the top button leading to the default action (View, Edit -- WYSIWYG, ) or to an overview page (History, Manage/Change, Export, Admin). So somehow we must make it clear that the top button "Admin" can be clicked and will lead to an admin overview page.

We can also add 1-liner explanations to the links in the fold out menus.

-- ArthurClemens - 10 Oct 2009

Let me sum up and comment on what we see here.

Both above app menu designs are very different. Both concentrate on a specific part of the page, i.e. the area directly above the content area. They both don't integrate the complete page, including a top bar, horiz navigation and sidebar navigation. I think it is critical to do so to avoid redundancy. Some elements that are now part of the above proposals might find a better place outside the area proposed so far.

The first approach has got a menu and a toolbar with icons to quickly access some of the most important actions. I like that, i.e. when it becomes customizable.

There are some redundant/overlapping menus in the first approach. For instance "Topic->Rename" and "Location->Change Location". While I know that two different operations are to be triggered underneath, the user probably does not. It both smells like the same thing. This might be inherited by the fact that "Rename/Move" is the same technical function and repharsing "Reparent" as "Change Location" does obfuscate the concept too much IMHO . A (faceted) document might have quite a few locations all of which are kind of virtual like being found in several categories at the same time. Enforcing the analogy of bookshelves where the same physical book can be found only in one location is constraining digital knowledge management too much.

So "Change Location" is not an easy one. Mabe users intend more of a "Change title" when they find "Rename", and a "Categorize/Tag" to configure the location of a topic. Changing the WikiWord is yet another thing that touches the "cool uris" and "permalinks" field but also the "database id" pattern.

So probably the "Location" menu is dispensable as the actions listed there are very "Tool"-ish.

I really like the icons on the menu of Carlo's proposal and the way menus are structured by separators and descriptions. That way users will memoize menu entries a lot easier. Menus on the second approach are too unstructured with menu items reading almost identical: multiple "Manage..." or "Edit ..." in the same menu.

There are a lot more menus in the second approach than in the first.

I like the idea to hide these menus when the user is not logged in as outlined by the second approach. I think it is very important to hide it not to obstruct reading the content.

In the first approach, I'd put "Export" under "Topic" and make "Settings" a menu of its own one before "Help".

"Foswiki Tools" could be shortened to "Tools" only.

The "Customize" flush-right should go under "Settings".

I think "Edit" and "Edit raw" is not needed. The default edit mode should be configurable in a "Settings" dialog.

The "Tools->Sandbox" should actually be on the "Help" menu because it is used during the learn phase most of the time. Not sure. Maybe this "Go" task is covered by other navigation elements outside the above designs already.

"Tools->Wiki applications (learn how to...)" smells like a perfect fit for "Help" where all "learn howtos" can be found. Some of the other entries in "Tools" are perfect "Help"ers actually.

All of the "Help" menu as it is now whould make up a nice first landing page for newbies.

Likewise I see all "Admin" stuff more as a wiki app of its own rather than a fit for the menu system.

-- MichaelDaum - 10 Oct 2009

Great input Micheal. Thanks for you analysis this is really helpfull.

I'm on vacation the next two weeks but I'm looking forward to help driving this iniative once I'm back...

-- CarloSchulz - 10 Oct 2009

Michael misses an important point IMO. That is the different nature of the 2 versions of top menus.

• Carlo's menu is a mix of actions (Topic, History) and pointers to HOWTOs, and is designed to provide in a nutshell all capabilities of and help for working with Foswiki.
• Arthur's menu is a mix of direct actions (Edit) and links to action landing pages (History) - where the folded out links are all pointers to action screens. It is designed to facilitate workflows.

How can we offer the best of both worlds?

Let's exclude Admin for a moment.

If the goal is to provide information about Foswiki's capabilities:

• Carlo's menu offers Tools and Help, which could well be combined into Help. We could have 2 columns in the fold out pane to create groupings.
• Arthur's menu offers no help, but should.

If the goal is to facilitate workflow - the idea is to:

1. Make it easy to jump from one action screen to the other, without having to search for it
2. Make it easy to change the menu based on rights / group membership / personal preference / ...
   • This could evolve to have a menu based on a chained action workflow (f.i. Create writing task, Review submissions, Combine to one paper, Publish)
3. Give guidance, for example by showing the current step

The comparison:

• Carlo's menu offers Topic, and additionally History, Location and Export, which all three are topic actions, and could just as rightly be offered under Topic. This distinction is a bit confusing.
  • When on the Edit page, the menu would still show "Topic" as first item, which is less helpful
  • A place must be found for Attach and Topic form
• Carlo's menu separates groups of actions (most used, less used, and conceptual groupings) which eases scanning tasks
• Carlo's menu has bolded and blackened action words which eases scanning tasks as well
• Carlo's menu offers help descriptions, especially useful for the Help links
• Arthur's menu has laid open the main topic actions View, Edit, History, Manage, New topic - which make them one-click targets to continue the task at hand, and by highlighting the current (main) task screen functions as location indicator

Updated screens with most of these ideas combined:

-- ArthurClemens - 11 Oct 2009

I like that a lot. Actually I love it.

-- MartinSeibert - 11 Oct 2009

Here are some unordered remarks.

"Edit" and "Change" as label for these two menus are very close semantically. Some of the "Edit/Change" actions are probably already reachable as part of the edit screen. The current menu as far as I understand is a menu for the view screen. There might be some actions that could be deferred to the edit screen. Candidates are: Add/remove form, Settings, Repartent, Attachments, Tagging, Rename/Change title. All of these are arguable of course. The point is that I have the feeling that there are too many things to "Edit" or "Change".

"New topic" is an area that needs to be customizable. For instance, if you deployed a blog, bug tracker, time tracker, project management app in the current web, users want to create a new topic of a very specific kind, e.g. "New discussion", "New bugreport", "New ...". This highly interferes with the templates each of these topic types need....

-- MichaelDaum - 11 Oct 20

The current menu as far as I understand is a menu for the view screen - no, this is the menu for all screens, except when on the screen itself, the menu item is highlighted. The links in the fold out menu are shortcuts to specific screens, for instance a Settings screen, or a edit tags screen (if a tag plugin is installed).

-- ArthurClemens - 11 Oct 2009

The next step should be a prototype, to give a feeling of the interaction of the menu with topic states.

-- ArthurClemens - 25 Oct 2009

on the prototype: I'm almost done I just need to update it to thel latest version (11 Oct. 2009)

-- CarloSchulz - 26 Oct 2009

a limited prototype is now available on RethinkingTopicInteractionPrototype

-- CarloSchulz - 03 Nov 2009

The Wikipedia makeover (currently in beta) has some similarities (but is also very different):

-- ArthurClemens - 04 Nov 2009

I have created a design mockup with an inpage menu:

The original idea, with arrows indicating dropdowns (but that increase feeling of clutter). The menu is dimmed to 'integrate' into the page:

Arrows removed:

With rollover, a menu dropdown pane appears (quick and dirty pane thrown in):

-- ArthurClemens - 04 Nov 2009

Thanks for the mockup. Illustrates quite clearly that this approach easily leads to clutter: site navi + breadcrumbs + menu ... that's too much.

Can you create a prototype moving the menu to the very top of the viewport?

-- MichaelDaum - 05 Nov 2009

I will publish an additional version of my prototype to have the menu on top of the viewport. Will upload tonight...

-- CarloSchulz - 05 Nov 2009

Many nice examples and something to look forward to.

I have two concerns.

The examples have lately been shown with the Foswiki skin where webs are at the top bar. Most corporate users have 10-200 webs and will never use a skin with webs at the top bar. We can see in our Foswiki project that we have reached the limit and we have webs you cannot access via the top bar. So we need to also remember the skins where webs are listed in the left bar. And I actually think a lot of the menu systems would function much better (be less of a clutter) if the menu system was graphically more part of the top bar area.

• We take the foswiki site skin because this is the most difficult to get a balanced interface: the main navigation is in the way. -- ArthurClemens - 05 Nov 2009

The other concern I have is that the requirement of having 1-click toolbar for the most common operations have not been shown. You have correctly captured this requirement in the introduction of this topic.

• 1-click are the button labels that lead you to "view", "edit". The expanded menus show the 2-click actions. -- ArthurClemens - 05 Nov 2009

It is only around 4 to 6 buttons we need. But we need to remember to include them in our examples so they do not get added afterwards looking like one fat oops.

But again. Very nice work you guys are doing with one good looking example after the other.

-- KennethLavrsen - 05 Nov 2009

Kenneth, you might want to check out RethinkingTopicInteractionPrototype.

-- CarloSchulz - 05 Nov 2009

new prototype with viewport not ready yet. but here are some screenshots...

-- CarloSchulz - 05 Nov 2009

These are designs for the top bar on a pattern skin page:

But myself I like the less cluttered version, no arrows and lines (a la Facebook):

On a light background:

Or with Facebook colors:

-- ArthurClemens - 05 Nov 2009

Ok, both versions seem to work from a pure visual perspective. So viewport seems to be the smarter alternative as it allows horizontal nav bars whitout cluttering everything.

Need to see how it works with a small prototype...

-- CarloSchulz - 06 Nov 2009

For comparison, see also the screencast of EditMe.

• Couple of small links on the page: Edit, Files, Versions, New
• Edit leads to an new screen: an edit area with tabs, more or less consistent with the ideas above
  • I like the word "Organize" for setting the parent

-- ArthurClemens - 10 Nov 2009

I like the new menu style interface, it adds a lot to the overall system.

I would also like to see the Left Nav bar have the following

• Two Icons Side by Side
• First Icon is View/Read Only has text 'Nav Bar'
• Second Icon is basically a dropdown list containing
  • Show
  • No Show
  • Dynamic

If Show is selected the Left Nav Bar will always be displayed

If No Show is selected the Left Nav Bar will never be displayed

If Dynamic is selected then Hovering/Clicking the Left Icon (containing text 'Nav Bar') will cause the Nav Bar to be Displayed until a selection is made or the user moves the mouse cursor out of the Displayed Nav Bar.

-- JtHolmes - 25 Dec 2009

Edit interaction

See InteractionPatternsForEdit

-- ArthurClemens - 23 Feb 2010