Reading List
The most recent articles from a list of feeds I subscribe to.
Meeting the TAG
When Bruce Lawson tweeted about an opportunity to meet the TAG, I managed, at the last minute, to get a ticket and joined a room full of very smart people discussing some technical aspects of the web medium.
Although Bruce and Jeremy have already written a much better summary of this fascinating evening, I will share my thoughts nonetheless.
The TAG?
‘TAG’ is an abbreviation of ‘Technical Architecture Group’. They are a special working group within the W3C, overseeing which web standards are developed and thinking about the general direction of the web.
The meeting
The meeting took place in the form of a Q&A session at the Google Campus in London, followed by beers. The atmophere was good, the TAG members interesting and the audience interested.
Archeology
When I entered the room, sorry I was late, there was a discussion about which design principles the TAG has. The web and its possibilities have extended tremendously over the past years, and the main concern of the TAG is making sure that the capabilities of the web ‘platform’ are well documented. Many things a web browser needs to do are not formally described by a spec, but nonetheless, they need doing. Those who put web standards together have to do some sort of ‘archeology’ into what browsers do to find consensus.
DRM
Then, someone asked a question about a drm. An extension of HTML, agreed upon by the W3C, provides APIs ‘to control playback of protected content’. It has been called unethical and bad for the web. In response to the question, the TAG pointed out that they are merely responsible for technical architecture, not for policy. However, individual TAG members did respond. Anne van Kesteren said he personally thinks DRM does not work and is bad for the web. Tim Berners-Lee, after explaining DRM is already in a lot of things that almost all of us use, pointed out the DRM issue is not simple and goes much beyond just technical problems. Many little procedures that make the web work and resulted in its popularity have a social aspect as well as a technical aspect. Someone in the audience noted that the technical DRM discussion ought to be preceded by another, about how, as a society, we want to value content creators. Because surely, we all want to read great books and watch interesting films, and no one would deny the makers of these things to do it for free. I agreed, this discussion has implications beyond tech.
Web Components
In the HTML5 spec, a number of new elements were introduced. Commonly used classnames, like header, footer and section had gotten there own element. When those new HTML5 elements were introduced, they appeared to have been carefully chosen, to make sure the standard remained simple yet effective. With Web Components, it will be possible for developers to use any element they like. Then, asked Jeremy Keith, with some irony, ‘what do we need standards bodies for?’ Now of course it is still good to standardise commonly used elements. Web Components are not meant to create your own <div>-like elements, although you can. They are meant to create the kind of elements that have extra features, like <input type="range">. For standard elements, the browser has APIs to ‘do’ those features. If you make them with a web component, you provide the API yourself, with JavaScript. Then, if some web components become very common, the W3C may decide standardise them, so that they can be used declaratively. In the future, commonly used Components and their JS APIs could be standardised and become part of browsers, just like commonly used classnames were standardised as elements. Now the web is being used more and more as a platform, some developers serve empty <body> elements with a lot of JS. With Web Components, they can serve <body> elements containing meaningful custom elements.
URLs
As the very last question, Andrew Betts brought up an issue that he had with the web product he works on. He felt it was not always possible to represent what was on the page with its URL. One concern he mentioned is that context is not always taken into account. In his organisation, some teams wanted to have different content in different contexts, and there is nothing in URLs that can help specify which context is currently used. The assumption of different web contexts have been argued to be wrong , but Andrew’s case was interesting and lead to the TAG’s final conclusion: ‘we all love URLs!’
Originally posted as Meeting the TAG on Hidde's blog.
Unobtrusive icons
In this article, I describe a way to add icons to descriptive links, and one that makes icons by themselves more accessible.
Icons are often employed to provide a visual description of an action. In some recent projects, I have treated such descriptive icons as merely enhancements of descriptive text. Because surely, text that describes some action is a basic yet functional substitute for an icon that describes that same action.
Icons preceding descriptive links
For example: an RSS link. In its most basic form, it would be:
<a href="http://site.com/feed" class="icon icon-rss">RSS</a>The link with just the word ‘RSS’ is sufficient, it does the job of pointing the user to the RSS feed. Or the finely tuned searchbot, a browser plug-in that looks for RSS feeds or even a screenreader.
In its enhanced form, it would have a super sharp, retina proof vector icon in front of it.
Now, as we already made sure everyone is pointed to the RSS feed in a basic way, we have already included almost everyone, we can apply the enhancement to only the browsers that understand it.
The icon would be a character from an icon font. Let’s add the character with a pseudo element in CSS:
.icon-rss:before {
content: 'foo'; /* character in your icon font, preferably
one from Unicode's private use areas */
}Icons with descriptive fallbacks
Sometimes, a web interface uses an icon by itself, without a label. In this case, it does not come with a useful descriptive text out-of-the-box. Adding it with generated content would exclude users whose browsers don’t understand :before or :after.
Support for generated content can be detected by Modernizr. Taking advantage of the class Modernizr adds, we could show or hide descriptive alternatives for generated content.
<span class="generatedcontent-alt">Enlarge text</span>.generatedcontent .generatedcontent-alt {
position: absolute;
overflow: hidden;
clip: rect(0 0 0 0);
height: 1px;
width: 1px;
margin: -1px;
padding: 0;
border: 0;
}This will “visually” hide the alternative in the case it is no longer needed, when generated content support has been detected by Modernizr.
Another example:
<a href="printversion.html" class="icon icon-print">
<span class="generatedcontent-alt">Print</span>
</a>The text ‘Print’ is no longer needed if the print icon is there. If generated content is not supported, the text provides an acceptable alternative.
Text as the most basic alternative
Icons have great advantages, and can help users finding their way around a website. But there will be cases in which the icons don’t work, for example if your web font fails, generated content is not supported or your user only processes text (e.g. Googlebot or a blind user).
With text, you can be sure you reach almost all web users. This makes it the ideal alternative, that is always good to have it in place, even if you (visually) hide it from most users.
Originally posted as Unobtrusive icons on Hidde's blog.
Handheld 2013: the web's structure, expectations and data poetry
In this post I’m going to go through some highlights of Handheld 2013, which started of with the Welsh anthem being played on an electric guitar.
The conference
Generally, I much enjoyed Handheld. If I’m right, it was meant for people who make things for handheld devices. This year, it seemed, the speakers were mostly talking about the web. Which is good, and important. I can imagine some people missed talks about app development, but I didn’t.
A common theme of this year’s Handheld was communication with clients. These days, to make sure our sites work on a big range of devices, most web designers have started using responsive web design (RWD) in some way or another. With RWD, the uncertainty of what a web design is going to look like has become more apparent than ever. It was always the case that websites could not look the same in every browser, but now that we attempt to optimise for more than just a few desktop browsers, we have to come up with ways to explain this to our clients. This is a lot about building trust, confidence and that sort of thing, in addition to crafting great designs.
Having just recovered from co-organising my own conference , I may have had a biased view here, but there were some things I did not like about the practical side of things, including the waiting at registration and the somewhat too visible sponsor involvement.
Some talks I loved
The long web
Jeremy Keith talked about the web, a medium which he clearly loves (and who doesn’t?) He loves it for reasons such as its backwards compatible design, allowing for websites to be built in layers of structure, style and functionality. He also loves it for its URL system, providing a great and multi-purpose way for developers to make content available.
The biggest change in working on the web recently must have been the ‘mobile first’ paradigm, or ’content first’. According to Jeremy, you could work URL first, so that you start thinking about how to address the content before you even think about navigation. A clever way he mentioned to create a website from content is to break it into bits of content, components. Creating a library of components can help a lot. Jeremy created Pattern Primer as a handy way to show patterns and their HTML. And there is of course Anna Debenham’s book on style guides.
Content first also works through in code. You could put the content as (one of) the first thing(s) in your code, and the navigation at the very end.
Jeremy pleaded for progressive enhancement and rightly so. It almost ‘follows’ from working starting with (structured) content first. Progressive enhancement is often thought of being there for users that ‘have their JavaScript turned of‘. Although it does probably help those people, progressive enhancement has more to it. It helps anticipating those things that you did not expect, like a bug in one of your JavaScript files. It is about dealing with technology failing, rather than it not being supported.
Do not outsource your [website’s] performance to a third party.
A great example Jeremy mentioned is that of the social sharing button thingies that many sites use these days. The social media sites often offer those as a <script>-element that they ask you to drop in the middle of a page. Now if you imagine a Twitter widget in the middle of a page: if a user in China opens that page, it may stop loading when it gets to the Twitter widget, because Twitter is blocked in China so its script is never found. Your website’s speed is its most important UX feature, Jeremy warned, “do not outsource your performance to a third party.”
How to call your client an idiot without being fired
Andy Clarke’s talk was about how to communicate about design with clients.
We should avoid setting the wrong expectations
Old-fashioned ways of wireframing and design comps is that they might cause us to set the wrong expectations. When a client is shown a wireframe that already has some basic lay-out, as wireframes often do, they might expect the visual design to look like that lay-out. If the client is shown static design comps, they may assume that the final website will look exactly like them on any browser or device ever used.
What we design, Andy says, is not how we design, but how we communicate our designs. It does not matter which tool you like to create designs, as long as you make sure you set the right expectations.
According to Andy, the waterfall method is one of the main causes to problems related to expectations. To be able to set expectations right, we should start working in agile teams. That way, designers, developers and clients work together. In the process, everyone involved will know what is being worked on, and big surprises at the end are avoided. Working together, team members will feel more accountable.
To improve the way we design websites, we could improve the way we ask for our client’s feedback. If they work alongside designers and developers, we already avoided ‘the big reveal’. There are some other ways to improve the feedback process. At Andy’s company, they try to make it easier to control the feedback conversation, by insisting on face-to-face feedback, not allowing feedback by phone or email. They also try to control the environment in which the design is presented, by making sure everyone who can decide about it is in the meeting. They also find it important to leave their personality at the door: it is about the integrity of the design, not about that of the person who made it or gives feedback about it.
Data poetry
Brendan Dawes had a great talk about data. Now data can have two appearances, Brendan showed. There is the ‘raw’ format of just plain csv of JSON files in a text editor. They look boring and do not invite people to interact with them. They don’t look sexy. But when using data as an input for graphic design, it can come to life. Data represented in a graphical way can show give us new insights. It can help us see connections that we would not have noticed in the csv, although technically they were in there.
Data needs poetry
In his talk, Brendan showed heaps of examples of cool things he had done with data, including many new ways of representing data that was already there. These examples really nderlined his point that data ultimately comes to life when it is put in a graphical form. “Data needs poetry,” Brendan concluded.
And more…
And there were other talks I did not mention.
Syd Lawrence opened up with an entertaining live show, which involved people texting details to a phone number that were later used for playing ‘Guess who?’.
Ling Valentine argued that for information-rich web sites like her own it makes sense to stay away from responsive web design and use a simple, yet annoying mobile page to get people to your desktop site asap.
The prophet of web standards Jeffrey Zeldman gave his ‘ten commandments of web design’, often using his own A List Apart as an example. He loves the web as much as Jeremy does.
Mark Boulton explained how as a designer of RWD projects, you have to worry about content as it is such an integral part of what the design is made of. He illustrated this with stories about some projects he did, like Al Jazeera, CERN, UCL and World Skills London.
Jon Hicks talked about the pros and cons of icon fonts and showed how to make one. He also briefly discussed some alternatives to using icon fonts, like SVG sprites.
Eddie Machado made the Handheld site and explained how. I found he brought a lot of tools in that, imho, he could have done without (eg Sass for icon fonts), and ‘dirty’ tricks like </code>-elements inside a <div> instead of a <video> so that he could conditionally load them in a video.
There were not only talks at Handheld. There was also Bruce singing web standard classics such as ‘Like a rounded corner’ and a new (?) song callde ‘Living standard’, and Aral who announced the next phase of his Project Prometheus, now known as Indie.
Handheld conference was a great and varied day. There will be no Handheld next year, but the organisers have plans for another event. I’m going to keep an eye on this.
Originally posted as Handheld 2013: the web's structure, expectations and data poetry on Hidde's blog.
Mark Boulton's grid system design workshop
On November 27th, I attended Mark Boulton’s workshop about designing grid systems. It took place in Cardiff, UK, on the day before Handheld conference.
In the first half of the workshop, Mark taught us the basics of grid design theory. In the second half, we were put to work and made our own grid-based design.
Mark emphasised that the design of (the grid of) a website should be a system. He said humans are pattern-recognisable machines, that humans recognise order. Grid systems can help create such order. Hence the workshop name: it was about grid systems.
First of, Mark went through some history of grid design and type design in general. Grids have existed long before the web. Very long ago, the decorative type in books had already some kind of system, but things really started with the Swiss graphic design in the 1960s.
Odd columns can create tension and balance.
Grid systems, Mark said, are most obvious in long form editorials, such as newspapers or magazines. In those places they make the content easier to read. In a lot of print work, odd columns prevail. Print designers do this to create tension and balance. It can ‘unsettle the eye’. In web design, even columns are often used.
One grid does not fit all, in contrary. If a grid doesn’t work for your content then you need to change the grid, that’s ok. Creating a good grid takes a lot playing around with the content you have available. This is why Mark feels grid frameworks that you have just downloaded from the web (like Bootstrap or the older 960 grid solutins) often don’t work.
Types of grids
Mark explained different types of grids: columnar, hierarchical, modular, baseline and compound grids.
- columnar grids can be subdivided into regular and irregular grids. UX designers use the term ‘swim lanes’ for groups of grid columns that form one big column. There can be different ratios in between the columns
- modular grids are hard to do on the web as height in browsers and devices is difficult to work with (and perhaps not desirable)
- baseline grids are most often used to prevent ghosting (the effect that happens in books if the text on the page behind the page you’re reading does not have the same baseline). On the web, there is no ghosting, and using a baseline grid can start to dictate undesirable line-heights. See Mark’s “Incremental Leading“ about this.
Avoid too many columns, it makes the grid less powerful.
The main point of grids is that it can make different pages that use it feel like ‘one system’. The more columns a grid has, the less power it has to come across as one system. Mark recommended to avoid too many columns.
Terminology
Mark also explained some of the basic terminoloy in grid design. A grid designer needs to know what margins, gutters, modules (or ‘units’), columns, hanging lines, offsetting and fields are.
On hanging lines
Good typesetting, Mark mentioned, is like good conversations, or if you like, a good talk. A good talk makes use of pauses, inflections, etc. Something like a pause in a talk is very fragile, it is hard to say when it is ‘just right’. Hanging lines can make typography better like pauses can make talks better, Mark argued.
On gutters
If your gutter is small, you can add a line to it. Newspapers sometimes do this. On the web, if you put a 1px line in your gutter, it can be useful to have a gutter with an odd width (so that the line plus surrounding whitespace are an even number). Sometimes gutters are defined by the padding within the module. Mark mentioned that this approach can require more mark-up, I have not yet done the comparison myself.
On DNA of grids
For years, web designers and web developers have come up with solutions to create grids on the web, a famous one being 960. According to Mark, grid systems like 960 are too limiting. Also, they have their own “DNA”. If many sites use the grid system, all of those sites end up having the same DNA. That threatens original web design.
Designing a grid system
In a lot of graphic design, the design is tied to the page size, Mark called this ‘knowable space’. On the web, there are no book-like pages and thus no page size, no dimensions that you can be sure of. Yes, grid systems for the web are hard.
We should design content out, not canvas in.
For that reason, Mark argues we should design content out, not canvas in. See also his “A Richer Canvas” article from 2011. This means you use your content to derive a canvas from, rather than start with a canvas and lay-out your content on it.
During the workshop, Mark explained three steps to designing content out:
- Find the knowable, fixed content sizes
- If there aren’t any, make some up
- Use them to design your grid
Grids are a system, as Mark said in the beginning. He mentioned three ways to ensure this basic principle:
- Relate everything back to the module
- Use repeated ratios
- Bind the content to the grid
Putting it into practice
The second part of the workshop day, we were put to work. We were given the choice between four projects, or could work on our own side project. The goal was to create a grid system. Mark gave us individual feedback and reviewed some of the projects in front of the class. This was of great help to those who had worked on them, but not much less for the rest of the group.
Mark Boulton’s workshop was very useful, and had a perfect mix of theory and practice.
Originally posted as Mark Boulton's grid system design workshop on Hidde's blog.
World Usability Day in Bristol
Last week, the World Usability Day Bristol was hosted in MShed, a building that is home to Bristol’s city museum with the same name.
The view from MShed
World Usability Day 2013 happened in lots of cities all over the world. This local edition was organised by Nomensa, a digital agency based in Bristol. The conference featured speakers discussing a variety of subjects, including interaction design, accessibility, dark patterns and the possible future of the web. It was well organised: the venue had a great view of Bristol, lunch, scones and tea were all taken care of and all of tickets were very affordable.
My focus here will be on three talks that I particularly liked, about practical abstraction, the BBC’s super accessible olympics website, creating cross channel user experiences.
Dan Klyn: practical abstraction
In his talk, Dan Klyn focused on architecture, rather than design or usability. He tried to connect ancient Roman architecture principles to modern information architecture principles.
In Roman architecture the triad of firmitatis, utilitatis and venustatis were considered the main principles of architecture. Roughly translated, they correspond to strength (or firmness), commodity (or utility) and beauty, respectively.
In Roman architecture the triad of firmitatis, utilitatis and venustatis were considered the main principles of architecture.
Different architects in history can be said to adhere to different equations of those three principles. Buildings that were designed by the American architect Frank Lloyd Wright often had leaking roofs, they lacked firmitatis, but they were both useful and beautiful. A software example: Apple’s first release of Apple Maps for iOS tended to show people plainly wrong directions, but its use could easily be seen and it looked beautiful.
There are also examples of two properties giving rise to a third. The architect Johnson was famous for designing buildings that were strong and beautiful buildings, and therefore functional. One could say their utility derived from those former two properties. The German architect Gropius, the founder of Bauhaus, designed buildings that were strong as well as useful, and therefore beautiful. One could say its beauty derived from those former two properties. An example of this from software design is Craiglist: its beauty is in the combination of its strength and utility. Rather than having one property derive from the combination of the others, one could also ‘add’ one of the properties to a combination of the others. Gumtree is an example of this: it is strong and useful, and a visual design layer has been added to that, as a third property.
Other principles from architecture that we might want to apply to web design: order, arrangement, proportion, symmetry, appropriateness and budget-friendliness.
Alistair Duggin: the BBC’s accessible olympics website
Accessibility was a high priority in building BBC’s website for the London 2012 olympics. Front-end developer Alistair Duggin shared some of his experiences working on this huge website.
The BBC aimed to deliver content about the Olympics to as many channels as possible, such as tv, radio and internet. On the internet, the BBC aims for a high degree of accessibility. “The BBC is paid for by everyone and therefore must be accessible to everyone, otherwise the BBC is not the BBC.”, said Michael Grade, Director General BBC 2004-6.
The BBC is paid for by everyone and therefore must be accessible to everyone, otherwise the BBC is not the BBC.
The website was built around a sports ontology: athletes connected to countries and events, events connected to a ventue and sport. All of these ontology items had their own pages, so there were pages for all of the 10000 athletes, 205 countries, 36 sports, 304 medal winning events and 30 venues, and they were all interconnected.
Making something accessible is not as easy as it sounds. An extra complication was that all the templates had to be right when the site was put in use, which was when the Olympics started. During the Olympics itself, there was a code freeze (except for very urgent bug fixes).
The website was a great succes: it was viewed by 37 million UK browsers (57 globally). Many have viewed it on mobile (9.2 million mobile browsers, 12 million requests for video from mobile devices, 34% of all daily browsing by mobile).
These things helped making the BBC’s London 2012 site more accessible:
- usage of a front-end style guide, to keep code consistent (more consistency is better for users)
- front-end was built component-based; a component could generally drop in most parts of most pages
- progressive enhancement was used: pages were built in ‘layers’, so that the basic content was accessible to anyone
- content was added in logical order, alt text added to images that needed it, tables had captions, abbreviations had their full text in the code
- in the HTML the team used: the HTML5 doctype, lang-attribute, skip-links, a unique
<title>and<h1>and WAI-ARIA landmark roles, hierarchical heading structure, no duplicate links, alt text if they would not duplicate, links that were sensible outside their context, correctly coded forms and tables - in CSS, the team was careful not to implement barriers with CSS; display:none was only used when strictly needed, focus-styles were defined, outline:0 and !important were avoided, colour contrast was checked and the lay-outs were checked without JS and images
- *in JavaScript, the team used feature detection, generated only valid HTML, updated state labels such as ‘open’ and ‘close’ appropriately, made all content accessible via keyboard and took care not to add keyboard traps
- WAI-ARIA was used as an enhancement for those users with devices that support it, for example to keep users informed, manage focus, implement keyboard controls and provide hidden instructions
Andrea Resmini: cross channel experiences
Andrea Resmini talked about how websites have gotten more deeply integrated in our world, and cross channel services.
The difference between multi channel services and cross channel services is that the former serves A, serves B and serves C, whilst the latter includes A, B and C.
Computing used to be bound to a very specific time and place, e.g. a computer would not follow you. Today, cyberspace is very deeply integrated into the world around us. It has become much like a layer.
In a city we are said to ‘know’, we have a mental map of that city. In the first few days in a new city, we are able to create such a mental map. Now with digital products, this is not much different. A digital product like Facebook is much like a city that we have a mental map of. Their app on our phone is part of this, and so are the friends we know to be online in its chat service.
The architecture of information spaces comes down to the information architecture of places.
We ‘know’ a place, because we know specific characteristics of it. Those characteristics make up our memory of the place. If we want to create a cross channel experience that is easy to navigate, we should concentrate on creating characteristics. The architecture of information spaces comes down to the information architecture of places.
Recommended reading: Manovich, The language of new media
Originally posted as World Usability Day in Bristol on Hidde's blog.