Re: [libreoffice-design] Future libreoffice.org web page: design request
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 , 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 for removing steps. Note: The bullet points show the most simple linear use case we will implement now, I assume. I hope that explains most of the behavior - I hope some of the basic ideas came through (and hopefully I did not make too many mistakes). Let's see how to transform that into visual feedback ... using [1] as a reference. * [ 1 ] shown small number in small circle, semi-trans
[libreoffice-design] Re: [Libreoffice-qa] Bug Submission Assistant : status report
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. > > * See: My favorite so far ... > * because: > * everything is grouped in a box ... easy to > understand what belongs together > * the understandability of the sequence steps > (left side) is much better than in the last > iteration > * but: > * The text "BugText" does not fit into our > branding scheme > * 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 > * 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 > 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 ? 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. > [...] > > Hope this helped a bit ... Very much :-) 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
[libreoffice-design] Re: [Libreoffice-qa] Bug Submission Assistant : status report
Hi Lic, hi all! CCing the Design Team ... please reply to the QA list. Am Donnerstag, den 15.09.2011, 22:12 +0200 schrieb Loic Dachary: > Hi, > > Today was mostly about the web design. There are three candidates > designs > (http://99designs.com/web-design/contests/bug-submission-web-form-design-wanted-libreoffice-95945) > that I just uploaded at > http://wiki.documentfoundation.org/Bug_Submission_Assistant_-_ToDo#Deliverables > I would really like your input. If nothing else a simple "I better > like this URL" will suffice. Oh, thanks for the links ... we should really avoid to let the BSA look much better than LibreOffice itself ;-) To be serious, I'd like to judge on the basis of our branding guidelines and some usability findings - that makes choosing the right one a bit easier. > When commenting on these proposals, please bear in mind that > a) it's a contest and only one designer will be paid, > b) the deadline of the contest is in 48 hours, > c) the prize is USD$495 (thanks to Free Software Foundation France for > funding this work). Very cool - I wasn't aware that FSF is so kind to fund this :-) As an additional note - do we get the "source code" to work on further refinements / changes after the challenge is over? > When interacting with the web designers, I heavily relied on Christoph > Noack interaction schematics > ( http://wiki.documentfoundation.org/cgi_img_auth.php/d/df/BSAinteraction.png > ) with one noticeable difference : I stick to a one page application instead > of implementing the "Next" button allowing for multi pages, because the multi > page interaction has not been defined yet. Hope to do that today ... at least a bit. > My goal is to integrate the web design that will be available in two > days so that the minimal version of the bug submission assistant is > better looking than it currently is. My dream is that the web design > produced will be useful for the evolution of the bug submission > assistant. Okay, so here is what I think - basically each of the designs needs tweaking to really fit, but one fits more than the other: * Hitron: While quite similar to the LibreOffice UI, the texts are hard to read (accessibility) and the tree views are incorrect (usability). Furthermore, it doesn't really fit to the branding guidelines stating e.g. "Friendly: The visual design creates a smooth and joyful environment. For example, rounded corners and the fresh color palette are used.". * Iva: I think it fits a bit better from the visual POV, although I've found some usability issues. For example, the captions (the green bubbles) might look like buttons for some - the closed design does not refer to the input fields. Furthermore, the grouping via the gray background is sometimes a bit strange (doesn't include that should be grouped). Furthermore, the information element (orange) in the lower right is too far away from the name/password input ... people might not notice it. * See: My favorite so far ... * because: * everything is grouped in a box ... easy to understand what belongs together * the understandability of the sequence steps (left side) is much better than in the last iteration * but: * The text "BugText" does not fit into our branding scheme * 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 * 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 We should "See" whether some of these things could be resolved ... then we get close to perfectionism ;-) 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 [...] Hope this helped a bit ... Cheers, Christoph -- 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
[libreoffice-design] Personal Summary: Hackfest 2011
Hi all, since I think its interesting for the Design Team, I've wanted to shed some (personal) light on what happened at the Hackfest in Munich two weeks ago. So maybe some inspiration for other topics ... or simply some entertaining. Up to you to decide :-) http://luxate.blogspot.com/2011/09/personal-hackfest-2011-summary.html Cheers, Christoph -- 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
