Repeat After Me

Repetitio est mater studiorum.

Repetition is the mother of learning. You might have heard this old Latin proverb before, and it’s true: Repetition is key to memorizing something because with each iteration your brain builds up stronger connections in the neuronal networks which then makes it easier and easier to recall this piece of information from memory. Neuroscientists discovered that this process of learning through the development of so-called “cortical memory traces” happens faster than previously thought: After repeating a word for 160 times in 14 minutes, the new memory traces of contestants were virtually indistinguishable from those of already familiar words.

So it really is that simple: Repeat something often enough and your brain will have formed a whole new network of neurons specifically tasked with remembering that information. Your brain adapts to the need of retrieving this information.

But there’s more to it.

The way you repeat something has a profound impact on how well you remember things. And as Robert Bjork, Distinguished Research Professor in the UCLA Department of Psychology and a renowned expert on human learning, explains in this super interesting UCLA Faculty Research Lecture, we tend to remarkably misunderstand our own learning. Although we have a lifetime of learning, we don’t seem to learn how the system works and carry around a flawed mental model of how we learn and remember. For example, taking notes in a sort of stenographer mode actually represses learning instead of supporting it. We also highly overestimate the success of our learning, thinking that we are well prepared, while in reality, our brain has already started to forget most of what we studied. That might also be the reason why we unknowingly favor short term successes over long term learning when we restudy the same information or do the same physical exercises over and over again over a short period of time. This “massing” of learning looks like this:

Yet, studies show that there is a clear benefit of spacing your study sessions meaning that you do something completely different in between those sessions, like going for a walk or watching a movie or whatever you like to do. Like this:

While this seems to be counterproductive, because you start to forget what you just learned, it is exactly this process of forgetting between the study sessions that actually enhances long time learning significantly. Cramming everything in your head still has a slight advantage if you test your knowledge immediately after learning. Forgetting after mass studies is very rapid though. Consequently, if you test after a longer period of time, for example after four weeks, there is a large advantage for spaced learning.

So where am I going with this?

There are things that are worth repeating over an over again: That we should build products and websites for everyone, inclusive and accessible. That we should care about web performance because it, too, is a way of making a website more inclusive and also resource-efficient. That we should take care of each other and guide those who are younger and less experienced than we are. That there is no place for racism and misogyny in our community and our societies. That we need to design the upcoming machine learning and robotics revolution with ethics in mind. And that we are responsible for anthropogenic climate change and that this certainly is the greatest challenge we face in our lifetime.

At the moment though, many of those topics only surface for a short moment every once in a while, like peaks that briefly stick out of a sea of constant noise. And every time a topic raises to the surface, for a short moment we are reminded that this indeed is an important topic and that we should do something about it. But then, it disappears again. And we carry on. We need those peaks of interest, of course, because they raise awareness. But just as much, we need constant reminders, constant repetition that helps us to not forget those things in the long run, once the dust has settled.

So if you have a topic you deeply care about – equality, accessibility, security, climate change, whatever it is, big or small – keep repeating it over and over again. Write about it, tweet about it, tell other people about it. Constantly and persistently and even if it might feel like you are, well, repeating yourself. Because, as we have seen, repetition is good. Not only because there will always be people who hear about something for the first time, but also because repetition is the mother of all learning and how you change culture for the better.

Vulnerability, Creativity, and Prototyping

Vulnerability is still highly stigmatized in our society, particularly in business. If you want to be successful in life you better be brave and don’t show any signs of weakness. And vulnerability is such a weakness. At least that’s what many of us are being taught from a very young age. Brené Brown, a Research Professor at the University of Houston and author of five #1 New York Times best sellers, has been studying vulnerability for years. Her TED talk “The Power of Vulnerability” is one of the top five most viewed TED talks, with over 38 million views. Recently, I listened to a very interesting interview with Brené from 2014. In her conversation with Chase Jarvis, she said something that is as true as it is often overlooked:

There is no creativity without vulnerability.

What she means is that whenever you create something important and put yourself out there and show it to the world, you make yourself vulnerable. You expose yourself to criticism, especially if your work challenges what is considered best practice or “normal”. Yet it is this type of work, the truly innovative and creative work, that has the most potential to invoke change. It is this work, the work that you are most scared of, especially when you are doing it for the first time, that has the most impact. And it’s also important to recognize that people don’t do this work because they are free from fear, they do it although they are afraid. Courage is not the absence of fear, it is acknowledging your own vulnerability and doing something despite feeling uncomfortable – and although you might fail.

But far too often, we avoid being vulnerable. We hesitate to speak up when we disagree because we fear rejection. We postpone sending that important email or making that necessary phone call. We forgo telling a client that this crazy idea won’t work because we don’t want to be seen as a complainer or fear to even lose the client if we disagree. To avoid vulnerability, we also often go for the safe solution, the one that promises a more predictable outcome. All of this leads to less robust and less innovative work, though. So taking a stand and advocating for a specific solution – whether it is the clear and robust, yet seemingly boring or the bold, daring, and unique – will truly make a difference. And it’s part of our job.

This is even more true if you are working in a modern design workflow with a lot of prototyping. You have to be comfortable with sharing rough, early prototypes with stakeholders and users. You have to be comfortable with live-editing that raw Codepen of your component in a meeting. You have to be willing to not take things for granted but to constantly challenge your assumptions – and the assumptions of others. All of this makes you vulnerable. But it is the only way to push your work beyond the expected.

There is no prototyping without vulnerability.

#SaveYourInternet

It’s hard to decide what’s right and what’s wrong these days. There are so many people and so many organizations with so many different interests that it’s easy to get overwhelmed and to be fooled into believing the wrong things. And so it seems to be an option to give up and not have an opinion at all about many of the topics that seem to be beyond our sphere of influence.

The latest EU copyright reform is such a topic. Copyright, in general, is a topic you can have a lot of debate about: How can we save the independence of creators and guarantee fair compensation for creative work, which, of course, is a good thing? What constitutes fair use and what doesn’t? When is quoting and remixing a piece of work a form of creative expression and when is it just plain criminal theft? The lines are blurry.

Supporters of the new copyright directive point out that currently, there is no clear framework to compensate creators if their work gets used online. And they are right. Something has to be done.

Opponents of the new copyright directive fear censorship and a restriction of freedom of expression. The Web as we know it is in danger. And they are right, too. This danger is real and the battle seems to be lost already.

The biggest problem I see with the new copyright directive isn’t the general idea of trying to find a way to reinforce copyright. The problem lies in the way Europe tries to compensate their inaction from the past with protectionism. If you listen carefully to interviews with MEP Axel Voss, who negotiated the current agreement and is a strong advocate for the directive, you will understand that, of course, it’s all about the money. For one, the EU sees a huge opportunity of holding YouTube (read: Google) and other web giants financially accountable. And as we all know, YouTube was built on a lot of copyright infringement. On the other hand, the directive is a desperate attempt to save the old European media groups from extinction. No wonder they passionately write in favor of the directive and mock the European youth on the streets demonstrating to #SaveYourInternet. This is old media versus “new media”. It’s a battle for power and money. But that's not the whole story.

If you want to understand how this directive, which also prescribes upload filters that check every piece of user-generated content for copyright infringements, will change the Web, I highly recommend one of the latest episodes of Seth Godin’s podcast Akimbo. In “Interoperability”, Seth brilliantly explains how monopolization and locking people into closed systems that prevent interoperability will lead to independent people being unable to get their product to market, regardless of how innovative they are. And that’s exactly the greatest danger of the EU copyright directive. Instead of guaranteeing the compensation of independent artists, upload filters would in fact not weaken the position of internet giants like Google, but instead strengthen, even cement it. When asked how upload filters could be realized, Axel Voss responds that “of course, this would require some kind of technology“ and he refers to Google’s ability to identify memes on the image search results page. Yes, Google is able to identify memes and other types of content quite well – and YouTube already does quite a good job of identifying copyrighted material. But what about small communities, small companies, non-profits, and start-ups? Having to implement upload filters and the machine learning technology necessary to make those filters efficient significantly raises the barrier of entry for competitors. Moreover, being sued can be existence-threatening for smaller companies – not for Google, though.

So in reality, the new copyright directive isn’t so much about the compensation of artists and fighting web content monopolies. The established players are closing down the system in a way that will make it hard for new businesses to come up with innovative ideas and challenge the status quo. The large media and internet companies will control technology, access, and who is allowed to participate for years to come. They are creating a walled garden.

This is why we should fight against the copyright directive in its current form.

Visit: https://saveyourinternet.eu/act/

#SaveYourInternet

Building an Accessible Mega Menu – Part 1: Background

