My Instapaper feed looks a lot like my Steam account. I have gathered many items with the good intention of making use of them on a rainy day, but they eventually gather dust on their virtual shelves.

Occasionally I’ll try and blast through a set of articles that I considered at one point to have potential value to me. When I’m strapped for time I’ll try Instapaper’s “speak” feature, which is effectively a shortcut to iOS’ dictation feature. I usually end up cancelling the dictation after it reads a few paragraphs. Perhaps I forget how bad it is or maybe I’m expecting some advances in the technology since I last used it that make it sound more natural and human-like.

With AI being applied to more and more tasks, fields and entire industries I notice how far it falls short of key human traits such as empathy and storytelling, and empathy within storytelling for that matter. We have thousands of years of experience on the robots when it comes to communicating oral wisdom from campfires and passing ideas down through generations.

AI narration is improving, however, services like Narro offer bots with various dialects that have fairly accurate speech patterns and rhythm. But ultimately the narration ends up having a passive effect as AI hasn’t managed to emulate the human capability of captivating an audience to deliver a message. Robots rely on punctuation like a musical score to inform the pace at which they communicate text, though we lack punctuation for instinctive human storytelling tools like drama and the pause to allow certain ideas to simmer in the minds of the listener. This is why uninteresting speakers often fail to communicate their idea — the audience becomes disengaged from the message.

On a relevant note, another key human trait in storytelling is context. With a contextual understanding of the topic, humans know when to employ the storytelling tools mentioned previously. Consider this example from a recent opinion piece in the New York Times about the dangers of relying on Google rather than investing in deep understanding:

Google is good at finding information, but the brain beats it in two essential ways. Champions of Google underestimate how much the meaning of words and sentences changes with context. Consider vocabulary. Every teacher knows that a sixth grader, armed with a thesaurus, will often submit a paper studded with words used in not-quite-correct ways, like the student who looked up “meticulous,” saw it meant “very careful,” and wrote “I was meticulous when I fell off the cliff.”

From You Still Need Your Brain by Daniel T. Willingham

A classic example of schoolchildren discovering a tool like a thesaurus and employing the technology incorrectly. With AI dictation we are cutting out the middleman leaving it open for potential missteps like this not necessarily with words, but the in the power of those words.

P.S If you are looking for a startup idea, please feel free to design a subscription service with great human storytellers willing to read my Instapaper feed for me, thanks!

Looking back over the vast majority of user testing sessions I have conducted, I noticed a pattern in where I felt I got the most value from each individual session.

I’m talking about the moment where the room is silent and there’s that awkward pause where the user is struggling and everything in your being is telling you to help them. It’s the moment in the session when they’ve been struck by genuine confusion that causes a gap in the person articulating thoughts back to you as they move through the prototype. If you cave and give into your inherent human desire to help then you risk losing highly valuable insights. You’ll know that moment is happening because you’ll feel it in your gut. You’ll see the obvious on screen where the person sees something else. You’ll see it in their eyes and you’ll want to help by telling them the answer or even ask them something like “What did you expect to happen here?”

Exercise restraint and give that moment time to breathe.

Wait for the silence to become uncomfortable and then keep waiting. If you speak first, you lose. Whatever they say first will be an insight. Even if it’s simply “I’m stuck…” or an “I don’t know what to do here…” that gives you a foundation upon which to build a line of questioning to dig deeper. Or they’ll tell you the answer and it will be gold.

Another thing that I’ve noticed is that after that moment in the session it’s generally the point at which the person loosens up a bit more and talks more candidly about their thought process and becomes more openly critical about your work. For me, this is what defines a useful user testing session versus a session resulting in a blank page with a lack of insights. Otherwise, we could end up going through the motions in a session where you both know the person isn’t being entirely honest because they don’t want to offend people and you end up receiving low-quality feedback, or some of the feedback simply isn’t communicated because that barrier hasn’t been removed.

I believe it’s still important to lay the groundwork in making them feel at ease, like reassuring them that you didn’t design this thing and that it was the team back in the office (even though you totally designed it), and the fact that you’re helping us make this thing better (which is true) — it’s in that moment of awkwardness where they struggle and you exercise restraint — that’s where the real value lies.

