A couple of days ago, I had a meeting with one of our clients to discuss the state of their website and what we could do to further improve it for their visitors. During this conversation, the client mentioned that they wanted to add a blog section, a place where they could inform their visitors about upcoming events, publish photos or videos they had taken during one of those events and where they could make other announcements as well.

The client went on and pointed out that all the content that should go into this blog already existed (and was continually being posted) on third party platforms like Facebook, Twitter, Flickr and Youtube. Being an advocate of the IndieWeb principles, this immediately got me excited, not least because I’ve never really come across this phenomenon on a client’s website before (at least not to this extent).

So I suggested to publish their content on their own site first and then syndicate copies out to the various silos they were already using. The client asked me, why they should do it that way. After all, they really enjoy the ease of use of the posting interfaces the various platforms are offering.

And I get that. It doesn’t take long to produce a Facebook post: you simply enter whatever message you want to share, upload some photos or even a video and you’re done. In a matter of minutes you published something on the web. But an important question to ask here is: for how long is it going to be there? Will people be able to access this information in a couple of months? In five years?

When it comes to publishing on the web, people tend to think: the web doesn’t forget, the Internet never forgets. Once you’ve put something online, it’s going to stay there forever. But that’s not necessarily true. The only thing that is keeping your content accessible over time is the URL. If the URL is gone, your content will be gone, too.

The problem with this is that if you don’t own the URLs your content lives on, then you don’t get to decide if will be available in the future or not. Companies like Facebook and Twitter do. And if any one of these services disappears one day, well then your content will most likely disappear with them.

One might argue that this is never going to happen. How could a company as large as Facebook possibly not be there one day? Well, it happened to a lot of companies on the web already. No one would have imagined that sites like Del.icio.us, Readability, Picasa, Google Code, Editorially, Google Reader, Posterous and Gowalla (just to name a few) would close one day. And yet they did.

When a site shuts down one might think: well, ok, the URLs may be gone, but the content I put online there wasn’t that important to me anyway, so who cares?

The assumption here is: your content isn’t that important to you. But in reality it might indeed be important to other people. While you might not care wether or not your content disappears from the web, other people most certainly do. They might have bookmarked it, they might have linked to it, hell they might even have written a book and put the URL in there as a reference.

If you publish your content on your own website, you can make sure that it will still be available in the future. That doesn’t mean that you shouldn’t be posting to third parties at all, but I would encourage you to first Publish on your Own Site, then Syndicate Elsewhere (POSSE). This way, you get to decide what happens to your content in the future and still can engage with the audience on a particular platform.

As for the client, I’m really looking forward to implement some of the IndieWeb principles on their website, not least because – them being a museum – I think longterm preservation is right up their alley.

I’ve been watching more and more people introducing offline capabilities to their websites so I decided to try and give that a go on my website as well. That meant I needed to add a service worker.

After reading Jeremy’s excellent post about his approach for using a service worker, I peeked through his code and implemented it here. Now when you visit my website (and your browser supports the use of service workers), an offline page and some static files get cached right away. As you browse the site, the pages you visit will be cached for offline viewing as well.

I also wrote a little module for Processwire (the CMS I’m using) which allows me to specify offline pages, static assets and some other options right from within the Processwire backend.

If you’re using Processwire as well and want to get started with your own offline experience, feel free to use the module as it is or tweak it to your needs. You can find it on Github.

Although I’ve chosen making websites as my profession—either freelance or as part of a team—I’ve always tried to make time for personal projects, the very first one and longest running being my own website of course. And despite the fact that only “real client work” is paying the bills, I think we as webdesigners can benefit profoundly and in many different aspects from working on our own projects from time to time.

Starting small

Let me tell you a little story. Some time ago, some of my team mates and me decided to try and taste a new beer every friday. Think of it as a weekly cool down/reward event. We set some rules (german beer only, real beer, no mixed beverages allowed) and we were eager to find out, how many fridays we could go on like this before there were no beers left that we hadn’t tried before. Admittedly a fanciful endeavour, but we started it nonetheless.

Soon we realised, we needed to keep track of the beers we tasted, not only to avoid repetition, but also because we wanted to rate them with a simple five star system. An ordinary spreadsheet was the obvious way to go at first, but that didn’t last very long.

Turning it up

After only a few weeks I thought: maybe I could write a little web application for that. It took me just one (although very long) evening to throw together a basic version that allowed people to log in, submit and edit new beers and of course to rate them. Over the course of a few days we came up with some improvements that I implemented and voilà: we had something we could use to replace our boring spreadsheet.

I really enjoyed building this thing. Not just because it really helped us “scratch our own itch”, but also because I had the opportunity to try new things and learn from it in the process. I figured out how to use the Processwire CMS for handling the data, I learnt about user management and sessions, I got to use flexbox a lot for layout purposes and I tried to make the interface as fast as possible. And thanks to Jeremy’s insights, I dipped my toes into SVG sparklines to create activity visualisations.

Up until now, we have assembled a nice backlog of ideas to further enhance our little app. I’m sure I’ll have a go at making the site work offline using a service worker at some point for instance.

Taking it one step further

Our initial plan was to try and taste one beer every friday. But soon enough, we started using the app outside of that time constraint. Barely three months in, there were already over 60 beers submitted, tasted and rated.

Not having found the perfect beer for us (yet), we came up with another plan: we wanted to make our own beer! After a few weeks of research and gathering of materials we started brewing. Of course, our beer needed a name and appropriate branding so we started working on those things during our lunch breaks and in our free time. We came up with some basic design elements and just went from there: we created a website, a Facebook page and an Instagram account that we’ve been posting on ever since.

You see where I’m going with this, right?

