User:JaronBaron

From Apache OpenOffice Wiki
Revision as of 04:59, 26 June 2008 by JaronBaron (Talk | contribs)

Jump to: navigation, search

ux-ooo-logo-rgb-129-61.png

ux.openoffice.org

Quick Navigation

Team

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... I have posted this on my page for right now since these are my opinions and an objective system for diagnosing pros and cons of UIs should be considered before posting on a new page.

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

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


Intro

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 the spreadsheet program should be designed for a document that contains primarily spreadsheets, but the tools in writer to modify spreadsheets should be the same.

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.


PLEASE DOWNLOAD THE GUI DESIGN AS DRAWN IN OOo Draw FROM THE FOLLOWING WEBSITE:

<Will likely send out the file via email, please feel free to contact me for a copy>

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, and might even skip 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. Margins limit 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
    • 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
    • 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 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, exs: 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 - drawn 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, for example, customized bullets, or a company logo 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 development in OO.o 3.)
    • Movies
    • Sounds
    • Animation/Flash/interactive web content
  • Links/Smart text/References/hyperlinks
    • Bibliography/Literary/Scientific references
    • Object references (footnote, figures, tables... ex: A figure hyperlink such as Fig. 1, where the number changes based on figure number order and clicking the words take you to figure 1)
    • 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 - end user interactive objects. (These would be customized interactive objects useful in creating templates such as those used to make 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 is simply blank with no pre-defined objects.
  • Equation - not applicable as this shouldn't be a separate program and needs a humongous overhaul.

Why Objects and Object base 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.

Proposed User "Views" (for writer)

Incorporating object contextual views really takes advantage of contextual menus to streamline the user experience. Additionally, views allow the user to separate tasks for an object. For example, the page layout view allows the user to define the size and placement of a diagram but the figure view is where the user edits the content of the diagram. Each view serves a separate task in the creation of the diagram, each with its own set of tools for completing the tasks.


The page pane in OOo draw is a good example of an object pane. It shows each page and allows the user to navigate through all the objects (in this case pages). For the following views the object in parentheses is the object within the object pane.


  • Page Layout View (Page) - General purpose view that allows the user to write text in the pre-defined text boxes or create their own text boxes, place other objects, and format page properties.
  • Page View (Page) - This view restricts interaction with the main body text as its purpose is for the user to create graphics objects and for the purpose of creating and linking text boxes, and controlling complex text wrapping. This view is more helpful for complicated freeform layouts.
  • Text View (Pages/Sections) - This view allows the user to organize the actual written text without worrying about layouts. This view would have added capabilities for sectioned documents for easy navigation and text style application.
  • Figure View (Figures) - This view allows the user to easily navigate 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. Excluding the chart functionality, this view should function similar to the main view in Draw.
  • Table View (Tables) - This view allows the user to navigate both the simple tables and spreadsheets, and is designed for organizing and manipulating tables spreadsheet data. This view functions similar to the main view in Calc for spreadsheets and slightly differently for tables.
  • Equation View (Equations) - 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 numbering options. While I don't see the purpose in having a separate program for equations, aka Math, this view would look similar to the main view in Math; the relevance of Math is a whole new topic to 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.
Personal tools