• Blog
  • Sponsors
  • Work
  • About
Menu

Eli Schiff

Street Address
City, State, Zip
Phone Number
Eli Schiff

Your Custom Text Here

Eli Schiff

  • Blog
  • Sponsors
  • Work
  • About

Critical Sharks Part III: Design Fallacies

March 17, 2015 Eli Schiff
It must not be very powerful then.

It must not be very powerful then.

This is the third installment of Humanist Interface: Critical Sharks. If you've missed the rest of the series, be sure to read part one and part two.

In order to fortify their position and divert attention away from criticism, modern minimalist apologists have amassed a whole assortment of baseless arguments for dismissing visual design issues. If you find yourself in a discussion with a modern minimalist who makes any of the following fallacious arguments, you can safely assume they are an obscurantist.

The first fallacious argument the modern minimalist apologist makes is to accuse the critic of being a Luddite. Their assertion is that only backwards users would refuse to upgrade their operating system past a certain point. It is true that upgrading is a requirement, often done only to avoid suffering planned obsolescence. This artificial necessity to perpetually upgrade is thus used to argue that visual design is somehow unimportant. In the eyes of the modern minimalist, if one aims not to be seen as a Luddite, then surely they must adhere, without question, to the latest design dogma that has been uncritically adopted by the industry.

An example of Prof. Dr. Style.

An example of Prof. Dr. Style.

Some modern minimalists go so far as to justify the ugliness of sites that refuse to invest in visual design. Most famously, they have exalted the bare-bones Craigslist as the height of “undesign,” an ideal which they would like to see more of. With this false dichotomy between features and design in hand, these purists would have the entire internet go back to Prof. Dr. Style if they could only have more features.

Appeals to Features

Modern minimalists then conveniently take note of the obvious fact that each subsequent OS release will have new features included. They believe that these features should offset any potential complaints one might have about design.

I could not have put it better myself.

I could not have put it better myself.

This type of appeal to features has been exhibited well in the Android community. Android fans have lauded the new features in Android that came paired with the onset of Android L and Material Design. These features are undoubtedly a step forward for Android. And the OS has received many tangible improvements that bring it closer to iOS in terms of stability and cohesiveness. On the other hand, modern minimalist iOS is hardly the pinnacle of design itself.

Thus the apologist conflates the existence or addition of features with satisfactory design. This is mistaken. The mere existence of features has little or nothing to do with the usability, effectiveness or beauty in a visual design. Features do not make design, design makes features. In and of themselves, the features are mere functionality: inaccessible and useless. Design exposes and communicates how a feature is presented and experienced by the user. Both are interrelated, but hardly the same thing.

Appeals to Improvements

Material Design rests on much the same core philosophy as Holo.

Material Design rests on much the same core philosophy as Holo.

We may all be in favor of improvements in features, even in improvements in design. Of course we must first be certain that what we have received are indeed improvements. But neither type of improvement gets at the heart of the matter. If we are to examine features or design, we need to discuss their underlying premises, not only how they changed between OS releases.

The fact that the latest design language for Android, Material Design, is in some ways an improvement to Google’s previous design language “Holo” does nothing to validate the core design philosophy shared by both versions. For us, the crucial aim should be the determination of what bases and what ends these features and designs are being implemented.

Appeals to Deadlines

It should by now be clear that software design must be judged on the design implementation of features, not on the mere existence of functionality. It is not as if this is zero-sum and features must suffer in order to allow for a better thought-out visual design.

The exception to this rule only occurs when one is working under time-pressure at the scale of an operating system redesign. Apple experienced exactly that zero-sum tradeoff between features and design as they struggled to get iOS 7 out the door on a tight deadline. Of course everything involved in that calculus was completely unnecessary and self-imposed: the arbitrary deadline, the redesign, and ultimately the tradeoffs.

Developer Ashley Nelson-Hornstein, an Apple and Circa alumnus now at Dropbox, explained, “I forgave iOS 7 because I understood the incredible amount of work accomplished to pivot the platform in just six months.”

This is a complete non-sequitur. It should not matter the timeline given for such a redesign. And forgiveness is not necessary. One need only ask if the redesign was called for to begin with.

