Jordan Moore - Web Designer & Front End Developer

Thoughts and opinion on responsive web design from Jordan Moore, a content choreographer and maker for the web.

[jordanmoore]

I am the Fold

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 page1.

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.

If it becomes a performance concern I had considering capping this at the last 100 or 200 users. ↩︎

[jordanmoore]

A Modern Default

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.

[jordanmoore]

The web designer's holiday gift guide 2014

Tilde by Jessica Hische (from $20 per year)

Jessica's attention to detail is evident in those beautiful in-between details

A stunning new typeface that looks effortless but is full of gorgeous subtle flourishes in its ligatures and strokes. It comes in two sizes for small and large uses helping maintain its delicate quality wherever you use it.

Available from Webtype

Sketch 3 ($99)

2014 has been the year of Sketch. Most folks I know have ditched other graphics editors in favour of Bohemian Coding's contender. Sketch is great for easily exporting resolution independent assets, constructing styleguides, establishing typographic systems - you name it.

The infinite canvas approach helps keep your broad vision for your project in check — and the ability to create symbols will save you heaps of time if you need to adjust shared elements across a number of layouts.

Available from Bohemian Coding

Kano ($149)

Creativity out of the box — build the hardware, build the software — Kano is a great learning tool

After watching Alex Klein speak at Break Conference in Belfast earlier this month I was completely astounded by what his company achieved with the Kano project. It started life as a humble Raspberry Pi and became a set of easy-to-assemble components that slot together to make a computer that teaches you how to code. The best part is - it's great for kids and adults alike.

Available from Kano

Responsible Responsive Design by Scott Jehl (from $9)

Scott Jehl's new book is a great addition to the A Book Apart library. He takes a look at the next level of responsive design as a practice: speed, overcoming performance issues on troublesome networks and delivering appropriate assets across the vast array of different platforms and conditions we face.

Available from A Book Apart

Responsive Sketch Pad ($16)

I try not to take the "screens" too seriously – the boxed areas are enough for me to figure out how elements work in a given space

I use my Responsive Sketch Pad pretty much every day. Its great for quickly drawing components in a narrow column and figuring out how they translate to larger spaces. Apparently it works well with UI Stencil's pixel ruler — I didn't realise such a thing existed!

Available from UI Stencils

Invision App (Free with paid plans starting from $15 per month)

I'll have to confess that I have only started using Invision App picked up recently, but already the benefits are obvious and it feels like the missing link that holds the whole design and development process together.

From keeping designers and developers singing from the same hymnsheet, to fostering design feedback discussion and iterations — Invision has you covered.

Available from Invision

Typecast (from $19 per month)

Typecast is the best tool for creating beautiful and usable typography for the web. It saves scouring the many different web font services available by bringing them together in a unified font selection UI. Typecast allows you to easily set your vertical rhythm, change properties over different media queries, play with font feature settings — everything you could imagine doing with web type can be done in the app.

Available from Typecast or free with a fonts.com account

The Great Discontent, Issue One ($30)

Weighing in at an impressive 272 pages on high quality paper, it's the perfect desk companion for a healthy dose of inspiration

I have been a fan of Ryan and Tina Essmaker's The Great Discontent for quite some time now — in fact, it has been my go-to example of responsive web design when I'm explaining it to clients. The inspiring interviews from the series come to life in high quality print with design and art direction from Frank Chimero.

Available from The Great Discontent

[jordanmoore]

A silent web

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.

[jordanmoore]

How I test type and layout

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 screen1.

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 change1.

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.

Apart from different orientations if the device allows it. ↩︎ ↩︎

[jordanmoore]

Emmet's hidden power features

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 coding1.

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 pressing2 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.

This article assumes you are familiar with Emmet. If you haven't tried it out yet you absolutely must. ↩︎

The keyboard shortcuts shown here work for my Mac installation of Sublime Text and Emmet. From what I can tell they may differ between installations, Windows installs will obviously have different shortcuts too. Bring up the Go To Anything menu and start typing the name of the command you wish to use to see the shortcut key. ↩︎

[jordanmoore]

SVG's missing killer feature

SVG has all the attributes for becoming the responsive web's image format of choice. Built for scalability SVG is inherently resolution independent. You'd think it would be omnipresent in websites existing after the introduction of responsive web design in 2010. It isn't.

