Hi everyone, a few days ago, Andrew asked for feedback on Mirek's Citrus proposal. So, here, I want to start a thread on what I/we like and what I/we don't like (about the desktop/laptop proposal), in the hope that it helps Mirek to refine his proposal. Please note, I am not a regular reader of Mirek's blog and my assumptions are based on the short descriptions from the wiki, so if anything on this list seems wrong to you, feel free to correct me. Here we go, structure is as on Mirek2's wiki page:
* Ellipsis menu: I like the idea and it looks much better (cleaner) than it does currently; for executing commands it is also more functional. Here's what I don't like: that you can customise your toolbar via drag-and-drop is not made visible at all; for users of accessibility solutions there seems to be no way to add or remove something. * Page/slide handles: I like the idea (so much I opened a bug about it – fdo#38597). There's a lot to discuss, though, before this can be implemented (how it zooms, how it acts, etc.). Also, the proposal doesn't work at all for Calc (which Mirek explained, he uses so seldomly that he didn't include it in his proposals). * Continuously scrollable slides: Not a bad idea for the read-only mode. When editing a document, however, there will sometimes be the case that an image or other element would overlap into the next slide. What should LibO do then? Push the slide further below? Cut the element off in between the two slides? I'm sceptical. * Add page/slide: I can see this being very useful in Impress and Draw, but in those programs, I would probably put this button into the sidebar. For Writer, it would be similarly useful, but we'd also need more complexity: it'd need at least a "Add page" and an "Add Section" button (unless there is any way in which we can make those two commands the same). *Float bar: I'm not sure that I heavily subscribe to this – there is a similar bar in the Pencil extension for Firefox that I use for mock-ups that pops up when one edits certain text fields. I think the most important aspect for the float bar is that it keeps a large enough distance from the element, so it doesn't annoy the user or gets in the way; and still is not positioned so far from the element that the user thinks it doesn't belong o the element any more. There are a few other positioning questions that need to be solved: if the element covers the entire screen, where would the float bar be least in the way (it can either cover the element itself or cover the docked toolbars or maybe could be positioned vertically) ... what's the best option? * Insert bar: This is an idea from Ooo 1.0, I think. I'd love to know why it was abandoned, then, because it probably is a good idea..? * Live preview: An MSO idea. I am unsure how much I like it, but I am pretty sure that developers will protest at its resource usage. The idea is also not very detailed. * Color-coded icons: This is a really good idea. But, I think, the codification is wrong. Currently there are too many shades that are so close to each other that no user will associate them with their underlying functional aspect. Similar shades would appear clustered in certain application (textual shades → Writer). Two ideas: → reduce the shades to only a few (~5) → maybe use menu titles as the basis for which command should have an icon of which shade (one for file actions, one for editing, viewing, formatting...) I'd love to see if such a colour coding system is viable. I'd also love to know if it is problematic for colour-blind or otherwise visually impaired users. By the way, building such an icon set is something the design team can do on its own (all you need is a zipping tool, graphics software, a file manager and lots of time) – so it could be the first part of Citrus that would actually be implemented. * Reduced standard toolbar: I agree, mostly. I think Print is essential though. I always hide Email (because I am a bit of a Ctrl frk and always open documents again before sending, then drag/drop them from the file manager into the mail application), but I think many people would see Email as equally essential. Finally, there is a command that I often use, but that doesn't fit the standard toolbar even today: Non-printing Characters. Where could it go or do we not need it in the toolbar? (I am assuming the Gallery would become part of the Insert toolbar – is that correct?) * Drop-down buttons: Creates a lot of functional inconsistency, I don't think users would like it. But we can agree on the direction of the arrows. * Sorting out commands: Good principles, basically, but probably too rough to be usable in their current form. Point two (no greyed-out buttons) is contradictory to the reasoning found under Reduced standard toolbar (clickable buttons as indicators). Also, this is part of the proposal is throwing (useful) conventions out of the window: should we really move Cut, Copy and Paste into completely different menus? * Getting rid of formatting dialogs: Granted, I am biased here [1], but I don't like interacting with menus in this way at all, even though that's something Microsoft Office makes heavy use of. It is also a huge, huge, huge amount of work for an unclear (to me) benefit. Two disadvantages of relying so much on rich menus: → opening menus to change anything all the time should be pretty annoying → customising styles is made very hard (we should want people to use styles, so they can create more coherent looking documents more easily!) * Combining navigator and side pane. I never actually use the Navigator, but I think that's an idea (a very rough one, though) worth investigating. * Simplified Options: I am pseudo-actively working on a proposal here [2], so yes, absolutely. * Rich menus: In principle, yes, but I wouldn't base the whole UI on them (rf. Getting rid of formatting dialogs). Overall, this proposal is quite coherent (and radical and creative) and that's all good, but there are still too many loose ends hanging around. Blip. Astron. [1] http://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout [2] http://wiki.documentfoundation.org/Design/Whiteboards/OptionsRework -- Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
