mrshoe

The real problem is industry-wide adoption of metrics-driven design.

When I studied cognitive science, the method we employed for HCI was User Centered System Design. Granted, this was a backronym for UCSD, but the point remains — design should be user-centered, not metrics-driven.

When I launch Netflix, it is abundantly clear to me that their design is driven by their metrics. What I want to see at the top is my “continue watching” shows — 99% of the time I just want to watch the next episode of a show that I’m already watching. Instead, they show me row upon row of shows that I have never watched. Their metrics prove to them that getting me hooked on new shows will increase my engagement and increase the amount of time I spend in their app. Guess what? As a user, those are not my goals! Their UI is effectively one big advertisement for Netflix itself. Wonderful.

Unfortunately, virtually all tech companies have accepted metrics-driven design as conventional wisdom at this point. Run an A/B test and see which button treatment performs better, based on the metrics the company cares about — not what the user cares about.

One outlier here is Apple. They do not design based on experiments and metrics. And the Apple TV app does in fact display the shows I am already watching as the top row. Go figure.

We designed our own magnetic phone mount, which comes with the product. Once you start mounting your phone in your car (especially with our mount, which is amazing), you won't want a separate screen for your camera. :)

The advantages of mounting your smartphone, with the cutting edge hardware and active software ecosystem that come along with it, are truly huge. When I rent a car now I am incredibly frustrated without the mount. Luckily ours has a magnetic pluggable backend, so I can pull it off my adhesive mount and attach the vent clip for use in other cars.

We are using industry standard encryption algorithms for all of our wireless traffic. We are also consulting with external security experts, in addition to the expertise we have in-house.

All of our over-the-air firmware updates are cryptographically signed.

We are initially shipping only in the US, but hopefully total world domination will follow eventually. :)

We do require an OBD port, which is present on all cars 1996 and newer.

Other than that, it should work on basically all cars, assuming you don't have e.g. an existing backup camera that mechanically blocks the installation.

The solar window is actually transparent. Our PD team is second to none! They were able to make the whole solar assembly look uniformly black while not sacrificing solar efficiency.

The camera frame is indeed paired with the car adapter at the factory, which is a theft deterrent. They will not function without each other.

The RearVision also comes with a security tool that must be used to attach and remove the camera frame.

Excellent question. It takes decades for new features to fan out to the majority of new cars. After that it then takes decades more for those features to reach saturation of all cars on the road, because only 7% of the car population turns over each year.

The bottom line is it's generally 40 years from the point when features like seat belts, air bags, traction control, and backup cameras are first introduced and when they reach 95% saturation.

Throughout this adoption process, demand for these features among those whose cars don't have them increases significantly!

The RearVision comes with a security tool that is used to attach and remove the camera frame. The camera frame and the OBD adapter are also paired at the factory and will not function in isolation.

The OBD adapter does serve a very important role in the system in that it has a power source and can wake the camera frame when necessary (before you ever launch the app!). All of our vision algorithms also run on the OBD adapter, which is a key aspect of the power model.

And I'd love to show it to you! :)

The video screen is definitely the main focus of the app, for obvious reasons. When the video stops, we also show an app launcher screen that's optimized for use in the car (large touch targets :) ), which you can configure to include a few of your favorite music or nav apps.

There is! The solar charging should be enough for most everybody. We have done testing in a variety of locations. As a backup, though, it can be charged over USB.

Aside from power, we do use the OBD port to detect things like reverse and speed (to stop the video automatically when you hit 10mph).

In general we want to integrate our products into the car and the driving experience as much as possible.

With literally zero solar charging and under normal usage, the battery should last over a month. Most people get at least some solar charging, though! If nothing else, at least while they are driving, parked at the grocery store, etc.

We've really tried to make this experience as smooth as possible. The product comes with a superb magnetic dash mount for your phone. Frequently our app will show up on your lock screen in iOS, so you can just slide up to launch into the video view.

We will of course leverage whatever tools both platforms provide to make the launching experience as seamless as it can be! We can also take cues from accelerometers, the OBD port, and other sensors, as you mention.

Thanks!

Based on our design and testing, the solar should keep the vast majority of users charged up (it has for me!). As a backup we do support USB charging as well.

Thanks dang! Totally understandable and I am happy to post again when we start shipping them out.

It's such an amazing feeling to put your blood and sweat into a product for months and finally be able to share it with the world. It's great to take our startup out of stealth mode today!

I couldn't imagine a better group of people to do it with, either.

It's been great working on this product, and with this amazing team, for the past couple of years!

Sure feels fantastic to take the "stealth mode" veil of secrecy off our startup today.

This story starts out reporting on a board ousting a CEO after a public scandal involving non-compliance with various laws, which incited multiple government investigations.

It then takes an abrupt turn and starts repeating everyone's favorite Silicon Valley trope du jour: the unicorn bubble is bursting, the fundraising environment is tightening up, and the halcyon days of multi-billion dollar valuations for everyone are over.

There's really no connection between the two.

That this is currently the top comment reinforces the author's hypothesis that many software engineers underestimate how much they could make at a large company.

> 250k a year in 5 years at a big corporation, really?

Yes, really.

> Yea if you're lucky to work on a project/team higher-ups care about and are also willing to bust your ass working long hours to meet insane deadlines.

Nope, not true.

> So I think this article is spreading a myth that there is guaranteed piles of money to be made by working at Google, Facebook, Apple, etc.

Have you worked at Google, Facebook, or Apple for 5 years? If you do, and you're a decent programmer (not a rock star, but a solid contributor), you'll find there are guaranteed piles of money to be made.