So why don't we use SVG? Why sidestep it in favour of a raster image inflated to double its intended display size? SVG lacks a killer feature that is present in JPG, PNG and GIF: convenience.

Graphics editing packages such as Photoshop treat SVG as an edge case. You can export SVGs from such applications but in an inconvenient, hacky way known only to some in the darkest corners of StackOverflow. Some of these "solutions" involve stripping the scalability out of the format to ensure it plays nicely in Photoshop’s restrictive parameters. In addition to that, my experience of patching that behaviour into applications has produced SVGs with varied results.

The recommended route would be to close Photoshop and open an alternative package that allows you to easily import and export SVGs like Inkscape or Adobe Illustrator, but it would be foolish to think that these applications have been ingrained into web design culture at this stage.

Making an SVG shouldn't feel like going beyond the call of duty, nor should it require patching functionality into our current software. Perhaps when the big decision makers in hardware roll out even higher density displays beyond double density then it might expose the pixelated shortcomings of icons and other web assets built using oversized raster images. Maybe then we’ll see that the benefits of SVG outweigh the cost and convenience makes way for necessity.

[jordanmoore]

Ixnay on the uckfay

Being a dad to 3 young kids under the age of 4 has taught me plenty of valuable lessons in such a short space of time. It has affected my everyday behaviour too. Just over a year ago, my son started going through the developmental phase in his life where he was repeating every single word he heard. Every. Damn. Word.

As a result, I have cleaned up my language when I'm home and in their company. A stubbed toe off the fireplace is no longer accompanied by a loud f-word, it's usually followed by an animated "Ouch!" or a "Fff-ouch!" in some particularly painful instances.

Having kids has made me more aware of when I turn the air blue. Now when I swear it's followed by a reflex reaction of guilt "Did the kids hear that?" and then I usually think "That was unnecessary." During some stressful occasions when the kids aren't present there are times where I feel "That f-bomb was entirely necessary and justified. I feel better after that."

If you've read my writing before, you'll notice that I rarely swear. This is a conscious decision for two reasons:

I treat my writing as if it's a talk. Most of the time I don't think it's appropriate to swear on front of my audience - particularly on the web where my audience could be young aspiring designers — it could be anybody

Picking up on that point, I don't mean that in a patronising way at all. In fact, I'd bet a lot of young designers aren't offended by a few swear words here and there. However web filters in educational institutions as well as parental controls in family homes take great offence to swearing.

I wanted to title this post "Watch your fucking mouth". It's an ironic quote from Nicholas Cage in the ridiculously fun action-thriller Face Off. It's my favourite line from the movie and it would have been an edgy, ironic title and it might have made a few people laugh along the way.

The problem is a URL like http://www.jordanm.co.uk/post/01234567/watch-your-fucking-mouth wouldn't stand a chance against a web filter. Some web filters might even block my domain from future browsing sessions. I'd hate to think that my content was being blocked because of something completely within my control and preventable. For me accessibility comes first and if some users can't even access my domain then that's an accessibility fail at the first hurdle.

Most web filters look for blacklisted words, search terms and URLs. Some offer real-time content filtering which means they probably have the capability to scrape your page for profanity and block it from the reader if they are accessing your page from a filtered network.

My good friend Chris Armstrong suggested the potential for new semantics that might allow the user to hide profanity and still enjoy the content.

@jordanmoore it does raise a question around accessibility actually…what if there was a <swear> tag, that a user could show/hide in browser?

— Chris Armstrong (@Armstrong) January 30, 2014

To me this underlines the superfluous nature of foul language in web writing. If the content reads fluently with inline elements removed then is there any need for it in the first place? I also doubt the willingness of content authors to go back over their content and take that extra step of wrapping their swear words in a tag. On the other hand if it was to prove a success then encouraging people to proofread and question the value around such words then I think that's a good thing.

At it's worst foul language is used to give weight to a weak point that requires extra leverage. For example:

"In a lot of cases it isn't necessary to support IE7."

A pretty weak and obvious statement, right? How about:

"Fuck IE7, we need to stop supporting it."

All of a sudden, a weak statement has a certain air of gravitas about it. It's the same concept, just delivered differently. It's an easy way of making something sound more compelling than it actually is.

Now let me make this clear: I am not anti-swearing, nor am I telling people not to swear. You are your own person and you should feel to write whatever you like. I'm not even anti-swearing on the web because one of my favourite posts, Fuck You by Brad Frost, contains a fair amount of it, but it forms the crux of the issue he is pointing out and hey, it works really well. It strikes a chord instead of feeling forced.