Although some designers dislike them, because, at a first glance, they seem to be too overwhelming and too densely packed with information: If you design them carefully, mega menus work really well for site navigation. They convey site structure, present your users all available options at a glance, and thus provide a convenient and fast way of navigating deep and broad hierarchies and taxonomies.

In one of my current projects for an agency, we are building and incrementally improving a website for a state-wide public transport initiative, launched by the Ministry of Transport of the State of Baden-Württemberg. As we need to serve all citizens with various types of information about public transport and also because of the EU Directive on the Accessibility of Public Sector Websites and Mobile Applications, the site will have to comply with industry standards for web accessibility, like the Web Content Accessibility Guidelines (WCAG) 2.1. Of course, in a project that large there is always room for improvement and as the website has grown considerably over the last 1.5 years, the next phase will also include a relaunch of the main navigation. The previous solution, a hamburger menu which was also used on desktop, did, unsurprisingly, not perform well in usability tests and will make way for a mega menu.

In my current position in the team as a UX designer and UI engineer (you could also say front-end designer), I’m in charge of much of the design and code of the front-end, which also includes making it accessible. So when the idea of rebuilding the navigation emerged, I instantly was hooked up. An accessible mega menu! A fantastic opportunity to learn so many new things. But at the same time also quite a challenge.

So in this and a few upcoming posts, I will share my experience of building this mega menu, from the initial research to designing and developing a component. But here’s an important disclaimer: Although I care about accessibility a lot and have acquired basic knowledge, I don’t consider myself an expert in accessibility at all. So I might make decisions along the way that could be further improved with more experience in the field. If you happen to be such an expert or spot any weaknesses in my approach, please (!) don’t hesitate to write me a quick email or tweet. I’d love to hear from you. As soon as the project is live, you can also file a bug or create an issue on GitHub. Thank you so much!

The goal is to end up with an accessible mega menu component that can be published and open sourced. The website project is publicly funded and open sourcing the code I write for it also seems to be a good way to give back to the public and make sure the work isn’t lost.

Last week, after Ethan Marcotte wrote his passionate clarion call for action, I, too, wrote about our obligation to build an inclusive Web for all and share what we learned. From now on, you will be hearing a lot more about accessibility from me. This post is the first in what will hopefully become a little series. I will make each post as concise as I can and try to bring in my design as well as my development experience, so there’s something in it for both domains.

I really hope you’ll be back for the next article. If you are planning to do so, consider subscribing to my RSS feed for articles and notes to stay in the loop.

Copy That.

When I was in school our art teacher used to say:

Kopieren heißt kapieren.

Which translates to something along the lines of “copying something means understanding it.” What he meant is that if you want to understand how a piece of art was created, if you want to understand the technique the artist used, or aspects like form, composition, materials, and use of color, you will learn the most by getting your hands dirty and copying and dissecting the piece down to the last detail. So I spent a considerable amount of time copying Max Beckmann and other expressionists as well as the Cubist style of Georges Braque and Pablo Picasso. And my teacher was right: By copying Cubism as good as I could, I learned a lot about the characteristics of the painting techniques like, for example, the interplay of the different layers of shades of brown and grey, and how an illusion of sculptural three-dimensionality and movement is created through light and shadows on geometric shapes.

Copying is an incredibly useful tool for learning. The process of copying something makes it your experience. By deconstructing it you gain a tangible understanding of the thought process of the creator(s) and how all the individual pieces come together to form something new and special. And by reassembling those elements again and recreating the piece, you acquire the necessary technical abilities – and make them your own. Copying itself is an art.

Copying has a bad reputation, though. Because often, it is understood as simply stealing an idea or concept. Of course, you should always credit people accordingly and respect the license under which a piece of work is published before you take and manipulate someone else’s work. Copying must not be theft. But that doesn’t prevent you from thoroughly analyzing something and then building your own thing based on what you learned. Nothing is completely new and even the most sophisticated innovation could not have happened without so many ideas that came before it. In the end, every new idea is just a combination of other ideas and your personal experience.

So the next time you see something that excites and amazes you, ask yourself: How was this done? How would I do it? Then, View Source (or use the DevTools), build prototypes and demos, and learn from copying and deconstructing the most advanced solutions out there. And then, apply it to your work in new and unseen ways.

Clarity and Style

A few days ago, John Maeda, Head of Computational Design and Inclusion at Automattic, shared this tweet:

Good design is about clarity over style, and accountability over ego.

— John Maeda (@johnmaeda) March 14, 2019

He is right. We are all responsible for what we create and the ego of a designer should never influence the design in a way that it negatively affects quality. But it was primarily the first part of the tweet that got me thinking because it touches on something quite important.

Good design is about clarity over style.

There is much truth in this statement, yet it is something that still isn’t well understood, it seems. Good design has intention and it has to communicate something, often on many different levels, to be effective. This makes clarity essential: The purpose of a design has to be clear, the functionality has to be clear, and the message has to be clear.

Style, though, in the sense of a distinctive aesthetic appearance, might appeal to the eye and thus successfully deceive people for a little while if a design lacks clarity. But taken all by itself, style is not enough for a design to be effective. If the message isn’t clear, making it look pretty will only get you so far. Style in the sense of appearance is not sustainable. It is volatile.

Yet, many designers seem to still favor style over clarity quite often. Why? It might well be that, sometimes, designers are themselves deceived by style, by an extraordinarily well-crafted sensual appearance. Sometimes, designers also simply fall in love with the artistic side of design so much that they get lost in it and forget to look with a beginners mind. Sometimes, designers deliberately use style to “seduce” clients and stakeholders to get approval or to gloss over certain shortcomings. Style certainly is powerful and seductive. But maybe the primary reason why so many designers prefer style over clarity is: Styling something is easy. Making something crystal clear is hard.

Making something crystal clear requires straightforwardness, consistency, and perseverance. It requires advocating for something and at the same time being open to change your mind. To achieve clarity, you need to be willing to ask questions, to challenge every detail, and to reduce something down to the essential. Clarity is when you communicate exactly the right amount of something, not too much, but at the same time – and this also often gets confused – not too little. Only because we make something less complex, it doesn’t automatically get more clear. Sometimes, you have to add the right amount of complexity to make something clearer. Maps, for example, can be exceedingly complex yet still strikingly clear.

Making something crystal clear also means knowing not only how to say something and how much of it but, first and foremost, what to say and why. And for this, it isn’t enough to simply slap some lorem ipsum text into your design and wait for someone else to fill in just the right words later. You need to know how to encode your message so that the right people are able to decode it. This is standard semiotics but it requires a deep understanding of the people you want to reach. You need to understand your audience, their needs and wants, what drives them, and the context in which they might interact with your design. You need to work with content first – maybe not the final version of it but already on point regarding the message – and design with this material, the real material, all real materials, constantly prototyping, observing, and improving every aspect of your design until you know it works.

And this is where style comes in again. Because, of course, style has its place. Which is also why John wrote “clarity over style” and not “clarity instead of style”. There is still an and. Style can be what sets you apart from the competition. Style can create identity and convey emotions and atmosphere, even a feeling of familiarity. Style can support your message by further improving clarity.

Good design is about clarity over style. Combining clarity and style so that they complement each other and the design reaches another level of fidelity is mastery.

Information Management, A Proposal

Yesterday, the Web turned 30.

Thirty years ago, Tim Berners-Lee submitted a document called “Information Management, A Proposal,” his formulation of an information network for sharing and exchanging information at CERN, marking the birth of the World Wide Web. Three decades later, the Web has permeated every pore of our societies and daily lives and the number of people with access to the web has surpassed 50 percent of the population of humans on this planet. The Web is by far the most impressive and revolutionary technological invention mankind has ever managed to create. As with every new technology, the Web started with a lot of enthusiasm and great hopes. Finally, information would be free and available to all, regardless of gender, religion, place of birth, or social status. The Web is for everyone!

Except, it is not.

Also yesterday, Ethan Marcotte expressed his deep frustration over the results of WebAIM’s latest study covering the state of accessibility on the Web. WebAIM analyzed the top 1 million home pages and although – or maybe even though – they only looked at the things that could be detected automatically, “the results paint a rather dismal picture of the current state of web accessibility.” I don’t want to list all of the findings here. Instead, please look at them yourself. Only to give you a first idea of what we are talking about: 97.8% of home pages had detectable WCAG 2 failures. Thirty years after its invention, we obviously failed miserably in keeping the original promise of a Web that is inclusive and empowering to all. As Ethan rightfully points out, “we’ve created a web that’s actively excluding people, and at a vast, terrible scale. […] Improving the state of accessibility on the web is work we have to support. The alternative isn’t an option. Leaving the web in it’s current state isn’t fair. It isn’t just.”

