Settings Human Interface Guidelines first draft online

Sebastian Kügler sebas at kde.org
Sun Jan 1 12:38:53 UTC 2012


Hey,

> as promised I have put the first draft of the HIG for Settings dialogs in
> the wiki at
> http://community.kde.org/Plasma/Active/Development/ActiveHIG/Settings This
> is clearly RFC. Please comment away, especially regarding
> - Things that you think could cause usability problems
> - Things that are not technically feasible
> - Things that might cause other problems in the long run
> - Questions still left unanswered by these guidelines
> - Things that are difficult to understand and/or ambiguous
> 
> I have taken the current Settings app and modules as a basis, but not as the
> golden example (some small things would need to be tweaked for the current
> modules to be consistent with these guidelines).
> 
> If you think it should be placed somewhere else in the wiki, just say so,
> this was just my first idea where to put it.

It should, just not really sure where. I suppose techbase, but there are 
people who know better where to put what in our Wikis.

> I hope you like this draft. ;)

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.

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.)

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).

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).

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


More information about the Active mailing list