My point is to think about your audience. Web and parental filters are barriers that we don't talk about very much. When they scour the web like sniffer dogs seeking to censor parts of the web I'd rather not draw their attention to the scent.

[jordanmoore]

View full site - the worst anti-pattern

The “view full site” link has fostered a negative behavioural trait. When faced with problems on a dedicated mobile site users have a tendency to look for the full site link like some sort of safety net.

How often have you arrived on a broken link on a dedicated mobile site from a search engine and looked for the full site link in an attempt to solve the problem? It’s instinctive among web savvy people, but I have witnessed people outside of our industry perform the same behavioural trait in a similar unconscious manner.

The sad truth is “view full site” can also be used by web developers as a safety net if the small screen experience isn’t good enough. The pinch-to-zoom fallback is there when a poor implementation fails and lazy web developers capitalise on the user’s newfound habits of correcting such website issues by clicking this magical link.

This leaves responsive designers in a difficult position. We are already on the back foot when the user arrives at our lovingly tailored responsive experience — we have to convince the user that our responsive design is the full experience after years of being misled to think they are getting half a product by dedicated mobile sites overzealous in removing content and stripping back features

Part of the problem is that from the average user’s perspective a dedicated mobile site may not look too different to a responsive site on the surface. If they run into problems with our design or perhaps they expected to see some content that is missing because it was simply overlooked, do they feel misled by default?

So how do we fix this problem? By continuing to fight the good fight with ubiquitous experiences and earning back the user’s trust over time — it’s not going to be a quick fix. Bad habits take time to eradicate. The great content swindle needs to stop.

[jordanmoore]

How I built Tickertape (aka fixing the shortcomings of the typical email newsletter)

I'm not going to make any grand statements like "newsletters are broken", newsletters are still a great way of bringing content to the reader rather than asking the reader to come to the content; and that's a powerful thing when RSS usage is dwindling. When I built Tickertape, I wanted to fix a few things about how newsletters are both presented and read by their readers.

The design objectives for Tickertape are as follows:

Quality

Relevance

Slow

Quality

Only quality writing and resources should feature in Tickertape. Each digest aims to have around 5 links, but this target is flexible — it has to be. Quality content will never be compromised in favour of filling a link quota. If another Tickertape issue is ready for release but it contains only 2 or 3 quality links then that's absolutely fine.

Traditional industry publications typically have a daily, weekly, bi-weekly or monthly schedule, Tickertape doesn't. It's a frequent publication. The content dictates the publication date rather than the schedule - otherwise quality suffers to meet a release date.

Relevance

Tickertape is all about relevant content. The links are ordered by date from newest to oldest — some might be as recent as today, some might be yesterday — just relevant, informative content from the best authors on the web.

Usually industry newsletters provide relevant content, I wanted to build on that with Tickertape. The dates are published in a relative format to help you quickly identify recent content.

In compatible email clients, you can quickly identify the items you have already read on the web

Compatible email clients take relevance a step further. Items you have already read appear different to items you haven't read. The articles you have already read before the issue arrives in your inbox appear in a dimmed grey in contrast to new content. This helps you quickly see how relevant the current issue is to you. Whether the items are all exciting new content you haven't read, or if it's content you can quickly tell if you've already read then Tickertape has done it's job in letting you decide if you want to read or not and get on with your day. It's disposable in the best sense of the word.

Slow

Personally this is my favourite feature. "Slow" is generally considered to be a bad thing on the web — I think we can embrace "slow" as a benefit and use it effectively.

Think about the typical email newsletter — does it always arrive at a convenient time where you are ready to read it? Probably not. There are many occasions where I have opened an email, scanned the contents and thought — I'll read that later, only never to return to the email.

Sometimes marking it as unread is enough of an indicator to come back to it, but sometimes your initial guess of where and when later might be mightn't correlate with your current situation.

Imagine a scenario where I open a newsletter in the morning before work. I mark it as unread to come back to it later this evening when I have a few hours to spare only to find that later that day I ended up resting and avoiding emails. This is a common situation and Tickertape approaches the problem differently.

You can read the current issue of Tickertape later by sending it to your Kindle, Readmill account or iBooks. Read on your schedule rather than the publication's schedule

