Apple's New Map • Hacker News Board

Re: Apple's New Map

#301

Post by aequitas » Fri, Nov 02, 2018, 1:26 PM UTC

kryptiskt wrote: post #231

aequitas wrote: post #199

Earlier quoted context omitted.

> All the time I see a destination and I'm trying to figure out what closest cross street I should stop at Instead of zooming pinching try to click the street to drop a pin and you got the street name. Old abstractions (maps) on newer media (phones, desktops) offer a UX that cartmakers in the past could only dream off. It is up to us to break our old habits and discover and use this new UX. For example. When the iPho…

> (eg: recognise numbers on a page and make them clickable links directly to phone app) I hate that! That makes it unnecessarily hard to copy order numbers and the like on my iPhone. Phoning is legacy functionality, I almost never want to use a number as a phone number. Copy/Paste on the other hand, that's very useful. I can copy the bits I want, anywhere I want, without dumb as hell software trying to guess what I a…

Of course it should not hinder the UX of copy pasting in the process. I probably hate that just as much as you.

> I almost never want to use a number as a phone number.

This is the 'what you want and what you need'. You don't want to copy and paste a number into a phone to dial them. You need to have a voice call with the person/company who's page you are visiting or email you are reading.

Google search solves this nicely in their mobile search. They don't show phone numbers or addresses primarely, but buttons to like Call, Navigate, Share and Website. That is what I need when I search a company on Google and essentially what I want.

Re: Apple's New Map

#302

Post by Sean1708 » Fri, Nov 02, 2018, 1:27 PM UTC

gitgud wrote: post #234

fouc wrote: post #116

Earlier quoted context omitted.

>Whenever you zoom in enough that there's enough room on a visible street to put a label, then put the label! I mean if I zoom in so far that only the one street is visible and there's no other text on it, but Maps still leaves it blank... it just feels inexcusable. Agreed. Happens on google maps too, and that's just so irritating

Really? Google Maps works pretty well on Android, [1] when you zoom in, street names pop up where possible... [1] https://i.imgur.com/c1Mtj57.png

Except when they dont (image shamelessly stolen from et-al): https://imgur.com/a/hCo3V2X

Maybe they would appear if you zoomed in even further, but at that point the map would be pretty useless.

Re: Apple's New Map

#303

Post by logicallee » Fri, Nov 02, 2018, 1:30 PM UTC

Natanael_L wrote: post #226

jefftk wrote: post #143

Earlier quoted context omitted.

I can't tell whether you're getting serious, but I'm pretty sure most users would not prefer your change. It's so dense it's hard to read, and in a repetitive way.

IMHO it could be useful if the repetition was greyed out. It would allow you to either read it directly (if your eyesight allows), or quickly trace the line to the text in black and read the name while being able to easily see what direction the street goes

Humans are fantastic at ignoring noise and concentrating on whatever we want to focus on. While you're reading this very comment do you have any idea how much noise is in your field of vision that you're ignoring? Not just on this screen at the same time (literally megabytes of other bitmaps besides my words) but the rest of your field of vision. Really look around. This message contains 575 bytes of text embedded in gigabytes of moving video you're ignoring. (Just one example.)

But if the information isn't there, no amount being human can bring it out. You're stuck.

Re: Apple's New Map

#304

Post by londons_explore » Fri, Nov 02, 2018, 1:39 PM UTC

bambax wrote: post #223

Fantastic article (the gifs could be slower). In general the article is very critical of Apple new maps, but at one point it seems to commend them for removing roads that are no longer there: > Notice how many of Parkfield’s roads disappear on Apple’s new map. When Apple’s vans visited, they likely saw nothing but empty fields here those roads were supposed to be (...) TomTom’s database somehow has roads from Parkfie…

If they're passable on foot, they're now footpaths, and should be marked as such.

Re: Apple's New Map

#305

Post by ship_it » Fri, Nov 02, 2018, 1:41 PM UTC

> Has Apple closed the gap with Google’s map?

.. proceed to explain how Apple Maps covers just 3.1% of the U.S.’s land area.

Sent from my iPhone

Re: Apple's New Map

#306

Post by logicallee » Fri, Nov 02, 2018, 1:41 PM UTC

fouc wrote: post #265

logicallee wrote: post #201

Earlier quoted context omitted.

Readers here seriously misinterpreted what I was doing. I absolutely 100% didn't write off the idea of putting more labels. I wasn't making a point about how bad it would be. I was doing something different. I read a comment, this one: https://news.ycombinator.com/item?id=18359646 - which I replied to. First I'll quote it in full then we'll break it down. >It's obviously an intentional choice to avoid too much screen…

