Re: [libreoffice-design] Design principles
Hi Mirek, Am 06.05.2012 17:29, schrieb Mirek M.: I thought it was about time to draft some design principles, so I put up a draft on my user page: https://wiki.documentfoundation.org/User:Mirek2#Design_Principles Tell me what you think. :) Your focus is rather on UI. But this is only one part of our design team. What about VI (Visual Identity, Graphical Design)? -- Grüße k-j -- 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
Re: [libreoffice-design] Design principles
Hello Mirek, great effort to do that! It seems to be based on Android's UI design principles... amiright? I'd like to comment on the goal of being focused: Focus on doing ONE thing well. Writer is for producing great-looking documents, Impress for supplementing a great speech, Calc for interpreting data. Additional features, like HTML controls for Writer, should be available to the user as extensions, not shipped with the product. Necessary features that aren't related to what the user is doing (e.g. Quit, Recent documents, New file in Writer) should be tucked away. While this is a laudable goal for some software, it's probably not a goal that's too helpful for LibO which currently is more of a jack of all trades and which has its strengths in being that. For office productivity software, one of the important things are comparison tables. In these tables, things like exports to HTML, support format XYZ, can create organigrammes all get you points. So, that's where this project comes from: trying to match MSO in a comparison table + a little authentic innovation. Obviously, LibO has a number of rough areas, the further out you get, the rougher it is. Obviously, it should be more focused, for instance, there's no excuse to ship a scanner module (that's only usable from inside one of the applications anyway), because MS doesn't do that either. Then, you have your example of Form Controls – I _guess_ these are most often used for writing macros for LibreOffice, not for exporting to HTML. Astron. -- 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
Re: [libreoffice-design] Design principles
2012/5/6 Stefan Knorr (Astron) heinzless...@googlemail.com Hello Mirek, great effort to do that! It seems to be based on Android's UI design principles... amiright? They weren't really based on any principles. Though I've drawn inspiration from some other companies' design principles, I wanted to craft my own. I'd like to comment on the goal of being focused: Focus on doing ONE thing well. Writer is for producing great-looking documents, Impress for supplementing a great speech, Calc for interpreting data. Additional features, like HTML controls for Writer, should be available to the user as extensions, not shipped with the product. Necessary features that aren't related to what the user is doing (e.g. Quit, Recent documents, New file in Writer) should be tucked away. While this is a laudable goal for some software, it's probably not a goal that's too helpful for LibO which currently is more of a jack of all trades and which has its strengths in being that. Even an advanced office suite needs to be focused. As I specified, I see Writer as a tool to create great-looking documents. That doesn't mean it can't export to HTML -- of course it can. An HTML document is just as valuable as an ODT document. What it does mean, though, is that Writer's workflow needs to be concentrated at creating a great-looking document. All the tools within Writer should help the user do that. If the user wants to create a website with Writer (which I wouldn't recommend, as there are better tools for that), he can download an extension to help him accomplish that. For office productivity software, one of the important things are comparison tables. In these tables, things like exports to HTML, support format XYZ, can create organigrammes all get you points. So, that's where this project comes from: trying to match MSO in a comparison table + a little authentic innovation. I guess we have very different ideas about what LibreOffice should be. I'd like LibreOffice to stand its own, have value not as a Microsoft alternative but as a powerful suite of applications that each has its specific goal and meaning. File format support is important, I agree, but it has no influence on how a piece of software is designed. Obviously, LibO has a number of rough areas, the further out you get, the rougher it is. Obviously, it should be more focused, for instance, there's no excuse to ship a scanner module (that's only usable from inside one of the applications anyway), because MS doesn't do that either. Again, I'd prefer to judge LibreOffice on its own rather than compared to MS Office. The scanner module could actually be very useful if done correctly, perhaps if included as a tab under the Insert image dialog. Then, you have your example of Form Controls – I _guess_ these are most often used for writing macros for LibreOffice, not for exporting to HTML. -- 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
Re: [libreoffice-design] Design principles
Hi Mirek, Even an advanced office suite needs to be focused. As I specified, I see Writer as a tool to create great-looking documents. That doesn't mean it can't export to HTML -- of course it can. An HTML document is just as valuable as an ODT document. What it does mean, though, is that Writer's workflow needs to be concentrated at creating a great-looking document. All the tools within Writer should help the user do that. If the user wants to create a website with Writer (which I wouldn't recommend, as there are better tools for that), he can download an extension to help him accomplish that. For office productivity software, one of the important things are comparison tables. In these tables, things like exports to HTML, support format XYZ, can create organigrammes all get you points. So, that's where this project comes from: trying to match MSO in a comparison table + a little authentic innovation. I guess we have very different ideas about what LibreOffice should be. I'd like LibreOffice to stand its own, have value not as a Microsoft alternative but as a powerful suite of applications that each has its specific goal and meaning. Our ideas where it should be are not so different, I think. :) However, the most important (paying) customers for LibreOffice are huge bureaucracies that will indeed create a table of necessary features and use that to compare the available solutions. So, that's what the core developers get paid for, too. Specifically: * fixing crashes/freezes * improving performance * matching MSO features (to ease migration) * opening foreign file formats (to ease migration) Also, a likely factor in LibO having so many half-baked features is that it's so much more interesting to do something new than to improve someone else's stuff. In that way, LibO's organicity also is a huge burden. File format support is important, I agree, but it has no influence on how a piece of software is designed. Well, these were examples. The scanner module could actually be very useful if done correctly, perhaps if included as a tab under the Insert image dialog. I believe that scanning isn't part of LibO's core competences (we don't even have a pixel image editor) and that all current OS's include better tools already. In the case where they (Windows XP and Mac OS 10.4/5 (?)), such a tool always comes with the scanner itself. Thus, integrating with these tools should be the best idea there. But again, that was an example. Astron. -- 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
