Task Teams » User Experience Task Team

Summary:	Set and develops User Experience direction for TWiki and TWiki.org and its sub servers
Team lead:	TBD
Participants:
Status:	On Hold

This Team sets and develops User Experience direction for both the releases of TWiki and TWiki.org and its sub server. It can delegate Experience related work to the TWikiOrgWebsiteFacilitatorTaskTeam, who work to keep the system running, and to developers.

---

WORK IN PROGRESS: This document is under heavy construction. We are currently working on our agenda. Everyone is welcome to contribute!

---

About the User Experience Task Team

Goals

• Build the foundation on which our devs can code the most powerful and easiest to use Wiki and web application platform on the planet!
  • creation and maintenance of the TWikiUserExperienceVision
  • Identifying the work products needed to turn this vision into reality
  • establish a development framework (wireframes and storyboards as drivers for architecture and design)
  • help people get up to speed regarding UE concepts
  • establishing TWikiUserExperienceGuidelines

• Work together with the TWikiOrgWebsiteFacilitatorTaskTeam to make TWiki.org the nicest wiki-project-site on the web.

Members

CarloSchulz

MichaelDaum

ArthurClemens

SvenDowideit

Wanna join? Let us know, there's plenty of work to do!

Required Powers

If in line with the TWikiMission and backed up by the ExtendedTWikiRoadMap:

