Hi Christoph, Love what you guys are doing here, looks great.
Cheers, Andrew On Fri, Sep 16, 2011 at 5:54 PM, Christoph Noack <[email protected]>wrote: > 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 > > > > -- > Unsubscribe instructions: E-mail to [email protected] > 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 > -- Unsubscribe instructions: E-mail to [email protected] 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
