- Published: Thursday, 02 December 2010 00:00
- Published: Sunday, 07 November 2010 00:00
Update 2012: Please note that his was working for iOS 4.x. Apple changed things a bit since then....
Use a smart playlist in iTunes and your iPod to organize podcasts you have not heard yet.
Do you also find it difficult to maintain the podcasts you still need to listen to on your iPhone or iPod? Without casts that you’ve already heard taking up too much space on your device? The ideal would be that all new podcasts automatically end up on your device, and automatically disappear once you’ve listened to them to make space for new ones.Write comment (0 Comments)
- Published: Friday, 01 October 2010 08:20
This is the user interface for operating on public transport cards available in busses. It is available in 4 languages. But look at the way the flags and buttons are connected. GUI Blooper? It can't be fixed in the next release of the software.... #oops #ovchipkaartWrite comment (0 Comments)
- Published: Monday, 13 September 2010 00:00
- Published: Thursday, 09 September 2010 09:00
The train that was supposed to take me from Rotterdam to Utrecht this morning broke down in the middle of the trip. Gave us an interesting viewpoint over the A20 freeway. For quite a while.... #trip #delay #nsWrite comment (0 Comments)
- Published: Saturday, 26 June 2010 00:00
The beach near 's-Gravenzande has been widened by adding sand, lots of sand. There were two reasons for this: first there was a problem of beach erosion that apparently was caused by a concave coast line. They therefore wanted to add so much beach that the coast line was no longer concave. Furthermore, a huge extension of Rotterdam harbor is being built on the south flank, and the resulting loss of ecosystem must be compensated somewhere. Part of the "old" beach area is now converted into a bird-friendly natural area.Write comment (0 Comments)
- Published: Saturday, 19 June 2010 22:41
A software shop like ours should deliver what customers want... but it may be difficult, because they often do not ask what they want. This is because customers think they know what causes a problem and they think they know the best way to solve it. They then formulate their request in an attempt to help us.
An example: I once had customers asking me whether I could change my software so that it would round the numbers that it would use to position a robot. It would have been easy to satisfy that request, but I decided to ask why? This proved to be a good idea. I found out the customers were copying the numbers into some other software package. Rather than doing what the customers asked, I ended up writing a direct interface to the other software. This made life of the users much easier yet, without limiting the possibilities of the robot.
We can not blame customers for not knowing what is easy and what is difficult to implement. Both ways. They can think that something is very easy, when in fact it is fundamentally very hard. But it also happens that they do not dare to ask a question they think is hard, when in fact it would be very easy.
If you want to make the best possible software, you need to keep asking "why" until your user's report has been changed to "If I do A, I get B. But instead of B I would like to see C (because I need D)". This will help you to decide how customer satisfaction can be maximized. The maximum may be much higher than your customers expect.Write comment (0 Comments)
- Published: Monday, 17 May 2010 00:00
- Published: Tuesday, 27 April 2010 00:00
#fireWrite comment (0 Comments)
- Published: Saturday, 24 April 2010 20:43
One of the first stages in the development of a new tool (software or hardware) is a functional specification. The functional specification matures in discussions between the developers (department of R&D) and the customer representatives (often the departments of marketing and sales).
Of course a functional specification is useful: it is very hard to develop something new without an idea of how the new tool will be used and what it will be compared with. However, defining a functional specification can also be taken too far. In some organizations, the functional specifications are spelled out in the tiniest details. At the end of a long formal procedure, the book of specifications is signed like a contract between marketing and development. The development can only be started when the list of signatures is complete and will be performed in splendid isolation from the world of potential users. Why do organizations do specifications this way? It is often an attempt to separate the responsibilities of the departments, so that if anything fails the appropriate party can be blamed. If the final product does not meet the functional specifications, this can be blamed on the developers. And if the product does not succeed even though it meets all the functional specifications, this will be blamed on marketing.
I have a serious problem with this approach: using this procedure, how can one ensure that the product will be useful? After two years without interaction, development may produce exactly what marketing asked for (making all deadlines and within budget), but the market has changed and does no longer need the designed product. Or technology has changed, and better specifications would have been within reach and are offered by the competition. Or maybe marketing truly made a mistake, and asked for something the world is not waiting for. In these cases, clearly the development department can not be blamed! But if you develop an obsolete product this way, where does that leave the organization as a whole? And if this is not the best solution for the organization as a whole, will it be good for the development department? Even though everyone did exactly what was expected, people may be laid off because development costs can not be recovered.
The solution is, as often, to keep a middle road. Using e.g. Agile or LEAN development methods, developers can stay in constant communication with marketing. Iterative and modular design procedures can be used to verify that the new tool does what it should, without relying on the capacity of people to describe specifications in words beforehand. And because the communication with the market is not lost during the development process, the tool will have a significantly higher chance of actually being useful at the moment of introduction.
Image (by QuiteLucid on Flickr): "a camel is a racing horse designed by a committee".Write comment (0 Comments)