Settings Human Interface Guidelines first draft online

[Thomas Pfeiffer]

On Sunday 01 January 2012 13:38:53 Sebastian Kügler wrote:
 
> It should, just not really sure where. I suppose techbase, but there are
> people who know better where to put what in our Wikis.

Okay, so we can move it as soon as someone has a good idea where.

> Overall, it looks very good. What would be helpful is a concrete list of
> things that should be changed in current modules, so that we have a) code
> examples and b) screenshots we can point people to as known good examples.

Makes sense. So these are the points that should be changed:

In Time and Date:
- Change the description to "Timezone, time format and NTP". I think we don't 
need to include "Date and time" there redundantly.
- Remove the "Close" buttom from the timezone selection dialog. Closing it by 
tapping outside is enough, like normal comboboxes.
- If a time server is alreadey selected, put it in the selection dialog title 
(Time Server: [servername])

In Web and Browser:
- Remove "Settings for" from the description
- Do not put "dEfAuLt" as the default value in the text box. Put a grey italic 
"Enter the adress of the start page here..." instead
- Remove the checkmark button next to the field. We use instant apply, so it 
should apply automatically on change.
 
> A bit more detail, such as 'use this component, laid out like this, labeled
> like that for this kind of settings", so we don't end up with all kinds of
> creative ways of putting together UI. As we grow more users, we can think
> about creating composite components for recurring things, maybe even data-
> driven.)

Hm, I'm not sure how to further specify the labeling and layout. I have 
specified maximum label length and alignment and order of options. Please 
indicate in more detail what's left undefined so I can add more detailed 
definitions.
As for the choice of widgets, that would be desireable, but it's rather 
difficult to come up with detailed solutions to not-yet-defined problems.
Therefore I'd suggest the following:
We ask that the first dialogs / modules be designed with the help of Fania 
and/or me directly. After we have a good stock of examples, we can extract 
patterns from them to be used by others. Once we have those patterns, creating 
composite components for their solution parts does make perfect sense.
This apporach runs the risk of introducing inconsistent solutions if people 
design dialogs without our help, but HIGs only help if they are actually used 
and respected as well. And I find extracting common patterns from actual 
designs better than creating rules from scratch.

> I'm also nearly done with the necessary changes to the settings app, and
> have already, as proof-of-concept integrated the browser settings module in
> the web browser UI (only not as separate dialog, which the HIG suggests,
> but inline in the dashboard -- that's an experiment, and we might either
> adapt the code to the HIG or the other way round (not a big fan of modal
> dialogs if they're avoidable).

This sounds interesting! Could you please send some screenshots so I can 
imagine how this works? I'm always open to adapt the HIGs to better solutions. 
They are by no means Holy Scripture ;)

> I have to finish the documentation for this stuff (writing, re-using
> modules) and will then post instructions as RFC to this list, hope we can
> merge it into master soon. (Functionality-wise, everything works for me
> without regressions already, so it's pretty close I think).

Having design and implementation working hand in hand is really helpful. 
Providing the technical means to implement HIGs as easily as possible helps a 
lot for getting them adhered to.

Cheers,
Thomas