Visa and smartphones….

Recently I ran into some problems when I wanted to buy something online and tried to pay for it by using my Visa card. Every time I reached the checkout section I was presented with a screen asking me for a code generated by my eCode app. Which is weird, since I don't have that code. I don't have that app either. In the past I had to enter my CC details and a personal password and that was that, but all of a sudden I had to use an app?

I figured I did something wrong and paid by using another method. But this happened every time. So I started looking into this by checking the sites (no option 'use eCode app' to be found) and then into my personal profile on the Visa website (also no 'use eCode app' option there...) I did find a lot of information about the for mentioned app but of course: only available on iOs and Android. Not on Windows or Windows Phone.

So I mailed Visa. I wanted to know when they were going to release a WP version because otherwise my Visa card would be pretty useless to me. A couple of days later Visa responded. And the response blew my mind...

Basically they said: "We haven't planned a Windows Phone version of our app. But to accommodate you we have reset your profile so you can use the password again. However, in the near future this possibility will be removed altogether so we hope you have moved to iOs or Android by that time. "

What? So they changed my options to use a Smartphone all the time without asking me? And now they tell me I have to use iOs or Android if I want to keep using their card in the future? What is wrong here?

I am not starting a debate about Windows Phone versus the rest of the world. I am starting a discussion about the arrogance of a company that decides they can decide what people should use. What if you don't have a smartphone at all? Or if your battery runs out? You cannot use the Visa card anymore at that time? What if you happen to have a Blackberry, a Nokia or any other non-supported OS on your device?

Why does Visa think they can decide only people having an Android Smartphone or iPhone are entitled to do online shopping?

I guess my options are clear: cancel my Visa card and move on to a platform that cares about peoples choices, elderly people who don't want to use smartphones, people with limited budgets that cannot afford smartphones, people with limited vision (who cannot really use smartphones) and so on. A lot of people still think (iphone/android) smartphones are very common, but they are not.

Visa apparently doesn't care about the majority of people in the world…

Code from your fellow developers

It's almost a law: whenever you take over code from another developer, you start to moan and complain about the state of that code. It's awful, terrible, the worst piece of code you've ever seen. I am no exception. However, when I took over some code from a colleague who left the company I found this gem. I think I am right in complaining about this piece of code. (FYI this is almost an exact copy of what I found in the codebase, except for it being an console application and the classnames…)

namespace ConsoleApplication9


    class Program


        static void Main(string[] args)


            Customer customer = new Customer();

            customer.Id = 42;


            Order order = new Order();

            order.Id = 64;






    public class SaveableEntity


        public int Id { getset; }


        public void Save(SaveableEntity entity)


            entity.Id = Id;


            this.Id = entity.Id;



    public class Customer : SaveableEntity





    public class Order : SaveableEntity






Now, please tell me what you think of this…

Our own Daily WTF

If you're a developer, you've probably heard of the website the DailyWTF. If you haven't, head on over to and read. And laugh. I'll wait.

Read it? Good. If you're a bit like me probably you've been wondering how on earth some people ever get hired as a software engineer. Most of the stories there seem to weird to be true: no developer would write software like that right? And then you run into a little nugget of code one of your co-workers wrote. And then you realize: "Hey, it happens everywhere!"

Look at this piece of art I found in our codebase recently:

public static decimal ToDecimal(this string input)


    System.Globalization.CultureInfo cultureInfo = System.Globalization.CultureInfo.InstalledUICulture;

    var numberFormatInfo = (System.Globalization.NumberFormatInfo)cultureInfo.NumberFormat.Clone();

    int dotIndex = input.IndexOf(".");

    int commaIndex = input.IndexOf(",");

    if (dotIndex > commaIndex)

        numberFormatInfo.NumberDecimalSeparator = ".";

    else if (commaIndex > dotIndex)

        numberFormatInfo.NumberDecimalSeparator = ",";

    decimal result;

    if (decimal.TryParse(input, System.Globalization.NumberStyles.Float, numberFormatInfo, out result))

        return result;


        throw new Exception(string.Format("Invalid input for decimal parsing: {0}. Decimal separator: {1}.", input, numberFormatInfo.NumberDecimalSeparator));



Me and a collegue have been looking long and hard at this and what we concluded was the following:

Apparently, we don't trust our users to be able to correctly set the culture in Windows. Users aren't able to determine if they should tell Windows to use a decimal point or a comma to display numbers. So what we've done here is make sure that whatever the user enters, we'll translate that into whatever the user WANTS to enter instead of what he actually did.

So if you set your locale to US, since you're a US citizen, but you want to enter the number 12.34 in the Dutch style (because, you know, the Dutch are way cooler with numbers) so you enter 12,34 we will understand this and respect your wishes! Of course, if you change your mind and in the next input field you decide to use the decimal dot again, that's fine with us as well. We will do the hard work.