It is an all too common excuse to claim that since it is an immense task to get software shipped, therefore we should take tight deadlines into account in a critique. If anything, this is why we need more criticism, in order to hold leadership to account should they put designers and developers to work on misguided paths.

Appeals to Omniscience

At Google I/O Alex Faaborg, Staff Designer for Android, made sure to impress on his fellow employees how much “smarter than most people” they are.

At Google I/O Alex Faaborg, Staff Designer for Android, made sure to impress on his fellow employees how much “smarter than most people” they are.

There is no shortage of reminders for employees of major corporations of their superior intellect. We hear continual rebukes to criticism telling us ‘up there, they know what they’re doing.’ As described previously, Tim Shundo of Circa exhibited this well when he said “I’m not gonna stand here and let you say that Apple’s hundreds of engineers are idiots.” The person with whom Shundo was arguing had not even insinuated that Apple engineers were idiots.

Shundo’s former co-worker, Ashley Nelson-Hornstein, is similarly skeptical that anyone at Apple could make a mistake. She believes that “a ton of smart people work at the mothership” and “thus far I haven’t seen evidence to the contrary.”

Continuing on, Nelson-Hornstein excuses the actions of her former employer, Apple: “I’m betting these incredibly intelligent people have already noticed the problem and moved to make the proper adjustments.” It escapes her that smart people are perfectly capable of making and doubling down on bad decisions.

Nelson-Hornstein offers a measured take on the situation: “Personally, I won’t be jumping to hyperbolic sentiments or joining in on the sense of foreboding doom wafting through the public discourse.” Strangely enough, the people doing the most service to the narrative of Apple’s impending “doom” are Apple apologists themselves.

Appeals to Collegiality

Former Art Director at the White House, Michael Aleo, wrote an article pointing out lackluster criticism coming from several FastCo journalists. Some of the design trends FastCo mocked included flat design, Google’s Material Design, minimalist posters and Helvetica, among a smattering of other design buzzwords like parallax, artisanal design, delightful design, the Nike swoosh, infographics and the Eames Lounge Chair.

Aleo explained that FastCo is “trying to be funny like the big bully beating up the scrawny kid is trying to be funny.” At least for me, it is somewhat hard to imagine a world in which Google or Nike would be best described as ‘scrawny kids being bullied.’

The argument that Aleo makes is that if designers work hard, that means their designs are off-limits for discussion. Reminiscent of Jason Santa Maria, Aleo expresses his disdain for:

writers publicly attacking and making fun of the work of designers…here’s the thing: all of these things are someone’s work. Someone worked their asses off on most of this stuff.

Aleo proposes a different kind of journalism, one expressly opposed to any tough criticism: “we should be building each other up, promoting the industry as a whole, spreading design further, and pushing our peers. Anything but this.”

It should surprise no one that Google’s Matias Duarte was the first to endorse Aleo’s article, given that his flat Material Design was a target of one of FastCo’s critiques.

Another among those endorsing the call to put a stop to FastCo’s critical writing was cofounder of Mule Design, Erika Hall. Her support is hardly coincidental considering the writing of her cofounder, Mike Monteiro.

Support for the article has been widespread: Adobe Typekit’s Creative Director, Elliot Jay Stocks, expressed his agreement with Aleo. As did RIT professor and notable owner of designcrit.com, Mitch Goldstein. Goldstein’s advice: “Design process: Do not read @FastCoDesign anymore.”

When I questioned Aleo on his article, explaining that criticism has an important place in the design industry, he responded circularly, “Totally agree. Constructive criticism is critical." So it turns out that Aleo is in favor of criticism, but only on the condition that it fits his definition of "constructive." This is very reminiscent of the sentiment philosopher Kenan Malik highlighted in his critiques of those who claim to 'believe in free speech. But…'

All the fuss around weak criticism from FastCo is misplaced. Those who would silence criticism should be plenty satisfied with design reporting today. It already has the promotional vacuity that they so desire.

For my part, I believe we should allow the lousy criticism we find in those few recent FastCo articles. Instead of taking this as an opportunity to prevent criticism, we should encourage in-depth criticism. Even if it might call in to question work that happens to be done by our peers.

Appeals to Bugs

