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 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-transparent > * [ <1> ] show large number in large circle, non-transparent > * [ *1* ] show small number in small circle, non-transparent > * [<*1*>] show large number in large circle, non-transparent > * [ ... ] placeholder like small circle, semi-transparent, no > description, no number > * [ --- ] show small number in small circle, semi-transparent, no > number > > [1] > http://wiki.documentfoundation.org/cgi_img_auth.php/d/dd/BSAsee1.jpeg > > Did anybody survive that description? ;-) > > > > > * I've tried to follow your current workflow, added snippets > > > provided by Michael and Rainer ... and considered "getting help" > > > and "joining a user survey". However, the essential part "bug > > > report" would also work "stand-alone". > > > * The structure contains a lot of "Full Description" elements - > > > added for scalability reasons, if the normal field size is too > > > small. So, they can be removed if not needed. > > I'm not sure what you're referring to. Are there the "Read on..." links ? > > Sorry, I haven't been clear enough. I've used some list fields that show > the information like tables (two columns). Rationale: > * The doesn't need to open a drop-down and is able to correct a > wrong selection more easily > * The user sees (a part of the) description right from the start > (e.g. what Chart means) - no need to "select, check description, > open drop-down again, select, check description, open ..." until > he finds the item that fits best > > But, the table does only provide space for (approx. ???) 30 characters, > so we need a full description. That is the reason for adding the full > description below each field. Mabey we need it, maybe not. > > > > * Personally, I think the structure is just a contain to add the > > > real workflow like the one by Michael. I don't know what's > > > currently planned, but it would provide more guidance (asking > > > for crashes, rendering fidelity ...). > > > I suppose the bug report will eventually be a tree of decisions. Because of > > that > > it won't be possible to display all the steps in advance on the leftmost > > menu. But > > for now it is and changing later should not be too much of a problem. > > Should be covered in my example above. > > > > * I've left some placeholders due to missing time and missing > > > knowledge, here it would be great if the others could jump in to > > > help us finalize the work. > > > * I might have missed some (or many) details, since I've tried to > > > avoid reading further mails this evening ... aehm ... night :-) > > > * And, grr, already found some caption mistakes after > > > uploading ... but that doesn't affect the concept. > > > > > > Feedback appreciated ... :-) > > > > > There are two technical issues that impact the user experience. > > > > a) the fact that the bug assistant cannot register a new user (this > > has been covered extensively already and there is nothing to add, I > > think) > > Okay, but I had hoped this is considered already ... that's the reason > for asking the user to come back once the registration is finished (see > the preparation step of the BSA). > > > b) the fact that bugzilla only allows for an attachment once the bug > > is created. It means that no attachment can be required to the user > > *before* the bug is submitted. Of course, the bug assistant could hide > > this from the user. For instance the bug could be submitted just > > before the first attachment is required from him. However, since the > > goal of the bug submission assistant is to reduce the number of bugs > > that are poorly described, this should be done only after there is > > enough information in the bug report, so that even if the user gives > > up before attaching the document the created bug report is useable. > > > > It is possible to workaround this limitation (attachments). However > > that implies the creation and maintainance of a server side temporary > > cache for attachments. This is not complex, but it adds a new layer to > > the bug submission assistant. It currently is client side only and > > there are no server side part. I'm happy to implement it if you think > > it's worth the trouble but I wanted to let you know what it entails, > > technically. > > I've stumbled across the "no whiteboards entry" and "no attachments" > when submitting the bug for the first time as well ... of course it is > possible to work around that and to ask the user afterwards for one or > more attachments. The only thing is, that we have to clearly communicate > that in advance. So let's try to guide the user accordingly ... if it > doesn't work, then "we" might rethink the server cache stuff. > > [...] > > > I'm expecting proposals from a web designer [...] > > The work you've done with > > http://wiki.documentfoundation.org/File:BSAinteraction.png makes it a > > lot easier for them to understand what's going on. Much easier than > > playing with the live example. > > Hehe, thanks for the feedback ... indeed, that's the intention. Such > mockups make it usually easier to "connect" and to discuss with peoples > from different domains. And it helps me to understand the workflow ... > > [...] > > 40 minutes past midnight ;-) > > Cheers, > Christoph _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: [email protected] Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