Christian Bale famously lost 63lbs for the role of insomniac Trevor Reznik in Brad Anderson’s psychological thriller The Machinist. Bale’s disturbing body transformation happened over the course of 4 months during which he forced himself into a diet of a can of tuna and an apple per day, keeping himself isolated for prolonged periods of time and going without proper rest. His dedication to the role before filming even began is a common reference point for people describing method acting.

Method acting is a technique derived from Constantin Stanislavski, a Russian actor and theatre director who between 1911 and 1916 used a methodology to train actors in the quest for theatrical truth. In essence the goals of Stanislavski’s System were to portray actors on stage as natural, believable characters. To achieve these goals actors would rely on recalling emotional memories and past experiences to bring those feelings to the role they had to portray. Actors would also use “If” (often refered to as the “Magic If”) to answer the question “What would I do if I was in this situation?” by envisioning themselves in the characters situation.

Like Christian Bale, many actors in the film industry such as Anne Hathaway, Robert De Niro and Joaquin Pheonix employ the modern day interpretation of Stanislavski’s System — method acting. The method starts before filming giving the actor time to plan and prepare for the role leaving them better equipped to deliver a stronger performance during filming with a relatable, believable character.

Don’t think that I’m suggesting that we as designers for the Web take on extreme diets or the kind of psychological experimentation that could be potentially damaging without professional advice. I can’t help but admire the lengths method actors go to for their art. Perhaps we can learn from the emotional investment they make to a role before production begins. Isn’t that the whole point of UX research? We throw the word “empathy” around boardrooms and company about pages to show that we care about the people we are making the product for. To me, empathy has become an empty promise - a buzzword to appease potential clients.

To be truly empathetic I believe it involves going further than a few demographically informed personas that we assume are going to represent real people who use the things we make. Think about the project you’re working on now - how much of a difference would it make if you lived as the person you are making this for? How would they feel using the product? Where does it fit in their everyday lives? My hunch is that we would be able to make more well informed decisions that resonate with those people by diving right into the role, then we would have better tools to answer “What would I do if I was in this situation?”

There is no doubt that with this approach it can be emotionally taxing. There’s a balance and a scale in regards to how far you pursue it.

After filming of The Machinist wrapped up Christian Bale’s next role was Bruce Wayne in Batman Begins. He gained 100lbs in six months and started rigourously learning martial arts for the many tightly choreographed fight sequences in the film.

Before I made the leap I read blog articles of other freelancers who did the same. People like Stuart Robson, Chris Allwood, people who have made it work. I also called a lot of people - Chris Armstrong, Chris Murphy, Andrew Fulton - without their advice I probably would have talked myself out of it because before you actually do it your mind finds plenty of reasons not to do it.

To cut to the chase: it’s working for me too, and I want to give that reassurance to people are considering making a similar move that it can work for you.

I thought I’d start by discussing a few of the worries I had after I handed in my notice:

• What if there isn’t enough work out there?
• What about all that paperwork?
• Running my own business sounds scary

Firstly there is always work out there. This comes from a place of reassurance rather than any sort of attempt at bragging but my diary has been full since I began. I haven’t needed to advertise my services,apart from the initial announcement in March that I was going freelance. Since then I’ve found traditional word of mouth is still the most effective form of advertising.

The best way to let word of mouth do the work for you is to turn up every day and do the best job you can do. One of the biggest differences between agency and freelance work is that in an agency environment I would plan out how the next day or in some cases how the next week would look. Now that I work for myself I need to know what the next 3 months look like to ensure the pipeline is healthy and that I can continue to work for a variety of different people on different design problems.

Paperwork was strangely my biggest worry. I’ve never owned a business, I’ve produced invoices and estimates before in both of my previous agencies, but not for my own business. I worried that there might have been other paperwork that I hadn’t been exposed to before and that perhaps the amount of paperwork would have been overwhelming.

