[morganvachon]

I'm not a UX designer by any stretch, but as a consumer I can say that if Apple can pull off the downsampling/downscaling correctly, good on them. I have a Kindle Fire HDX 7", and recently upgraded to a Fire HDX 8.9". The former is 1920x1200 and 323 PPI, the latter is 2560x1600 and 339 PPI. That's not a huge difference in PPI in fact it's far less than the difference in the two new iPhones, yet so many apps (mostly games) render incorrectly on the larger Kindle, to the point that small text becomes unreadable.

If Apple can release two new phones with greater disparity and seemingly get the app experience right, why can't Amazon? I don't use an iPhone but seeing these explanations that break down how they pull off such a feat really impresses me.

[MCRed]

I haven't worked in the Kindle division, but there is a huge cultural gulf between Apple and Amazon. Apple is very much a software company (well they're a design company that encompasses both hardware and software). They care a great deal about getting software right. At WWDC each year they have a session on how to do great software that illuminates a process that involves a lot of design and upfront work before you begin coding. A process that virtually nobody does these days. (I say these days because back in the 80s this is how CS students were taught "write your program out in paper before writing it in code". Nowadays nobody barely thinks about their work before they start writing code, for the most part.)

This is the polar opposite of Amazon, which I worked for in the past.

Amazon is perceived as a high tech company but it is a retailer and its management is the management of a retailer. Amazons engineering is overseen by non-engineers and the company culture is highly political and focused on making a show more than making a product. Quality is the last thing they actually care about (when it comes to software.) You get ahead at Amazon with press releases-- it never matters if your product makes no sense. (EG: Movie listings on amazon.com, mail-order catalogs, literally scanned, and posted to amazon.com, innumerable initiatives and features that were put up there getting someone a promotion, only to have the team disappear in the next quarterly company wide reorg and the result to just rot.)

This is why I would never buy a tech product from Amazon. They really don't give a damn as a culture, and any engineer who gives a damn will not survive long there (and will be punished).

Giving a damn about design and quality doesn't play well with stack ranking.

What plays into stack ranking is kissing your bosses peers butts, playing political games and making splashy new features.

[derefr]

Huh. Does any/all of that apply to AWS specifically as well, or is it an exception?

[BugBrother]

>> Nowadays nobody barely thinks about their work before they start writing code, for the most part.

I am old enough to remember where this came from...

I used to do C for quite a while, then I made my hobby (Perl and scripting) my day job.

If given a certain size of a problem while working alone, I used to sit down and think for 1/2 a day or so, then develop (coding and also thinking more) for a week or two.

After I went scripting, this didn't work.

Since I could over an afternoon throw together a solution to the same size of problem which took a week in C, it was just not realistic to think first!

The best solution was to throw something together, look at it and then rewrite it if I didn't like it. The sheer development speed felt like I had gotten a sports car.

[tracker1]

Absolutely agreed... prototype-morph-prod is a faster cycle.. but on the same lines, it means automated unit tests are more important the more complex projects get. Which is why modular code and testing work really well with scripting environments, and computing is fast enough.

With a modular approach, it also becomes easier to scale horizontally either in the same server/system or a separate server/system. Either via HTTP, TCP, 0mq or another abstraction, if the interfaces are the same, the modular layers can be replaced. This gets easier with async by default environments (node.js, golang, etc), and I find it to be much harder with classic N-Tier (.Net, Java). I'd rather use 0mq with node than wcf with .Net any day of the week.

[BugBrother]

Interesting point about scaling, thanks.

[eddieroger]

Apple documents the crap out of it, and pages like on the dev site, and summaries like this are just built of that (usually aimed at a less technical audience than the dev portal). I think that's what helps the most - I've been able to tell every designer I've worked with what resolutions I need and how I need the files suffixed, and since they tend to use vectors anyway, it all just works out. Amazon must not put the same amount of effort into documenting, but admittedly I don't know about that.

[morganvachon]

I think you've hit on a big part of it. It seems Apple works more closely with their iOS developers than Amazon does with their Android developers. The Fire OS itself is very nice, fluid, responsive, and makes sense when you treat it as a purely consumption oriented device. That's why it's such a shame that third party apps and games can look awkward on the larger tablet; the user experience should matter more but it seems Amazon doesn't want to put in the same effort to support their third party developers.

[naspinski]

Have they gotten the experience correct? Serious question, I haven't seen them.

[morganvachon]

I haven't either, but all signs point to "yes". I have a friend eyeing the 6 Plus as an upgrade from his Note 3, so I may get a hands-on soon enough.