
Navigation Should Be Boring - mpweiher
https://allenpike.com/2019/navigation-should-be-boring
======
tniemi
Or, you could say "Don't make me think":
[https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think](https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think)

Unfortunately UX people seem to hate boring and/or simple stuff...

~~~
superhuzza
I think you're mistaking UX with UI design.

UX people tend to advocate for simple, boring stuff because they test. Like
you pointed out, UX professionals like Krug, Nielsen, Norman constantly
advocate for boring navigation:

"Users spend most of their time on other sites. This means that users prefer
your site to work the same way as all the other sites they already know."

\- Jakob's Law of Internet User Experience

However, someone simply designing UI will often suggest new and complicated
designs, because they don't test. If they don't test, they are not practicing
UX. Even if their job title is UX designer, they are just doing UI design.

Disclaimer: Yes I am defending my UX job, which involves testing and face time
with users :)

~~~
sephoric
This is precisely what drew me to start making Mac apps 10 years ago. There
was a whole philosophy behind Mac OS X's Cocoa framework that contrasted
sharply with my experience with all the programs I had been accustomed to
using on Windows 95-98-2k-XP. In all those OSes, there was invariably some
program I would need to run that had its own custom scroll bars that didn't
work like normal, and the body of a scrollable page didn't respond to arrow
keys and the scroll wheel, or the buttons had unusual semantics and required
pressing them in certain ways. This was the norm for Windows programs. When I
came to Mac and everything all worked the same, it was a breath of fresh air.
The philosophy behind Apple's Human Interface Guidelines (HIG) at the time was
that every app should follow the same basic rules with only slight variations
where it made sense. I went full force into learning Cocoa because of this
genius idea, but unfortunately now every app is Electron and each has their
own UX paradigms that reinvent the wheel all over again. It's frustrating and
I hope and plan to make apps that hearken back to the days of predictability,
familiarity, and simplicity so people can just use their computers to get a
thing done and then get off their computers ASAP, like it's meant to be.

~~~
int_19h
Windows also had the equivalent to HIG, and it was just as rigorous as Apple's
in many cases, especially by Vista. Take a look at this:

[https://docs.microsoft.com/en-
us/windows/desktop/uxguide/gui...](https://docs.microsoft.com/en-
us/windows/desktop/uxguide/guidelines)

Problem is, it was and is routinely ignored.

Anyway, as you say, it's the Electron era now, and it's the same everywhere.
We had our golden age of desktop UX, but we couldn't keep it.

------
toss1
Absolutely key ==> "Their “attention span budget” can thus be spent
considering how your new thing can fit into their lives, rather than trying to
recall ..."

UI is all about minimizing user workload, and NOT requiring people to learn
redundant knowledge.

Take advantage of every bit of knowledge that they already have from previous
systems.

Every split second they must use to figure out your new way to do someting
they already knonw how to do another way, is squandered and redundant.

Eliminate it. Work hard to eliminate it, so that they can focus on your _real_
innovation

Note: even if you have actually figured out some truly better UI controls,
they must be not merely noticeably better, but better by a margin that exceeds
the cognitive costs of both the new learning & the ongoing disconnect from the
main UI (and remember, they don't live in your app the way you do).

E.g., the fad towards 'clean interfaces' with minimalistic or totally hidden
hotspots may look prettier, but is a huge waste of user time and generates
animosity towards the product. Just the example of Gmail hiding the Trash
folder; I don't know how many times I've had to help people telling them that
they need to scroll down, click on the "MoreV" word (not even transiently
highlighted as a control), then scroll down again... I use it so little I've
even had to Google it myself in a rush... That and 1000 other things are not
an improvement, they are a waste of people's time for some design conceit.

Of course, if you want to give off signals that your core product ideas aren't
all that uniquely useful, and you need to create cute & costly UI differences
as distractions, by all means, go right on ahead...

If you have a real innovation, the best thing you can do is put zero redundant
learning between your user and your key innovations.

~~~
toss1
There may even be a good coding analogy way to think of this.

Consider that the user base already has a set of pre-installed libraries and
callable routines for most UI functions. These were effectively created by MS
and Apple by their design process, and installed in the user base by endless
familiarization, then extended by Apple & Android on mobile devices. Those
libraries are now well embedded and installed.

Make calls into those existing libraries.

Don't force the user to rewrite and reinstall new libraries (unless absolutely
necessary).

------
nine_k
I'd say that ideally navigation should be invisible. That is, natural,
obvious, and requiring minimal cognitive load.

If this is not possible, "boring" navigation is the next best thing: it's
tedious but obvious and predictable.

Highly creative navigation should be an exception, for art pieces of web
design.

Please note that the presence of "boring" navigation does not prevent having
"advanced" navigation, which is a faster equivalent for power users. E.g. many
sites have efficient keyboard navigation. But that advanced navigation should
complement, not replace the easy-to-discover "boring" navigation. A good
example is Stackoverflow.

------
calvinbhai
I worked on an app for a few years (in the earlier part of this decade), and
we redesigned the heck out of the app, moving from tabbar based design to
hamburger menu. Literally everyone in the company were super happy about how
the app looked.