I also really like Ethan’s suggestion that instead of trying to get “accessibility” right at large, maybe we could all do one thing this week to broaden our understanding of how people use the Web. I’d even add: Write about it, too.

Léonie Watson, an accessibility advocate who recently recorded a webinar with Smashing Magazine that is freely available and that I highly encourage you to watch and listen to, agrees and shared this quote with me, which she included in one of her talks:

Accessibility doesn’t have to be perfect, it just has to be a little bit better than yesterday.

I think Léonie and Ethan are right: We would certainly not be talking about the Web as the inaccessible, discriminatory mess it appears to be, if we had all improved it one bit at a time. But as much as I appreciate that this quote doesn’t blame anyone directly and, in a way, also acknowledges that building something accessibly is often quite challenging and even harder if you try to solve everything at once, I also fear that it leaves too much room for interpretation and excuses. There simply are no excuses. Accessibility is a civil right. Or to put it another way: If your work isn’t accessible, it’s not done yet. We are all accountable. And we should be held accountable.

That is not to say that all of this is easy or that you’re a bad person if there are still things that could be improved. Of course not. But let’s be honest: Far too often, accessibility is still a mere afterthought in digital projects, if it is considered at all. I happen to see a staggering discrepancy between what is discussed by a relatively small group of thought leaders who share a deep understanding of and interest in accessibility and many of the people in agencies, marketing offices, and development shops doing the ground work. If we want to invoke change, we need to find the root cause of the devastating state of accessibility. And for this, we have to look at where and especially how the majority of sites gets built.

Because reality still often looks somewhat like this: Neither the client who wants to spend as less money as possible for a site nor the agency that promised a stunning, state-of-art design are even aware of accessibility as an important topic to consider. Maybe, the client has heard of “response web design” (no typo) and of course they need tracking. KPIs FTW! But many just don’t know that a website explicitly has to be built to be accessible. Maybe some also just take it for granted. But certainly, it won’t be part of their project requirements.

Many agencies, then, are too busy getting miscalculated projects out of the door that pose a challenge on so many levels: All those different static Photoshop or Sketch layouts that now also have to be broken down into Atomic design components and documented in a style guide. Managing the creation of all of the content and then replacing it in the layouts again. Including last minute change requests by the client who “just doesn’t understand good design.” Then handing everything over to the other company that does the frontend development. Accessibility? Come on, we need to finish the job and, by the way, we’re already running out of budget! Also, the client didn’t ask for it, specifically! But we can maybe leave a note for the devs – that’s their responsibility anyway, right?

At the bottom of the food chain and with an unrealistically set deadline approaching rapidly, the developers are struggling with their build process and with making sense of poorly documented static layouts that have to be translated into React components or, alternatively, Twitter Bootstrap. That the external developers in Asia are working in a different time zone doesn’t help, either. Accessibility? That wasn’t a requirement, as far as I know. Maybe, if there’s some time left, I’ll add some ARIA roles in the end. Alt texts for images? Nobody sent us those.

Of course, there are countless other ways in which things for the Web get built and maybe I’m exaggerating a bit here and there – but then again, not so much. If an inaccessible site gets built, then obviously nobody thought of accessibility as being important enough to raise their voice, at no step of the process. But then again, nobody builds inaccessible websites on purpose. And that’s exactly why it is so important to never stop advocating for accessibility. Every day. Persistently and passionately. Because it still can work if we keep making noise.

That being said, this job is never done. We have to keep educating not only fellow designers and developers, but also clients and other stakeholders. It is vitally important that they, too, care and see the need for building inclusive experiences. It is hard work to raise awareness. Yet there is no other option. We can all do better – and never stop learning.

So follow people on social media, go to conferences and meetups and talk to people about their struggles and successes, read articles and newsletters, listen to podcasts and most importantly: Consider accessibility in every project you are part of. Ask why when accessibility isn’t considered, file bugs, and insist on improvements, regardless of your role in the team – because accessibility should be part of every step of the process. Plan with accessibility in mind, design with accessibility in mind, prototype with accessibility in mind, develop with accessibility in mind – and learn how to test it. There have never been better tools at our disposal. And then, share what you've built and what you learned along the way.

There really are no excuses for building inaccessible websites and applications in 2019. As Ethan wrote, we are all constantly under deadlines. But that’s no excuse for excluding people from a medium that still comes with the promise that it’s for everyone. It’s our job. Let’s not wait another thirty years. Let us fix this together.

Planning, Goals, and Uncertainty

People like to stick to their habits. Why? Because it is safer where they are now. Following a routine, a trusted pattern, reduces uncertainty about the future and thus alleviates fear. Everything is plannable and manageable. Tomorrow is safe.

The problem is: The future is unstable and change is inevitable. So each plan you make can only be a rough guess of where you will ultimately end up. Even if you were able to obtain all information there is about a situation, there are still so many factors that are beyond your control that from a rational perspective, planning – especially in a classical waterfall approach – doesn’t make any sense. So why people still do it? Because people like to stick to their habits. And because this is how you do those things as a professional, right? Also, what’s the alternative? You have to have a plan, right?

The reason why plans still work, to a certain extent, is that they invoke change. Not because the plan is laid out so nicely but because you set a goal that describes a state in the future which is not where you are now. And the feeling of control that the plan provides allows us to overcome our fear of change and take the next steps towards our goal, together. What keeps us moving isn’t the plan, it’s the goal.

This is not to say that you shouldn’t plan, or to be more precise, that you shouldn’t obtain as much information about a problem and its context as you possibly can – as if you were making a plan. Because when the future is most likely not going according to plan you have to be well-informed to react to different unexpected outcomes and challenges. So instead of making a plan, start by defining what it is you are trying to achieve, what change you are about to make and set a goal. Then try to generate as much information as possible by talking to stakeholders and users, by building prototypes and testing your assumptions, by exploring new materials and their combinations, by evaluating different contexts, by trying out different content and formats, and anything else that could make your design more resilient and adaptable.

There’s only one caveat: You will need to get comfortable with uncertainty, with moving from one decision to the next without a plan, without routines, without a handbook. This can feel daunting at first. But with your growing knowledge and experience, and a lot of curiosity, you will constantly gain more confidence in your ability to improve things as you go.

Convenient or Unique?

If you’re riding through the suburbs in a train, you might recognize that houses usually come in two flavors. For one, there are the townhouses: Tightly packed, not too large, repeatable, convenient. And then there are the individual single-family homes which come in all forms and sizes, small or large, each one unique.

Both types of houses have their advantages. If you are looking for the safe bet and don’t want to spend too much, the proven and reliable concept of a townhouse can reduce much of the risk involved with buying or building a home. Of course, you trade convenience for a more tailored solution. With townhouses, changes to the ground plan are less easy and especially on the outside, you will have to content yourself with something more ordinary. Individual single-family houses, on the other hand, offer much more flexibility and room for realizing your dreams. You are still restricted by the qualities of the building materials as well as things like architectural statics and, not to forget, the environmental context like ground conditions, groundwater level, binding site plans, et cetera. But other than that, you can realize a solution that perfectly fits your individual ideas and unique demands. Yet, this flexibility also comes at a cost: An individual solution like this will most likely be more expensive than a townhouse, it might take longer to build, and, depending on who you hire to do the job, you can’t be sure about the outcome in terms of build quality and timely completion.

This question – do we need a convenient or unique solution? – is also vitally important when designing a product or any kind of system for the Web. If someone approaches you with a specific problem to solve, whether it's a corporate website or a single component, it is important to consider which solution works best in the given situation. Does the budget allow for building something unique or are you better off with a convenient solution? Are you ready to take some risks – also the risk that your solution might be so unique that it doesn’t work – or should you go for the tried and tested pattern first?

As with so many things, the right answer depends on many factors that have to be assessed anew for each project or task at hand.

What I often see though is agencies or designers promising – or also clients demanding – something unique without checking first if this is really what they need. More than often, they would be better advised to consider the convenient solution. Because being unique is really hard and getting the convenient right can be hard enough. Don’t get me wrong: I’m not talking about setting goals that are too low or not ambitious enough. I’m talking about unrealistic expectations and the danger of investing time and energy into the wrong things. Because if you promise something unique but don’t realistically acknowledge what it means to walk that road, the result won’t be satisfactory. Even worse, you might find yourself in a situation where the unique solution falls short in terms of accessibility or performance and you’re already running out of budget to fix all of this.

Going for the convenient solution is often much more valid because it ensures an experience that gets the job done. Sometimes it’s also a start on which you can further improve upon, but still far better than pointless innovation for its own sake.

