From 16d28628aca9b2d356de31c319f5e7bc0f5b2b02 Mon Sep 17 00:00:00 2001
From: Bradley Taunt <bt@btxx.org>
Date: Sat, 8 Jun 2024 13:43:37 -0400
Subject: Remove incorrectly generated files, fix up markdown articles

---
 build/simple-does-not-mean-ugly/index.html | 34 ++----------------------------
 1 file changed, 2 insertions(+), 32 deletions(-)

(limited to 'build/simple-does-not-mean-ugly/index.html')
diff --git a/build/simple-does-not-mean-ugly/index.html b/build/simple-does-not-mean-ugly/index.html
index c47c29e..3dc0070 100644
--- a/build/simple-does-not-mean-ugly/index.html
+++ b/build/simple-does-not-mean-ugly/index.html
@@ -3,11 +3,12 @@
 <head>
 	<meta charset="utf-8">
 	<meta name="viewport" content="width=device-width, initial-scale=1">
+	<meta name="color-scheme" content="dark light">
 	<link rel="icon" href="data:,">
 	<title>Simple Does Not Mean Ugly</title>
 	<link href="/atom.xml" type="application/atom+xml" rel="alternate" title="Atom feed for blog posts" />
 	<link href="/rss.xml" type="application/rss+xml" rel="alternate" title="RSS feed for blog posts" />
-<style>*{box-sizing:border-box;}body{font-family:sans-serif;line-height:1.33;margin:0 auto;max-width:650px;padding:1rem;}img{max-width:100%;}pre{border:1px solid;overflow:auto;padding:5px;}table{text-align:left;width:100%;}.footnotes{font-size:90%;}</style>
+<style>*{box-sizing:border-box;}body{font-family:sans-serif;line-height:1.33;margin:0 auto;max-width:650px;padding:1rem;}blockquote{background:rgba(0,0,0,0.1);border-left:4px solid;padding-left:5px;}img{max-width:100%;}pre{border:1px solid;overflow:auto;padding:5px;}table{text-align:left;width:100%;}.footnotes{font-size:90%;}</style>
 </head>
 
 <nav>
@@ -16,74 +17,43 @@
 
 <main>
 <h1 id="simple-does-not-mean-ugly">Simple Does Not Mean Ugly</h1>
-
 <p>2019-03-26</p>
-
 <p>I see new blog posts popping up now and again advocating for designers to keep their products as simple as possible - and I couldn&#8217;t agree more.</p>
-
 <p>A lot of designers tend to think they need to reinvent the wheel when it comes to UI concepts that are standard defaults and expected by most users. Not only does this add extra work for your design and development cycles, but also increases the potential of frustration for your users when they are using your product.</p>
-
 <p>Your job as a designer is to focus on the user experience journey and understand what those users <em>expect</em> to happen - not what <em>you want</em> to happen. This is a very delicate balance of design “give and take”, hence why simple designs always seem to work best.</p>
-
 <p><strong>But simple does not mean “ugly”</strong>.</p>
-
 <h2 id="ugly-simple">Ugly Simple</h2>
-
 <p>Anyone who has read some of my opinion pieces on here in regards to UI know that I have a profound distaste for the overused “flat design” trend. Many designers consider this trend a clean and “simple” approach to most UI conventions - which is complete nonsense to most professionals in the industry (at least those not drinking the kool-aid).</p>
-
 <p>Using the term “simple” in the context of UI is currently quite damaging to modern application and product development. Designers take these definitions too literally, leading to stripped down interfaces with little to no usability for their end-users.</p>
-
 <p>Cap Watkins wrote a post back in 2014 where he explained his admiration for <a href="https://capwatkins.com/blog/the-boring-designer">boring designers</a> and how they tackled design problems using the most boring or “lazy” techniques. While I don’t agree completely with his arguments, nor do I think one should try to attain the status of “boring designer”, I can understand his main sentiment: everyone can appreciate obvious and clever design.</p>
-
 <h2 id="fixing-simple">Fixing Simple</h2>
-
 <p>I hate when people point out problems without at least attempting to suggest some sort of solution - which is exactly what I’m going to do here (with only a few set examples of course, otherwise the post would become a book). Let’s take a look at the major culprits I find around the web: navigations, buttons and form elements.</p>
-
 <h3 id="1.-hidden-navigations">1. Hidden Navigations</h3>
-
 <p>How many native apps that you use regularly rely on the trusty “hamburger” menu icon navigation system? What about news sites, video streaming services, or blogs? Maybe you’ve implemented this concept in your own projects as well, advocating for it’s “cleaner” approach to navigation. </p>
-
 <p>The <em>hamburger</em> is a great example of “ugly simple”. You are purposely hiding the main structure that allows your users to move around your product freely behind an <strong>additional</strong> interaction. That is the opposite of simple.</p>
-
 <p>The only time you should be using the “hamburger crutch” as I call it, is for very small screen sizes or when targeting mobile user agents directly. That’s it. If your users are viewing your product on a larger screen, for the love of God, <strong>use the space available</strong>.</p>
-
 <p><img src="/public/images/navigation.webp" alt="Desktop Navigation" /></p>
-
 <h3 id="2.-buttons-not-looking-like-buttons">2. Buttons Not Looking Like Buttons</h3>
-
 <p>It’s difficult for users to actually <strong>do</strong> the action you want them to perform when your buttons look like text. I’m not exactly sure why designers have pivoted towards removing all stylings that regular users have come to expect from button elements, but it’s plaguing far too many websites.</p>
-
 <p>Buttons should be eye-catching, colorful, fun to interact with, and support all proper CSS states. Clients and agencies will tend to push for “cleaner” buttons - which most of the time refers to setting the buttons as simple underlined text items. Do not be brainwashed into thinking this is better:</p>
-
 <p><img src="/public/images/buttons.webp" alt="Button Comparsion" /></p>
-
 <p>You tell me what looks more interactive&#8230;</p>
-
 <h3 id="3.-overriding-form-elements">3. Overriding Form Elements</h3>
-
 <p>Designers should rarely rebuild the browser structure for web form elements in their projects. I should clarify - I’m not suggesting that you use the barebones default styles provided by the browser, I’m saying that you shouldn’t hide the elements themselves just to replace them with mimicking components. I find this practice is becoming more and more noticeable with the growing popularity of component-based frameworks. Don’t fall into these bad design habits.</p>
-
 <p>For example, you should leave the following <code>select</code> element as is:</p>
-
 <pre><code>&#60;select&#62;
     &#60;option&#62;
 &#60;&#47;select&#62;
 </code></pre>
-
 <p>Instead of doing something like this:</p>
-
 <pre><code>&#60;select style="display:none;"&#62;&#60;&#47;select&#62;
 &#60;div class="custom-select-container"&#62;
     &#60;span&#62;Option&#60;&#47;span&#62;
 &#60;&#47;div&#62;
 </code></pre>
-
 <p>There are cleaner ways to customize web forms with straightforward CSS. Have a look at my own open source project <a href="https://normform.netlify.com/">Normform</a> if you’d prefer to just use a lightweight plugin to do this for you. (Shameless plug, I know)</p>
-
 <h2 id="simple-can-be-good">Simple Can Be Good</h2>
-
 <p>Having a boring or lazy design thought-process doesn’t mean you should develop ugly UI for the sake of “simple”. Too often that word is associated with “minimalism” or “less content” and that is only half true.</p>
-
 <p>The <em>experience</em> is what needs to be simple for your users - the UI itself should still be beautiful.</p>
 <footer role="contentinfo">
     <h2>Menu Navigation</h2>
-- 
cgit v1.2.3-54-g00ecf

