Professional

In my series about how I work on my side projects, I already wrote about interaction design and software design. This post is about graphics design.

Knowing how to realize a given design in a piece of software is part of my job. I have picked up enough HTML, CSS and JavaScript in the past few years to be able to do that (but I still have a lot to learn). For me, the big question is: How do I get to a good design that I can realize in code afterwards?

Because my side projects did not earn me any money yet, and because I don't want to spend too much money on them, I did not hire professional designers for them. This might change in the future, but until now I did (almost) all of the design myself. I had to learn a lot to be able to do that, and I think I am getting better, but I am not a designer - and I'll probably never be one.

There are two books from which I really learned a lot: The non-designer's design book by Robin Williams and Visual language for designers by Connie Malamed.

The non-designer's design book contains lots of useful tips that you can immediately use in your daily work. It explains four basic principles of design in a way that is easy to understand and remember. The book also explains the basics about type and typefaces - things everybody should know.

"Visual language for designers" is more about the big picture. It explains how we process visual informations and how designers can use this knowledge to create effective designs. The book contains lots of examples. It is sometimes a little hard to read and does not contain many practical tips or workflows, but it is definitely interesting and I am sure that I can use the things I learned from this book in my future designs.

The tools I use: For editing HTML, CSS and JavaScript I use the editors of eclipse, but also JEdit and sublime text 2. For editing images and icons I mostly use The Gimp, but I am planning to buy Photoshop later this year.

Finally, here are two examples of my designs: gclimbing.com and scribblingspree.com.

This article is the last part of the "Side Projects" mini-series I started quite some time ago.

Last week I was working a lot on my side projects. I was at home for almost the whole week because I was sick. On the days where I felt better I coded. And after a few days I noticed: I take a break really often. Still I get more done than on an average day in my day job.

At home, whenever I get stuck, tired or bored, I take a break. I cook something or eat something. I get a cup of coffee or tea. I wash the dishes or clean something in our appartement. I play counter strike or watch TV or take a nap or just do nothing for 10 minutes. I just do anything - anything but writing software.

I know there are many possible reasons why I am still more productive, even though I work less net hours. One reason is probably that I don't have to deal with company politics and that I don't have to coordinate with other people. But that's not the point of this blog posting. I think that there are three reasons for me being productive that are directly related to the breaks.

The first reason is quite trivial. I don't code when I am tired, I just take a break. When I'm tired it is harder for me to concentrate, so I make more mistakes and get less done. Simply taking a long break solves this problem.

The second reason is that I don't really get frustrated by my work. When I am stuck or bored I just take a break. I relax and remind myself why I do this: Because I like developing software, because it is fun. After a break, with a new perspective, things are often easier. It's also easier to push through boring work when you know you can take the next break any time you want, and it does not matter how many hours you work today.

I just don't let myself get to the point of frustration. That way I am more motivated, have more energy and procrastinate less when I am actually sitting in front of the computer. I know you could argue that I procrastinate more by spending more time away from the computer. Anyway, I believe less time in front of the computer but better spent still means more productivity.

The third reason is maybe the most important one: When doing a mundane task like washing the dishes, my mind can wander. The details of what I have been doing are still in my head, but by taking a break I can see things from a different angle and often find solutions for why I am stuck. I also have most of my ideas when I am doing "nothing" - just a few days ago I had a great idea while I was having a bath (more on that in a later posting).

Doing only work as long as I like doing it and taking lots of breaks costs a lot of time. I spend less time in front of the computer, I spend less time developing software. Anyway, I think I gain more productivity than I lose because of the breaks.

I have been playing around with IndexedDB for a while now, and now I want to write about my first impression. A couple of days ago I was looking for a way to enable a webpage to store data at the client - in the browser. I found some tutorials about Web Database and immediately liked it (because I immediately understood it). But I soon found out that spec is deprecated and you should use IndexedDB instead.

So, IndexedDB it was. At first it looked rather complicated to me, but in fact it is quite easy to use. I found some good tutorials, of which I liked this todo-list and Mozilla's "Using IndexedDB" best.

What I found out pretty quickly was that there is no easy way to delete a database. This is a real problem when you want to test the code that creates the database - or when you simply want to wipe all data. I found this tutorial to delete the database but this is really cumbersome. In Google Chrome there is a slightly easyer way: Go to "Options" - "Under the hood" - "Content Settings" - "All Cookies and Site Data" - "localhost" and delete the "Indexed Database". The problem here is that this does not always work.

Otherwise developing with IndexedDB is pretty cool. The database is versioned, so you can decide when to update. The onupgradeneeded handler from the mozilla tutorial did not work for me, so I chose the way of the todo-list tutorial. Here is the code to start the update:

var oldVersion = db.version;
if(v!= db.version) {
	var setVrequest = db.setVersion(v);

	setVrequest.onsuccess = function(e) {
		//...
	}
	//...
}

The first problem I had here was that I could not check for db.version in setVrequest.onsuccess because it already contained the new version. Also, only running the newest update is not an option, since the user might have missed an update. I came up with the following code (in the example I use my own version number scheme):

setVrequest.onsuccess = function(e) {
	console.log("updating from "+oldVersion+" to "+v);
	while(oldVersion != v) {
		if(oldVersion === "v01ds02") {
			//perform update
			oldVersion = "v01ds03";
		} else if(oldVersion === "v01ds01") {
			//perform update
			oldVersion = "v01ds02";
		} else {
			//create database
			oldVersion = "v01ds01";
		}
		console.log("updated to version "+oldVersion);
	}
};

