In a recent interview with Intercom, Joshua Porter expands on his “Wireframes are dead, dead, dead!” tweet from a while ago:

I think you can capture almost everything you need to capture in a pretty detailed sketch. Not a high fidelity sketch by any means. Not the ones where you use five different kinds of markers and you shade everything or whatever. The purpose of sketching is to communicate the major ideas, like, “What’s going to be on the page? What are the objects on the page? What are the things you can do to those objects?” […]

On the other hand if you want to actually test something, you need a prototype that someone can test. So, I would actually say that the role of the product designer is working with stakeholders to come up with those sketches, and then going right from that sketch all the way through to prototyping. That usually means high fidelity mockups that can be clickable or lightweight HTML prototypes that are clickable and usable.

This is the workflow we’ve adopted at Flow as well. We sketch different interface ideas (variation), and then move to prototyping in Axure when it’s time to test and improve a specific idea (iteration). There’s not much room for static wireframes in that workflow. But it is an ideal workflow, and not every project is ideal. As I’ve mentioned before:

Lacking budget, flat wireframes for quick iteration is better than doing no iteration at all. We can’t be so idealistic that we’re not willing to scale down our processes when we need to.

So as long as we’re willing to admit that one size doesn’t fit all, I’m all for advocating an ideal approach that degrades gracefully under non-ideal circumstances.

Also see Wireframes: A good communication tool, a poor design tool by Dan Ritzenthaler.

John Naughton wrote a good summary of the Mythical Man-Month problem (the belief that adding more people to a project will get it done faster) in Why big IT projects always go wrong:

Man-months are a hopeless metric for assessing the size of a complex software project. Why? Basically because a big software project involves two kinds of work: the actual writing of computer code; and co-ordinating the work of the dozens — or maybe hundreds — of programmers working on different parts of the overall system. Co-ordination represents an essential but unproductive overhead: and the more programmers you have, the bigger that overhead becomes. Hence Brooks’s law: adding manpower to a late software project makes it later.

I’ve yet to see a large project where this law doesn’t apply.

Elliot Hannon nails it in CNN Gets It Wrong — Why We Don’t Really Mind:

If we cared more about journalism than news theater we’d all be watching PBS. But no one’s talking about NewsHour. There are no meltdowns. The circus, itself, becomes the point — the reason to watch. Youtube videos go viral precisely because they are unexpected, unvarnished — embarrassing. This is CNN.

I know I talk about it a lot, but here’s another paragraph from Neil Postman’s 1985 book Amusing Ourselves to Death that could have been written about 24-hour news networks:

Thus, we have here a great loop of impotence: The news elicits from you a variety of opinions about which you can do nothing except to offer them as more news, about which you can do nothing. […]

And a few chapters later:

Our culture’s adjustment to the epistemology of television is by now all but complete; we have so thoroughly accepted its definitions of truth, knowledge, and reality that irrelevance seems to us to be filled with import, and incoherence seems eminently sane. And if some of our institutions seem not to fit the template of the times, why it is they, and not the template, that seem to us disordered and strange.

Develop Smarter, Simpler and Better Connected Apps with Javascript

Imagine connecting your app to everything with just 2 lines of code — files from all over the web, across cloud storage source, social networks and devices.

Filepicker.io provides a full file system API for your web and mobile applications that allows your app to upload, open, read, write, store, sync and convert files from over 17 sources including Dropbox, Google Docs, Facebook, Skydrive and Box. With the Filepicker.io Javascript API, request a file and receive a simplified URL. Then, upload the URL to your server or serve through your CDN.

Filepicker.io includes a customizable drop-in UI widget and an API library allowing you to send uploaded files directly to your S3. Sign up for Filepicker.io today!

Sponsorship by The Syndicate.

Jessi Hempel’s The second coming of Facebook is a very interesting profile of the company and where it’s headed. There’s one paragraph in particular that has stuck with me for the past few days:

At Facebook developers choose the projects they want to work on, and product groups compete to woo them. Managers sent out reports highlighting the product teams that were doing a good job. Pretty quickly teams realized that if they wanted to get praised in the weekly memo, they needed to start recruiting mobile developers.

My first thought was that this is a great idea. If you want to get something done at Facebook, your idea has to be interesting and challenging enough to convince developers to work on it, otherwise it just won’t happen. I’m sure this weeds out a lot of ill-conceived project ideas.

But there’s a problem with this approach. If Product Managers have to convince developers to work on their projects, they are going to pitch ideas that have a big chance of being interesting to… developers. Not to Facebook users. So there’s a danger that the product features being pushed out are wild and challenging and extremely interesting, but don’t meet user needs particularly well.

In the example cited in the article, an internal weekly memo effectively changed the company’s entire roadmap by shifting attention to mobile. Not that shifting to mobile is a bad thing, but too much focus on things like who gets praised in an email has the potential to seriously derail a company.