I was going to reply to you and say the same thing: it's extremely similar to the initial iPhone 3rd party developer story, and for the same reasons. Apple is pretty predictable, really.

I know how WatchKit works, I was in on some of those meetings... Trust me, everyone at Apple had the same concerns you expressed and they still do. It will get better over time.

Also note that some built-in Apple apps do use WatchKit.

And I would still argue that allowing 3rd party code to run on the watch instead of in an extension on the phone would be just another example of an internal-only feature being opened up to the public. It's the same pattern. I realize that's a significant "feature", but so was the switch from html+js to native apps on the phone. And those significant advances go through the same decision process as smaller ones: do we feel comfortable opening up this feature to 3rd parties? what are the risks? have we used it enough internally to feel confident? has it iterated enough internally that we consider it stable enough to release (because it's hard to change after release)? etc.

Your point is actually orthogonal to the OP's.

The OP was claiming that Apple's architecture is flawed and that once they realize the error of their ways, battery life will improve dramatically. That's just not true.

Your point is that the public SDK limits 3rd party developers from doing some stuff that Apple can do with the private SDK. That is, of course, absolutely true.

Letting the public SDK (or at least parts of it) lag behind the private SDK, while certainly frustrating to 3rd party developers, is the right thing to do. The situation is exactly the same on the iPhone, iPad, and Apple TV. Apple has employed that strategy from the beginning with iOS, and they believe it to be the correct strategy, so they will almost certainly stick with it.

I don't work at Apple any more (pushing toward launch on a startup!), but based on over 8 years of iOS history, I think it's safe to say that the public watch SDK will get more powerful over time, as private-only features are deemed ready to release to 3rd parties.

I never understand how someone can write an article about their very first foray into something and then, at the end, assert that they know more than the experts already.

> In the end of the day, the watch battery is there just to shuffle these .PNGs around. When Apple realizes how to avoid that, the watch will last for a week instead of hours.

Drawing every frame using CoreGraphics is a terrible idea, on any iOS device. Just like any platform, you have to understand at least the basics of the underlying architecture if you want to write efficient code.

I happened to make the built-in Stopwatch app on the watch, which displays an animated graph very similar to his. Suffice it to say, I did not use a CADisplayLink and CoreGraphics at 60fps. Especially considering my graph is horizontally scrollable by the user.

Even if WatchKit still doesn't provide a more efficient way to do this (I don't know; I've never used WatchKit), rest assured that Apple's apps certainly don't use this method, so the week-long battery life claim is just a dream, unfortunately.

For iPod users, that is entirely reasonable (since they are basically required to have headphones handy to use the device at all), and that is exactly what we did.

For iPhone users, who never took their headphones out of the box, or lost them months ago, or simply left them at home today... it's less reasonable.

The fact is, most iPhone users don't have their headphones with them most of the time. That means the vast majority of launches of the Radio app would go straight to the "Please plug in your headphones" screen, at which point the user would be frustrated because they don't have headphones to plug in.

Whether it's worth it to include a feature that would result in frustration for many users, but yield utility for some users, is always a tough call. It's not black and white.

While half-baked conspiracy theories are fun, a good journalist would've consulted a few more sources to get to the bottom of this story.

FM radio requires a large antenna. It will not work without one. The 5th generation iPod nano (2009) was the first iPod with an (enabled) FM radio. We used the headphone wire as the antenna. It worked well enough. While there was a tiny speaker in those iPods, headphones were the only practical way to listen to audio.

That's not the case with phones. People listen to the built-in speaker, and they listen over bluetooth and WiFi. It's becoming less and less common to plug headphones into these devices. That being the case, including an FM radio feature would just be a horrible experience for the majority of users: they'd hear nothing but static, all the time. I don't know about the other smartphone makers, but Apple will not ship something that will likely be a horrible experience for most users. Couple that with very low demand from users (as the article points out) and there's no FM radio on iPhones.

None of the articles I've read about this answer the one question that matters to me:

Will I be able to land (and base) my plane at Google-run Moffett Field?

> I know this is a frustrating situation for everyone involved. But the cynicism that says there is some ulterior motive cuts deep, especially coming from someone I respect like you, Matt.

Ha! HN loves GOOG. Try frequenting this site as an Apple employee...

Adam,

My wife's uncle made the original Admiral Ackbar costume for the movies. If you wanted a costume, you could have just emailed me and I would have put you in touch with him.

Regards, shoe

In addition to the sketchy mathematical foundation, there's another reason to not draw too many conclusions from this observation: your company, product, and customers are probably quite unlike Southwest Airlines. For starters, airline customers care almost exclusively about price.

Joel Spolsky was wise to warn against doing what this article suggests (http://www.joelonsoftware.com/items/2007/09/11.html):

    In one of Gerald Weinberg's books, probably The Secrets of Consulting, 
    there's the apocryphal story of the giant multinational hamburger chain
    where some bright MBA figured out that eliminating just three sesame
    seeds from a sesame-seed bun would be completely unnoticeable by anyone
    yet would save the company $126,000 per year. So they do it, and time
    passes, and another bushy-tailed MBA comes along, and does another study,
    and concludes that removing another five sesame seeds wouldn't hurt
    either, and would save even more money, and so on and so forth, every
    year or two, the new management trainee looking for ways to save money
    proposes removing a sesame seed or two, until eventually, they're
    shipping hamburger buns with exactly three sesame seeds artfully arranged
    in a triangle, and nobody buys their hamburgers any more.