Luckily clever companies have been solving this problem. I bought a subscription to FreeAgent which handles my accounts including estimates, changing estimates into invoices, sending out invoice reminders, it keeps everything in check for things like tax returns and expenses. Without it, I’d be putting so much more time into this side of the business rather than concentrating on the fun, rewarding stuff.

One of the most exciting aspects of working for myself has been applying the knowledge I’ve gained after over 7 years of industry experience. I’ve learned from some great people like Paul May how could apply analytical thinking to design problems and could lead effective workshops with stakeholders and get the most out of people’s time. I’ve learned from Paul McKeever’s ability to find, create and deliver value for users and clients alike, and I’ve also borrowed heavily from Jamie Neely’s design theory and reasoning to ensure everything I make serves a purpose and fulfills a need.

By observing and working with great people, it’s easier to deliver great work.

The same is true today, if I take on a project where I know someone can specialise on a particular component, I have the flexibility to hire people in and apply their skills. Working with be best helps you keep performing to your best.

Aside from the work itself I have adapted to the freelance lifestyle pretty quickly. I have taken the time to study when I’m most productive and shape my working day around those hours. This means I know when I can do my best work rather than working within a set period of hours that the rest of a team works within.

That flexibility extends to the working environment. If I’m bored of working at my desk I can take my office with me to somewhere else like a coffee shop, or another studio, the library - wherever I want to work.

I’ve even worked a few evenings during my summer holidays - I wouldn’t recommend it for most people if you want to unwind, but I rather enjoy the novelty of working in a different country on the same projects I’ve been working on from home. It means the holidays themselves can be more flexible too - next year I’m considering working from the US for a couple of months and making the most of the school holidays with my family.

The last point I want to make is the most important factor in my decision to go freelance. I went from seeing my kids for 1-2 hours a day to being able to drop them to school, pick them up from school, attend sports days, I’ve been able to be there. That’s the kind of freedom that I enjoy most aside from all the other benefits. I can watch my young family grow up much more closely than I have before, and the best part is they don’t grow up so fast anymore because I’m there to see so more of it and spend time with them. It’s our most precious commodity and now I can shape my time to fit however I want rather than being told how to spend it.

I am delighted to announce that after 7 years working in web agencies I have decided to leave and start a new adventure as a freelance web designer.

Since I joined Front in 2008 midway through my final year of university, I have spent the last 7 years honing my craft specialising in responsive web design, user experience as well as front end and Expression Engine development. I believe that being part of the team with Front (now known as Typecast) and Eyekiller has equipped me with the skills required to manage my own destiny and seek new and exciting projects.

Working and collaborating closely with clients of all different shapes and sizes from various sectors including the BBC, Firefly and TextHelp and has been a truly invaluable experience. I’ll miss working with my fantastic clients - it has been a priviledge working together with each and every one of you to make useful, meaningful things for the web.

And of course I will miss working alongside the wonderful team at Eyekiller. I have made many friends since I joined in 2012. My last day is just under a month away on April 1st 2015. If you have any projects you would like to discuss with me, please feel free to get in touch!

I don’t usually keep my cards close my chest, but I was very excited about building a little web app to counter the recent, and in my opinion, misinformed talk of the importance of “the fold” in web pages.

Update

Iestyn Williams has made it happen at iamthefold.com!

I’m not going to get the opportunity to build this thing any time soon so please feel free to take the idea and run with it because I’d love to see it come to life rather than sink into the abyss of my Someday list.

The idea

A one page website that saves the height of the user’s viewport on page load to a database, draws a line at this value (in the form of an HTML element — a 1px high div will do) and that’s it.

The cool part is that it will show you the lines drawn by every user to have visited that page¹.

That’ll prove in a nice visual way if there is such a thing as the common fold, let’s leave it up to science!

Added fun

Feel free to ditch this part. I thought about a tongue in cheek Spartacus analogy calling the app “I am the Fold” with a searchable Twitter hashtag #iamthefold which would show a list of Tweets containing the user’s screen height and a link to the app.

It would be an effective way of demoing to clients and others that there is no such thing as a common page fold. The array of Tweets with different pixel values and the page itself with lines sporadically drawn depicting different viewport heights through the power of random will hopefully make the point.

