Hacker News new | more | comments | ask | show | jobs | submit login
Navigation Should Be Boring (allenpike.com)
87 points by mpweiher 19 days ago | hide | past | web | favorite | 78 comments



Or, you could say "Don't make me think": https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think

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


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 :)


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.


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...

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.


Just wanted to say thank you for trying to make native apps with thoughtful UX! I also frequently bemoan how far we've fallen since the golden age of app design and implementation.


Navigational difficulty increases site stickiness, and I hope nobody is going to try to say sites left that idea behind 10 years ago, because they haven't. I think any UX/UI person opining on this topic, by mere businesswise proximity, is behooved to contribute understanding of BizDev and Marketing's role in all of this.


Nielsen etc advocate boring, predicrable designs.

A number of others seem to have mistaken simple and boring for dumb and useless.

What happened to the familiar menu?

UX Designers decided it wasn't simple enough and replaced it with hamburger menus and ribbons because "dumb users".

I'm not saying you are one of these UX designers, but lets not pretend they aren't there cause they run the shop at most places it seems, including a number of places in FAANG land.


Try running Netscape on a 4" screen


This does not explain why there are still hamburger menus on 20" screens.


640x480 is tiny compared to a modern phone...


A 14" CRT monitor from The Olden Days has an area of about 523 cm². An iPhone X has a screen area of about 127 cm². A 5.8" screen is tiny, regardless of its resolution.

Resolution will only get you so far; people don't have infinitely acute eyesight and infinitely precise dexterity. Most people can't reliably hit a touch target of less than ~10mm in any dimension, which equates to ~180 real pixels on an iPhone X.


> A 14" CRT monitor from The Olden Days has an area of about 523 cm². An iPhone X has a screen area of about 127 cm². A 5.8" screen is tiny, regardless of its resolution.

People hold phones much closer than you would sit from an Olden Days CRT, too. It's not just raw area that matters, but something like degrees, as observed by your eye.


Still, there is a point: even if we could easily see the design elements from Netscape 4 on a modern smartphone they'd be hard to hit consistently.

So that is not what I argue above. In my post above I argue against the dumbification of desktop apps and websites. Things that were working until UX designers came up with the idea that people are to dumb.


But people are dumb.


Nope, an iPhone 8 is 375x667

Edit: for those questioning my reply, I’m talking about the logical resolution (what you actually use for layout) not the physical pixel resolution


Not according to Apple. They say it is “1334-by-750-pixel resolution at 326 ppi“[0]

https://www.apple.com/iphone-8/specs/


That's the raw screen resolution but the web viewport size will be in CSS Pixels and is 667 x 375.

https://vizdevices.yesviz.com/devices/iphone8/


How did you come up with that? iphone 8 is 1334x750.


It looks like the parent commenter is talking in points (iPhone 8 is a 2x Retina Display), while you're speaking about pixels.


Ok; the classic 640x480 figure is also in pixels, so I'm not sure why the parent commenter would use a different unit to try and draw a comparison.


We’re taking about rendering UI... If I render a div with width=375px and height=667px it will fill the screen on an iPhone 8 because it renders @2x.


There must be a pixel-per-inch ratio in this equation. A 14" monitor running at 640x480 will have around 57 ppi, while iPhone X has like 462 ppi.


Yep!


It doesn't look good on a portfolio.

If the mockups are boring then you have done your job well. The problem is that mockups that stand out, are what gets steak-holders interested. Some of my design work involved selling concepts, and the ones that sold were those that broke the UI conventions in some way. Those features that broke the conventions were then set in stone! Instant regret.

Uniformity is bad! They want bright colors, low contrast text, and each page to be unique. If every page looks the same then they obviously are paying you too much. This is how lots of print designers get started in the web-industry, and wowing people is the main objective. UX doesn't come into it.

The other thing that I've found happen, is business requirements sometimes further complicate the UI. We had a simple app that was a report of damages as part of a return process.

This was mandated by the project manager to be displayed as a progress bar. Sofar as a vehicle that was 100% fucked would be 100% complete. I tried to push back with exclamation points for damaged areas, but progress bars were already sold to the customer.


If you have to sell yourself on a portfolio then you are talking to the wrong prospects.

Some of my best clients have never seen my portfolio. Even the ones who start off with "where can I see some of your work" forget all about my portfolio by the time we are done speaking. If you do a proper job of explaining what your job entails, what the client gets out of it and where to focus priorities, you'll likely never need to show your previous work.

Sadly, most junior UX wannabes don't understand this and continue to try and impress people with portfolios. They get the client they deserve. This does the industry no favors, but I could care less. Once that business is butt hurt by a previous designer and decides to commit to a real process, we can talk.

If you are part of the problem, you don't get to complain. Be the one designer who does 80% data and 20% design. Just say "no" to stupid ideas and squash them like a bug. If you are an entrepreneur running a business, you are in charge. Do you tell a plumber how to do his job? No. Then act like the plumber and do things the right way and tell them to thank you later. Results speak for themselves.


Mmm... steak-holders.


I wondered if anyone would pick up on that. :-)


UX people love boring and/or simple stuff.

Source: am a UX designer

It’s literally the whole point of the job.


To clarify ... A designer wants to make things look cool, a UX designer wants to make things boring. Both are wrong.


I think that’s a gross oversimplification that completely misses the mark.


I'm going to get your comment tattooed on my hand and then slap people whenever they tell me their opinions in real life. (I'll also need to use it to slap myself.)


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

That's probably true of many professions. Our software architect got us stuck with microservices for example, which we don't need. He did it either because he's bored, or wanted to put something fancier on his resume.

If not managed well, many employees go off the deep end. I admit, I've over-engineered parts of software for the sheer fun of it. But I try to limit my "experiments".


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

