If one phrase from Bram Stein’s excellent Fronteers Spring Conf talk stuck with me, it was ‘always have a font loading strategy’. The point he made was that if you use custom web fonts in CSS, you should not rely on browser default behaviour, as that will often mean users see white pages with invisible text in case of font loading failure.

In his article ‘Web fonts for president’, Zach Leatherman compares font loading strategies (or, mostly, lack thereof) of the 2016 US election candidates. What a great idea! It’s a very interesting read!

Bram Stein describes how to use his Font Face Observer on his blog.

(I realise this blog currently lacks a font loading strategy, since I recently updated the typeface, I’m working on that)

Originally posted as Font loading strategies on Hidde's blog.

Reply via email

On Friday 1 April I attended Fronteers Spring Conference at EYE in Amsterdam. The first of its kind, after 8 two day conferences in autumn. IMHO, this one day spring thing is a fantastic format worth pursuing again!

Fronteers has in recent years always taken place in Tuschinski, an old cinema with a very cool interior, an eclectic mix of styles like art deco and Jugendstil. Cinema equals comfy seats. The cool thing about the new venue, also a cinema, was that most of us had to get on a boat (for five minutes or so) to get there.

The day was all about web performance (hashtag #perfmatters): making websites faster. It was divided into three sections, each with three 20 minute talks: the first on visual performance, the second on performance and accessibility and the last technical performance. Each section ended in a panel discussion with MC, eh, host, Phil Hawksworth. The day was then concluded with a keynote talk about money and the business case for web performance.

Visual performance

Tobias Ahlin started the day off with some great tips for better performing animations (slides). He recommended to only ever animate opacity, transform and translate properties, and suggested the use of pseudo elements to resemble animating other properties. An example: you cannot transition/animate border, but you can add a pseudo element, make it look exactly like a border and transition/animate that instead.

Paul Bakaus discussed the perception of performance. How a person experiences speed, he argued, may be a more important thing than actual, measurable numbers. Long activities, he said, can be memorised as short, and short ones can be memorised as long. He also emphasised how important context is for this: where and how you experience time can also influence what you feel about an interaction taking a certain time.

Bram Stein then talked about web typography, and more in particular the timing of custom font loading (slides). Browsers (and developers) make choices about what to do when your CSS wants to use a font that is not on the user’s system, the main options being FOIT or FOUT. FOIT is the flash of invisible text: a white screen until the requested font has downloaded. FOUT is the flash of unstyled text: rendering content in a fallback font until the requested font is downloaded and available. I could not agree more with him that FOUT is the best strategy: displaying any content at all is more important than displaying it in your font of choice. Web fonts are an enhancement. Bram stressed we should optimise how browsers load fonts with code, as most browser’s defaults are not great. This can be done with prefetch headers, the Font Loading API or its polyfill, Stein’s own Font Face Observer.

Accessibility

Marcy Sutton talked about ensuring accessibility in apps that rely on JavaScript (slides). To get websites to perform well and accessibly, she encouraged us to think about how you impact users (eg those that want or have to interact with their keyboards or assistive tech). This means we should not only focus on the DOM tree, but also on the accessibility tree. In terms of performance, if your app relies on JavaScript to be usable with a keyboard or AT, she stressed, make sure this JavaScript is in the critical path and load it before the rest of your app. She also recommended to prefer native elements above custom ones, as they often come with free accessibility benefits. I feel this is especially important when thinking of Web Components.

Karl Groves said that an important reason that we optimise for performance is because our clients want it and they’ll leave our sites or refrain from buying our stuff if we don’t and our website takes too much time before it becomes accessible. He said research (on physical businesses) showed that up to 83% could indeed leave a business if they had difficulty accessing it, and that this applies to the web. The most important question he said developers should ask is: “What is this thing and what does it do?”. This makes lots of sense, because the answers to those questions will likely remain the same whatever the device/context/user. Like Marcy, Karl mentioned the benefits of using native elements, and he showed an awesome video that compares how ATs make sense of real <select> elements and their jQuery UI counterpart.

Estelle Weyl talked about how responsive web design is not (only) about making it ‘squishy’: with sites getting larger in file size, page weight really matters (slides). An example she showed is that of YouTube Feather, a super light replica of YouTube (100k instead of 1200k) that someone at Google made. She also explained how responsive images save time in both decoding and transferring, and said we should consider our user’s battery lives. Design, Estelle concluded, is not about making it pretty, it is about making it usable and intuitive (and I guess that includes fast).

Technical performance

Yan Zhu went into the speed of TLS: when it was first on the table, people said it should not be deployed as it would be too slow. This is changing, with the likes of Netflix (which accounts for a huge part of bandwidth usage, especially in the US) switching to HTTPS. She said session resumption makes TLS less expensive by saving roundtrips. HTTP2 will also have impact as it allows multiple TLS connections at ones (and all regular supporting browsers will require HTTPS for it). HTTPS has in recent months become much easier to deploy on any site, with the public launch of Let’s Encrypt, which has issued over 1.4 million certificates since its launch, which, in number, makes it one of the largest CAs out there.

Tobias Baldauf showed us some very clever tricks to get better performing images, including those ‘hero’ images that we all love. There were three parts to his proposal: use HTTP2, use progressive JPGs and optimise the ‘scan levels’ in those JPGs. Tobias showed a number of comparisons showing real speed differences between HTTP1.1 and HTTP2, and between progressive JPGs / optimised progressive JPGs and ‘regular’ JPGs. With HTTP2, progressive JPGs and optimised scan levels, he showed, you can get a recognisable image on screen after only 15% of the image has downloaded. Wow.

Fronteers veteran Mathias Bynens blew everyone’s mind by explaining a very different phenomenon related to comparing the timing of downloads: the so-called timing attack (slides). He showed a number of different ways this can be used, but the main idea comes down to making requests to a site you think your victim visited, and use differences in server response times to find out about their status on that site (e.g. that they are logged in, have an account, or even have a certain age).

Round-up

Kristian Sköld ended the day with an interesting keynote about a subject that was hardly discussed in the other talk: money. If you need your organisation’s support for spending time on web performance, you will want to make a business case and discuss money, as that is likely what the management will want to know about. Whatever you do, there should be a business case behind it, Kristian said. If you correlate pageviews/load time statistics with bounce rates, you will likely find that more people bounce if the site takes longer to load. This is a metric marketing/business people can work with and ultimately, approve the budget for. If better performance can shave money off the marketing budget, Kristian explained, making more money available to the IT/web department becomes simple math.

My takeaways:

• We should be conscious of and minimise the amount of bytes we send down the wire
• Page speed is not just numbers, perception can also be a factor
• Fast websites do not have to be insecure: TLS is getting faster (so fast that Netflix is moving to it) and HTTP2 (HTTPS-only in all major browsers) lets us benefit even more from progressive JPGs
• Fast websites do not have to be inaccessible: resources that aid accessibility should be part of the critical path and if we use native elements, we get a lot of accessibility for free
• Paying attention to the amount of bytes sent to users can also help evil companies to track them

What a fantastic day this was. We learned about keeping file sizes down and minimising bytes sent over the wire, about using the right tools for the right job and about advantages of HTTP2 and HTTPS. There were both specific and general talks about web performance issues, and as many as three accessibility talks. Lots of variety! Well done, team Spring Conference!

Other posts about the Spring Conference

• Tom Hartwig’s takeaways

Originally posted as Perf mattered at the Fronteers Spring Conference on Hidde's blog.

Reply via email

When I started out learning to build websites, the web world was just moving from adding style declarations to every single element, to a generalised approach where one small-ish set of rules would apply to all of a website’s pages.

We transitioned from meaningless markup:

<font size="-1">A smaller heading1!</font>

to markup that described an element’s position in the page structure:

<h3>A smaller heading</h3>

This was the magic of CSS: because our markup had meaning, we could contain the style of all the elements in just a small set of rules that would sort of automatically work for new pages.

Styling things that don’t even exist yet

With CSS, you don’t just style that heading, you style the general thing ‘heading’, including the ones on pages that don’t exist yet, with lengths you hadn’t imagined yet.

Preparing for the unexpected is a large part of the art of authoring stylesheets. We don’t know what device a user is going to pick, we don’t need to know, but if it’s got a certain screen width, we can write rules to adapt the lay-out.

Cascade blaming

In modern approaches to CSS, some portray the cascade as a nuisance. In his (well-considered) article about REMs vs EMs (seriously, read it, it is good!), Zell Liew says:

What throws people off is that 1em can take on different values in different parts of the code

Harry Roberts responded to this on Twitter:

This, in a nutshell, is why I hate ems.

So about this ‘taking on different values on different parts of the code’: in any programming language that would be bad, a side effect, a bug, a problem. But for CSS, a declarative language, it is arguably the whole point of it. CSS is made to have a cascade: behaviour that inherits style declarations based on priorities.

I would argue the benefit of CSS is that it does unexpected things. Instead of having to style every heading individually (result: expected behaviour), it will style each heading for us, including the ones that don’t exist yet when we’re writing the style rule (result: unexpected behaviour).

This is something you need to keep in mind when writing stylesheets. Harry replied that the cascading behaviour of ems is ‘cognitive overhead’ that ‘isn’t worth it’. I concur it is cognitively challenging, and education is important (Harry personally does a lot of great CSS education), but so are many things in web development.

Complexity in CSS vs complexity in preprocessors

The benefit of cascading as a cognitively challenging thing: it is clearly defined in specifications.

Many features of the modern day CSS approach, such as custom mixins and functions, are defined by the (very smart) people behind projects like Bootstrap, Bourbon, Inuit et cetera. They, too, bring cognitive overhead, but have only their documentations to refer to for help.

Where the spec-defined complexities have always been explained in the spec, and books by people like Eric Meyer and Andy Clarke, many modern-day complexities in CSS are harder to learn. Arguably, they bring more cognitive overhead.

Originally posted as Cascading and cognitive overhead on Hidde's blog.

Reply via email

This weekend I attended World IA Day in Bristol. The event is organised simultaneously in 61 locations across 31 countries. The local one was put together by Nomensa, an awesome Bristol web agency whom I had the pleasure of freelancing with for 3 months last year.

The day offered a variety of talks: some more philosophical, others more practical. The overarching theme of the day was ‘information everywhere, architects everywhere’. Talks focused on what architecture is (and whether ‘architecting’, as Kanye West used it, is indeed a verb). It was about what it means that in the digital age, information can really go everywhere.

Simon Norris - From taxonomy to data and beyond

Simon’s talk gave us an interesting overview of the history of information architecture (IA). According to Simon, four paradigms characterise the development of IA: Classic IA, User-generated IA, Pervasive IA and Inversion. He related each one to a change of context.

First spoken about in the sixties at companies like IBM, the discipline of IA started with the popularisation of the phrase by Richard Saul Wurman, and the publication of the book ‘Information Architecture’ by Morville and Rosenfield, also known as the Polar Bear Book.

Simon considers IA as a ‘sister’ discipline of UX (separately, like chemistry and physics are separate disciplines). One does not supersede the other, they work together. IA is about the blending of the immaterial and the material, Simon said. In this view information itself is completely shapeless, and giving it shape is what IA is about.

Simon discussed these four waves of IA:

1. Classic IA - Context: the web was quickly becoming the most popular technology ever. Classic IA was about what to equip designers with to make sense of all the information that needs to go on a website. Simon said that for him, Classic IA was about defining taxonomies to aid the design of websites that support human decision making.

2. User generated IA - Context: the web had become a global phenomenon in many ways, it was bigger than what anyone expected. Another shift happened: User generated IA. It was almost the opposite of Classic IA: it was user orientated not designer orientated. Users were enabled to make their own taxonomies and with that, shape their own experiences. Example: delicio.us (now Delicious), the bookmarking website, lets users save URLs and manage them within taxonomies like tags and categories.

3. Pervasive IA - Context: people started to use computers everywhere. It was no longer a discrete activity, computing had become ubiquitous, and interaction started happening ‘cross channel’. IA was no longer about labeling and hierarchies, it became about sense making and place making. Resmini and Rosati wrote ‘Pervasive Information Architecture’. IA now had to consider changing and emerging experience across channels.

4. Inversion - Context: digital is now influencing the physical world. The fourth wave is about ‘inversion’. There is now so much data, ‘big data’, that we could do analysis on, that we are urged to look at information in a completely new way, Simon said.

Simon recommended reading “A brief history of information architecture” by Resmini/Rosati (PDF).

Shaula Zanchi - The world is greater than the sum of its parts

Shaula works in ‘physical’ architecture and talked about how internal information is managed at her company. For each project there is a lot of information that they need to keep track of. One example of information is keeping track of samples used in the architectural process: which they had, where they were, where they came from, et cetera.

They began making sense of their information and the relationships within it through a spreadsheet. Then they started using a database with some PHP, as a kind of Excel plus. They then started adding layout kind of things to what they had, so that it could look and feel more like what they now call Sample Library. It all became part of the bigger intranet project.

A very interesting case study!

Team BBC

The next talk up was by what Simon called “Team BBC”: four smart people involved with the BBC’s information architecture.

Dan Ramsden talked about blending the day’s theme, ‘information everywhere’, with another: ‘uncertainty’. At BBC, he said, they literally have millions of pages online. This is a lot of content and information. The ratio of content producers to designers is roughly 83:1. Projects vary from simple projects with a clear direction and scope to more complex ones, with many uncertainties. Information architecture helps them hugely with these challenges. The most important IA adds to the BBC, Dan concluded, is that by defining a structure, we create meaning.

Luisa Sousa then talked about joining and becoming a User Experience Architect at the BBC. When she first started, she explained, Luisa felt like being in a box where she couldn’t move or see much. On her first project, a new website for GEL, she learned to stop worrying about the word ‘architect’ in her job title, and to start being involved as a problem solver, master of questions, designer and jelly bean eater. From her talk, I understood good information architects are able to put on many hats.

Barry Briggs talked about practical aspects of being a user experience architect. He emphasised how complex IA work can be, as there are many gaps between bits of information. He showed how flow charts can help. Not only do they help verifying IA work with stakeholders, they also help with dividing stakeholdership across different parts of the chart. Letting team members and stake holders be involved with specific parts of the flow chart, also aids working in parallel, Barry explained.

Lastly, Cyrièle Piancastelli talked about advocating for UX at BBC. The best user experience, she explained, enables innovation, is an investment and is essential. The best way for user experience (and perhaps information architecture). At the BBC, as Dan also mentioned, there is lots of good content. When you are already sure about your content, the thing that you can make a difference with is how your present it, said Cyrièle. With good IA, we can make a difference.

Karey Helms - Making the invisible physical

Karey talked about how to make sense of complex data driven systems to design enterprise solutions. She discussed what makes enterprise UX so challenging and what physical prototyping is, and showed us some cool example projects.

One of the major challenges Karey’s company had, is that many of their users are ‘situationally disabled’. Whether they are potentially under stress (healthcare patients) or wearing gloves (when working in a warehouse): they can be in complex situations, and interfaces need to be designed appropriately. I think this goes for users outside enterprise as well: we should always design for circumstances that we are aware or unaware of.

Physical prototyping or model making, Karey explained, is used by her company to identify what ‘core components’ of a project are, to situate things in context and to explore interaction modalities.

Karey showed some great and personal examples:

• the ‘party mode’ on her website that corresponds with a Philips Hue light on her desk. Information, she concluded from this project, is emergent, part of an ecosystem and not a fixed modality.
• the ‘burrito’ bot: it analyses use of emoji in personal communication between her and her husband, and then reports who the weeks’ best spouse was at the end of each week. From this she found that information has a large role in the design of systems, but also that it has broader implications and varying levels of fidelity.

Ben Scott-Robinson - Making money out of IA

Ben works for Ordnance Survey, Britain’s ‘national mapping agency’. Making maps, he explained, is in its core all about information architecture. His talk was about how OS makes money from IA. The main thing they produce, he said, clarity of information. Detailed information, in their case, used by the likes of governments and telecom providers.

Despite the IA-like activities being at the core of the company, OS’ website was not ‘generating leads’ or selling products very well. This almost lead to the closure of the website, but this did not happen. They decided to work on a new website and have a strong focus on user testing during the process.

Ben explained OS decided to make ‘happiness of users’ a key metric for their definition of success. Their company’s performance would be judged by how happy their users were. There was an big role for NPS (net promotor score), a number that expresses the chance a customer would recommend your company to others. NPS, they decided, equals happiness. When they first started, the NPS was very low, negative even. Then they started using UX processes like paper prototyping and card sorting. They built a new website, showed it to stakeholders. Some departments were unhappy as their bit wasn’t in the main navigation, but this is where the user testing sessions came in handy: there were many a user testing video they were able to show to back up their decision.

Dan Klyn - Everything needs to be actually architected

The last talk of the day was a great Kanye West-inspired keynote by Dan Klyn. A greatly inspiring talk, about whether architecting is a verb (compared with the word ‘designed’, he said, it is about something more fundamental than design). Dan emphasised that architecture is not design. He also talked about the difference between good design and better design, which he said is immeasurable.

Dan Klyn

The reason we don’t call architects something like ‘building designers’, Dan said, is that they operate on a different level, being the level of human agreement. An interesting challenge in IA Dan mentioned is that of the ‘structural integrity of meaning across contexts’: the ‘mess’ that iTunes currently is, is an example of a product where this needs improvement.

Conclusion

I had a great time at World IA Day 2016 and learned a bunch about information, architecture and information architecture! Practical tips about different approaches and working together, but also theoretical ideas about the meaning of information architecture concepts. Also, I should definitely go and read the Polar Bear book.

Originally posted as World IA Day 2016 in Bristol on Hidde's blog.

Reply via email

Heartbeat API is a thing built into WordPress that sends a POST request every 15 seconds. It allows for interesting functionalities like revision tracking, but can also dramatically slow things down and even block editors from editing content (if your connection is quite slow).

The “Edit” pages in WordPress use the Heartbeat API to detect connection loss. If they detect you’ve lost your connection, your ‘Update’/‘Publish’ button will get disabled until your connection is back.

Why?

“Connection lost” message on slow connections

When I was working on a WordPress site this week, I accessed the internet through my 3G MiFi, and added a VPN for security (the less glamorous side of working remotely). It resulted in seeing the ‘Connection lost’ message all the time. It would usually appear before I could make any changes, and never disappear. In which case it stopped me from editing content.

! The error message

High CPU usage

Others comment that Heartbeat leads to high CPU usage: imagine having multiple instances of WordPress edit pages open in a browser, each sending its own POST requests every 15 seconds.

Turning Heartbeat off

Only when I just turned the whole thing off, I was able to make changes to my page. Turning Heartbeat off can be done by simply deregistering the script:

add_action( 'init', 'remove_heartbeat');
function remove_heartbeat() {
 wp_deregister_script('heartbeat');
}

(via Aditya Nath Jha

Originally posted as Turning off Heartbeat in WordPress made my day! on Hidde's blog.

Reply via email