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:

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.

72Nd

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:

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:

Readlists Death By Javascript

The Wayback Machine snapshot of Readlists only shows a spinning wheel.

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. ;)

and:

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.