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 -
replacing the file you've uploaded for me (thanks!):
Comments on the new version:
* It is still a draft ...
* I refined the structure so that it matches better with the
design proposal you've send to me (navigation on the left side,
more dominant header).
* Added a few more steps and thought a bit how things could be
explained in a rather user-friendly language (whereas I tried to
be as understandable as possible until the bug report assistant
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
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
* 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 ?
* 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.
* 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)
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.
Since this mail is send to the QA list / Design list as well, I'll keep
most of the discussion we had so far.
I'm expecting proposals from a web designer participating in the following contest
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.
Am Dienstag, den 13.09.2011, 10:01 +0200 schrieb Loic Dachary:
On 09/13/2011 12:44 AM, Christoph Noack wrote:
So I've started to read most of the specs lying around and tried to
understand the motivation by Rainer and Michael. Next, I've tried you
bug report assistant and read the mails discussing that topic on the
mailing list. Finally, I've tried to come up with my own point-of-view
in a mockup (which is far from being completed):
It's a great illustration of what I have in mind, except for the left
part which is outside the scope of the bug submission assistant (I
hope ;-). I wish I would be able to do such nice schematics.
A first feedback from your side would be great!
* The "intermediate page" that allows people to provide feedback
via different methods is something I'd like to have for our
users. To me, it seems less important for your work I guess.
* I assumed that the content is embedded into some other website,
e.g. the LibreOffice website.
yes, in an iframe https://www.libreoffice.org/get-help/bugTest/?stage=Stage
* The first step is a mixture of Michael's proposal and the one
I've made ago ... selecting the main components via buttons (or
whatever can be done) and offering a container (or whatever...)
to provide a full list if people are able to understand that.
I understand the rationale.
* Next, the whole design doesn't feel right yet ... unfortunately
we lack the time for relaxed iterations, so it should be
considered as "something".
* I've added the mockup to Picasa if you want to discuss it with
other people ...
* Like the usual usability driven mockups, the visual design isn't
available (missing colors icons, ...). Thus ...
I got a design proposal that implements your "Report a Problem" box, I think (see attached).
What do you think ?
I think it will work well ... I had a few concerns whether people
understand the sequence of the steps (at the moment, it rather looks
like the tabs in recent software or on websites), but for a first
iteration it's great.
The only things I'd like to mention are that we usually don't use drop
shadows and that we try to use lots of white - so the header may be a
bit too dominant.
For the visual design, we currently have the following resources:
[... already added to the wiki page by your side ...]
Maybe this helps to get an idea how the final design could look like.
It makes things a lot clearer for me, indeed.
The only thing I'll be missing is someone to slice the images from the
mockup, so that I can work the CSS/HTML integration. I have limited
skills with regard to producing images for background, buttons etc.
and the web designer won't do it.
I hope somebody can jump in - as I mentioned before, joining tomorrow
(maybe even the day after) is impossible :-\
This is going to be good, I feel it :-)
Hehe, that sounds good ... its fun to work on that. And its extra fun,
because of the great resources available you've made available
(pictures, prototype, ...).
Unsubscribe instructions: E-mail to email@example.com
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
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy