I was thinking about improving the "new key" dialog of KGpg, which can be seen here: https://docs.kde.org/stable4/en/kdeutil ... generation

Currently there is even one more control, looks like I should update the docs. So basically there are 3 things a user should enter every time, which is name, email, and expiration. All other things are of the kind "you can change when you know what you are doing", so I think they should be somehow "hidden" to prevent a user to change them because they may think they need to.

This is less about a technical question on how to implement this, I can fiddle that out. It's about what the expected visual representation should be to give a good UI.

There is no best practice for simple vs. advanced options. For the new KCM layout there was a 'more' button proposed which expands the advanced section within a scroll area. You could also have different pages (access via tabs, or rather KDE-like a list view in report style with icons). And perhaps a wizard could also make sense where you go through the steps until expert settings defaulting to close at this point.
I think any kind of confirmation "yes, I promise to be careful" in order to access hidden expert features is paternalistic. It's up to the user to access expert options, and you should only warn before making anything effective.

Wouldn't it make sense to create a HIG entry for advanced options?
It's something that is quite often needed. If every app handles it different it will be even harder for the user?

fabianr wrote:Wouldn't it make sense to create a HIG entry for advanced options?
It's something that is quite often needed. If every app handles it different it will be even harder for the user?

Yes, please.

fabianr wrote:Wouldn't it make sense to create a HIG entry for advanced options?

Four variants are discussed in this thread:
a) present expert features in an extra dialog
b) provide separate sections for average and expert stuff
c) expand expert features on click
d) use a wizard and close it by default after the normal settings

Which one should become the standard? (Guess smart people will find more approaches)

I don't think it makes sense to define one of these as the standard. It depends on the app type (e.g. security relevant as kgpg or not like kmail), the number of settings, how frequently those are accessed, and much more conditions. Although I always vote for having a consistent and familiar workflow.

Could you provide a link to the thread?

Hopefully not everything I write below was not already suggested in this thread


I searched in the documentation for Microsofts UWP Apps and Googles Matrial Design documentation. Keep in mind both a primarily targeted at mobile.

https://msdn.microsoft.com/en-us/hh770544
http://www.google.com/design/spec/patte ... tings.html

Both don't have an "advanced options" concept. They both have pretty much the same way how they handle lots of options. They suggest you group your settings in up to 4 groups and display these groups on an additional screen.

My 2 cents on the 4 options:
a) Since settings are a lot of time in a dialog them self, I would not recommend this as a standard. Actually I would not recommend this at all.

To me b) is not really solving the problem of advanced/additional options. No options are hidden from the user at first sight of the settings dialog.

c) sounds to me like the best solution. Its very similar to what Google and MS suggest. Maybe the section header / button should only have the "advanced options" label, if no better title can be found. (e.g I would suggest something like "Key settings" as a title for "Key length" and "Algorithm").

It seems to me that c) is the solution chosen in this KCM settings thread?
viewtopic.php?f=285&t=127056&p=339649&hilit=KCM+layout#p339649


d) I would suggest to use a wizard only for first run settings or if you have a group of settings you have to set all at once only (e.g. create a new mail account). I would not recommend a wizard for editing options. If you need advanced options in a wizard, I would use c) to display them.

fabianr wrote:c) sounds to me like the best solution....
It seems to me that c) is the solution chosen in this KCM settings thread?

Exactly. Now imagine KGpg (or take KMail's settings) as a dialog with a scroll area containing a 'more' link or button. And when this one is clicked that expert part opens up. Still vote for a guideline?

Ompf whole posting deleted because of session timeout again ...

I'm not suggestion to replace the whole content structure with option c). Only if you have in the last depth options that are not important to most users and have sensible defaults one should use c). As an kind of additional "expert" depth.

Looking at KMails settings, yes a HIG for settings looks quite important. And even if the HIG won't be able to cover the very complex settings of some applications like KMail, wouldn't it be good to have a HIG for less complex scenarios?

Reworking KMails settings seems like a very complex task and probably needs a lot off own threads For a starting point, it is not even following the HIG for 3-deep basic content structure. Most parts are 3-deep. butnesting tabs instead of using a Collapsible List.