Tickertape allows you to send the articles from the current issue to Readmill, iBooks or your Kindle1 meaning you can pick up the current issue of Tickertape when it's convenient for you to do so. No marking as unread, flagging or tagging.

Newsletters have become comfortable with their current format. Tickertape reimagines how we use email content with quality, relevant and timely content.

You can receive Tickertape by becoming a member and supporting this site along with many other benefits.

Thanks to the power of Readlists from Readability and Arc90. ↩︎

[jordanmoore]

The Web Designer's Holiday Gift Guide 2013

Now for something a little different. With Christmas around the corner I thought I’d share a collection of great gift ideas for your fellow web designer.

Pencil from $49.95

Fifty Three are best known for their impeccably designed and critically acclaimed Paper app for iPad. Now Paper has a hardware companion — Pencil. The milled, graphite brushed aluminium finish provides a good grip that compliments the carpenter pencil form and the eraser on the opposite end of the point does exactly as you’d expect in the app.

Available from Fifty Three

Slate from $98

This is a really neat idea. Slate is a portable desk that houses your laptop and a mobile device on your lap whilst providing you with space to take notes or even use a mouse. The holes beneath the space for your laptop helps keep your legs and your computer cool.

Available on Kickstarter

Device Lab stand $149

A must for the responsive web designer. This device stand from Vanamco houses up to 6 devices leaving a gutter for USB and charging cables.

Available from Vanamco

UINK.it Stamp from $35

Sketches are an interface designer’s best friend. They’re quick and easy to produce — devices however are not. When producing mobile UIs it helps to frame them but this takes away a lot of the flow and spontaneity that sketching brings. UINK.it solves that allowing you to stamp device templates anywhere you want.

Available on Kickstarter

Platinum Pro-Use I 03 Drafting Pencil $16.50

Those wireframes aren’t going to draw themselves. This exquisite drafting pencil produces the perfect weight for fast wireframe production.

Available from JetPens

Gridbooks Web Book $24

Gridbooks produce high quality notebooks for wireframing. Their Web Book features a 15-point dot grid that divides vertically into two, three, four, five and six columns with horizontal grids that can adapt to two, three, four, six, eight, twelve and sixteen columns. The opposing page features space for notes like objectives and goals to help keep you focused and produce great looking wireframes ready for sign-off.

Available from Gridbooks

Get Mental Notes Sold Out

Mental Notes are a set of 50 cards designed as both reference and brainstorming tool for psychological design. The first set of 5000 cards went in a flash, so make sure to get notified of when new batches arrive so you don’t miss out.

Available from Get Mental Notes

Five Simple Steps Pocket Guides £19

Five Simple Steps’ popular Pocket Guides series have made the transition from digital to physical format seamlessly. The first set of books features works from The Standardistas, Brian Suda, Rachel Andrew and Joe Leech. You’ll also receive the digital editions when you buy the paperback versions.

Available from Five Simple Steps

Cloud Typography subscription $99

The quality of Hoefler & Frere-Jones’ typefaces speak for themselves. Their long awaited web fonts service arrived earlier this year and the time taken to port their elegant library for the web shows in their ScreenSmart fonts. With packages starting from $99 per year it’s easy on the wallet too.

Available from Hoefler & Frere-Jones

[jordanmoore]

What we can learn from game designers

After watching Indie Game: The Movie during Channel 4’s video games night I couldn’t help but notice the parallels between game design and web design. There are elements of this that I have noticed before, but I thought I’d share some of the facets of video games that aren’t spoken about so often in relation to our industry.

Note that this isn’t a discussion about gamification, rather a look at how game design applies to the web.

Video games are usability success stories

Pong is perhaps one of the greatest examples of usability for a digital product. The original Pong arcade box featured two knobs. A knob on one side of the box for player one and one on the other side for player two. Twisting the knob on the either side moved the corresponding on screen paddle up and down.

The box had no instructions. The player was left to learn the behaviour and play.

The original Pong machine deserves credit for being a usability success

More complex games that require extra behaviours to progress (let’s use Tomb Raider as an example) produce scenarios where environmental situations encourage you to recall certain behaviours, perform the input combination on the controller to trigger the behaviour and progress. In fact most games are essentially sequences of pattern recognition.

One of the most enjoyable facets of gaming is when the player is in a state of flow1 and they perform the actions almost instinctively. The game then feels more rewarding to play because the player is progressing at the ideal pacing and feels more at one with the game when difficulty level and ability level are in perfect synergy.

