Difference between revisions of "Proposal by Juan Canham"

From Apache OpenOffice Wiki
Jump to: navigation, search
(New page: {| style="border: thin dashed #CC2222; padding:5px; background:#FFDAB9" = Design Proposal [linked sections] = {{User Experience Community}} {| style="border: thin dashed #CC2222; padding:5... (checkpoint save))
 
Line 12: Line 12:
 
<span style="color:DimGray">Instead of providing a fixed layout, providing a framework to allow users to setup a wide variety of setups to suit thier needs. Additionally the most popular setups can then be shipped with openoffice to work around the fact that different use cases use different setups (e.g a person who mainly reads documents doesn't want much screen estate wasted on toolbars, but a user who mainly formats will need his tools visable most of the time)</span>
 
<span style="color:DimGray">Instead of providing a fixed layout, providing a framework to allow users to setup a wide variety of setups to suit thier needs. Additionally the most popular setups can then be shipped with openoffice to work around the fact that different use cases use different setups (e.g a person who mainly reads documents doesn't want much screen estate wasted on toolbars, but a user who mainly formats will need his tools visable most of the time)</span>
  
Status: Request for Comments
+
Status: WIP..only read about the project just now, apologies if i run over the deadline, is it GMT?
  
 
<span style="color:DimGray">After you consider the comments and questions in the comments section, revise your proposal for completeness and understandability. When you feel your proposal is ready for evaluation, please change the status above to “Proposal Complete”. </span>
 
<span style="color:DimGray">After you consider the comments and questions in the comments section, revise your proposal for completeness and understandability. When you feel your proposal is ready for evaluation, please change the status above to “Proposal Complete”. </span>
 
== Mockup ==
 
<span style="color:DimGray">Please add your main “wireframe” mockup. For example: A mockup which shows the functionality for adding a slide in Impress.
 
 
{| class="prettytable"
 
| [[Image:ProjectRenaissance_AndreasBartel_MenuNavigation.png|640px|thumb]]
 
|}
 
 
{| class="prettytable"
 
| [[Image:ProjectRenaissance_AndreasBartel_TabbedNavigation.png|640px|thumb]]
 
|}
 
  
 
== Detailed Description ==
 
== Detailed Description ==
<span style="color:DimGray">Menubar:Replace the main menubar with a menubutton [mozilla.org], use this to show all menu bar buttons that aren't shown by menu buttons that are spread out at the appropriate ends of the main toolbar (help)
+
*Menubar - Replace the main menu bar with a menu button, use this to show all menu items that aren't shown by menu buttons that are spread out at the appropriate ends of the main toolbar (e.g view and tools next to the menu bar and help in the top right)
 
+
Buttons: you are likely only interacting with one thing at a time, if define usage cases narrowly enough to put all the relevant tools on a toolbar but widely enough that there are only a few settings, then you can save space (or give more space to just the relevant tools).
+
 
*Some Actions can be done from any of the states Copy/undo stick this outside of a "container"
 
*Some Actions can be done from any of the states Copy/undo stick this outside of a "container"
 
*Bind keys&buttons (automatically based on selection?) to toggle whats in the "container"
 
*Bind keys&buttons (automatically based on selection?) to toggle whats in the "container"
*Imo the container should be editing text/ editing pictures/layout(including columns & tables)/document(changing setting /print/save/open/new) and read (auto-hide the entire toolbar, giving 100% of screen estate to the document)
 
 
|Menubutton(s)|permanent buttons|toggles:relevant buttons|help|
 
|Menubutton(s)|permanent buttons|toggles:relevant buttons|help|
 
+
*Customizations:Make the whole thing customizable (if the relevant buttons are to big to fit in the provided space that section should be the first to lose space  and allow users to define their own containers, with repeated buttons and add their own buttons(also allow keybiding and auto toggeling on selecting the relevant medium)
*Customizations:Make the whole thing customizable (if the relevant buttons are to big to fit in the provided space that section should be the first to lose space  and allow users to define thier own usage cases, with repeated buttons (looking at you kde3) and thier own triggers (some people want to go straight to the text editing menu as soon as they select text others dont).
+
*Allow the different sections to be separated, like separate toolbars(so you could put the "container" on an entire tool bar underneath)
Make the whole look changeable (companies may want to replace the default menu button with a company logo? or make the whole thing bright pink?)
+
*Allow different toolbars to use different sized icons (and allow some to have text while others dont)
Allow the different sections to be separated (so you could give the relevant buttons an entire tool bar underneath)
+
*Providing too much customization is not a bad thing as long as most people can use the defaults.
Allow different toolbars to use different sized icons
+
*Provide an easy&safe way to save/share a theme. (There is no point in doing research designing what you thing is a good compromise for the work load that office/home users put their suite through, when you can just put a version out there and see what people do with it.)
Providing too much customization is not a bad thing as long as most people can use the defaults.
+
 
+
Themes:Provide an easy&safe way to save/share a theme.
+
Provide sane defaults and get it out there, during the next release cycle look at which themes popular (you'll probably find there to be a few popular themes, classic, ribbon, office, geek, flashy) and ship them with the next release. There is no point in doing research designing what you thing is a good compromise for the work load that office/home users put their suite through, when you can just put a version out there and see what people do with it.
+
 
+
  
 
* <span style="color:DimGray">'''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.</span>
 
* <span style="color:DimGray">'''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.</span>
* <span style="color:DimGray">'''Explain the rationale and assumptions''': If you decided to go for a certain concept, then please explain why you chose this.</span>
+
* <span style="color:DimGray">'''Explain the rationale and assumptions''': I decided to go with toggle.</span>
 
* <span style="color:DimGray">'''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.</span>
 
* <span style="color:DimGray">'''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.</span>
 
* <span style="color:DimGray">'''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.</span>
 
* <span style="color:DimGray">'''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.</span>
  
 
== Additional Material and Mockups ==
 
== Additional Material and Mockups ==
* [http://wiki.services.openoffice.org/w/images/c/c2/ProjectRenaissance_DesignProposals_MenuBased_Navigation_Andreas_Bartel.pdf Menu-Based Navigation]
 
* [http://wiki.services.openoffice.org/w/images/9/9c/ProjectRenaissanceUXTeam_DesignProposals_Tabbed_Navigation.pdf Tabbed-Navigation]
 
 
== Author or Team Working on This Proposal ==
 
 
{| class="prettytable"
 
| '''Author / Team Member'''
 
| '''Contact (OpenOffice.org login name, used for email)'''
 
 
|-
 
| <span style="color:DimGray">Andreas Bartel</span>
 
| <span style="color:DimGray">Andba</span>
 
 
|}
 
  
 
== Comments ==
 
== Comments ==

Revision as of 23:07, 11 May 2009

Design Proposal [linked sections]

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

ux.openoffice.org

Quick Navigation

Team

Please do not edit this page unless you are the original author. Your feedback and comments are welcome in the Comments section below or on the ui@ux.openoffice.org mailing list.

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

Summary and Status

Instead of providing a fixed layout, providing a framework to allow users to setup a wide variety of setups to suit thier needs. Additionally the most popular setups can then be shipped with openoffice to work around the fact that different use cases use different setups (e.g a person who mainly reads documents doesn't want much screen estate wasted on toolbars, but a user who mainly formats will need his tools visable most of the time)

Status: WIP..only read about the project just now, apologies if i run over the deadline, is it GMT?

After you consider the comments and questions in the comments section, revise your proposal for completeness and understandability. When you feel your proposal is ready for evaluation, please change the status above to “Proposal Complete”.

Detailed Description

  • Menubar - Replace the main menu bar with a menu button, use this to show all menu items that aren't shown by menu buttons that are spread out at the appropriate ends of the main toolbar (e.g view and tools next to the menu bar and help in the top right)
  • Some Actions can be done from any of the states Copy/undo stick this outside of a "container"
  • Bind keys&buttons (automatically based on selection?) to toggle whats in the "container"
permanent buttons|toggles:relevant buttons|help|
  • Customizations:Make the whole thing customizable (if the relevant buttons are to big to fit in the provided space that section should be the first to lose space and allow users to define their own containers, with repeated buttons and add their own buttons(also allow keybiding and auto toggeling on selecting the relevant medium)
  • Allow the different sections to be separated, like separate toolbars(so you could put the "container" on an entire tool bar underneath)
  • Allow different toolbars to use different sized icons (and allow some to have text while others dont)
  • Providing too much customization is not a bad thing as long as most people can use the defaults.
  • Provide an easy&safe way to save/share a theme. (There is no point in doing research designing what you thing is a good compromise for the work load that office/home users put their suite through, when you can just put a version out there and see what people do with it.)
  • 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: I decided to go with toggle.
  • 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

Comments

Community members, this is where your comments and questions concerning completeness and clarity should be written. Please add your OpenOffice.org login name to let us contact you via email.

Your space :-)

Personal tools