Many years ago I was working on a project for a major UK high street bank, and on the team was a designer who genuinely believed "users like a challenge". No users do not like a challenge. Users like spending the absolute minimum time possible doing their online banking, then they like getting on with their lives.

I believe he later went on to win loads of awards... as judged by other designers. Anyway a large part of why the web sucks and runs like molasses is guys like that.


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.


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).


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.


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).


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...


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?


> 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.


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?


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.


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.


"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.


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

Only end users, but who cares about them?


I wanted to check out the menu at a local pizza place the other day and this was my experience:

1) Menu link, one of two important things on the entire site (the other one is hours) is buried in a hamburger menu

2) The menu is implemented as a fixed-size page designed for an iPad Mini (which they use as menus at the tables)

3) Different types of items (appetizers, entrees, pizza, drinks, etc) are in a horizontal bar across the top, with large font size. Since it's a fixed iPad Mini width, this scrolls horizontally. Less than half of them are visible at a time.

4) Individual items are listed by name, thumbnail photo, and price for each size. Want to know what toppings are on their "Eighth Street" pizza? Click on it! Then click to close that and click on the next menu item. Do this for each pizza, then try to remember what the one that sounded best was called, and probably go through half of them again to get back to it. Super efficient way to find which pizza you'd like.

I think the restaurant understands in concept that they should have a website, but I don't think they care to think about it beyond that.

EDIT: I just revisited this and you actually can get to the menu without the hamburger link. It's designed as one of those pages where the content is centered (vertically and horizontally) with a bunch of white space as a full page thing, so it doesn't look like you'd need to scroll, but there's actually more content (including a second link to the menu) if you try scrolling down.

I'll blame this partly on Apple for taking away the always visible scroll bar indicators and partly on this stupid web design trend of giant "paginated scrolling" pages that don't look like there's anything running off screen that you'd need to scroll to.


>1) Menu link, one of two important things on the entire site (the other one is hours) is buried in a hamburger menu

I think hamburger menus should not be used anywhere except in hamburger restaurants.


Someplace (reddit?) did a promo with a fast food chain recently where the hamburger menu was colored like a hamburger.


but how do you handle a lot of links.. 1) find a way to just diplay them all 2) put them on a separate navigation page (e.g. a second level)


Tiered navigation (multi-level) has always worked.

Why would a restaurant website need a hamburger menu (UI I mean, not the literal menu of hamburgers on offer)?


I'm not arguing in favor of anything, just looking for best practices


Or, the cost of anything but the most basic development is prohibitive and their margins are too low.


I suspect they've locked themselves in to whatever crappy menu system the iPads run on. Works well enough in-house, and the website's menu existence is an afterthought. Not great since they do takeout, but for the most part I think it's a sit-in restaurant.

If the menu vendor had bothered with responsive design it wouldn't be half as bad, but "here's an iPad viewport centered in your browser" must have meet the contractual requirements.

A $10/month Squarespace subscription is pretty damn cheap and IIRC you don't need to know much of anything about web development to set that up.


Do they also cut corners with their kitchen?

And the cost of web development has never been lower.


It is likely they don't realize or understand the actual issue. The decision-makers probably don't ever look at the menu on a mobile device. Even if they recognize that there is an issue, they may be intimidated by the prospect of finding someone who can fix it.

This is in stark contrast to kitchen-related matters, which they are likely much more experienced at identifying and dealing with.


Why do you resort to such sophism ?


What exactly is the "sophism"?

That the cost of web development has never been cheaper is a fact.

That the restaurant website is important -- that's how customers find out about it -- and shouldn't be left behind because of "small margins" is also not very controversial.

If the margins are so small as not to afford some $1000 (or less) for a decent website, then what other corners have been cut?



Nice to see an article by Devesh linked here.


Have you used iOS? Apple rarely if ever uses hamburger menus in any of their software.


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.


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.


https://medium.com/@eventbrite/mobile-safari-whyyyy-73cf6103...

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;


Yeah this is actually something I wish Apple would change. For once the material design team are ahead of them by adding a bottom app bar:

https://material.io/design/components/app-bars-bottom.html


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.


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.


> 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.


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


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).


Right from the article:

>many users don’t even find gestures


This is not an issue on any mobile platform. On iOS, you can swipe to go back, and on Android the back button is at the bottom of the screen.


> On iOS, you can swipe to go back

This is 100% entirely application dependent and in no way guaranteed or obvious.

> on Android the back button is at the bottom of the screen.

That was true for some time. Modern android phones don't have buttons down there anymore.


I run a modern Android phone (Pixel 3) and it certainly does have a back button on the bottom.


Modern Android has a fake back button on the bottom. Thankfully, it's been a long time since I've seen one of 'those' apps or webpages that insists on pretending my phone is an iPhone and puts the back button way on top.

Since I'm ranting anyway. I wish chrome on Android would put the address bar down at the bottom too, even Microsoft figured that one out. Also, since we know Android dropped buttons to save money for manufacturers, why can't we have some luxury phones with real buttons?


I have a tendency to uninstall apps that break the back navigation swipe, because this usually means they ditched standard navigation elements for their custom thing that's flashy and likely broken.


Where else would you put it?


Anywhere that normal sized right-handed people can reach with their thumb without nearly dropping their phone.

I realize that we're all conditioned from years of browser back buttons that "top left == back" but there's no real reason that it's the case.

How about bottom left? Like Android phones used to do?


I find the bottom left to be a very inconvenient spot due to the palm creating false touch events.

Logically, it makes sense to be on either of the left corners because obviously having it in the middle of the screen (even on the side) takes up valuable content real estate. Between the top and the bottom, I'd pick the top every time.

As for ACTUALLY going back a screen, the gesture to swipe from the left is the real UX default. The top left button is for newbies/redundancy.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: