Created attachment 102175 [details] How the original toolar is and the mockups with and without text I have worked on a revamped print preview toolbar for writer and have attached mockup previews of what it can look like. As there is alot of space available in the toolbar, i would recommend going for the text based mockup. If some space is needs to be removed, then the word 'Double' can be changed to 'Twin' and the word 'Previous' can be shrunk to 'Prev'. I have used my usage of Adobe Reader and Okular as inspiration for this mockup, using functionality that is already present in LibreOffice, so that additional work is kept to a minimum. As i know some may be wondering why the print button was removed from the mockup toolbar, and the reason for that is that there is a print button still available in the standard toolbar and print is also available in the File menu and also with Ctrl+P. The print button will still be retained in the toolbar as the first button, but will be hidden by default. In order for this mockup to become a reality, i have already started submitting enhancement bugs including: 1) Bug 80651 - addition of a single page button 2) Bug 80654 - addition of a close button icon 3) Bug 80657 - addition of navigator page number field 4) Bug 80758 - having unnamed icons in a toolbar set to icons & text Going beyond what is necessary to achieve the mockup, i'd like to suggest that the toolbar be centered whenver its activated, and that the text 'Next' and 'End' be positioned to the left of their icons.
Created attachment 102176 [details] the customized toolbar xml file Here is the customized toolbar xml file that was used for the mockup. The entry for .uno:GotoPage was a filler as i didnt have a means of putting in the page jump control from navigator. Also another means of reducing space in the toolbar is to shrink 'Multiple' to 'Multi'.
Reasonable to track these UX design efforts, and development follow-on, with topical meta issues. But should also work-up Whiteboard on the Design wiki, and Design meetings. Setting new.
(In reply to comment #2) > But should also work-up Whiteboard on the Design wiki, and Design meetings. I'm not sure if you are asking me to do this. If so, then i would need instructions on how to do this, as i'm just a QA member. :)
(In reply to comment #3) > > But should also work-up Whiteboard on the Design wiki, and Design meetings. > > I'm not sure if you are asking me to do this. If so, then i would need > instructions on how to do this, as i'm just a QA member. :) Yes, exactly that! Not to worry that you've only worked QA issues. You've already got wiki access, that one ticket gets you admission to all facets--QA, development, marketing, documentation--it is all there to contribute. And if the effort has merit you'll find willing helpers to refine your contributions. Frankly a lot of the initial work is clerical. Design and good UX mock-up are an essential step toward encouraging a developer to take on the task. It helps them to scope out what they're getting into, the more detailed the vision the simpler to resolve programmatically into needed function. Then with a well vetted design, and a ready channel for user and designer feedback, development can move pretty quickly on new features and enhancements.
Submitted the request for the addition of the whiteboard, but unfortunately no response from the ux-advise team as yet. http://nabble.documentfoundation.org/Libreoffice-ux-advise-Request-the-creation-of-whiteboards-tt4114676.html
(In reply to comment #0) > I have worked on a revamped print preview toolbar for writer and have > attached mockup previews of what it can look like. As there is alot of space > available in the toolbar, i would recommend going for the text based mockup. > If some space is needs to be removed, then the word 'Double' can be changed > to 'Twin' and the word 'Previous' can be shrunk to 'Prev'. It's generally bad practice to shorten labels like this, as the clarity of the original label may be lost ("twin" is pushing it a bit) and as they advantage a single language only -- "twin" might be longer than "double" in a different language and it might be hard for translators to deduce what "prev means". Also keep in mind that whether a toolbar can fit depends on the window size -- a toolbar might seem small to you on a widescreen laptop, but it might not fit on a screen of a netbook. Fortunately, thanks to last year's GSoC project, we can choose to show only some icon labels in a toolbar. We should choose only those where the icons aren't clear -- "Full Screen" and "Close Preview" seem like good candidates. It'd be better to keep the entire "Close Preview" label, as "Close" is too vague. (One might think it's referring to closing the document rather than exiting preview mode.) As for the arrangement of icons, I can't judge which is better. Since I don't use the mode at all, I'll trust that you know what you're doing. > I have used my usage of Adobe Reader and Okular as inspiration for this > mockup, using functionality that is already present in LibreOffice, so that > additional work is kept to a minimum. > > As i know some may be wondering why the print button was removed from the > mockup toolbar, and the reason for that is that there is a print button > still available in the standard toolbar and print is also available in the > File menu and also with Ctrl+P. The print button will still be retained in > the toolbar as the first button, but will be hidden by default. Great. (I'd be in favor of removing it from the toolbar completely, btw.) > In order for this mockup to become a reality, i have already started > submitting enhancement bugs including: > > 1) Bug 80651 - addition of a single page button > 2) Bug 80654 - addition of a close button icon > 3) Bug 80657 - addition of navigator page number field > 4) Bug 80758 - having unnamed icons in a toolbar set to icons & text > > Going beyond what is necessary to achieve the mockup, i'd like to suggest > that the toolbar be centered whenver its activated, and that the text 'Next' > and 'End' be positioned to the left of their icons. I was hoping to have a centered alignment option for toolbars and I talked about it with Kendy, but it seems like the VCL toolbar code is too much of a hassle to deal with. AFAIK, only right-aligned toolbars are technically feasible right now.
(In reply to comment #6) > It's generally bad practice to shorten labels like this, as the clarity of > the original label may be lost ("twin" is pushing it a bit) and as they > advantage a single language only -- "twin" might be longer than "double" in > a different language and it might be hard for translators to deduce what > "prev means". Well if there is a space constraint and the shortened labels can be understood in a particular language, i think its a good thing, because the label is only a supplement to the icon and you also have tooltips to further explain it, if a user doesn't already know what it is. > Also keep in mind that whether a toolbar can fit depends on the window size > -- a toolbar might seem small to you on a widescreen laptop, but it might > not fit on a screen of a netbook. I have always kept the toolbar size in mind, as its size is nearly exactly the same size as the standard toolbar. Presently, the size will look fine at a screen width of 1024. > Fortunately, thanks to last year's GSoC project, we can choose to show only > some icon labels in a toolbar. We should choose only those where the icons > aren't clear -- "Full Screen" and "Close Preview" seem like good candidates. > It'd be better to keep the entire "Close Preview" label, as "Close" is too > vague. (One might think it's referring to closing the document rather than > exiting preview mode.) Well showing some labels and not others will definitely help with Bug 80758. The point of tooltips are to notify a user of what an icon that may not be clear to them means, which is how it works on all other toolbars. We dont go around adding labels to those icons, as the user may not understand what it is. The point of the label based mockup was that we have space to spare and spacing out the icons with labels also makes it easier to click on them as they have larger clickable areas. If a user clicked on 'Close' thinking that it may close the document and it instead closes the print preview mode, that isnt a bad thing because now they know what the button does, if they didnt already get it from the tooltip. But as the close button isnt how a user normally closes a document, i doubt they would assume such a thing. I believe that the close button is only useful in the toolbar if the standard toolbar was hidden when print preview mode was activated. This is so because most users simply re-click the print preview button to exit print preview mode. Here is stats on how users enter/exit print preview in writer. 1) Print Preview Button - 221,865 2) Close Preview Button - 138,042 2) File Menu Item - 60,117 3) Right-Click Menu (Close) - 691 4) Keyboard Shortcut - 212 With these stats you can see that most people re-click the print preview button, if they entered in print preview mode by clicking the print preview button. Users that entered into print preview mode by clicking in the file menu, will likely always click the close preview button, as they might not be aware of print preview button or the standard toolbar may be hidden. These stats are taken from OOo's tracking results < https://wiki.openoffice.org/wiki/Tracking_results > Here is how okular has its toolbar. http://www.kde.org/images/screenshots/okular.png Adobe reader doesn't do it will labels because they also include icons for open, save, print, email, find, text select, image snapshot, page rotation, and help in their toolbar. http://img.brothersoft.com/screenshots/softimage/a/adobe_acrobat_reader-43143-1.jpeg > As for the arrangement of icons, I can't judge which is better. Since I > don't use the mode at all, I'll trust that you know what you're doing. Glad to have your support on that. :) I do use this mode and i'd love to hear the point of view of someone else who uses this mode of what they think of the mockup. > Great. > (I'd be in favor of removing it from the toolbar completely, btw.) Why i thought to keep the print button in the toolbar is that users would have easy access to renable it if they choose and if the standard toolbar was hidden by default, then having the icon there would be crucial. > I was hoping to have a centered alignment option for toolbars and I talked > about it with Kendy, but it seems like the VCL toolbar code is too much of a > hassle to deal with. AFAIK, only right-aligned toolbars are technically > feasible right now. Yes i thought it might be the case and if that is the case, maybe we can divide the print preview toolbar in two. One on the left and one on the right. The right one would contain begin, previous, page jump, next, end, and close. Any knowledge whether its possible to have some icons with their label on the left side within a left-to-right toolbar?
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=747ed5793cbcf7b7a98b33ba4001d0fe20812921 fdo#80838 rearranging the buttons in the toolbar 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.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]