Keith Houston’s fascinating essay The Ancient Roots of Punctuation begins like this:

The story of the hashtag begins sometime around the fourteenth century, with the introduction of the Latin abbreviation “lb,” for the Roman term libra pondo, or “pound weight.” Like many standard abbreviations of that period, “lb” was written with the addition of a horizontal bar, known as a tittle, or tilde. And though printers commonly cast this barred abbreviation as a single character, it was the rushed pens of scribes that eventually produced the symbol’s modern form: hurriedly dashed off again and again, the barred “lb” mutated into the abstract #.

Which is why the hashtag is often referred to as the pound sign. Keith also explains the origins of the Pilcrow (¶), the Ampersand (&), the Manicule (☞), and the Diple (>). Great article.

I continue to be fascinated by the smart city movement. The multiplexed metropolis is a very interesting look by The Economist at the pros and cons of connecting cities through open access to all kinds of information:

But clever cities will not necessarily be better ones. Rather than becoming paragons of democracy, they could turn into electronic panopticons in which everybody is constantly watched. They could be paralysed by hackers, or by bugs in labyrinthine software. They could furnish new ways to exclude the poor. They might even put at risk the serendipity that makes cities such creative places, argues Richard Sennett, a sociologist at the LSE, making them “stupefying” instead.

I have to admit that I had to look up the word “panopticon” — and it’s such a great analogy. From Wikipedia:

The Panopticon is a type of institutional building designed by English philosopher and social theorist Jeremy Bentham in the late 18th century. The concept of the design is to allow a watchman to observe (-opticon) all (pan-) inmates of an institution without their being able to tell whether they are being watched or not.

Let’s hope we can avoid this…

The front-end team at Booking.com continues to grow and we are looking for talented UX Designers, Web Designers, Product Owners, and Front End Developers to come help us create the world’s best accommodation platform.

You’ll work at our head office in central Amsterdam which is sandwiched in-between canals, museums and the occasional statue of an old Dutch master (good evening, Mr. Rembrandt). We’ll pay to move you and your family from anywhere in the world; USA, Portugal, New Zealand, Brazil, Japan, just to name a few! We’ll provide short-term accommodation and help you adjust to your new home in Amsterdam. You’ll be given the freedom to make impactful improvements to a website and collection of apps used by millions of people. We also have unique company perks like bicycle reimbursement, on site lunch, monthly parties, and our world class year end party complete with live performances!

Apply today.

Sponsorship by The Syndicate.

I love the phrase “getting caught in the melancholy of the infinite scroll.” That’s just one gem from Alexis Madrigal’s The Machine Zone: This Is Where You Go When You Just Can’t Stop Looking at Pictures on Facebook. He explores this strange dark side of “flow”, where we get stuck in an online activity and can’t stop doing it, even though there’s no tangible benefit:

What is the machine zone? It’s a rhythm. It’s a response to a fine-tuned feedback loop. It’s a powerful space-time distortion. You hit a button. Something happens. You hit it again. Something similar, but not exactly the same happens. Maybe you win, maybe you don’t. Repeat. Repeat. Repeat. Repeat. Repeat. It’s the pleasure of the repeat, the security of the loop.

We certainly do seem to treat “pull to refresh” like a slot machine in a casino. And the chances of winning something valuable are about the same, too.

Stijn Debrouwere’s Cargo cult analytics is a fantastic talk/essay on how we often get obsessed with meaningless data in the name of evidence-based decision-making. I don’t want to ruin it, because it’s one of those rare must-read pieces, but here’s a small taste:

Pageviews is a vanity metric: something that looks really important but that we can’t act on and that tell us nothing about how well we’re actually doing, financially or otherwise. […]

There’s nothing like a dashboard full of data and graphs and trend lines to make us feel like grown ups. Like people who know what they’re doing. So even though we’re not getting any real use out of it, it’s addictive and we can’t stop doing it.

Don Norman points out some of the misconceptions of style in a good piece called Great Design Always Means Great Style. He concludes:

There are many dimensions to great design, but great style is certainly among the most important. Style in appearance, style in behavior, style in the manner of interaction – style in every aspect of the product or service. Great style requires careful deliberate specification and then attention to all the details that result, for everything must be coherent, everything must be consistent with the chosen style. Call it personality, call it the voice of the product, call it the persona of the product, call it what you will: great design always means great style. Honest, coherent, and consistent.

I’ve been thinking about workflows for Responsive Web Design quite a bit, particularly since it’s now become our default approach on every new project (similar to Cloud Four’s recent change of heart). I’ve been especially influenced by two recent articles on the topic, namely Dennis Kardys’s A More Flexible Workflow, and Viljami Salminen’s Responsive workflow.

I struggled a bit to make their approaches fit into how we worked, so I decided to expand on what they’ve done and draw something that reflects a bit more accurately how we are incorporating Responsive Web Design into a user-centered workflow within an agency model. It’s not perfect by any means, but here’s what I came up with:

The goals of this approach is to stay grounded in two core principles:

• Content first. We need to stop thinking about content in terms of layout, and plan content independent of design.
• Mobile first. We need to stop the focus on device thinking, and assume a multi-device world where we work on style direction independent of layout.