I am not sure if this is the best way to do it, but it works. If anybody knows a better way please email me or contact me on twitter or google+.

Accessing data through the asynchronous API is pretty easy and the description in the tutorials mentioned above is very good. The only thing I had to get used to is that you normally only query indexes - you don't write queries like in SQL, you just obtain objects from an index. But this somehow makes sense, I guess queries are always fast this way.

So, my first impression about IndexedDB is: I like it, but it definitely needs better development support and better error messages. Deleting an IndexedDB has to be really easy, otherwise testing is a real pain. And some of the error messages printed by Chrome and Firefox made me really scratch my head - I just couldn't decifer them and I had to resort to trial and error programming.

I have disabled comments on this blog (again). Enabling them was an experiment, and it did now work as expected. There are very little useful comments, but lots of spam that get past the CAPTCHA. So, almost every day when I go through the approval queue I delete all the comments in there. This is not how I want this to work. I hope you all understand it.

This article is part of the "Side Projects" mini-series I started quite some time ago.

I am not sure if it was a good idea to include this topic in my original list because I don't do much formal software design when working on a fun project. Again, I do things completely different when working for a client, where I am part of a team and everybody has to understand the design. But in this case there's only me. When designing some part of the system I usually do the following:

• Think about the problem and possible solutions, try to simplify the problem
• Maybe write a small throwaway prototype (this is optional, normally I won't do this
• Code the most streight-forward solution I can think about

In the end the only artifacts produced are the production code, and maybe - if it is a complicated problem - some automated tests. I don't write much documentation and I do not create UML diagrams or other artifacts. Sometimes some scribbling in my notebook. Sometimes.

The key to make this work is to code the most streight-forward solution I can think about. This means that, when I come back to the code later, I can easily figure out what it does: I just have to remeber the problem and then think of the simplest solution. This gives me a good lead for digging into the code.

Even if the simplest solution was not working when I implemented it first it is still easy to re-trace my steps from there. This works quite well because I am the only person who works on the code. I guess it would be extremely hard - or even impossible - to pull this off in a team with collective code ownership. But meybe it could even work there: When everybody agrees on how the simplest possible solution should look like.

And the advantage of no documentation: The documentation can never be wrong. And I don't waste any time wading through endless pages of (mostly outdated) documentation to find something - A problem that I've seen with some dev team wikis. Also, writing documentation is not fun, and working on a fun project better be fun! If I really fear to forget some important aspect of my code or the architecture I write unit tests instead of documentation. The test at least tells me when it becomes obsolete by not running anymore ("red bar"). Obsolete documentation does not have this feature.

This article is part of the "Side Projects" mini-series I started quite some time ago.

As everything I do for my side projects, I keep interaction design as simple as possible and try to do the absolute minimum possible. I really only perform two steps:

Draw a quick sketch on paper: In my notebook, I draw sketches of the user interface. I also add some annotations that describe how everything should work, but I write down very little. Later I try to remember what I thought when drawing the sketch, or I decide about things as I go.

Write the HTML: After drawing I write the HTML that should be rendered and test it. This is no mockup - It will be production code. I can do this because JSXP allows me to easily transform HTML mockups into the production system.

After writing the HTML I implement the functionality and then go back to writing more HTML. This means that the original drawing on paper does not look like the end result most of the time - but this is OK. It was only a quick sketch. The drawing is even optional: For simple things I start directly with the HTML.

I have bought a license for balsamiq mockups but I rarely use it. Don't get me wrong, it is a great tool. But for a side project where the only designer, programmer, tester, ... is me even drawing simple mockups with balsamiq would require too much effort. They'll become obsolete as soon as I test the real HTML so there is no reason for storing (or even creating) them.

This works quit well because I am alone and I do not have to coordinate my work with anybody else. But I really think this "process" might even work for small teams: Just build something, then iterate to make it better and more beautiful. When you use the right technology, iterating and making things better should be easy.

Now that I'm back from my honeymoon and christmas is over it's time to think about next year. I have some ideas and plan to do some (hopefully) interesting things. Of course I'll blog about them, so stay tuned - I plan to return to a weekly posting schedule in January.

Meanwhile, merry christmas and a happy new year to everybody! I hope 2011 was a good year for you and I wish you that 2012 will be great. Try to learn something and try to change something. It's worth the effort.

My CSP application has been approved by the scrum alliance, so as of today I am a "Certified Scrum Professional". Hooray! Not that much will change in my life ;)

This week I gave a 2-day wicket training in Erlangen, Germany. Here is a short video of the training:

There are some things I could do better, but overall I am quite satisfied with how it went. Thank you Mathema for inviting me as a trainer!

On Monday, I had dinner with Alexandra Specht and Ed Burns (who is JSF spec lead at Oracle). It was a great evening with two great persons.

I am not a big JSF fan (and probably will never be one), but it is a good web technology and you can do great projects with it. They also have some very interesting projects going on. But that's not what I wanted to write about today.

The best thing about the evening was meeting Ed again. He is a great person and it is fun and interesting to talk to him. You can also learn a lot of things from him - and I am not only talking about technical stuff here: It always impresses me how he seems to remember every name of everybody he ever met. I mean, he remembers my name ;) And he also asked about people we both know, so he remembered them AND the fact that I know them.

I guess this really is something I should try to learn from him: I sometimes even forget the names of people I meet while I am talking to them. When this happens it annoys me and I am ashamed and I hope that they don't sense it.