Jony Ive’s iOS 7 was introduced with many visual bugs that left a sour taste in the mouths of those expecting fit and finish from Apple. iOS 8 still contains many visual design bugs. In this example, bookmarks in Safari inexplicably overlap with each other.

Jony Ive’s iOS 7 was introduced with many visual bugs that left a sour taste in the mouths of those expecting fit and finish from Apple. iOS 8 still contains many visual design bugs. In this example, bookmarks in Safari inexplicably overlap with each other.

When it is determined beyond a reasonable doubt that there are serious flaws in their design languages, modern minimalist apologists have nowhere to turn but to fallaciously appeal to bugs. They claim that the badly designed operating system must have been a big mistake, a bug that can be easily fixed. But that it is you, the user, who must cease with your criticism and do your part.

When Michael Heilemann, the Interface Director of Squarespace, politely pointed out several areas for improvement in iOS 7, his detractors dismissed him and declared the issues he criticized to be mere bugs due to the build being only in Beta 1. Heilemann argued of the beta that yes, "it might change. But how did it make it this far? He continued:

You could chalk it up to experimentation, as some do, but it's like experimenting with triangular tires. We know it doesn't work, there's no need for us to repeat that particular experiment.

Heilemann was not against reporting bugs per se, but rather felt that there were significant changes that went beyond mere bugs that practitioners needed to grapple with. Nevertheless, his detractors felt that instead of it being Apple's responsibility to fix the so-called bugs, it was Heinemann's personal duty to submit bug reports to mend the situation.

Iconfactory developer Craig Hockenberry took this self-professed “duty” to new heights in an open letter to Apple CEO Tim Cook, entitled “Death by a thousand cuts.” He explained how “guilty” he feels when he forgets to submit a bug report, because “Apple may not be aware of the scope of these issues because many of these annoyances go unreported.”

So guilty did Hockenberry feel about this matter that he spent “two days of his productivity,” without pay, filing bug reports. He went so far as to expend energy building custom software to lessen the friction required to file bug reports. In his words, “My obsession knows no bounds” and that “Lately, it feels like I’m making a career out of submitting issues for Radar.” Hockenberry implored his readership to do the same, “I’ll keep harping on my 20K+ Twitter followers to do their duty. These problems won’t fix themselves.” Many have followed in his footsteps.

The situation could not be more appalling. Apple, a company sitting on a $155 billion war chest, has convinced independent developers that it is their own fault that Apple’s operating systems are unstable. Not only that, but indie developers are convinced they should spend their billable hours working unpaid to spot errors that were missed by a QA department at Apple that seems to be on vacation.

Still, Apple’s lack of action should not be surprising. With unpaid laborers like Hockenberry and his cohort at their disposal, Apple has no reason to invest in building better tools—even if they are tools directly tied to improving the performance of Apple’s own software. Why pay for those tools when indies will make them for free?

So bad is the state of affairs that iOS developer Nick Lockwood said that today “3rd party iOS app developers generally have higher standards than Apple when it comes to quality control.” If industry designers, developers and journalists accept this type of negligence on the part of operating system makers, it is no wonder that other companies take them up on the opportunity.

The obscurantism inherent to an appeal to bugs is easily refuted when one looks at the gestalt that makes up an operating system’s design. One error may be a bug. But thousands? That is when you have a flawed software design philosophy. We are at a point beyond which one can say without question that the dominant modern minimalist school of design is fundamentally destructive.

Once one adopts modern minimalist principles, lapses in software quality, specifically in visual design, are virtually guaranteed. This is a necessity, because visual design is no longer a priority. It is predictable that we see more bugs today.

It is today often impossible to distinguish bugs from the myopic design ideology from which they emerged. Some argue that the abundance of bugs in software today cannot be blamed on poor design philosophy. They believe that bugs were the result of developers being rushed, and that this has nothing to do with design. Here is where I disagree. It is true that there are bugs that are the result of incorrect implementation. But that does not preclude there also being bugs that originate in design ideology. What is worrying is that there is an abundance of both types of flawed design in modern operating systems where there weren’t before.

Some are hopeful that these implementation bugs will be squared away. I remain skeptical. It is clear that Apple’s deadlines were driven by a new management regime. Design leaders who were clearly willing to accept a mess of implementation bugs if it meant they would get their modern minimalist stranglehold on operating system design.

