GitHub introduced a new text editor called Atom last week, and reactions (at least in my Twitter feed) seem divided between fervent desire and snide disregard. For every few people shamelessly begging for invites, you’ll find one or two bemoaning how fickle we all are, how crowded this software category has become, or how our obsession with the “latest and greatest” distracts us from what really matters (what we make).
Some of these emotions are likely the result of the unspoken assumption that everyone in our industry must always know everything (Lyza called this the knowledge burden). But I also believe, regardless of industry, that a natural friction exists between makers and their tools.
We’ve yet to invent a device capable of directly converting our thoughts into physical manifestations. Until we do, tools can only approximate our intent. This means that the distance between idea and execution is often defined by the capability of our tools and our mastery thereof. They tell us what we can and can’t do.
It’s a complicated relationship.
Some remain faithful to a specific toolset for as long as possible, cultivating an intense and focused knowledge of every feature, quirk and workaround. Peanuts creator Charles Schulz was so fond of Esterbrook & Co.’s Radio Pen No. 914 that he bought all of their remaining stock when they stopped producing it. The pens lasted him through the remainder of the strip’s nearly fifty-year run.
Others transition quickly, abandoning their previous workflow as soon as they feel it may be working against them. English post-punk band The Fall have remained vital and prolific for nearly four decades, in part because of frontman Mark E. Smith’s infamous propensity for changing the band’s lineup with little or no warning.
We’ve yet to discover that magic “one size fits all” process. Until we do, we should encourage the accelerating expansion of available tools while remaining skeptical of any that claim to be everything to everyone. Choice encourages diversity in the types of thought processes our medium supports.
In other words, tools are important. Not for their own sake, but for those they empower to create. Welcome!
Last year, the kind folks at UIE invited me to give a workshop entitled When Responsive Design Meets the Real World at their UX Immersion Mobile conference in Seattle.
The workshop was a blast. People seemed to enjoy it.
But despite that I was honored and surprised that the folks at UIE invited me back to UXIM 2014 to present an updated version of the workshop.
Not only that, but they created a neat animated video about the talk.
I wasn’t sure what to expect from the animation. I did an interview with Jared Spool for the UIE Podcast (available for your listening pleasure now), and at the end of the podcast, they asked me to talk for a couple of minutes about the workshop and they would “animate it”.
I think it turned out pretty well. I literally laughed out loud at the person hitting their head against the wall. Let’s just say that it wasn’t hard to see myself in a character with a round head and no hair.
UXIM looks great again this year. Lots of great speakers and in-depth workshops. If this sounds like something of interest to you, you can register for UXIM using the code “SPKUXIM” and save $200 off the full conference price.
I’d love to see you in Denver.
Have you seen Dan Bricklin‘s Responsive App Design video? Yes, that Dan Bricklin. The “father of the spreadsheet” Dan Bricklin.
I desperately wanted to include this video in my last article on when responsive design makes sense for your app. But it felt forced so it got cut.
The video is worth watching. It’s fun to hear Dan compare responsive design to the challenge of fitting a spreadsheet on a 40 character screen. Check it out.
A few months ago, I found myself in a Twitter debate over whether or not responsive design can work for web apps.
While it was a fun debate, trying to answer the question of whether or not responsive design makes sense for your app is futile. Let me explain.
We don’t have a common understanding of what responsive means.
I wrote about my struggles with figuring out what is “responsive” recently. People think they know what others mean when they say something is responsive, but our definitions often differ.
The best responsive designs use much more than responsive design. When that is the case, it is easy to find faults with any given responsive implementation that can be used to say, “Well, that’s not really a responsive design.”
What happens when you use responsive web design, but add to it things that seem to be at odds responsive design? Is it possible to add something that make it no longer responsive? If so, where is the line?
What is a web app?
If responsiveness has a murky definition, “web app” is considerably worse. Jeremy Keith has long argued that “like obscenity and brunch, web apps can be described but not defined“.
Chris Coyier recently polled his readers about whether or not it was useful to distinguish between “web apps” and “web sites”.
See the Pen SVG Doughnut chart with animation and tooltip by Chris Coyier (@chriscoyier) on CodePen.
While people agree that the distinction is important, there was little consensus on what the distinction was. Chris summarized his findings thusly:
I was kind of hoping we could get somewhere close to a solid distinction between these two classifications, but I don’t think it’s going to happen. There is very little agreement and heaps of opinion.
So any time we’re discussing web apps, we’re going to have trouble agreeing on what we’re talking about. Discussing responsive web apps is just asking for trouble.
A case study in different perspectives
Here is a timeline of articles and discussions that illustrates my point perfectly:
June 17, 2013 — Responsive design Web apps – good or bad?
On a content only site it [responsive design] probably is very wise to start small and scale up. But in a highly interactive functional UI the UX will be damaged by the time you scale up. Or vice versa. Take a demanding environment such as online betting or a tipping platform. The users needs are potentially very different between device environments.
July 4, 2013 — Why Responsive Web Design is a Must for Gambling Sites
I personally have no doubts that responsive web design will become an official standard for all good web pages and web content design to comply in the future, so now is the right time for you to start using it on your gambling and sports betting sites.
June 13, 2013 — Case Study: Betting on a fully responsive web application
Kambi is one of the top sports betting providers and their services include popular sports from all over the world…At Kambi we went all-in on this bet and decided to build a web application that scales across the board. The value was clear, unified development process and consistent user experience on all platforms…Fully responsive web applications is not just a pipe dream anymore*. With the right mindset, tools and processes it all becomes possible.
July 9, 2013 — I point to Kambi as an example of responsive design being used for a web app. Nick Finck replies:
- Gambling apps are too complex to use responsive design.
- All gambling apps should be responsive.
- A case study of how a popular gambling app was built to be responsive.
- The gambling app in the case study is too light-weight.
Therein lies the problem. Even when we have a specific niche app/site (e.g., gambling), we can’t agree on the definitions. We have a case study of how a gambling app was made responsive, but we derive different conclusions about how applicable the case study is.
And I’m fine with that. I don’t mind ambiguity. People don’t have to agree.
I just think it points out how futile it is to try to convince others that responsive design for web apps makes sense.
My thoughts on responsive design for apps
For my own part, I believe responsive design for apps is a no-brainer. We’re building apps for clients that use responsive design. I’ve seen large, complex apps for Fortune 500 companies that are in development. I’ve seen what other agencies are working on.
This stuff is coming. And perhaps when enough of these projects launch, we’ll move on from the debate about whether or not responsive design works for apps like we’ve moved on from similar questions about responsive design for ecommerce. (We have moved on, haven’t we?)
But even if I wasn’t fortunate enough to get a behind the scenes look at upcoming responsive app projects, I would still argue that responsive design for apps is inevitable:
Once you start accepting the reality that the lines inside form factors are as blurry as the lines between them, then responsiveness becomes a necessity.
I’m not saying there isn’t usefulness in device detection or looking for ways to enhance the experience for specific form factors and inputs. This isn’t a declaration that everything must be built to be with a single html document across all user agents.
What I am saying is that even in scenarios where you’re fine-tuning your app code and UI as much as possible for a form factor, that the differences in screen size and the various forms of input within a form factor alone will be enough to require you to design in a responsive fashion.
Sure you can build a complex web app without responsive design that only targets tablets, but that app would be limited. There is too much variation in the screen sizes of tablets for a design that isn’t responsive to work on more than a handful of devices.
I’m much more interested in skating to where the puck is going to be, no matter how difficult, than to fixate on what is easiest to do now.
We’re focused on helping our customers make their apps work across devices. And that means taking on many complex challenges. Making apps responsive is just one of them.
So how will you know when responsive design makes sense for your app?
When you decide it does and put in the hard work to make it so. The rest of the discussion is just noise.
Earlier this week, I made my first custom icon font using IcoMoon (implemented with Filament Group’s “bulletproof” technique).
I set my grid sizes and exported, but all the icons felt a little higher than I wanted them to be in relation to their surrounding elements. I did some finagling in CSS, but found the results varied (sometimes wildly) between platforms.
After some fruitless Googling, I trudged through the font’s preferences and found the culprit: A rather diminutive baseline height value. In IcoMoon, this is under Preferences, then Font Metrics.
Here’s a quick example at the default height (6.25%):
Here are the same elements and icons, but with a larger baseline height (18.75%):
Lesson learned: If the icon font’s vertical alignment is off, adjust its baseline height before resorting to CSS tweaks.
The more you know…