But how do you decide which solution is the best? Well, it depends. It depends on your budget, of course, but that should never be an excuse for building something that doesn’t cut the mustard. Above all, it depends on the purpose of what you are building and who you are building it for. Because the primary goal is to build something that works for the people who are using your product or service. What is the core of what they need and are you providing that in a respectful, appropriate, accessible, and useful way? Finding an answer to this question will most likely also answer the question if the convenient is the right solution or if it is worth going the extra mile for something truly unique.

And how do you know what your users want? By doing your homework: Research, prototyping, user testing. All of which are still neglected far too often. It’s up to us to change that.

Considering the Opposite

When you are developing a statement about something, this advice can be useful: If you can turn the statement into the opposite and it sounds like the most ridiculous thing on earth, chances are that your original statement isn’t that distinctive.

For example, if you were to say about your service that it provides “a great user experience”, the opposite statement, that is to say, that a service provides a “poor user experience” surely isn’t something anyone would strive for – let alone proudly tell the world about. So while you still might want to communicate that you provide a great user experience, it is obviously something that everyone else could say about their service as well. Focus instead on highlighting something that truly stands out.

This reframing of a statement into the opposite can also be helpful by providing a fresh perspective if you are designing or prototyping something: Is your solution really that innovative? Is it distinctive? Can it be turned into the opposite and what happens then? Does it become useless? Unusable? Harmful even? In this way, looking at the opposite can reinforce a decision because you now know for sure that the opposite isn’t an option at all.

Or is maybe the opposite worth considering, too? Which solution is better? Light or dark? Visible or hidden? Animated or static? Ordered or random? Contextual or unrelated? Inclusive or exclusive?

It might not be easier to decide. Harder even. But at least you considered the full spectrum.

Our New Design Overlords and a Remarkable Future

I spent the last days of 2018 listening to an amazing podcast: Stephen Fry’s Great Leap Years brilliantly tells the story of the evolution of information technology throughout human history – from Johannes Gutenberg inventing the printing press to Alexander Graham Bell and his Bell Labs changing the course of history to Google’s AI DeepMind winning against the world champion in the complex board game Go in 2016. For one, as Jeremy Keith puts it, “you’ve got the wonderful voice of Stephen Fry in your earholes the whole time”, but Fry also masterfully creates an overall picture of all the consecutive but also somehow magically intertwined events and stories that lead us to where we are now: A present and future full of wonder, opportunities, but also unprecedented challenges.

The world is about to change as fundamentally as it did as a result of the agricultural and then the industrial revolutions. We sleepwalked into the information age. Let’s not stumble as blindly into Humanity 4.0.

2019 will no doubt be the year we all finally realize that artificial intelligence, or AI, is not some distant thing of the future anymore. It has already begun to permeate the software tools we use and, as Ethan Marcotte rightly points out, “instead of asking ourselves if something can be automated, maybe we should start asking who’ll be affected once it is.” Also, because we as an industry will be one of the first to witness this sea change and experience its impact firsthand. The change is already visible in tools like Remove.bg, Let’s Enhance, or apps like Prisma – and also Photoshop uses a lot of AI these days. But it already goes much, much further than that.

Last October, I had the opportunity to visit the World Usability Congress in Graz, Austria. One of the speakers, Sean Chiu, talked about how Alibaba, the world's largest retailer, uses AI to produce or, dare I say, “design” artwork for their e-commerce platforms. Alibaba created an AI called Luban(鹿班) that generates millions of high-quality, customized website banners each day. Millions of layouts. Each day. You can see it in action here: https://www.youtube.com/watch?v=C4izVFzarug John Maeda’s 2018 Design in Tech Report states that there are 1 million banner or e-commerce designers in Alibaba’s ecosystem – and 70 % of them face the challenge from Luban. So will designers lose their jobs to AI? Yes. Maybe not immediately and of course mainly regarding certain repetitive and tedious tasks but the way we design will – once more – alter drastically with photo editing and layout being only the tip of the iceberg. According to the Design in Tech Report, AI and machine learning is the number one emerging trend to have the biggest impact on design and future design tools with further developments in AI will possibly…

1. Construct models of our customers

2. Generate design directions on their own

3. Sort and prioritize competing constraints

4. Identify best potential ROI and more

5. Enable savings in time for designers

6. Run experiments for us and reduce risks

7. Create many variations to test

8. Scan the entire experience for inconsistencies

9. Prevent re-invention of past solutions

10. Have the potential to remove apprentice-level jobs

And those are only predictions. Maybe you’ve heard of other predictions that drastically underestimated the radical change of technological innovations, like the famous prediction by Thomas Watson, president of IBM, from 1943: “I think there is a world market for maybe five computers.”

Each time a technological breakthrough changes the way our world, our society, and our culture works, the implications are unlikely if not impossible to predict. Because, as Jeremy Keith notes in his talk “Evaluating Technology”, they create a form of singularity which means that “there is no way, that we, from our vantage point here, in the present, can possibly see what’s beyond that event horizon of the technological singularity.” Who could have guessed that it would be completely natural to talk to any person around the world via telephone? Who could have predicted that people would rearrange their living rooms around television screens that bring them news and entertainment? Who could have foreseen that people would spend hours and hours of their day looking into mobile glass devices that act as a magic door to a World Wide Web? No one.

Yet although it is almost impossible to predict the magnitude and quality of the transformative change that lies ahead of us on so many different areas, we can still be aware that this fundamental change indeed is happening and, most importantly, we can still actively influence, shape, and develop it in the right direction. Because regardless of where we live on this planet, we are all also facing many other challenges aside from the fourth industrial revolution like climate change, poverty, unnecessary wars, human diversity, social inclusion, equality, and above all: climate change. Technology can help us save the world from harm but it can also cause more suffering.

Robotics, AI, nanoscience, the Internet of Things, quantum computing, genomics, gene editing, bioaugmentation, bionics, autonomous weaponry and transport, brain-machine interfacing – all these existentially transformative developments are gathering pace and momentum now. And when they converge and coalesce, they will create a remarkable future.

A future that lies beyond our imagination. Let us at least make sure that it, in fact, will be remarkable.

Drives safe!

We all know that we should backup our data regularly and ideally with some sort of backup strategy but let’s be honest: Many of us don’t. Over the years, I got a bit better, but after listening to one of the highly recommended episodes of the (mainly German) Working Draft podcast, it became obvious to me that there was still a lot of room for improvement. So I used some spare time over the holidays to spruce up my backup setup. In this post, I’ll share what I did – maybe it inspires you to do something similar or you might have much better ideas, in which case I would love to hear from you, of course. A warning upfront: I use MacOS, so this post might be of less use here and there if you prefer any other operating system.

The current situation

Daily backups: Non-existent.

Yes, this is pretty bad, I know. I used to have an external drive for a Time Machine backup but over time I completely stopped doing regular backups of my MacBook Pro’s hard drive. And although SSDs are much more reliable than SATA hard drives, you never know when disaster strikes (knock on wood…). So obviously, this was one of my major pain points I wanted to improve.

Home server solution: Synology Disk Station

A few years ago, I bought a Synology DiskStation DS214+. It’s a two-bay NAS server that comes with a lot of useful features for setting up your own little datacenter including a “cloud” solution that works a bit like Dropbox. I configured it so that I have one network volume called ARCHIVE and one called HOME. The ARCHIVE is where I move completed projects and all the other stuff I still need to tidy up one day but I definitely don’t want to lose. The HOME network volume is for daily work and automatically synced with a folder of the same name on my work computer – although I often switched off automatic syncing via the Synology Cloud Station application, because it slows down my Mac quite substantially – especially if I use a watch task in a tool like Gulp, for example. Overall, this setup worked quite well and gave me peace of mind regarding my work files, also because the two 2 TB hard drives are combined in a RAID, so if one hard drive fails I still have the other one.

The main problem with this setup was that the 2 TB RAID was filling up and was in danger of running out of space. So I was in need of a storage upgrade.

Upping the game

Step 1: Upgrading storage capacity

To expand the storage capacity of the Synology NAS, I bought two 4 TB Western Digital Red hard drives which are optimized for use in NAS systems. The upgrade process itself was astonishingly easy – and yes, I use the word easy intentionally here, because it indeed was easy: I replaced one of the old 2 TB drives in the NAS with a new 4 TB drive. Then, I went into the Storage Manager of the Synology DiskStation Manager (DSM) and started a Repair of the degraded RAID storage pool. After the successful repair, which took a few hours, the two drives were in synch again so I then replaced the second old drive with a new one. I started a Repair again – done. Here is an article that explains the process.

Step 2: Wireless Time Machine backup

A Time Machine backup is a super convenient way to back up your work machine, but I didn’t want to fill the precious space of my NAS with incremental backups. So I put one of the old 2 TB drives inside an external HDD case to plug it into the USB 3.0 port of the Synology.

