Ubuntu Touch : an emergency mode ?

When friends came home, I let them try UbuntuTouch on my Nexus7. First, I just said « use edges ».

They started and found easily the launcher, then launched gallery, then an image in full screen, and then… lost ! They were stuck on the image, tapping/swapping on the image as much/fast as they could.

I had to tell them « the toolbar is in the bottom edge and there is a back button ».

All this made me think : « what if… there was an emergency mode ? »

Here is a proposal ;-)


If you have ideas about other gestures that can be mapped to the « emergency mode », please tell me !

Ubuntu Touch : about the « Back » button

There is an interesting thread in the ubuntu-phone mailing list about the « back » button : https://lists.launchpad.net/ubuntu-phone/msg02260.html

Some early users are complaining that :

  • it’s not easy to discover (specially for new users),
  • it needs two taps

Several proposals have been made, but only described as text. I tried to make some proposals with more precise mockups :

1 – a « back » button as an overlay, with 2 variations


Pro : only one tap, very easy to discover
Cons : doesn’t respect the Ubuntu guideline : « no controls, just content »

2 – a back gesture


Pro : respect the Ubuntu guideline « no controls, just content », very similar to notification’s gesture
Cons : stil not very easy to discover

Finally, as each proposal is interesting while not being perfect, I think that Ubuntu touch may let the user decides which one he wants to use : it may be defined in settings :

The « back » behavior is implemented through :

  • a « back » button in the toolbar
  • a « back » button as an overlay
  • a back gesture from the bottom edge


Thoughts about Libre Office design process (part 9 : conclusion)

As a reminder, here is the list of all the articles :

In few words, the main ideas are :

  • the TDF should define a long-term strategy with a roadmap
  • the TDF should define rules to be sure that every part of the roadmap is executed (ie important functionalities are developed on time instead of developers working on non-important functionalities)
  • the TDF should have control over branding
  • the current design team has skills only in graphics, Visual Identity, not in User Experience
  • the current design team lacks some basic professional knowledge and behavior
  • the design process should be handled by a new team with proven skills in UX design
  • the design process should be completely enhanced to become professional, with interactions with others teams (devs, VI, QA, A11y…), use cases, guidelines, iterative process, prototyping, specifics tools and rules to use them, user feed-back and schedules

Consequently, subjects for « easyhacks » or GSoC with GUI should be designed before any work on code. Today, the implicit message is « Come in and code, we’ll check UX later« . It should be « Come in, help design/prototype and then code« .

I know that in FOSS world, there are mantras « release early, release often« , and « consider users as testers« . But, as LibreOffice  has millions of users, it’s not possible : LibreOffice must provide rock-solid and perfectly designed functionalities from scratch, from the ‘.0′ release.

