Add a page about icon usage, including menu icons
AbandonedPublic

Authored by Fuchs on Mar 11 2018, 12:54 PM.

Details

Reviewers
fabianr
Summary

This adds a new page about how to use icons, including menu icons such as hamburger and overflow.

Diff Detail

Repository
R985 KDE Human Interface Guidelines
Branch
fuchs-icon-usage (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Fuchs requested review of this revision.Mar 11 2018, 12:54 PM
Fuchs created this revision.

In source/img/chatapplication_menu.png remove the "Telegram Desktop" from the drawer?

source/patterns/iconusage.rst
17

I would suggest to link to not yet ported page about icons https://community.kde.org/KDE_Visual_Design_Group/HIG/IconDesign here, instead of the general rules.

22

geographical should be geometrical ?

Fuchs updated this revision to Diff 29311.Mar 12 2018, 10:56 AM
  • Link to the community wiki as per phab comment

Updated, I didn't see that old community wiki entry, that is of course way better. Linked until it gets ported, which also fixes the second comment as side effect.

ngraham added inline comments.
source/patterns/iconusage.rst
7

"Icons can save space..."

Compared to what? Is this referring to icon-only buttons?

"and due to recognition allow users to work more efficiently."

This is a bit awkward to me. Really the whole paragraph itself is a bit awkward. Icons almost never stand alone; rather, they're integrated into something else.

21

"size-limited"

35

Remove "It is" to match the way the hamburger menu paragraph starts.

37

What does this mean?

38

Conceptually, how is that really different from what a Hamburger menu shows? Anywhere there's a hamburger menu, you could theoretically replace it with a bunch of buttons if space was unlimited, no?

43

Seems a little odd to use an Electron-based non-KDE app in our own HIG as an example of how to design KDE apps.

Fuchs marked 2 inline comments as done.Mar 12 2018, 7:01 PM
Fuchs added inline comments.
source/patterns/iconusage.rst
7

"Compared to what? Is this referring to icon-only buttons?"
Compared to buttons with text, which is what they usually replace.

"This is a bit awkward to me. Really the whole paragraph itself is a bit awkward. Icons almost never stand alone; rather, they're integrated into something else."
It's almost a textbook example. But if you have a better intro text, feel free to propose it.

37

That an overflow menu is, compared to a hamburger menu, context sensitive. It is valid for the context it stands in, not globally or across scopes.

38

The difference is that an overflow menu should only be used when there are things left out, in case of icons: you have some, but not all of them. Similar to how an ellipsis works in language, that's also where it came from. You e.g. start a sentence or an enumeration and leave things out, putting an ellipsis in there instead.

43

As I wrote in the Telegram group: if someone has the time and talent to create a mockup where it is done correctly: feel free to.

fabianr added inline comments.Mar 14 2018, 12:57 PM
source/patterns/iconusage.rst
7

Maybe some more details about when/how to use icons would be good. That is, if they are not already covered by another page in the HIG.

22

Could you add a reference to the HIG page about menus?

mart added a subscriber: mart.EditedMar 16 2018, 9:31 AM

I don't think screenshots of other (and potentially proprietary) apps should ever be used in our pages.
if on those telegram screenshots there are concepts we may want to reuse, we need to replicate something in qml, which looks not too close

As a quick fix Dicover on master features contextual menus (the 3 dots) and System settings features a global menu top left. Maybe just take some screenshots of these for now.

In D11231#227114, @mart wrote:

I don't think screenshots of other (and potentially proprietary) apps should ever be used in our pages.
if on those telegram screenshots there are concepts we may want to reuse, we need to replicate something in qml, which looks not too close

It's FOSS (and, despite what other people wrote, Qt), and as I wrote twice by now, but I gladly repeat it a third time:

if someone has the talent and time to create a different mockup: feel free to, I do not, hence I won't.

mart added inline comments.Mar 16 2018, 10:30 AM
source/patterns/iconusage.rst
26

I would like to add a (tough not mandatory) recommendation of always try to have at most one hamburger icon in the whole app

30

hmm, I don't like that too much, i think it really has sense when there is one, as it's a generic "menu" without convening meaning of what's in the menu, if you see two, which has a different kind of menus inside, it doesn't tell you which is which

37

a more verbose rephrase:
"An overflow menu is context sensitive regarding to the nearby, or grouped together contents. It will uncover a menu of actions with similar scopes of the visible ones or actions in context with a title nearby"
(more on that last part later)

38

yes, when there is a clear context, a header, or a visual group of any kind (like a card) and the icons tells, "more of that stuff here"
an hamburger is completely context-free and fails to say "more of this stuff there"

I'm not convinced at all that visible actions are actually *needed*. I know technically it's an ellipsis and evolve to say more of the same stuff it's immediately right of.
tough a design language it's actually that, a language, and all languages evolve also in ways they were not really supposed to. Yes, literally now means figuratively, deal with it :p and if this disturbs, remember that "awful" was born with a meaning similar to "awesome".
there are supposedly "wrong" usages of it all over the internets, but usages that have one thing in common, which means its real meaning (which is the same thing as "its more widely perceived meaning") actually changed.

It's often used anywhere there is some kind of an enclosed box, some clear context with a title, regardless there is another action button nearby or not, if there a visible title, it says "more on that topic"

A typical example where an overflow menu icon would make sense, is here in discover, because it says: "more on kde neon repos" (and no, those overflows in each item are wrong, they are supposed to be different looking "handles")

41

see above... i feel for that context overflow is already better (and yes some more generic menu icons are needed, such as something that says "options" menu)
and for sure, never the hamburger in random places in-app

43

this is from kirigami gallery, i can quickly do a qml mock of something with any icon there to tell the story{F5755691}

Fuchs added inline comments.Mar 16 2018, 10:46 AM
source/patterns/iconusage.rst
26

Yes, as I wrote in the VDG Chat, if you have too many menus, maybe reconsider the design of your application.

What under no circumstances should happen is that someone takes a different but wrong icon (e.g. overflow where it is not overflow) just in order to not have more than one hamburger. That would be wrong on multiple levels.

41

Whilst I'd prefer a better app design which does not require these menus at all, or as sparsely as possible, I'd rather have multiple hamburgers (which is not random) than further abusing overflow menus.

Other people making that mistake should never be a reason for us to make it, and the bigger projects (which have some designers and UX people) tend to get it right.

43

works, and at a first glance it's a proper use of overflow, just lacks hamburger. But I agree that it would be better to have a proper mockup (which does it right, mind) instead of using a non KDE application which does it right.

mart added a comment.Mar 16 2018, 10:50 AM

I think it's a good start tough for general icons usage it it needs some expansion, one different sccenarios of when using an icon, when not,
or as is now... this could become a page about toolbars? (so when to use toolbars how many items they should have min/max, when to elide them in a menu etc.

On a completely different note:
On generic icons usage, another of the annoying pet-peeves of mine, is to define first and foremost, when is not a good idea to use an icon, to keep them as few as possible, to not cause a cognitive overload to keep icons helping, not hinder
http://uxmyths.com/post/715009009/myth-icons-enhance-usability

mart added inline comments.Mar 16 2018, 11:06 AM
source/patterns/iconusage.rst
41

my point is exactly that: it is not wrong anymore :p
about bigger teams, btw facebook uses it


google uses it

that means it entered in the "used language", of what is shared and understood,
which doesn't care about "correctness" and is more important than correctness (again my point about literally and awful)

on a very similar theme, there is a centuries old debate among linguists of "used" language vs formal grammatical correctness (like the organic grow of english vs the centralized real academia of Spain) i think it's obvious what side i'm on :p

Fuchs abandoned this revision.Mar 16 2018, 11:14 AM
Fuchs added inline comments.
source/patterns/iconusage.rst
41

my point is exactly that: it is not wrong anymore :p

Yes it is.

about bigger teams, btw facebook uses it

Hence "tend", just because facebook does something doesn't make it right. Otherwise we could base our privacy policy on facebook, since it's a big player and so many big players do it that way, it can't be wrong any more.

Honestly, if we have set UX as one of our main goals, I'd rather be an example of doing things correctly instead of "doing as the others do", that is cheap and everyone can do it.

However, this discussion is getting tiresome, so I lost interest in adding this page. Sorry.

If someone comes up with corrections and mockups (which is why I prefered the old wiki, it made this so much simpler) do go ahead, otherwise: okay, do whatever you want.

mart added inline comments.Mar 21 2018, 11:54 AM
source/patterns/iconusage.rst
41

Honestly, if we have set UX as one of our main goals, I'd rather be an example of doing things correctly instead of "doing as the others do", that is cheap and everyone can do it.

i completely agree with you (and kinda retire my point) that we should not only copy, this is *very* important.
My concern with icons is that unlike other parts of the design they are a shared language just as important and abstract as the native spoken language.. (that's why there is an iso committee that's bothering with standardising emoji i guess)

the making the overflow menu just adere to what "..." means in text yeah, i can see a benefit indeed as in kde if anything we would need more rigidity, not less as we tend to be a bit too random woth our designs :)

If someone comes up with corrections and mockups (which is why I prefered the old wiki, it made this so much simpler) do go ahead, otherwise: okay, do whatever you want.

please don't renounce!
It's normal to not agree, it's what makes the end product better (you should see the eternal discussions in c++ patches sometimes:)
They're good to have, but indeed it's also important to signal when the discussion gets stuck in a direction that feels completely unproductive, which you just did and did the right thing. That's the time to find an agreement and move on. on the specific issue i say, let's stick to the strictest guideline then, and then see how it will work in practice.

anyways, i'll do a qml mockup for it so that it can be uploaded both the screenshot and the qml file (which makes easy to make eventual further modifications)

mart added a comment.Mar 21 2018, 12:03 PM

here's a mockup that with some changes could be used:




right now i gimped it to make it look exactly like it(hamburger icon at top left in desktop mode): however if is something that makes sense usability-wise i can integrate it into kirigami