I recently had the pleasure of attending a discussion between Steve Blank and Gary Shapiro on startups & innovation. While there wasn’t a huge amount of new insight for a San Francisco audience already steeped in lean principles, I was glad to finally pair their voices and mannerisms with all the words they’ve written.
While discussing how industries beyond Silicon Valley have sought repeatable innovation through bureaucratizing teams and processes, Shapiro shared a brief anecdote about meeting with US military CIOs. He was amazed by their sophisticated capabilities in acquiring, interpreting, and acting on raw data. In particular, he was impressed by how vehicle movement patterns across entire cities were tracked and analyzed to predict future behavior - an incredible feat only recently made feasible by surveillance drones, some capable of tracking
every moving object across an area of 15 square miles and storing
one million terabytes of video per day, 5,000 hours of HD footage, while broadcasting live streaming footage ➠.
Shapiro’s enthusiasm for the technology independent of its use particularly struck me because just a month ago I saw Mark Mazzetti, Pulitzer Prize-winning National Security Reporter for the New York Times, sit in the same chair and describe how vehicle movement patterns are used to select signature drone strike targets in Pakistan. While the exact qualifications required for signature strikes are not public, they are attacks against vehicles, individuals, and locations which
bear the characteristics of Qaeda or Taliban ➠ - in short, strike authorization is determined primarily through pattern recognition.
the CIA could not confirm the identity of about a quarter of the people killed ➠, and
the strikes have killed an estimated total of 2,600 to 4,700 people ➠. Scroll through this table of documented drone strikes and note the number of killed
Unknown, and how many targeted organizations are designated
Unclear instead of
Al-Queda. The degree of uncertainty and collateral damage is unsettlingly high considering these attacks kill people.
I don’t mean for this to be a comment on the morality/efficacy of drone strikes. Rather, it’s an observation on how disconnected data-based decision making can be from the very real human impact. It was a bit startling to see an enthusiastic Silicon Valley endorsement of capability that failed to address how data-heavy decision processes fundamentally alter our awareness of and compassion for the people affected. This shouldn’t be a binary choice, but it’s often embraced as one.
To dial it back a bit, inadequacies in even the most extensive customer and user behavior databases have sent companies back towards more humane decision making - for example Facebook’s adoption and advocacy of Data Informed, Not Data Driven. For those of you interested in the broader subject of technology trust & security, I’ve been greatly enjoying Bruce Schneier’s blog.
The BBC News’s web development team recently shared their path to responsive design. It’s a cautious, iterative approach befitting the BBC’s broad distribution, but aspects of it may be appropriate for any team wary of flipping scary-big switches while migrating a large legacy site to a more modern front-end.
When the mobile site first re-launched it was … just for devices that we classified as “basic phones”. Towards the end of last year (2012) we felt the site was good enough to make it the primary experience for smart phones, i.e. iPhones and Samsung Galaxies, so we started automatically redirecting those phones from the desktop site to the mobile one.
Sometime this year we will start redirecting tablets to the responsive site, and then hopefully towards the end of the year we will make the responsive site the default version you see on any device.
… We are slowly growing the mobile site into a fully-fledged responsive product to eventually take over and replace the existing desktop site.
Implied by this approach is that moving to a
fully-fledged responsive product involves more than the fairly trivial challenge of adding breakpoints. Designing and building a single site that feels right for users across a wide variety of devices with appropriate layouts, interactions, and client-/server-side components is a lot of work and touches more than just CSS.
BBC News’ iterative-support approach is a great model for exploring the technology and its impacts on user behavior & design, provided your team is capable of supporting two independent front-ends through the potentially lengthy transition - especially if the desktop site requires continued feature development with a separate set of legacy design requirements.
Building a shiny new future next to the deprecating past is standard practice in software development, but it’s easy to fall into indefinite parallal support. Resource-strapped teams tracking early signals to guide where to invest effort are suseptible to abandoning the lower-traffic responsive front-end if new feature development on the legacy site takes priority. The BBC News team addressed this by building new features as responsive components, then serving those componenents within the legacy desktop site. Love it. Shades of Luke W’s RESS.
A fully client-side alternative is to introduce responsive and flexible elements piecemeal, first on global chrome (header, navigation, footer, etc), then responsive-izing individual components and layouts to live within that chrome. This shares some of the BBC News approach’s advantages while keeping your entire team in one codebase, sidesteps issues with canonical URLs and both user-agent & legacy redirects. However, it introduces the potential of design awkwardness to users navigating across content at various stages of migration, can add transitionary page weight when both legacy and new front-end must be supported within the same view, and the conflation of greenfield with legacy concerns slows down development while restricting design freedom.
Challenges aside, the key benefit of these approaches is that they’re a) looking beyond device-specific sites that must be independently maintained in perpetuity with no path toward reconciliation, and b) avoiding the support gradient and usability risks of huge redesigns.
We need native CSS media queries at the element/component/widget level, not just the viewport. Make it so, internetz.— Nicolas Gallagher (@necolas) February 7, 2013
Using global viewport dimensions in what should be disparate, isolated components leads to a fragile page dependent on layout & positioning interactions between components.
You’re probably already using media queries at the component level instead of in viewport-specific overrides because it’s far easier to maintain a self-contained component than one that’s described in multiple places, but this approach isn’t without tradeoffs - your stylesheets with be littered with duplicate and interdependent breakpoints. It’s too easy to wreck layouts by editing one breakpoint without adjusting all the others it interacts with - pretty much the opposite of DRY.
These problems are alleviated somewhat by using tools like the Compass Breakpoint extension with well-scoped and descriptive breakpoint variable names, or just copiously documentating (volatile) UI code, but those are high-effort workarounds that’s don’t address the problem that we’re using viewport media queries for more than they’re intended. We can make square pegs fit, but it’s hell on the round hole.
Fortunately, people like Tab Atkins (on the Google Chrome team & CSS Working Group) are also thinking about this:
The idea of Element Queries is pretty simple - it’s like a Media Query (specifically, the min-width/etc queries), but for a parent or ancestor element, rather than the viewport.
If implemented, element queries would improve encapsulation of UI components, improving flexibility, modularity, and maintainability by defining CSS properties relative to the space available within the layout rather than the size of the entire viewport.
More from around the web:
media queries for elements.
- Ian Storm Taylor also shared examples of media query brittleness and the element query opportunity.
- Atkin’s article on element queries (also linked above) discussed some of the challenges and and possible solutions, including a new
viewportHTML element that would behave similarly to
iframeas an independent viewport within a larger page.
On 2013’s design trends, how user’s really hold mobile devices, what does
mobile mean anyway, what’s up with all those iPhone weather apps, bourbonomics, harmonious pages, the rest of the world, astronauts becoming humans, digital magazine experiences, herd immunity, and some tweets.
On hidden motives, performance as design feature, layout’s impact on performance, Google redesigns, CSS code smells, how software gets built, Small Nudges, new product manager priorities, and modern.IE.
The team behind the innovative and well-received Orchestra is nearing a public launch for Mailbox, shifting from
a to-do list with email-like functionality ➠ to an email inbox that behaves like a todo list. Mailbox appears to be taking a somewhat different approach from other recent email clients, so I’ll refer to its potential while exploring where I think email’s next stage of client evolution is headed.
That inboxes are simply todo lists other people can put stuff in is increasingly regarded as truth, especially after Paul Graham wrote last year about email’s noisy, inefficient status quo and the opportunities it presented in Frighteningly Ambitious Startup Ideas:
As a todo list protocol, the new protocol should give more power to the recipient than email does. I want there to be more restrictions on what someone can put on my todo list. And when someone can put something on my todo list, I want them to tell me more about what they want from me.
Efforts to modernize email-like messages are of three general types:
- Develop a new protocol (eg: Microsoft’s MAPI, Apple’s iMIP) - difficult outside the enterprise,
- supplant the inbox by creating an alternative messaging service (a/synchronous chat, status, feeds, boards, eg: Salesforce) - fracturing where users look for new content,
- redesign the email client’s content and interaction layers.
Redesigning the client’s low barriers to entry have made it a very busy space. Unfortunately, most address only superficial challenges and delivering even a superficial client is difficult. New clients must meaningfully differentiate from service providers’ thoroughly entrenched clients, integrate with existing services (Exchange most notoriously), resonate with user needs, and attract & retain notorously fickle process voyeurs necessary for evangelizing a broader audience. Achieving all that, client design is highly vulnerable to duplication.
Sparrow may be the only recent example of a successful email client, which many attribute to their port of other messaging platform models, good timing, and steady improvement over time. But even their success is relative - future development was abandoned when acquihired by Google to work on Gmail.
The best way to defend an email client that competes on design is to consistently deliver the best product in a space regularly flushed with new competitors scrabbling for niche users. It’s extremely difficult to dig a moat without other advantages. Still, the siren calls ever more developers - today’s clients are simply inadequate.
Mailbox is unique because of the potential moat afforded by using their own API in place of IMAP. While it is currently marketed as improved message delivery (ie: iOS push notifications), there’s an opportunity for its purpose to expand. Speculating, this could perhaps be similar to Apple’s Messages, sending email from Mailbox to Gmail but meta-augmented todos from one Mailbox user to another. As Graham put it,
Do they want me to do something beyond just reading some text? How important is it? … When does it have to be done? By acting as intermediary, Mailbox could deliver more useful, actionable messages to users on its platform without creating yet another inbox.
The Mailbox team has already suffered to learn the difficulty of succeeding in a sea of similar products. After all, great adoption and poor retention precipitated Orchestra’s pivot to Mailbox:
Lifehacker calls Orchestra the best to-do app for iPhone. Apple named it the 2011 Productivity App of the Year. And perhaps more importantly, user reviews have been nothing short of amazing. In short, the response has been more positive than we could have possibly imagined.
So that’s the good news. But as we analyzed how people used Orchestra, we discovered two challenging facts. First, most people (even the very excited ones) stop using Orchestra over time, in a pattern similar to other to-do lists. And second, no matter how much people use the app, almost everyone still has tasks trapped in their email. At best what you get is a two-tool world: two systems that you have to stay on top of, with one of them (Orchestra) getting used less and less over time.
Implicit in the quote above is that Mailbox, or any client, must solve email as more than just a todo problem. Todo-oriented interaction and design overhead cannot interfere with more consumer-oriented use cases, like sharing cat pictures or saying hello. If the todo workflow negatively impacts more basic communication, users won’t adopt it for anything but todos - effectively recreating Orchestra’s two-tool problem. The ideal case for all users is less time managing inboxes.
But we’re getting closer to mere implementation details. Philosophically, email clients increasingly acknowledge inbox user needs instead of simply showing unread at top. Mailbox as marketed doesn’t quite answer Graham’s challenge, but apps like it are the first breaths in email’s next stage of evolution.