[sonofhans]

IMHO they’re taking the wrong lesson from this. Users don’t want complexity and they don’t want to hunt, but they desperately want not to waste time — they want some confidence that the action they’re about to take will further their goals. Showing an unordered list of unfamiliar names doesn’t further anyone’s goals, and it gives no confidence that further action will help, either.

Why keep scrolling if all the names are arbitrary? Why read one random trail report from one random person? No one has actual needs that are afforded by the original design. What’s the user story behind this? “As a sheep, I want to maximize my engagement with your application, in order to meet your KPIs?”

They write, “See, I'd made the information so readily available that it left the user no desire to dive deeper.” This is baloney. The first design presented no information at all; at best it presented a small amount of data, and data entirely abstract from any human use case.

The map design allows people to easily pay attention, on a familiar substrate, to things that are important to them. It gives users agency and confidence in the future.

You don’t need to present users with a puzzle or a journey, or to manipulate them at all. If they’re not using the UX surface you put in front of them it’s not working hard enough to show that it affords their goals. Get to know your users better, and quit falling in love with your own designs.

[Eddy_Viscosity2]

I was about to make a similar comment. The author even states this at the end "user's prioritize trails close to them, so the best way to show that is with a map". --- The first UX was NOT the most efficient way to show the information but the second one was. Therefore, users do in fact want the most efficient UX. He was just wrong about what that was.

[JoshTko]

This, calling the first design the most efficient UX shows how little empathy he has for his users. He built a UX for himself and faulted users for being "inefficient"

[jrochkind1]

+1. "As simple as possible but no simpler" -- the takeaway is that the first UI was in fact "simpler than possible" to accomplish user goals, not that users prefer things to be less simple or less efficient!

[mromanuk]

I’m wondering what will happen if the first UX is ordered by proximity with distance to it and also a way to open it on the map. I think it’s worth trying it. Is a common use case for my searching for gas stations on Google maps

[bombcar]

It annoys me that Apple Maps enroute will let me "see gas stations" nearby but can't do a simple "find the closest McDonalds to my current route" - I have no desire to turn around and back track even if that's currently the closest one, I'd rather have it say "in fifteen minutes there is one a mile from the freeway".

[cuteboy19]

How would you make it clear to the user that they are sorted by proximity?

[mromanuk]

Showing the distance at the right of the list:

  First place     1.4km
  Second place    3.6km
  third place     9.0km

[cuteboy19]

Strangely, Google maps doesn't do this and just presents us with a list without any context

[tyingq]

I agree with this. The initial design presents trail names and a report with no context. I would immediately wonder what the list was..is this all trails within 30 minutes, 100 miles, or something else? Why is this trail sorted at the top...because it's the closest or the best, or most recently reported on? And why this particular report? Is it just the most recent, or the most upvoted? And those tags...is that the tags from this recent report, or the most popular tags from all reports, or ?

Basically, I have no idea what I'm looking at.

[sonofhans]

Yeah, I totally agree — lack of context. Even a little context would help the original list, e.g., “Most reviewed trails in the last 7 days.”

[hinkley]

> unordered list of unfamiliar names

Unordered data always gives me pause, because from a UX perspective, "unordered" today means "reordered" tomorrow. People will eventually learn to cope with your gonzo UI via muscle memory. If you can't put what they need to click on where they can find it, you're just inconsiderate. But if you keep moving it, now you're a monster.

Mountains, I'm lead to understand, have a tendency to stay exactly where you found them, as do the ski resorts that are so often built upon them. A pin on a map representing a snow covered hill is not going to move. And if it does move, you will have bigger priorities than skiing.

As for the title, there are situations where certain activities should be a little bit inconvenient, and the fact they are inconvenient gives your brain time to talk your reflexes out of doing something truly horrible, like setting off the Halon system, or pushing the emergency stop button, shutting off an entire server room, backup power be damned.

We separate things by workflow, and by subject matter, but sometimes we additionally segregate by consequence. "Wrong lever! Why do we even have that lever?"

[finfinfin]

Not to justify author's UX choices, but he does mention that the feed shows reports from the trails the user follows. It's not a list of random trail reports, there is some logic behind it.

[LudwigNagasena]

That means zero discoverability.

[finfinfin]

I don't disagree, just noticed that many comments missed this detail about the feed showing reports for user's favorite trails, not some random irrelevant content.

[tyingq]

He mentions it, but fails to make the UI show that. It just says "Trail Reports", and he says it's the main screen. And there's a search box at the top. Does that only search trails I've followed?

[Animats]

Google has trained people that the top search results are all ads, and that you have to scroll past them to get to the good stuff. If you make a UI which replicates that, people will have the same assumption.

Or worse, you'll have some spammer posting "Fresh powder at Mt. Perfect" when it's bare ground with ice patches.

[cycomanic]

I agree with what you're saying. Particular when you start using the app for the first time you have no idea what those reports actually mean. I suspect if he had an option for a widget or homescreen at a later point which shows users this list screen (with selectable favorites), it might find very significant use, but it is something the users have customised and now understand the meaning of.

[toss1]

Yes definitely seems like the wrong lesson but right changes

Just a large list of reports only MAY give me a faster access to the info I want. If the trail I'd like to go to today is not at the top of the list / on the first page, it would likely take objectively longer to check the conditions for the place that I want to see.

What would be best would be a map that not only provides locations of the listed trails, but also a coarse indicator of conditions — just Excellent/OK/Marginal/Closed, and maybe a number of trails/km/miles open. Click to that, and NOW the list of reports by recency will give me the detail I wanted. This would be all WAY faster (presuming a properly responsive app) than scrolling through multiple reports that aren't relevant.

So, it seems we have different ideas about what counts as "complexity". I see a map as simpler than a list with the order that I don't want; the author apparently sees it as more complex (perhaps because coding the map and the selected lists is more complex than just the one big list?).

In any case, it is an improvement.

[fdr]

I think you're right. The expected value of a result is generally low in these fundamentally geographical applications that try to avoid displaying a map. There tends to be both inclusion and exclusion error, and viewing things on a map helps for most applications of this type.

[goldenchrome]

As a designer, this is absolutely spot on. I’d add that first time users benefit from the map, whereas experienced users might actually prefer the list view of favorites. It sounds like the app designer only tested with first-time users though.

[insaider]

Yep exactly, maybe they just want to be provocative with their title so they framed it that way...