I’ll briefly go through each step in the diagram and how it helps us to accomplish these goals.

During Discovery we do our research to uncover user needs, develop personas, and create the user journey map that becomes our product strategy (see my article Usable yet Useless: Why Every Business Needs Product Discovery in A List Apart).

In the Planning phase we evolve the user journey map into a content plan and Information Architecture document (see my post on this topic). Once we have our scaffolding in place, we start the design process.

We rarely do static wireframes any more (Cennydd Bowles explains why), but we do a lot of Sketching. The benefits of sketching have been proven time and time again (see, for example, How Diagrams Solve Problems and The importance of sketching in product design). What I like most about the sketching process is how it allows the team to try multiple solutions to a problem, before settling on one or two ideas to iterate further (see Jon Kolko’s Iteration and Variation). I like using Zurb’s responsive sketch sheets as templates because they keep us focused on a multi-device approach.

Once we’ve gone through the sketching phase with clients, and we know what approach we’d like to pursue, we start Prototyping. We mainly use Axure, but there are multiple solutions out there to suit a variety of approaches. Axure isn’t natively responsive (yet), so we’ve been building two prototypes on our projects: starting Mobile first, and then moving on to Desktop. This isn’t ideal, but it works for our current purposes. We have a strong focus on user testing, so we test these prototypes in our usability lab, and iterate the design based on the findings.

Towards the end of the Prototyping process we start working on Style Tiles so we can have a discussion about graphics with clients without focusing on layout and flow issues. We’ve seen huge success with this approach. Once clients are comfortable with the visual direction, the focus can return to discussing how the UI will help them meet their business goals and user needs. It also makes the move from prototype to graphic design much smoother.

Although I won’t say that we’re completely post-PSD, we definitely don’t create the entire site in Photoshop. Since we have an interactive prototype and strong style guides, we generally only create about 6 or so pages in Photoshop, so clients can get a good feel for the direction.

At this point we also start working on Front-end Development. We build the framework using the prototype and style tiles, and pick up speed as the graphic design gets finalized. We don’t use boilerplate frameworks like Foundation and Bootstrap for production code. On this point we stand with Aaron Gustafson:

I find Foundation, Bootstrap, and similar frameworks interesting from an educational standpoint, but I would never use one when building a production site. For prototyping a concept, sure, but to take one of these into production you need to be rigorous in your removal of unused CSS and JavaScript or you end up creating a heavy, slow experience for your users.

An important point on the last three phases: as the diagram points out, these are all very much iterative phases. We make changes all the time based on user feedback, and discussions between designers, developers, and the client. I think we can all agree that responsive design is messy, and we just need to get comfortable with a certain amount of ambiguity during design and development. That’s ok, as long as we’re prepared for it.

It’s been an enormous learning process — and we’re still figuring out the best ways to make Responsive Web Design our default approach. But we’re committed to it, because we believe in content parity, and we’re convinced that responsive design is the approach that will get us there. Some things we’ve learned along the way:

• You can’t wing content choreography. We can’t just make our front-end developers figure out what happens at each breakpoint. This is something we have to plan together to consider all the goals and constraints of the project. Breakpoint graphs are particularly helpful in this step (see Stephen Hay’s Responsive Design Workflow).
• Optimize for touch, support keyboard actions. Josh Clark points out that “every desktop UI should be designed for touch now.” He’s right. The lines are getting blurrier and blurrier between what is considered “desktop” and “mobile”, so we should just assume everything is a touch screen, and make controls easy to discover and manipulate.
• The benefits go beyond mobile. Going mobile first helps us create better desktop sites as well, because we remain focused on meeting core user needs and ensuring there is an easy and discoverable path through the flows. There is no room for cruft on smaller screens, and that makes our desktop designs better as well.
• It’s hard, but it’s worth it. As Ben Callahan points out in The Responsive Dip, “The fact that we don’t know how to do something today doesn’t mean we shouldn’t strive to do it tomorrow.” This is an amazing time. We get to be part of shaping the future of the web, because no one has it all figured out at the moment. I don’t know about you, but I want to be part of that, no matter how hard it is.

We have much maturing to do, but I’m excited about the progress we’ve made in shifting our entire process towards building responsive sites. Every project runs just a little bit smoother, and that’s encouraging. So my only advice to those standing on the edge of responsive design is this: jump in. The water is cold, but refreshing. And you’ll feel great when you get to the other side of the river.

Still encoding video with on-premise hardware? Encoding.com is the world’s fastest cloud encoding service. We’ve made proprietary optimizations for ingest, queue times, processing, and egress of your source content that rivals the fastest on-premise equipment, with infinite scalability.

We support nearly every video format imaginable, including a few that only we offer. We can accommodate a number of different transcoding workflows with an easy to use web interface, a flexible watch folder, a desktop uploader, or our robust and mature API. You can even automate basic editing tasks such as video overlays and concatenation programmatically using our API.

Vid.ly is a unique feature of our service that completely takes the guesswork out of your transcoding workflow, combining transcoding, device detection, delivery, and storage into a single short url.

Don’t take our word for it, try our forever free account today, complete with your own API key.

Sponsorship by The Syndicate.