[Libreoffice-qa] [libreoffice-design] Future libreoffice.org web page: design request

[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 -
> replacing the file you've uploaded for me (thanks!):
Hi,

> http://wiki.documentfoundation.org/Bug_Submission_Assistant_-_ToDo#Web_design
>
> 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
>         is entered).

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
http://99designs.com/web-design/contests/bug-submission-web-form-design-wanted-libreoffice-95945/brief
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.

Cheers
> 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):
>>> https://picasaweb.google.com/lh/photo/w31yhEvxH3xkTt1YYwvjkA?feat=directlink
>>>
>> 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.
> Thanks :-)
>
>>> A first feedback from your side would be great!
>>>
>>> Some comments:
>>>       * 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.
>> yes.
>>>       * 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, ...).
>
> Cheers,
> Christoph
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: loic.vcf
Type: text/x-vcard
Size: 341 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice-qa/attachments/20110914/df129d00/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/libreoffice-qa/attachments/20110914/df129d00/attachment.pgp>