Ben Taylor

The user experience ‘slide’

Mon, 12 Jan 2015 00:00:00 +0000

A process or task that a user needs to complete is like a slide. At the start of the task the user is at the top, and their goal is to get to the bottom of the slide. As designers our job is to enable the user to complete the task as smoothly and easily as possible.

Every time a user has to stop or slow down to think, or consider options, or when an interface doesn't respond to input immediately or predictably, or any other of the many little things that can happen in any interface design, we are adding grains of sand to the slide.

A few grains of sand are inevitable in almost any task we ask our users to complete, but they soon add up. And nobody wants to slide on sandpaper.

Really responsive web design

Wed, 05 Nov 2014 00:00:00 +0000

Responsive Web design:

Responsive web design (RWD) is a web design approach aimed at crafting sites to provide an optimal viewing experience — easy reading and navigation with a minimum of resizing, panning, and scrolling — across a wide range of devices

Wikipedia

As the Wikipedia quote above implies, the phrase ‘responsive web design’ has become synonymous with visual layouts that adapt in response to a particular viewing resolution. That's completely natural — it's generally technically simple, well supported and the most visible and understandable responsive web implementation. It's often also quite an easy ‘sell’ — one layout that works anywhere? Yes please!

I love the techniques that allow us to do this and I use them all the time. I firmly believe, however, that rather than being the definition of responsive web design, it is really just one implementation. Changing a site based solely on available screen real estate is really a sub–set of a what truly responsive web design could be and it's short sighted, even damaging, to think that will be enough going forward.

It's not new

Many people think responsive web design is a new ‘thing’. It's not at all really, we just have more sophisticated techniques and a collective name for some of the practises many people have been taking for years. Whenever we make a design decision based on what we know or suspect about the current state of a user's technology, we are designing responsively. When we add features targeted at a particular type of technology, we are designing responsively.

Whenever we make a design decision based on the current state of a user's technology, we are designing responsively.

Some examples

So, layouts that adapt to any given screensize are almost the rule rather than exception, and buttons or menus that are tailored for touch screens are very common, but what else can be done?

Enter the web APIs

There are a number of APIs at various stages of development that allow us get extended information about the state or environment of the users device, in a way we're accustomed to seeing in native apps. This offers potential to tailor design and function of sites and pages in a manner that is sympathetic to the users needs.

Battery API

Almost 40% of browsers globally support the Battery API. If we know a user's battery is running low, there is opportunity to reduce the use of non–essential battery intensive tasks such as animations and transitions. This could even go as far as use a light on dark colour scheme, reducing the power required to illuminate the screen.

Ambient Light

Whilst currently not as widely implemented as the Battery API, with current support at about 12%, development underway in Chrome, and under consideration for Internet Explorer, the Ambient Light API offers some potential for adjusting designs based on the user's environment. A dark colour scheme may be appropriate to increase contrast in bright conditions, or a more subdued scheme to reduce glare and battery use in lower light.

Page Visibility

The page visibility API has excellent browser support (about 80% at the time of writing) and provides a simple but important function; allowing us to test wether the our page is currently the active, focused browser tab. Animations, videos or audio could pause when not in view to save resources. If your web app uses push notifications, or times out after a period of inactivity, the page <title> element could update to inform the user of any changes.

Complete API list

These are just a couple of ways we can make pages and web apps respond to the users technology — the coming months and years will inevitably see growth in the variety of responsive design solutions beyond those which simply reformat layouts based on the screen size.

complete web API list

User testing & the uncertainty principle

Sat, 25 Oct 2014 00:00:00 +0000

This post came about after I wrote about a suspicion I had when prototyping and testing some form inputs. Specifically, that asking for a user's date of birth with a set of 3 drop down lists, or <select> inputs, may encourage users to select random entries rather than scroll through long lists to find the correct date. Whilst wondering how to test this hypothesis, I came to the conclusion that more than likely, I can't. Bear with me — I'll try to explain.

The uncertainty principle

The Heisenberg uncertainty principle predicts that the act of observation somehow alters the phenomenon being observed.

On the surface, this could be the case in my set of three drop downs for entering date of birth; the fact that someone is being watched may encourage them to take extra care when entering data. But Heisenberg was describing physics and the physical intrusion observation requires. A much more pertinent description is found in the pyschological concept of Reactivity:

Reactivity (psychology):: A phenomenon that occurs when individuals alter their performance or behavior due to the awareness that they are being observed.

It's well documented that study particpants will consciously or unconsciously change the way they respond for a variety of reasons, so how can we ensure this doesn't alter conclusions when analysing usability testing?.

Remote testing

