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

RULES :

  • 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) :