Created attachment 103008 [details] LibreOffice Writer Toolbar Button Usage Statistics As a long time ms word user since word 6.0, though i didnt use versions after ms office xp until joining the QA team, i've always enjoyed using the button toolbars. The only negative thing has been that the 2 default toolbars havent been customized to better suit the vast majority of users, which for me is easily noticable as the toolbars doesnt have a button for 'insert image'. I am aware that it is available in the drawing toolbar, but i dont think that most users would associate clicking a tooltip named 'Show Drawing Functions' with the ability to add an image. So presently, 86% of users are going into the menu (Insert > Image > From File) in order to add an image into their documents, which to me is quite sad, as most documents will have a image in it and inserting an image is the second highest inserted element in a document. Its so important in a document, that its the only element used in the writer icon, excluding the text. So it is my intention to present a proposal of a customized default toolbars that will contain as many useful buttons as possible, in order to reduce the need for most users to have to go into menus. I hope that in the future, that the sidebar will be improved enough that it could eliminate the use of the toolbars (similar to Calligra Words) for users who wish to do so, but unfortunately the sidebar isnt presently even able to remove the formatting toolbar, as it doesnt have a style drop down menu [bug 73071]. I have utilizing statistics gathered from OpenOffice.org 3.1 Usage Data < https://wiki.openoffice.org/wiki/Tracking_results > that was done in 2009, along with the assistance of the most used features used in bug reports that i worked on for the QA team, as well as useful input from Thibaut Brandscheid and other QA team members in order to come up with this proposal. The proposal will be broken up into sections, with each section being submitted as a comment, so that interested individuals have time to comment on each step. Below are the various steps i plans to submit for this proposal in upcoming comments. Step 1 - Removal of less used button entries Step 2 - Grouping similar items together Step 3 - Addition of buttons of highly used features Step 4 - Suggestion of new UI elements To begin the process, i have attached the statistics of the standard and formatting toolbars, showing a comparison of how much each button is used comparing to other buttons in the toolbar, as well as a comparison of how much the button is used in relationship to its menu bar entry, keyboard shortcut and context menu entry. I've included comments to further explain things, when things werent as straight forward as i would have hoped. I look forward to any suggestions to the improvement of this data. I'm hoping this proposal will find its way into the 4.4 or 5.0 release, and hope the same for my print preview proposal [bug 80838]. Note: For those looking to look over the raw OOo usage data, Astron had uploaded it to < http://dl.dropbox.com/u/87946285/libreoffice/OOo31_Usage_Feedback_Data.ods >.
Created attachment 103115 [details] Step 1 - Removal of Buttons - Before and After As there hasnt been any responses so far, lets get the ball rolling. :) -------------------------------------------- Step 1 - Removal of less used button entries -------------------------------------------- In order to make room for useful buttons to be added to the toolbars, we first need to remove/hide the less used ones from the toolbar. With some toolbar buttons that dont have equivalent menu items, menu items would need to created in order for the feature to still be accessible. -------------------------------------------- * Step 1a - Removals from the Standard Toolbar -------------------------------------------- 'New' (.uno:AddDirect) - There were no stats for the usage of the button in OOo, which makes me think that the .uno:NewDoc button was executed instead of it in the toolbar in OOo 3.1. Using the .uno:NewDoc stats, the toolbar total usage for it is at > 0.1%. This is believable as the shortcut key (Ctrl+N), which takes over 80% of the total function usage, is a common shortcut key used in pretty much every application. The other issue is that when you first load Writer, it always starts with a new file, so there isnt a need to press the button, unless you wanted to create another new file. 'Document as E-mail' (.uno:SendMail) - With less that 1% of toolbar total usage for the button and more users using the menu entry than the toolbar button, i think this button should be removed. I believe that most people are capable of attaching a document to an email (as of course they would have to if they used a web-based email client) without the help of writer and if they wish for the ease, then the file menu option is still there for them. 'Edit File' (.uno:EditDoc) - With 1% of toolbar total usage for the button, i think this button should be removed, but think the functionality should be available in the menu with a shortcut key [bug 80536] and should have its own dedicated toolbar which appears when in read mode, similar to how the fullscreen button appears in print preview mode [bug 80538]. Many users have been confused when documents open in read-only mode and even though the button is in the toolbar [1], they still dont know to press it, so a better notice needs to be presented to users, possibly in the form of an hovering toolbar button and/or popdown infobar. 'Show Draw Functions' (.uno:InsertDraw) - There isnt any stats for how often this button is pressed to make the Drawing toolbar appear, but i still believe this button can be removed, as the most used functionality of the toolbar will be brought into this toolbar in step 3. 'Navigator' (.uno:Navigator) - With less than half of a percent of toolbar total usage for the button and over 70% of users using the shortcut key (59%) and menu bar item (13%) to access it, i think this button should be removed. I believe that most users would never have to open this dialog unless they wanted to jump to a particular page by typing its page number in, instead of using the scrollbar. 'Data Sources' (.uno:ViewDataSourceBrowser) - With less than half of a percent of toolbar total usage for the button and over 75% of users using the shortcut key (73%) and menu bar item (4%) to access it, i think this button should be removed. I believe this feature is an advanced feature that isnt used by most users. 'Help' (.uno:HelpIndex) - With less than half of a percent of toolbar total usage for the button and ~70% of users using the menu bar item to access it, i think this button should be removed. Would have expected there would have been stats for the keyboard shortcut (F1) to access help, but unfortunately there wasnt any. I believe that most applications have a help menu that is short and simple and the F1 key is a universal means of quick access to help, so having this button isnt necessary. -------------------------------------------- * Step 1b - Removals from the Formatting Toolbar -------------------------------------------- 'Styles and Formatting' (.uno:DesignerDialog) - With 1% of toolbar total usage for the button, as well as an option to access the dialog from the 'more' entry in the 'Apply Style' drop down list, and ~70% of users using the shortcut key (40%) and menu bar item (30%) to access it, i think this button should be removed. -------------------------------------------- The attached image has a before and after image of what the default toolbar looks like and how it looks after the removals. Look forward to the feedback. :) -------------------------------------------- [1] http://ask.libreoffice.org/en/question/1228/libre-excel-read-only/
Created attachment 103175 [details] Step 2 - Grouping Similar Items Together -------------------------------------------- Step 2 - Grouping similar items together -------------------------------------------- Buttons with similar features or with mutually exclusive behaviour can be grouped together to increase the available space for the addition of more buttons, as well as to keep the accessibility of these features in the toolbar. The grouped buttons will look similar to the New and Open toolbar entries, i.e. that the group icon will have an arrow to the right of it, which can be clicked to see the underlying grouped entries. -------------------------------------------- * Step 2a - Grouping in the Standard Toolbar -------------------------------------------- 'Word Functions' group button - A group button should be created with 'Spelling and Grammar' (.uno:SpellingAndGrammarDialog - 3rd most popular dialog window) as its main button, as it takes up ~7% of toolbar total usage and 'AutoSpellcheck' (.uno:SpellOnline), which takes up 3%, should be grouped underneath it. Additional related entries can be added to the drop down including Word Count (.uno:WordCountDialog - 8th most popular dialog window), Thesaurus (.uno:ThesaurusDialog), and AutoCorrect (.uno:OnlineAutoFormat). I think the 'AutoSpellcheck' toggle entry should be available in the tools menu, under a menu item group titled 'Spelling', which will also contain the 'Spelling and Grammar' entry. Here is an example of the hierarchy: Tools Spelling Spelling and Grammar (F7) AutoSpellcheck I hope that in the future, additional entries can be added to the drop down, like a translation option using online translation services from google and bing. An enhancement request was submitted [bug 80722] for a shortcut key to jump to the next spelling error, and maybe a 'Next Spell Error' and 'Previous Spell Error' could also be included in the drop down list. -------------------------------------------- * Step 2b - Grouping in the Formatting Toolbar -------------------------------------------- 'Paragraph Alignment' group button - A group button should be created with all the alignment buttons (.uno:LeftPara, .uno:CenterPara, .uno:RightPara, .uno:JustifyPara), as all of them are mutually exclusive. I would recommend 'Centered' as the main button, as it has the highest toolbar total usage (27%) among the four buttons, while others have recommended that 'Align Left' be used as default for non-RTL languages, and it has the second highest toolbar total usage (16%). Another suggestion has been that left, right and justify be the group button as it has a 53% of usage of the four buttons, and center should remain its own button with its 47% usage. If space is available, i would recommend this option over the single group button. 'Bullets and Numbering' group button - A group button should be created with 'Bullets On/Off' (.uno:DefaultBullet) as the main button (15% toolbar total usage) and 'Numbering On/Off' (.uno:DefaultNumbering) grouped underneath it (6% toolbar total usage), as the two are mutually exclusive buttons. Another reason for Numbering to be underneath, is that more than half of users toggle Numbering with its shortcut key, while 99% of users toggle Bullets from the toolbar. The opening of the drop down would reveal a selection of bullet and numbering styles, similar to how it is displayed in the sidebar, but smaller in size, similar to the borders drop down found in calc. -------------------------------------------- The mockup continues on from the mockup of step 1 and shows how the grouped items would appear in the toolbar and how their drop down feature could possibly look.
Created attachment 103420 [details] Step 3 - Addition of buttons of highly used features -------------------------------------------- Step 3 - Addition of buttons of highly used features -------------------------------------------- The criteria for the inclusion of new buttons, most of which will be button groups, is governed by the overall usage of the function by users. The first group of new buttons will be of buttons hidden by default in the toolbars, the second will contain buttons found in other toolbars, and the third will contain buttons only accessible by customizing a toolbar. -------------------------------------------- * Step 3a - Unhiding items found in the toolbars -------------------------------------------- 'Find & Replace' (.uno:SearchDialog) button - The 'Find & Replace' dialog is a popular dialog window and its button is not hidden by default in OOo. OOo only has a single dialog window for both Find and Find & Replace, while LibO has a Find toolbar and Find & Replace dialog. The benefits of having it visible by default is that it can act as both a Find and a Find & Replace dialog, and i believe that 25% to 40% of LibO users are accessing its functionality through the menu bar or from the Find & Replace button in the Find toolbar. 'Script' group button - A group button should be created with the main button being 'Superscript' (.uno:SuperScript) and 'Subscript' (.uno:SubScript) underneath it. The two buttons have a toolbar total usage of ~2% though they are hidden by default and their functionality is still ~54% activated through the toolbar. With this in the toolbar, it also helps eliminates the need for it to be in the right-click context menu. 'Line Spacing' group button - A group button should be created with all the line spacing buttons (.uno:SpacePara1, .uno:SpacePara15, .uno:SpacePara2), as they have a toolbar total usage of ~1.5%, though they are hidden by default, and their functionality is 15% to 30% activated through the toolbar. Most users set this functionality in the 'indents & spacing' tab of paragraph dialog box, while the next most used means is in the right-click context menu. The main button should be for single spacing, but in addition to the 1.5 and 2.0, 1.15 should also be added, as it is available in the sidebar, and a more button should also be its final entry (opening the Paragraph dialog in the 'Indents & Spacing' tab, and possibly selecting the line spacing drop down). Additional entries like 2.5 and 3.0 can also be added, as they are available in both Kingsoft Writer and MS Word. With this in the toolbar, it also helps eliminates the need for the line spacing submenu in the right-click context menu. 'Text Size Change' button - With ~0.75% of the toolbar total usage for the hidden Increase Font (.uno:Grow) and Reduce Font (.uno:Shrink) buttons, i'd recommend the inclusion of a single button with the ability to both increase and decrease the selected text's font size by one notch, without the need to open up the font size list. This would also help eliminate the need for the right-click context menu option to scroll through the font sizes. I can only guess that a suitable control widget exists that can fulfill this suggestion. -------------------------------------------- * Step 3b - Adding entries found in other toolbars -------------------------------------------- 'Insert Media' group button - A group button for the insertion of media files including images, sounds and videos. The main button would of course be the insertion of an image from a file (.uno:InsertGraphic), as it is the 2nd highest added element to a document. Underneath entries will include the addition of an image from the gallery (.uno:Gallery), image from fontwork gallery (.uno:FontworkGalleryFloater), image from a scanner (.uno:TwainTransfer), and an audio/video from a file (.uno:InsertAVMedia). The gallery button from the toolbar would be removed, a gallery item would be added to the View and/or Insert menus [bug 80545], and ideally a close button could be added to the gallery popdown. (buttons taken from the insert toolbar) 'Insert Internal Link' group button - A group button for the insertion of links within a document. The main button will be for insert footnote (.uno:InsertFootnote), as it has the highest usage amongst these various link options. Underneath entries will include insert endnote (.uno:InsertEndnote), insert bookmark (.uno:InsertBookmark), insert cross-reference (.uno:InsertReferenceField), insert index entry (.uno:InsertIndexesEntry), insert bibliography entry (.uno:InsertAuthoritiesEntry) and insert index/TOC (.uno:InsertMultiIndex). (buttons taken from the insert toolbar) 'Insert Object' group button - A group button for the insertion of objects into a document. I think the main button should be insert chart (.uno:InsertObjectChart) which is in second place in this category of buttons, but the numbers show that more users use insert formula (.uno:InsertObjectStarMath). Underneath entries will include insert file (.uno:InsertDoc), insert OLE (.uno:InsertObject), and insert plugin (.uno:InsertPlugin). (buttons taken from the insert toolbar) 'Special Character' (.uno:InsertSymbol) button - The button is the most popular button in the insert toolbar and overall is more popular than the Non-printing Characters button. As such, it deserves a dedicated button in the menu or alternatively a group button with a set of popular special characters (e.g. currency symbols, intellectual property symbols, greek letters, fractions, math symbols, emoticons, arrows, etc) and a more button to open up its regular dialog box. 'Comment' (.uno:InsertAnnotation) button - It is the 5th most popular button in the insert toolbar and will normally represents the reviewing of a document. This button could be converted into a group button and have underneath entries focused on the document review process like Edit > Changes menu entries ('Record Changes' .uno:TrackChanges, 'Show Changes' .uno:ShowTrackedChanges, 'Accept or Reject' .uno:AcceptTrackedChanges, 'Merge Documents' .uno:MergeDocuments, 'Prevent' .uno:ProtectTraceChangeMode) and the Edit > Compare Document (.uno:CompareDocuments) entry. 'Insert Fields' (.uno:InsertFieldCtrl) button - With this group button being the 6th most popular button in the insert toolbar and having a toolbar total usage of 23% and inserting a field being more used than drawing a line or merging cells in a table, i believe this button deserves a spot on the default toolbar, as 96% of users go to the menu to access this functionality. The order of popularity of the buttons underneath entries are Page Number, Date, Page Count, Time, Title, Author, Topic, and i think it can be sorted this way. Some other entries that i thought can be added to this list are Subject, Chapter (Name, Number), and File Name. Note: It was my intention to include buttons from the drawing toolbar in this section, but toolbar space wasnt sufficient, so the 'Show Draw Functions' (.uno:InsertDraw) button has been re-added to the toolbar. -------------------------------------------- * Step 3c - Adding entries found by customizing toolbars -------------------------------------------- 'Save' group button - The sixth most used function in Writer is 'Save As' (.uno:SaveAs) and ~97% of users go into the File menu in order to activate this option, so the 'Save' (.uno:Save) button, which is the third most used function, should be converted into a group button. The underneath entries should be popular formats like odt, fdot, docx, doc, and rtf. If pdf was also added to this list, it would be possible to remove the 'Export Directly to PDF' (.uno:ExportDirectToPDF) button from the toolbar. 'Character Line' group button - The underline (.uno:Underline) button is the 2nd most frequently used button in the formatting toolbar (42% toolbar total usage) and it should be converted into a group button with alternative means of placing lines on characters. Entries underneath should include Strike Through (.uno:Strikeout), Double Underline (.uno:UnderlineDouble) and Overline (.uno:Overline). With each of these three underneath entries, over 50% of users apply these lines using the Font Effects tab of the Character dialog (.uno:FontDialog), while the next group of users apply it with the context menu or keyboard shortcut, and the remainder of users apply it by adding the button to the toolbar. The last entry of the drop down should a 'more options' button, which jumps into the Character dialog's Font Effects tab. 'Font Effects' group button - The Character dialog (.uno:FontDialog) is the 7th most popular dialog window and its second most popular tab is the Font Effects tab. The second most popular reason users visit this tab, is to enable direct formatting font effects like shadow (.uno:Shadowed), outline (.uno:OutlineFont), relief (embossed and engraved) and case effects (small capitals). Half of users enable shadow and outline through the right-click context menu and the other half enable it from the Fonts Effects tab, while ~1.35% enable the buttons in the toolbar. The default button should be shadow as it has the most usage amongst these various effects. I believe this group button will be expanded in the future to include more font effects, including those from ms office 2010 and above. I think that the drop case (.uno:FormatDropcap) paragraph feature might also be a good candidate for inclusion in this group button. Having this button would help eliminate the need for the right-click context menu style submenu. -------------------------------------------- With the removal of many buttons and the inclusion of new ones, it is important to finalize the toolbars by re-arranging the buttons into useful groups. So i've arranged the standard toolbar into sections for file open & save, print, copy & paste, undo & redo, functions, and insert. With the formattting toolbar i've arranged it into sections for font styles/face/size, font effects, colors, bullets & indentation, and paragraph features.
Created attachment 103482 [details] Google Docs - single widget color picker ------------------------------------- Step 4 - Suggestion of new UI elements ------------------------------------- The creation of new UI elements is not an easy task to my knowledge, as it can involve quite a bit of development work in order to complete, and due to that, i've limited my suggestions to just one. Single Color Group Button - Presently in Writer, there are 3 drop down buttons for colors (i.e. Font Color, Highlight Color, and Background Color) and they take up more space then any other group of buttons or drop down list in the formatting toolbar. It would be beneficial to have a single drop down color pick widget that has tabs for Text, Highlight and Background, similar to how google docs does it in the attachment. Of course the drawback to this suggestion is that it wouldnt be as easy to add an already selected color to text, because its a merged single button that you couldnt click the icon portion of it to do one thing and the down arrow portion to perform another. ------------------------------------- Step 5 - Additional Suggestions ------------------------------------- During this process, i've thought about alot of other suggestions that didn't make it into the final mockup, so i'm taking this opportunity to present them encase others think they are worth using. Removal of Cut/Copy/Paste Buttons - With over 90% of users using either the shortcut key or context menu to achieve this functionality, there really isnt a need to keep around these buttons other than to maintain the standard toolbar legacy layout used in most applications. The removal of the paste button would only be a recommendation if 'paste special' was added to the context menu [bug 62947]. Removing these would allow the inclusion of 3 other buttons that dont have easy access to from the toolbar, like 'Manual Break' (.uno:InsertBreak) and 'Insert Columns' (.uno:FormatColumns), which are accessed ~99% from the menu. Cut/Copy Group Button - As these two buttons are mutually exclusive in their actions, they could be combined as a group with copy as its main button, as copy is used 3 times more often than cut. Combining these could allow the addition of one other button into the toolbar. Print Group Button - By converting the standard print button into a print group button, the drop down would list all the available printers for easy direct printing to and the list would end with a more button which would give access to the print dialog. Customized Open Drop Down - When most users are in a particular application, they consider that application as an independant application (thats how libreoffice even presents it in the application menu) and as such, if they have Writer opened and clicked on the toolbar open drop down list, they would expect to see only text documents in the list. Customized Open dialog - Similar to customization of the open drop down list, it would be equally expected that if a user clicked on the toolbar open button, that 'Text documents' would be automatically selected in the file types drop down list. It makes no sense that 'All Files' is selected by default, when LibreOffice cant open all files. Improvements to Tooltips - With many of the buttons that have been suggested to be included in the mockup, their tooltips are not suitably written because they link to the wordings in the menu (e.g. 'From File' used for the insert image button [bug 80542]), were incorrectly written (e.g. 'Insert Footnote/Endnote Directly' when this button only inserts footnotes), or can be further improved by better wording (e.g. 'Hyperlink' to 'Add/Edit Hyperlink'). Highlighting and Background Color Confusion - I find that having both these buttons in the formatting toolbar to be a major confusion because a user is supposed to understand that highlighting is the text background color and background is the paragraph background color. IMHO, i'd assuming most users would consider highlighting to be what they perseive as background color and as such, the background color button should be removed. What really makes things more confusing is that the Character and Paragraph dialogs both have tabs called 'Background'. Insert Table Button Default Behaviour - As most users will normally create small tables, the default behaviour of the insert table button (.uno:InsertTable) should be to open its drop down and not to show the dialog box.
Created attachment 103484 [details] Final Mockup Toolbar as well as an alternative ------------------------------------- Step 6 - Conclusion ------------------------------------- It has been a pleasure to contribute these suggestions to LibreOffice, so that its toolbars can hopefully be refreshed from looking like office suites from 9+ years ago < http://polishlinux.org/reviews/openoffice/OpenOffice2_Writer.png > :D. My proposal has heavily used group buttons to pack as many similar features as possible into the toolbars, so i'm also providing a less aggressive group button mockup for consideration. I think implementing any of the two mockups or any of the suggestions provided would be a great step in the right direction. I look forward to feedback from the UX team and others, so that i can begin with the execution of these suggestions. I would like to take this opportunity to thank the individuals who developed and participated in the OOo user feedback program, without whom this proposal wouldnt have had solid statistics to back up its suggestions, as well as the individual who pointed me to the stats (jorendc). I would like to specially thank Thibaut Brandscheid for his efforts and suggestions last year and during my proposal and you can find his recently mocked up single toolbar suggestion at < http://i.imgur.com/72HB3vP.png >. I would also like to thank the QA team members that i discussed the idea with (jmadero, FirasH, sophie) and lastly i'd like to thank Michael Meeks and those handling the libreoffice twitter account for replying to my tweets, which ultimately started my contributions to libreoffice. I think redoing this statistical feedback program would be a great thing for libreoffice to do every few years, as it gives better insight on user behaviour and how best to improve the user experience. Below i've included buttons that were planned for the final mockup, but were excluded due to space restraints of limiting the mockup to a width of 1024 pixels. ------------------------------------ 'Insert Drawing' group button - As the current 'Show Draw Functions' (.uno:InsertDraw) button simply opens the drawing toolbar, i believe that the most popular buttons found in the toolbar can be merged into a single group button, by creating a popup toolbar similar to the basic shapes popup toolbar. Kingsoft Writer has a similar group button, which can be seen at < http://i.imgur.com/m01xVMn.png >. The popup toolbar would have 6 columns and would likely be limited to the most used buttons of each type, if space is a factor. I have sorted approximately 75% of the various shapes below by their popularity :- Toolbar Buttons Line, Freeform Line, Rectangle, Ellipse, Callouts Basic Shapes Diamond, Circle, Rounded-Rectangle, Quadrat, Isosceles-Triangle, Block-Arc, Frame, Round-Quadrat, Right-Triangle, Trapezoid, Ring, Cross, Cube, Hexagon, Parallelogram, Can, Circle-Pie, Octagon Symbols Smiley, Heart, Sun, Flower, Cloud, Right-Brace, Moon, Lightning, Left-Brace, Puzzle, Octagon-Bevel, Forbidden, Diamond-Bevel, Quad-Bevel, Right-Bracket, Left-Bracket, Bracket-Pair Arrows Left-Right-Arrow, Rigth-Arrow, Down-Arrow, Left-Arrow, Up-Arrow, Corner-Right-Arrow, Circular-Arrow, S-Sharped-Arrow, Notched-Right-Arrow, Split-Arrow, Up-Down-Arrow, Striped-Right-Arrow, Split-Round-Arrow, Up-Right-Arrow, Pentagon-Right, Chevron, Drown-Arrow-Callout, Right-Arrow-Callout, Up-Right-Down-Arrow, Quad-Arrow Flow Chart Internal-Storage, Process, Connector, Terminator, Alternative-Process, Decision, Punched-Tape, Extract, Data, Multidocument, Magnetic-Disk, Predefined-Process, Document, Merge, Collate, Display, Sequential-Access, Manual-Input Callouts Round-Rectangular-Callout, Cloud-Callout, Round-Callout, Rectangular-Callout, Line-Callout-1, Line-Callout-2 Stars Star5, Bang, Horizontal-Scroll, Veritical-Scroll, Star4, Star24, Star8, Star6, Signet 'Text Frame' (.uno:DrawText) button - With it being the 2nd most used button in the insert toolbar, and one that is not possible to integrate into the drawing group button, it should have a dedicated button in the toolbar, as it allows the placing of text in any location on a page. 'Insert Breaks/Marks' group button - A group button encompassing all the various breaks (line, column, page [.uno:InsertPagebreak]), hyphens (non-breaking [.uno:InsertHardHyphen], optional [.uno:InsertSoftHyphen]), and spaces (non-breaking [.uno:InsertNonBreakingSpace]). The main button will be insert page break as its the most used of these entries. The last entry of the group will be for 'Manual Break' (.uno:InsertBreak), as the dialog is access ~99% of the time through the menu, while other entries are accessed 75 to 99 percent by the keyboard shortcut. One of the goals of having this as a default toolbar button is to encourage users to use page breaks rather than using the enter key to move to the following page. 'Properties' group button - A group button should be created that give easy access to both the 4th most used dialog window, Paragraph Dialog (.uno:ParagraphDialog), and 7th most used dialog window, Character Dialog (.uno:FontDialog). With each of them, 2/3rd of users go into the format menu in order to access it, while the other 1/3rd access it from the right-click context menu. Additional dialog windows can also be grouped underneath this like 'Page Settings' (.uno:PageDialog - 5th most popular dialog window), which has 83% of users accessing it from the format menu and 17% from the context menu. 'Insert Page Division' group button - A group button catering to the division of the page into pieces. The main button will be 'Insert Columns' (.uno:FormatColumns) as it has the highest usage, while underneath entries will include insert frame (.uno:InsertFrame) and insert section (.uno:InsertSection). The main benefit of this button group is that 99% of users go to the menu to get access to these dialogs and accumulatively, its more likely for one of these three function dialogs to be opened compared to the opening of the table properties dialog.
My 2 cents are... During the installation of LO respectively Tools -> Options -> View offer two options: 1) proposal as"image 3" and 2) proposal as "image 4" Reason: some people want "simple", some people want "full" informations. Everyone now has the opportunity to decide between the two versions and then adjust the view according to his ideas. Maybe it even makes sense to offer all four proposals as a selection
Hi Jay, That's quite a mouthful. I'll try to comment on all of it. For starters, though, I'd like to point out that the current contextual ("formatting") toolbars are supplemented by the Properties pane in the sidebar. Thus, a reorganization of any of these toolbars should take this pane into account as well. In general, the purpose of each of the UI elements is as follows: * The Standard toolbar should serve as the starting point for everything not pertaining to the current selection. It has a long way to get there, but that is the goal. (Note that this should be solved not by cramming everything into the toolbar, but by clever design. Modern browsers, Gnome 3, elementary OS, iOS, and Android apps prove that this can be done.) * Contextual ("formatting") toolbars provide quick access to commonly-used commands related to the selection. * The Properties pane should provide access to all commands pertaining to the current selection, replacing formatting dialogs in the long run. It's also notable that split buttons should be used when a) one button in a group is much more commonly used than the others, or b) the button is a shortcut to a command and the menu allows the user to tweak the command's function. For groups of buttons that are all used with the same relative frequency, a drop-down menu should be used instead, as it provides a larger target area and is therefore easier to click. Groups should hold at least 3 buttons -- 2 buttons are not worth grouping. I'm not sure if by "group buttons", you mean split buttons or drop-down menus, so I'll suggest the ones that I think are fitting below. Now I'll comment on the specifics: Step 1 ====== * +1 for removing everything you listed (provided all the changes required for getting rid of "Edit File" happen) * Additionally, I would propose to either get rid of the "Font Name" dropdown or at least condense it into a drop-down menu with an icon. It's bad practice both to use more than 3 fonts per document and to hard-format fonts instead of using styles. Step 2 ====== a) * +1 to having a "Word functions" split button * I disagree with having a Spelling menu item -- the current approach that lets you work with the selection, the paragraph, or all text makes much more sense to me. * Not keen on building Google or Bing into LibO. Wouldn't mind extensions for this, though. * Error navigation is better suited for the "Navigate by" feature. b) * Given that several of the alignment options are commonly used, I would not make them into a group button. Because we have the Properties pane now, we should just have individual buttons for the more important features in the toolbar. * The same with "Bullets and Numbering". Step 3 ====== a) * I'm torn about whether to add "Find" or "Find and Replace". Though "Ctrl+F" is relatively well-known, 15% of users used the toolbar button (more than "Undo", "Cut", "Copy", or "Paste"). The toolbar is also more comfortable to use, already links to "Find and Replace" if it's needed, and has navigation features not found in the dialog. I'm also hoping some basic replace functionality will be added to the toolbar. * Subscript/superscript should be individual buttons. (There's space freed by the "Font name" removal suggested above.) * A "Line Spacing" drop-down menu sounds good. * A single "Size Change" button would be hard to implement, it would feel alien as it's not a native widget, and the small version would be hard to target. It'd be preferable to replace the font size combo box (which shouldn't be used anyway -- styles should be used for sizing text) with "Increase font size" and "Decrease font size" buttons. Clicking one of these buttons should show the new font size in a tooltip below the button. b) * An "Insert Media" group doesn't seem necessary to me. It's extremely unlikely for sounds or videos to be inserted into documents, spreadsheets, or drawings, and, from my own experience, it's pretty rare for presentations. The Gallery is in the sidebar and shouldn't have a toolbar button (see [Bug 73151]). Fontwork should basically never be used. The only buttons remaining are Insert Image ("From File...") and "Scan Image" -- the former should be in the toolbar, the latter is, IMHO, not used frequently enough to warrant its own button. I'll comment on the rest later.
I think the idea here is we need to do a proper audit of what should really be in the Standard toolbar and then design and implement accordingly. Jay, it seems like you've done quite a bit of work on this, but it's difficult to comment on individual parts of it here in bug report. I would caution against adding any more functionallity into the standard toolbar. As it is, it's so crowded it makes it more difficult to navigate than a menu in my opinion. This is my idea for how the standard toolbar ought to be set up in conjunction with the sidebar: http://imgur.com/a/XyN4O , althought I've since removed the spellcheck button, since it's already in the status bar.
(In reply to comment #7) > Hi Jay, > That's quite a mouthful. I'll try to comment on all of it. Hi Mirek2, Thanks for taking the time to read and comment on it. > Step 1 > ====== > * +1 for removing everything you listed (provided all the changes required > for getting rid of "Edit File" happen) The 'Edit File' bug has been added to the menu and an infobar to indicated that the document is in read-only mode seems like it will be pushed through. > * Additionally, I would propose to either get rid of the "Font Name" > dropdown or at least condense it into a drop-down menu with an icon. It's > bad practice both to use more than 3 fonts per document and to hard-format > fonts instead of using styles. The concept of styles are foreign to many users and they will stick with using the font names dialog to select fonts they want to use and i doubt there is anything that will change this behaviour unless styles are introduced in a new manner that is very ease to grasp. > Step 2 > ====== > a) > * +1 to having a "Word functions" split button > * I disagree with having a Spelling menu item -- the current approach that > lets you work with the selection, the paragraph, or all text makes much more > sense to me. Well i suggested the spelling menu, as a means of grouping spelling related items into the Tools menu, similar to having a language menu item in the Tools menu. I didnt quite get what you meant with 'work with the selection, the paragraph, or all text' when it comes to spelling. > * Not keen on building Google or Bing into LibO. Wouldn't mind extensions > for this, though. This was only a hope that something would show up like this in the future, as i think it would help many translators (especially those working on the release notes for LibO :D). If an open source alternative is around, i'm all for it, but was just suggesting how this drop down might get expanded in the future. > * Error navigation is better suited for the "Navigate by" feature. Where can i find this navigate by feature? > b) > * Given that several of the alignment options are commonly used, I would not > make them into a group button. Because we have the Properties pane now, we > should just have individual buttons for the more important features in the > toolbar. > * The same with "Bullets and Numbering". These are commonly used buttons, but unfortunately they take up more space than the more used trio - bold, italics and underline. In the alternative mockup i have suggested the use of a two button approach so it takes up the size of 2.5 buttons rather than 4 (this mockup also keeps the buttons and numbering separate). > Step 3 > ====== > a) > * I'm torn about whether to add "Find" or "Find and Replace". Though > "Ctrl+F" is relatively well-known, 15% of users used the toolbar button > (more than "Undo", "Cut", "Copy", or "Paste"). The toolbar is also more > comfortable to use, already links to "Find and Replace" if it's needed, and > has navigation features not found in the dialog. I'm also hoping some basic > replace functionality will be added to the toolbar. I was initially going to suggest a group find button, but unfortunately space was a limiting factor. The group button was going to have Find, Find & Replace, Goto Page (dialog), and Navigator. > * Subscript/superscript should be individual buttons. (There's space freed > by the "Font name" removal suggested above.) Yes if there is space, i'd have these as separate. > * A single "Size Change" button would be hard to implement, it would feel > alien as it's not a native widget, and the small version would be hard to > target. It'd be preferable to replace the font size combo box (which > shouldn't be used anyway -- styles should be used for sizing text) with > "Increase font size" and "Decrease font size" buttons. Clicking one of these > buttons should show the new font size in a tooltip below the button. Well i was going to suggest the 2 increase and decrease font buttons located on either side of the font size combo box, but space was an issue. I dont think eliminating the combo box was good as it would mean users couldnt jump to a particular size that they wanted and would have to waste time clicking till they got to the correct size. I think the combo box could be reduced as it seems that it has enough room for 4 characters, when most font sizes are only only 2 chars, except for '10.5'. > b) > * An "Insert Media" group doesn't seem necessary to me. It's extremely > unlikely for sounds or videos to be inserted into documents, spreadsheets, > or drawings, and, from my own experience, it's pretty rare for > presentations. The Gallery is in the sidebar and shouldn't have a toolbar > button (see [Bug 73151]). Fontwork should basically never be used. The only > buttons remaining are Insert Image ("From File...") and "Scan Image" -- the > former should be in the toolbar, the latter is, IMHO, not used frequently > enough to warrant its own button. This proposal was limited to just writer. The ability to open up the gallery, whether it be in the current location or in the sidebar, from within the button group is still a useful feature, as it is possible that the user doesnt have the sidebar enabled or open. This would be no different than having the button in the Tools menu. (In reply to comment #8) > I would caution against adding any more functionallity into the standard > toolbar. As it is, it's so crowded it makes it more difficult to navigate > than a menu in my opinion. This is my idea for how the standard toolbar > ought to be set up in conjunction with the sidebar: http://imgur.com/a/XyN4O > , althought I've since removed the spellcheck button, since it's already in > the status bar. Yes it is crowded with junk that is rarely used, which is why the first thing in the proposal is the removal of the trash. Your standard toolbar + sidebar approach is a similar layout to IBM symphony and Calligra Words and i look forward to the day that it will be possible with LibO, but unfortunately i dont think that will happen within the next year or two. Also you will have users who will choose not to use the sidebar, so i dont think LibO should force them to do so.
Created attachment 104127 [details] Competition - Atlantis Word Processor Toolbars Here is the toolbar used by Atlantis Word Processor ( www.atlantiswordprocessor.com ). They have gone the route of having 3 toolbars on by default and a button on the right of the toolbars to switch it to a different set of three toolbars.
Created attachment 104130 [details] Competiton - Corel WordPerfect Here is the toolbar used by Corel WordPrefect X7 ( www.wordperfect.com ). They have a good selection in the toolbars, which includes many of the suggestions i've made, as well as many that i couldnt include do to spacing (shapes, text box, columns).
Hi Jay, I'll just comment on your answer here and comment on the issue later: (In reply to comment #9) > > * Additionally, I would propose to either get rid of the "Font Name" > > dropdown or at least condense it into a drop-down menu with an icon. It's > > bad practice both to use more than 3 fonts per document and to hard-format > > fonts instead of using styles. > > The concept of styles are foreign to many users and they will stick with > using the font names dialog to select fonts they want to use and i doubt > there is anything that will change this behaviour unless styles are > introduced in a new manner that is very ease to grasp. Yes, but the font name drop-down is rarely used, which means it should either be removed from the toolbar and left to the sidebar or it should at least occupy less space (as a drop-down with an icon). > > Step 2 > > ====== > > a) > > * +1 to having a "Word functions" split button > > * I disagree with having a Spelling menu item -- the current approach that > > lets you work with the selection, the paragraph, or all text makes much more > > sense to me. > > Well i suggested the spelling menu, as a means of grouping spelling related > items into the Tools menu, similar to having a language menu item in the > Tools menu. I didnt quite get what you meant with 'work with the selection, > the paragraph, or all text' when it comes to spelling. Spelling is an integral part of the Language menu under tools -- spell-checking and grammar-checking are the only reasons to apply a language to parts of text. What I meant to say is that there's no need for a separate Spelling menu -- it would just duplicate the Language menu. > > * Not keen on building Google or Bing into LibO. Wouldn't mind extensions > > for this, though. > > This was only a hope that something would show up like this in the future, > as i think it would help many translators (especially those working on the > release notes for LibO :D). If an open source alternative is around, i'm all > for it, but was just suggesting how this drop down might get expanded in the > future. I understand. > > * Error navigation is better suited for the "Navigate by" feature. > > Where can i find this navigate by feature? Either the navigator or the Find toolbar. In older versions, it used to be at the bottom of the right-hand scrollbar. > > b) > > * Given that several of the alignment options are commonly used, I would not > > make them into a group button. Because we have the Properties pane now, we > > should just have individual buttons for the more important features in the > > toolbar. > > * The same with "Bullets and Numbering". > > These are commonly used buttons, but unfortunately they take up more space > than the more used trio - bold, italics and underline. In the alternative > mockup i have suggested the use of a two button approach so it takes up the > size of 2.5 buttons rather than 4 (this mockup also keeps the buttons and > numbering separate). The thing is, we don't need to save space. We should keep all the common options as accessible for users as possible and relegate all the lesser-used commands to the sidebar. Button groups make things harder to access, and if the formatting toolbar is supposed to provide quick access to the most common commands, it should avoid them when possible. (Ideally, LibreOffice would be responsive and group buttons into drop-down menus when there is no room for them.) > > > Step 3 > > ====== > > a) > > * I'm torn about whether to add "Find" or "Find and Replace". Though > > "Ctrl+F" is relatively well-known, 15% of users used the toolbar button > > (more than "Undo", "Cut", "Copy", or "Paste"). The toolbar is also more > > comfortable to use, already links to "Find and Replace" if it's needed, and > > has navigation features not found in the dialog. I'm also hoping some basic > > replace functionality will be added to the toolbar. > > I was initially going to suggest a group find button, but unfortunately > space was a limiting factor. The group button was going to have Find, Find & > Replace, Goto Page (dialog), and Navigator. A simple Find button is probably best, as it encompasses both search and navigation. > > > * Subscript/superscript should be individual buttons. (There's space freed > > by the "Font name" removal suggested above.) > > Yes if there is space, i'd have these as separate. If there is no space, they should be in the sidebar. > > * A single "Size Change" button would be hard to implement, it would feel > > alien as it's not a native widget, and the small version would be hard to > > target. It'd be preferable to replace the font size combo box (which > > shouldn't be used anyway -- styles should be used for sizing text) with > > "Increase font size" and "Decrease font size" buttons. Clicking one of these > > buttons should show the new font size in a tooltip below the button. > > Well i was going to suggest the 2 increase and decrease font buttons located > on either side of the font size combo box, but space was an issue. I dont > think eliminating the combo box was good as it would mean users couldnt jump > to a particular size that they wanted and would have to waste time clicking > till they got to the correct size. I think the combo box could be reduced as > it seems that it has enough room for 4 characters, when most font sizes are > only only 2 chars, except for '10.5'. Reducing the box sounds good. > > b) > > * An "Insert Media" group doesn't seem necessary to me. It's extremely > > unlikely for sounds or videos to be inserted into documents, spreadsheets, > > or drawings, and, from my own experience, it's pretty rare for > > presentations. The Gallery is in the sidebar and shouldn't have a toolbar > > button (see [Bug 73151]). Fontwork should basically never be used. The only > > buttons remaining are Insert Image ("From File...") and "Scan Image" -- the > > former should be in the toolbar, the latter is, IMHO, not used frequently > > enough to warrant its own button. > > This proposal was limited to just writer. The ability to open up the > gallery, whether it be in the current location or in the sidebar, from > within the button group is still a useful feature, as it is possible that > the user doesnt have the sidebar enabled or open. This would be no different > than having the button in the Tools menu. The problem around panes being duplicated in the sidebar is still a hot topic now, but, generally, we should either promote one or the other, and since the sidebar has panes that aren't available individually, we should prefer the sidebar over the panes. Rather than buttons for individual panes, then, how about having a button for the sidebar? > (In reply to comment #8) > > I would caution against adding any more functionallity into the standard > > toolbar. As it is, it's so crowded it makes it more difficult to navigate > > than a menu in my opinion. This is my idea for how the standard toolbar > > ought to be set up in conjunction with the sidebar: http://imgur.com/a/XyN4O > > , althought I've since removed the spellcheck button, since it's already in > > the status bar. > > Yes it is crowded with junk that is rarely used, which is why the first > thing in the proposal is the removal of the trash. Your standard toolbar + > sidebar approach is a similar layout to IBM symphony and Calligra Words and > i look forward to the day that it will be possible with LibO, but > unfortunately i dont think that will happen within the next year or two. We have the same sidebar that Symphony had -- IBM donated the code to AOO and now we have it -- we just refined it a bit. We're already there. > Also you will have users who will choose not to use the sidebar, so i dont > think LibO should force them to do so. The toolbar is for quick access. If you need lesser-used commands, you'll have to open either the sidebar or the formatting dialog. The sidebar is easier to work with and some may just view it all the time. It's not being forced on anyone, though. I'm just saying that putting common things into harder-to-access group drop-downs to make room for lesser-used commands goes against the quick access nature of toolbars.
(In reply to comment #9) > (In reply to comment #8) > Also you will have users who will choose not to use the sidebar, so i dont > think LibO should force them to do so. Changing the design of something does not constitute "forcing" people to do anything. This mentality is an all-too-prevalent enemy of design. It may be a bit of a cliche by now, but design is not some kind of polish you put on software after you've made it to make it look nice--design is how it works, so if we can't make decisions about how LibreOffice works, then we can't expect it to be designed well. We shouldn't rely on the expectation that each user will "paint their own" ui--most people can't be bothered to do that. Most people don't use LibreOffice primarily for the ability to change the chrome--they use it to be productive. The sidebar is a much more natural way of laying out tools, which I would bet increases overall productivity. >> Also you will have users who will choose not to use the sidebar, so i dont >> think LibO should force them to do so. >I'm just saying that putting common things into harder-to-access group >drop-downs to make room for lesser-used commands goes against the quick access >nature of toolbars. This is important. A toolbar with many items takes just as long to look through as a menu. In order to move forward, we need to: (1) Recognize and agree that Writer's toolbars have a fixable problem. (2) (a) Create a whiteboard to work on this problem collaboratively, or (2) (b) Create different proposals separately (3) Decide on a solution (4) Get some developers to work on it. This bug report is great for addressing (1), but we can't move into part (2) without first completing part (1), which is answering the question: Are the standard and formatting toolbars in need of a redesign? I would say they are.
Created attachment 104556 [details] IBM Symphony single toolbar line with standard and contextual toolbars Hi Mirek, (In reply to comment #12) > Yes, but the font name drop-down is rarely used, which means it should > either be removed from the toolbar and left to the sidebar or it should at > least occupy less space (as a drop-down with an icon). Well i guess that we'll have to disagree on how used the font name drop-down is. You also have to take into consideration that styles arent highly used in calc and impress, as there isnt a style drop down in the toolbar. Here are responses about this issue from the ux mailing list. Jean-Francois Nifenecker: Could you elaborate, please? When I see the people around me (corporate environment, 400+ users) who don't use styles (most of them, unfortunately), the font drop-down *is* used very often. David: I really do get irritated with this argument about styles. Yes, they are the right way and yes, we should use them all the time. But the real world isn't like that and a significant proportion, if not majority, of LO users just don't get styles. Period. I use styles and have taught their use in offices I've managed for many years. But for short 1 to 2 page documents it is irrelevant whether users will be bothered about spending time styling their documents. Please do not reduce the choice of users to use fonts and direct formatting if they wish, and do not make it harder for them to do so. > Spelling is an integral part of the Language menu under tools -- > spell-checking and grammar-checking are the only reasons to apply a language > to parts of text. What I meant to say is that there's no need for a separate > Spelling menu -- it would just duplicate the Language menu. Well if you'd prefer to have 'Spelling and Grammar' and 'AutoSpellcheck' underneath the Language submenu, then i'm fine with that, though i think it maybe confusing for some users. The reason for suggesting the spelling menu was that i didnt want to suggest cluttering up the main Tools menu with an 'AutoSpellcheck' entry, but maybe it would be worth it so users didnt have to go digging through a submenu for it. > The thing is, we don't need to save space. We should keep all the common > options as accessible for users as possible and relegate all the lesser-used > commands to the sidebar. LibO has a plethora of useful features that can be brought forward to users, so they dont have to go through menus, dialogs, and sidebars. And in order to bring some of these features to the toolbar, space needs to be freed up. > Button groups make things harder to access, and if the formatting toolbar is > supposed to provide quick access to the most common commands, it should > avoid them when possible. Button groups do not make things harder to access, as we already have button groups for open, new, paste, table, font color, highlight color, background color, and all the shapes in the drawing toolbar. You could easily consider the style, font name and font size a button group. As an example, lets take my proposed 'Insert Internal Link' group button. Instead of a user having to go into Insert > Footnote/Endnote and then the dialog opens up and then them select 'Endnote' under type, they would click on the down button in the group button and click the endnote entry. This is easier access. This functionality isnt available in the sidebar as well. > (Ideally, LibreOffice would be responsive and group buttons into drop-down > menus when there is no room for them.) It would be great if LibO was smart enough to do that, but as it isnt, we can still help. :) > A simple Find button is probably best, as it encompasses both search and > navigation. Presently there isnt a Find button available. > The problem around panes being duplicated in the sidebar is still a hot > topic now, but, generally, we should either promote one or the other, and > since the sidebar has panes that aren't available individually, we should > prefer the sidebar over the panes. Yes i've seen the discussions around this issue and thought to comment on it, but chose not to. Ultimately, i think users who use the sidebar would like the panes in the sidebar, but users who dont, would prefer it the old way. > Rather than buttons for individual panes, then, how about having a button > for the sidebar? I think it would be useful to have a sidebar/toolbar mode button that would allow users to choose what they prefer to use. If they are in toolbar mode, it works as it has always done. If they are in sidebar mode, only a single toolbar line should be visible that primarily hosts the standard toolbar, and there shouldnt be drawing, table, and find toolbars popping up at the bottom (similar to how IBM Symphony had it). > We have the same sidebar that Symphony had -- IBM donated the code to AOO > and now we have it -- we just refined it a bit. We're already there. I am aware that the sidebar was brought from IBM Symphony, but the additional toolbar functionality wasnt brought over. In IBM Symphony, there was a single top toolbar line that had a small standard toolbar and then an additional contextual toolbar, which changed when you were on/in an object (see attached image). This contextual toolbar took the place of all the bottom popup toolbars (table, picture, etc) as well as the toolbars that that switch with the formatting toolbar (frame, ole-object, drawing object properties, etc). > The toolbar is for quick access. If you need lesser-used commands, you'll > have to open either the sidebar or the formatting dialog. The sidebar is > easier to work with and some may just view it all the time. It's not being > forced on anyone, though. The toolbar is quick access just like the sidebar, but as the sidebar is a non-experimental feature introduced in 4.2 and is not enabled by default, many users may not be aware of it or prefer not to use it. If the styles, navigator, and gallery are decided to be exclusively kept in the sidebar, then they will be forced to use it. > I'm just saying that putting common things into harder-to-access group > drop-downs to make room for lesser-used commands goes against the quick > access nature of toolbars. Group drop-downs are not hard-to-access and most entries proposed for the drop-downs are for highly used commands, as the statistics have already shown. If you look at the WordPerfect screenshot, you will notice that they have similar group drop-downs for underline (this is in the sidebar already), alignment, and symbols. -------------------- Regarding the sidebar, I believe there are two types of users who use writer. One type of user who will use the sidebar and one type that wont. I think the use of the sidebar will likely come down to the user's screen size, but the maturity of the sidebar will also likely effect some users decision. If you look at these stats, < http://www.w3counter.com/globalstats.php > and < http://gs.statcounter.com/#resolution-ww-monthly-201307-201407 >, you will see that the second most used screen size is 1024x768. A user at this small 4x3 screen size, is highly unlikely to use the sidebar over the toolbar, as the sidebar takes up 1/3 of the screen (the smallest size of the sidebar is 317 pixels). Such a user wouldnt be able to handle that huge chunk of space taken away from him/her and would prefer the formatting toolbar. This proposal was done for toolbar users who may not know about the sidebar, as its not enabled by default, and for users who choose not to use it.
(In reply to comment #13) > Changing the design of something does not constitute "forcing" people to do > anything. This mentality is an all-too-prevalent enemy of design. It may be > a bit of a cliche by now, but design is not some kind of polish you put on > software after you've made it to make it look nice--design is how it works, > so if we can't make decisions about how LibreOffice works, then we can't > expect it to be designed well. We shouldn't rely on the expectation that > each user will "paint their own" ui--most people can't be bothered to do > that. Most people don't use LibreOffice primarily for the ability to change > the chrome--they use it to be productive. The sidebar is a much more natural > way of laying out tools, which I would bet increases overall productivity. Presently, there are two choices to get access to the gallery. The first is the old way of the gallery appearing between the toolbars and the ruler and the second is the new way of the gallery appearing in the sidebar. By eliminating one of these two choices, would this not limit a user's choice. For a user at 1024x768, when the gallery appears under the toolbar < http://i.imgur.com/1I7K3sp.png >, he/she can view their document at 100% and can see view more images than when the gallery appears in the sidebar. If the sidebar gallery appeared at 1024x768 < http://i.imgur.com/YeXodS8.png >, it would cause a significant portion of the document to be not viewable unless the view is adjusted with the scrollbars or the zoom level. Yes most users dont bother adjusting the default UI, but we do allow the users that do, the ability to move toolbars to any of the four sides, so in the same spirit, we should allow users to have the gallery at the top or in the sidebar. > >I'm just saying that putting common things into harder-to-access group >drop-downs to make room for lesser-used commands goes against the quick access >nature of toolbars. > > This is important. A toolbar with many items takes just as long to look > through as a menu. Images are easier to recognize then words, especially if they are easy to see (bug 82309) and easy to understand (bug 82272), and when toolbar buttons are organized in a good manner representing a collection of features, they will be quick to navigate. LibO has grouped similar features like bold, italics, and underline together and in a similar manner, i had suggested the grouping of various insert buttons like table, image, footnote, comment, etc. together. The drop downs do not make it harder to access, as entries underneath the main entry are very related to the main entry. This is no different than the submenus in the context menu for styles or line spacing. Without this quick access, users would have to always jump into the dialog boxes to get these basic features lacking from the toolbar. > In order to move forward, we need to: > (1) Recognize and agree that Writer's toolbars have a fixable problem. > (2) (a) Create a whiteboard to work on this problem collaboratively, or > (2) (b) Create different proposals separately > (3) Decide on a solution > (4) Get some developers to work on it. > > This bug report is great for addressing (1), but we can't move into part (2) > without first completing part (1), which is answering the question: Are the > standard and formatting toolbars in need of a redesign? > > I would say they are. Yes this bug was mainly setup to address step 1 and demonstrate how it can be fixed, so that the necessary individuals/teams could take these findings and finalized it into a solution. I am willing to work with whomever can move this proposal forward and believe step 4 can easily be achieved, as i can submit patches to add/remove all non-group button entries and will find a developer to implement the group buttons.
First of all I have to admit that I didn't read all of the comments. Sorry if something has been discussed before. We run a study on LO standard toolbar last year. Quick wins can be found here: http://user-prompt.com/conclusions-of-the-libreoffice-icon-test/ The findings support Jay's basic idea. But I would be careful with removing or adding too much stuff from the standard toolbar because the position of an icon is quite important too. That means some icons serve as whitespace even when it's never used. For instance, if Save was the left most function it could be misinterpreted as save and close (it was common practice to have Exit in the toolbar, erstwhile). All toolbars are customizable. Right click somewhere and chose the option from the context menu. Neither this dialog is usable nor it's obvious how to access it. But Jay's first issue could be solved right now. So how's about a better usability for the personalization of toolbars? Finally I'd like to advice caution using personal preferences. For instance, the Navigator might not be used by many people but I love it. So I'd suggest to add Search into this sidebar - and most users wouldn't find the function anymore. All ideas have to get confirmed by a larger group of standard users.
Thanks Heiko for the link to your standard toolbar study, as it did confirm my proposal's removal of the data sources and navigator icons. Your study also brought to my attention that AutoSpellcheck is likely being mistakenly for Spelling and Grammar due to their similarity and that the group button was the right thing to do with them. Regarding the customization of the toolbar, in LibreOffice 3.3 as well as OpenOffice 4.1, the end of each toolbar had a distinct down arrow with a darker background which did suggest a user could click on it for additional functionality. Unfortunately, allowing users to customize their toolbar isnt the main issue of this proposal, as most users wont do it even if they knew it was possible. The main issue is to optimize the toolbars, so most users wouldnt ever need to customize it as it will have the most commonly used functions.
Created attachment 105415 [details] My setup I don't agree with kicking out some icons, since I use them regularry, but if most of people don't use it, I'll just have to re-add them into toolbars. Tried using sidebar, but to many things missing. It's just unfinished product. Attached you can find my current setup. In Calc I added Save As, (OM) = WRAP , verital aligment and number formating 0.0 (thousand separator and 2 decimal places, not sure why this isn't on by default since it's probably one of most used buttons in calc for me). Increased button size and placed it all in 1 row. In Writer I just added Save As and kicked out buttons I know I will never or very rarely use.
Hi Mikeyy, (In reply to comment #18) > I don't agree with kicking out some icons, since I use them regularry, but > if most of people don't use it, I'll just have to re-add them into toolbars. > Tried using sidebar, but to many things missing. It's just unfinished > product. Yes the proposal is to make the toolbar more usable to most people's needs, but still make it easy for users to re-enable the removed/hidden icons. > In Writer I just added Save As and kicked out buttons I know I will never or > very rarely use. Thanks for your screenshot, as it shows that you do customize it with many of the proposal suggestions - adding save as and comment, as well as removing styles, data sources, navigator, help, copy, cut, and paste.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e5f52eddda1230eba971881223601bb7aa255d6b fdo#81475 New layout for Writer standard and formatting toolbars The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b59c5ace4b7213ffd62495d0c0e5b6411f5071be Related fdo#81475 Improve toolbar tooltips in Writer standard toolbar The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jan Holesovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b1a5e34e27c0118f319aebbc5a6c9cdf05929239 Revert "Related fdo#81475 Improve toolbar tooltips in Writer standard toolbar" The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Let me add something about toolbars. I think this is a good place. I think that dynamic appearance/disappearance of toolbars is not a good idea. For me it is comfortable to place toolbars once and use them when I want to use them, not contextually (current object- or action- dependent). But now in 4.3.2 toolbars disappear even if they have Lock Toolbar Position option checked. Please enable static toolbar positions. Popping toolbars may cause attention switch and may lower document author's productivity. Otherwise you will create another stupid, ugly, non-usable Ribbon/MFI. I think that many LibreOffice users would be happy with MS Office 2003-like interface. Users do not need bells and whistles, they need comfortable and customizable interface. This interface should allow users to place and pin (lock) toolbars as they want and use keyboard shortcuts for more productivity (for example, the fastest way to add Cross-Reference is to press <Alt-i><e>).
@Norbert - you can just enable the toolbar. I highly disagree that it should not be by default context specific. There are too many options to just have all the toolbars activated and in 3+ years on the project I've never heard anyone else suggest that we should do so.
As drop down buttons wont be arriving for the 4.4 release, the formatting toolbar drop down placeholder entries (superscript, shadow) needed to be removed so more useful buttons could be added (line spacing). Also color and list/indent buttons were rearranged for better placement. Patch has been submitted for this - https://gerrit.libreoffice.org/#/c/11817/
Hi I do not support removal of 'New' and 'Styles and Formatting' icons (and of course Cut/Copy/Paste Buttons). I am glad about 'Comment' (I used to added buttons manually) and Subscript/superscript as individual buttons. In Writer, I add all case effects (5 buttons, are they all included in 'Font Effects'?), Insert Comment (that yellow one, is it included in 'Comment' group?), Insert Footnote Directly (nice if added) and Alternative Find & Replace from search extension (Bug 38261). In Calc, I add also 'Show All Notes' and 'Hide All Notes' - please consider if Calc will be changed too - and of course 'Wrap' from wrap extension (Bug 60349) - please take a look at that one.
I checked LO master today, and I can see as follows: - 'New' icon is there in both Writer and Calc, while 'Styles and Formatting' is not visible in Writer and is visible in Calc. I think it should be the same in both, I prefer to have it visible. - In Writer, 'Insert Comment' and 'Insert Footnote' icons are already there by default, but case effects are not. Can you please CREATE icons for them and ADD them to Formatting toolbar (as not visible until drop-down buttons)? I suggest icons with stylized letters: Sc (sentense case), sc (small), AC (all capitals), CW (capitalize - every - words), tC (toggle case) or maybe Abc, abc, ABC, AaBbCc (well, somehow..), aBC. If yes, please backport to 4.3. Should I open a new bug? - Calc is now in Bug 85594, so, I'll write there.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=10c979462263c50ca5d19debf61205ff2de12ffa fdo#81475 - Rearrangement some buttons and add some hidden ones It will be available in 4.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0daa405e104098bbceea6a974a80ad49ff50af7a fdo#81475 Disabling background color in enabling some other buttons It will be available in 4.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2a29fa312cb71616ca90d71eb61c80d54e1cf086 fdo#81475 moving alignment buttons back to original place It will be available in 4.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3452d8ba0f2069a39a793fa05b89153ea73d4a93 fdo#81475 rearrange, add and remove entries from toolbars It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=de39032e3877dcbe41f11d3d62d1ed1b4cc2b841&h=libreoffice-4-4 fdo#81475 rearrange, add and remove entries from toolbars It will be available in 4.4.0.0.beta2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=503379fa0b06b66ab6f2bbedc73cdcb056545330 fdo#81475 Writer doesn't have ParaspaceIncrease/Decrease commands It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a3363248d97d74f077579a4a9b8891b7fe0e2c9c&h=libreoffice-4-4 fdo#81475 Writer doesn't have ParaspaceIncrease/Decrease commands It will be available in 4.4.0.0.beta2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dd359cff8814ad7a9796f05cd21c9d98190898c2 fdo#81475 reorganization of writer's table toolbar It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=815f515b8ff14f0542ec5f7898ca98d589b193eb&h=libreoffice-4-4 fdo#81475 reorganization of writer's table toolbar It will be available in 4.4.0.0.beta2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e91104ee1654b104a0a9a75c3e0147549f3a3325 Revert "fdo#81475 Writer doesn't have ParaspaceIncrease/Decrease commands" It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This bug fix comes with LibreOffice 4.4 (release notes https://wiki.documentfoundation.org/ReleaseNotes/4.4) The “Standard” and “Formatting” toolbars were reorganized by removing uncommonly used commands and replacing them with frequent features, in order to reduce the need for users to hunt through menus or customize toolbars. Additional buttons have been added to the toolbars, but are hidden by default and can be enabled by using the “Customize” option. See a graphic of the work: https://wiki.documentfoundation.org/File:Before_and_after_1024.png
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c18468bbef6f701520116485fa20a790a2c837e9 fdo#81475 addition of 'Add Caption' button to table toolbar It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=88ae2a436ec79dd152f9e81edea00e402438cc1f fdo#81475 rearrangement of writer's frame toolbar It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bc4210772aebbbc91dc10b11090086b6143a9dc5 fdo#81475 Improvements to writer web standard toolbar It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ca2174e24369bc63a2475ee471bf76697a859317&h=libreoffice-4-4 fdo#81475 rearrangement of writer's frame toolbar (4.4) It will be available in 4.4.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=72abe12705c9c8fdf82ad48697e9301133d5ecbc&h=libreoffice-4-4 fdo#81475 addition of 'Add Caption' button to table toolbar (4.4) It will be available in 4.4.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
About "Styles and Formatting" It is good to have statistics proving that styles are rarely used compared to fonts changing -- see Step 1b by Jay Philips and his comment that "concept of styles are foreign to many users". However, this might be a mistake to follow this logic. Consider that there are other mechanisms of imposing "good practices" to users. IMHO, the one proposed in Pages is very effective, see http://macmost.com/using-styles-in-pages.html It simply apply changes of font to a style, not the selected text. So simple. Also, most users create few content, while few users work on collaborative 10-100 pages long documents, i.e. create a lot of content. Speaking for the later users, we are annoyed by terrible Frankenstein-like formatting. We do need a better toolbar! P.S. an important change would be making special paste of unformatted text the default option for text. This means no information about size and font should be copied (yet, styles like em., ital., bold, scripts should be).
> About "Styles and Formatting" > It is good to have statistics proving that styles are rarely used compared to > fonts changing -- see Step 1b by Jay Philips and his comment that "concept of > styles are foreign to many users". > However, this might be a mistake to follow this logic. So - I'm not in the UX team - but I 100% agree; we should be enthusiastically encouraging the use of styles - left/right =) the fact people don't know what they are is (IMHO) the fault of the UI in large part ;-) I'd love to have a better style selector, nice, big previews of styles etc. to help people create better documents. If we've removed the button that pops-up the (admittedly shockingly ugly) style selector that (to me) is a shame =)
(In reply to Vladislav from comment #44) > It is good to have statistics proving that styles are rarely used compared > to fonts changing -- see Step 1b by Jay Philips and his comment that > "concept of styles are foreign to many users". > > However, this might be a mistake to follow this logic. The removal of the styles and formatting button in the toolbar in Step 1b does not eliminate the ability to set styles and access the styles and formatting dialog, as these two are possible through the style drop down menu in the toolbar. The elimination of the button was based on OOo stats that showed it was rarely used and most users didnt click the button to access the dialog. My statement that "The concept of styles are foreign to many users" was in defense of retaining the font name drop down which Mirek wanted to eliminate when he said "I would propose to either get rid of the "Font Name" dropdown or at least condense it into a drop-down menu with an icon". > Consider that there are other mechanisms of imposing "good practices" to > users. IMHO, the one proposed in Pages is very effective, see > http://macmost.com/using-styles-in-pages.html It simply apply changes of > font to a style, not the selected text. So simple. Yes iWork's implementation of style management is quite interesting but that wont necessarily impose "good practices" on users, as users could ignore clicking the 'Update' button, but would likely make non-style users grasp the concept faster. With iWork, all formatting is done through the sidebar, but with LibreOffice, you have a formatting in both the toolbar and sidebar, so many toolbar users simply ignore the sidebar. > P.S. an important change would be making special paste of unformatted text > the default option for text. This means no information about size and font > should be copied (yet, styles like em., ital., bold, scripts should be). I have suggested another paste special option for retaining character styles in bug 83102. (In reply to Michael Meeks from comment #45) > So - I'm not in the UX team - but I 100% agree; we should be > enthusiastically encouraging the use of styles - left/right =) the fact > people don't know what they are is (IMHO) the fault of the UI in large part > ;-) I totally agree that we need to encourage users to use styles and that the UI is the largest problem behind adoption. Bug 73071 has asked that the style drop down be added to the sidebar, but unfortunately it hasnt been done yet. > I'd love to have a better style selector, nice, big previews of styles > etc. to help people create better documents. I have submitted enhancements to get a good style selector as a tab in the sidebar (bug 86039, mockup in attachment 109138 [details]) and have also suggested getting styles in the context menu (bug 85940) as direct formatting options were removed from there. The design team has discussed ways to improve styles and we are looking into them, including having it as a GSoC project. > If we've removed the button > that pops-up the (admittedly shockingly ugly) style selector that (to me) is > a shame =) The button has been removed from the toolbar, but is visible by default as a button in the sidebar. The style selector is no longer a pop-up, it is a permanent tab in the sidebar.
To second Jay's reasoning: We asked users [1] about the preferred method to change the text highlight color and paragraph background color. Most people responded that they use the toolbar buttons (n=185, 78%), followed by users who change it through the context menu (n=16, 7%), then users who change it through styles (n=16, 7%). From another survey about Calc [2] we know that styles are not known at all for 25% of the users. If we force them to use styles instead of direct formatting we loose the casual user who does not care about large documents or consistent layout (which requires the usage of styles). [1] http://user-prompt.com/de/standard-toolbar-in-libreoffice/ [2] http://user-prompt.com/de/results-of-survey-about-libreoffice-calcs-toolbar-configuration/
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=85e4761b929797216a56e4c9eca3d8bb0685f883 tdf#81475 Unhiding of entries in the standard and formatting toolbars It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fd68059586246f415a5fa6637fafad1ac9293e92 tdf#81475 added/removed/rearranged buttons from various toolbars It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ff9fde527ec05a71c27fa3109ef4b57216f785dd tdf#81475 Fix missing space in standard toolbar and rearranged other toolbars It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Jay Philips from comment #5) > 'Insert Breaks/Marks' group button - A group button encompassing all the > various breaks (line, column, page [.uno:InsertPagebreak]), hyphens > (non-breaking [.uno:InsertHardHyphen], optional [.uno:InsertSoftHyphen]), > and spaces (non-breaking [.uno:InsertNonBreakingSpace]). The main button > will be insert page break as its the most used of these entries. The last > entry of the group will be for 'Manual Break' (.uno:InsertBreak), as the > dialog is access ~99% of the time through the menu, while other entries are > accessed 75 to 99 percent by the keyboard shortcut. One of the goals of > having this as a default toolbar button is to encourage users to use page > breaks rather than using the enter key to move to the following page. > Jay, if I understand well, you're still speaking about single page break button? It exists now and inserts page break with some logic: if the page was Default Style, then the next one is also Default Style, if the page was Left, then the next one is Right. But, for example, I frequently use page break with First page, so that I get my first page header and footer. I suggest page break button be drop-down button where there will be also be Styles, like page break with Default Style, with First page, with Landscape, with Right page, with Left page.
(In reply to Timur from comment #51) > Jay, if I understand well, you're still speaking about single page break > button? It exists now and inserts page break with some logic: if the page > was Default Style, then the next one is also Default Style, if the page was > Left, then the next one is Right. > But, for example, I frequently use page break with First page, so that I get > my first page header and footer. > I suggest page break button be drop-down button where there will be also be > Styles, like page break with Default Style, with First page, with Landscape, > with Right page, with Left page. Timur: Yes the standard page break (Ctrl+Enter) was added to Writer's toolbar in 4.4. Adding page break styles to the drop down button wouldnt be a wise approach from my stand point as there are many page styles and users can add more page styles which wouldnt get listed, which is why the last entry in the drop down would open the 'Insert Break' dialog (Insert > Manual Break...), which gives full access to all the page styles and changing page numbers.
Sorry, do you think that: - page break styles shouldn't be added to the drop down button at all, or - all page break styles must be added, including the last entry in the drop down for the 'Insert Break' dialog (Insert > Manual Break...)? If I understand well, currently there is no button for 'Insert Break' dialog. Thank you.
I think that page break styles shouldnt be added to the drop down. You can add a button for 'Insert Break' by customizing the toolbar and adding the 'Manual Break' entry found in the 'Insert' category. It doesnt have an associated icon, so you'll have to put one that suits your needs, if you dont like seeing text.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=89f7a5670ae0b21c8a80f73d27b5bc1181021373 tdf#81475 Additional improvements to Writer's toolbars It will be available in 5.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=79ebc1b02ede836626e1df0a09e8960aba06aff3&h=libreoffice-5-0 tdf#81475 Additional improvements to Writer's toolbars It will be available in 5.0.0.0.beta2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1a8e9dae32997bf199dbd192058fcd8f187ddc49 tdf#81475 Additional work on the formatting and draw toolbar It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=caef2a4f7649bc7bddbefa7693d9c451758fb896&h=libreoffice-5-0 tdf#81475 Additional work on the formatting and draw toolbar It will be available in 5.0.0.0.beta2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0fd01e681e1c5886be3909cc3d7eb66cc62705f3 tdf#81475 Another round of tweaks to Writer's various toolbars It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9d03c6a52deb5ad877e1637d5faccea9233bdbc2&h=libreoffice-5-0 tdf#81475 Another round of tweaks to Writer's various toolbars It will be available in 5.0.0.0.beta2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=167f10f846b58fd5a35d48a96fcec2d50c832fc6 tdf#81475 Improvements to writer's table toolbar It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bd7f0b0ba3391f3049cb3f2d7b70493a05362316 tdf#81475 Improvements to writer's toolbars It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cbff71864a02674e9b7eba756aa3f881e39b5c27&h=libreoffice-5-1 tdf#81475 Improvements to writer's toolbars It will be available in 5.1.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=33459c1b7c76f909ccdbaa707ef27d7e3be80550 tdf#81475 Minor tweaks to writer toolbars It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8cb088d71c4ccda318e298dbbb425b72731f9c05&h=libreoffice-5-2 tdf#81475 Minor tweaks to writer toolbars It will be available in 5.2.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c31c338fa2a941e128d0dac251fb99f777ac7b00 tdf#105293 tdf#81475 Tweak standard and formatting toolbars It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc31c2335b2469630cdbcef4ba38a44e01408e27 tdf#81475 Add separator before clone formatting button It will be available in 5.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e3a5998e64f4568ef9d68bb8c36207dae3f595d0&h=libreoffice-5-4 tdf#81475 Add separator before clone formatting button It will be available in 5.4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=91c8acaacf3846169d1e58c03acc5c20cd79a257 tdf#81475 tdf#113434 improve drawing object toolbar It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f894386a8fe58639c295048fe7894f68613a0df1 tdf#81475 Organize the form toolbars It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e027dc4629db2959e2c62b97b463c1846849dbd7&h=libreoffice-6-0 tdf#81475 Organize the form toolbars It will be available in 6.0.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=603d1773a2dfea6b347f44ddacef478577098caf tdf#115447 tdf#81475 Restore form controls used in forms It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2460d20c9a10920944b470d5ff5871f2bdb328f5&h=libreoffice-6-0 tdf#115447 tdf#81475 Restore form controls used in forms It will be available in 6.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
as there is no linked bug can this bug be closed with fixed?