So take it or leave it. I’m certainly not going to get a chance to make it happen any time soon and I’d feel bad letting the idea rot when it could be of some use to others.

There are few things on the Web that excite me more than a new HTML document its raw form and the possibilities it brings. In an unstyled HTML document the contents are laid bare for all to see. Out-of-the-box HTML comes with an established typographic hierarchy and elements are distinguishable like the different variations of lists that we seem to have a strange habit of resetting and stripping of the characteristics that make it a list.

The default styles for HTML are sensible defaults. The type is legible, the layout is functional — in fact it’s almost entirely responsive, with a few small tweaks it can be completely responsive.

I have shared a project on GitHub called Modern Default HTML. It’s nothing overly remarkable, nothing fancy and it didn’t take very long to make. But I felt the need to publish it to show the few changes necessary to make the default web page accessible on all devices. There are a few similar projects out there, but perhaps this is a more focused effort at addressing the initial tweaks necessary for a completely accessible starting point.

My project goals were simple:

• Stay true to the default and do the minimum required to make the default web page work anywhere
• Don’t impose any solutions to common design problems (and there are plenty like responsive tables for example — the same solution may not apply to all types of data)
• On a related note - there shouldn’t be anything in the default you will need to undo

I’ve been meditating on the idea that as designers we owe it to ourselves and anyone who comes into contact with the things we make that we stay as true to the sensible defaults as we possibly can within the typical constraints of a web project. The default web page is fast, functional and founded upon a clear typographic hierarchy. Any design decisions we make thereafter will either enhance this experience or tarnish it.

I’m asking myself more challenging questions in this mindset when designing even the smallest change: “Why is this better than the default?”, “What does this bring to the table?”, “Is this feature so critical to the goals of this page that the performance hit is necessary?”, “Does it break the default or is it loading a completely redundant asset?”

As designers we are in the position of power where we can both make and break the Web. We have a great foundation to work with by default, it’s up to us where we go with it.

Sometime during the last decade the web fell silent. There was a time when Flash-based websites with autoplaying background music were commonplace and the Internet felt like a lively, noisy place to be.

Fast forward to the present day and websites have turned quiet apart from certain media elements like video where the user can give explicit permission to play.

Whilst I believe this is better than websites that continuously sing at the user on an autoplaying loop, I think we maybe went too far in the condemnation of all forms of audio on the web.

Consider audio as component of the user interface for a moment: what’s wrong with using a sound like pips to represent hovering on menu options?

Advantages

• Potentially good for accessibility where blind and partially sighted users might struggle to see a hover state
• The sound could form part of the look and feel of the experience
• And additionally it can help with other facets of the experience like helping a user feel a sense of achievement after completing a task

Disadvantages

• The user is accustomed to a quiet web and the sound could come as an unwelcome shock
• From an accessibility standpoint - there would need to be some sort of standard to indicate hover states which could confuse blind and partially sighted users

When audio was mainstream on many websites it was during a time where volume controls were disconnected from the device - potentially hidden on part of a CRT monitor or detached on external speakers. This was likely a source of frustration where you would have to move from a comfortable position to turn down the volume. Today we are well accustomed to use devices with mute buttons when we don’t want our apps to make any noise - the same applies to desktop for the most part where mute buttons are part of the keyboard functions. Audio has a definitive off switch should the user choose to opt out of all audio, and I’d wager that most folks know that if they want their device to be quiet - they’ll put it in silent mode (or mute for laptops and desktops).

Why should apps get all the fun of satisfying interface chirps and clicks when flowing through the experience? What if the games industry decided to go quiet in regards to their main menu systems? Both industries are trying achieve the same goal: to facilitate the user in completing a task. The game and app industries have audio as an integral part of UX whereas our industry opted to avoid it in recent years.

I think we wrote off audio too soon.

I thought I’d elaborate on my testing strategy that I introduced during a talk I gave recently for Typecast’s seminar series. I described how I use two different testing methods for typography and responsive layouts.

Both are two very different facets of the same overall system and subsequently require different test conditions. In essence, I test typography on devices and I test layout in the browser.

