diff options
| author | Bradley Taunt <bt@btxx.org> | 2024-06-08 13:43:37 -0400 |
|---|---|---|
| committer | Bradley Taunt <bt@btxx.org> | 2024-06-08 13:43:37 -0400 |
| commit | 16d28628aca9b2d356de31c319f5e7bc0f5b2b02 (patch) | |
| tree | 11947abb71e38cbe75116871694a44c33d257763 /build/sticky-elements/index.html | |
| parent | dcfb172704f3afb68a30425029ec834be2883274 (diff) | |
Remove incorrectly generated files, fix up markdown articles
Diffstat (limited to 'build/sticky-elements/index.html')
| -rw-r--r-- | build/sticky-elements/index.html | 25 |
1 files changed, 2 insertions, 23 deletions
diff --git a/build/sticky-elements/index.html b/build/sticky-elements/index.html index f39fa55..bdd12bd 100644 --- a/build/sticky-elements/index.html +++ b/build/sticky-elements/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>Stop Using Sticky Navigation on Mobile</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,60 +17,38 @@ <main> <h1 id="stop-using-sticky-navigation-on-mobile">Stop Using Sticky Navigation on Mobile</h1> - <p>2019-10-06</p> - <p>Stop styling your web elements to be “sticky” on mobile. This creates a horrible experience for your users and also looks like trash from a UI perspective. Don’t style your navigation (or any components for that matter) to be “sticky” on mobile. They create poor experiences for your users and take away valuable screen space.</p> - <h2 id="what-do-you-mean-by-sticky">What do you mean by “sticky”?</h2> - <p>The concept of <em>sticky</em> elements include but are not exclusive to:</p> - <ul> <li>Navigations that follow users as they scroll</li> <li>Chatbot prompt bubbles eating up half the bottom of the screen</li> <li>Banners or modal prompts that pester the user to “sign up, accept cookies” etc.</li> </ul> - <p><strong>These are bad and you should feel bad for implementing them.</strong> Spacing and layout is a critical part of a product’s design and greatly impacts the experience of its users. Stop screwing it up with ugly sticky elements.</p> - <p>First, let’s breakdown “sticky” navigations and why they’re terrible. We’ll also go over some easy solutions to avoid making these bad design decisions in the first place.</p> - <h2 id="the-stalking-navigation">The stalking navigation</h2> - <p>When you make a decision to eat away <code>>50px</code> of space at the top of the page for your site’s navigation - you’re hurting your users. You’re also making their time interacting with your website more painful.</p> - <p>“Wait!” I hear sticky-nav defenders exclaim, “this navigation bar makes it so the user can <em>easily</em> interact with the site’s pages!”</p> - <p><strong>What absolute rubbish.</strong> A user should only see a website’s navigation when they <em>need to use it</em>. This isn’t rocket science.</p> - <p>Let’s a take a look at the problem:</p> - <p>Knowing when to show navigation can be easily solved where the user isn’t bogged down with a chunk of their screen permanently taken away, all the while still having access to the navigation. This can be fixed by simply understanding the user context at a given time. See below:</p> - <p>Here the navigation flows up with the rest of the page as the user scrolls the main content into view. Don’t worry about creating confusion - the user knows the navigation is still at the top of the page because they <em>watched it scroll out of view</em>. This is best paired by having a matching navigation in the footer of the page as well. That way, when the user makes it to the end of a specific view they can change pages right in the “footer”. No need to scroll back to the top.</p> - <h2 id="the-best-of-both-worlds">The best of both worlds?</h2> - <p>Maybe you want to hide the navigation without losing the flexibility of it always being accessible at the top of the page? This is possible, although I find it still <em>somewhat</em> intrusive on the user. An easy way achieve this is by displaying the navigation when users perform a specific action, such as:</p> - <ul> <li>Long or multiple upward swipes on the page</li> <li>Pull down menu from top of current view (easily shown to user)</li> </ul> - <h2 id="navigations-arent-the-only-culprits">Navigations aren’t the only culprits</h2> - <p>I wish that navigation items were the only sinners of the “sticky” position on mobile - but they are not alone. A few other problematic components include:</p> - <ul> <li>Chatbot or support “bubbles”</li> <li>“Agree to our cookies” prompts</li> <li>Time-based pop-up modals</li> </ul> - <p>Every time you implement one of these components, somewhere in the world a puppy dies. Seriously - don’t be part of the problem and build these things. Push back on “marketing research” or team leads who tell you that this crap works. You’re making the mobile web worse for everyone and setting a terrible precedent for future developers.</p> - <p>Stay <em>static</em>, my friends!</p> <footer role="contentinfo"> <h2>Menu Navigation</h2> |