Webstock 2016 - The Manifestations of Mindfulness
This year I was fortunate to be able to attend the Webstock conference for the sixth time. For each of these successive years since 2011, something about it has drawn me back - more than the intriguing speakers and the interesting topics that they talk about. I remember entering Webstock 2011 not knowing what to expect, but leaving feeling absolutely inspired with a natural high lasting several days.
Webstock is not a technical conference like Microsoft's Tech-Ed; rather, most talks are higher-level - focusing on the 'why' as well as the 'what', in terms of the bigger picture. It is this aspect, which gives the talks added purpose. For this reason, the conference is relevant to many roles: designers, developers, product managers, business managers, and more. Despite the bigger-picture thinking on display, there are also technically-focussed workshops conducted on the days leading up to the main conference, and several talks highlight principles that can be applied to one's work.
The cover of my programme guide from Webstock 2016
Mindfulness
Perhaps the central theme of Webstock 2016 was Mindfulness, as explicitly discussed by Leila Adu. As she, and Ethan Marcotte emphasised, there is a much wider world beyond the scope of what our product or service, or use of a product or service, considers. Factors such as the supply chain. What the conditions like for the people involved in the development of a product such as a smartphone? Are they ethical and sustainable?
Ethan drew attention to the growth of mobile devices worldwide, and how they are being used. In the Western world, mobile devices are assumed to be personal devices, yet we saw that in communities of Bangladesh and some sub-Saharan African countries, mobile phones are being treated as community phones that are hired for short periods of time from phone lenders. These phones typically lack 3G-speeds, so the trend of increasingly bloated webpages is not a practical solution for this wider customer base. In our own markets, several promotional webpages for cars, high-end fashion wear and electronic devices were found to consume 3 to 21 megabytes; some extreme examples were even in excess of 70MB. That's more than the disk space required (52.6MB) for a 'typical' installation of Windows 95. As websites become responsive, it is essential to remain mindful of the impact of a particular design on page size, and the resulting impact on visitors. Especially given that bandwidth has not caught up with the exponential growth of storage space and RAM.
Of CSS
One particular aspect of web performance to be mindful of is CSS, which was covered in-depth in Harry Roberts' workshop on scalable CSS. A major point was that CSS performance is critical for determining how long a site visitor will have to wait before the page renders, since the browser will not render the page until all CSS has been downloaded and processed into a CSS 'object model'. Furthermore, all CSS files will be downloaded regardless of the specified media type. An ideal way to minimise this impact is to combine all CSS into one file and use media queries as necessary. This includes webfonts; rather than using an @include, or linking to the external CSS (e.g. at fonts.googleapis.com), it is better to copy the @font-face declaration into the main CSS file itself.
Other aspects to be mindful of when maintaining CSS:
- Where possible, using child selectors, e.g.
.top-nav > .nav-item
is preferable due to better performance than descendant selectors e.g.
.top-nav .nav-item
- Using an element selector as the key selector, e.g. the 'a' in '.top-nav a', incurs a performance hit as for every hyperlink on the page, the DOM hierarchy is traversed towards the root node looking for a potential ancestor with the .top-nav class when determining whether to apply the style. This is because browsers evaluate CSS rules from right-to-left. As a guideline, a class selector should be used instead for key selectors when descendant selectors are used; otherwise the rule should be adapted to use child selectors.
- Using the 'extend' feature of SASS or LESS leads to added bloat in the resulting CSS and should be avoided. This is due to the likelihood of combinatorial explosion of selector rules
- Too many style overrides leads to CSS bloat and the CSS equivalent of 'spaghetti code' This is where the ITCSS (Inverted Triangle) structure comes in handy; CSS rules are ordered from lower specificity (broadest reach) to higher specificity (most targeted) to keep the overrides in check. Particularly, the styles are grouped into the following categories:
- Reset styles / CSS normalisation
- Base elemental styles (h1-h6, p, a, etc.)
- Objects, i.e. the layout and other parts forming the 'skeleton' of the visual design
- Components, i.e. the 'flesh' of the visual design
- Utility styles / overrides
- Separating layout styles from skinning styles promotes greater flexibility and reuse, yet this should be kept in balance by not being too granular (e.g. .align-left .text-large .bold .vspace-after-large .fgnd-red). This is where a design language needs to be developed and documented in a style guide so that consistency is maintained.
- Naming classes according to the intended function is less reusable than naming according to visual traits.
- Consistency should be defended as much as possible. This is where the 'Five Whys' technique can be applied to understand the underlying issue prompting a specific request such as 'Make this button bigger', and potentially lead to a revision of the style guide.
Know What You're Doing - And Why
Perhaps the most important lesson of mindfulness was delivered by Steve Hillenius of NASA, when he described the project to improve crew members' autonomy in planning and carrying out missions and other tasks while onboard the International Space Station (ISS). This was achieved via a tablet app for use by astronauts, though the project was not "to create an app".
Every project has at least one goal to achieve, and each goal is influenced by a set of guiding principles and known constraints. These principles and constraints are discovered when encountering one or more pain points, and developing a vision and expectation of what should be.
For NASA, ISS crew members were becoming frustrated by having their days scheduled to within 5 minutes by Mission Control. Additionally, each task likely has dependencies on other tasks, and also influences what other tasks can be carried out, e.g. due to power limitations or required access to a limited shared resource. This complexity has been managed by hundreds of flight controllers, who have a vast collective knowledge from each of their specific, dedicated roles. As NASA looks toward future missions to Mars and other celestial bodies, addressing longer communication latencies over limited bandwidth is a major concern. For Mars, communication round-trips would likely take between 8 and 48 minutes at the speed of light, depending on relative orbital positions. This makes it increasingly impractical to rely on ground control for such detail of planning, especially if an urgent issue arises that could threaten the lives of the astronauts on board.
In resolving these issues, a set of principles was formalised to guide the development of the solution. The role of Mission Control should be to advise the astronauts, not enforce their schedule. Each of the 6 astronauts on board should be able to 'walk up to & use' the system, in a manner that is efficient and effortless. As an example of these principles in action, each mission or task had a 'Go / No-go' indication shown on the timeline, while the underlying complexity of dependencies was managed by the app behind-the-scenes.
UX
Much of the implementation of NASA's scheduling app revealed some insights into delivering an efficient and effortless user experience. The typically clunky and frustrating experience of copy & paste on a tablet was avoided by designing a 'staging' area instead, which modelled how we as humans conceptually move something to the side temporarily, and later deploy it when ready. The key to this is visibility - the staging area is always visible, along with an easily-identifiable thumbnail of each item stored there. Visibility also means showing a countdown timer of expected communication round-trip times, in order to manage expectations of astronauts communicating with Earth.
Luke Wroblewski presented several guidelines for presenting content and designing interactions with the user. He identified several factors involved in the interaction with an application or website, based on inputs & sensors, output and the user's posture:
- Touch input availability
- Presence of keyboard / button controller
- Presence of a pointing device, e.g. mouse, digitiser pen, trackball
- Screen orientation (portrait, landscape, lying flat on table, held above head while lying down)
- Ambient light (e.g. night mode / low disturbance in a theatre vs daylight / artificial light)
- Screen resolution
- Screen aspect ratio
- Screen density (and resulting physical dimensions)
- Typical distance of screen from user's eyes (smartwatch vs smartphone vs tablet vs desktop vs TV)
These last few factors reinforced the need to design for human scale; in Android this means using device-independent-pixels and providing alternative assets/layouts based on different device/screen configurations. For the web, new Level 4 media queries have been proposed. Luke emphasised that display resolution alone is an inadequate point of differentiation, with the example of a recent LG smartphone having a 551ppi display and therefore the same 1920x1080 resolution as a Full-HD television set. This is where it is necessary to take the other properties into account - on a phone and tablet, touch targets should be large enough and spaced out enough to be unambiguously touched by a finger. On a desktop, where the default pointing device is more precise, it makes sense for this to be smaller. On a TV the size of text is a concern instead - for legibility at distance; touch is irrelevant as a keyboard/controller replaces that method of input.
A sense of balance is required for adapting content to different devices - while this technique is useful for optimising the use of screen real estate and presenting content effectively, there is a lesson not to make naive assumptions about the user's context based on information supplied by the device. Karen McGrane highlighted research findings that user behaviour, i.e. content & functionality accessed, was basically the same on mobile as on desktop. Therefore, it is essential to make the same information and services available for all users regardless of device.
On the Web, this means not serving a separate mobile site; rather, it is more efficient to maintain a single site where Responsive Design (where the browser/client determines how to display the same content) is employed as a top priority. As a fall-back, where some component becomes impractical to implement in a responsive manner, Adaptive Content (where the server provides different content based on information provided in headers) may be used as a supplement. These are not mutually exclusive - using Adaptive Content does not mean that Responsive Design is abandoned. As an example, a responsive site may present the same figure of data in a table for devices with large screens, and a series of stacked 'cards' (using a different markup structure) for smartphones with a narrower display.
Tom Coates said it profoundly, when discussing the coming Internet of Things (IoT), that we should amplify the core purpose of whatever we are building. A key test of some feature is to ask, "Does this make things easier?" If the net effect is that there is simply more to learn, or more to do to achieve the same result, then we as designers or engineers have failed. In the IoT world, Tom's prediction is that these devices will proliferate to the point that it will be very difficult to buy a non-IoT device. The impact of learning how to use each device is cumulative; this stresses that the interface should be as intuitive as possible, without customers having to increase their skill level to that of a programmer. An effective mental image is that of an 'enchanted device', where the product in question gains extra superpowers that enhance the core purpose. Samsung's smart fridge, with its internet browser, digital photo album, news & weather, for example, doesn't fit that description.
Webstock 2016 covered much more than what is described here. As I mentioned, part of the appeal of Webstock is the bigger-picture thinking on display - the human aspects (a commonly-recurring theme) that inspire, move, and give a greater sense of purpose are another significant part of the conference beyond the 'what' and 'how'. These will be covered further in my next post.