Running tests remotely may help; particpants being in a familiar environment may well be inclined to adopt a more casual approach and react to the matter to be tested in a manner that is more natural. The organisation required to setup and run usability tests generates an inherently artificial or sterile envrionment, free from the distractions of daily life, and test subjects are likely to be fully focused and concentrating. In real life, of course, they may well be mutlitasking or suffer frequent interruptions.

Whilst remote testing may encourage subjects to act more naturally when responding to tests, this manner of testing clearly has it's own set of drawbacks. The lack of subtle cues — a smile, a sigh, tone of voice, make it difficult to pick up on what the user is really thinking. It is generally recommended to combine this form of usability testing with live person to person testing to get a broader array of insights.

In conclusion

I started this post based on a hunch about a certain type of form input, and whether that particular pattern would influence the accuracy of data entered. Having researched the subject further, I still don't really know. I do know how I personally act when faced with an extensive form to fill in — I tend to rush through as quickly as possible, focusing only on the data I percieve to tbe critical. I strongly suspect a lot of people have a similar approach but, unfortunately, I can't see a way to realistically emulate that under test conditions.

One thing is clear though, whilst any usability testing is likely to have a degree of bias of one form or another, accounting for that when examining the results is simply part of the process. Being aware that a user is likely to be far more focused, or perhaps eager to please when under test conditions, can help you make more informed decisions about the real issues with any given application or site.

Knowing the questions

Fri, 17 Oct 2014 00:00:00 +0000

It's never been a more exciting time to be working in web design and development. Web standards support is a dream compared to where we were just 3 years ago, mobile and ‘always–on’ connectivity is almost ubiquitous and the tools — the software and libraries and frameworks that help us build exciting products — are numerous and very often given freely.

A nice problem to have

But whilst the tools and all the information available are what make modern web development interesting, its also one of the issues I struggle with most. What should I read next? what should I try to learn? — there is always something new. Whether you are a specialist or generalist (a brick or the mortar), for people working on the web it's vital to keep up with new developments. Most developers I know have a running ‘to read’ list that gets longer daily — most also accept the fact that some things will just never get read.

If you work in small team, it's likely you'll wear many hats and have multiple areas of responsibility. When faced with the plethora of new information to keep up with, it's tempting and only natural to focus on the areas that are most likely to have an immediate use in your daily work — it makes that reading list seem a little bit more manageable. From time to time though, it can be beneficial to read about a subject that seems only tangentially related to your core role. It will round out your knowledge, and maybe when a related issue crops up in 6 or 16 or 36 months time, you'll know enough about the topic to understand the questions that need to be asked.

…it's beneficial to read about a subject only tangentially related to your core role…you'll know enough to understand the questions that need to be asked.
me

A simple example

An example that springs to my mind is GZIP. At some point in the past I read a little about how GZIP works. Not that compression algorithms are a particular area of interest, but I read enough to get an understanding of the way it references repeating strings. I didn't think much more about it at the time, but gradually realised this little snippet of information was starting to inform the way I approach some front end development tasks — creating strings in a way I know will compress well, whilst emphasising human readablity and maintainablity.

The ‘stalagmite’ skillset

Many people talk about the ‘T–shaped skill set’, but I prefer to think about it as stalagmite. The drip drip drip of snippets of knowledge builds up over time to give a breadth and depth of skills, allowing you to collaborate and contribute across disciplines. I'll probably write more about this soon.

New site

Sun, 05 Oct 2014 00:00:00 +0000

This site is brand new. There may well be quirks, inconsistencies or downright bugs — please contact me if you notice anything askew.

Browsers

So far it's only been tested in latest IE, Firefox and Chrome on the desktop. I will run things through a full device lab when I get the chance.

If something's not working in IE8, it never will. I do enough fixing for that in my day job, and if you're using that browser it is highly likely you're not my target audience.

To do

All the things. There is running to do list in lieu of a real about page.

The humble SASS $variable

Sun, 21 Sep 2014 00:00:00 +0000

SASS is an extremely powerful and flexible language that enables us to work quicker and smarter to generate CSS. For me, one of it's most useful features is one that almost seems to be taken for granted, the simple $variable. With a little consideration about how we define variables, we can ensure a subtle but important consistency throughout pages and across breakpoints, whilst retaining the flexibility we need to Get The Job Done ™

A quick reminder:

SASS variables are simple! We can write something like:

$header-size: 2em;

and then reference it wherever we need to:


     .page--header {

        font-size:$header-size;

     }

… and the compiler will know what to do. SASS understands CSS units, and can work with them in mathematical operations. Building on the example above, we can write:


  .page--header__subheader {

        font-size:$header-size/2;

     }

and the generated code will be:


     .page--header__subheader {

        font-size:1em;

     }

See the SASS documentation for more

