From 07e4a2dafe248280b5610f8c7d09b0f30b530f54 Mon Sep 17 00:00:00 2001 From: Bradley Taunt Date: Mon, 10 Jun 2024 09:41:25 -0400 Subject: Initial modifications to rebuilt only changed files based on mod date, performance updates --- build/browser-history-sucks/index.html | 83 ---------------------------------- 1 file changed, 83 deletions(-) delete mode 100644 build/browser-history-sucks/index.html (limited to 'build/browser-history-sucks') 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 @@ - - - - - - - - Browser History Sucks - - - - - - - -
-

Browser History Sucks

-

2019-04-20

-

Have you ever needed to step back through your browser history to find a particular site or product? Do you remember that experience being good? Most likely not.

-

Much like printers, the design of browser history interfaces hasn’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’t.

-

Browser history views rely on the user’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.

-

What browsers get wrong

-

Modern browsers give the general public too much credit when it comes to memory (I don’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:

- -

For reference, let’s take a look at the current Chrome (73) history view:

-

Default Chrome History

-

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.

-

Why not use extensions?

-

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 inside the history view? If an extension can add these features, why not have those extras built-in?

-

Two subtle improvements

-

A little goes a long way. With just two small changes, we can drastically increase the history view’s UX.

-

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.

-

Chrome History with date picker

-

The second small functional change we can make is including extra subcategories. These new options allow users to focus their searches based on:

- -

Session length

-

Chrome History by session length

-

Allow users to display their history filtered by session duration. This helps when searching for an stagnant page or pinned site during a user’s long session. An example default would allow filtering by:

- -

Return visits

-

Chrome History by return visits

-

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.

-

Last restored tabs

-

Chrome History by restored tabs

-

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.

-

Far from perfect

-

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.

-

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’s users, I see that as a positive.

- \ No newline at end of file -- cgit v1.2.3-54-g00ecf