But before I connected it to the NAS, I formatted the external 2 TB drive with MacOS’s disk utility. Side note: Since MacOS High Sierra, MacOS switched to the newer Apple File System (APFS) which is also used by iOS, tvOS, and watchOS. Time Machine can’t make use of the new file system though, so if you want to use a hard drive with Time Machine, make sure to format it using the Mac OS Extended (journaled) aka HFS+ file system.

But, as it turns out, this step wasn’t necessary. The Synology already comes with the option to create a shared volume for Time Machine backups and for that, the drive can perfectly be formatted with ext4, a journaling file system for Linux. So I reformatted the external USB drive again, renamed the shared folder of the drive to TMBACKUP, enabled Bonjour Time Machine Broadcast via SMB in the DSM, and selected TMBACKUP as the Time Machine folder. After that, I was able to mount the TMBACKUP volume on my Mac and select it as the backup disk in the Time Machine system preferences. If you’re interested in the whole process, there is a helpful article in the Synology Knowledge Base.

Ultimately, after a pretty time-consuming first Time Machine backup, my MacBook Pro’s hard drive is now backed up hourly via WLAN onto the external USB drive connected to the NAS. Yay!

Outlook: Physical separation

So after all this tinkering with hard drives and DSM settings, I now have much larger storage capacity and a wireless Time Machine backup up and running. The last thing to do is to find a nice way to keep another backup copy offsite, which is especially important for the ARCHIVE.

Patrick suggested that I could buy a cheaper or used Synology to remotely backup the main Synology and this seems to be a pretty compelling solution. Another idea would be to rent storage online. I haven’t yet decided what to do regarding physical separation, all I know is that I don’t want to manually copy any data because I won’t do it anyway then.

Overall, I’m already much more satisfied with my setup than before. But now I’m also curious: How do you back up your data? Do you keep a backup offsite and if you do which solution did you choose? I would love to hear from you via Webmention or Twitter – or write me a good ol’ email.

Crazy Work

I have a confession to make. I’ve become utterly terrible at finishing books, especially non-fiction. I once even published a list of books I will definitely maybe read one day. The reasons why I don't finish them are manifold: For one, there is always some work to do that seems more important than to sit down and read a book. Then, I have a lovely family and I spend as much time as I can with them. And ultimately, there is the Interwebs demanding “screen time”. So I had not finished a book in months.

Last Friday, I did.

The book is the latest one by David Heinemeier Hansson and Jason Fried, the founders of Basecamp, and it’s called It Doesn’t Have to Be Crazy at Work. It is a collection of ideas and advice about how to establish and maintain a “calm” company culture, without the hassle and craziness that seems to have become the new normal in tech, design, and often also in business in general. Yet the book is not only aimed at founders or executives but also full of useful advice for everyone working anywhere, regardless of position or if they work at a company or are self-employed.

The main message is as true as it is often left unsaid: At many places, work has become this ugly, greedy beast that wants you to work for 60, 70, or even 80 hours a week and robs you of your time with family and friends, your sleep, and, ultimately, your health.

Sustained exhaustion is not a badge of honor, it’s a mark of stupidity

The answer, according to the authors, isn’t more hours, but “less bullshit”. Fewer meetings, less distractions, less unrealistic deadlines, less false promises, and more focus on the real important work.

Through my work as a freelance designer, I have seen quite a few companies and their different approaches to company culture and processes. David and Jason are definitely right: At many companies, unnecessary work, artificially created tasks, and – especially in open-plan offices – repeated distractions absorb most of the time there is to do your work. What you end up with is a cluttered day, where you don’t have the time to focus on a task for a few hours straight or to thoroughly think something through. Combine this with unrealistic deadlines like a website launch date set by a client upfront or rash overpromising by project managers without getting a second opinion from the people doing the work and you are right on track for a project full of stress and compromises. What a waste of energy.

It Doesn’t Have to Be Crazy at Work provides important, sane, and actionable advice on how to change all of this and I cannot recommend it more. I can’t wait to give many of the ideas a try.

A few days before I bought the book, I listened to a great conversation between Jeffrey Zeldman and Jason Fried on the Big Web Show that also covered the book, so I already had a pretty good idea about what to expect. Maybe that’s the reason why – in the spirit of the book and despite the busy last weeks of the year – I took the time to unwind a bit and read it calmly from start to finish. It already felt like a first step on the road to recovery.

Infused Design Attitude

I recently listened to an interesting episode of the podcast “The Design of Business | The Business of Design”, in which Jessica Helfand and Michael Bierut talked with Mariana Amatullo, who teaches strategic design and management at Parsons School of Design at The New School in New York.

One of Mariana’s fields of research is how and when design works in large organizations. According to Mariana, whether design-oriented approaches to business succeed or not is largely determined by the level of a “design attitude” found not only in designers but also leaders and organizations as a whole. This design attitude consists of five dimensions:

The first one is empathy. We really work with design students around this notion of empathy.

The second one is creativity — being able to look at the novel.

The third one is engagement with aesthetics, and thinking about a multisensorial environment.

The fourth one is ambiguity tolerance.

Number five is connecting multiple perspectives — the divergence we talk about a lot in design thinking methods.

In my work with clients of all sizes, I found this indeed to be true: The more pronounced the elements of this “design attitude” are in a person or a group of stakeholders, the better the outcome of a design project will be. If you are working in an agile setting and are building a lot of prototypes, for example, you will always encounter reluctance if the people looking at the work have a low ambiguity tolerance, which means that they are getting extremely uncomfortable if things look unfinished, raw, and not precisely defined yet. In design though, especially when you consider today’s diverse, heterogeneous environment we need to design for, it is almost impossible to precisely plan upfront. You need to be comfortable with tackling completely new problems with only partially pre-determined processes with uncertain outcomes. Clients often struggle here, because they are used to having control over things and making decisions before the work starts. But that’s not how iterative design works nowadays.

The same is true though for the teams creating the design. Each one of the aforementioned traits is crucial if you want to build a product based on considerate, appropriate decisions together because you are able to avoid long discussions arising purely from matters of taste or snap judgments. The level of design attitude can then also make a difference when it comes to articulating design decisions to a client – and also if you need to defend those decisions with vigor if needed. I have seen more than a few design teams struggle not because the clients didn’t “get design” but because parts of the agency were obviously lacking a design attitude, too.

Design attitude can be seen as a form of design literacy. The more design-literate your organization is, the more it values design which in turn results in better user experiences. Someone who often brings this idea forward in articles and talks is Jared Spool. While he has been getting a lot of pushback recently for repeatedly stating that everyone involved in creating a product is influencing the design and thus everyone is a designer, Jared is certainly right with the basic idea that to become more design-literate, teams need to spread the knowledge and expertise of design beyond just designated designers:

Every developer and product manager must become literate in the differences between bad design and good design. More importantly, they must also be literate in the differences between good design and great design, so they strive for excellence at every opportunity.

An organization that successfully makes the transition into an organization where everyone has a high design literacy – by consistent exposure to users, a solid vision of the aspirational user experience, and embracing a culture of continuous learning – can then reach a state of “infused UX design”, as Jared calls it.

While I already had a good understanding of the why and the how of improving design literacy, the what still wasn’t that clear to me. What traits or skills should we focus on if we want to improve design literacy in our organization? Mariana Amatullo provided a possible answer to this question.

I really like the idea: Becoming a design-infused organization by facilitating empathy, creativity, aesthetics, ambiguity tolerance, and the ability to connect multiple perspectives – in every individual in your organization.

Infused design attitude, so to say.

Overflow: unlimited

This morning, I read a tweet by Dave Rupert that made me smile:

Hey, Internet. My son loves drawing. This is great. My house is filled with 1000s of pieces of paper tho. This is not so great.

Has anyone converted a ~5yo to an iPad or Surface Go for drawing? Does it work? Is there another strategy to limit Papergeddon?

— Dave Rupert (@davatron5000) November 20, 2018

I had to smile because it’s exactly the same with my son. He is seven now and has been producing drawings since he was able to hold a pen. He can sit for hours in his room and draw dragons, knights, pirates, robots, superheroes, machines, factories, or also computer games. He produces new pieces faster than we can sort them out so we decided to buy a huge box for everything he spits out. This box is now overflowing regularly and so we need to still clear it out from time to time. Meanwhile, I am honestly impressed by how skilled, fast, and confident he has become. It’s amazing to watch and in a way, he is already better at drawing than me. Most certainly, he is so much more unafraid and less occupied with what is a right or wrong way to draw. He just does it. I have been thinking a lot about how this came to be. And I believe it comes down to this: not limiting him.

