This adds a new page about how to use icons, including menu icons such as hamburger and overflow.
Details
Diff Detail
- Repository
- R985 KDE Human Interface Guidelines
- Branch
- fuchs-icon-usage (branched from master)
- Lint
No Linters Available - Unit
No Unit Test Coverage
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 ? |
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.
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. |
source/patterns/iconusage.rst | ||
---|---|---|
7 | "Compared to what? Is this referring to icon-only buttons?" "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." | |
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. |
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.
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.
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: | |
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" 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. 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) | |
43 | this is from kirigami gallery, i can quickly do a qml mock of something with any icon there to tell the story{F5755691} |
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. |
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
source/patterns/iconusage.rst | ||
---|---|---|
41 | my point is exactly that: it is not wrong anymore :p google uses it that means it entered in the "used language", of what is shared and understood, 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 |
source/patterns/iconusage.rst | ||
---|---|---|
41 |
Yes it is.
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. |
source/patterns/iconusage.rst | ||
---|---|---|
41 |
i completely agree with you (and kinda retire my point) that we should not only copy, this is *very* important. 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 :)
please don't renounce! 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) |
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