[kde-guidelines] Current page suggestions

Thomas Pfeiffer colomar at autistici.org
Tue Jun 11 19:18:00 UTC 2013


On Tuesday 11 June 2013 10:54:16 Todd Rme wrote:
> I posted these suggestions on Thomas's blog, but he said he thought
> there should be a more permanent place for such comments, and
> suggested I join the group.  Considering this is venue more suited to
> discussion, I thought I should cross-post them here.

Hi Todd,
thank you for joining our list and posting your suggestions here!

> If it is more appropriate to create separate threads for each, I can
> do so, but I didn't want to spam the mailing list right after
> subscribing.
> 
> 1. A lot of what I see with the widgets is “use this widget under this
> circumstance, use this other widget under this other circumstance”.
> This might lend itself to a decision tree, where the user selects from
> a list of progressively more specific options until they get to a
> single widget that is appropriate for what they want to do.

True. Now we just need a good way to present that decision tree.

> 2. In the “two lists” page, it is unclear grammatically whether
> allowing supporting drag-and-drop is mandatory or optional. It also
> might be good to have separate “sortable single list” entry, and refer
> people to the HIG on that for the right-hand list. There is also
> nothing about the placement of the arrows, especially the up-down
> arrows which are often placed inconsistently (i have seen right, top,
> and bottom for sortable single lists).

Good points! Feel free to update the pattern right away. Otherwise I'll do it 
when I find the time (probably this weekend).

> 3. I think combining the spin box and slider pages might be good,
> especially with the combined spinner/slider case mentioned at the end
> of the slider page. Also, should there be any rules about prefixes and
> suffices in spinners? What about float vs integer guidelines?

Hmm, not sure if we should combine two widgets in one guideline. We'll have to 
think about it a little more, I guess. Cross-linking them definitely does make 
sense, though.
These guidelines are still old, so we'll have to revise them at some point, 
anyway.

> 4. Should the “wording” page mention something about warning dialogs
> for “delete”?

Tbh: I don't get what you mean. Could you elaborate a bit more?

> 5. In the ellipses section, in the third entry you say not to use
> ellipses with “Print”, but everywhere else on the page you say to use
> ellipses with “Print”

Well spotted! We need to make clear that it depends on whether the button 
opens a print dialog or prints immediately. Since the latter is rarely the 
case, maybe we should just remove it from the "Don't" section.

> 6. In “wording”, “Use Options for a configuration dialog which
> provide.” is not a complete sentence.

Yes, looks like that guideline is simply unfinished. I don't even know how that 
sentence was supposed to continue. That guideline needs to be revised anyway, 
so at that point we'll have to come up with a complete sentence.

> 7. I think the “don’t make the menu bar hideable” should be amended to
> include something like “unless it is automatically replaced with a
> toolbar button”.

I suppose this guideline is from the "Pre-Menubutton-Era", so yes, it will 
have to be updated to take menu buttons into account.
In fact, menu buttons are not covered by the HIG yet, but they should, since 
they pop up in more and more KDE applications without being standardized in 
any way.

> 8. I think the KNS entry should mention that there should always be a
> button to install an item without using KNS (since KNS only works with
> files hosted on the KNS page, which many files are not).

Absolutely. Could you add that, please?

> 9. In the “Date Time” page it is not clear what is wrong with the “bad”
> example” 

Yes. That one definitely has to be reworked as well.

As you can see, there is a hell of a lot of work yet to do. We've only just 
started improving exiting guidelines one by one, which takes days of mailing 
back and fourth for each one if you're trying to do a thorough job.

That's why we really appreciate your help!


More information about the kde-guidelines mailing list