aboutsummaryrefslogtreecommitdiff
path: root/build/browser-history-sucks
diff options
context:
space:
mode:
authorBradley Taunt <bt@btxx.org>2024-06-10 09:41:25 -0400
committerBradley Taunt <bt@btxx.org>2024-06-10 09:41:25 -0400
commit07e4a2dafe248280b5610f8c7d09b0f30b530f54 (patch)
tree8a145d1d4d07e1278a837ff15dadccc322d27515 /build/browser-history-sucks
parent16d28628aca9b2d356de31c319f5e7bc0f5b2b02 (diff)
Initial modifications to rebuilt only changed files based on mod date, performance updates
Diffstat (limited to 'build/browser-history-sucks')
-rw-r--r--build/browser-history-sucks/index.html83
1 files changed, 0 insertions, 83 deletions
diff --git a/build/browser-history-sucks/index.html b/build/browser-history-sucks/index.html
deleted file mode 100644
index 93abd0b..0000000
--- a/build/browser-history-sucks/index.html
+++ /dev/null
@@ -1,83 +0,0 @@
-<!doctype html>
-<html lang="en">
-<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>Browser History Sucks</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;}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>
- <a href="#menu">Menu &darr;</a>
-</nav>
-
-<main>
-<h1 id="browser-history-sucks">Browser History Sucks</h1>
-<p>2019-04-20</p>
-<p><em>Have you ever needed to step back through your browser history</em> to find a particular site or product? Do you remember that experience being good? Most likely not.</p>
-<p>Much like printers, the design of browser history interfaces hasn&#8217;t changed in years. This would be fine if these UIs had been well thought out and optimized for an easy user experience - but they weren&#8217;t.</p>
-<p>Browser history views rely on the user&#8217;s own memory for more in-depth searches. This defeats the whole purpose of having a robust, documented history. The browser should be doing this heavy-lifting.</p>
-<h2 id="what-browsers-get-wrong">What browsers get wrong</h2>
-<p>Modern browsers give the general public too much credit when it comes to memory (I don&#8217;t mean this as an insult!). To assume users remember the URL or site name when browsing random pages is short-sighted. I find myself asking these types of questions when jumping back into my view history far too often:</p>
-<ul>
-<li>&#8220;That article had <em>something</em> to do with CSS&#8230;&#8221;</li>
-<li>&#8220;I remember seeing a beautifully designed site a month ago but have no clue what the URL was&#8230;&#8221;</li>
-<li>&#8220;My browser crashed and I can&#8217;t recall that [example website] I had pinned in my tab for weeks&#8230;&#8221;</li>
-</ul>
-<p>For reference, let&#8217;s take a look at the current Chrome (73) history view:</p>
-<p><img src="/public/images/browser-history-01.webp" alt="Default Chrome History" /></p>
-<p>As you may have noticed - this UI is lackluster at best. An oversimplified search field in the header is the only means of filtering items.</p>
-<h2 id="why-not-use-extensions">Why not use extensions?</h2>
-<p>I know using browser extensions or tagging favorites can alleviate some of these issues. This is great, but why not simplify everything by having these features <em>inside</em> the history view? If an extension can add these features, why not have those extras built-in?</p>
-<h2 id="two-subtle-improvements">Two subtle improvements</h2>
-<p>A little goes a long way. With just two small changes, we can drastically increase the history view&#8217;s UX.</p>
-<p>We start by adding a date picker. Users open the new calendar icon to filter by days, months or years before searching. Seems trivial, but this saves the headache of filtering through all saved history.</p>
-<p><img src="/public/images/browser-history-02.webp" alt="Chrome History with date picker" /></p>
-<p>The second small functional change we can make is including extra subcategories. These new options allow users to focus their searches based on:</p>
-<ul>
-<li>Session length</li>
-<li>Number of return visits</li>
-<li>Last restored tabs</li>
-</ul>
-<h3 id="session-length">Session length</h3>
-<p><img src="/public/images/browser-history-03.webp" alt="Chrome History by session length" /></p>
-<p>Allow users to display their history filtered by session duration. This helps when searching for an stagnant page or pinned site during a user&#8217;s long session. An example default would allow filtering by:</p>
-<ul>
-<li>longest to shortest</li>
-<li>shortest to longest</li>
-<li>pinned tabs</li>
-</ul>
-<h3 id="return-visits">Return visits</h3>
-<p><img src="/public/images/browser-history-04.webp" alt="Chrome History by return visits" /></p>
-<p>When users make repeat visits to a site or web app, the browser should keep a record of return sessions. This allows the user to refine their search by many or singular visits.</p>
-<h3 id="last-restored-tabs">Last restored tabs</h3>
-<p><img src="/public/images/browser-history-05.webp" alt="Chrome History by restored tabs" /></p>
-<p>A basic concept, but the ability for users to view all previous instances of restored tabs is helpful. This would fix most edge cases not covered by the other two categories.</p>
-<h2 id="far-from-perfect">Far from perfect</h2>
-<p>The Chrome (or any browser for that matter) browser history view is simplistic to a fault. The current UI is prone to human error, since it makes assumptions and relies heavily on user memory.</p>
-<p>These are simple fixes that attempt to boost the basic UX of the history view. Are these concepts absolutely perfect? Not at all. Is it at least an improvement? I believe it is. When products decrease the effort required of it&#8217;s users, I see that as a positive.</p>
-<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">&uarr; 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> &amp; <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