From Apache OpenOffice Wiki
Revision as of 21:32, 6 December 2008 by JaronBaron (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Quick Navigation


Renaissance Logo Concept

Here is a logo concept I came up with for Renaissance. Since the renaissance period was marked by enlightenment and by renaissance men I chose to base the design off of a Renaissance period font. Da vinci combined artistic and engineering concepts in a lot of his designs and so I added the square/circle ratios seen in his Vitruvian man. My goal was to create a logo that looked like a schematic (since we are in the design project stages) but combined the artistic beauty of Renaissance period writing. The seagulls carry the OOo theme into this logo.

The font is a free font, and the files were made in Inkscape. Anyone who wants a copy of my original Inkscape file can email me at jaronbaron @ gmail (d0t) com.

RenaissanceLogo userJaronBaron 1.png

Design iteration 1

RenaissanceLogo userJaronBaron 2.png

Design iteration 2 - with vitruvian man and sharp corners on letters for a more handwritten look (though conceptually shown on "n"'s, is not complete).

RenaissanceLogo userJaronBaron s1.png

Short Logo

User Intro

I am currently a new member of the User Experience Community, and will add more to my user page in the future.

Reach me at JaronBaron @ gmail (dot) com

I am primarily interested in the following topics:

- New UI design

- New user experience

- Graphic design of UIs, such as icons, logos, etc...

- Organizing the current rules for designing OO.o 2's UI and creating rules for the future UIs

I would like to see user experience compatibility between the different OO.o suite products which I believe will be beneficial both in programming and maintaining OO.o but also gives the user a continuously intuitive experience. That is to say interacting with a table in Writer should be the same as in Calc.

My Thoughts & Ideas, My Grand Scheme for the UI

I believe for OO.o to be successful we must adopt our own new and unique approach to the program layout and interface. After a long analysis of the already existing office suites, I believe none to be sufficient. Microsoft Office is a complete UI disaster, and iWork has taken humongous strides towards redefining the next generation of office suite but has some UI problems and suffers from no high level content. All office suites still fail to create a user friendly manipulation and application of object styles, such as text styles, page templates etc...

Please feel free to contact me with all criticisms, recommendations, changes, and comments. I will change the info below to reflect said recommendations. Thanks!

Later I will add my actual preliminary GUI design; some refinements still need to be made.


I want to start off by talking about office suites in general.

What is the difference between the different programs in office suites?

Answer: Nothing (or rather it should be). The objects contained within the different suites are exactly the same, and in theory should behave the same for a user consistent experience. However, most fail to operate this way. I mean to say that for example, the interface to modify vector graphics should be the same in Writer as it is in Draw. Creating a document with tables and text should be as doable in calc as it is in writer, but if the user wants lots of tables then Calc should be their starting point, or if the user wants lots of text, Writer should be their starting point. The default tool set available in Calc should be designed for a document that contains primarily spreadsheets, and in Writer for a document that is primarily text, but the tools in Writer to modify spreadsheets should be the same as the tools in Calc etc...

What is in an office document? Answer: The following objects: Pages, Text Boxes, Text, Raster Images, Vector Graphics, Tables, Media, Notes, Hyperlinks/Reference Text

An office document contains only these basic items which the user manipulates. However, in many office programs interacting and formatting the objects is confusing. Sometimes properties that belong to one object are assigned to another. The average user might not be able to identify the fundamental objects and tasks they perform because the means by which they perform tasks doesn't follow the basic logic behind the office document design.

How do we remedy this? Answer: An object and view based UI design that focuses the user's attention on the tasks relevant to the object with which they are currently interacting.


An Object Based Design

Object oriented programming comes from the natural urge to classify and order things. In office programs the UI approach should be as intuitive to program (I mean in terms of objects) as it is for the user to navigate. Below I have written a practical list of the core objects within office suites and some of their dependents. The list was made with a focus on document programs (aka Writer) so please keep that in mind, especially the page object which contains objects relevant only to traditional text documents.

  • Pages
    • Pre-defined text boxes - These might change based on page "style"/template and could have content dependent on the current document section (this was written specifically for writer)
      • Body text box (free form document writing has no need for body text, ex: newspaper-articles don't wrap from page to page, or might even pages)
      • Headers/Footers/Siders (siders would be a new concept. its applicable to documents with things like numbered lines)
    • Section or Page Style Breaks (normally things like line breaks are under the page category, but that is not appropriate since breaks effectively limit the writing space within a body text box not a page. Also, currently margins are used to define body text and headers/footers instead of limiting the usable space within a page)
    • Layers (All documents benefit from graphical layers, ex: watermarks on simple text document)
  • Text Boxes
    • Text - with defined Text Wrapping (wrapping text from one text box to the next, such as body text from page to page, or a newspaper article that starts on page 1 and ends on page 5)
    • Columns (normally, inappropriately assigned as a page object)
    • Breaks (line, column, section, "page" breaks, since page breaks basically restrict the use of the remaining text box space and are only relevant for linked text boxes, "page" is a misnomer)
    • Footnote space (this is not a page property since the footnote stays with the text reference, which, if it changes pages, moves)
  • Text - I chose not to differentiate between characters and paragraphs as all text effectively has both and since a paragraph is essentially only the characters between two next line characters
    • Characters
      • Special Characters
      • Figures as Characters (I assume this is relevant mostly for lists but likely has other uses)
    • Lists
      • Bullets/Numbering - local list (a simple list or outline)
      • Sections - global list (defines arrangement of document, even text styles, based on sections)
    • Paragraph formatting
  • Tables - I differentiate between tables and spreadsheets because they serve very different purposes but spreadsheets need to be incorporated in Writer for higher level end users that would benefit from cell dependencies and functions. Incorporating the ease of tables with the functionality of spreadsheets is difficult. Should they be separate objects or can they be combined? I believe they should remain separate.
    • Simple Table - aka the table object in Writer (tables that contain and organize any/all objects, Ex: a table with simple hand written text, a table that organizes multiple subfigures but is a single figure and has a single caption)
    • Spreadsheet, aka the table in Calc (tables that have a local referencing system for functions)
    • Captions
  • Figures
    • Canvas - A space designated for a figure within a document, it can be a placeholder. (I use canvases since the following objects can be intermixed within any given figure, ex: a picture with an arrow, however the user will likely identify the figure as one of the following, even if subconsciously)
      • Pictures - raster image/picture
      • Charts - image based on spreadsheet data
        • Data Spreadsheet - same as spreadsheet object but is used to create the chart. Since charts are OO.o created vector objects they are scalable unlike a copy pasted raster image of a (Access to this within Writer would be useful for scientists among others, ex: Someone needs to change a single data point but doesn't want to have to copy paste
      • Drawings - vector-based graphical diagram/drawing
    • Captions
  • Vector-based graphic objects - these are "Shapes" (this object is different than a figure. This could be within figures, serve as a decorative page border, or could be a "figure as a character" for, for example, customized bullets)
  • Raster images/pictures (this object is different than a figure. This could be, within a figure, a "figure as a character" for customized bullets, or a company logo within the page template in a professional letter)
  • Media (These categories are completely different but I have no experience with using them in office suites. However these are of key importance to the future of incorporating web compatibility in OO.o 3.)
    • Movies
    • Sounds
    • Animation/Flash/interactive web content
  • Links/Smart text/References/hyperlinks
    • Bibliography/Literary/Scientific references
    • Object references (footnote, figure references, table references etc...)
    • Text references/Bookmarks (ex: a link whose text is the current section title and takes you to the beginning of the section)
    • Web links
  • Fields - (Like the customized interactive objects useful in creating templates or editable forms, ex: a space for the date that must be in the format dd/mm/yy)
  • Notes/Corrections - text or object metadata that tracks changes or allows the user to add a comment.

There may be more kinds of objects or a better way to categorize these objects and I am constantly refining the list.

How the Page Object Would be Different in Each Suite Program

I think the major difference between the different office suite programs would be in the definition of a page and the default view.

  • Calc - the page should be able to readily contain multiple tables, text boxes and figures/charts.
  • Impress - like in Writer, the page would have different pre-defined text spaces for titles, lists, and figures, the arrangement of which being equivalent to the predefined page templates already in OOo 2.
  • Draw - the page would likely be blank with no pre-defined objects.
  • Equation - not applicable as this shouldn't be a separate program and needs a humongous overhaul.

Object based "Views"

Incorporating object contextual views really takes advantage of contextual workspaces to streamline the user experience for each individual task. Views can also seperate specific tasks for each object, ex: Layout View is where the user places a figure, Figure view is where the user edits the actual figure. Each view serves a separate task in the creation of the figure, each with its own set of tools.

  • Page Layout View - General purpose view that allows the user to write text in the pre-defined text boxes or create their own text boxes, place & size other objects, and format page properties.
  • Page Design View - This view restricts interaction with the main body text as its purpose is for the user to create graphics objects, for creating and linking text boxes, and controlling complex text wrapping. This view is more helpful for complicated freeform layouts, such as a school newspaper.
  • Text View - This view allows the user to edit and organize the written text without worrying about layouts. This view would have added capabilities for sectioned documents for easy navigation and text style application.
  • Figure View - This view allows the user to easily navigate and format the document's figures. This view's tools are designed around vector and raster graphics manipulation. It also allows the user to interact with the spreadsheet data in Calc charts or create a spreadsheet chart directly within Writer so that the user may easily edit points and formatting on charts. This view should function similar to the main view in Draw.
  • Table View - This view allows the user to navigate and format both the simple tables and spreadsheets. This view functions similar to the main view in Calc for spreadsheets but would function differently for simple tables.
  • Equation View - Organizing equations is an annoying and difficult task in current office suites. This view allows the user to organize and create equations, and set formatting and equation numbering options. While I don't see the purpose in having a separate program for equations, aka Math, this view would in theory look similar to the main view in Math; the relevance of Math should be discussed later.
  • What else? - Integrating the remaining objects, especially references, is a difficult task. A separate view for references may be useful but I haven't thought about this in significant detail yet.

Why Objects and Object based Views?

  • Easy inter-suite program object transfer
  • Consistency in experience
  • Contextual menus can be intuitively designed around currently selected object - This isn't a new concept, as object selected contextual menus already exist.
  • Object trees would allow users to organize their objects - As is the case in many engineering programs, object trees allow the user to see a list of objects and organize them.
  • Potentially reduced program development time and reduced physical space of OOo? - Since the object contextual menus could be the same in all programs I imagine there should be a reduction in the size and development time of OOo. This is just conjecture as I am not a computer scientist.
  • Object contextual UI "views" can streamline the user experience for each object they interact with - Incorporating "views" that have completely different contextual menus and UI designs that are streamlined for each object type will allow the user to customize the interface for each object type separately. For example, a user is writing text and needs to input a figure. By switching to figure view, the user's workspace transforms into a space designed for vector graphics, with grids, and a tool set designed around vector graphics. When the user switches back he/she has no need for those tools any longer and can focus once again on writing and formatting text.
  • No fuss template changes and easy object replacement - With well defined objects, switching out a graph or table while maintaining formatting could be made as simple as a few clicks.
Personal tools