Far worse than implementation bugs though are the so-called bugs that are simply bad design choices. Choices implemented perfectly accurately by developers. Designs where flatness is embraced over coherence, stability or legibility. Apple users have nowhere to run from ideologically hampered designs, because the same philosophies have been adopted and implemented at Google and Microsoft too.

Yosemite’s volume indicator corner rendering error.

Yosemite’s volume indicator corner rendering error.

Consider one bug wherein the volume indicator in OS X Yosemite incorrectly renders its corners. Several months after the release of the OS, the bug was fixed to much fanfare. iOS developer Dan Wineman exclaimed, “Best news you’ll hear all week: OS X 10.10.2 draws the volume overlay correctly.” That a bug-fix like this causes such an uproar illustrates how depressingly low developers’ expectations are of Apple when it comes to design.

If there truly were one thousand no’s at Apple for every yes, then iOS 7 would not exist. (The irony of this short commercial, entitled “Designed by Apple” is that it wasn’t even designed by Apple. It was outsourced to an external animation agency.

If there truly were one thousand no’s at Apple for every yes, then iOS 7 would not exist. (The irony of this short commercial, entitled “Designed by Apple” is that it wasn’t even designed by Apple. It was outsourced to an external animation agency.

It is interesting to consider the latest backlashes at Apple by iOS developers, whose pent up frustration is now bubbling to the surface. Today, features themselves are suffering, rousing the ire of formerly satisfied developers—those who have proven not to care for visual design. In fact, many Apple journalists and developers are now uncharacteristically criticizing Apple for their fast release cycle and the abundance of bugs that are released on their platforms, many of which are directly related to visual design.

Federico Viticci of MacStories put forward his position “Despite its problems, I’d take iOS 8 over an improved version of iOS 7 with no new features any day.” Indeed, for developers and hard-core Apple fans, features are the name of the game.

What journalists like Viticci ignore is that the very bugs they experience today emerged due to developers being forced to spend an incredible amount of time and money accommodating Apple’s arbitrary aesthetic shift. If developers and journalists so value features over design, then back in 2013 those like Viticci would have argued their preference for an iOS 6 with feature improvements over a visual downgrade to iOS 7. Few, if any at all, did.

Apple apologists conveniently ignore that there is a clear connection between the massive visual overhaul of both iOS 7 and Yosemite and the bugs we find in those operating systems today. The very “herculean” effort that brought about the flat redesign of iOS 7 meant fewer engineers focused on quashing bugs and adding features, the very thing fanatics claim to value.

Yet Apple journalists like Rene Ritchie of iMore still celebrated the modern minimalist shift. Ritchie exclaimed: “Jony Ive lending his considerable talents to software design is glee-inducing.”

It is quite possible that neither features nor design are ultimately important to tech writers and developers. What instead may be their highest priority is being invited to the next Apple Keynote. How else then to stream to fans over Meerkat about how “bullish” they are about Apple. How else to take a selfie with Apple execs?

Hesitation and Backtracking

In criticizing the choice to use a thin variant of Helvetica Neue in iOS 7, Stephen Coles of Typographica said "I fear this decision was made with fashion, not usability, as the main priority. Yet, when pushed on the subject, he backtracked and apologized:

Update: I’m painfully aware that this answer is as shallow as the surface-level iOS7 typography that it mocks. The new font technology behind the visual choices is more interesting and probably more important in the long term.

The problem with this self-censoring is that Coles’ appeal to features and technology has nothing to do with his original criticism and does nothing to invalidate it.

Also discussing the typography of iOS 7, Khoi Vinh of Subtraction argued that iOS is “simpler, less cluttered, and decidedly flatter…It’s also more like the cosmetics counter at your local department store than ever before.” Yet he too felt the need to hedge:

To be fair, these uses of Helvetica Neue’s thin and ultra light weights are not necessarily indictments of the design strategies that Apple and Google are pursuing…it’s still too early to fully pass judgment.

Why is it too early? When will enough time have elapsed? Why does Vinh need permission to make critical judgements? And who will be the arbiter that permits such heresy?

It is worth noting that so many in the industry feel it necessary to defend predictably bad decisions made by the most-informed design leaders. If the designers at Apple, Google and Microsoft are indeed “only human,” then they should not be beyond reproach and criticism. In a healthy design industry, criticism of bad ideas would be welcomed alongside praise of good ideas. After all, criticism helps anyone open to it grow and evolve.

Take a look at the fourth and final installment of Humanist Interface: Critical Sharks, Fear of Apple.

← Critical Sharks Part IV: Fear of AppleCritical Sharks Part II: Schmearing Colored Paint →
Featured
Jan 5, 2016 Eli Schiff Comment
Jan 5, 2016 Eli Schiff Comment
Unofficial Apple Icon Design Awards
Jan 5, 2016 Eli Schiff Comment
Jan 5, 2016 Eli Schiff Comment
Jan 5, 2016 Eli Schiff Comment
Jan 5, 2016 Eli Schiff Comment
Dec 15, 2015 Eli Schiff Comment
Dec 15, 2015 Eli Schiff Comment
Mel Brooks: The Anticritic
Dec 15, 2015 Eli Schiff Comment
Dec 15, 2015 Eli Schiff Comment
Dec 15, 2015 Eli Schiff Comment
Dec 15, 2015 Eli Schiff Comment
Dec 9, 2015 Eli Schiff
Dec 9, 2015 Eli Schiff
Implausible Hypothetical Eastern European App
Dec 9, 2015 Eli Schiff
Dec 9, 2015 Eli Schiff
Dec 9, 2015 Eli Schiff
Dec 9, 2015 Eli Schiff
Nov 17, 2015 Eli Schiff Comment
Nov 17, 2015 Eli Schiff Comment
Fire 'em!
Nov 17, 2015 Eli Schiff Comment
Nov 17, 2015 Eli Schiff Comment
Nov 17, 2015 Eli Schiff Comment
Nov 17, 2015 Eli Schiff Comment
Oct 20, 2015 Eli Schiff Comment
Oct 20, 2015 Eli Schiff Comment
Mel Brooks: The Critic
Oct 20, 2015 Eli Schiff Comment
Oct 20, 2015 Eli Schiff Comment
Oct 20, 2015 Eli Schiff Comment
Oct 20, 2015 Eli Schiff Comment
Sep 27, 2015 Eli Schiff Comment
Sep 27, 2015 Eli Schiff Comment
Keyboard Smörgåsbord
Sep 27, 2015 Eli Schiff Comment
Sep 27, 2015 Eli Schiff Comment
Sep 27, 2015 Eli Schiff Comment
Sep 27, 2015 Eli Schiff Comment
Sep 16, 2015 Eli Schiff Comment
Sep 16, 2015 Eli Schiff Comment
Interview: James Gill of GoSquared
Sep 16, 2015 Eli Schiff Comment
Sep 16, 2015 Eli Schiff Comment
Sep 16, 2015 Eli Schiff Comment
Sep 16, 2015 Eli Schiff Comment
Sep 3, 2015 Eli Schiff Comment
Sep 3, 2015 Eli Schiff Comment
Featured Offscreen
Sep 3, 2015 Eli Schiff Comment
Sep 3, 2015 Eli Schiff Comment
Sep 3, 2015 Eli Schiff Comment
Sep 3, 2015 Eli Schiff Comment
Aug 11, 2015 Eli Schiff Comment
Aug 11, 2015 Eli Schiff Comment
Forecast: Tweetstorm
Aug 11, 2015 Eli Schiff Comment
Aug 11, 2015 Eli Schiff Comment
Aug 11, 2015 Eli Schiff Comment
Aug 11, 2015 Eli Schiff Comment
Aug 4, 2015 Eli Schiff Comment
Aug 4, 2015 Eli Schiff Comment
Crafting Icons
Aug 4, 2015 Eli Schiff Comment
Aug 4, 2015 Eli Schiff Comment
Aug 4, 2015 Eli Schiff Comment
Aug 4, 2015 Eli Schiff Comment

Humanist Interface Newsletter

Do you want to learn about the art and history of interface design? Sign up to be the first to know as updates are posted on the Humanist Interface blog.

Subscribers will receive a primer collection of critical design articles and a free Sketch cursor icon resource.

 

Sign Up Free
 

Support Humanist Interface

 

Buy me a coffee and help me stay awake to write more articles for the blog.