Now, I am all for smart software. Software that can handle all sorts of input the user can think of. But this feels a little uhm, I don't know.. wrong..

Or am I too old fashioned?

Windows Phone appointment task

I am currently working on a new version of my AgeInDays app for Windows Phone. This app calculates how old you are in days (or weeks, depending on your preferences). The inspiration for this app came from my father, who once told me he proposed to my mother when she was 1000 weeks old. That left me wondering: how old in weeks or days am I? And being the geek I am, I wrote an app for it. If you have a Windows Phone, you can find it at

A new version of the app was published quite quickly, adding the possibility to mark a date in your agenda when you would have reached a certain age. Of course the logic behind this if extremely simple. Just take a DateTime, populate it with the given date from the DatePicker, then call AddDays(numDays) and voila, you have the date. Now all I had to do was implement a way to store this in the users calendar so he would get a reminder when that date occurred. Luckily, the Windows Phone SDK makes that extremely simple:

public void PublishTask(DateTime occuranceDate, string message)


var task = new SaveAppointmentTask()


StartTime = occuranceDate,

EndTime = occuranceDate,

Subject = message,

Location = string.Empty,

IsAllDayEvent = true,

Reminder = Reminder.None,

AppointmentStatus = AppointmentStatus.Free






And that's it. Whenever I call the PublishTask Method an appointment will be made and put in the calendar. Well, not exactly: a template will be made for that appointment and the user will see that template, giving him the option to either discard or save the reminder.

The user can also make changes before submitting this to the calendar: it would be useful to be able to change the text in the agenda and that's exactly what this allows you to do. Now, see at the bottom of the screen the option "Occurs". This tiny field is what this post is about. You cannot set it from the code.

I want to be able to have repeating items in my agenda. Say for instance you're counting down to a certain date, I want to be able to give you that option as well. However, I cannot. The field "occurs" is not part of the Task you create in code.

Of course, you could create a whole series of events yourself. Have the "Occurs" field in your own user interface and make all the appointments. But that's not the same. First, the system doesn't recognize them as part of a series. That means if you want to change the text later on on one of the occurrences it will not ask you if you want to open this one or the whole series. More important however, is that the user has to acknowledge each and every single occurrence and save that into the agenda.

Now, I understand why they implemented the system in such a way that the user has to approve an entry. You don't want apps to automatically fill your agenda with messages such as "Remember to pay for my app!". But why not include the "Occurs" option? The user can still opt out if they see this happening.

I hope an update will fix this soon. But for now: you just have to countdown to your birthday yourself. My app won't support this.

TwitterSearch in Windows Phone: How hard can it be?

Some of you probably already know this, other probably don't care. But I am a Bruce Springsteen fan. A huge fan. I adore the man's music, I know the tunes, I love the music and I try to spend as much time as possible by playing his songs on my guitar (and fail miserably but having lots of fun doing so). I visit as many shows as I can or as I can afford. So when Bruce decided to have another tour in the year of 2014 I got a little nervous. His shows usually sell out in a couple minutes which means that as soon as the shows are announced you have to be ready to buy tickets. That means that you have to know what's going on in Springsteen-land and for me, that meant I had to write an application for my phone that tells me exactly these sort of thing. It didn't seem that hard to do: just write an app that reads out some RSS feeds and show them on the screen.

But then I thought a little bit harder about it and thought that maybe other people might be interested in this as well. Of course, that meant that the competition for those tickets would be a bit tougher but what the heck, as Bruce himself said, nobody wins as everybody wins.

Now, writing a simple app just for myself is one thing, writing an app that gets downloaded by people all over the world is something else. If it were only for myself I could have finished the thing in a couple of hours, but publishing an app for real means I had to seriously think about it and make sure it would be stable, nice-looking and useful. Which means I had to add features I didn't need just for keeping up with the latest show announcements.

The idea behind writing apps is that you ship early and ship often, so the first version was out of the doors pretty quickly. It did little more than just displaying a list of the last 40 news items on the web that were about Springsteen. The second version was a bit more complicated: it had a live tile telling you exactly how many new news items were available for you to read since the last time you started the application. This uses Windows Azure Mobile Services as the backend so it gave me the opportunity to learn how to use that as well. After all: I would be using this app to learn new techniques as well as giving me the information I wanted.

When that version was finished and published I started thinking about new features. One of the features I thought would be nice to have is an overview of Tweets that contain the word "Springsteen". After all: when there is news that hasn't been really published yet, people will talk about it on Twitter. So I had to add another news source (on another screen) that contains the results of a Twitter search.

Since Twitter apps are the new "Hello World" apps I figured it couldn't be hard to build. And if I were to run into problems I would find documentation and samples all over the web, showing me the way. Boy, was I wrong.