In Tomb Raider the player quickly learns to apply input combinations in relation to environmental features. Some ledges require a running jump rather than a regular jump to progress to the next area

Repetition plays a key role in establishing these actions in the user’s mind. If you strip the surface texture graphics and reduce the polygon count in Tomb Raider, you would notice that the environments would look quite similar in that they can all be traversed using the same character behaviours but in varied and more challenging ways — the foundations remain the same from the first level through to the end.

There are many lessons we can learn from how games are designed and built and apply the findings to the web. Input combinations that trigger specific actions could appear in the form of gestures or even as part of a visual language. Think about how games teach you to subconsciously perform such actions using techniques like pacing and repetition to help engrain them in the user’s intuition.

You might think that kind of thinking could lead to a deviation from established web design patterns” - it all depends on the implementation. Imagine a first person shooter that didn’t bind the fire action to the right shoulder button on a controller or the left mouse button and instead required you to press a button like ’x’. It would be infuriating because it simply doesn’t feel right. Design patterns occur in games too, they’re just sometimes hard to spot because they almost feel like second nature — which is a very good thing.

Storytelling and narratives

We can learn a lot from point-and-click adventure games. Not even in regards to the nature of the input for the genre — my favourite point-and-click adventure was Grim Fandango which was labelled a point-and-click adventure even though it was controlled entirely by keyboard — I’m talking about how they are structured in terms of their narratives.

All good stories have a beginning, a middle and an end. Point-and-click adventures are (mostly) linear stories made up of sequences that require item collection and puzzle solving to advance to the next sequence. The difference between the web and point-and-click adventures is that the latter wants you to struggle to advance, but not too much. In most cases on the web, that’s not what we want to do, but there are certainly elements from this genre that we can learn from and apply to the web. Adventure games are trying to funnel the user down the linear story without leaving you completely stuck, otherwise the user is less likely to feel compelled to finish the game. It’s the in-between bits that hold this narrative flow together that interests me the most — when the player starts to struggle the game has a job on its hands to keep the player interested and help them back into the narrative so the game can tell its story.

Characters respond to changes in the dynamics of the game. If you are looking for a specific item to proceed to the next sequence and you’re having a hard time doing so, some specific characters will become aware of the situation at hand and perhaps provide help or hints when spoken to.

In Grim Fandango speaking to characters you have already met can often provide clues as to how to proceed to the next sequence

This sense of situational awareness can apply to the web too. As a user progresses through our own narrative, situational awareness can help the user progress to the next scene. Imagine a user adds an item to their cart in an e-commerce website — the dynamics of the situation have changed from when the user began on their journey and we can help them through to the end of the story. Perhaps the user digresses from the shop after deciding to read a rather interesting article on the store’s blog about how the store has been donating a portion of profits to charity. What if the blog post had a helpful block at the end to inform the user of the change in dynamics? Something to the effect of: “And you can help us donate too by buying that t-shirt in your cart. Would you like to do that now?”

Games speak to the players in plain English. No technical jargon like “Your session has expired” — something informative, clear and to the point, but not abrupt and not too long so that it wastes time either. Narrative content is hard.

We really should listen to video game designers and developers a lot more. I would love to see people like Raph Koster speak at web design conferences and talk about flow theory, establishing core gameplay and environmental mechanics and the similar challenges we face in both industries. When it comes to telling compelling stories and teaching users to perform instinctual reactions to scenarios, the games industry has been doing this for a long time and have left a lot of good examples for us to learn from.

http://www.ccs.neu.edu/home/lieber/courses/cs4500/sp09/resources/p31-chen-flow-in-games.pdf ↩

[jordanmoore]

My Design Principles

In the interest of openness I thought I’d share my set of design principles that I have been experimenting with for the last few weeks. They serve as a guide for design decisions and help me focus on good, honest values when making products for real people.

I’ll run through each principle individually below expanding on its meaning. Some have been borrowed and tweaked from elsewhere and noted in the footnotes.

Start with needs

A product should be useful. To be useful it needs to serve a specific need or a set of needs. The needs belong to the user and no-one else1. We need to know what the user needs through and through otherwise we’re making a product nobody wants.

Think impossible