Still, the idea is really appealing: making Product Managers effectively vie for developer attention ensures that the PMs do their homework so that they can sell and defend their ideas to the company and to customers. That’s a worthy cause. It would be great to make some form of user validation part of what happens before projects are pitched, though. I guess I just remain weary of the prevailing myth that we are like our users.

In his post Why we fear Facebook and why we shouldn’t Paul Jacobson makes an interesting counterpoint to the common refrain that it’s bad to share our personal data with companies:

Conventional wisdom is that if you are not paying for a product, you are the product. That may be true, as a generalisation. I prefer to think it isn’t so much we who are the products on Facebook but rather our preferences and attention. What does that buy us? For starters, it buys us Facebook, Twitter, Google services and more. It also buys us slightly less annoying ads that can be remarkably relevant. It buys advertisers a better chance that we may want to buy their products and services because those products and services may just be what we are looking for at that point in time.

It’s a good question. Is it really that bad to get highly targeted ads in our news feeds? The more targeted the ads are, the more useful they are to us, right? So why is there such pushback against this trend in companies like Google and Facebook to try to find out everything they can about us?

I think there are three main reasons why we need to be wary of letting ad-driven companies know too much about our preferences, even if they just use it to serve us more targeted information and ads.

1. It makes the web smaller

If we only see stuff we’re already interested in, we run the risk of becoming sucked into the Internet’s “filter bubble”, where it’s much harder to discover new information beyond our current knowledge. Maria Popova puts it like this in Are We Becoming Cyborgs?:

The Web by and large is really well designed to help people find more of what they already know they’re looking for, and really poorly designed to help us discover that which we don’t yet know will interest us and hopefully even change the way we understand the world.

When an algorithmic constraint is placed on the information we see, and that constraint is based solely on our current preferences, we will remain safely locked into the world we know. That means that we become less likely to broaden our horizons with new discoveries.

2. It results in heightened confirmation bias

When we’re steeped in information that confirms our existing beliefs (regardless of whether those beliefs are true or not) we not only seek out more of the same information everywhere we go, but we also become incapable of changing our minds even if we eventually are presented with the truth (the denial of Global Warming is a good example of this…). This is called confirmation bias, and Clay Johnson writes about it in the context of media and the Internet in his book The Information Diet:

It’s too high of a cognitive and ego burden to surround ourselves with people that we disagree with. If you’re a Facebook user, try counting up the number of friends you have who share your political beliefs. Unless you’re working hard to do otherwise, it’s likely that you’ve surrounded yourself with people who skew towards your beliefs. Now look beyond political beliefs—how many of your friends share the same economic class as you? […]

Those algorithms are everywhere: our web searches, our online purchases, our advertisements. This network of predictions is what Pariser calls the Filter Bubble in his book by the same name—the network of personalization technology that figures out what you want and keeps feeding you that at the expense of what you don’t want.

So, for example, through its EdgeRank algorithm Facebook figures out what we like and what we believe in, and then shows us stories and ads that confirm those beliefs. It doesn’t care about truth, it cares about engagement — even if that engagement comes at the expense of what is right.

3. It designs our lives for us

This is true for all advertising, but even more so for hyper-targeted advertising: it tries to sell us stuff we don’t necessarily need. Yes, I know we’re tired of hearing how we should all live with less stuff blah blah blah. That’s not necessarily what I’m saying. What I’m saying is that we need to be careful that we don’t become a society built around the needs of corporations. David Cain talks about this in his chilling essay called Your Lifestyle Has Already Been Designed:

We’ve been led into a culture that has been engineered to leave us tired, hungry for indulgence, willing to pay a lot for convenience and entertainment, and most importantly, vaguely dissatisfied with our lives so that we continue wanting things we don’t have. We buy so much because it always seems like something is still missing. […]

The perfect customer is dissatisfied but hopeful, uninterested in serious personal development, highly habituated to the television, working full-time, earning a fair amount, indulging during their free time, and somehow just getting by.

There’s nothing wrong with stuff, of course. But there is something scarily wrong about the way we let our desires be dictated by advertising — especially targeted advertising by companies that know us so well.

What it means…

I don’t think our biggest fears about the data that companies collect about us should revolve around identity theft or the government coming to get us (although, in some regions, that’s certainly legitimate concerns). Our biggest fear should be what Huxley points to in the future he paints in Brave New World: that we will be ruled by what he calls “man’s almost infinite appetite for distractions”. Huxley believed we should fear companies who aim to control us by inflicting pleasure on us, and I think he might have been on to something.

I know that sounds really alarmist. But still, I can’t look at my Facebook news feed and not think about this possible future. That’s why I think we should hold our personal data and preferences just a little bit closer to our hearts.

