Are Designers Crazy?
shkspr.mobi
shkspr.mobi
But those who care about the details achieve truly high quality results overall. It extends to all areas of the design, not just to the parts you can't see.
In the movie "Who Framed Roger Rabbit," there's a scene in a dark room where Roger Rabbit (an animated character) flies across the room, knocks a hanging lamp around, and the lighting becomes so dynamic that all the shadows move around including the animated character's shadow. Here's the scene in question: http://www.youtube.com/watch?v=_EUPwsD64GI
This was such a small detail that it would have been forgivable if the animators had left it out entirely: if they had not moved the lamp, kept the shadow steady, no one would have really noticed the difference. It would have been 100 times easier to animate and the effect wouldn't really have been that different.
But they did it anyway. The term was later coined, and "bump the lamp" is used throughout Disney (and probably other organizations) to mean something akin to "go the extra mile"—but I see it as having a special significance to design.
You're right, most people won't notice. By that logic, you could cut corners a lot of other places too. You could be lax about button colors matching exactly, or per-pixel sharpness on the map and buttons. No one would probably notice.
But if you go for every detail like it was the most important detail, you have the possibility of reaching a level of design quality that is superlative, and some people will notice. Others will not notice directly, but will see that the piece exudes style and quality subconsciously, due to the attention to small details. If you carry this into other areas of your work—programming, customer service, market strategy, marketing, and more—then you have a chance to create something of true quality.
If you don't pay attention to detail at that level, well, you might have the chance to actually get something done. Yes, it's a balance, like everything else. But you have to know that it won't be quite as good, and understand that yes, you are sacrificing something, even if you can't see it.
The fact of the matter is that people usually do notice, if only subconsciously. If you show someone a clip from a Disney movie and a clip from a Hanna-Barbera cartoon, they will be able to tell that the animation quality is much crappier in the latter. They won't be able to tell you why, but on a visceral level they will be able to feel the difference. [1]
This visceral feeling of "quality" is what gives Apple's brand such cachet. Sure, their skeumorphism can be tacky, but it's never slapdash. Their apps always run at the highest framerates, and their touch interactions and animations have always been tweaked to a level that their competitors can't match.
Now, if you asked someone what the difference was between Mobile Safari on an iPad Mini and Chrome on a Nexus 7, no one would say "the scrolling is much smoother on the iPad, and the variance in framerate is much lower as well, which contributes to a feeling of responsiveness and playfulness", but those features still contribute dramatically to the "feeling" you get when using one of the two devices.
Now, sometimes it really doesn't matter. The example in the OP seems particularly silly. However, don't underestimate the value of "bumping the lamp" when it comes to design or interaction development. People will notice.
[1] The answer to the "why" has many parts, but mostly involves the fact that Disney animation runs at 24fps while HB cartoons ran at 12fps or even 6fps. Disney animation involves characters that are carefully articulated and that move realistically and with a sense of weight behind them. Also, the general quality of animation and camera work was just better -- look, there are a lot of reasons. They all add up to the difference between Scooby Doo and The Little Mermaid.
It sounds like they optimized for the wrong thing.
You can take your Hannah Barbara example as proof that some intangible things have an aesthetic impact, but you still can say when you see the two cartoons that one seems to be of better quality -- I hardly thing that is 'subconscious'. I think this article is intended to focus on the things designers do that are stylish yet unremarkable or wholly unnoticed, which any sensible designer must agree is something of a problem for web designers.
Now, it works because of the HB cartoons' light-hearted style and premises, but would seem tacky and ridiculous for a film or episode attempting something grander (i.e. a feature film like The Little Mermaid or Toy Story).
[1] For example, many HB characters don't have necks, or have extremely thick necklaces or collars where a neck would normally be. This allows you to swap out head and face animations with much greater freedom, and makes it harder to detect camera errors when the head and the body don't quite line up correctly. Is that bad? Not necessarily, but if you rely on too many of these tricks you end up painting yourself into a corner.
[2] Also, some HB characters don't even walk correctly. Their torsos and upper bodies stay perfectly motionless while their legs flail about beneath them. It looks cute and storybook-like in certain applications, but completely ridiculous in most others.
I mean, in terms of the 80/20 rule (the last 20% of quality costs 80% of the time), we're not talking about turning an 80% thing (i.e. typical in-house enterprise software) into a 90% thing here. Hell, even going for 95% is something I believe we should all go for, and fight our colleagues, bosses and project managers, and customers for. But the OP's example is more like turning 99.5% into 99.8%.
Personally, I believe that much of the value created lies in the final 20% that takes 80% of the time. If what you say is true, near anyone can create something that's 80% of the way there. It's your job to get as close to 100% as you can realistically, while balancing time and money and value. It's not an argument for unlimited perfectionism; it's an argument for quality. The higher you can get, the better you will produce, and the more you will succeed. And don't just limit this to product quality; extend it to everything you do (including customer service, including planning and resource management, including hiring and culture) and you'll create a company that has a chance of being better than the others.
Perfect? No. But if you're not striving for creating something of quality (in other words, of value) then what are you doing, exactly?
Edit: There's a caveat here, I think. It may not be your job to worry about every design detail down to the pixel. It doesn't have to be. You can find someone who can help you produce what you need at the level of quality you desire (like the designer the OP is talking about, presumably) and you can worry about all the little details of running your company. Details that I'm guessing a designer might not understand or care about, but you do.
Maybe for this case in isolation going the extra mile to this level of perfection is not justifiable, but if the designer is doing good work and meeting deadlines then you should keep your bean-counting micro-managers far far away. To attempt to quantify everything (even in programming) is to take the human element out of creation, and that runs a severe risk of throwing the baby out with the bathwater.
There are coders out there who strive for absolute, unlimited technical perfection. They rarely if ever ship - and ditto for designers in that boat.
In reality most designers, and programmers, walk a balance between the bottom-line functionality of their work and less concrete (and more subjective) qualifiers like code quality or sub-pixel scaling.
There are many analogues between design and code here. Most people here would agree that sloppy coding standards aren't deadly, but encourage sloppiness on a larger scale over time. Ditto, sloppy design is insignificant in the individual case, but have the tendency to accumulate and lower the bar.
The example OP chose was particularly bad, mostly because as an iOS dev I know for a fact that getting 1x assets right doesn't take that much time. The usability improvement over time invested is not atrocious - certainly nobody spent an extra week just to get some pixels to line up just right.
The major problem with scaling 2x assets down to 1x devices is that thin features become muddy and blurry, while code-wise UI elements may become aligned against half-pixels, resulting in filtering that produces blurriness. Both the design and code elements of this are easy fixes for any competent iOS developer/designer duo, and takes no more than an hour or two at the extreme most. You get a pretty clear legibility improvement for not a lot of man hours.
Not to mention the very noticeable blurriness of the buttons in the "unfixed" versions - things that users do notice. So much so that some of them can actually articulate it (as opposed to merely being a subconscious annoyance).
Design is not art in and of itself, but you can't talk about one, without talking about the other.
SUPER IMPORTANT!
If you are not in that situation, could it be because you weren't perfectionist enough in the past?
E.g Nokia vs Apple.
And tried polishing symbian. Which had a number of terrible design decisions at the core (which may or may not have been good ones 15 years ago, when they were introduced into EPOC, the ancestor of Symbian). And those decisions affected everyone who worked with it, both internal Nokia developers and external app developers. It made developing for Symbian a pain. It was natural, that iOS and android (and Windows) passed by.
To add what little I can to this, the reason that drives me to go to these lengths is the craft. Design, like code, is a craft. A good craftsman just does not leave mistakes in their work purposely. Whenever I do this it slowly drives me crazy until I either go back and fix it, or drop the project entirely (if there are a lot of mistakes and/or things I don't really like), usually citing some reason like 'it's too messy' or 'i lost interest'.
For me, design and programming are not all about a/b testing, 100% time efficiency, etc. A lot of it is about art -- making something you know is great and shipping it. When you know something is wrong with your work as an artist, it will bother you until it's fixed.
I am a lead designer, and I know that not every piece needs to be a masterwork, but ever piece of software does need to ship.
Absolutely not the case. We're talking about quality specifically, and why someone might choose to pay attention to finer details versus ignoring them.
Your reasons for ignoring details might be perfectly valid and entirely appropriate. The project may not call for artistry and mastery. All very good points for a different discussion.
Don't think for a moment that those who believe high quality is an important factor are implying that it is absolutely necessary. That is simply a false dilemma.
My point was that the ONLY thing that was listed was details being the separating point, and that there is more to it then that. It wasn't meant as a quip just a clarification, if anything a question even, not requiring a snarky answer but maybe a genuine one. But, I forget, I'm on the internet and snarky is everyone's default for whatever reason.
Basically "I completely agree with you, but wish to do so in a humorous and sarcastic manner." Apologies.
The same sort of technical ugliness and lack of optimization happens in plenty of programs.
In theory, one should never optimise prematurely, and get the application working first. Only at the end profile the speed, find the one single slow loop or algorithm, and optimise that.
But plenty of applications acquire slowness not due to one core slow algorithm, but a lack of concern for even trivial optimisations everywhere. You end up with something like Eclipse where a keypress can take multiple seconds to appear, or a "cancel" button might take minutes to stop whatever task. And there is no place to optimise, because the inefficiencies are spread out by tiny bits everywhere.
1. A work of art is created by definition to be beautiful. While a beautiful UI is awesome and definitely something to strive for, it is not the end goal.
2. A UI can be changed after its release. Unlike art, you can release a UI and then later change details that are important.
3. Most companies do not have the manpower or time to actually get to the place where the entire product is pixel-perfect. pg's mantra is: "release early." This means that not everything is going to be perfect and you have to decide what corners can be cut and which cannot. (You cannot simply state, I am going to cut NO corners).
4. A UI is likely to change. When you first release a UI you dont really know how it is going to be used. Therefore, as the OP suggests the improvement from 95%-98% really does seem like a pre-optimization.
That said, the UI should make the experience easier in that it aids the function. I would take it a little beyond that where you want something attractive to look at, but it doesnt necessarily need to be in the v1. As the UI matures over time beauty in design becomes a more important goal.
Why is the always treated as truth whenever non-artists discuss art? This is a backwards, 19th century era concept. Art broke out of this generalization over a hundred years ago.
Of course, with experience also comes the knowledge of which things are more important, and which can be sacrificed for the sake of saving time.
But it's often hard to tell the difference. A lot of details that seemed superfluous at first turn out to be crucial. So if you can afford to, it's safer to bring the maximum level of care to everything you do.
Instead, reading through these comments I see pretty much nothing but personal opinion, vigorous hand-waving, very poor and stretched-to-breaking analogies and the usual "because it means this to me" and "because I say so" and "because... Apple" arguments.
I'd suggest reading again with the mindset of "this is the way non designers think about us" and then come back and (with facts this time) explain your perspective.
And remember... this is Hacker News. We work at Start-ups. We believe in shipping early, shipping often, and iterating to improve. Your answers and perspective MUST work within this construct or we will ignore you (and you will thus teach all of us that designers are, in fact, crazy).
Ball's in your court.
Heh. Because "business decisions" are always so rational, demonstrating a genuine understanding of the product and what the people that actually are going to use it will want from it?
> And remember... this is Hacker News. We work at Start-ups. We believe in shipping early, shipping often, and iterating to improve. Your answers and perspective MUST work within this construct or we will ignore you (and you will thus teach all of us that designers are, in fact, crazy).
Sigh. Some of us want to ship genuinely high-quality products, not ship whatever we manage to shit out every other day.
If my users are noticing my bugs (or design faults), that adds up to an aggregate middling opinion of my product. One thing you got right -- I do want to be Apple, not Time Warner Cable.
> Ball's in your court.
Not really. You sound like someone that will willingly produce mediocre products, and I don't really know why anyone interested in excellence (and the rewards that it brings) would want to work with you. So this becomes a self-fulfilling prophesy for yourself.
Most products have a budget and deadlines. Your job as a designer is to do the best job you can given the time and money allotted. There are very few projects that have unlimited time and unlimited money.
I've been on too many projects where designers didn't get that and given the promises to distributors, retailers and advertisers we had to ship a worse product than we wanted to because the designers spent to much time perfecting certain elements and not giving enough time to others.
And many of them just lack pragmatism. There's a point where stuff is $good_enough and a user wouldn't ever notice that it's not optimal - but still many designer tend not to accept this. They strive for perfection. (Which might be fine if they weren't burning my money.)
But that's not confined to designers. Lack of pragmatism is generally a problem. Many engineers I know won't let a problem go until their solution would work for every possible edge case - even if it's impossible for said edge case to happen with the current project.
Designer culture in startups is still relatively new; most of us are still relatively recent imports from graphic design & advertising agencies where things are totally different.
But I've seen programmers exhibit the same deadly perfectionism in startups (namely, premature optimization. overly-ambitious architecture for week-long MVPs, and writing hundreds of lines of Rspec tests for code that is designed to be thrown out after an experiment).
Yeah, programmers are not immune to that. When I was younger I wanted to be a game developer. So I made games ... well, I rather designed game engines, threw them away as I came up with 'better' designs and threw those away too because I dreamt up an even better system.
In the end I didn't ship even one game in my 6 years of being an aspiring game programmer :)
Your idea of "good enough" almost certainly isn't. Users do notice even if you're too pigheaded to admit it.
"Ok... Now I see some differences. On one, the
buttons are slightly larger, the colours slightly
more nuanced, the shading is subtly different. If
I zoom to an extreme level, the font on "ebay"
in slightly smoother."
The main difference is pixel fitting [1]. The fuzzy border lines on the buttons are like "nails on a chalkboard" to me. "Nails on a chalk board" don't actually bother me that much but I notice it. For many cases I would just ignore it. However, if I am shipping a product that I am hoping will get free advertising from people talking about how beautifully it is designed, I am going to pixel fit the damn thing.
In this case, the designer is not being crazy, he is looking out for the the bottom line. Free word of mouth advertising and free blog articles written about the beauty of the pixels contribute to the bottom line much more than the cost of doing a little pixel fitting.
Look at the Hulu example below
Really? Give me the data to back up your bottom line claim. Because in my (5 and counting) start-ups I've seen little to no impact on the bottom line from design blog posts.
I believe products that are designed well and polished get more attention from blogs and receive more word of mouth recommendations. I believe one of reasons iOS and the iPhone helped propel Apple into becoming the largest company in the world was Apple's attention to design details. However, I have no way to test or prove this theory. So please disagree if you like.
2 - Normal blogs and tech blogs don't write articles that go into detail on the minutae of the design elements in a product's UI. That's limited to design blogs.
3 - Personally, I'm getting kind of tired of the default defense of most designers to this sort of criticism ("because Apple"). Saying that Apple is where it is because of Design not only ignores the market, product and business realities that have lead to Apple's (recent) success - it also ignores the many ways in which Apple's design is sub-standard or even bad (resulting in people copying bad design patterns "because Apple did it").
Internally, I think it's also a way to have the designers/developers proud of something they helped accomplish. No, I didn't perform any of the design on the SeatGeek app, but you'll bet your ass I'm not complaining about the three hours I spent uploading about 100 - outsourced and therefore not named well enough for me to automate it - logos to S3 for use in the app. It's a source of pride, and it's what staves off the burnout.
Reference: I work on Operations at SeatGeek, and after slicing up a PSD to very exacting specifications two years ago, I know exactly what kind of a difference design can make re: tech blogs/traffic.
As with any vector rasterization, you do trade accuracy for pixel fitting, but for things like small body text you almost always want that. For example, if the 1 pixel wide vertical stem of a "b" is supposed to be between two columns of pixels, the hinting algorithm can push the stem either left or right so it is rendered as a single black column of pixels, rather than two gray columns of pixels. This will look less fuzzy, but it will technically cause the "b" to be closer than it should be to an adjacent character.
I was thinking about something more elaborate, like an algorithm that takes distances between neighboring elements, proportions and other factors into account (and which can be tuned to include/exclude factors).
An example "smart" rule would be: If a group of elements are aligned, the same size and the same distance, they must remain aligned, the same size and the same distance after the processing
Ideally it would be a plugin for a vector graphics application which could then allow the designer to add finishing touches to the places where the algorithm got it wrong.
But you can probably go far by just fitting everything in your 2x version to even pixels and using even-width lines; then the scaled-down 1x version will be sharp.
If you have seen Jony Ive's tribute to Steve Jobs, you may recall the part where he talks about "giving a damn". I think that is very relevant here.
But what happens when you want to refactor something when 1) it's not strictly necessary in terms of functionality and 2) it will cost the client some non-zero amount of money. You easily slip into a gray area that this visual example illustrates well. Sure there are differences but are they material to the overall design goals? It's hard to say yes.
There's no such thing as "giving a damn" in an absolute sense. It's hard to say that any software product is ever done. If that's the case then it's the programmer's / artist's responsibility to say when something is good enough for the project's current goals.
The higher quality thing is still higher quality, regardless of time or value constraints. If you choose a lower quality path while acknowledging you're balancing time and money, you're still choosing lower quality.
Realistically you can't achieve perfection (sometimes even completion) because you don't have unlimited time or money, and there are always new variables. But it is important to strive for that high quality as an ideal, even if you can never reach it. You know it is still better in some absolute sense. It's always out there as an intangible goal, and if you reach for it, you can understand and center on that balance beam even better.
Framed like that I would say "yes, I never want to deliver something of 'lower quality'", but in this case (the two interfaces) one really doesn't qualify as lower quality. We're talking about the difference between "good" and "slightly, almost imperceptibly better". Having said that I'm not a designer and maybe if I were I would have a different opinion about this particular case.
>> But it is important to strive for that high quality as an ideal, even if you can never reach it.
No, I think it's entirely possible to deliver high quality. But we do have to deal with the law of diminishing returns and it's up to us (programmers, designers) to know what's best for our client (or ourselves).
I did say, "realistically you can't achieve perfection" which would appear to indicate that I'm not kidding myself here.
Understanding quality in both the realistic obtainable realm, as well as the unobtainable more-pefect level allows you to differentiate the two, and make conscious decisions about the level of quality you're targeting as well as your ability to do so in reality. The higher unobtainable level of quality doesn't even have to be close to the perfect you're talking about—if you have time and money constraints, that unobtainable level of quality might be a lot lower than perfect.
If you dismiss all levels of quality above a certain level as being this mythical unobtainable thing before even attempting to think about them in the abstract, then you've cut yourself off from a true understanding of the balance and compromise involved.
Of course you can't achieve it, but that doesn't mean you shouldn't be aware of it.
At some point this idea becomes a philosophical discussion and ceases to be useful. Just as at some point, your perfectionism becomes a philosophical endeavor and ceases to be useful. There is a balance where the pursuit is useful and complete.
I read some short story (that I wish I remembered the title of) when I was a kid about the idea that achieving immortality on earth had caused people to stop producing anything useful in their quest for perfection.
I don't understand where people are getting the idea that we are to ignore balance, constraints, and reality in deciding how to complete a project.
Absolutely not the case. We're talking about quality specifically, and why someone might choose to pay attention to finer details versus ignoring them.
Your reasons for ignoring details might be perfectly valid and entirely appropriate. The project may not call for artistry and mastery. All very good points for a different discussion.
Don't think for a moment that those who believe high quality is an important factor are implying that it is absolutely necessary. That is simply a false dilemma.
"someFunction(); "
the things the OP talks about are things that designers claim make a direct difference to the end user. if you know a programmer who claims that about indentation, he is, in fact, crazy.
When I design, I am placing myself in the viewer/users shoes and thinking about what it is they are trying to do/understand. The subtile differences may not be critical when viewed at first glance but the designer thought it affected the experience enough when they were thinking about it from the end-user/viewer's perspective, that he/she thought it needed to be slightly different.
Sometimes it is just insanity. Yes, I admit it is a bit crazy to spend 30 minutes on something that no one will really look at twice and I'm completely guilty of it. And as a designer, sometimes we can't help ourselves... because "it just doesn't look right." I can't explain what "right" is but I'll know it when I see it... so I'll experiment with a numer of different approaches.
Sometimes however, it's a genuine care for the experience and the cumulative effect of sweating the small things showcase a level of polish and care that Apple is/was famous for. You just have to decide whether it matters to you (as a company) or not.
Some of the design choices made for the two versions seem like just an evolution in the style for the app that weren't back-ported to the older version. For example, the different colors of orange for the button, gradient shading, etc. Other changes are adjustments that, from his eyes, seemed necessary to make the experience better/acceptable on the 2x version, such as the sizing of the Search button, border bevel, etc.
It's the year 2013, and your competition is using frameworks like Bootstrap or Foundation to release something while your dev team is fussing over bespoke line-heights specified in points. Maybe your app looks better, but how many users are waiting for that placed-just-so button image to download?
We take design very seriously, and thats because better designs have been quantifiably proven to have a meaningful impact on our bottom line. That means sometimes we try and polish something for the first release, but we always set a limit to that - if it's not in production, it's not shipped, and we will forget about it amongst the 23524 other things going on in a given week. Therefore, we usually set at least some internal goal of "good enough" and then ship. It just so happens one of our founders really likes digging into design.
Also note, this is an iPhone app, not a web application. Very different rules apply here, so you can't just slap Bootstrap on your UI and hope for the best :)
For a developer, an example of equivalent behaviour is being overzealous about a specific programming paradigm. Things that can't be directly quantified in business terms (unlike "response time").
IMHO, it's about pragmatism and business sensibility versus artistic perfection. And it applies for both worlds.
An argument from a more business-oriented visual designer could be, for example, about how some button color can affect conversion rate.
People want to use things - i.e. products, digital or otherwise - with style and performance. People, real people, don't give a rats ass about computer science or design - they just want the product to do something for them and they want to look cool doing it. With their expectations of performance aside for the moment, there is nothing cool about engineers "optimizing" style.
In my experience engineers who think a little bit about design work better with designers than those who don’t.
There seems to be an aversion to A/B testing because that would clearly challenge their title of "experts".
Once you get down to a functional and complete design, it's useful to A/B test details to optimize.
But it's nearly impossible to design something using an A/B test. Design simply does not work that way—it is not an evolutionary process on three variables, initially whether you believe in it or not, it is an art and as such takes in thousands of variables in thousands of forms and outputs something that works. That's the job of the expert—at the beginning, they are using their internal A/B test to produce something they know will be successful in the grand scheme. Give them a chance, please.
A/B testing is useful, of course, but the results can only ever be as good as the options you test.
Most problems with perfectionism in design and engineering come from people making bad decisions early on in the design/development process and not realizing that something is fundamentally wrong until much later on--when its much harder to fix.
Notice how the edges are now fuzzy? On the buttons, on the edge just below the map, on the cog. That sticks out to me personally on this monitor here, and I tend to find differences like becoming even more noticeable when looking at the phone with it's hi-res "Retina" display.
They may not be crazy; they just notice different things. :)
Of course, I still watch analog NTSC on a CRT TV, so what do I know about image quality?
> *"A design can be wrong. The entire thing can be wrong, parts can be
> wrong, or even a tiny, 10x10 pixel area can be wrong. Not, "I think it's
> good but it needs improvement" but flat-out wrong. 1 + 1 = 3 wrong. A
> spelling mistake in a book wrong. A syntax error in a code file wrong.
> It's not an opinion, it's not a matter of subjectivity, it's a fact: a
> design can be wrong."*
The buttons with numbers in his example are such.
There's still the question of whether fixing it is worth it or not though...
However, I'm frustrated with designers who associate thoroughness with being "pixel-perfect". Pixels should not be the focus. We live in a multi-res world; different people have differing visual acuity and varying ppi screens that they hold at varying distances. Being user-centered means accounting for all that variation, not optimizing individual pixels for your super-designer-vision. Just use vector art instead.
I hoped that the retina iStuff would finally break designers of their pixel-focus, but it seems that it's just become a way to obsess even more about pixels.
There's nothing wrong with beautiful design as long as you are willing to accept the fact that at one point it is serving art and not business needs. And that's OK.
If the requirement is to strictly serve business needs, then you have to A/B test, generate numbers and go with what optimizes conversions or whatever you are after. People react to what they see in amazingly different ways. I don't think anyone has a canonical "manual" for what will please most people or what will compel most people to take a given action. I mean, look at Craigslist!
it's becoming a problem. look at dribbble. countless designers would be more likely to obsess over a single misaligned pixel rather than focusing on far more impactful improvements to the user experience.
a pixel perfect button in the wrong spot will always perform worse than a misaligned button in the right spot.
I will notice pixel perfection every time. So thank you all for the attention to detail.
Also, if the @2x version has 1px features then these will definitely become blurry when scaled.
Even so, when held at arm's length I'm doubtful of how noticeable the differences are.
I know of no-one, tech or non-tech, that holds their phone at arm's length. Most hold their phones much closer.
I think I have a way to explain why pixel perfection is a very good optimization that caters to more of a a developer mindset like yourself; it comes down to image compression, and specifically PNG compression.
When it comes to UI elements, the fewer colors you use, the better. This means avoiding things like gradients, or unnecessary colors can have a major impact on file size. It's also the 'art of design' to manage to create a beautiful design without a lot of crappy and needless 'veneer'.
I don't know the specifics of the PNG algorithm, but it can do an amazing job at compressing an image if it's made up of few and often repeating colors (typically it's terrible at photographs, however).
When you apply a scaling algorithm (as exemplified by the post) other than nearest neighbor, it tends to create a lot of intermediary colors that end up hurting the size of the image.
Looking closely at the borders of those buttons, that blur is going to end up adding to the file size because it adds colors that didn't exist before. If you properly 'scale' (which sometimes requires a redraw at a smaller size to get it right), it can have a huge impact (sometimes as much as 2x or 3x).
Oftentimes you can get away with it from a 1/2x scale fairly easily, but you have to remember there are many android devices at a 1.5x scale, and that can sometimes require completely new rounded corners that take advantage of that pixel density.
This is of course anecdotal, but it's not as simple as 'looks' even though I could immediately see the differences between the properly and unproperly scaled images.
There seems to be something similar to the 'uncanny valley' where something nearly complete becomes more obviously incomplete before being complete. (I know how crazy does that sound!) But an example might help, if you straighten up a room, it goes from fully chaotic to less and less messy until the 'organized' parts start dominating the scene with respect to the messy parts. Than as you approach completely organized a small bit of chaos sticks out more and more. Until that is eliminated and everything is in its place.
Different folks have different tolerances (I know, Doh! right?) People who consider themselves designers have worked hard on being able to see where something can be improved visually, so they are much more likely to see issues that detract. Non-designers just don't see things the same way.
If the designer figured out a better way of scaling an image, that he will use EVERY TIME moving forward, he has just improved himself and/or his trade.
It doesn't make them crazy necessarily, it just makes them not programmers.
In the rare case that it does not lead to a better process or experience AND is not noticed by the end-user AND is not noticed by the employer, then you can argue that it is indeed 'crazy'.
Or you can call it self-satisfaction, pride, etc... :)
The 'scaling problem' and 'aspect ratio problem' are both ancient and well solved - I can't take anyone seriously complaining about iPhone form factors - its just a new problem for them because they are utterly inexperienced and new.
What I find interesting is that the example you give has many more ugly design problems than the minuscule changes from compensating for the scaling. Look at how poorly the text is arranged in the buttons for instance... I also hope the colour banding is an image compression artefact and not in the actual app...
Where you look at the buttons individually, the designer looks at the style. The sum of all the items styled in a certain way.
The real question is not whether designers go too much into details but rather when they should and when they shouldn't.
Achieving pixel perfect design nowadays doesn't mean you have to go insane in the process.
I am not sure if that kind of "eye" can be trained or not, but I know I have it, and that the slightest misalignment or aliasing will jump out at me and I have to fix it (if I can help it).
Retina Design is brand spanking new. You're not going to find it being taught in a university anytime soon.
But this is just trolling man.
"pixel perfection" trumped actual ux improvements.
Try again.
On the other hand, I'm sure designers would say the same complaints about source code optimizations. But I hope we can agree it's about personal satisfaction, and that there's not necessarily anything "crazy" about it, it's just the sort of passion that results in quality.
https://itunes.apple.com/us/app/seatgeek-tickets-concerts/id...