To serve needs in the most efficient manner, the solution must be visualised clearly without obstruction. Obstruction may come in the form of the proposed platform for the product — it’s best to think without the distraction of how you’re going to solve the problem, rather think in terms of the impossible — how would it work if it worked like magic?

Design from the content out2

A design without content is, at best, a guess. It’s a guess at how it should look, how it should function, how it should feel. One big assumption. The content informs the design and the overall shape of the product. Preconceived notions of how a website should look must be ignored and trust placed in the content to lead the decision making. Content is an absolute which holds value to the user and must be treated with such esteem rather than being regarded as a commodity.

Keep it simple

A simple product is more likely to be easier to use and rarely has complex problems to fix. Why design something complex? Superfluous design is nothing but exercise for the ego. Simple design is clear, useful and honest.

Accessible

In every sense of the word. From screen readers to Kindles. IE7 to Chrome Canary. A simple product shouldn’t have to bend and break to work everywhere.

Future-Friendly

Take a device agnostic approach to delivering an experience that works where the web works for past, present and future devices, interfaces and scenarios. The best way to achieve this is by staying true to the nature of the web.

Do less

Where time and budget are fixed, scope needs to flex or else quality suffers3. Less important features can wait for another day, priority features shouldn’t be compromised for the sake of shipping with all features. It’s better to do one thing well.

Make useful things

The finished product should be useful, otherwise design hasn’t achieved anything — it’s solving imaginary problems. A useful product solves real problems for real people.

Make remarkable things

The finished product should resonate with people and touch their lives in a positive, meaningful way.

https://www.gov.uk/designprinciples#first ↩

http://www.markboulton.co.uk/journal/a-richer-canvas ↩

http://gettingreal.37signals.com ↩

[jordanmoore]

Book Review: The Smashing Book 4

Having authored work for Smashing Magazine in the past I know this for sure: they care a great deal about the quality of their content. They have an entire editorial team dedicated to scrutinising every word and every technical claim by contributors to their publication — which is an amazing thing because it is reflected in the high quality writing consumed by thousands every day.

Like its predecessors The Smashing Book 4 is wonderfully constructed and illustrated

Their book series is an extension of this quality going beyond the screen in the form of a beautifully presented collection of work from some of the web’s greatest thinkers. The Smashing Book 4: New Perspectives on Web Design is 480 pages long and geared towards the intermediate web designer (or developer). I felt right at home when I settled into the contents. The theme that runs throughout is the idea of looking at things from a new perspective.

This is evident in chapters from very qualified thinkers and doers like Harry Roberts. In his chapter on Modern CSS Architecture and Front-End Development Harry details the considerations for planning for today’s more complex web.

The book covers themes that fit a mature web. Nicholas Zakas' chapter on writing and maintaining future-friendly code is littered with useful takeaways. It's easy to get stuck in our web development bubble and write code simply to get things done — Nicholas reminds us the importance of communication and that our code is meant to be read by humans as well as computers.

Addy Osmani's chapter on finding and fixing mobile web rendering issues is another example of the level of detail each chapter covers. He covers everything from achieving the magical 60fps refresh rate for animations to paint and layout problems. The book really takes the themes from The Smashing Book 3 and evolves them to address the real everyday issues that arise from advancing our fundamental knowledge of topics like responsive web design, performance and typography.

Corey Vilhauer and Nishant Kothary's chapters deal with designing for the needs of real people — editors and users alike. Nishant delves into the psychology and behavioural patterns of stakeholders with useful, palpable advice on design reviews and achieving sign-off.

The closing chapter of the book sees my friend and mentor Christopher Murphy produce a rousing piece about creative spirit. Chris use his experience of educating in the field of web design (which I have had the privilege of experiencing first-hand) and dissects James Webb Young’s technique for producing ideas from 1965, expanding the key themes effortlessly which in turn results in an inventory for idea generation.

The Smashing Book 4 is excellent value for money. Imagine if the stellar line-up of authors and their valuable, relevant topics were presenting their work at a web conference — you would expect to pay at at least £250 for entry, a variable amount for travel depending on where you live and other living expenses for the duration of the conference. The Smashing Book 4 is conference quality topics in the palm of your hand, permanently committed to paper (or the medium of your choice) ready for you to consume whenever you want.

The web has grown up and The Smashing Book 4 is the perfect field guide for making and maintaining things for a future-friendly web.

[jordanmoore]

A concept for a better web design tool

