I think the most convincing defence of text labels is a discussion trying to find the best icon to use for a feature. It’s a conversation I’ve had multiple times, and we usually end up picking something that vaguely feels related, having combed through the Font Awesome icon list and thrown at least half a dozen suggestions into the mix.
If it’s this hard to pick an icon knowing what the icon is meant to represent, then how hard must it be for the user trying to reverse engineer our logic?
I agree with the author that the right icon at the right time is brilliant, and can make something immediately understandable at a glance — far more than a textual representation can do. But defaulting to text-with-icon (or even just text!) is probably the best place to start.
There was a time when software companies and web studios had their own graphic designers and they created custom icons to suit their needs. Instead of „picking something that vaguely feels related“.
However I agree that icon itself is sometimes not much useful and icon+text combination or even just text is sometimes better option.
P.S. There used to be books on how to design icons. The Icon Book by William K. Horton is great. It is a 1994 book. Is there something more contemporary worth reading? I found some books about design in general or some web resources, but no other comprehensive writing on icons.
I feel like this (that icons alone make for a poorer UI) is so obvious that it hardly needs to be said, but it’s good to be reminded of it. It’s worth remembering that the trend towards textless UIs was (and is) fueled in large part by a desire to minimize localization costs. And admittedly, it is rough trying to design a good UI experience when its main elements are of indeterminate size. But it’s still a tradeoff with severe costs.
I agree generally but I feel like point 1 doesn’t really support the argument
A stacked list of text requires only a one-directional scan (top-to-bottom), while icon grids demand bi-directional scanning (top-to-bottom and left-to-right).
I feel like this is more of a critique of grid based layouts and not really related to the topic of icons
A great way to make smaller and maybe-more-recognizable (or at least more-easily-localized) icons less opaque is tooltips. …Oh right, you can’t have those on touch devices. Welp.
I actually wrote a draft for a blog a couple days ago on tooltips but it isn’t ready to go live yet… the short version is tooltips kinda suck:
you can’t scan them quickly, you have to position the mouse and pause for each one you want to look it.
they sometimes pop up when you don’t want them and cover things up (this drives me totally nuts)
it isn’t always obvious what does and doesn’t have tooltips, so you guess and check, slowly.
Among a few other things. I’d rather have both visible. One alternative for the toolbar is that every tool bar icon should also be visible in the main menu…. the icon and label could be together in the menu, allowing you to scan it and learn the icons, then the shortcut on the toolbar is more usable as you get to know it.
Using standard icons for standard operations is nice too. Old style open, close, save, print, standard icons and behaviors are getting depressingly less common, sigh.
I think the most convincing defence of text labels is a discussion trying to find the best icon to use for a feature. It’s a conversation I’ve had multiple times, and we usually end up picking something that vaguely feels related, having combed through the Font Awesome icon list and thrown at least half a dozen suggestions into the mix.
If it’s this hard to pick an icon knowing what the icon is meant to represent, then how hard must it be for the user trying to reverse engineer our logic?
I agree with the author that the right icon at the right time is brilliant, and can make something immediately understandable at a glance — far more than a textual representation can do. But defaulting to text-with-icon (or even just text!) is probably the best place to start.
There was a time when software companies and web studios had their own graphic designers and they created custom icons to suit their needs. Instead of „picking something that vaguely feels related“.
However I agree that icon itself is sometimes not much useful and icon+text combination or even just text is sometimes better option.
P.S. There used to be books on how to design icons. The Icon Book by William K. Horton is great. It is a 1994 book. Is there something more contemporary worth reading? I found some books about design in general or some web resources, but no other comprehensive writing on icons.
I feel like this (that icons alone make for a poorer UI) is so obvious that it hardly needs to be said, but it’s good to be reminded of it. It’s worth remembering that the trend towards textless UIs was (and is) fueled in large part by a desire to minimize localization costs. And admittedly, it is rough trying to design a good UI experience when its main elements are of indeterminate size. But it’s still a tradeoff with severe costs.
I agree generally but I feel like point 1 doesn’t really support the argument
I feel like this is more of a critique of grid based layouts and not really related to the topic of icons
A great way to make smaller and maybe-more-recognizable (or at least more-easily-localized) icons less opaque is tooltips. …Oh right, you can’t have those on touch devices. Welp.
I actually wrote a draft for a blog a couple days ago on tooltips but it isn’t ready to go live yet… the short version is tooltips kinda suck:
Among a few other things. I’d rather have both visible. One alternative for the toolbar is that every tool bar icon should also be visible in the main menu…. the icon and label could be together in the menu, allowing you to scan it and learn the icons, then the shortcut on the toolbar is more usable as you get to know it.
Using standard icons for standard operations is nice too. Old style open, close, save, print, standard icons and behaviors are getting depressingly less common, sigh.
Why not? The Google apps on my Android phone have tooltips, triggered by pressing and holding a button.