Of course, there are a lot of sites and articles that tell you how to do this. But these articles have two problems:

  1. They are written for Windows Phone 7. Things have changed since then.
  2. They are written for Twitter API v1. Things have changed since then.

In fact, things have changed so much I couldn't use the information out there at all. So I had to figure it out all myself. Well, I did just that and I am presenting you with the way to do this right here so you don't have to worry about it.

Twitter side of things

First, the biggest change on the Twitter side of things is that in the old days you could go out to and get the results you wanted. This doesn't work anymore. They want you to authorize your app first. So you have to log in.

Now, there are two ways you can do this. First you can ask your user to log in and then search on his behalf. This is not really acceptable in my case since all I want to do is show the search results. I don't need the users credentials: I won't be posting or re-tweeting anything. So I have to use the second option which is let the application log in for the user. This means the app has read-only access to the Twitter API but that's just fine in this use case.

To do this, you have to register your app with Twitter. Go to, sign in and reserve your app name. If you do that, you get some keys that you're going to need. For my app BruceNews it looks like this:

I have edited out the keys but it's just a bunch of characters you get when you let your cat walk on your keyboard for a while. These keys, the API key and API secret are what you need to authenticate your requests. The reason for this feature is that while the usage of Twitter is free, they don't want you to overdo things. There is a limit to the number of requests you can fire against their servers. At the time of writing, this is 450 calls per 15 minutes for the search, per app instance. So that's once every two seconds which is reasonable enough for our app. I don't expect users to refresh the search more than that for fifteen minutes at the time….

When you register your app they also want you to give a call back URL that gets called when users use your app to authenticate themselves. However, you don't need that so you can fill in whatever you want.

Now, for an app to do a Twitter search, the flow is as follows. First, you authenticate your app against Twitter. They will give back a token key. This token key is then passed on to Twitter again whenever you do an API call. Remember: this authentication scheme only allows you to do read-only calls such as search!

Windows Phone 8 side of things

It's time to start up Visual Studio and create a new Windows Phone 8 app. I have made a very simple test application, so all I needed was the standard Blank App template. I won't be using MVVM here since I am only showing you how to use the Twitter Search. Of course, if you do want to create a real app I strongly, really, really strongly urge you to use an MVVM framework. For now, the MVVMLight stuff by Laurent Bugnion is your weapon of choice for both Windows Phone 8 as Windows 8 Store Apps. But I digress.

My main screen looks pretty simple. All it does is show a Listbox. In that Listbox I have added a datatemplate for the itemtemplate to format the tweets. Twitter has some guidelines to how those things should look like. They really want all tweets to look the same:

However, there is a nice little loophole: the developer side says: "Applications that cannot implement these guidelines due to the technical limitations of their platform must make a best effort to satisfy as many rules as possible" Since we want our tweets to adhere to the Windows Phone look and feel, we can more or less deviate from this standard. Still, it's a good idea to implement as much of this as possible since it makes it for users easy to recognize as being a tweet. I use the avatar, screen name, handle, text and postdate in my example.

So, how do we get the data from the Twitter service? Well, you need to add a Nuget package first. All data from Twitter is in JSON format so you need a way to handle that. There is a more or less standard package which helps for that: NewtonSoft You can install through the "Manage NuGet Pacakges…" context menu in the solution explorer or through the Package Manager Console and type in "Install-Package Newtonsoft.Json". Another package you will need is the Microsoft HTTP Client Libraries (Install-Package Microsoft.Net.Http). Now, you're good to go.

I have defined two static members in my codefile, named TwitterConsumerKey and TwitterConsumerSecret, which are the two keys we got from Twitter. Next to that, I have added a Loaded event handler on my main screen that does two things: Load the tweets and assign the resulting list to the listbox on my main screen.

Now, before we go to the nitty-gritty details of how to get the data out of the Twitter server, we need to have classes that hold the tweets. Now, don't you think a tweet is just a simple set of text lines. The structure you get back for a single tweet is rather impressive:

Don't try to read it. It's hard to read since it's pretty small in this image. But it does give you an idea of the complexity. Especially the user is quite elaborate.

On you can get the resulting JSON and there are tools out there that can help you transform this JSON result into C# classes. You need to do that so you can actually use them in your Phone application.

I have added these classes to my project and now I am ready to begin reading the data. Remember, there are two steps to take: first authenticate, then get the results.

First, let's do the authentication.

Authenticate against the Twitter REST API.

If you look at the steps on the Twitter site, it seems pretty straightforward. However, to translate this into valid code for a Windows Phone 8 app you need to go through some hoops. Here it is:

private async Task<string> GetAuthenticationToken()


var client = new HttpClient();

var uri = new Uri("");


var encodedConsumerKey = HttpUtility.UrlEncode(TwitterConsumerKey);