Our tools are antisocial. They don't talk to each other very much, or very well, or at all most of the time. One tool does the editing, one does the uploading and another lets you see the result on the web. Some tools are negotiators, like CodeKit. They try to help everyone get along by becoming the invisible glue holding the whole operation together.

I can live with some of this friction. I feel it most between browser and code editor though. Considering the code editor makes the stuff you see in the browser it's funny how they barely speak to each other if at all in most cases.

What if Sublime Text1 had a detachable browser window docked on the side? Not only could that being browser and editor closer by visual proximity but imagine if it unlocked new capabilities that allowed them to talk to each other...

Realtime design in the browser

Style injections that allow you to see instant results and automatic page reloading for markup changes is one of the biggest time savers an application such as this could offer. We have already patched this behaviour with our negotiators like LiveReload and CodeKit, but if it worked straight out of the box with a hybrid browser and editor tool it would reload more reliably (i.e after CSS is preprocessed — I have had frustrating run-ins with compilers that can jump the gun).

I believe any CSS changes should be immediately reflected in the docked browser window without the need for saving the file in a way that doesn't destruct the page — that would require a bit of intelligent logic when creating new style rules in the middle of a Stylesheet to assume a closing brace.

It should preprocess LESS and Sass files too and while we’re theorising — it should have the capability of doing that beyond the local environment (e.g over FTP).

This is an area our negotiators have mostly covered so it's not the biggest pain point of web development.

Inspect Element in Editor

Right clicking in the browser and inspecting element should bring you to the appropriate line in CSS inside the editor itself.

This is one of the biggest problems in web development workflows. The current behaviour allows you to inspect and make adjustments in the browser. While this is a good thing the boost in productivity is lost when you have to retrace your steps, copy and paste your code, save, reload, realise you didn't retrieve all of your inspector changes, despair, recreate them again in the browser, meticulously retrieve your changes this time causing your workflow to slow to a snails pace and watch the perceived benefits of in-browser editing vaporise before your eyes, copy and paste your code into your editor, save, hesitate, hesitate a little more, then decide to open a new browser tab and leave the tab containing your ideal design state the hell alone, load the URL, and hope that it works.

This isn't how it should be.

By bringing browser and editor together, the disconnect between both entities is non-existent and the issue with the workflow above is vanquished. No more copying and pasting and retrieving edits lost in code.

There are a couple of potential limitations: why favour CSS over DOM inspection when inspecting elements? I don't necessarily think it should. Perhaps when an editor tab is open containing markup, inspect element should find the selected element in the markup and a shortcut key could help you cycle through other areas that it affects in CSS. This shortcut would also help solve the problem of navigating multiple CSS rules. Sublime Text’s minimap could become a temporary space during source inspection to show the affected areas in CSS and HTML, line numbers, file names and provide a visual shortcut to where we might want to go. Maybe even some quick edit abilities like Adobe Brackets would be useful in this space.

Milestones

You’d think live editing would bring big changes to how we save work - it shouldn't. Live edits, like editing in browser inspection tools, are only committed to code when saved in the editor. So if you change a page through the live editor and close without saving, your changes wouldn't appear next time you loaded the project - which is exactly the way it should be.

One of my other gripes about current web development tools is that it's difficult to roll back to a safe state. If you are working on a project and you make some heavy changes that mess up the code and design it's a Cmd-Z marathon to find the last safe and stable state.

Milestones would help solve this problem. It's a feature already present in Espresso and it's super-useful. Before making major changes you could press a different hotkey instead of Cmd-S to save a milestone. You could optionally name the milestone and continue to make the major code changes knowing there is a saved state you could quickly roll back to if it all goes wrong.

Browsers

For the browser element of this editor to be a true web design tool, it should allow you to switch between Trident, Gecko and Webkit2 rendering engines. The context menu shouldn't change in each rendering engine, you should be allowed to inspect element and see the affected code in each browser to quickly diagnose layout issues and make changes in the code editor.

There have been attempts by integrated development environments to accomplish some of the concepts above, but no existing solution has truly met each pain point satisfyingly. I'm not a programmer so I don't know how feasible it is to accomplish each point, all I know is as a front end developer at the coalface these problems begin to grate on you after a while and it needs fixed.

Insert your favourite code editor here. ↩︎

AKA Internet Explorer, Firefox and Chrome. I think that they should keep their rendering engine name so people know the technology behind the branded browsers as well as to cover potential issues that browser vendors might have building their browser into a hybrid browser and code editor. ↩︎

