Last week I had the privilege to attend the Smashing Conference in Freiburg, Germany. For those who do not know what the Smashing Conference is, it is a conference related to the Smashing Magazine which focuses on everything related to Front-end development and UX Design.
This year’s lineup of speakers was amazing and with the 2-day single track approach, there was no fear of missing out on anything. As a first timer to the conference I did not know exactly what to expect, but came back really happy as I learned a ton, which inspired me to write this. Some of the things here are from the conference and some are my own thoughts and additions to the topics that interested me.
Don’t confuse your users
The first day was kicked off by Joe Leech. He gave us a good overview about how to design powerful user experiences with psychology. The talk ended up being one of my absolute favorites and I was pleased that I had also chosen his workshop about Psychology for UX And Product Design for the day after the conference. Next time I kick-off a new application project there might be one, or two new tricks up my sleeve I might use.
There was a ton of good advice in his talk and the workshop, but the one thing wtat really came on top was the basic concepts of how our design decisions might affect the user’s cognitive load and the differences between declarative and procedural knowledge.
In a nutshell, declarative knowledge relies on our memory, the facts and information stored in our brains. Procedural knowledge relies on how we know how to do certain things and is considered knowledge related to methods, procedures, or operation of equipment. If we want to design solutions that are intuitive and easy to use, then it is better to try to design them in a way that they target the user’s procedural knowledge, instead of declarative knowledge.
This means that there are certain common patterns (like the menu on top or the search bar on the top right) which people are used to, and making innovative new designs might be fun but we might end up making it much more harder for the users to use what we have designed. So when possible, it is better not to innovate in the UI, but if we really want to innovate then it is good to prepare for the fact that this will take time and cost money.
International is hard
As I have been working the past few months with translating a mobile application to multiple languages I had some real personal interested in Robyn Larsen’s talk “International is the new mobile first”.
One of the best things for me was to notice that even though Shopify works in a much larger scale, the same challenges we face with our clients are also present in their work.
It is not just about the text; it is also about the culture. Translating texts is not enough. Some words and writing styles might have a completely new meaning in other cultures and we need to understand this so that the content is still relevant when used in a different country. This requires testing and iteration in order to ensure that the content stays relevant (and that it is not offensive).
If the layout looks fine in English, do not expect it to look fine when you translate it other languages. When the length and in some cases style of your text change it can have a big impact in how it fits the designed page. Languages like German and French tend to have longer words and phrases which might not fit in the area you have reserved for languages. As a rule of thumb, if you are developing in English, then test your changes at least with 2 other languages. One long and one short. A good alternative to this is to use a Pseudo localization, which helps in simulating translations, without actually doing the translation work. Netflix has released an excellent article about how they do this with their product.
When you start to design and develop your solution, you might have a specific font you want to use, but when you start adding additional languages which have unique characters like Russian, Japanese or Turkish, then you might find yourself in a situation that your selected font does not support these characters. So either beforehand decide what fonts to use with different languages, or prepare to find new fonts when the ones you have chosen do not work.
Architecture matters. When starting to build a new solution there might be a big difference in if the application is designed from beginning to handle multiple languages or not. Making the decision later to want translations might be a more expensive one if in the beginning you have decided to save in this area.
Is my content accessible?
Nowadays when we design and develop applications, we put high focus in making the applications look and feel as intuitive as possible and put focus on providing a seamless and easy flow. However, unfortunately when doing this, especially when utilizing a modern library or framework, like react or Angular, we at times forget that not all users use the solution the same way as we do. There are many people with different kind of disabilities, who also need to have the same access level. Some do not see all colors the same way, some only navigate with a keyboard, some use screen readers etc. Our solutions should be built in a way that they make it possible for as many as possible to have the same access. The World Wide Web Consortium (W3C) has actually a web accessibility initiative that you can use to help in ensuring that your content is accessible.
Sara Soueidan gave an information-packed talk about practical tips how we can make our front-end more accessible.
Semantic HTML = Descriptive HTML
We are used to consider the DOM (Document Object Model) when developing content for the web, but something we might not consider that often parallel to the DOM tree is the Accessibility Object Model and accessibility tree:
DOM tree, accessibility tree and platform accessibility APIs from the AOM github page
Sure it is really easy to just use <div> elements in your markup, but for a screen reader the div is just a division or a section in the document. Using the correct semantic markup makes a whole lot of a difference. There is a reason why there are separate elements for headings, paragraphs, headers, footers, articles, images buttons etc. (the whole list is long) and also a huge list of different attributes we can use with them. If you are not that familiar with them then for example w3schools.com offers a long reference list of different elements and attributes and some guidance on how to use them.
At times, there is a need to hide some elements from the view of the user, meaning that you cannot see them. When doing this we need to be careful that we don’t accidentally hide the functionality from e.g. screen readers. It is quite common to use visibility: hidden or display: none to hide an element, but the problem is that these also hide them from the DOM and the accessibility tree, thus making them completely inaccessible. clip-path: inset(100%) and opacity: 0 lets us achieve the same thing, but with maintaining the accessibility.
Accessibility testing tools
On the side of the talks I was introduced to a new tool. Deque offers a great extension called axe. After installation, the tool can be accessed via the browser dev tools and can be used to evaluate your solution for accessibility and get instructions on how to solve the accessibility violations. They also have a new tool called axe-pro what is in beta and can be used for more detail, manual testing.
Final remarks
We tend to take many things for granted and thus fail to consider alternative aspects when building solutions. Accessibility is not just about considering people who might need to use alternative means of browsing the web, but also people with different cultural backgrounds. Finally, we should not make simple things complicated just to make something fancy.
On top of the above, there were also many other talks, with excellent content and speakers, but one can fit only so much in one blog post. Smashing Conference will release videos for all of the talks at some point and I will then update the links for those in here, so that you can also enjoy them.