This site makes extensive use of SASS variables for all aspects of layout and typography. There is a super simple proportional layout system that I'll write about another time, but that importantly generates variables $column and $gutter

Padding and offsetting with `$column` and `$gutter`

$gutter is currently set to 20px. By setting padding:$gutter/2; and padding:$gutter/4; throughout the SASS files, I know I'll have consistent padding across all elements that require it. Similarily, by using $column, $column/2 or $column/4 to offset elements, I get margins that are always proportional and consistent.

Media queries with `$break-point`

The basic grid has a max-width set using variable $page-width:960px;. This is used this to generate some basic breakpoints:

$sml-breakpoint:$page-width/3; $med-breakpoint:$page-width/2; $big-breakpoint:($page-width/3)*2;

Using these as the basic breakpoints in @media queries ensures the page responds predictably at any given screen size — I don't need to remember whether I previously set max-width:320px or min-width:321px.

Combining these breakpoint variables with $gutter and $column gives a powerful way to generate layouts across a range of screen sizes that can be implemented with minimal effort whilst maintaining consistent proportion.

A simple example

An example of the techniques described above can be seen on this very page. When the browser viewport is greater than 960 pixels (as defined by the $full-width variable), the main and sub– headers are offset using:

margin-left:-$column;

The post meta data, showing the publish date and author information, also has a horizontal margin set to the value of -$column;, and additional horizontal padding set as the value of $column/2 to push the date element back inwards. This gives a pleasing diagonal rhythm that leads the eye in to the introductory paragraph.

As the available screen size decreases^*, the margins and padding change appropriately to be fractions of the $column and $gutter, therefore maintaining the relationship and rhythm between the elements whilst maximising the use of the screen.

^* Technically, the changes happen as the screen size increases, not decreases, in a mobile–first fashion.

Paring back design

Fri, 19 Sep 2014 00:00:00 +0000

It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away.
Antoine de Saint Exupéry

One issue I have personally faced when designing sites or interfaces is an inclination to hone (or literally Photoshop Zoom) in on a small component and spend time working and re–working that specific part of the design. That of itself is not a issue, after all, ‘God is in the detail’. It can, however, become detrimental to a design when that component starts to become ‘overly designed’.

##Over designed

One component I spend a lot of time working is the simple button. Having spent time choosing the typeface and scale, picking the correct colours and setting appropriate whtespace with margins and padding, (which hopefully will be proportioned inline with the rest of the UI), the temptation can be to just add a border, or a slight gradient. Then a drop shadow and a little text–shadowing, to make it stand out — without realising it, your well proportioned, simple honest button is a masterpiece!… in isolation. Unfortunately, when viewed as part of the overall page and likely paired with other similarily OTT elements, the net effect can be overly fussy and ultimately detrimental to the success of the design.

A real example

Drop cap sample rendering

When creating this site I wanted to add an oversize drop–cap as a visual anchor point for the introductory paragraphs. I created some sample code and was reasonably happy with the way it looked in testing. Unfortunately, when viewed in the context of real pages, it felt in some instances as if it were fighting the other elements. There are already several combinations of typeface and size in that area of the page, and adding another didn't serve as the reference point I had hoped it would — it just clashed and actually had a distracting, negative impact. On it's own, I liked this small design element and I didn't want to let it go, but feel the design is stronger without it.

Having written about it here, I sneakily managed to get this little tiny bit of design in to a page in a way that doesn't disrupt the flow. For reference, the untested–in–anything–but–Chrome .scss for that is:

.post--intro { text-indent:-2px; // pull the second letter in &::first-letter { font:350% / 0.85 georgia, serif; float:left; padding:0 3px; // offset the indent position: relative; left: -2px; bottom:-4px; color:$accent; } }

So, cut it all out?

Not at all! As with many things, its about balance and necessity. Adding visual ‘flare’ simply for the sake of it may well have a negative impact but, in the right context, a gradient on a button, an inner shadow on an input or whatever it may be, can provide valuable affordance — suggesting to the user that the element is something to be interacted with or an important point of interest. For me, the key is keeping it simple and keeping it subtle.

Ben Taylor

The user experience ‘slide’

Really responsive web design

It's not new

Some examples

Enter the web APIs

Battery API

Ambient Light

Page Visibility

Complete API list

User testing & the uncertainty principle

The uncertainty principle

Remote testing

In conclusion

Knowing the questions

A nice problem to have

A simple example

The ‘stalagmite’ skillset

New site

Browsers

To do

The humble SASS $variable

Padding and offsetting with $column and $gutter

Media queries with $break-point

A simple example

Paring back design

A real example

So, cut it all out?

Padding and offsetting with `$column` and `$gutter`

Media queries with `$break-point`