When we did UX testing with real users, and also some users who were given the
scenarios, it became painfully obvious about how much of a cognitive load it
was, for the users to understand what's hidden behind the hamburger menu.

But we still continued with this design, because we (the organization as a
while) didn't have the gumption to revert back to tabbar based design while HB
menu was still the rage, and a year later Apple mentioned in one of the WWDC
talks that Hamburger Menu is not cool.

Recently, I quit an app company because (in addition to other reasons) they
decided to move from tab to hamburger (and I had an another offer).

------
romwell
Some exceptions to the rule: Snapchat was made confusing on purpose[1],
because its target demographics (teens) could adapt fast, but people used to
more traditional UI schemes (their parents) had some friction using it.

In that, just like Facebook's "college email only" lock-out at start, it was a
feature, not a bug.

[1][https://www.businessinsider.com/jeremy-liew-first-
snapchat-i...](https://www.businessinsider.com/jeremy-liew-first-snapchat-
investor-explains-why-the-app-is-confusing-to-use-2017-2)

------
platz
What alternatives are there to the ubiquitous "hamburger menu" for navigation
that look good on both mobile and desktop?

Does anyone think that that static links are better than flyouts?

~~~
wtallis
> What alternatives are there to the ubiquitous "hamburger menu" for
> navigation that look good on both mobile and desktop?

Step one is to stop trying to make the same UI for mobile and desktop. You're
guaranteed to end up with a result that is insultingly bad for at least one of
those segments of your user base.

~~~
hombre_fatal
The issue is that you can always show more options on desktop. On mobile, you
naturally have to choose fewer menu items to display. Where do you put the
rest?

The worst is when the mobile version doesn't have those additional menu items
at all, anywhere, and certain things are simply impossible to do on mobile.

Tossing the lower priority items onto an additional page (hamburger menu) when
screen space is limited is often the fair and simple trade-off.

"Don't use hamburger menus" is often coupled with the hand-wavy "just create
novel mobile UI that doesn't need it", but the reality is that the items in
hamburger menus usually don't need their own top-level button on a small
screen at all. That's why they're hidden behind a click. They aren't worth the
clutter, but they're still things a user may want to do.

In my experience, seeing that just about everything uses the hamburger menu,
like the Kindle, it's a concession users are willing to make in order to use a
small device. What exactly is the trade-off here without downsides?

~~~
platz
I would not characterize the "hamburger menu" as an "additional page". I would
call that a "flyout". An additional page means that you navigate away - so
you'd then be navigating to a sub-page that displays more links, if you did it
that way.

~~~
hombre_fatal
Agreed, I phrased it that way because, for some reason, an additional page
seems more agreeable to people in these discussions, yet a hamburger menu is
really just a much more convenient take on that: a quick flyout that only
covers part of the screen.

~~~
contextfree
"hamburger menus are bad" vs. "no they're good" is such a silly argument to
have - all you know about a UI that uses a "hamburger menu" is that there's an
icon with three lines involved somewhere. You don't know what the application
is for, what options are in the menu, or even the mechanics of the hamburger
menu itself - for example on Windows the built-in "hamburger menu" control
shows icons in compact state and can be expanded by default, which avoids most
of the problems with options being buried, etc. It's frustrating that UI
discussions tend to stay on such a superficial level.

------
contextfree
The article is right that users overwhelmingly tend to prefer familiar
navigation design, but elides the question of how new patterns come to be
familiar and accepted in the first place. If everyone followed its advice
there would be no advancement or broadening of the commonly accepted
navigation language or culture.

------
LoSboccacc
I mean, I wish I could use a navigation bar on the bottom of my web app, but
on ios touching that area springs back the browser chrome and on chrome
pinning something at vh will place it out of the screen when the address bar
is visible.

~~~
RealDinosaur
[https://medium.com/@eventbrite/mobile-safari-
whyyyy-73cf6103...](https://medium.com/@eventbrite/mobile-safari-
whyyyy-73cf61039047)

Here's a fix and description of the issue, but yes. The bottom of the screen
will take trial and error. I've been messing around with fullscreen modals for
interactive content, and iOS is the main problem, 100vh != 100% != position:
absolute; bottom = 0; top = 0;

------
rco8786
Can we all agree to stop putting the "back" button in the top left of the
screen though? It's literally the _worst_ possible place to put a button that
has a very high likelihood of being used.

~~~
ziftface
I'm actually fine with a back gesture in this case. I think it's pretty
commonly known that you can swipe back. And it's way more accessible than the
top left back button.

~~~
Macha
> way more accessible

It can be too accessible, see got example the swipe left/right to change
articles gestures Blogger had (has?). I could never scroll a long article to
the end without accidentally navigating elsewhere.

~~~
ziftface
I agree, those are awful. Edge swiping from the left is a lot harder to do by
accident though.

~~~
rco8786
Edge swiping from the left is nearly as cumbersome as reaching to the top left
of the screen, for me. Not to mention the general finickiness of edge swiping
(at least in my experience).

