Back in the day, almost a decade ago, I built a website called “Turtleshell”, loosely inspired by the concept of the world turtle and the subsequent cosmological question of infinite regress: if the world rests on a turtle, then what does the turtle rest on?
Late last year I relaunched that project as a place where I collect personal learnings and aspirations. Come have a look!
It is real, and it is happening now. It’s causing stronger storms, droughts, flooding, mass migration and species extinction.
If you start changing your way of life today, as opposed to once we run out of oil, not only will the change be easier, but if we all do it together we might be able to mitigate the worst aspects of runaway climate change.
September 20th to 27th is the Global Climate Strike. Please take this time to consider which future, if any, you’d like to pass on to the next generation.
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.
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.
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.
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:
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.
My family has supported UNICEF for as long as I can remember. I grew up with their gorgeous puzzles that featured all the colors and kids of the world. Over the past many years I’ve donated to various charities, but UNICEF has always been a staple that I’ve given to on a monthly basis. It’s probably been more than a decade now.
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.
The new WordPress editor, codenamed Gutenberg, comes with a new gallery block that lets you easily pick the number of columns, and quickly put together a nice image collage.
If we utilize the ability to also add a custom CSS class, we can rearrange this gallery relatively easily, using just a little bit of additional CSS.
Start by opening the Block Settings panel, and adding custom-gallery in the Additional CSS Class field:
We can now write a snippet of custom CSS to hook into that and tune the design. Here's a bit of CSS that'll turn it into a masonry layout.
.custom-gallery {
column-count: 2;
column-gap: 0;
padding: 0;
display: block;
}
@media (min-width: 782px) {
.custom-gallery {
column-count: 3;
}
}
@media (min-width: 1440px) {
.custom-gallery {
column-count: 4;
}
}
.custom-gallery .blocks-gallery-item {
display: block;
width: auto;
margin: 0;
}
.custom-gallery .blocks-gallery-item figure {
height: auto;
}
If you'd like an example of what this looks like, head to my Projects page.
No doubt someone will soon enough create a dedicated block just for masonry-style galleries. In the meantime, this trick might hold you over.
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.
I put together a Codepen which features the simplest approach that I've found while still being solid and easy to apply. It works by relying on a main column that has no max-width, and instead applying this max-width to every child element that isn't a wide or fullwide image. The code looks like this:
.site-content > *:not( .alignwide ):not( .alignfull ) {
max-width: 50%;
margin-left: auto;
margin-right: auto;
}See also a version of the same Codepen which features a sidebar, in addition to wide images.
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.
The usual way to float an image is this:
.alignleft {
float: left;
margin-right: 2em;
}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:
<figure class="alignleft">
<img src="https://cldup.com/yPKF2vjugC.jpg" alt="">
</figure>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:
.alignleft img {
float: left;
margin-right: 2em;
}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.
While we can try to raise the ceiling of what’s possible with WordPress by continuing with PHP, HTML and CSS as the foundation, recent discussions in the WordPress JavaScript community about embracing a new framework, excites me. The potential modern JavaScript has for WordPress is huge, and can blow through the roof of opportunity in a truly material way. Just look at what ustwo did with a fully JavaScript: ustwo.com. ???? That’s a WordPress theme. Now imagine the fluidity something like this could bring to the WordPress admin interface.
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.
I grew up learning web development using “View Source”. There was no GitHub, there were no build processes, and JavaScript was usually additive to the webpages we built, rather than foundational and structural. The most worthwhile new thing I learned between 1990 and 2010 was moving from tables to CSS floats for layout. At this point I’m pretty proficient in those technologies, and I can rather quickly put websites together that are pretty good. Why should I learn a new way of writing JavaScript in order to add a little fluidity and speed to websites? Seems like it should be possible to sprinkle some of this on top of existing projects using tried and true technologies, no?
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.
Seems like it’s worth it.
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.
Most successful hardware categories seem to share a few traits:
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:
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.