Of course, you also need to have a bit of talent and a general interest in drawing. But then again, which child doesn’t? But what happens to so many kids is that, beginning already in Kindergarten, they are constantly being evaluated and teachers and parents start to tell them how to draw correctly. “Is this supposed to be a tree? It doesn’t look like a tree at all! And why is it blue and purple? Let me show you how to draw a proper tree!” And after some time, kids get so occupied with drawing things “the right way”, that they forget how to doodle and invent and explore and play and dream. What they are also told, is not to waste precious paper with careless scribbles but instead to carefully consider what to draw. But while there is certainly a time and place for conceptual considerations, by giving such narrow-minded adult advice we are limiting the scope of what our kids could create before they even started. The idea that it is better to carefully craft one fine piece of art than to produce a wealth of seemingly flawed experiments is flat wrong.

Nobody will ever become as good a painter as Pablo Picasso by painting just a handful of paintings. The number of artworks Picasso created has been estimated at 50,000. Nobody will ever become as good a composer as Mozart by composing just a handful of pieces. Mozart composed more than 600 works until his early death at the age of 35. And nobody will ever become as good a blogger as Seth Godin by writing only a handful of posts. His blog has been appearing daily for more than a decade.

What I am trying to say is: Regardless of what it is – if you want to become really good at something, you will need to do it over and over and over again. And while you are practicing, you need to realize that there is no right or wrong and only if you fearlessly explore and try out things, you will reach a state of fluency. Also, get comfortable with producing a lot of stuff that might look like junk. It isn’t. It’s the most valuable output you could ever create. Because only by drawing a line a thousand times, you will finally own it.

What is it for?

Yesterday, I shared some advice by Seth Godin from an interview with Chase Jarvis. Today, I’ll do the same again, but not because I’m lazy (at least not this time) but because I think it’s a great follow up and just as actionable and useful advice.

It goes like this: Whenever you need to communicate, write, build, or create something, always ask yourself

What is it for?

This sounds like the most obvious thing in the world to ask, but how many times have you been part of a project where you built something just because you were told to do so or because everybody does it this way? Or how many times have you seen clients demand changes that obviously had nothing to do with the purpose of the project? And how many times have you started a task without really knowing what it really is for? Far too often, this simple and important question is neglected.

Am I a professional who is doing this in a way that the work matches what the work is for?

Asking yourself this question can completely change the way you approach your creative process, how you plan what to build and what to focus on. It makes sure you consider the true purpose of the work you are doing. It lets you eliminate the unnecessary and ambiguous. But most importantly, if you have found an answer to this question, it gives you the confidence to march into the unknown, to try out new things without knowing if they will work, and to be persistent, patient, and passionate – because you know why you are doing it.

This works for whatever you are up to – whether you are writing a blog post or a newsletter, planning an event, taking pictures, running an agency, coding a website, or building a prototype. So whatever it is that you are working on at the moment: What is it for?

Unlimited Bowling.

Last weekend, I listened to a highly interesting episode of the Chase Jarvis Live Show, a podcast featuring interviews with creators, innovators, and entrepreneurs. The episode’s guest was Seth Godin and as you might expect, he dropped a lot of knowledge and good advice. And while there was a whole lot more to take away from the interview, I especially liked what Seth said about content creation, using the analogy of bowling:

One of the drivers of bowling is you gotta pay by the game. So if I only got three games, I gotta be careful with my rolls.

What would happen if you had unlimited bowling? If you had unlimited bowling, you could practice different shots, you could practice different approaches, don’t worry about it! […]

That’s where we live now: Unlimited bowling.

So we gotta decide: Are we just constantly trying to get it just right down the center – which is boring and isn’t gonna get us anywhere. Or do we have the guts to say: You know, this might not work. But I’m gonna persistently and consistently and generously bring it forward. […]

If you’re asking for a guarantee, you’re in the wrong line.

This advice is gold if you are writing a blog, for example. What you write is totally up to you. And because you have unlimited shots on the Web, you can try out different formats, different styles, different topics. Regardless of what other people might think and although it might not work.

But this advice is also gold when you are prototyping user interfaces. Because prototypes are so inexpensive compared to high-fidelity solutions, you can easily try out different approaches to solving your problem, although it might not work.

That’s where we live now: Unlimited prototyping.

Never done.

I spent two weeks in August visiting my sister in New York. It was the first time for me in New York and one of the things that impressed me the most, was the perpetual movement of the city. This city really never sleeps. Everything seems to constantly evolve and change. Even such an evolved and established system as the Subway, which is now 114 (!) years old, isn’t at all “done”. For example, closed platforms in the south of Manhattan tell of the changing ridership over the years when more and more people started to work in Midtown Manhattan. The system adapts to the changing city. Somehow, New York felt like an agglomeration of interwoven systems that all have a prototypical element to them. Rough. Unfinished. Constantly exploring what works and what doesn’t. I really like that.

I wish more projects were like that: Acknowledging the fact that the world around us is constantly changing and we are therefore never really done.

Out there.

Recently, I read two posts within a few days that both resonated a lot with me. The topic of both pieces was the same: Writing. Or more specifically, writing on your own site. The first piece, “Just write.”, is by Sara Soueidan and if you haven’t read the article, I highly encourage you to do so. Besides the general advice that you should just write, no matter if people read it or not, what stuck in my mind the most were those two short sentences:

Once I got over my own obstacles, I stopped feeling like I was obligated to meet other people’s expectations. I started enjoying writing again.

Over the last two and a half years, I have published a few articles on this site. Most of them were quite lengthy, but I was fine with that, mostly because I cared deeply about the topics and also wanted to explore them for me. The feedback I received for those articles was very positive (thank you all ;) ) and I still feel that starting to write on my own site was one of the best decisions of my life. So if you think about starting to write yourself, I can only join Sara in saying: Just write.

But if you take a look at my site, you’ll see that the last article dates back to January 2018. What happened? Looking back, it was a combination of a few things. One is that I started writing a monthly newsletter about prototyping for the Web, Prototyping.news, which I really enjoy, and another being the feeling that each new article had to be at least as good as the one before. I felt “like I was obligated to meet other people’s expectations” – if only a small but lovely group of people. While this can be a good thing and there is generally nothing wrong with aiming high, it can also have the effect that you start to constantly question yourself and your writing. As a result, the draft of an article about prototyping is still on my computer, waiting to be finished since the beginning of the year.

The second post I wanted to share with you is by Tobias Tom. The post is not an article, it’s a quick note on his site, so short that I can share it in its entirety with you:

Starting today I’ll try again to use this thing more again. More short notes, more links, and even more how-tos.

Why? Because if one word or link helps someone else out there, it’s better then nothing.

I’ll also try to force it into my habit. Starting goal is one post a day. Including the weekends. Phew.

This quick note somehow is like a self-fulfilling prophecy: Even the smallest post can help someone else out there. In this case, this someone is me, seeing that others struggle to publish regularly, too. But no matter what expectations you think there are, it is important to get your thoughts out of your head. Even the rough and unfinished ones. You need to share your experiences because you never know whom it will help.

So starting tonight, you can expect (haha) more posts from me again. Because I now understand that the most important thing about writing – just like with any type of work – is to get it out there.

Starting Prototyping.news

Prototyping has been captivating me for quite some time now. Since 2012, I teach Interface Prototyping at the Muthesius University of Fine Arts and Design in Kiel, Germany and especially over the last few years, I could watch prototyping slowly attracting more and more attention in the Web community. And at the moment, the topic is gathering even more momentum: Tools like Framer, Adobe XD or also Sketch (with InVision’s Craft Plugins) are rapidly evolving into the next generation of design tools, with prototyping baked right in. More and more articles and talks about prototyping are seeing the light of day and there are many good reasons to believe that prototyping is central to developing products for a Web that is as flexible and diverse as ever.

At the same time, it is also harder than ever to stay up to date on all the different topics in Web design and development. One way to fight this is to rely on weekly or monthly newsletters, curated by people who care about the respective topic. I really appreciate those updates, for example Rachel Andrew’s CSS Layout News, Val Head’s UI Animation Newsletter, or Anselm Hannemann’s invaluable Web Development Reading List.

So I’m starting something new in 2018: Prototyping.news, a carefully curated newsletter all about prototyping for the Web – for strategists, designers, and developers.

The basic idea is, of course, to provide all those of you who are interested in prototyping with an easy way to read, watch, and hear interesting and entertaining content about prototyping. Starting with the first issue, you will find links to articles, talks, tools, and everything else related to prototyping for the Web in your inbox. But I also want prototyping.news to be a prototype itself. So it should be flexible enough to evolve over time, adapting to the developments in the community. However, I don’t yet know exactly how this iterative improvement will look like. We’ll see.

