Revision as of 22:38, 13 May 2009

Design Proposal [Add Proposal Title]

The following design proposal is part of the collection of design proposals for “Accessing Functionality”, which is part of Project Renaissance.

Summary and Status

For a complete description, please download the pdf file : Media:Proposal_impress_ui_renon2.pdf‎.

The fundamental idea is to focus on user's needs, specially the type of document and the associated tools.

Depending on the type of document I work, I need a subset of the tools available in OOo.

But OOo proposes only basic types of document : word processing, spreadsheet, slideshow, drawing...

OOo should propose more detailed type of documents, for example :

Writer

• 1 page simple letter
• business document
• scientific document
• Thesis
• mailing, labels, envelopes
• publishing
• web
• …

Calc

• financial document
• scientific document
• Canvas/ Grid – Editor (cf http://wiki.services.openoffice.org/wiki/)

Then OOo should propose associated tools in a very simple UI : the idea is to show only tools on demand through toolbars.

Each toolbar has few elements about a common subject. Tools shared by every documents would be macros, forms, media, drawing tools... For example, tools for Writer would be mailing, versions, indexes, headers & footers...

The element are actions, not properties.

There is a main toolbar for each document : she contains the basic tools for the document.

The user can add, remove, move, organize (horizontally, vertically, in tabs or beside) the toolbars (except the main).

An example of main toolbar with buttons shared by all types of documents :

An example of UI with several toolbars reorganized :

Note the “Click to add new functionality”

Note the properties panel : it's an inspector :

• it is context-sensitive : its content change according to the selected object
• his content allow the user to change the properties of the selected object

As there is a hierarchy of objects, the properties panel show every properties of every object in the hierarchy.

For example, in Writer, if we usually have the hierarchy : Document/Section/Page/Paragraph/character, the properties panel looks like :

It is very common in others software.

I propose a variation : the properties panel show properties of only one object. We provide the user a way to select every object of the hierarchy : a “breadcrumb”. For example :

Proposal for Impress

Needs

From my experience with Impress, and with what I heard from other users, I suppose that most needed features are :

• add slides
• change background
• add images /videos
• add some simple transitions between some slides

Remarks on actual Impress

Here is what I find difficult with Impress :

• some terms are difficult to understand and/or are incoherent :
  • the most important example is “master slide” : in the task panel, it's called “master slide”, and in the “view” menu, it's in a group called “mask”...
  • the other example is “slide layout” : beginners don't find that very obvious
• the “Insert” menu is very complicated and has too many sublevels :
  • to insert a spreadsheet, you have to select “Insert” then “Object”, then “OLE” and then select “spreadsheet” from a panel !
• Some very disturbing behavior (should define a bug report ?) :
  • when you modify a mask, if you clic on the tab “handout”, what really happens ?
  • when you modify a mask, if you clic in one “master page” or “layout” in the “tasks” panel, what really happens ?
• for beginners, it's not obvious that you can change default text size with the “mask”

Main toolbar for Impress

The first idea is to use terms “Background” and “Foreground” instead of “master/mask” and “layout”.

Then one button would give access to the backgrounds, and another to the foregrounds :

Status: Request for Comments

Mockup

This is the default screen

Update : here is a more precise version of the default screen : the toolbar has a name and a link to add others toolbars there is a "configure" button

In my pdf document, I propose 2 ways for adding new toolbar. And I let the reader choose which one he prefers.

In this wiki page, the mockups must avoid ambiguity, so I update them.

Initial version :

Detailed Description

This space is reserved for the detailed description of your design. Add anything you might find important for us to know. If you don't have any clue what this might be, then you will find some topics below.

• Describe dynamic behavior: The mockup above is something static. To better illustrate what will happen on the screen, describe what actions would be taken by the user and what would appear on screen.
• Explain the rationale and assumptions: If you decided to go for a certain concept, then please explain why you chose this.
• Highlight particular design ideas and alternatives: A concept usually incorporates many individual ideas. If you think certain ideas are really unique, then please highlight them. And if you think that there were other really good ideas which could not be implemented at the same time, tell us about them.
• List issues and open questions: Please list any issues you are aware of and open questions. Do not worry if your proposal or concept isn't perfect. If you have discovered any stumbling blocks or worries, then please provide this information right from the start. Maybe the team can help find answers/solutions.

Additional Material and Mockups

Please share everything you might think is important to better understand your proposal. Perhaps you also have other ideas which are not directly related to “Accessing Functionality”? You might add further documents, Internet links, or additional mockups - e.g. showing a workflow or different states of the software.

Author or Team Working on This Proposal

Comments

Your space :-)