• final say about TWikis new look and feel (otherwise all the work that needs do be done by this team is pointless if it doesn't have the final say).
• Change TWiki's architecture
  • Don't know how to put this right by now. The point is, without the power to change the way TWiki works today where are just curing symptoms instead of building a solid and well designed TWiki that's ahead of the competition and not behind it.
  • This is espacially tricky as we need to have existing customers in mind (upgrade hell?)
  • need some Dev help and statements on this one
    • I would say: user experience should drive development, and our goal is to create a unified (and possibly diverse) vision on UE. We will help to define features in terms of user benefits. We need to have diferent users in mind: new users as well as existing users; sporadic users versus power users. -- ArthurClemens - 12 Sep 2008

InterimGovernanceTeam contact

MichaelDaum will help this team craft their charter to prepare for rubber-stamping by the InterimGovernanceTeam (or the association, if it is formed in time)

Resources and starting points

Components for a Successful Web Site Redesign

Some good reads on usability and open source:

• Designing Web Applications for Use
• Why Free Software has poor usability, and how to improve it
• Ten Ways to Make More Humane Open Source Software
• The Rise of Interface Elegance in Open Source Software

• KDE Usability Project - Good input for organizing our own efforts.

Important TWiki topics on Usability and User Experience:

• TWikiUsability
• TWikiForNormalUsers
• UsabilityCategoriesAndHeuristics
• WebPageAudience
• TWikiUserExperienceVision.
• TWikiOffice
• MasterRefactor - good stuff
• InterfaceProject

Agenda

By now, we might wanna start with these things.

If we manage to keep the resulting work products small, we increase the possibility to get things done.

Refactor or add your own ideas...

Have A Vision

Let's look five or ten years into the future and ask the question, "What will using TWiki be like on that date? What experience will the user have?"

Having a clear vision helps us chart a direction for our design, helps identifying if any design idea is moving us closer to the vision or farther away.

It's critical for our vision not to focus on future technology but instead on future experience. What are the steps in today's process that makes things cumbersome or frustrating? How could the TWiki-experience become more delightful?

Want to help shaping the TWiki-vision? See TWikiUserExperienceVision for more details.

Who are our users?

To successfully redesign, we need to know who is using TWiki and what are they are doing with TWiki.

WebPageAudience and it personas were created to understand the needs of people who are visiting TWiki.org. Maybe we can (re)use them to understand the needs of TWiki users.

• Consider that the everyday basic needs of most TWiki users are different than those of most TWiki developers, consultants, and admins. Elements of a successful user experience for one of those groups will likely conflict with (or at least clutter and confuse) the other, or will remove tools they need quick access to. I think this might be at the root of some of the recent debates about TWiki facelifts. Does a different experience (i.e., different skins or templates) need to be provided for different classes of users? -- DavidWolfe - 12 Sep 2008 (Feel free to delete this comment if not needed here.)
• Exactly, who are our users? Instead of the everbending elastic user, a good way to define users is Personas. We have defined personas for twiki.org (WebPageAudience) but not yet for twiki usage. The above below ABC list may be of use for grouping behaviours and then create personas out of them. -- ArthurClemens - 12 Sep 2008
• Regarding the "who are our users" issue, here's a quote from Designing Web Applications for Use: "Robert Hoekman, author of Designing the Obvious: A Common Sense Approach to Web Application Design (New Rider Press, 2006), has a suggestion, one that echoes Donald Norman’s advice: “Ignore the demands of specific audiences and make the product work for anyone by focusing on the activity instead of the user.”
  • Indeed, if personas are used we don't need too much personal information. We also don't want to focus on all kinds of features. Rather the personas should be derived from needs and behaviour (what actions do users need). -- ArthurClemens - 14 Sep 2008

Analyzing the status quo

The list below looks like a premature list to me. I think we need to split the list in:
Yes, mostly brainstorming so far. -- CarloSchulz - 12 Sep 2008

• Hygienic factors like performance, translations (we all want that!)
• Factors that have more diverse impact on user behavior:
  • A. everyday basic workflow (edit, search function, dealing with attachments; getting system feedback/error handling)
  • B. advanced workflow (working with one or multiple plugins; creating small applications; working with access restrictions)
  • C. super-user (but less frequent) workflow (installing TWiki, building applications, customizing sites/pages)

Then we need to define how these 'typical' workflows could or should look like and where they fail/can be optimized/needs to be added, or which elements need to be in place.
-- ArthurClemens - 12 Sep 2008

Topics:

• What's already good?
  • customisability
  • powers users can use the browsers address bar as a "jump box" to access all twiki screens (edit/rename/attach/etc., webs and topics)
• What needs to be better?
  • find out as early as possible if permission for an op is denied
    • What is this? -- ArthurClemens - 12 Sep 2008
    • hmm, maybe if a user is allowed to perform an operation? We'll have to ask Crawford... -- CarloSchulz - 12 Sep 2008
  • use of asynchronous loading
  • ease of simple customisation (colours, logos, coarse position a la MTSkin)
  • editing
  • ease of use of WYSIWYG
  • performance
• What do we need to get rid of?
  • oops pages
  • to many customisation options
  • multiple edit options

Take a look at the competition

Not to play copycat, but to inform ourselves or get inspiration from.

• How do they deal with edit?
• How do other wikis look like (tools, navigation, etc.)?
• What kind of design patterns emerge in the wiki arena?

Outline our ideas

• take input from above
• try thinking out of the box, some crazy stuff
  • It is always good to think of the magic box: what if TWiki was a magic box that creates ...
• ...

Designing the new user experience

• Use input from above to draft storyboards and wireframes
• Facilitate development by visualizing concepts and implications for users
  • Discuss them within the task team and the twiki community
    • Goals? -- ArthurClemens - 12 Sep 2008
    • Goals of discussing this? Or what do you mean by "Goals?" ? -- CarloSchulz - 12 Sep 2008

Coding the new user experience

• A task team on it's own?
• Managed via current FeatureRequest process?
• We will help to define features in terms of user benefits.

Prepare for roll-out

• How to communicate / announce the new design Develop a plan to create buy-in from the community. Otherwise this team is bound to fail.
  • I think the plan is to openly communicate our ideas, the agenda, work product and stuff and encourage people to particpate in this process no matter if part of the UserExperienceTaskTeam or not. And of course discuss our work products with the community before they are declared finished -- CarloSchulz - 12 Sep 2008
• Keep people in mind who do not want their TWiki to change (regarding look and feel).

Discussion

No Discussion this time, action!

---

I found this gateway while cleaning up: InterfaceProject It list topics related to usability and user experience, and some old discussions.

-- RafaelAlvarez - 13 Sep 2008

Thanks a lot Rafael, Codev is indeed a funny place. You can bet that almost everything you might want to write down has been discused already (somewhere deep, deep down in Codev).

-- CarloSchulz - 13 Sep 2008

I found another topic that may be useful: CollaborationSituations

-- RafaelAlvarez - 14 Sep 2008

MichaelDaum, what do you think is needed to "rubberstamp" this task team. I had to stop contributing for a while to due busy times at work... not much input from others since then.

-- CarloSchulz - 08 Oct 2008

Rubberstamped. Not sure if that's it.

We should start with the status quo by first listing the standard use cases: e.g. installation and 1rst steps, administration tasks (add user, add group), editing a topic, uploading a document, pretty every topic action needs to be reviewed. Creating a new web is awful. Deleting a web even more. Bulkregistration is bad. Editing preferences on twiki, web, topic and user level is awful. Changing access rights is too geeky.

Then we have to review documentation in the TWiki web: does it describe what it says; is it actually helpful. All of the TWiki web is actually a big mess mixing up different stuff; we need to structure it; the current category system inside is no good.

AFAICS, the task team has to address much more than only the interface usability and look & feel.

I think most people on TWiki are really not aware how low TWiki scores. Therefore, we need to debunk some of the most itching parts using screenshots and arrows in a series of status quo documents. It is easy to say something is awful, but we have to communicate it clearly why and what's a better way to do it.

-- MichaelDaum - 09 Oct 2008

In brief, an expert review (heuristic evaluation) of current TWiki. Would fit into the "Analyzing the status quo" chapter.

-- CarloSchulz - 09 Oct 2008

"Rubberstamping" requires:

1. Statement of charter and powers, agreed with InterimGovernanceTeam (via Michael)
2. Next review date set and status flipped (in the form)

That's all, folks!

-- CrawfordCurrie - 10 Oct 2008