Under the hood, the website for prototyping.news runs on Kirby, Bastian Allgeier’s neat file-based content management system, which is really a joy to work with. The setup is super easy and fast, you have full control over your template code and, as it is a file-based CMS, I can simply write the newsletters in Markdown an put them in the archives folder for publishing. This is exactly the kind of flexibility and convenience I wanted to be able to iteratively improve prototyping.news. If you haven’t worked with Kirby yet, I suggest you give it a try. It is super flexible and perfect for small to medium-sized web projects of every kind.

The website for Prototyping.news is hosted on Uberspace, the friendly German pay-as-much-as-you-want hosting provider. Setting up a new U7 uberspace was also super fast and convenient. With a few clicks and shell commands, you have a modern environment up and running: HTTPS via Let’s Encrypt with automatic renewal of your certificates and HTTP/2 is included, and even the most important security headers are already set for you.

The newsletters will be delivered via MailChimp for now. Depending on how the project evolves, I'm considering switching to a different solution, most likely Mailtrain.

Prototyping.news is a personal project that will always be free for its readers. At the moment, I don’t know if I will set up something like a voluntary PayPal donation. It is just too early to tell how the project evolves. But if you have a product or business somehow related to prototyping you can support the project by sponsoring an issue. If you are interested in that, please do get in touch.

I really hope that prototyping.news will be a helpful resource to everyone interested in the topic. If you have any ideas or feedback, or if you stumble upon an interesting link that you think should be included in the next issue, please don’t hesitate to write me a message – on Twitter, for example, or via the good old email.

The first issue of Prototyping.news is almost ready and like all issues it will be published on the last Friday of the month. If you haven’t signed up yet I’d be happy if you do so here.

Write Your Media Queries in Pixels, Not EMs

In all of my latest projects, I was using em units for writing media queries, just like so:

@media (min-width: 30em) {
	/* CSS for viewports >= 480px */
}

I had switched to em units some time ago because writing pixel-based media queries seemed to be the inferior solution. At first, because browsers used to handle zooming really bad, like Lyza Gardner had shown in 2012 in her article The EMs have it: Proportional Media Queries FTW!. And although the zooming behavior has since been made consistent, another article made a strong case against using pixels for media queries: Zell Liew showed in a couple of Codepen experiments that although most browsers handled pixel-based media consistently, Safari was the party pooper that still didn’t handle pixel-based media queries properly.

But yesterday, I stumbled upon an article by Alastair Campbell‏ in which he states that the advice to not use pixels in media queries should be considered a myth. I got curious: Maybe the Safari bug from back then had been resolved in the meantime and using pixel-based media queries was safe now?

So I looked at Zell Liew's article again and tried to find the Codepen he had used. I could not find it but found one further down in the comments. It was by a user named Ola who repeatedly pointed out that Safari was indeed handling media queries in the wrong way – but contrary to what the article suggested, not the ones that used pixels were problematic, but the em and rem media queries.

So I looked into it and it indeed seems like he is right. Safari handles pixel-based media queries correctly when the user zooms. If, for example, the zoom level is at 125 %, a min-width:400px media query correctly “fires” at a width of 500 device pixels.

You can try it out yourself. Open this Codepen in Safari and change the zoom level to 125 %. Then change the width of the browser window until the media queries kick in. And while the pixel-based behaves correctly, the em-based media query is triggered at a width of 625 device pixels. Obviously, Safari multiplies the font-size as well as the value in the media query by 1.25:

16px * 1.25 * 25 * 1.25 = 625px

Alternatively, look at this test page with Safari and zoom in/out (and compare it to any other browser): http://output.jsbin.com/ubuvay/4. There's also a related Webkit bug report (41063).

So until this issue gets resolved, it seems like we have to change the recommendation regarding media queries once more: For the most consistent cross-browser behavior, write your media queries in pixels, not ems.

What do you think? Am I missing something here, maybe? And how do you write your media queries? If you write an answer and link back to this article, you can add it via the form below and it will appear in the Webmentions section. But you can also write via Twitter or email, of course. I'd be very happy to hear your opinion.

Colorful Code: Adding Syntax Highlighting to My Site

In all of the posts I published on my site so far, I’ve never shared a single line of code. But since this is going to change with the next article on pattern libraries, I spent a little time over the weekend implementing syntax highlighting for my posts. I settled on Lea Verou’s Prism, a lightweight, extensible syntax highlighter for the Web. It is used by sites like Smashing Magazine, A List Apart, or CSS-Tricks and it is dead simple to use. Just include prism.js and wrap your code in <pre><code> tags and Prism does the rest for you. The styling is done through CSS, so it is up to you if you want use one of the many ready-made themes or prefer to write your own styles. I decided on the latter as it promised to be fun and I wanted to see how theming is done for syntax highlighting.

The resulting theme is loosely based on GitHub’s styles so that it feels familiar, but it aims to be a little bit more intensively colored without being too colorful because the main goal of syntax highlighting is to improve the readability of code. So below you will find some examples of Prism in action. Feel free to write me if you have any remarks or questions.

<!-- HTML / Handlebars -->

<form class="webmention-form" method="post" action="/{{ craft.webmention.settings.endpointSlug }}">
	<label for="webmention-source">Have you published a response to this? Send me a <a href="http://indiewebcamp.com/webmention">webmention</a> by letting me know the <abbr title="Uniform Resource Locator">URL</abbr>.</label>
	<input type="url" name="source" id="webmention-source" placeholder="URL / permalink of your article">
	<input type="hidden" name="target" value="{{url}}">
	<button type="submit">Ping!</button>
</form>

/* CSS / Sass */

// Variable
$primary-color: hotpink;

// Mixin
@mixin border-radius($radius) {
    -webkit-border-radius: $radius;
    -moz-border-radius: $radius;
    border-radius: $radius;
}

.my-element {
    color: $primary-color;
    width: 100%;
    overflow: hidden;
}

.my-other-element + .my-element:first-child {
    @include border-radius(5px);
}

/* JavaScript */

/* MIT license http://www.opensource.org/licenses/mit-license.php/
 * @author Lea Verou http://lea.verou.me
 */