I always enjoy the interviews on The Great Discontent, and this one with designer Matthew Smith is no exception. Here he describes how he turned his hobby into a business:

At the time, my wife was pregnant, we had a one year old, and we were all living on about $26,000 a year—I knew I had to think bigger, so I went for it. I got the first $8,000 job and then another. Then people started asking me to build more things, like customer databases. I would nod in agreement as if to say, “Of course I can do that,” and then I’d get off the phone, crap my pants, and go do research on Google, ask questions on forums, and figure it out in order to deliver a product to a client and make them happy with the results. Done!

I can certainly relate to the get off the phone → crap pants → figure it out workflow. I also like Matthew’s critical take on the concept of endless feeds on the Internet:

Who came up with the idea of endless content constantly streaming toward us? There’s this unlimitedness that concerns me because it is so unlike the rest of the human experience and I think it confuses the human mind and puts us into a space where we aren’t at our best. I want to make sure that no matter the project or company I’m involved with, I’m always asking if it’s serving the human best and helping us be at our best.

That last part reminds me of something Alex Griendling said recently:

Our work does not exist in a vacuum; it is given context and meaning and power by the places it appears and the people that benefit from its usage. When clients hire us, they’re doing so because they believe it will benefit them. With this in mind, it’s important to ask yourself the question “Is this client worth helping?”. If great work is made for those that exhibit repugnant practices, how does this benefit anyone other than the individual client?

Words to live by…

This post provides background and additional resources for my talk on Responsive Web Design in Africa. Last update: May 23, 2013.

I’ve seen a surprising amount of pushback on responsive design within the South African web community recently. The skepticism is mostly based on issues such as low smartphone share and high data costs in Africa, along with assumptions about “the mobile context” and how people supposedly have vastly different needs on mobile phones than they have on their desktops.

So, the purpose of this talk is to summarize the case for Responsive Web Design, and to argue that the reasons against using this approach in Africa don’t hold up. Smartphones and data access are exploding in Africa, so if we want to be Future Friendly, we don’t have a choice. We have to adapt.

The slides for the talk are below, although of course, some context gets lost without the voiceover. There are also embedded gifs and videos that obviously don’t play within Slideshare, so you’ll have to use your imagination on those…

Resources

I cite the source for each quote, example, and data point on the applicable slide, but I thought it would be helpful to provide a brief list of Responsive Web Design resources here for easy reference.

For those who want to dig a little deeper on the data in Africa, here’s a list of the reports and presentations I found most useful:

• GSMA’s Mobile Observatory Series, particularly the report African Mobile Observatory 2011 (PDF link)
• Insights into Mobile Telecoms in Africa by Jon Hoehler and Andrew McHenry
• The Smartphone Snapshot Showdown by Jon Hoehler and Andrew McHenry
• Key findings from the Mobile Africa 2012 report (thanks to Ethan Marcotte for this link)
• Insights into the mobile-only generation

Here’s an incomplete list of introductory articles to get you started on responsive design. These articles mainly touch on topics I bring up in the talk, like the reasons for adopting responsive design, performance issues, and RESS:

• Define :: Responsive (a demo to show people how it works)
• Responsive Web Design: What It Is and How To Use It
• Reasons for Responsive Design
• Responsive web design: the war has not yet been won (More reasons)
• Content Parity (Relates to the “Mobile is Less” myth)
• Impact of Responsive Designs (Some good data on the benefits of responsive design)
• Where to Start (How to start adjusting workflows)
• Prioritizing Performance in Responsive Design
• Conditional Loading for Responsive Designs (On progressive enhancement)
• Getting started with RESS (Server-side components to deal with lower end phones)
• Responsive Deliverables (What you can expect from your design team or agency)

If you’re looking for responsive patterns, start here:

• Brad Frost’s collection of patterns and modules for responsive designs
• Responsive navigation plugin (without library dependencies and with fast touch screen support)
• Some more patterns for dealing with navigation
• Responsive Multi-Level Menu Demos
• Alternative ways to optimize navigation across touch devices (Luke Wroblewski and Jason Weaver)

And here are some ideas for dealing with responsive images:

• Adaptive Images in HTML
• Responsible Responsive Images by Mat Marquis
• ReSRC.it (Responsive images on demand, directly from the cloud)
• A small set of CSS classnames to help keep images cropped on the focal point
• A quick intro to Icon Fonts

For more great resources on responsive design, see Jeremy Keith’s extensive list.

The point

My goal with this talk was not to say anything groundbreakingly new about Responsive Web Design. The goal was to urge designers and developers who work in developing regions to take responsive design seriously, and at the very least consider the approach for their next projects.

If you have any questions or comments (or are interested in having me come present this talk somewhere), please get in touch.