diff options
Diffstat (limited to 'build/use-text-not-icons')
| -rw-r--r-- | build/use-text-not-icons/index.html | 69 |
1 files changed, 69 insertions, 0 deletions
diff --git a/build/use-text-not-icons/index.html b/build/use-text-not-icons/index.html new file mode 100644 index 0000000..b7d90a5 --- /dev/null +++ b/build/use-text-not-icons/index.html @@ -0,0 +1,69 @@ +<!doctype html> +<html lang="en" id="top"> +<head> + <meta charset="utf-8"> + <meta name="viewport" content="width=device-width, initial-scale=1"> + <link rel="icon" href="data:,"> + <title>Icons Should be Complementary - Text is Always Better</title> + <link href="https://bt.ht/atom.xml" type="application/atom+xml" rel="alternate" title="Atom feed for blog posts" /> + <style>*{box-sizing:border-box;}body{font-family:sans-serif;margin:0 auto;max-width:650px;padding:1rem;}img{max-width:100%;}pre{overflow:auto;}table{text-align:left;width:100%;}</style> +</head> + +<nav> + <a href="#menu">Menu ↓</a> +</nav> + +<main> +<h1>Icons Should be Complementary - Text is Always Better</h1> +<p>2021-12-17</p> +<p>Designing[^1] software is a complex thing. A great deal of real-world testing and user feedback is needed to create the best solution to the problem you are trying to fix. Obvious requirements are to keep things simple, make it easy to understand by <em>looking</em> at it, and build it to be headache-resistant for future updates. All these things are easier said than done. This is the challenge of a designer's dat-to-day.</p> +<p>But with this term of "simplicity" modern designers tend to take this approach too much to heart. In my 12+ years involved in UI/UX software design, I have lost count how many initial iterations of interfaces suffer from the same "dumbing down" decision making:</p> +<p><strong>Using icons to represent an action or function without textual information</strong>.</p> +<p>If you decide to stop reading the rest of this article, at least take away this one important thing:</p> +<blockquote><p><em>Always try to use text to convey your designs</em></p> +</blockquote> +<p>After achieving this, you should start reiterating those designs to include iconography. Even then, not all UI instances will require you to do that. Designers will find this process difficult, which is why it is important to get <em>right</em>.</p> +<h2>Icons make an <em>ass</em> out of <em>u</em> and <em>me</em></h2> +<p>Icons make general assumptions about what the user may or may not understand. Leading with this in your designs will end <em>poorly for you</em>. Trust me - I've learned this through failed designs many times over. A certain visualization might be common knowledge to you, while differing greatly to someone else with a different set of experiences.</p> +<p>I've found the only thing you should ever <em>assume</em> is that the user knows nothing. Please note - I'm not referring to their intelligence but instead their software literacy.</p> +<p>Take a look at our now "famous" save icon used in almost every piece of software; the floppy disk. Do any software users below the legal drinking age even understand the initial reasoning for using this icon? In all honesty, it was a terrible icon decision even when first introduced. No "hard copy" of the save action is taking place, software creates this save in a digital space[^2]. Yet, it was adopted and people (ie. designers) went along with it.</p> +<p><strong>Quality is not measured by mass appeal.</strong></p> +<p>The argument could be made "People learned to associate "Save" with a Floppy Disk icon..." and my response would be "But what alternatives were they given?"</p> +<p>Original software designers (and developers) held all the power in early UI decision making. General users didn't <em>know</em> any better. Things were new and fresh. Now our response is to shrug our collective shoulders and say, "That's how the save icon has to be now!"</p> +<p>Hogwash. Make it a button that says, <code>Save File</code>. I'm not kidding. Oh, it doesn't work with your current design? Then your initial design wasn't future-proof then, was it? I sound snarky here but many designers put up imaginary walls around their design systems, making them incredibly rigid and difficult to adapt.</p> +<p>Take the time to do even a small thought / wireframe experiment: redo the layout and flow of your application without using a single piece of iconography. If you can't achieve this with even limited success, something is wrong with the design.</p> +<h2>The hamburger menu is the 7th circle of Hell</h2> +<p>Normally, the inclusion of a hamburger menu is indicative of an overly complex application. Too many cooks and all that jazz. Enterprise applications don't get a pass here either, as they tend to be the worst culprits of pouring out everything on to the user as software vomit. Sweeping all this interaction under the hamburger "rug" does not make for a cleaner design.</p> +<p>New features are great, but stop dumping so much of it behind hidden, unintuitive sub-navigation. This design is such a "quick fix" and plagues far too many software apps[^3]. Both desktop computers and mobile devices allow users to <em>scroll</em>, let them.</p> +<p>I've discussed this in further detail here: <a href="https://bt.ht/hamburger-menu-alternative/">Using Hamburger Menus? Try Sausage Links</a></p> +<h2>But what of the "advanced" users?</h2> +<p>I understand applications will have advanced or "pro" users that have full knowledge of the product and wouldn't need things <em>spoon fed</em> to them. This is a more difficult problem that I myself haven't been able to solve without approaching each one on a case-by-case basis. Unfortunately, there is no "one size fits all" method to this. But, although solving for advanced users proves difficult doesn't mean we should dismiss the merits of avoiding icons as a crutch.</p> +<h2>Try for yourself</h2> +<p>As I stated above, try doing a quick design experiment by replacing all your existing iconography in your application with simple text. I assure you that at least you'll discover interesting design flaws in your system.</p> +<h2>Refs</h2> +<ol> +<li>By "design" I'm referring to visuals not programming or system engineering</li> +<li>Early software programs did save to an external floppy disk. My point stands that many digital file storage applications copied this iconography blindly.</li> +<li>Not to mention how rampant it is on plain ol' regular websites. If you're hiding five menu items behind a hamburger menu for "mobile users", you're doing it wrong.</li> +</ol> +<footer role="contentinfo"> + <h2>Menu Navigation</h2> + <ul id="menu"> + <li><a href="/">Home</a></li> + <li><a href="/projects">Projects</a></li> + <li><a href="/uses">Uses</a></li> + <li><a href="/wiki">Wiki</a></li> + <li><a href="/resume">Resume</a></li> + <li><a href="/colophon">Colophon</a></li> + <li><a href="/now">Now</a></li> + <li><a href="/donate">Donate</a></li> + <li><a href="/atom.xml">RSS</a></li> + <li><a href="#top">↑ Top of the page</a></li> + </ul> + <small> + Built with <a href="https://git.sr.ht/~bt/barf">barf</a>. <br> + Maintained with ♥ for the web. <br> + Proud supporter of <a href="https://usefathom.com/ref/DKHJVX">Fathom</a> & <a href="https://nextdns.io/?from=74d3p3h8">NextDNS</a>. <br> + The content for this site is <a href="https://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA</a>.<br> The <a href="https://git.sr.ht/~bt/bt.ht">code for this site</a> is <a href="https://git.sr.ht/~bt/bt.ht/tree/master/item/LICENSE">MIT</a>. + </small> +</footer>
\ No newline at end of file |