[jordanmoore]

Start from impossible

Knowledge is a gift. Having a few years of experience in the web industry under my belt there are plenty of opportunities for prior knowledge to solve design problems. But knowledge comes with baggage. Knowledge stifles potential.

When approached with a design problem we have a tendency to try and solve the problem through the knowledge of our platform before writing a single line of code or painting a single pixel. We think about the restrictions and limitations that come with our platform and try to fit a solution to these requirements.

The problem is that this complicates the solution before we have even started. The solution has already been hindered by our understanding of the intended platform.

I had the privilege of working with Paul May for two years at the company now known as Typecast. Paul is a very talented interaction designer. He taught me to start from impossible.

Starting from impossible means worrying about the details later. This helps you work with an unclouded view and see the solution more clearly.

Hailo is a common example of the importance of starting from impossible. The design problem was clear: hailing a taxi sucks. The success rate varies, sometimes you need to call the cab office and tell them where you are, sometimes it's not even obvious where you are, sometimes the taxi driver gets lost on their way to pick you up, it's hard to know how long it'll be before you can get a taxi — it has the potential to become a whole host of frustrating problems.

I imagine the conversations at Hailo started from impossible: "If getting a cab worked like magic, how would it work?"

In the impossible scenario the taxi would know when you needed it and just appear wherever you are standing to take you where you wanted to go as if by magic. This is the solution to the design problem staring you right in the face! It's important not to lose sight of it as you introduce real world limitations.

In Hailo's case, their limitation was the platform and the device. How was the device to know the thoughts of the person who needed a taxi? The person could press a button to tell the device that they needed a taxi. How would the taxi know the person needed a ride? The taxi would have a communicator that could tell that the person pressed a button on their device. How would the person know that the taxi received their request and wants to pick them up? The taxi driver could also press a button telling the person's device that they are on the way.

So in essence the design solution is an app with a "Pick me up" button and a confirmation message to tell them their taxi is on the way. It's a beautifully simple solution to a frustrating problem. The user doesn't need to worry about the communications between the device and the taxi, or about how the taxi uses the device's location sensors to know where to pick them up. They just need to worry about pushing a button when they need a ride.

By removing the restrictions and the limitations that prior knowledge imposes on your thinking, imagining the impossible helps you to see the solution more clearly.

[jordanmoore]

A Browser is a Phoney Phone

The Chrome development team proudly announced that they addressed one of the most common complaints from responsive designers about their browser - Chrome now let's you resize your browser down to 320 pixels wide1.

While it's nice to resize down to the width of some popular mobile device screen widths it reminded me of some of the issues with relying on resizing a browser to test responsive designs.

Limitations with testing in a desktop browser:

Not all devices have screens that are 320 pixels wide and larger

Doesn't account for different pixel densities

You can't touch it (well, you can but it won't react)

Can't reliably re-create touch-based gestures

Not every mobile browser runs on the same browser your are testing with

Not every layout problem you fix in a desktop browser is guaranteed to fix a layout problem on a real device

An unobscured desktop display gives an unrealistic impression of how your hand might grip a mobile device and obscure parts of the design

It doesn't account for external factors like the shape and form of the device

A mouse pointer is more accurate than a finger

A desktop can't account for the variance in mobile network speeds (you can fake a constant state but not the variance)

A desktop is hard to test in potential mobile contexts (in the sun, in the shade, in noisy environments, in quiet environments etc)

Proprietary software functions (like pinch to zoom) can't be reliably emulated in desktop browsers

Doesn't account for other operating system factors like the limited system fonts on Android devices

There are more reasons, these are just the ones that spring to mind first. I'm not saying you should stay away from desktop browsers altogether for responsive design testing, in fact I find a narrow browser window a great foundation for making a start on responsive layouts — it's part of my workflow.

Generally I find that using a desktop browser is good for quick layout tests — for example if something is badly broken it might be quickest to diagnose on a desktop browser, fix and test on real devices. It's quick, it allows for page source inspection — it would be foolish not to make use of these tools.

The point I'm making is that there are testing limitations that you wouldn't face with a suite of real devices2.

If you haven't been docking your browser window to the right you've been missing out on resizing your browser window below the 320 pixel mark. ↩︎

Hat tip for Mr Stuart Robson for reminding me about this ↩︎