var Prism = (function(){

// Private helper vars
var lang = /\blang(?:uage)?-(\w+)\b/i;
var uniqueId = 0;

var _ = _self.Prism = {
	manual: _self.Prism && _self.Prism.manual,
	util: {
		encode: function (tokens) {
			if (tokens instanceof Token) {
				return new Token(tokens.type, _.util.encode(tokens.content), tokens.alias);
			} else if (_.util.type(tokens) === 'Array') {
				return tokens.map(_.util.encode);
			} else {
				return tokens.replace(/&/g, '&').replace(/<\/g, '<').replace(/\u00a0/g, ' ');
			}
		},

		type: function (o) {
			return Object.prototype.toString.call(o).match(/\[object (\w+)\]/)[1];
		},

		objId: function (obj) {
			if (!obj['__id']) {
				Object.defineProperty(obj, '__id', { value: ++uniqueId });
			}
			return obj['__id'];
		},

		// Deep clone a language definition (e.g. to extend it)
		clone: function (o) {
			var type = _.util.type(o);

			switch (type) {
				case 'Object':
					var clone = {};

					for (var key in o) {
						if (o.hasOwnProperty(key)) {
							clone[key] = _.util.clone(o[key]);
						}
					}

					return clone;

				case 'Array':
					// Check for existence for IE8
					return o.map && o.map(function(v) { return _.util.clone(v); });
			}

			return o;
		}
	}
}

/* PHP */

class WebmentionPlugin extends BasePlugin
{   
    function init() 
    {
        // Require dependencies (composer)
        require CRAFT_PLUGINS_PATH.'/webmention/vendor/autoload.php';
        craft()->on('entries.saveEntry', function(Event $event) {
            craft()->webmention->onSaveEntry($event);
        });
        # sections.onDeleteSection
        craft()->on('sections.onDeleteSection', function(Event $event) {
            craft()->webmention->syncEntryTypes();
        });
        # sections.onSaveSection
        craft()->on('sections.onSaveSection', function(Event $event) {
            craft()->webmention->syncEntryTypes();
        });
        # sections.onSaveEntryType
        craft()->on('sections.onSaveEntryType', function(Event $event) {
            craft()->webmention->syncEntryTypes();
        });
    }
    public function getName()
    {
         return Craft::t('Webmention');
    }
    public function getVersion()
    {
        return '0.3.1';
    }
}

We Are Team Internet. We Need to Save #NetNeutrality.

Once more, net neutrality is under attack. This founding principle of the open web guarantees that all data packages are treated equally – regardless of content or the amount of money you pay your service provider. Net neutrality keeps the internet open and uncensored and by that fosters freedom of speech and an exchange of ideas.

Today, 12 July, is the internet-wide day of action to save net neutrality. And we all have a voice and a responsibility to stop this threat to the open web.

So join the protest by adding an alert to your site, change your avatar, spread the word on social media, or do what you do best to fight for net neutrality. To learn more, visit battleforthenet.com or read more about why the 12 July protest to protect net neutrality matters.

We need to stop this together. We are team internet.

–

Thanks to @webrocker for the reminder!

Adding JSON Feed to My Craft CMS Site

Despite the proclaimed death of RSS I know a lot of people who still love to read their feeds on a daily basis. So feeds are definitely here to stay and providing your readers with different ways of consuming your content is also an important part of a website, especially if you consider yourself (and your site) part of the open web.

Recently, Manton Reece and Brent Simmons announced an interesting new feed format called JSON Feed. As its name implies, JSON Feed is similar to RSS or Atom, but it uses JSON as the format for syndication. This has some advantages over XML, for example that it is far easier to read and write. Manton and Brent also have the hope that the lightness, simplicity, and flexibility of JSON Feed will encourage people to develop for the open web. And JSON Feed indeed is not complicated at all. For an overview of the structure, have a look at the spec. There is a JSON Feed Viewer, made by Maxime Vaillancourt, that showcases some feeds and is also great for testing your own feed, once it’s ready. Besides that, popular feed readers like Inoreader or Feedbin already added support for JSON Feed.

So I decided to give it a go and implement JSON Feed on my own site, too. Just to get an idea of what’s possible, I first looked at some sites that already provide a JSON feed, e.g. the sites of John Gruber (who also talked with the co-authors of JSON Feed on his The Talk Show podcast) and Jeremy Keith.

After that, I evaluated different ways to easily provide the feed with Craft CMS, the content management system I use for my website. For one, you could simply output a frontend template under a route, for example “/articles/feed.json”. But I decided to use a more flexible solution: The Element API plugin. Element API is a powerful plugin vor Craft that makes it really easy to create a JSON API for your entries. You simply define an array of API endpoints in a single PHP file within your craft/config folder and the plugin will do the rest automatically for you. There is also a basic example of how you can set up a JSON Feed with Element API, which is a good starting point.

With Element API, setting up a JSON Feed for my articles section turned out to be really easy. The only part that needed more care was to find the best way to pull out matrix blocks. I now simply loop through the blocks and add the individual data to the response string. If you also need to parse markdown, the parseMarkdown() function of the StringHelper class is really useful.

So you can now subscribe to my JSON feed for the articles section or have a look at it in the JSON Feed Viewer. If you have any feedback or encounter any problems, please let me know. Within the next days, I will also add feeds for the notes and links sections.

Progressive Search

Today, I added a basic weighted search to this site. You can find it here and in the footer below. Providing a search functionality is one of the pillars of an IndieWeb site, mainly because it offers improved access to the content you create and own on your site. But: Search on personal and corporate sites is a somewhat difficult topic. On the one hand, offering search more or less is imperative, but on the other hand, it is hard to get right. Most users are used to the comfort of those insanely accurate search results of Google's sophisticated artificial intelligence algorithms. Of course, this is something a normal website hardly can compete with. Nevertheless, you have to find ways to provide a sufficient search experience to your users.

For now, my site uses the standard search of Craft CMS, improved by a weighted search plugin. This is a solid start but I want to find ways to gradually improve the search experience for visitors of my site. If you look at what makes a good website search, things to consider include:

• relevant search results
• providing a good “no results” page with a path forward
• suggesting synonyms and alternative terms
• recognizing typos and misspellings and offering guidance
• autocomplete for search terms
• using a stop word list
• displaying search results by category
• faceted search or filters

This list is by no means complete and probably I won't be able to implement all of those points. My goal is a convenient search that optimally supports the content of a personal site, offers accurate results presented in a useful and usable form, and is as fault tolerant as possible regarding user input. Or, as John Postel said:

“Be conservative in what you send. Be liberal in what you accept”

So I will take this core functionality and, focussing on the most effective design decisions, enhance it. Bit by bit. Progressively.

Data loss (also) by JavaScript

Tantek Çelik wrote a post in 2015 called “js;dr = JavaScript required; Didn’t Read.”. It was about a fundamental problem regarding sites that depend on JavaScript for rendering content: Indexability. Although search engines got much much better at indexing JS, it still remains a major problem, which I learned the hard way a few weeks ago.

On October 30, Readability closed down its “read it later” bookmarking service. Although I had not been a regular user of the service, I had created a fair amount of lists of interesting links for the students of my Interface Prototyping seminar using a site called readlists.com, a service by Readability that depended on the Readability API – and JavaScript (require.js, to be exact).

Unfortunately, Readability went offline pretty quickly, giving all users only 30 days to export their personal data. Somehow, I must have missed the Medium article or an email that announced the shutdown. So I learned about it the hard way when I opened the site with my students. No lists. No links. Gone.

Not too big a problem, I thought. And a good opportunity to show the students the beauty of the Internet Archive! But when I went there to look at the snapshot of the site, I stared at this:

I don't want to blame the people at Readability for shutting down their service. It is also totally their decision when and how fast to go offline. But one fact remains: Once again, many users irreversibly lost their data. And this was not only due to the fact that the site was shut down, but mainly because the content was dependent on JavaScript (and an API) in a way that made it invisible to the crawler of the Internet Archive – and by that dead to history.

After five years, all that remains of Readability is a spinning wheel in the Internet Archive and a Wikipedia article.

Or, as Tantek puts it:
“If it’s not curlable, it’s not on the web.”

Books I Will Definitely Maybe Read in 2017

It’s that time of year when most people publish their „books I have read“ articles. Tim for example, and also Jeremy. I for myself am what you could call a book taster. There are a lot of books on my shelves that I started reading but somehow never finished. But this year this is going to change. Maybe.

So here’s my list of books I want to finish in 2017. By pure chance, a lot of them have the word “design” in their title. ;)

• Inclusive Design Patterns by Heydon Pickering (I’m already halfway through this one!!!!!)
• Resilient Web Design by Jeremy Keith
• Adaptive Web Design by Aaron Gustafson
• The Shape of Design by Frank Chimero
• Pricing Design by Dan Mall
• Demystifying Public Speaking by Lara Hogan
• Design for Real Life by Eric Meyer & Sara Wachter-Boettcher
• Just Enough Research by Erica Hall
• Responsive Design: Patterns and Principles by Ethan Marcotte
• The Smashing Book 5: Real-Life Responsive Web Design by Daniel Mall, Sara Soueidan, Zoe M. Gillenwater, Bram Stein, Yoav Weiss, Tom Maslen, Matt Gaunt, Andrew Clarke, and others.
• High Performance Images by Colin Bendell, Tim Kadlec, Yoav Weiss, Guy Podjarny, Nick Doyle, and Mike McCall
• SVG Animations by Sarah Drasner
• Designing Design by Kenya Hara
• Less and More, the Design Ethos of Dieter Rams by Klaus Klemp, Keiko Ueki-Polet (editors)
• Thoughts on Design by Paul Rand
• Design for Dasein by Thomas Wendt
• The Design of Everyday Things: Revised and Expanded Edition by Don Norman
• Design for the Real World by Victor Papanek
• Die Kunst der Typografie (the art of typography) by Paul Renner
• Designing for the Digital Age by Kim Goodwin
• How to Make Sense of Any Mess by Abby Covert
• Digital Design Theory: Readings from the Field by Helen Armstrong
• Undercover User Experience Design by Cennydd Bowles and James Box
• User Story Mapping by Jeff Patton
• Designing UX: Prototyping by Ben Coleman
• Prototyping for Designers by von Kathryn McElroy

and:

• Moby Dick by Herman Melville
• Karlsson vom Dach (Karlsson-on-the-Roof ) by Astrid Lindgren

We’ll see…

Starting to Write Notes

In May 2016, I flipped the switch for the redesign of this site. My last site was never updated once it was online, so I wanted to do things differently this time. Inspired by numerous people who use their web presence to share and promote their thoughts and ideas, I decided to start writing on my own site. To explore things, to share with others what I learned, to retain my thoughts and make my site a place of documentation.

Knowing that it might be hard to keep up with writing, I set myself the goal of publishing four articles by the end of the year. Somehow I indeed managed to find the time to write four articles and I found that I want to keep writing. It really is a great pleasure.

But I also noticed that my articles turned out to be a bit lengthy. Although I don’t think that this is necessarily a bad thing, sometimes a different, a shorter form of writing is necessary. For example, when you just want to write down a quick thought or when you read about something and want to share more than a link but not a lengthy article either.

So today I’m starting to take notes. Quick, raw, unpolished, short, sometimes also a bit longer. Sometimes only an image, a hasty sketch, or a drawing. But always without the need to finalize anything.