Mobile devices aren’t great for layout testing

Device stands may look pretty on your desk, but they’re not going to cover all the possible states of a responsive layout. In fact, testing layouts purely on a set of devices is no different than designing for a set of predefined weights and heights — devices let you see how a layout will act at a particular size, but that’s the only size you’ll see on that screen¹.

This is why I do the majority of my layout testing in the browser. A browser will let you see all the in-between states that a set of devices won’t let you see. Expanding and collapsing the browser window from the small compressed state to an uncompressed wide state like an accordion allows you to see your elements actively respond and helps identify any potential gaps or problem areas.

Of course the actual device will show you the definitive state for that particular device - but what about every other permutation of the responsive layout?

The desktop browser helps paint the complete layout picture. No modern mobile browser gets the basic fundamentals of CSS layout so wrong that it requires you to refresh and investigate every layout change[^1].

Desktop browsers aren’t great for testing type

Where a desktop browser excels at showing you the difference in screen sizes, shapes and dimensions - it fails to account for the potential differences in type rendering between browsers and operating systems. A single browser window can only show you how type renders for that individual display and configuration.

The vast array of different mobile device displays requires a testing setup that caters for the variance in different screen densities, resolutions and screen types to give an indication of how type renders in these different environments.

An electronic ink display might render the type blurry compared to the display of a crisp high density screen. This is where a broad set of devices comes in handy - it pays to stress test your fonts across the often unforgiving and varied display properties of mobile devices. A single desktop browser won’t let you know about any of these potential issues.

The best of both worlds

I still reference mobile browsers during layout testing from time to time - functional testing is a different matter where I test heavily on all devices - but primarily my layout testing happens in the browser and my type testing happens on mobile displays.

The speed and efficiency of scaling a desktop browser window from small to large for building truly responsive layouts met with a set of devices that represent as much of the potential difference in display types is the sweet spot that works for me.

Emmet (formerly known as Zen Coding) is a plugin for text editors helping you create CSS and HTML faster by using abbreviations to write common values saving ridiculous amounts of time along the way.

There are heaps of really useful features alongside Emmet’s primary text-expanding function. Here are a few of the hidden gems that I frequently use when coding¹.

Inline Calculation

Emmet has a built-in calculator which allows you to solve equations directly in your code. I use this daily to solve EM values in CSS, particularly for nested EM values simply by pressing²Cmd Shift Y beside an equation like: 24/16 (desired pixel value/base pixel value).

You can also chain this with abbreviations, so typing: mb24/16 and pressing Cmd Shift Y then tab would output: margin-bottom: 1.5em.

Jump to Matching Pair

Sometimes when coding HTML I might find a closing tag and it’s not always quick and easy to trace back to where the opening tag exists. Pressing Ctrl Shift T when the cursor is in the closing (or opening) tag jumps to the opening (or closing) tag pair.

Code comments

To prevent running into the situation in the previous tip, I recommend placing comments beside your closing tags. But writing the class name of the element for a second time and wrapping it in comments can take up time, and it’s extra effort that won’t be beneficial until you run into scenarios where you need to revisit that code, so it’s often forgotten about or left out completely.

Thankfully Emmet makes it easier to write comments beneath closing tags by adding a tiny snippet to the end of an abbreviation. Typing: .container>ul>li*5>a|c expands to:

<div class="container">
    <ul>
        <li><a href=""></a></li>
        <li><a href=""></a></li>
        <li><a href=""></a></li>
        <li><a href=""></a></li>
        <li><a href=""></a></li>
    </ul>
</div>
<!-- /.container -->

So writing comments where elements close is as easy as writing |c.

Convert image to Data URI

One of the most underused features of Emmet is it’s built-in ability to convert images to data:URI schemes. Using a data:URI instead of linking to an external image saves an extra HTTP request which ultimately improves the performance of your site by reducing latency.

To convert an image to a data:URI, place your cursor in the image tag and press Ctrl Shift D.

Emmet can be as powerful as you want it to be. It’s worth using for its text-expansion capabilities alone saving huge amounts of coding time, but beyond that lies a very powerful suite of development tools.