Difference between revisions of "User:JaronBaron"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Renaissance Logo Concept)
 
(35 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{{User Experience Community}}
 
{{User Experience Community}}
 +
= 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 OpenOffice.org 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.
 +
 +
 +
[[Image:RenaissanceLogo_userJaronBaron_1.png]]
 +
 +
Design iteration 1
 +
 +
 +
 +
[[Image: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).
 +
 +
 +
[[Image:RenaissanceLogo_userJaronBaron_s1.png]]
 +
 +
Short Logo
 +
 
= User Intro =
 
= User Intro =
  
Line 21: Line 42:
 
= My Thoughts & Ideas, My Grand Scheme for the UI =
 
= My Thoughts & Ideas, My Grand Scheme for the UI =
  
= Intro and my existential view of office suites =
+
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.
 +
 
 +
 
 +
== Intro ==
 
I want to start off by talking about office suites in general.
 
I want to start off by talking about office suites in general.
  
What is the difference between the different programs in office suites?
+
'''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.'''
  
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.  If I want to create a spreadsheet with some paragraphs to explain contents, should I use a spreadsheet program or should I use a document program?  The answer should be that it doesn't matter but the default tool set available in the spreadsheet program should make it easier to use for a document that contains primarily spreadsheets.
 
  
 +
PLEASE VIEW THE GUI DESIGN AT: http://wiki.services.openoffice.org/wiki/User_Experience/NewGUILayout
  
 
== An Object Based Design ==
 
== 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 list of the objects that I identify as the core objects contained within documents.  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
+
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'''
 
* '''Pages'''
** Page Style
+
** 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)
** Pre-defined text spaces (this could be something other than text, such as tables for OO.o Calc)
+
*** 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)
*** Body text (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)
*** Style or Section dependent content objects
+
** 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)
**** Headers
+
** Layers (All documents benefit from graphical layers, ex: watermarks on simple text document)
**** Footers
+
**** Siders (a new concept, its applicable to documents with things like numbered lines)
+
** Breaks (normally things like line breaks are under the page category, but that is not appropriate since breaks belong to the body text box)
+
*** Style
+
** Layers (All documents benefit from layers, ex: watermarks on simple text document)
+
  
 
* '''Text Boxes'''
 
* '''Text Boxes'''
** Text Box Style
+
** 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)
** Text
+
** Columns (normally, inappropriately assigned as a page object)
** Box Links
+
** 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)
** Columns
+
** Footnote space (this is not a page property since the footnote stays with the text reference, which, if it changes pages, moves)
** Breaks
+
** Footnote space
+
*** Line
+
*** Column/Layout
+
*** "Page" (since this basically restricts the use of the remaining text box space and is only relevant for linked text boxes, page is a misnomer)
+
  
* '''Text'''
+
* '''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
 
** Characters
*** Special Characters (besides the normal special characters also implies images as characters which is relevant mostly for lists)
+
*** Special Characters
 +
*** Figures as Characters (I assume this is relevant mostly for lists but likely has other uses)
 
** Lists
 
** Lists
*** Bullets
+
*** Bullets/Numbering - local list (a simple list or outline)
*** Numbering
+
*** Sections - global list (defines arrangement of document, even text styles, based on sections)
*** Sections
+
** Paragraph formatting
** Paragraphs
+
  
* '''Figures'''
+
* '''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.
** Canvas (I use canvases since the following objects can be intermixed within any given figure, ex: a picture with an arrow)
+
** 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)
*** Pictures
+
** Spreadsheet, aka the table in Calc (tables that have a local referencing system for functions)
*** Charts
+
*** Drawings
+
*** Placeholders
+
 
** Captions
 
** Captions
  
* '''Tables'''
+
* '''Figures'''
** Spreadsheets (tables that contain primarily text and have a local referencing system for functions etc...)
+
** 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)
** Organizational tables (tables that contain and organize any/all objects, ex: a table that has multiple subfigures but is a single figure and has a single caption)
+
*** 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
 
** Captions
  
* '''Shapes/text boxes/vector-based graphic objects'''
+
* '''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)
  
* '''Rastered images/pictures'''
+
* '''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 current office suites have failed to incorporate them effectively and I doubt their user functionality is well defined)
+
* '''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
 
** Movies
 
** Sounds
 
** Sounds
 
** Animation/Flash/interactive web content
 
** Animation/Flash/interactive web content
  
* '''Smart text/References/hyperlinks/scripts'''
+
* '''Links/Smart text/References/hyperlinks'''
** Literary references
+
** Bibliography/Literary/Scientific references
** Object references (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)
+
** Object references (footnote, figure references, table references etc...)
** Text references (such as hyperlinks which reference the current section title)
+
** Text references/Bookmarks (ex: a link whose text is the current section title and takes you to the beginning of the section)
** Web Hyperlinks
+
** Web links
** Footnotes (the textual refrence, the footnote space falls under the page category)
+
** Bibliography/Scientific References
+
** Content Tables (Index, Table of figures, etc...)
+
** Bookmarks? (Reluctant to include this since they are better defined as a form of object metadata and not text related metadata)
+
** Notes? (Reluctant to include this since they are better defined as a form of object metadata and not text related metadata)
+
** Auto text (external metadata references)
+
*** Static (creates static text, such as inputting the date)
+
*** Dynamic (changes based on current metadata values, such as a "current date" script)
+
  
* '''Fields''' (end user interactive objects)
+
* '''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)
** Form fields
+
*** Text/number
+
*** Template text (such as mm/dd/yyyy, date entry)
+
*** Dropdown menus
+
*** etc... (there is a long list of potential form fields)
+
  
 +
* '''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, especially when it comes to the last two categories. 
 
  
I think the major difference between the different office suites would be in the definition of a page.
+
There may be more kinds of objects or a better way to categorize these objects and I am constantly refining the list.
  
== Object Properties ==
 
After trying to identify the objects within office suites I startes to create a list of the objects properties.  This list is quite extensive but I have included a preliminary example with the text object.  Note that text is pretty much the traditional character and paragraph format options.
 
  
 +
'''How the Page Object Would be Different in Each Suite Program'''
  
* Text
+
I think the major difference between the different office suite programs would be in the definition of a page and the default view.
** Style
+
 
** Text
+
* Calc - the page should be able to readily contain multiple tables, text boxes and figures/charts.
*** Font
+
* 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.
*** Bold
+
* Draw - the page would likely be blank with no pre-defined objects.
*** Italic
+
* Equation - not applicable as this shouldn't be a separate program and needs a humongous overhaul.
*** Strikethrough
+
 
*** Color
+
== Object based "Views" ==
*** Background Color
+
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.
*** Size
+
 
*** Direction/rotation
+
* '''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.
*** Subscript
+
 
*** Superscript
+
* '''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.
*** Line spacing
+
 
*** Alignment
+
* '''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.
*** Indents
+
 
*** Paragraph spacing
+
* '''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.
*** Tabs
+
 
*** Drop caps
+
* '''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.
*** Font effects
+
 
*** Character spacing
+
* '''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.
*** Hyphenation
+
 
*** Text flow
+
* '''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.
** Lists
+
 
*** Level
+
== Why Objects and Object based Views? ==
*** Bullet/Number (Character or image as character that is the number/bullet)
+
* '''Easy inter-suite program object transfer'''
*** Content of auto space preceding text (ex: “#.#.→“ as opposed to “#-#→“ where → is a tab)
+
* '''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.

Latest revision as of 21:32, 6 December 2008

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

ux.openoffice.org

Quick Navigation

Team

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 OpenOffice.org 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.


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 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.


PLEASE VIEW THE GUI DESIGN AT: http://wiki.services.openoffice.org/wiki/User_Experience/NewGUILayout

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