var encodedConsumerSecret = HttpUtility.UrlEncode(TwitterConsumerSecret);

var combinedKeys = String.Format("{0}:{1}", encodedConsumerKey, encodedConsumerSecret);


var utfBytes = System.Text.Encoding.UTF8.GetBytes(combinedKeys);

var encodedString = Convert.ToBase64String(utfBytes);

client.DefaultRequestHeaders.Add("Authorization", string.Format("Basic {0}", encodedString));


var data = new List<KeyValuePair<string, string>>


new KeyValuePair<string, string>("grant_type",



var postData = new FormUrlEncodedContent(data);


var response = await client.PostAsync(uri, postData);

if(response.StatusCode != HttpStatusCode.OK)

throw new Exception("Did not work!");


var content= await response.Content.ReadAsStringAsync();

var authenticationResponse = JsonConvert.DeserializeObject<AuthenticationResponse>(content);

if(authenticationResponse.TokenType != "bearer")

throw new Exception("wrong result type");


return authenticationResponse.AccessToken;




Let me walk you through the code. First of all, you need to mark this method as async. After all, it might take more than 50 milliseconds to authenticate and the guidelines say you need to make it asynchronous if it takes that long. So mark the method with async and let it return a Task<string>. The string in this case is the authentication token I was talking about earlier on.

Now, create an instance of the HttpClient. This comes from the HttpClient package we installed earlier on. The uri I give is the one you need for authenticating, so that's pretty straightforward as well. Now, the next few lines prepare the two secret keys in a way Twitter expects them. First I UrlEncode them. Twitter suggests I do this. In reality this doesn't do anything since the keys do not contain any characters that might need escaping, but the Twitter documentation says this might change. So I decided to do this. Better safe than sorry, right? After this encoding I combine the two strings with a colon (:) in between. I get one string as a result. This string needs to be passed on to Twitter but it needs to be Base64 encoded. Since you can't directly do that in Windows Phone, I first need to translate the string into an array of bytes which then in turn get turned into a Base64 string.

Now, the tricky part. The API wants this key to be in the headers of the request. So I add to the DefaultRequestHeaders a value of this string with the key being "Authorization". It also wants some extra data in the form of the key-value pair "grant-type" / "client_credentials" so I make a list of this one key-value pair, give it to a new FormUrlEncodedContent which I pass on to the actual request I make: client.PostAsync.

Once you do that the Twitter authentication mechanism starts to work and will get back to your. It will do that with either a response 200 (which means it all went ok) or another one saying something went wrong and that you probably are the one to blame. And they usually are right, darn them…

Let's assume it all went ok and now it's time to look at what we got back. The response object contains a Content stream that we can read out with ReadAsStringAsync(). This content can be converted to an object of type AuthenticationResponse. This class I created myself and looks like this:

class AuthenticationResponse



public string TokenType { get; set; }


public string AccessToken { get; set; }



It's just a placeholder for two fields, namely token_type and access_token. I have decorated the fields with the correct Json names so I can use the right format for the property names and thus prevent my tooling for complaining about my crappy naming convention. Now that I think about it, I did the same for the Twitter classes….

If all went well we now have an instance of the AuthenticationResponse. This can contain several things, but if things worked as they should you now should have an TokenType (or token_type if you use the original name) of "bearer". The value belonging to this field, stored in AccessToken (or access_token) is what you need to pass on to the next call. If this is not "bearer" you're in trouble and you did something wrong…

Let's do some searching!

Now that we have this authentication token we can do the actual search. If you understood the last part, you will find the search is pretty simple. It does things more or less the same way. Let me show you my code. First I have created a wrapper object which will contain all search results:

internal class TwitterSearchResults



public List<RootObject> Statuses { get; set; }



This is what we will get back from the search. It's just an object with a list of RootObject instances. This RootObject you can find in the diagram above (if you look really hard) but that contains information about the user, the tweet itself, the time and date and so on.

The search looks like this:

private async Task<List<RootObject>> GetTwitterResults()


string token = await GetAuthenticationToken();

var client = new HttpClient();

var uri = new Uri("");

client.DefaultRequestHeaders.Add("Authorization", string.Format("Bearer {0}", token));


HttpResponseMessage response = await client.GetAsync(uri);

Task<string> content = response.Content.ReadAsStringAsync();

var searchResult = JsonConvert.DeserializeObject<TwitterSearchResults>(content.Result);


return searchResult.Statuses;



Again, we need to mark this method with async. The result is a Task<List<RootObject>> so in effect we get the list with tweets we can databind against. The first thing I do is call our previously discussed GetAuthenticationToken. After all, each call to the API needs this token otherwise it just will not work.

The moment we have this token we create a new instance of the HttpClient. Then we build up the query we want to perform. I have hardcoded the search string "#springsteen" (the hashtag is UrlEncoded otherwise it won't work) and instead of the default 15 results I want to get back the last 30 results. There are about 30 options you can specify here. You can limit the results to a certain date, or a certain geographical location and so on but I would suggest you keep things simple at first. First make it work, then make it pretty, remember?

Just like we did in the authentication code we add a new header, but this time we give it the key value pair "Authentication" – "Bearer xxxx" where xxxx stands for the token we just got back.

Now all we have to do is call client.GetAsync(uri) (we did a Post in the authentication, this requires a Get) and again we get back a response. You really should check for the code again, it should be 200, but for brevity I decided to "forget" about that here. I assume it all just works…

The resulting string in the Content is deserialized to a TwitterSearchResults object and returned to the calling Loaded event handler. This then puts that data into the Itemsource for the listbox and voila, there it is! The tweets will show up on the screen.


It's really not hard to get Twitter search results in your Windows Phone 8 app, but the lack of documentation and samples make it quite a challenge to find out how to do this exactly. But once you find out how to do this, you can enrich your app with real time results matching your audience. And that makes an app a lot more useful for a lot of people. At least, I know now that there are no plans for an European tour so I don't have to worry about getting tickets… yet.. wait, let me check again…




Windows Phone and IconicTile updates

The project I work on right now is a fun one. It has all sorts of technology mixed. The base application is a Windows 8.1 with a Windows Azure Mobile Services backend. This means I get to do C#, XAML, NodeJs, Javascript and a lot more weird technology. My main projects are hosted in Visual Studio Online (TFS in the cloud) while my Azure scripts are stored in a Azure GIT repository. I see a lot of technology in a normal day.

However, what is really frustrating is the lack of documentation on the Windows Azure Mobile Client side of things. I spend most of my time in Google trying to find simple answers to simple questions, such as: where can I find a specific module? Or: how do use that module?

One of the apps is running on Windows Phone 8. I decided to give it an Iconic tile which is basically a static tile with a title and an icon. Nothing fancy there. But I needed to send updates from the backend about the number of messages waiting for the user to be read. This is one of the big things in Windows Phone of course: live tiles with instant information. So I wanted to send out push messages from the Azure backend to the phone.

There are tons of examples out there on how to do this. And all of these examples are almost exactly the same. And none of them work…

After a full day of exploring and Googling (I have definitely given up on Bing: it doesn't find anything when it comes to this sort of thing), I finally found, somewhere deep in the bowels of the internet, the cause and the solution.

The thing is: it all works just great as long as you don't use IconicTiles. FlipTiles and Cycle tiles all work great but IconicTile isn't supported in the backend. And there is no information about this. I repeat: the documentation says nothing about this. You can use the tiles in your app, but you cannot use them in the backend.

Luckily, Jeff Wilcox ran into the same problem and solved it by creating his own push package you can use.

The usage is pretty simple: you import the module mpns (found here) and use that instead of the normal push.mpns package. This one has the long sought after sendIconicTile method:

var payload = {
count: updateCount

handle, payload, function () {
// nothing

This works great. I have updates now in my app. But… the big questions are

  1. Why doesn't Microsoft support this out of the box? The do have the sendTile and sendToast methods, why not this one?
  2. Why isn't this documented? If you decide not to support parts of your own technology, well, I guess that's your choice. But please let me know, instead of hiding it.

I love the platforms WP8, Win8 and Azure Mobile Services but this part has taken a lot of energy and a lot of frustration. Please people from Microsoft: do something about either points…

Right. Back to coding!

Dutch for once: op zoek naar een nieuwe uitdaging!

I apologize to my non-dutch speaking readers: this post is about me looking for a new job and since I am based in the Netherlands I will do this in Dutch… Next time I will be technical (and thus in English) again!

Het leuke van interim zijn is dat een klus een keer afloopt. Ik heb heel bewust gekozen voor het leven als freelancer: ik wil graag heel veel verschillende mensen en organisaties leren kennen. Dit werk is daar bij uitstek geschikt voor! Immers: bij iedere klus breng ik niet alleen nieuwe ideeën en kennis maar ik leer zelf ook iedere keer ontzettend veel. Die kennis kan ik dan weer gebruiken bij een vervolgklus en op die manier verspreid ik die kennis onder de bedrijven in Nederland. En er is niets leukers dan zien dat wat ik meebreng een organisatie naar een ander niveau brengt!

Iedere keer een ander bedrijf zoeken houdt in dat ik iedere keer weg moet gaan bij een organisatie. Het lastige daarvan is het juiste moment te vinden. Van buitenaf gezien is dat lastig in te schatten: wanneer kan ik niets vernieuwends meer bijdragen en is het tijd om verder te gaan? Wanneer is het tijd om te zeggen dat de organisatie alles weet wat ik ze kan bijbrengen?

In mijn huidige klus is dat moment nu aangebroken. In de afgelopen elf maanden heb ik dit bedrijf zien veranderen van een kleine maar enthousiaste groep ontwikkelaars naar een professionele organisatie met ruim twee keer zo veel ontwikkelaars. Dat veranderingsproces is erg leerzaam geweest en ik ben dan ook erg blij dat ik die verandering heb kunnen en mogen begeleiden. Van drie teams met ieder vijf of zes ontwikkelaars naar zes teams met zeven tot acht ontwikkelaars per team groeien betekent dat je je ontwikkelproces heel anders moet insteken. Ook houdt dat in dat je je teams anders moet indelen, dat de organisatie zelf anders gemodelleerd moet worden en dat mensen anders met elkaar om moeten gaan. Om dat voor elkaar te krijgen is er door iedereen heel hard gewerkt, is er een aantal fouten gemaakt, is heel veel van die fouten geleerd en is uiteindelijk een vrijwel nieuw bedrijf ontstaan.

Het is tijd om dit bedrijf te verlaten. Ik ben benieuwd waar ik hierna terecht kom: ik ben aan het rondkijken naar mogelijkheden. Ik weet wèl: het bedrijf waar ik naar op zoek ben, is een bedrijf dat openstaat voor veranderingen. Veranderingen, maar dan wel met het oog voor het individu; mensen staan immers centraal in de software ontwikkeling!

Ik heb er in ieder geval weer zin in!

Software for “the other people”


Let me start with something that has been bothering me for quite a long time. I may have mentioned this before, I know I have repeatedly stated it in one of my many talks but I believe this is a very important point. I work in the industry we call ICT. I assume you do too. If I'm wrong here, ignore this first part and please skip ahead. Now, if I ask my coworkers what ICT (in the old days it used to be IT which has the same problem) means, I usually get a correct reply: Information (and communication) technology. Of course, I never stop there and ask the next question which is "what do those words mean?" And almost nobody gets that part right.

Isn't it sad that people who make their living in an industry don't even know what that industry does? It's vital for understanding what it is you do everyday and more important: why you do it. But if you do not know what the idea behind the industry is, how can you make a worthwhile contribution?

ICT does stand for Information and Communication Technology. So, that implies it deals with all the technology (be it hardware or software) that enables communication and something called information. Communication is something most people have a fairly good idea about what it is. Information however is one term that is almost always used wrong. And that includes me: although I claim to know what it means I also make the same mistake every now and then. It's weird to hear people say we live in the Information Age without them knowing what that means.

I have studied IT. I learned a lot, most of it had to do with alcohol and how to survive Amsterdam as a young student, but one of the things that stuck was the definition of Information. So, here it is:

Information is data that, provided it is

  1. Given to the right people
  2. Given at the right time
  3. Given at the right location
  4. And is correct

Adds value for that person.

If some piece of data doesn't satisfy all four points, it is data and not information. I quite often hear people saying the information was incorrect. Well, according to my definition that is simply not possible: the data might be incorrect but then it's not information. It's data. What if I were to tell you that Apple's stock price rises 10%? That may be correct (I don't know, I am not inn the stock market business but let's assume it is correct). But if you don't have any shares in Apple or are not interested in acquiring them, you are obviously not the right person for this data. It's just data, it doesn't add value so it's not information. Of course, if you ARE a broker and you spend a lot of money on Apple stock only to find out I meant the rise in the price was 10 years ago, well, you won't be to happy either: the data was correct, it was delivered to the right person but the timing was a bit off. So: it's data, not information. I think you get the point.

The last point is for me the most important one: the data, given the four prerequisites, should add value in order to become information. And that's basically what ICT does: it makes sure that the enormous amount of data that is floating around is validated and brought to the right person at the right time at the right location so that it adds value to something for that person. All the spreadsheets we make do that: they take a large amount of data and turn it into something the user needs to do something worthwhile. All the applications we write do just that: they transform data taken from numerous sources into something the user needs at that point so they have an advantage in something. This is what adding value means.


Knowledge is power. It's an old saying; in fact it is that old that it has become a cliché. But clichés become clichés for one simple reason: they are the truth, that's why everyone repeats them every time over and over again. So I will repeat it as well: knowledge is power. And knowledge can come from information. After all, if some data gives you added value you gain some knowledge. Knowledge others might not have and that gives you an advantage. I am not saying information equals knowledge but there is a strong link between those two. A lot of people benefit from having information and thus get more knowledge about a topic. A business tycoon that knows something that his competitors do not know has an edge. Usually this knowledge comes from information that has been provided to him. More often than not, that information has been made available through means of something the ICT industry has thought of.

Doesn't that make you happy? You as an ICT worker are in the position to provide power to people! We get to decide who gets what kind of information! We are the dealers of knowledge!

Ok, I exaggerate a bit but there is some truth to be found in what I am saying. We as ICT workers are for a large deal responsible for sharing the knowledge. How do we do this? Simple: by enabling people to use ICT. And that is where it all falls apart…

The information gap

In the old days, and by that I mean: before the mid-nineties of the last century, access to information technology was limited to the happy few. Although you could go to the shops to buy a PC very few people actually did so. To operate that machinery required skills, determination and a very abstract sort of mind. Not many people were willing to invest a lot of time and effort mastering the machine. And so even in households where the computer did make its entrance most of its power was used to play games. Then the World Wide Web came along. All of a sudden it was possible for people with limited knowledge of the devices to find data and even get information. Ok, it still wasn't easy to find what you were looking for and the machines were still hard to use but compared to the late eighties it all of sudden became a piece of cake. Lots and lots of people went out, bought a computer, put it in their homes and went online. However, these people only used a fraction of the power of what was available. A browser, a mail program and some simple word processing (and games, always games…) was all they were using. There was software available that might have helped people get information but that software was either hard to use or very expensive. And so even these enlightened people with access to the hardware were only touching the tip of the iceberg. There was a lot of potential information out there but there was a gap between that data and the people who could benefit from it.

The current state

And then Apple came along. They introduced the iPhone. No, they didn't invent the smartphone, or touch, or any other of the many things the ill-informed claim they invented, but they did enable a lot more people to get access to data. And more important: they did introduce a very, very important and often overlooked new thing: the app.

The app is short for application but it is more than that. To me, an application is a complex piece of software that does a lot of things, mostly centered on a set of task but not limited to that set. An app is simpler: it allows you to do one thing, and one thing only, but it does that very well. Thus, with the advent of the app and the devices that support it, all of a sudden people were able to use more and more software and get to more and more data. Since the law of large numbers started kicking in, more and more people had access to information.

Apps are easy to use. They do not require extensive training, they do not need long manuals. They are easy to use, usually are operated by one or two fingers and are very easy to take control of. Everyone can use them. And since a lot of people have very, very powerful but also very, very portable computing devices (we call them smartphones but that's what they really are: very portable powerful computers) a lot of people can have a lot of information at their fingertips. Everyone can gain knowledge. Everyone can benefit from the work us developers do.

The cold, hard truth.

But that's not true, is it? We as developers tend to think the situation I describe above is how the world looks like right now. And from our point of view it's true. If we look at the devices we have, if we look at all the data available, if we look at our peers, family members and so on we are tricked in believing we have reached a perfect world. A world where everyone can get to all the data they need and thus get all the information. However, we as developers often fail to realize we are "the chosen ones". We understand technology. And usually the people around us more or less understand it as well: it's either because they work in the same field, have the same level of education or simply because we taught them how to get the data. I think all of us have told our parents how to Google…

But there's a very, very big world out there that we don't teach. A world we don't reach. A world we usually don't even see. There's a very big group of people that still have no access to the knowledge we take for granted. The elder people for instance. They don't know how to use their shining new Lumia 1020 with 41mp cameras. They don't even know how to use to call their grandchildren. The result is they are getting afraid of the devices. It's expensive and they might break it (they think). So they don't use it. And they don't get the data they need.

A while ago I volunteered for a project where we spend 48 hours working on a piece of software that helped people prevent stress situations. We were invited by a Dutch institute for mental healthcare to talk to their clients and see what they need in order to get a better grip on their situation. Techies as we are, we thought of a nice solution that kept track of stress moments; the system would learn from daily entered data and thus warn the user that an upcoming situation might be stressful. However, we designed this system to run on a smartphone. After all, they would carry this with them all the time and so they could enter all the data it needed. The clients loved the idea but they had one tiny issue: none of them could afford a smartphone. These people were people who lived on social benefits and have no access to the devices we take for granted. They could use the computer in the treatment area if they wanted to (and that's where the final version would eventually run) but they had no fancy powerful portable computer of their own. We as technical people tend to forget these people.

And what about other groups? People like refugees? They could use a lot of data, they need information about the situation in their homeland. But they can't get it that easily. Hardware is not readily available and if it is (usually in the form of a shared PC) it's hard to use. Sure, they can use Bing and a browser to find something, but that's what we had in the last century. We can do a lot better.

Or take a look at people with disabilities. Sure, a smartphone is a great device but not very useful when you are visually challenged. You can't feel a keyboard on it, you don't know what they display is showing so it's useless for you.

And how about people from developing countries? They are even worse of. They don't even have that shared PC. And if they do it's usually some old third-hand Pentium II based machine with Netscape on it (if you know what I am talking about you know how terrible that is!). It's better than nothing but it's nothing compared to what we have here.

This is the way it is right now. A very large percentage of the world's population do not have access to information. They do not have the easy way we do to get knowledge. We do. This means the gap between the haves and the have-nots widens, at least when it comes to knowledge. And I think that's a bad situation. I think we need to do something about it.

So, what's next?

To be honest: I don't know. I don't have the solution. But I do know I feel very strong about this subject. I am not in a position where I can help people get to more hardware. If I could I would, but that's not what I do. What I do know however, is that I can focus on other groups. People who can have hardware but who are unable to use the devices because of its complexity. I spent a lot of time thinking about other ways to use machines. I have built software for the original Microsoft Surface (the big touch table) especially with these people in mind. I experiment currently with the Leap Motion device that allows controlling hardware without actually touching. I feel there's a way to help others with this but I haven't found it yet. But I will.

Software is still hard to use. Although we have come very far, we haven't even reached the point where I can say it's satisfactory. A very large group of people still do not know how to operate the device they are in front of. This is not only true for the PC but I also see a lot of people struggling with the iPad. And with the Android Phone. And with the Surface RT. It's still way too hard. By not designing software in such a way that these people (the elder, the disabled, the less talented, and so on) can use the machines as easy as we do, we are denying them access to knowledge. And to me, that is completely unacceptable.

So. The next time you start your compiler to write that great app for the smartphone, please take a moment and think about these people. If you're writing an app for displaying train departure times, please remember that during off-peak hours most of the travelers in trains are elderly people. But they don't understand the current apps. Make sure they get it. Make sure these people are not left out. Bruce Springsteen said it a lot of times during his concerts "Nobody wins, unless everybody wins". Please keep that in mind.

On behalf of the people who cannot say thank you online: thank you!

A forgotten audience?

Earlier this week I had an appointment at the Dutch Microsoft office to talk about people with disabilities and Apps. (You'll have to forgive me: I am Dutch and we don't care that much about being politically 100% correct; we'd rather get our point across than thinking hours and hours about the right term for a person with challenging visibility abilities: we call them blind people, so I will do that here as well. Not being insensitive, I'm just being Dutch).

I have to be honest. Although I work a lot on software for people with autism, I hardly ever think about making software for people who can't are almost can't see the screens. Or who can't hear a thing. Or who have no hands to make those nice gestures with.

But, I was told that a staggering large amount of people "suffer" from such conditions. Soon during the discussion the question arose: why aren't we all paying attention to this group? Are these people less likely to buy or apps? Or is it just not economically worthwhile to redesign your app so this group will also spend their hard earned money on the developers who built the app? For me, the answer is simple yet still embarrassing: I just don't think about that group. Later in the discussion it turned out how stupid that attitude I have is: I have a very mild form of colorblindness, something that I hardly even notice but that sometimes is a bit annoying when using apps that rely on recognizing colors. Yet I never even think about designing apps for people with disabilities (another disclaimer: I am not saying not being able to distinguish between similar shades of yellow and green is comparable to not having hands (disclaimer in a disclaimer: I CAN see the difference between every color very well, as long as they are written down in their hexadecimal RGB notation)).

The discussion that followed had me thinking. How would one make an app that is suitable for a blind person? Screen readers worked fine in the old days of command line applications. Some websites are optimized for screen readers as well. But how do blind people operate an iPad? Or a smart phone? I find the absence of not having tactile feedback (i.e. not feeling keys) on those devices a huge drawback: it means I have to look at what I am doing. Now, I have that choice: a blind person doesn't.

What can we do to help people who have limited abilities? How can we make software smarter so that everybody has access to the information they need? I have some ideas and I invite you to come up with some ideas as well. Please leave them in the comments and we can make this world a bit more accessible.

Oh, and if you're in the Netherlands around Saturday April 6th / Sunday April 7th I invite you to come to and we can try out some of the ideas we might have. It will be fun, I promise you that.

I can't wait to see what you come up with!

Search charm

Now, I am confused. One the rules of Windows Store Apps is that you make extensive use of the available charms. This means you do not add a "Share to FaceBook" button to your app, you don't add a "Print" button to your app and so on. Why? The reason is simple: there are charms available for this and the users know what they are and how to use them. So your app should adhere to this.

Now, we all know that some of the apps that Microsoft itself provides do not follow the guidelines themselves. I always thought that the reason for this was that those apps were designed or even written before the rules were written down. And then, earlier today, I got an update for the Mail app. To my surprise, I saw this:

Yes, indeed. A search button. To search your mail. If you press it, it will take you to the search charm, but why did they include that button here? This violates the rules. And they don't have the excuse of having written this prior to the rules: this is a new addition.

I am puzzled and a little bit angry: if we want the platform to succeed we need to have a consisted user experience and this hurts that.