Even if it is a strong criticism of the actual design process, it is also a constructive criticism, with proposals. And as I am pragmatic, I’m currently working on some ideas for Impress with these methods and tools. It started as a question on the ux-advise mailing-list (http://lists.freedesktop.org/archives/libreoffice-ux-advise/2013-March/001876.html). And I expect to have good results. Everything will be on the ux-advise mailing-list.

I hope TDF will hear my feed-back and provide an appropriate answer to that urgent problem. The future of LibreOffice depends on it.
If nothing is done about the design process, as a domino effect, all other parts of LibreOffice will have problems, and I really feel sorry for developers, translators, testers and users.


Addendum : As a proof of my fears, there is the last version of ColorPicker (https://wiki.documentfoundation.org/Design/Whiteboards/Color_Picker and http://ubuntuone.com/57jcpbGE2SGHXlzw1JjY2n) : while looking interesting, some parts show that nothing has been learned from the TemplateManager or previous ColorPicker :

  • what about use cases ? (the mockup is described as « explains everything » !)
  • will it be ok for all parts of LO ? Writer, Calc, Draw, Impress, Preferences…
  • they expect « themes », but is it really a planned feature ?
  • they expect to have « live preview » of colors : no one dev confirmed it is easy to implement (and it’ll be completely inconsistent with all other popups)
  • they expect to work with « mm » instead of « px », ie with resolution-independant-widgets : again, is VCL able to handle that ?
  • what about accessibility ?
  • did they prototype that proposal ? will users guess the workflow ? Will users understand the buttons ? Is it ok to have the « custom color view » in the popover ? or in a real dialog  or in a floating window ?
  • it was still designed drawn by just 3 to 6 people, without any other feed-back
  • Mirek just proposed some big changes, just 1 week before the theoretical deadline (http://listarchives.libreoffice.org/global/design/msg05729.html), a usual « best practice » of the current design team…
  • and so on…

About the template manager, there is some strong feed-back  (http://listarchives.libreoffice.org/global/design/msg05731.html) : most of those problems could have been identified with early prototypes. What a waste of time and energy…


Thoughts about Libre Office design process (part 8 : branding)

I also have a proposal for the branding process : branding should be done INTERNALLY : some contest may be started to receive ideas, but the processing, the creation and validation of the new branding/visual identity must be made internally and validated only by TDF members.

TDF members know what they want to obtain since they have clearly defined the objectives. As LO is used by millions of users, the visual appearance is essential and cannot be handled by non-professionals. TDF should not hesitate to pay for this specific task in order to have real professional visual branding. Thus this task will be performed efficiently in short time instead of weeks of polling.

As they answered on the mailing list, Charles & Italo should have said (instead of http://listarchives.libreoffice.org/global/design/msg05261.html and http://listarchives.libreoffice.org/global/design/msg05267.html) :

« we assume/take on our role of TDF Member and then decide :
– to stop the current poll,
– to work internally with designer & graphic artist, based on current proposals,
– to choose internally the branding for LO4 (via a poll for TDF members),

Everything will be done in few hours, and will be ok for LO 4.0.0 release. »


Thoughts about Libre Office design process (part 7 : schedule)

The most unbelievable part in the current design process is the total lack of schedule !

On the opposite, if we look at the dev process, the schedule is very well defined : https://wiki.documentfoundation.org/ReleasePlan and https://wiki.documentfoundation.org/ReleasePlan/4.1 and https://wiki.documentfoundation.org/ReleasePlan/4.2

This explains the latest problems :

  • the template manager was not completely designed, even 1 month before the release date
  • the branding for LO4 was started just weeks before the release date

We absolutely need to define planning/schedule in order to greatly reduce working in hurry.

As the hard freeze is defined 2 or 3 months before a release, here is my proposal :

  • UX and VI design should be complete at least 6 months before the release date
  • branding should be complete 3 months before the release date

Each team must prepare their internal schedule to respect theses deadlines. For example, UX design should be done 12 to 6 months before a release date : today (april 2013), we should be working on LO4.2 UX design, until july 2013. And we should work on mid-term and long-term design for 4.3, 4.4 and even 5.x releases.

During the last 6 months before the release date, the UX team should only work on details/questions from devs, about problems that may appear during the finalization of features.

Thoughts about Libre Office design process (part 6 : tools & workflow)

My proposal covers also the tools for the design process.


Here are different tools to create UX mockups :

  • A lot of companies use Balsamiq, but  there is no more free (0$) version
  • in order to « eat our own dog food », we could use Draw + gallery extension to provide basic objects. But the problems are :
    • very time consuming to create a new gallery with all widgets
    • widgets will be simple shapes and it will not  be easy to make variations for UX mockups (ex : simulate data in a table)
  • I recommend Pencil 2.X (http://pencil.evolus.vn/) :
    • Pencil is developed to create mockups, period.
    • it’s free (0$ and open source) and x-platform
    • there is already a list of widgets specialized for creating mockups
    • optionally, we can extend widgets to have specific LO widgets, although this is not obvious
    • I just found a bug : when you drag an object from the left column, sometimes it is not created in the main panel. The workaround is to drag the object *slowly* when you enter the main panel !


Rules for Mockups

A great tool is nothing without some rules to produce good results.

  • export as pdf/svg/png
  • each mockup should describe one use case
  • As a basic rule for layout, each mockup should contain :

- list all available states
- list all transitions between states, with the associated rules

here are some good examples of mockups :

http://wiki.openoffice.org/wiki/User_Experience/DocumentCheck (by Christoph Noak)

https://wiki.documentfoundation.org/Design/Whiteboard/Calc_Range_Names (by Christoph Noak) and the associated image : https://wiki.documentfoundation.org/images/e/e2/DesignTeam_Mockup_Calc_RangeNames.png

http://design.canonical.com/2013/03/app-patterns-applied-calculator-key-journeys/ and http://design.canonical.com/2013/03/app-patterns-applied-clock-key-journeys/ (by Canonical). They are very interesting, because :

  • they have simple use cases : « start… », « view… », « delete… », « add… », « change city… », « set an alarm… »
  • they describe the behavior even for every keystroke !



They must be easy to code, easy to deploy. Today, the obvious choice is HTML5. In order to speed up, we can add jQuery, jQueryUI (?) Maybe ExtJS, because it provides some widgets similar to LibreOffice (tabs, panels, dialogs…)

Another solution would be QML. The only problem is that it requires some software to deploy (qmlscene ?)

Bitmap mockups (for VI only)

  • Gimp (export jpg/png)


Thoughts about Libre Office design process (part 5 : proposal)

My proposal for the design process is in 3 steps :

  • Step 1 and Step 2 are executed at a regular interval, every year or two years,
  • Step 3 is executed for every design subject.

STEP 1 : Goals

The TDF board/ESC should define goals/objectives/roadmap for future versions (see further down for complete description) : what must be enhanced/modified in LO ? what must be added/removed in LO ? what should be the focus of future versions ?

All those goals/objectives/roadmap must fit in a global, long-term strategy.

Then :
with UX team, they define UX goals/roadmap,
with VI team, they define branding, aesthetic goals/roadmap.
with devs, they define technical goals/roadmap.


STEP 2 : the materials

Then UX team starts process :

  • Uses inputs :
    • the UX goals from TDF (« the mountain »)
    • infos from users, stats about usage (« how do they use LO », « what do they like/dislike », « what do users want/expect »…)
      This is a parallel process that can also be used to identify parts of LO that need urgent modification (bottleneck/outdated/papercuts…). As it is based on surveys and user feedback, it’ll take time to have results, but that part must be started asap (the results may modify the Guidelines).
      In ux-advise ml, someone is trying to analyze tracking data for OOo3.1 (http://lists.freedesktop.org/archives/libreoffice-ux-advise/2013-February/001828.html). Maybe the extension that recorded these data can be adapted and  integrated into LO4 ?
  • Produces outputs :
    • tenets (« the path to get to the mountain »)
      They are rules to follow when designing for the next 1 or 2 years.
    • schedule of UX works :
      • short term : ex « papercuts » or « easyhacks », next release,
      • mid term (1 or 2 years),
      • long term (> 2 years),
    • Interface Guidelines to simplify future coding : a kind of FAQ, or a list of « HowTo layout… ». The first version will be created asap. And then, it’ll be enhanced after few months of design iterations.
      The Guidelines can be defined for each LO version : Guidelines for LO5 may be different from LO4 ; they can be defined at the very beginning of dev, during/following vcl evolutions.
      Devs are asking for that : http://lists.freedesktop.org/archives/libreoffice-ux-advise/2013-February/001826.html
    • a list of use cases, or a list of main actions/workflows


STEP 3 : Iterate for each design

for each subject :

  1. ask one dev to be a participant in the validation part of this subject. Depending on the complexity of the subject, ask also one QA and one A11y member.
  2. define the context :
    • With dev(s), evaluate what is technically possible
    • define a schedule, with first estimation of release date (linked to the standard release plan of LO)
  3. create proposals/mockups
  4. tests proposals/mockups against tenets
  5. create prototypes for best proposals/mockups
    A prototype must be live : it must react to mouse&keyboard and show the precise expected behavior
  6. evaluate prototypes (usability test by some users, tdf members, devs, QA and A11y)
  7. loop to step 3 until a prototype is ok :
    validated by design team and dev
  8. validation by TDF members/board
  9. ask devs to code (c++) the prototype


  • mockups *must* be in wireframe and made with a std/common tool (cf part « tools »)
    (only the VI team will create non-wireframe, screenshot-like mockups)
  • devs must *never* add/modify UI without a validated prototype (except for small UI changes, where a review/validation from the design team would be sufficient)



Examples of goals/roadmap by TDF

It defines the vision of next releases of LibreOffice by TDF.

It can contain several parts :

  • specific priorities / roadmap

« in the next X years, we want to modify part A, B and C »

The TDF should find a way to have some actions flagged as mandatory : they have to be done for the x.y release. For example, TDF could define a list of bugs that have to be closed for each release. TDF could define some priority tasks : developers should work on nothing but those tasks (It’s just a suggestion as I don’t know very well the way it works today ; it seems difficult to say that to volunteer developers, but TDF should really find a way to do that).

  • UX/UI goals

TDF may explicitly define some UX/UI goals to make some necessary design choices : « In the next X years, we want to switch to a new UX paradigm« . or « we want to integrate the Symphony sidebar« . Or « LO will have a different/identical UI between desktop and tablets« .

  • technical goals

TDF may explicitly define technical goals : « LO must work on phones and tablets with screen sizes from 5′ to >20′  » or « LO must support platform Y » or « LO must integrate the new technology Z« .

  • general goals, example :
    - about targeted users : beginners ? advanced users ? corporate users ?
    - about general functionalities :

    • LO will have to have strong functionalities in desktop publishing/scientific calculations/business analysis…
    • LO will focus on some functions needed for companies (ex : easy deployment/configuration over network)


There are already a lot of referenced tasks to be done, the TDF « just » have to say how to select, complete and prioritize them (or some of them) :

Thoughts about Libre Office design process (part 4 : teams)

My proposal is to create a new design team for UX design only. There will be :

  • the current team for visual identity, graphics, artwork, branding material
  • a new one for UX design

The UX team must have core members, with proven skills and knowledge in UX design, and be certified by TDF. The core members act as moderators to prevent unskilled members and out of scope proposals (and waste of time). The remaining question is how the core members could be certified by TDF. It could be a process similar to the definition of reviewers of code.

And the core members of one team can not be core members in the other team because it’s impossible to have strong skills in UX and VI.

All this might look hard and even non open source, but I think it’s the necessary foundation upon which we can build strong teams.

On the technical side, each team must have its own mailing-list, wiki space.

Of course, they have to communicate, just as QA team, Translation team and Dev team communicate.

Let’s be clear : it’s absolutely not a personal attack nor an insult. It’s just « let’s build teams with coherent skills« . I can say that because I know my skills and you can tell me « Michel, you have no skills in graphics or VI (visual identity) » because it’s true.  With my experience (I’ve been writing software with GUI for 20 years, with good user feedback), I can tell you I have some good skills in UX (more practical than theoretical), and not in VI. And I dare say that the current design team has only skills in VI and not in UX.

Thoughts about Libre Office design process (part 3 : analysis)

Someone has to say it loud : the current design process is very weak, and lacks some professional behavior :

  • No roadmap

Papercuts are ok, but they are only short term. LO needs short term AND mid term AND long term design projects. Sometimes, new proposals may override previous work because of lack of roadmap. For example, there is a new proposal to completely change the new template manager to make it handle the start screen, just 1 month after the first release (http://lists.freedesktop.org/archives/libreoffice-ux-advise/2013-March/001882.html).
It clearly shows a communication problem in every case :
- either the template manager is designed to handle the start screen, but only few people know that ;
- or the template manager should have been designed to handle the start screen, but not enough communication/exploration during design process ;
- or the template manager does not have to handle the start screen, but the design team never said it.

People need/ask for a roadmap : http://listarchives.libreoffice.org/global/design/msg05303.html

  • No clear direction

First, for each subject, the design team receives a lot of completely different proposals that make it difficult to handle. Some of them can be bizarre because they have no UX foundation (http://listarchives.libreoffice.org/global/design/msg05707.html). It’s very difficult to keep LibreOffice UI coherent. After some months, LO will lose its consistency (some parts will behave like iOS, others like android, others like Winphone…)

Secondly, the rules to select a proposal seem to change from subject to subject. Maybe it means that there is no validation rules ? When we read mailing-list or chat log, It seems that most of UI decisions are taken with arguments like « I prefer… » or « I think it’s better… » (most of logs in https://wiki.documentfoundation.org/Design/Meetings). And those decisions are taken by very few non-professional people (sometimes less than 5 !) while they change UI for millions of users !

  • No guidelines

Devs are asking for guidelines for basic design questions : http://lists.freedesktop.org/archives/libreoffice-ux-advise/2013-February/001826.html :

« Is there any style guideline concerning items greyed out in  UI? » 

  • Lot of energy and time wasted :

First : endless hours in chat/mail answering the same questions for every subject :

« do we target desktop users ? tablet users ? » « do we copy iOS/Android or create something else ? » « How to layout items for that common behavior ? » « Do you take care of that special use case ? »

Secondly : the global bad process wastes everyone’s time. As we are mostly volunteers, it’s very bad (« we » means all people involved in LibreOffice : devs, designers, translators, testers…). And it prevents new volunteers from joining.

  • No feedback with users

First, there is currently nothing that allow design team to have informations about users : who are they ? what tool do they use often ? what do they like/dislike in LO ? what are their papercut ?

Secondly, the design team takes decisions about design without any user testing or prototyping. These two important notions are not part of current design process (https://wiki.documentfoundation.org/Design/Meetings/2013-01-05, [21:24 --> 21:30]).
IMHO, this is the weakest, non-professional part of the current process. It typically looks like the myth of the genius designer (http://www.nngroup.com/articles/the-myth-of-the-genius-designer/).

  • Design team lacks some basic knowledge about code, coding :

This complexifies the relation with devs, or makes some proposals useless. The best example being the color picker (without asking devs, the team supposed the new color picker will provide live preview).

The last proposals (template manager, color picker) are made only through static images and lack some important informations : input datas, output datas, event workflow, different use cases, special values handling, error handling…
Here are some old proposals with minimal expected informations : https://wiki.documentfoundation.org/Design/Whiteboard/Calc_Range_Names

Or devs must take some decisions themselves while coding, because the design was not coherent with code or incomplete. The example is when Cedric had to change (in hurry!) how the new template manager handles opening a folder by removing the notion of overlay (http://lists.freedesktop.org/archives/libreoffice-ux-advise/2012-December/001671.html and you can extend to the whole discussions during december 2012 in this mailing-list : thread http://lists.freedesktop.org/archives/libreoffice-ux-advise/2012-December/001603.html and thread http://lists.freedesktop.org/archives/libreoffice-ux-advise/2012-December/001615.html and thread http://lists.freedesktop.org/archives/libreoffice-ux-advise/2012-December/001665.html).

  • Accessibility has not enough support


  • QA

With bad design and development in hurry, do you imagine the state of QA ?

  • Bad tools, not efficient

The best example being using a mailing list for a poll. Or creating mockups with Gimp instead of a wireframe tool.

  •  No UX skills/knowledge

It’s really the most important problem, and the most difficult to be clearly expressed.

Today, the design team theoretically handles the following areas :
(from http://www.libreoffice.org/get-involved/ux-visual-designers)

  • user experience (UX)
  • visual identity (VI)
  • accessibility
  • user support and training

The fundamental problem here is that the two first points are mutually exclusive : they work on the same subject (LibreOffice UI) but with two different and opposite point of view (pov) :

  • the UX analyses the UI with a dynamic pov : events, workflows, interactions, number of click, number of keystroke…
  • the VI analyses the UI with a static pov : perception of colors, perception of icons,  perception of space between elements, fonts, font-size, precise layout of elements…

And they require completely different skills :

  • the UX needs engineers, scientists
  • the VI needs artists, graphic artists

When we look at the proposals, the discussion in the design team (irc, mailing list), it seems that most of participants have skill only in Visual Identity. The most visible symptom being that all proposals are made as real screenshot while all professional UX designers always make proposals as wireframe. And that there is no use case, no scenario, no event workflow, nothing about UX.

This is also the case for one of the most known proposals : the citrus ui. it’s a nice proposal from an artist. But the contained ideas can’t be processed because it’s light years away from being a UX designer proposal. So it is disappointing that this proposal is often seen as the future UI of LibreOffice and that his creator is leading the design team.

  • Some problems start to appear, ESC feed-back

Hopefully, some devs are starting to realize : http://lists.freedesktop.org/archives/libreoffice/2013-March/047676.html (go to part « Learning lessons from the template manager story »). It’s a very simple list, but so significant !
But, nothing else is suggested to correct those problems.


In conclusion, all this is very annoying for the future of LibreOffice, because it is one of the foundations of LibreOffice and there is a lot of expectations from users. If you compare with the dev process, it’s very professional : versioning, code review, daily builds, automatic testing, bibisect…

The design process needs to be very professional too.

Thoughts about Libre Office design process (part 2 : other projects)

This article is a list of references, links about design process. My future proposals are based on work and reflexions made by specialist about UX design. (bold emphasis are mine)

Design process by Nielsen


The only generalizable advice is this: rather than rely on your own best guesses , base your decisions on user research :

  • Conduct field studies and task analysis before deciding what your app should do.
  • Paper prototype your initial ideas before doing any detailed design — and definitely before wasting resources implementing something you’d have to change as soon as you get user feedback.
  • Design iteratively , conducting many rounds of quick user testing as you refine your features.

[...] My view is just the opposite: no one should be allowed to work on an application unless they’ve spent a day observing a few end users.

(Whatever you do, at least promise me this: Don’t just implement feature requests from « user representatives » or « business analysts. » The most common way to get usability wrong is to listen to what users say rather than actually watching what they do . Requirement specifications are always wrong . You must prototype the requirements quickly and show users something concrete to find out what they really need.)


It has long been recognized that user interfaces should be designed iteratively in almost all cases because it is virtually impossible to design a user interface that has no usability problems from the start. Even the best usability experts cannot design perfect user interfaces in a single attempt, so a usability engineering lifecycle should be built around the concept of iteration.

Iterative development of user interfaces involves steady refinement of the design based on user testing and other evaluation methods. Typically, one would complete a design and note the problems several test users have using it. These problems would then be fixed in a new iteration which should again be tested to ensure that the « fixes » did indeed solve the problems and to find any new usability problems introduced by the changed design.




And to stay humble as designer :




Joel Spolsky

« The Joel Test: 12 Steps to Better Code »

specially for design :
#7 : do you have a spec ? (design must be complete before coding)
#9 : best tools (for design also)
#10 : do you have testers ?
#12 : hallway testing

A serie of article about UX, design and users :

Controlling Your Environment Makes You Happy

Figuring Out What They Expected


Affordances and Metaphors

Consistency and Other Hobgoblins

« designing for people who have better things to do »

  • Users don’t read stuff
  • Users can’t use the mouse
  • Users can’t remember anything

« the process of designing a product »

  • Invent some users
  • Figure out the important activities
  • Figure out the user model — how the user will expect to accomplish those activities
  • Sketch out the first draft of the design
  • Iterate over your design again and again, making it easier and easier until it’s well within the capabilities of your imaginary users
  • Watch real humans trying to use your software. Note the areas where people have trouble, which probably demonstrate areas where the program model isn’t matching the user model.

« Top Five (Wrong) Reasons You Don’t Have Testers »
and specially the « 3. My customers will test the software for me. »


Openerp v7

They wanted to have metrics about usability enhancements between v6.1 and v7. They created a javascript tool to record some simple values : nb. of clicks, the distance between clicks, the pixels to move and the keystrokes involved.
(and the direct link to the video : http://www.youtube.com/watch?v=Ar8lobad1aE)


Canonical has a strong design team. Their last work had an incredible impact : Ubuntu Phone OS. In their blog, they explain how they work :

And Canonical created a special website for the community to participate in the design of apps for UbuntuPhone :


It is very well organized :

  • predefined rules and workflow to create proposals
  • each app has
    • User stories
    • Functional requirements
    • List of views that need a design
  • there is a dedicated balsamiq website :
    • design proposals have to be wireframe
    • common tool for all proposals
  • but their Interface Guidelines are still a work in progress

And in a very recent video hangout (http://www.youtube.com/watch?v=JLAVx91Uhmo), they explain that their current proposals are in a pseudo-wireframe : it’s not the final UI (some colors and other visual details will change).

Design process at Google

An excellent article about the recent design changes at Google :


And a video about one member of the design team :

Apache OpenOffice

TDF should look at Apache Open Office as a very strong competitor : if LibreOffice doesn’t prove that his UI evolves correctly, some distros may switch back.
Example : « Fedora To Look At Reviving Apache OpenOffice » (http://www.phoronix.com/scan.php?page=news_item&px=MTI4ODI)

The wiki page of AOO design is clear, structured and very professional (http://wiki.openoffice.org/wiki/Apache_OpenOffice_User_Experience).
There is everything we expect from a design team of such a big project :

  • precise list of datas about users/AOO
  • precise list of all tasks/activities needed to cover design process
  • research
  • design
  • evaluation of design proposals

Even if they seem to have a slower speed, the strong organization of design process will be visible in mid and long term : they’ll provide regular, stable, tested and good UI evolutions. And I guess those evolutions will not need modifications after their public release.


An example of simple usability test, but with tremendous feed-back : http://openthedesign.posterous.com/usability-test-gnome-character-map


Microsoft Office

The video about MS Ribbon history :

What is very interesting is the process used to do that work :

  • UI goals : « the mountain where we want to go »
  • Design process :

- research
- design tenets : « the chosen path to go to the mountain »
- prototypes
- evaluation