It fascinates me how ideas turn into small side projects and that these projects themselves spark other ideas that turn into projects once again.

Wrap-up

I think, personal projects are incredibly valuable for a number of reasons:

Freedom of failure

Unconstrained by any client work, you can just do whatever you like. Never used a particular technique before? Just go ahead and do it. What could go wrong? The cost of failure is very low, the learning possibilities however are endless.

Learning opportunities

If we’re not careful, we tend to get stuck in kind of a rut when we do client work. Sure, every client is different and we need to adapt how we approach things depending on specific requirements. But: we are also humans. And as such we try to do things in a way we feel comfortable with. Working on a side project allows us to do things differently and in doing so offers us the possibility to learn new things, which then in turn can find their way back into our day to day client work. Just recently a colleague asked me about a particular problem she was having and I immediately knew the answer, because I had just encountered that exact same situation when I was working on the app.

Sparking creativity

Working on something you are excited about is an excellent catalyst for new ideas. We went from beer tasting to developing a web application to brewing our own beer in just a few weeks. I really like the kind of flow you’re getting into, especially if it’s not just you working on a personal project. When there are other people involved, there’s infinite room for bouncing around ideas and sharing thoughts.

A few years ago I started adopting the IndieWeb principles on my website. I have set up a micropub endpoint, I post to twitter from my own site, and I’ve been using OwnYourGram to pull in the photos I post on Instagram.

One thing that I’ve been wanting to do since then, was to include the bike rides I track and post on Strava. Strava let’s you upload activities through their API, which would make it the perfect choice for the POSSE principle.

However, there is a downside to this approach: I don’t have a separate GPS tracking device to record my rides. Instead, I use Strava’s iPhone app which is absolutely brilliant. So I decided to go with the PESOS principle here. I wrote a module for Processwire (the CMS I’m using) that hooks into the LazyCron module, fetches the rides I’m tracking and posts them in the notes section of this site, including the photos I took on the ride, a map and some stats. The final result looks like this.

I really enjoyed playing around with Strava’s API and I suspect I’m not done yet. Next steps might include grabbing the kudos and comments on my rides and displaying them here.

There’s always this guy, trying to diminish whatever good you’re trying to do for your team without having contributed anything himself. There’s always this guy, claiming to be liberal and open to other opinions, as long as they don’t conflict with his own interests. There’s always this guy, lecturing people about their wrongdoings but can’t stand criticism himself. There’s always this guy, expecting things of others which he himself never lives up to. There’s always this guy, blaming everyone else but himself. There’s always this guy, dragging others down to cut a better figure. There’s always this guy, envying everything good that doesn’t happen to himself.

Just don’t be that guy.

I recently reviewed the performance of one of our clients’ websites. During its lifespan, a myriad of developers had contributed their code without any form version control.

One thing that struck me instantly was the heavy use of JavaScript and CSS frameworks. I counted a total of three framework integrations accompanied by several other scripts that seemed to be solely fulfilling just one purpose each. Even for an “organically grown” codebase this seemed a bit too much.

When it comes to frameworks of any kind, I think it’s worth considering that it comes at a cost. Not to sound old and grumpy but I still see especially young developers choosing their own convenience over the convenience of their users and disregarding the fact, that throwing another 100 KB JavaScript into the mix might actually do more harm than good in terms of performance (and therefore: user experience).

Don’t get me wrong: frameworks are great and they can make your life easier if they are considered well. Let’s say you’re building a web application and are planning to use all kinds of enhancements to make user input easier, i.e. date pickers, spinners, range sliders and so on, then sure, it might be worth considering a framework that can provide this kind of functionality for you.

But if you only want to attach an event listener to an element, then why bother including a JavaScript library to do what you could have done with just a few lines of JavaScript yourself?

Today a colleague asked me to help her finish a PDF that she needed to send to an online print shop. They specifically asked for a document created with solid colours (instead of process colours), either in Pantone or HKS.

The last time I had to deal with things like this was probably ten years ago, during my photography apprenticeship. Back then, I learnt a lot about colour theory and the printing process.

Today, it took me a couple of minutes, but my memories emerged slowly and steadily and I could answer her question. I guess everthing we learn can be of some use sometimes. That’s what I learnt today.

I’ve been trying to ring up a prospective client for the last two days. Although I could have left a voicemail, I didn’t. I’ve never liked leaving voicemail messages because it always feels a little awkward talking to no real person.

Today I finally left a message to ensure that the conversation keeps going and we have a chance to reach one another at some point, but I still don’t like it. I wonder if anybody else resists leaving voicemail. That’s what I learnt today.

Today I came across this tweet from @StarbucksUK:

Pumpkin Spice Latte is back! #PSL pic.twitter.com/gmNAtRJQfA

— Starbucks UK (@StarbucksUK) 15. September 2015

I really like this clever use of the false frame illusion and I realised, how often I tend to “think” in frames and boxes. I suppose writing CSS and dealing with the box model for a couple of years somehow clouds the view for design delighters like this one. I’ll have to remind myself not to think in boxes and frames all the time. At least that’s what I learnt today.

Last week I took a few days off. I spent a generous long weekend hiking through the Palatinate Forest and celebrating my birthday. When I started working again this morning, I had to deal with some email that had piled up during my absence.

For most people, handling email is a very unpleasant task. But ever since I adopted the inbox zero principle, I’m rarely stressed about it. After sorting out the important ones, I move the rest into a separate archive folder or even delete them. Then I assign a task to the remaining items requiring action and move them into the same archive folder.

And that’s all there is to it for me. Over the years I’ve developed a very strict routine and today I realised again, how important such a set of rules can be. That’s what I learnt today.