Re: [tdf-discuss] Experimental UI for LibreOffice proposal
Your idea of a ribbon turned into a sidebar by 90° rotation imho is nothing else than the revival of the old (pre-Windows) Lotus 1-2-3 menu system. Pulldown-menus (and dialog boxes) are a far more advanced concept. Besides the issues with screenspace. A concept that could be a *lot* more useful imho would be to allow tearing off individual (sub-)menus and placing them as floating (or docked if the user prefers that) toolboxes next to the workspace. See typical graphics software or e.g. RagTime. When I was working in RagTime (or FrameMaker, but that was more than a decade ago), all I had on-screen besides the document itself and the pull-down menubar above were the listboxes with character and paragraph styles and very few other floating palettes. Hmmm, that sounds interesting. To be honest, I liked the image I picked, but I think that when starting, it makes sense to consider other designs. If it turns out you don't want a radically different toolbar, then my proposal is a bad idea. In fact what must be absolutely avoided is to create several different parallel GUIs (toolbars vs. pull-down menus) for the same functionality. If the primary GUI is not ergonomic then fix it. Don't add another, redundant GUI, this is just confusing. Use only pull-down menus, but allow them to be torn off as floating or docked palettes, at the choice of the user. Allow menu items to be text, icons or any combination of both (icons only is a toolbar then). Allow the menu contents to be edited by the user. Allow for definition of shurtcuts for all menu items by users, so that the complete GUI can be entirely used without ever using the mouse, which is important for proficient users. Get rid of those idiotic redundant assistants, wizards or whatever they are called, since they are just yet another parallel redundant GUI. Instead, restructure menus and dialog boxes to make them more ergnomic. A truely ergonomic GUI is necessarily visually spartanic. Application GUIs are work tools that have to follow the rules of ergonomics. They are *NOT* fashion objects. Sincerely, Wolfgang -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Experimental UI for LibreOffice proposal
Hi; On Mon, Mar 11, 2013 at 11:54 AM, Wolfgang Keller felip...@gmx.net wrote: I'm working on a proposal for building an experimental new LibreOffice toolbar / UI in Python: https://wiki.documentfoundation.org/User:KeithCu Err, I would like to point out the fact that trying to emulate MS in any way is always a B-A-D idea. I agree that one should never blindly copy anything MS is doing, especially around radical UI changes which can be disruptive. This proposal is a prototype, which could also be relatively quickly changed based on unhappy user feedback. Your idea of a ribbon turned into a sidebar by 90° rotation imho is nothing else than the revival of the old (pre-Windows) Lotus 1-2-3 menu system. Pulldown-menus (and dialog boxes) are a far more advanced concept. Besides the issues with screenspace. A concept that could be a *lot* more useful imho would be to allow tearing off individual (sub-)menus and placing them as floating (or docked if the user prefers that) toolboxes next to the workspace. See typical graphics software or e.g. RagTime. When I was working in RagTime (or FrameMaker, but that was more than a decade ago), all I had on-screen besides the document itself and the pull-down menubar above were the listboxes with character and paragraph styles and very few other floating palettes. Hmmm, that sounds interesting. To be honest, I liked the image I picked, but I think that when starting, it makes sense to consider other designs. If it turns out you don't want a radically different toolbar, then my proposal is a bad idea. Otherwise, you could build a reasonable experiment in a few months. I would be excited to see what you all came up with, perhaps even two designs / modes ;-) Warm regards, -Keith -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Experimental UI for LibreOffice proposal
I'm working on a proposal for building an experimental new LibreOffice toolbar / UI in Python: https://wiki.documentfoundation.org/User:KeithCu Err, I would like to point out the fact that trying to emulate MS in any way is always a B-A-D idea. Especially, but not limited to GUI ergonomics, where MS has been consistently been implementing things exactly the wrong way, from the perspective of the proficient user who knows also something else than MS. Your idea of a ribbon turned into a sidebar by 90° rotation imho is nothing else than the revival of the old (pre-Windows) Lotus 1-2-3 menu system. Pulldown-menus (and dialog boxes) are a far more advanced concept. Besides the issues with screenspace. A concept that could be a *lot* more useful imho would be to allow tearing off individual (sub-)menus and placing them as floating (or docked if the user prefers that) toolboxes next to the workspace. See typical graphics software or e.g. RagTime. When I was working in RagTime (or FrameMaker, but that was more than a decade ago), all I had on-screen besides the document itself and the pull-down menubar above were the listboxes with character and paragraph styles and very few other floating palettes. Sincerely, Wolfgang -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
[tdf-discuss] Experimental UI for LibreOffice proposal
Hi; I'm working on a proposal for building an experimental new LibreOffice toolbar / UI in Python: https://wiki.documentfoundation.org/User:KeithCu I'm going to add some links to places where the C++ code would need to be changed and a few more tweaks, but I'm interested in feedback. Feel free to use email or post in the discussion page as you prefer. Regards, -Keith -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Experimental UI for LibreOffice proposal
On 03/08/2013 03:44 PM, Keith Curtis wrote: Hi; I'm working on a proposal for building an experimental new LibreOffice toolbar / UI in Python: https://wiki.documentfoundation.org/User:KeithCu I'm going to add some links to places where the C++ code would need to be changed and a few more tweaks, but I'm interested in feedback. Feel free to use email or post in the discussion page as you prefer. Regards, -Keith What is the target display width for your design? We may have users that are using 800 pixel width CRT monitors. So whatever you design to be on the side panel, the work space that the use will be doing the typing and editing in must be wide enough for them to efficiently work with the document file. When I was working with the display withs under 1024 pixels, I found many packages that were not designed to be easily used with the smaller width display/monitors. I have some that do notwork with any display that are less than 800 pixels high, let alone a narrow width. There bottom buttons were not accessible. So please think about the users we may have that need a package UI that work well and easy with a 800 pixel wide CRT display or similar limiting with display. -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Experimental UI for LibreOffice proposal
Hi; This should probably be on the UX mailing list. Also are you developing this also? Finding developers to implement this could be very very difficult - just giving you a heads up in case you don't want to waste a bunch of time for nothing. Best, Joel I'm not planning on developing this. It would be very difficult if built using VCL, etc. The point is to side-step that for now. You could get an intern to make it for Writer. Regards, -Keith -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Experimental UI for LibreOffice proposal
On Fri, Mar 8, 2013 at 1:24 PM, Kracked_P_P---webmaster webmas...@krackedpress.com wrote: On 03/08/2013 03:44 PM, Keith Curtis wrote: Hi; I'm working on a proposal for building an experimental new LibreOffice toolbar / UI in Python: https://wiki.documentfoundation.org/User:KeithCu I'm going to add some links to places where the C++ code would need to be changed and a few more tweaks, but I'm interested in feedback. Feel free to use email or post in the discussion page as you prefer. Regards, -Keith What is the target display width for your design? We may have users that are using 800 pixel width CRT monitors. So whatever you design to be on the side panel, the work space that the use will be doing the typing and editing in must be wide enough for them to efficiently work with the document file. When I was working with the display withs under 1024 pixels, I found many packages that were not designed to be easily used with the smaller width display/monitors. I have some that do notwork with any display that are less than 800 pixels high, let alone a narrow width. There bottom buttons were not accessible. So please think about the users we may have that need a package UI that work well and easy with a 800 pixel wide CRT display or similar limiting with display. To be clear, the underlying image was created by Paulo José. Working on smaller screens is a good question, but you have to get something before you make it work with additional constraints. LibreOffice has two challenges, looking good on the upcoming high-res screens, and working okay on the smaller screens. I think as a start, the focus should be on ~1280 pixels wide screens. -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Experimental UI for LibreOffice proposal
To be clear, the underlying image was created by Paulo José. Working on smaller screens is a good question, but you have to get something before you make it work with additional constraints. LibreOffice has two challenges, looking good on the upcoming high-res screens, and working okay on the smaller screens. I think as a start, the focus should be on ~1280 pixels wide screens. Really not trying to be pessimistic but in all truth, I don't see this happening. I've seen the work before and personally I like it quite a bit but you have three major issues: 1. Lack of any kind of consensus, without UX input it's kind of DOA. Doing a ton of work and then showing it to them seems worse than working with them and getting their feedback as you plan. There may have already been extensive talk about this already within UX, a quick email over there might result in a huge savings of time on your part. 2. Lack of developers to implement -- if you look on FDO you can see a massive list of bugs that are being worked on and awaiting work. Having a developer spend months implementing this is unlikely as they focus on more pressing issues 3. Lack of funds to pay someone else - for this you're really probably talking about $10's of thousands of dollars. Just my two cents, feel free to take it or leave it. Best, Joel -- *Joel Madero* LibreOffice QA Volunteer jmadero@gmail.com -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Experimental UI for LibreOffice proposal
My mistake, thought this was on user list, discuss list seems more appropriate but expanding it to UX list also seems good. Even getting some developer input just to understand what a huge undertaking this is would be useful. Again, personally I like the look ;) Just unsure of the point of discussing it if it's never going to happen -- and I could very well be wrong about that as well, just think the wrong people are being asked if that's the case. Best, Joel On Fri, Mar 8, 2013 at 1:50 PM, Joel Madero jmadero@gmail.com wrote: To be clear, the underlying image was created by Paulo José. Working on smaller screens is a good question, but you have to get something before you make it work with additional constraints. LibreOffice has two challenges, looking good on the upcoming high-res screens, and working okay on the smaller screens. I think as a start, the focus should be on ~1280 pixels wide screens. Really not trying to be pessimistic but in all truth, I don't see this happening. I've seen the work before and personally I like it quite a bit but you have three major issues: 1. Lack of any kind of consensus, without UX input it's kind of DOA. Doing a ton of work and then showing it to them seems worse than working with them and getting their feedback as you plan. There may have already been extensive talk about this already within UX, a quick email over there might result in a huge savings of time on your part. 2. Lack of developers to implement -- if you look on FDO you can see a massive list of bugs that are being worked on and awaiting work. Having a developer spend months implementing this is unlikely as they focus on more pressing issues 3. Lack of funds to pay someone else - for this you're really probably talking about $10's of thousands of dollars. Just my two cents, feel free to take it or leave it. Best, Joel -- *Joel Madero* LibreOffice QA Volunteer jmadero@gmail.com -- *Joel Madero* LibreOffice QA Volunteer jmadero@gmail.com -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
RE: [tdf-discuss] Experimental UI for LibreOffice proposal
I work with a 2560 x 1600 display. One reason is so that I can do work among multiple documents that I keep open at once. I *never* have a document application running full screen on my 30 monitor. I even object to web pages that can't be viewed properly unless the browser-window is kept too wide. And these days, requiring full use of the 1040 x 768 display by a single app on my Tablet PC is also burdensome. I think an important approach to allowing flexible usage, including accommodation of smaller displays, is simplifying what an application window requires kept inside the application window by having as much as possible fly away and also be easily re-expanded and again collapsed. Having more contextual control (e.g., sensitivity of right-click to context) also matters. And, of course, accessibility considerations apply at all sizes and shapes. - Dennis -Original Message- From: Keith Curtis [mailto:keit...@gmail.com] Sent: Friday, March 08, 2013 13:45 To: Kracked_P_P---webmaster Cc: discuss@documentfoundation.org Subject: Re: [tdf-discuss] Experimental UI for LibreOffice proposal On Fri, Mar 8, 2013 at 1:24 PM, Kracked_P_P---webmaster webmas...@krackedpress.com wrote: [ ... ] What is the target display width for your design? We may have users that are using 800 pixel width CRT monitors. So whatever you design to be on the side panel, the work space that the use will be doing the typing and editing in must be wide enough for them to efficiently work with the document file. When I was working with the display withs under 1024 pixels, I found many packages that were not designed to be easily used with the smaller width display/monitors. I have some that do notwork with any display that are less than 800 pixels high, let alone a narrow width. There bottom buttons were not accessible. So please think about the users we may have that need a package UI that work well and easy with a 800 pixel wide CRT display or similar limiting with display. To be clear, the underlying image was created by Paulo José. Working on smaller screens is a good question, but you have to get something before you make it work with additional constraints. LibreOffice has two challenges, looking good on the upcoming high-res screens, and working okay on the smaller screens. I think as a start, the focus should be on ~1280 pixels wide screens. [ ... ] -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Experimental UI for LibreOffice proposal
Hi; On Fri, Mar 8, 2013 at 1:50 PM, Joel Madero jmadero@gmail.com wrote: To be clear, the underlying image was created by Paulo José. Working on smaller screens is a good question, but you have to get something before you make it work with additional constraints. LibreOffice has two challenges, looking good on the upcoming high-res screens, and working okay on the smaller screens. I think as a start, the focus should be on ~1280 pixels wide screens. Really not trying to be pessimistic but in all truth, I don't see this happening. I've seen the work before and personally I like it quite a bit but you have three major issues: Many things are harder than a Python Writer toolbar built by someone with the skills of a college intern. Depending on how you implemented it would tell you how much it cost. The only new C++ code is in a way to dock this Python toolbar so it looks like it belongs. The C++ changes to LibreOffice here are a lot smaller. It could even start as a separate extension / window, and ignore all these difficult C++ changes indefinitely. I agree you shouldn't take your busy people away from their tasks. There are many things to be done that are higher priority than experimental. However, if it becomes useful to some even while unfinished, it is then adding value back like the other experimental features. It could also be a source of ideas for incremental improvements to other parts of LibreOffice. A task like this will need mentoring, every volunteer is being mentored somewhat, so you can seemingly afford one more. If any designers are comfortable with Python hacking, they could implement some of their ideas and cut devs out of the bottleneck. There are many bitmaps that could be used in the spec. The person doing the work would have to figure out what it will precisely look like and behave, with feedback from other people. I haven't seen a more official bitmap. -Keith -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.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.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