You actually have a great idea there. I wonder if they truly tested the "null hypothesis" like you bring up. There could even be an invented special "road" font that helps people further disambiguate it visually from all the other map labels.

Thanks. It wasn't my idea. I literally tested the spec "whenever you zoom in enough that there's enough room on a visible street to put a label, then put the label!"

I guess the person meant "on one spot" but since labels are frequently repeated I didn't see the harm of trying it out in the "worst" way possible. Still looks fantastic.

Maybe it was misspecified but I did what it says and I think it's great. A light grey might help but then again it could be easier to ignore black you don't need than make out light grey you do.

Re: Apple's New Map

#307

Post by gitgud » Fri, Nov 02, 2018, 1:49 PM UTC

Sean1708 wrote: post #302

gitgud wrote: post #234

Earlier quoted context omitted.

Really? Google Maps works pretty well on Android, [1] when you zoom in, street names pop up where possible... [1] https://i.imgur.com/c1Mtj57.png

Except when they dont (image shamelessly stolen from et-al): https://imgur.com/a/hCo3V2X Maybe they would appear if you zoomed in even further, but at that point the map would be pretty useless.

So strange... What kind of unpredictable algorithm is this!

Re: Apple's New Map

#308

Post by logicallee » Fri, Nov 02, 2018, 1:49 PM UTC

salvar wrote: post #271

logicallee wrote: post #201

Earlier quoted context omitted.

Readers here seriously misinterpreted what I was doing. I absolutely 100% didn't write off the idea of putting more labels. I wasn't making a point about how bad it would be. I was doing something different. I read a comment, this one: https://news.ycombinator.com/item?id=18359646 - which I replied to. First I'll quote it in full then we'll break it down. >It's obviously an intentional choice to avoid too much screen…

What UX study did you do? All I saw was a mockup. Maybe I misunderstood.

>What UX study did you do?

I looked at the mockup and imagined it on my screen as I navigated, imagining this from a few different points, and imagining further pinching to zoom and scrolling around. I thought it was great. Especially if I imagined zooming in further to deal with an exact corner I was going to.

I didn't get the result I expected, that it would look awful. It looks great, fantastic, tremendous, amazing, wonderful, superb, terrific, awesome, excellent, magnificent. I literally have to open a thesaurus to express how great it is, I ran out of words partway through.

How it doesn't look is "something I really don't want", which is what I was promised.

Re: Apple's New Map

#309

Post by ryandrake » Fri, Nov 02, 2018, 1:50 PM UTC

panic wrote: post #178

ethbro wrote: post #94

Earlier quoted context omitted.

I think the thing that confuses me and parent is that Maps ALREADY knows about road continuity. And road names. I'm sure I'm missing something, but (1) flow labels along their roads to the center of the screen, (2) separate them with predefined padding, (3) drop labels if visible label count > maximum, smallest-to-largest road, until under the threshold. If UXers want to bitch, hide it behind a layer filter. But hone…

Anything moving on a screen will call attention to itself. A bunch of road labels "flowing" around at once turns into a huge mess. The real problem here is with label conflicts. Say you have an important point of interest in the center of the screen already. If a road label happens to be placed underneath the point of interest label, it will look like the road is unlabeled. There are clever ways of moving labels arou…

Yes, you got it. Not only does it have to both look good motionless and in motion, but it has to look good at different speeds, and at smoothly changing zoom levels. Back in the olden days, there was no smooth zoom and pan, so you'd pre-compute labels at each discrete (logarithmic scale) zoom level and they'd remain fixed while panning around. And since panning happened in discrete steps, you wouldn't really notice labels repositioning themselves for each scene.

Now, we have moving maps that scroll at whatever speed you're driving or moving, and arbitrary, smooth zooming, so you can't just let an algorithm take hold or you get labels popping in and out as the logic decides in real time where to put them. Users will find it distracting and weird, and most designers will say "no way". So you need to add things like debounce and hysteresis. You have to have resolve label conflicts in a way that doesn't always let (for example) POI names always take precedence. You have to determine whether/when to display street numbers vs street names. Do the locals call it I-880 or "Nimitz Freeway"? You have to keep labels right side up at arbitrary map rotations and along twisty road geometry (easy but yet more code). It adds up and requires these fiddly thresholds and scaling factors that are usually hidden from the user.

As someone else pointed out, having sliders and preferences for every little tuning knob is always a no-go with the designers, who want everything to just magically work without configuration. As a programmer, I've always thought that "design minimalism" is cancer, but on the other hand, it provides constraints and makes the problem interesting to solve.