There’s a classic principle in design, which is that you should go broad before you go deep. The idea is that unless you intentionally go outside the boundaries of what is known, you’ll be leaving a ton of solutions on the table, many of which could be superior to the one that’s right in front of you. The idea is that unless we explore the unknown, we’ll always end up back where we started.
Going broad is essentially an undirected design exploration. We are intentionally designing outside of what is immediately realistic, and we are intentionally disregarding perceived blockers.
In recent conversations with friends, it became clear that this is something many designers struggle with. Either they had a hard time looking past what they knew to be existing technical limitations of a project, or they simply felt uncomfortable looking too far ahead given any number of immediate challenges, whether they be deadlines or specific problems to solve. Having worked in the field of design for almost two decades now, I felt that I could potentially share some personal learnings, in case they might be helpful to others who struggle with “giving themselves permission” to do undirected design explorations.
Because I’m a Star Wars fan, you can always count on me to find a way to bring it into a Star Wars context. In this case, I’d like to steer your minds toward the tale of how Han Solo — scoundrel, smuggler, and captain of the Millenium Falcon — managed to complete the Kessel run in less than 12 parsecs.
But surely you know that a parsec is a unit of distance, not time? Surely Han was just just bad at physics and was trying to impress would-be passengers to pay more? Come now.
Yes, that may still be the case, it certainly would be in his character to do so. But the reason Han was able to actually complete the Kessel run in less than 12 parsecs (11.5 to be precise, citation needed), was that he took a shorter, more dangerous route to Kessel. Han succeeded because he disregarded the dangers of veering off the path, by then going outside that beaten path, and ultimately he did so by having faith that it might work.
Serendipitously, this maps well to the craft of design. Let’s extract from Han’s heuristics three principles of undirected design explorations.
1: You’ll Live
The first step is to accept that you won’t encounter literal space dragons as you explore. The very worst thing that can happen as a result of you giving yourself permission to explore, is that you’ll end up in a dead end (or in Han’s case, a black hole).
But even then, you have to trust that this dead end has intrinsic value. Something led you to take that path, and you followed it to the end. Maybe you found out it didn’t work, but now you can relax in actually knowing that. You have cauterized that idea (just like how a lightsaber cauterizes wounds as of the 1997 special editions). You can let that idea go, knowing it’s been explored to its depths, and you can proceed to explore other ideas.
2: Go Outside The Beaten Path
You won’t know whether something is possible, or whether an idea is viable, until you actually try it. If you give yourself permission to pretend anything is possible, it opens up avenues to explore that you otherwise wouldn’t have considered.
Trust that there is a solution to any challenge. Imagine it being out there, shrouded in fog, and that the only way to find the path forward is by exploring in any direction. If you keep exploring long enough, eventually the fog will lift and the best path forward will present itself, clear as day.
That path might not contain answers to your immediate challenge at hand, but maybe it will instead suggest where you’d like to be down the road. Consider that a vision of where you want to be, then work to create steps on a roadmap to get there. In shaping each step of the way you can get closer to that vision, and you’ll eventually end up in a nice place.
On the other hand, if your process is driven only by a near-future desired outcome, you’ll only end up in a place you’ve already been.
3: Have Faith
The path to Kessel is 18 parsecs, mapped in such a way as to avoid a string of deadly black holes. Suggesting it can be finished in less than 12 is a little crazy. The only way anyone would ever actually do such a crazy thing, would be to have faith that it could be done in the first place.
For the craft of design, it’s okay to believe a particular approach or idea is crazy and impossible, so long as you still give yourself permission to explore it. It can be really hard to give yourself that permission, as the more you know about a task, the harder it can be to disregard boundaries you know are present. You have to have faith that giving yourself this permission will benefit you long term. You have to believe that if you don’t do this, you will block off ideas from even entering your radar.
If it helps, pretend your explorations are “what if’s” — pretend they are strawman examples that you know won’t work. Allow yourself to explore them regardless, just to understand how they don’t work, or how badly they would work. As mentioned, you might end up in a dead end, but you’ll still be smarter for it. Or, you might be surprised to find a happy accident: maybe that crazy idea of yours just might work. Or maybe a variation of it could!
If you’re on a deadline, it can be tempting to take the path of least resistance and skip the “go broad” step. You might feel like an undirected design exploration is a luxury you simply can’t afford. In that case, maybe try and time-box the explorations. Keep them as low fidelity as you like: use crayons! You can even keep it text-only, and write a stream of consciousness of sorts — a rapid-fire series of ideas and how they would be supposed to function.
But do it regardless. If you jump immediately on the idea that seems the most actionable right now, you’re arguably wasting time in the long run. At best, you’ll end up making only slight iterative improvements. At worst, you’ll end up fortifying a fundamentally flawed approach, just making it that much harder to eventually get to a good place.
We can boil it down to the following:
Trust that the process is more important than the immediate outcome. Allow yourself to think ahead (way ahead) and consider the long-term vision. It’s always easier to pull back to reality once your exploration process is done.
Divide that vision up into steps on a roadmap. Define each step as the minimum amount of work that gets you closer to the vision while still providing an iterative improvement. By being steps towards something greater, you’ll ultimately end up with something compelling.
Have faith that your aimless design explorations have intrinsic value. Even when they fail, the failure is informative, and it’s a delighfully cheap way to fail if you do it at the start.
Once you trust in the value of this process, it becomes easier to make the elbowroom that is necessary to cultivate new ideas. And as with all things in life, the more you do it, the easier it becomes.
Last week I cancelled my membership and today I joined instead the World Wildlife Fund. I don’t see myself coming back to UNICEF, and given the history my family has with this organization, this fact is crushing to me.
The reason I quit is that a few weeks ago, UNICEF launched The Hopepage, which mines cryptocurrency using your computer power. While this might seem smart on the face of it, in a world where climate change threatens everyone (and especially those UNICEF aims to aid), spending electricity looking for imaginary coins is the last thing we need. I find it to be a collossal lapse in judgement on part of UNICEF, and I cannot fathom how this project got past the idea stage. But because it did, I can’t trust the organization anymore. It may “only” be the Australian division that started this, but the reason I supported UNICEF in the first place was exactly that it was a global organization, one that had the reach and potential to effect real change.
Perhaps even worse is that by resorting to crypto mining, UNICEF is tying the practice of mining crypto-coin to a good cause. But it is not a good cause, it is an irresponsible use of power that the globe cannot afford, not now, not ever.
Sure, the blockchain has potential, and proof of stake based currencies sound like they could be promising. But so long as mining crypto costs the equivalent energy usage of a medium sized country, such computer power should be spent curing cancer, doing something real.
WWF fights climate change to protect nature, wildlife and the ecosystem necessary to sustain them, and incidentally us. As of now, they have my support.
WordPress is set to receive a brand new editor, some time this year with WordPress 5.0. Along with this new editor are some new features that themes can opt into. This post will cover what those new features are.
If you only ever read one thing about Gutenberg and themes, though, know this: there is no "Gutenberg theme", and as a theme builder, there's nothing you have to do, to be compatible with the new editor.
As with all things, there may be more features you can opt into in the future. But the editor that will ship with WordPress 5.0 will not require you to make any changes.
While you don't have to do this, you can opt into supporting wide images. Gutenberg specifically supports two new image sizes: wide, and fullwide. Here's a fullwide image:
You can use these alignments on nearly all blocks. Here's the wide alignment applied to a gallery:
When a theme supports wide alignments, blocks get access to two new alignments on the toolbar:
The two last buttons are wide and fullwide respectively. The way your WordPress theme opts into these two alignments, is to paste the following snippet into your functions.php:
add_theme_support( 'align-wide' );
Adding that will make the two new alignment buttons show up, and it will add .alignwide and .alignfull to blocks which have been given these alignments.
The next step to take is to ensure that we have the necessary CSS in place to handle these new classes. The reason you have to opt-in to these alignments, is because the code to do that is slightly more complex than what you need to simply float an image left or right.
What this code does is say every immediate child of the .site-content, except elements with classnames .alignwide or .alignfull, should have a max-width and be centered horizontally. This essentially lets us specify max-widths of 100% for fullwide (use ALL the screen!) or 75% for wide images. You could also specify pixel-widths here.
But what about floats?
The usual way to float an image is this:
Simple. But in a layout with an unconstrained main column, this float would burst out of the main column, and place itself snugly to the extreme left of the viewport. Not what we want. What we want is for it to float alongside the left margin as defined by the main-column max-width we defined previously.
But images in Gutenberg come with extra markup we can leverage. Here's the markup:
The figure here is the same width as the main column, because it was not excluded from the max-width we applied earlier. That means this element is both centered, and has the same margins as the adjecent text. Which means we can just float the image inside this element:
Subtle change, but an important one. We're simply floating the image inside the constrained and centered container. This makes the figure element collapse into a zero-height element, and lets subsequent text float around the image. Just like how we want it.
There are many other ways to support wide images in Gutenberg, but it's important to remember that you don't have to support these alignments, and if you don't do anything, the buttons won't show up in the editor. Hope you'll enjoy using wide images! By the way, this website is now using a theme that supports wide images out of the box, and you can snatch it on Github.
Update, February 24th: The Codepen examples linked in this post have been tweaked slightly, and captions have been added to floated images.
Back in the day, I designed Flash websites. I was pretty good at it too, and it netted me a job as a Flash animator and designer at a small Copenhagen based studio. We made really cool things, some of them are probably still around.
As time went on, though, the shortcomings of Flash became painfully obvious. It was not born with any accessibility to speak of, it didn’t print well, and it wasn’t going to make the transition to mobile. Perhaps worst of all, it was hard to build complex projects in the tool. It felt like there was a ceiling to what you could achieve with Flash, and we were bumping into it all the time, without a way to significantly elevate it. As with many nascent technologies, the writing was on the wall for Flash.
A fair bit before we reached the end of the road for Flash, though, I had decided to look for opportunities elsewhere. I started with Movable Type, but the difficult setup, combined with a serendipitiously timed and delightful post by Mark Pilgrim, I quickly made the move to WordPress. Version 1.2 had just been released at the time.
WordPress was easy to install — the “famous 5 minute install” was not hyperbole. It was easy to hack on the themes it came bundled with; PHP was forgiving, and you could quickly get something up and running with a little copy/pasting. HTML and CSS was the same — just hit View > Source, and you could look at the skeleton of a website. Most importantly, documentation was easy to uncover. Back then most of what you’d find lived in the forums. Even so, for almost anything you wanted to do, there was a code snippet. With WordPress and PHP, there didn’t appear to be any type of website you could not build. This remains true today.
It feels like we are approaching a crossroads, though. There may not be a fixed ceiling to what PHP, HTML, and CSS can achieve together in the same way as Flash had, but the returns on development feel diminishing. The emergence of mobile as the key point of interaction and consumption especially, seems like it demands interactivity and performance that is not easy to achieve through traditional means. By virtue of being open source and built on web standards, WordPress can never share the fate that Flash did. But it feels like there’s an opportunity to turn the crossroads into an inflection point.
Modern web-apps, including progressive web-apps — webpages that behave as native mobile apps — depict a future where pages don’t reload for every click you make; where interactions can be fluid instead of abrupt. Notably, interactions can be fast.
The benefits of modernizing the foundation of WordPress feel obvious to me. But there’s a cost attached: we all have to learn something new, and new documentation has to be written. That’s a high price to ask, for a tool that millions use. Speed, potential, and fluid interactions, are insuffient answers to the legitimate question: “Why?”
There is also another, much more meaningful, answer.
The answer is that it’s not about me. If you’re reading this, there’s a good chance it’s probably not about you either. It’s about the next generation. It’s about kids growing up today. It’s about not only ensuring that WordPress remains a relevant tool for the kids learning to code today, but about honoring our responsibility to make sure these kids learn something really valuable.
In the face of robots, AI, machine learning and automation, it seems like learn something difficult is increasingly good advice for the next generation. By sticking with the old I deeply personally feel like we are doing a disservice both to WordPress, and to the kids learning it. In fact it feels like we have a responsibility to build for our kids rather than for ourselves.
By moving forward, even though it’s uncomfortable, we are being inclusive of what’s to come. Yes, it means many of us will have to learn something new, but we’ll be embracing the next generation of the web, and teaching kids how to get there. All the while, we’ll be drastically elevating what’s possible in WordPress. If we believe in this future, our job then becomes to start this process as soon as we can, write documentation and tutorials, and provide good migration paths.
The desktop computer used to be the hub of your digital life. Then the smartphone joined the family. The tablet was supposed to fit in between those two, and the smartwatch was your phone companion. In the end, the phone became the new digital hub; your most personal form factor.
The smartwatch seemed poised to take over that role, with a new ultra-portable form factor, and a promise to untether you. And it has indeed turned out to be great, for some, but is completely irrelevant for others, and even at its best, it did not succeed in replacing the smartphone as the single device you take with you. In fact the whole family of device categories seems to have stabilized in recent years: the tablet is great for some, the tiny laptop is great for some, the big laptop is great for some, and the giant high-end PC — the “truck” — is great. For some.
Remaining at the center of it all, though, there’s your smartphone. With increasingly mature operating systems, it can increasingly do more things for you. It’s not too difficult to make an argument that most people could cut out every other form factor, keep only their smartphone, and still get by perfectly fine. Some do already, I’m sure, which is a factor that no doubt will help inform the next category of personal devices.
There’s probably always going to be room for multiple form factors and screen sizes, one for each specialized use case. In between all of these, however, there’s likely to still be a single hub device. Is it a future watch? Is it a pocket sized rectangular slate with cell capabilities? Let’s speculate, because that’s what this blog does.
A New Category
Most successful hardware categories seem to share a few traits:
They solve specific problems
They are easy to interact with
From a technology point of view, the only constant has been miniaturisation, resulting in increasing amounts of power being available at increasingly lower costs. The biggest barrier to physical device miniaturisation however, perhaps more-so than battery concerns, has been an interaction model that just hasn’t kept up.
The smartwatch UI is impressive, but despite valiant attempts, a whole slew of actions are still much better done on your phone. Perhaps one day when rock solid voice input mechanisms, digital assistants, gestures, and other magical science fiction interaction methods reach a combined threshold of quality, the watch might replace your phone, but until such a time, the watch is unlikely to replace the well-tested benefit of a big screen. And so for our most personal device, we’re likely stuck with traditionally proven interaction models like tapping buttons to do actions. Fitt’s law suggests the same: the bigger a button is, the easier it is to tap. (That might sound obvious, but the actual math has been done to prove it too.)
Remember when it was claimed that Apple would never make a phone larger than 4″ because touch targets would be out of reach for single handed use? Yet here we are. Given the current interface limitations, the challenge is propping as much screen into as pocketable a form-factor as possible, while still letting you reach the most important actions with a single hand.
Incidentally, if mobile VR ever takes of, which seems likely, the screen will have to be high resolution, and as scratch-resistant as possible. When you’re looking straight at something that’s an inch from your eye, every speck of dust shows up. As such, it would be really nice if the device doesn’t scratch just by being pocketed.
Big screen, one-hand operation, pocketable, doesn’t scratch? Tall order.
Remember the Nintendo Game & Watch? For its time, it had a pretty big screen (with room for more), was pocketable, and barely scratched.
We’re probably not looking at the next iPhone up there. But we may be looking at the inspiration for Microsoft’s next attempt at a phone. With zero marketshare to speak of, Microsoft is desperate to either invent a new category they can own, or just stand out as unique. They might not succeed in doing so, but they might well try. In a way, they already tried it once, with the Microsoft Courier, and arguably got a few things right, way before its time.
The foldable form factor solves a number of problems that are increasingly becoming evident: $800+ pocket devices that go splat when you drop them are arguably fundamentally flawed in their design. Since transparent aluminium hasn’t been invented yet, it’s probably time someone started experimenting with form factors that are just slightly more durable than a sheet of thin glass. In fact, Lenovo has already gone down this path in a tablet form factor.
Maybe the next category of devices isn’t foldable. Maybe it’s bendable. Maybe it slides or transforms. Maybe there are three screens, of which two are hidden when the clamshell is closed. Maybe we’re just looking at a magnetised keyboard case.
Whatever it might be, such a new device is probably going to need new interaction models that can scale to multiple screens. What might one-handed operation look like on a dual-screen folded device — will the interface adapt and place important interaction only on the one screen? Only near the bottom? What happens to the UI when you rotate the device? Would you want a pen?
6″ is too big a phone for most. Surely no-one in their right mind would want a 7″ phone, right? It just so happens that if you put two 5″ phones next to each other, the combined screen would be about 6.4″. It would be close to a square in its aspect ratio, somewhat like a book:
Would it work? Impossible to tell, and it would depend on a beautiful combination of hardware and software. Like the good old 1982 Donkey Kong Game & Watch.
“There’s an app for that” was a popular phrase thrown around a few years ago. The phrase optimistically noted that in this technological era, whatever task was at hand, you could probably find an app on your pocket-carried supercomputer that would help you right out.
What the phrase did not include was the notion that in order to get said app, you had to open the app store, search, pick the right one, possibly pay 99¢, type in your app store password, wait for it to download, open the app, grant permissions to contacts, location or whatever else the app might want until finally you could use the app. Unless you had to register and/or sign in to use it, possibly add a credit card.
Apps were revolutionary for their time, no doubt. But in a world where cars drive themselves and pizzas are best ordered from your watch, some of the qualities of apps as we know them are starting to seem a bit menial. The numbers seem to suggest this as well, as apparently half of U.S. smartphone users download zero apps per month.
At its most atomic scale, an “app” is a little window on your phone that does things your operating system might not do on its own. When the iPhone was first introduced, the phone dialer was presented as “just another app”. It was no different, it was suggested, than any other apps you’d install, and every app added new features to your phone.
But what about replacing features? What about augmenting features? Sure, WhatsApp can create a dialer app that lets you call using their service instead of the cell network. But they’ll lose out on all kinds of systems integration into the OS: what if someone calls you, can you answer with WhatsApp?
It varies from platform to platform the amount of integration apps are allowed to do. While iOS is mostly closed down, you can still replace the keyboard. Android allows you to replace many aspects such as the browser, and yes, the dialer as well. But even then Android is still very much Google’s platform, and there are key aspects of the operating system that are still off-limits.
Apps of today are also very much hardware specific. Android apps look and behave a specific way and iOS apps look and behave a specific way. Some apps are cross-platform, available on both. This has worked fine for a world where people carry a smartphone in their pockets, but what happens when we stop doing that?
In order to speculate what the app of the future might look like, let’s summarize some of the challenges posed by the current interface:
Finding and installing apps is cumbersome
Having to manage your identity and sign into every app is a pain
Having to remember or save passwords for every service is dangerous
Trusting an app with your credit card information is both cumbersome and risky
Generally, closed platforms are advantageous mostly for the platform vendors
Future hardware categories are likely to demand drastically different or adaptive apps
If you’re Apple or Google, it might sounds like #5 — being the platform vendor — is a good place to be, and so it might dampen any initiatives to make new touch points that’ll fully open the home turf to competing apps. But there’s an argument to be made that they will have to, or be left behind.
Enter Facebook. Most of the world is on it. They have your name, address, credit card, contacts, and probably photos. Facebook is you; it’s your identity, and you can use it to sign in, pay and communicate. Facebook is a metaplatform. So is Amazon, and so is Microsoft. Neither of these three have a mobile hardware play to speak of, but they have services and ecosystems you wouldn’t want to be without. To a certain extent, so do Google and Apple, but it’s a competitive space and Facebook arguably has the upper hand on the identity aspect, while Amazon has for the payment aspect. And so in five years maybe it doesn’t matter how good Apple Pay is if you can’t get your “Prime discount” when using it, and it doesn’t matter how good Google Duo is if none of your friends are using it.
People use Facebook. People use Amazon. People use them even if they have to use a browser to do so, and their webpages run well. More so, the secret sauce that makes them run well — React, AWS etc. — is available to anyone. To an extent it doesn’t matter which platform these run on — all they need is a browser. In five years time, will you care whether that browser runs on Android or iOS?
Apple and Google obviously care, and the thing they need to do in order for their platforms to be relevant in the metaplatform future, is open up. The platform that opens up the most integration touch points in their operating system will be able to provide the better user experience for your metaplatform of choice. People might choose Android simply because Facebook runs better on it.
In a future where apps run anywhere, the underlying platform becomes a checkbox. We’re already seeing the baby steps towards this with React Native, and progressive web apps.
So what might the app of the future look like? Perhaps a better question to ask is: how would the app of the future work?
A few problems need to be solved. Instead of installing a separate app for every airline you fly with, and only when you fly, then perhaps the website should be allowed to perform as well as were it actually native. If you fly that airline a lot — pin it — it’s now “installed”. Unpinning it uninstalls it. Identity wise, you are signed into your operating system with whatever cloud account you prefer. This cloud maintains your passwords and your credit cards. Through biometric authentication, apps can tap into this information when you allow it. No signups, no cumbersome passwords to remember.
Increasingly, apps won’t install themselves as icons in a grid, but instead hook into touch points in the operating system and become actions for intents provided. It’s long been the case that the best apps are the ones that focus exclusively on solving very specific problems and tackling specific use cases. The ultimate refinement of this is the complete reduction into taking action based on a user intent.
In comparison, the apps of today are very linear in their flow. You pick an app, pick an intent, complete your task:
When the intent of an app becomes available before the app itself is even launched, suddenly the flow to completing tasks can be highly streamlined:
Instead of hunting for icons, perhaps your homescreen will simply list intents contextual to location, time of day, and habits.
Intents also enable interoperability between apps. Some intents are present already today — on Android, the “share” intent lets you transport content from one place to another. Imagine every app as an intent-based action — the plug-in platform, where apps add, replace or augment any intent you might have. Call someone, text someone, take a note are all existing intents that apps can handle the actions for on Android. But who’s your digital assistant, and can it place a WhatsApp call when you ask it to?
The process will be gradual, but it’s likely to kill off most apps that aren’t able to transition to being simply actions. There’s going to be room for the occasional “pinned app” for use cases to which there aren’t universal handlers, or for apps that create new intents (“I want to tweet”), but those are likely to be exceptions.
When metaplatforms provide all the infrastructure and apps merely tap into them, will this make for a more closed web? That remains to be seen — could be that it becomes more open, as web-apps increase in what they can do and where they run. But one thing’s for sure — you’ll spend spend less time hunting and pecking between icons in a grid, as menial tasks are being handled by intents and actions. In fact we might finally be able to go to a dinner with friends without everyone putting their smartphones next to their plates. In this golden future, maybe that Swarm check-in is handled by your digital assistant.
The best user interface is invisible, and in the plug-in future there might not be a lot to look at. Apps are dead. Soon enough, there will be an action for that.
One Automattic "hack day" many years ago, I released Genericons, a font containing a bunch of little icons useful for blogs and websites. For this years hack day, I created a new version, Genericons Neue. It's visually more coherent and icons are better weighted against each other. The set comes with minified SVG files ready for use, as well as an icon font if you want to use that (buyer beware). If you're a fan of Node, there's a module you can install. It's super easy to use, and I encourage you to use the set, fork it, customize it, and bundle it with your themes.
The original Genericons set was created for the WordPress Twenty Thirteen theme. A goal for that theme was to be colorful, and in order for that to work, icons for tags, categories and comments had to be easily re-colored using only CSS, something which PNGs did not allow. SVG support wasn't impressive at the time, and so Genericons became an icon font. Inspired by The Making of Octicons, Genericons were pixel-perfectly drawn in Glyphs Mini. It was quite an arduous process.
Genericons Neue is focused fully on icons, so all logos have been removed — more on that in a bit. The set now use grunt to build everything from the minified SVGs to the icon font. The build process is like a black box: you feed it a folder of SVG icons you drew, and it outputs formats ready to be used in your themes and web projects.
If you're coming from Genericons, do note that there are no logos in Genericons Neue. Because Genericons was so early to the icon-font game, it more or less became a kitchen-sink for icons and logos. First just a few logos — "the most important ones" — then slowly it grew into too many. There were a bunch of little dingbats and one-offs, like triangles for CSS speech-bubbles today better done using just CSS alone. It was useful at the time, but it diluted the focus on being a great and consistent set of icons. On top of that, logos present unique challenges. Aside from having to be kept up-to-date with rebrandings, how should they be sized? Every logo is drawn on a unique grid, they don't all fit well on a tiny pixel-perfect grid.
If you would like to upgrade from Genericons to Genericons Neue, you can use logos from a different set, such as Social Logos. If you are only using the icons also present in Neue, it's a drop-in replacement as the icon font will map to the same codepoints.
Incidentally, the new Pixel homescreen applies icon normalization, which resizes icons that do not follow guidelines:
Icon normalization isn’t perfect either, though, and it also doesn’t prevent app builders from creating wildly different icons. The move to round icons feels like a last ditch attempt at reaching for some kind of consistency in app icons, even if the icons themselves lose a great deal of creativity in the translation:
The thing is, outside of doing basic icon normalization, the Pixel phones don’t enforce the round icons, so unless a developer actually makes one, you’ll still end up with a mix of styles.
There Is No Single Style
Having consistent and beautiful app icons throughout an operating system is a beautiful dream, one that I’m sure many designers have had. But so long as app developers have to provide this icon themselves, the styles are going to vary as much as all human art does. It’s human nature, it’s an expression of individuality, a difference in taste, and a result of varying degrees of design time invested.
It might even be done intentionally for differentiation. While having an icon that blends in, fits, looks right among the other icons on the platform might make users happy, the app developers might want their icon to stand out (even if like a sore thumb), scream to the sky: look at me, my developers have families to feed, launch me.
Many attempts have been made at producing consistency where none is found, icon normalization is just one of them. Samsung phones put all icons on a squircle badge, Xiaomi phones offer multiple approaches ranging from badging and masking to replacing icons with huge icon packs to replace every icon on your homescreen.
Perhaps the most successful approach has been that of the iPhone, and probably due to the rather strict limitations imposed: no transparency, therefore no custom silhuettes. Every icon gets cropped into a rounded rectangle. Even then, icons on the iPhone differ wildly in style.
The story is the same on Windows and macOS. Windows 8 and 10 courageously tried to retire the app icon in favor of live tiles that could even be resized, so the user had more control of the aesthetics, and recommending flat white, fairly easily designed motifs:
Spot the odd one out
… but even then, no matter how specific your guidelines for app icon designs are, designers can choose to not follow them.
Even if the guidelines were enforced, I suppose, there’s no guarantee the results would be consistent.
The Why of App Icons
It’s always prudent to ask the question: what problems are we trying to solve? Why are there app icons in the first place? I suspect Microsoft asked the same question, leading them to try live tiles.
The obvious answer is that app icons exist because apps exist, and apps work in a specific way. Your operating system provides a platform on which an app runs, and it’s then the job of the app to solve problems, give information, make you productive. If you need to write text, you open a writing app. If you need to edit photos, you open a photo editing app. This is how it’s always been. But will it stay this way?
We have to go deeper!
Why did you want to write text? Why did you want to edit a photo? What happens to the text when you’re done writing, are you going to send it somewhere, publish it? What happens to the photo when you’re done editing?
What if the operating system was intent-based instead of just a platform for a wild west of apps? You want to call someone, use the operating system dialer, but use it with WhatsApp. Want to make a reminder? Use voice actions, but save it in Evernote. Want to listen to music? Press the play button, which you mapped to Spotify instead of Apple Music.
We’re getting ahead of ourselves, and I still have that upcoming post about how apps might look in the future — Update:here’s that post. But the point is — perhaps app icons don’t really matter in the future. Perhaps the platforms of the future finally break the shackles of “a grid of icons” and relieve us of the menial tasks of jumping in and out of apps. In such a future, perhaps an app doesn’t even need an icon — perhaps the app is more like a plugin that hooks into touch points of the operating system, replacing or giving alternatives to what’s already there.
Keeping such a future in mind, it’s hard not to look at Google’s round-icon efforts and smile like a loving parent: aaw that’s so cute, bless your heart for trying!
I like round icons. I like silhouetted icons. I like really well-designed icons, and I love that Google and Microsoft are trying their best to foster consistency among app icons. But perhaps the battle won’t be relevant in a few years. There will still be good designs and bad designs, of course, but perhaps that battle won’t be fought on your homescreen or desktop.