[libreoffice-design] Where to submit feedback for template and extensions website?
Hi all, Do you know how I could provide feedback for the new repository? Maybe the web admins mailing list? I am wondering, because I think the old OpenOffice repository already looks very good feature-wise and in my opinion a clone would be the best option. Kind regards Alex -- 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] Introduction
Hi Nate, Welcome to the team :) Alex Am 14.09.2011 17:39, schrieb Nathaniel Schultz: Heh, I joined the lists a month or two back, but work got hairy, and then it ended. Suffice it to say, I was distracted. My applicable background is primarily user-interface design and programming. (I'm also a bit of a data guy and my degrees are in bioengineering, so I don't actually consider myself a programmer, or even UI designer, but I've done both.) I've been doing things with Star Office kin for quite some time, and switched to Libre Office this year. (What can I say? SVG support sold me. I hate juggling resolutions on bitmaps in documents.) One thing I've noticed in OO.o and friends is the continual improvement. When I wrote my thesis, my school used some really picky formatting rules. In OO, The only way to consistently achieve that was manually tweaking the page and paragraph formatting. I ended up using another word processor. Now, the solution would be tricky ugly, but it's possible. (The school's rules have now relaxed considerably, too: Now that Libre Office can do the picky stuff, the new grad student don't have to.) In many significant ways, I consider Libre Office already superior to MS Office, but I'd like to assist making that unconditional. I've been pondering a few issues, and actually have a few specific comments to lay on you shortly. -Nate Schultz -- 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] Introduction
Hi Alex, Nathaniel! Somehow missed to respond to this mail ... thanks for the reminder, Alex ;-) Nathaniel, welcome to the team ... if you have any questions or comments, then please go ahead :-) Cheers, Christoph Am Freitag, den 16.09.2011, 22:02 +0200 schrieb Alexander Wilms: Hi Nate, Welcome to the team :) Alex Am 14.09.2011 17:39, schrieb Nathaniel Schultz: Heh, I joined the lists a month or two back, but work got hairy, and then it ended. Suffice it to say, I was distracted. My applicable background is primarily user-interface design and programming. (I'm also a bit of a data guy and my degrees are in bioengineering, so I don't actually consider myself a programmer, or even UI designer, but I've done both.) I've been doing things with Star Office kin for quite some time, and switched to Libre Office this year. (What can I say? SVG support sold me. I hate juggling resolutions on bitmaps in documents.) One thing I've noticed in OO.o and friends is the continual improvement. When I wrote my thesis, my school used some really picky formatting rules. In OO, The only way to consistently achieve that was manually tweaking the page and paragraph formatting. I ended up using another word processor. Now, the solution would be tricky ugly, but it's possible. (The school's rules have now relaxed considerably, too: Now that Libre Office can do the picky stuff, the new grad student don't have to.) In many significant ways, I consider Libre Office already superior to MS Office, but I'd like to assist making that unconditional. I've been pondering a few issues, and actually have a few specific comments to lay on you shortly. -Nate Schultz -- 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] Re: [Libreoffice-qa] Bug Submission Assistant : status report
Hi Loic, all! Am Freitag, den 16.09.2011, 00:07 +0200 schrieb Loic Dachary: Hi, As an additional note - do we get the source code to work on further refinements / changes after the challenge is over? I will provide the deliverables as a layered XCF file and it will be under GPLv3+ as the code. That's great - XCF and SVG files is something we can easily work with (whilst SVG provides a bit more flexibility). * See: My favorite so far ... Oh, See already has made an update - excellent progress and very close of what I had in mind :-) http://wiki.documentfoundation.org/cgi_img_auth.php/7/75/BSAsee01.jpeg [...] * but: * The text BugText does not fit into our branding scheme Has been corrected. The current font decision resides here: http://wiki.documentfoundation.org/Marketing/Branding#Fonts * Furthermore, the textured background for Submit and the header is a bit different to what we use ... if possible, a green on (different) green motif should be used for large areas Already fixed. The motif examples might have helped here... http://wiki.documentfoundation.org/cgi_img_auth.php/7/7b/ROUGH_postcard_PRESENTED.jpg http://wiki.documentfoundation.org/cgi_img_auth.php/b/b3/ScatterInContext_bunch.jpg * the dashed lines do not fit and adds visual noise * the Submit button is something good - red/orange is a warning color (in most countries), e.g. blue would fit better Also fixed, looks very nice and is far better from the usability point-of-view; colors according: http://wiki.documentfoundation.org/Marketing/Branding#Colors Could you please add URLs (as precise as possible) explaining the relevant part of the branding scheme for the text or the required textured background ? I've noticed that they don't have time to research or read more than what is strictly necessary. I don't understand what you say about the dashed lines. Do you mean they don't fit the branding scheme and should be removed ? To be honest, we've never decided on the user of whatever lines ... so there is neither a best practice nor a guidelines. But, dashed lines are something that catch attention - good if that's required, less good if the surrounding elements do have priority (here, the line was just a divider). And for the sake of completeness - the branding page also covers a temporary description of the intended visual design: * Clean: The visual design is straight and clean. Reduced geometric elements are combined to visualize the intended message. * Balanced: The visual design avoids any extremes. For example, neither extreme coloring nor intensive surface shining effects are used. * Friendly: The visual design creates a smooth and joyful environment. For example, rounded corners and the fresh color palette are used. Nik, who puts lots of work into the motif and the website, added some time ago use lots of white. I communicated your remarks to see anyway but it would help for me to know more ;-) By the way, I don't know whether it is possible, but maybe the designers could add a large problem icon based on the Tango icons set (default in LibO)? http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines Could you please phrase this a self contained request ? I'm sure see will agree to it if time allows. Okay, but only if it fits, since I don't have any clue how binding the 99designs work description is. Rationale: Bugs aren't funny, but for our website it would help to have a visual anchor that tells the user bug this way, please. Furthermore, a hiqh quality graphic lets us appear more professional ... although it is still the same product (note: users tend to be more forgiving, if the product - the BSA - is a pleasure to use) Request: Create an graphic that can be used to refer to bug reporting for a) in the product LibreOffice, b) the bug submitting assistant, c) the feedback selection website. If the detail level is mid and the file type vector (SVG), then we can adapt and tweak it afterwards. Visual Design Hints: * Primary: Consider the Tango Desktop Icons styleguides * Secondary: Consider the LibreOffice branding guidelines Proposal: I don't have any proposal for a metaphor ... :-\ Examples: * If I remember correctly, Ubuntu uses a black exclamation mark on an orange explosion callout sign. * Bugzilla uses/used: http://www.brightcreative.com/i/projects/bugzilla-lg.gif * I once created a cracked note to symbolize the work in progress when we've worked on the Writer comments feature: http://wiki.services.openoffice.org/wiki/Notes2_Development_Releases
[libreoffice-design] Re: [Libreoffice-qa] Bug Submission Assistant : status report
On 09/16/2011 11:11 PM, Christoph Noack wrote: Rationale: Bugs aren't funny, but for our website it would help to have a visual anchor that tells the user bug this way, please. Furthermore, a hiqh quality graphic lets us appear more professional ... although it is still the same product (note: users tend to be more forgiving, if the product - the BSA - is a pleasure to use) Request: Create an graphic that can be used to refer to bug reporting for a) in the product LibreOffice, b) the bug submitting assistant, c) the feedback selection website. If the detail level is mid and the file type vector (SVG), then we can adapt and tweak it afterwards. Visual Design Hints: * Primary: Consider the Tango Desktop Icons styleguides * Secondary: Consider the LibreOffice branding guidelines Proposal: I don't have any proposal for a metaphor ... :-\ Examples: * If I remember correctly, Ubuntu uses a black exclamation mark on an orange explosion callout sign. * Bugzilla uses/used: http://www.brightcreative.com/i/projects/bugzilla-lg.gif * I once created a cracked note to symbolize the work in progress when we've worked on the Writer comments feature: http://wiki.services.openoffice.org/wiki/Notes2_Development_Releases Hi, I sent this to see. Let's hope he can make provide something within the next 24h (project deadline). I will not block the completion if he does not. I think your description is very detailed and will allow him to fully understand the idea. Cheers -- 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] Future libreoffice.org web page: design request
Hi all, after my rather lengthly explanation yesterday, here is an structural example (based on See's design) of how it could look like: https://picasaweb.google.com/lh/photo/PLZvWTs1NiL_w3auPyfUjA?feat=directlink Cheers, Christoph Am Freitag, den 16.09.2011, 00:40 +0200 schrieb Christoph Noack: Good evening Loic! 18 minutes to go before tomorrow gets today ;-) Am Mittwoch, den 14.09.2011, 12:57 +0200 schrieb Loic Dachary: On 09/14/2011 01:01 AM, Christoph Noack wrote: Hi Loic, hi all! I've refined the interaction design a bit and uploaded it to the wiki - [...] I noticed the next button and the fact that each step would be displayed on its own. I assume that the user would be able to click on a previous step to amend its choice. Is that right ? Yep, otherwise the progress indicator on the left side isn't that much needed ... the Next approach helps to slice the required information in reasonable chunks being (hopefully) more understandable, and it ensures a constant screen height. Of course, there are other solutions ... but not knowing exactly the workflow and the questions, I assumed this to work best. If it is the case, let say (s)he changes the component. How would (s)he be notified that a new subcomponent must be chosen ? In the case of a single page displaying all the information, I though there would be an error message + red border around the missing field. With a multipage display I can't picture how it would work Okay, there are some assumptions on my side, so let's go through some use cases. I lack the time to do the example graphics, so I hope some descriptions are sufficient to understand it. I hope something like that can be done technically ... The problem: * We have procedure of several steps, * the procedure might be tree like instead of linear, * (future) steps may be added when working with the wizard * (future) steps may also be removed when working with the wizard, * the user might choose to go back and to change options, * selected steps need to be checked for consistency/correctness, * assumption: the user can only continue to the next step, if the current step (and the steps before) are valid. So, we need to introduce some states for each step (the stuff in the squared brackets will be used for further description): * not available * [ 1 ] a step with number 1 not worked on yet * [ 1 ] a step with number 1 already currently being worked on * [ *1* ] a step with number 1 already finished * [*1*] a step with number 1 already finished (before), currently being worked on (because user visits it again) * [ ... ] a placeholder for one or more steps not worked on yet and not known yet (because we have to implement the tree like procedure) * [ --- ] a step not worked on yet after [ ... ]; step number cannot be calculated, but the action is known Example: [ *1* ] Preparation [ *2* ] Component [ 3 ] Sub-Component [ 4 ] Version [ ... ] [ --- ] Description [ --- ] Submit [ --- ] Attachment It might look overly complex, but I'm sure you know such indications from websites and other software. Let's dig into it ... the use cases (each of the cases starts with the conditions in the example above). Current: The user works on step 3, he successfully completed steps 1 and 2. The next step 4 requires to chose the LibO version - but this may have impact on insert_reason_here, so we may need additional step(s) [...]. Therefore, we skip the numbers for Description, Submit and Attachment. Go back: User goes back to step 2 but doesn't change anything. * [ *1* ] Preparation * [*2*] Component * [ 3 ] Sub-Component * [ 4 ] Version * [ ... ] * [ --- ] Description * [ --- ] Submit * [ --- ] Attachment Note: If the user changes the component in step 2, then (in our constructed case) all future steps are dependent and get set to not worked on yet. Go forward: The user choses to have a look at one of the steps not yet done. Here we have two alternatives (technical constraints will decide here): 1. We don't offer to go there (inactive button) 2. We show the BSA page, but the whole page content is inactive Add steps: The user selects the sub-component in step 3 and confirms. Now we are sure that we need two additional steps - the workflow is linear now. So we can add step 5 and 6, and the remaining steps can get numbers as well: * [ *1* ] Preparation * [ *2* ] Component * [ *3* ] Sub-Component * [ 4 ] Version * [ 5 ] Whateveroption * [ 6 ] Evenanotherwhateveroption * [ 7 ] Description * [ 8 ] Submit * [ 9 ] Attachment Note: This behavior is similar
Re: [libreoffice-design] Re: [Libreoffice-qa] Bug Submission Assistant : status report
Hi all, just wanted to share my first ideas regarding the icon for the bug-report pages. It's simply a LibreOffice icon with red borders and a little warning sign containing an exclamation mark. Its not based on the tango guidelines or the LO color-palette, only a draft. SVG: http://ubuntuone.com/0E5q1IRdAY6Zox59CCZp4N Hope this somehow helps the design process Greetings Alex Am 16.09.2011 23:11, schrieb Christoph Noack: Hi Loic, all! Am Freitag, den 16.09.2011, 00:07 +0200 schrieb Loic Dachary: Hi, As an additional note - do we get the source code to work on further refinements / changes after the challenge is over? I will provide the deliverables as a layered XCF file and it will be under GPLv3+ as the code. That's great - XCF and SVG files is something we can easily work with (whilst SVG provides a bit more flexibility). * See: My favorite so far ... Oh, See already has made an update - excellent progress and very close of what I had in mind :-) http://wiki.documentfoundation.org/cgi_img_auth.php/7/75/BSAsee01.jpeg [...] * but: * The text BugText does not fit into our branding scheme Has been corrected. The current font decision resides here: http://wiki.documentfoundation.org/Marketing/Branding#Fonts * Furthermore, the textured background for Submit and the header is a bit different to what we use ... if possible, a green on (different) green motif should be used for large areas Already fixed. The motif examples might have helped here... http://wiki.documentfoundation.org/cgi_img_auth.php/7/7b/ROUGH_postcard_PRESENTED.jpg http://wiki.documentfoundation.org/cgi_img_auth.php/b/b3/ScatterInContext_bunch.jpg * the dashed lines do not fit and adds visual noise * the Submit button is something good - red/orange is a warning color (in most countries), e.g. blue would fit better Also fixed, looks very nice and is far better from the usability point-of-view; colors according: http://wiki.documentfoundation.org/Marketing/Branding#Colors Could you please add URLs (as precise as possible) explaining the relevant part of the branding scheme for the text or the required textured background ? I've noticed that they don't have time to research or read more than what is strictly necessary. I don't understand what you say about the dashed lines. Do you mean they don't fit the branding scheme and should be removed ? To be honest, we've never decided on the user of whatever lines ... so there is neither a best practice nor a guidelines. But, dashed lines are something that catch attention - good if that's required, less good if the surrounding elements do have priority (here, the line was just a divider). And for the sake of completeness - the branding page also covers a temporary description of the intended visual design: * Clean: The visual design is straight and clean. Reduced geometric elements are combined to visualize the intended message. * Balanced: The visual design avoids any extremes. For example, neither extreme coloring nor intensive surface shining effects are used. * Friendly: The visual design creates a smooth and joyful environment. For example, rounded corners and the fresh color palette are used. Nik, who puts lots of work into the motif and the website, added some time ago use lots of white. I communicated your remarks to see anyway but it would help for me to know more ;-) By the way, I don't know whether it is possible, but maybe the designers could add a large problem icon based on the Tango icons set (default in LibO)? http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines Could you please phrase this a self contained request ? I'm sure see will agree to it if time allows. Okay, but only if it fits, since I don't have any clue how binding the 99designs work description is. Rationale: Bugs aren't funny, but for our website it would help to have a visual anchor that tells the user bug this way, please. Furthermore, a hiqh quality graphic lets us appear more professional ... although it is still the same product (note: users tend to be more forgiving, if the product - the BSA - is a pleasure to use) Request: Create an graphic that can be used to refer to bug reporting for a) in the product LibreOffice, b) the bug submitting assistant, c) the feedback selection website. If the detail level is mid and the file type vector (SVG), then we can adapt and tweak it afterwards. Visual Design Hints: * Primary: Consider the Tango Desktop Icons styleguides * Secondary: Consider the LibreOffice branding guidelines Proposal: I don't have any proposal for a metaphor ... :-\ Examples:
[libreoffice-design] Writer: Styles Formatting Ideas
Principle: Users shouldn't have to map their thinking process to the computer. A good UI will map the data to intent to allow (as much as possible) refinement in any order. Styles: Beginning and ending tags of manual formatting versus styles are clumsy to edit, and some of the rules can be awkward. This is where trusty ol' Word Perfect had reveal codes. Given that the underlying data is using an xml format, this is not a wild-eyed request. Simply display things linked to a single tag, and allow a tag to be edited per an appropriate style format dialog. An option to view the rules in play and what styles/manual tags caused them would be grand. Styles have rules in them, some of which are not obvious how to separate, and none are obvious how to simply remove. Once a style has been set to a differing font face from the parent style, for example, it's not obvious how to remove the face change, say, but retain the italics setting. The styles display a nice summary of the contained rules, but deleting things from that list should be easier. There needs to be a dialog of some sort one can call up that makes removing rules or copying/moving rules to another style straightforward. (Groups like font weight/slant/size should probably be lumped together.) It would also be nice to get some options on the rule summary that show the underlying rules their defining styles that are overridden by the rule in question and an option to show all rules defined by the style and its inheritance. When there is no single value possible to display, such as with character styles, a term like Paragraph Defined might work. Conditional Styles are currently bad about this. One may easily define and use a style before realizing that it makes sense to rework some of the logic and redefine a style to be conditional. We need to make a few functions easy in the interface: copy style to new name, copy some rules from style to a new name, and rework normal style into a conditional one. (I assume one can globally search for a style and replace it with another, though I don't know how to do that without a macro, right now.) A few dialogs would need to be written: A dialog for deleting rules, and perhaps another for moving/copying rules to other styles (also deleting them, presumably.) When editing a style, the conditional style trait should simply be a toggled state. One should just edit the style's conditions, one of which, I guess, would be normal. (It could be in an advanced tab hidden from a simple view, but I don't like doing that.) The interface can look like this without a needing to change the lower level stuff, either. The selection of conditional could trigger a new temporary style which gains the rules, and becomes the default conditional style of the new style, then replaces the original. Rename and done. A display for the revealed formatting tags would need to be worked out. (This COULD be some form of insertable mini-icons, (sorta like spaces and tabs with revealed white-space characters) but that seems a smidgen *too* terse.) This interface should allow any proper movement of tags, as well as deletion. These all sorta interact, so I'm placing them together for comment. (Reveal codes should use the other dialogs, such as the 'copy rule into new or existing style' and 'view style rule sources,' and so on. ) Mostly, this is to spawn ideas on how best to approach this issue. I intend to consider further to cement more details. -Nate Schultz -- 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
