Sunday, 29 November 2009

MSIE market share below 13%, the problem of not upgrading

MSIE is still by far the biggest browser on a world scale, but segmentation adds another picture:

* In some market segments, MSIE 6.0 is still used on more than 80% of all PCs.
* Some websites have MSIE below 50% (like W3Schools or some Delphi developer sites).

Users seem to upgrade their browsers very differently. MSIE is still used in very old versions on many PCs, Firefox users are much better at upgrading, and Chrome self-upgrades automatically. As an example, this blog has this distribution for the last 30 days:

* Firefox 52%
* MSIE 18%
* Chrome 15%
* Opera 8.7%
* Safari 4.0%

However, if you divide it by major browser versions, in order to see what standards the site needs to support, it looks like this:

* Firefox 3.5 41%
* Chrome 14%
* MSIE 7 12.7%
* Opera 9 8.7%
* Firefox 3.0 6.8%
* Safari (version > 520) 4.0%
* MSIE 8 3.2%
* MSIE 6 2.5%

As you can see, Chrome climbs to second place, and MSIE 7 is on 3rd place, but with a downwards trend. As others have noted, MSIE 7 market share on a global scale started its downwards trend before the release of MSIE 8, and MSIE 8 will probably not gain enough upwards momentum to replace regain the lost territory, any time soon:

There are good reasons for the Bring Down IE 6 campaign, even though it doesn't make sense in some industries that depend heavily on IE6. But actually, one of the most important supporters should be Microsoft... as the numbers show above, the slow adoption of new versions of MSIE is a market share killer, and for Microsoft it would make sense to ask users to upgrade to MSIE 8 asap.

Many websites do not specifically support Opera, Chrome, Safari and other browsers. Maybe they should categorize their numbers differently and reconsider which browsers they should support?

Friday, 27 November 2009

Google Wave is a software development platform

Google Wave has been reviewed in multiple places, but mostly by looking at the usefulness of the GUI tool that Google has made available. Instead, this post will focus on it's ability to compete with alternatives.

Google originally launched it as "e-mail as it would have been if we designed it today". However, it actually does not compete well with e-mail, for several reasons:

* There is currently no gateway for e-mail, indicating that it may be a problem to integrate it well with other messaging systems (SMS, MMS, SMTP, etc.)
* It can be very confusing to find out, who wrote what to whom and when. The replay function does not give a quick overview.
* It can be hard to find out, where in a wave there are changes.

There are many more reasons why Google Wave doesn't compete well for mails. It also does not compete well with most IM systems:

* In Google Wave, Person A can add person B to a wave that includes person C.
* The chronology is not 100% clear.

Again, there are more reasons. Google could probably build much of the features of e-mail and IM systems into the Google Wave protocol, like "do not allow participants of this wave to include other participants" etc., but a perfect IM system, built on top of Google Wave, would probably not be much different from other IM systems.

Collaboratively editing a document works much better in Google Spreadsheet than in Google Wave, simply because Google Spreadsheet delivers more structure to the document, with columns, tabs etc. For almost every generic purpose in Google Wave, there is a specialized application that does the job better, and these specialized apps usually work well together in a session.

Gadgets change the game: Gadgets make it possible to do things like collaboratively edit a mind map. This is great stuff, but it could have been done in Google Apps, as a new mindmap tool, too. As long as Google delivers it all, and you need to sign into Google to use it, there is not a huge difference. You can also insert gadgets in collaboratively edited Google Spreadsheet documents, so inserting Gadgets in Google Wave is not a benefit per se.

If an application developer wants to create a gadget for collaboration, this can be done in Google Spreadsheet or Google Wave. In both cases, the gadget needs to be available on a central server. However, there is one big difference: With Google Spreadsheet, data is stored in a single online service, whereas Google Wave makes it possible to have the data available on multiple servers at multiple companies at the same time.

Therefore, we can define Google Wave as: A platform for online collaboration applications, that features decentralized data storage and decentralized user authentication.

Google Wave becomes interesting when one of these events happen:

* the main user interfaces gives easy access to great collaboration gadgets
* companies start adopting Google Wave internally in their organization

Saturday, 21 November 2009

The power of app stores and usability

I use Vopium to reduce my phone bill when making international calls and calling back home from other countries. Very nice product, huge savings, no subscription fee, works seamlessly when making calls, and easy to install from their homepage. However, the obvious is to install such tools from the app store, right? So when I had to reinstall it this week and went for the Nokia App store, it was empty. There was just one tool in there: A new version of the Nokia app store (named Ovi Store). Using an expensive data connection in a foreign country, that's just extra costs.

Nokia's usability department seems to have had a vacation for the last couple of years, and this new version isn't better, even though it should be a high priority for Nokia to keep their smartphone market share. The online version of Ovi Store isn't much better, because when I go into the online store using my phone, it first tells me that there is a better way, than the HTML version: I can use the Nokia Ovi Store app. It asks me, if I want to use the app or continue to use the website. If I choose to use the website, it shows the first page of the mobile version of the website, and then it automatically starts the Nokia Ovi Store app, moving away from the HTML version. If I'm not allowed to use the HTML version, why did it ask?

If Nokia's market share for smartphones continues to drop, usability must be the reason. Fortunately, Vopium's homepage works perfectly in the Nokia mobile browser and solved my problem, I didn't have to use the Ovi Store.

If you are worrying about usability in your project, I can recommend the usability works of Søren Lauesen. In contrast to Jakob Nielsen, Søren's works contain more generic and deterministic methods.

Monday, 16 November 2009

Std. cookie use outlawed in EU

EU has investigated internet technology, and discovered that http-cookies are an invasion of privacy. Therefore, a new directive has been made, that forces consent before using cookies. To many programmers, this seems idiotic - cookies have worked well for 15 years, and continue to do so, and many businesses require them to be able to track users around. Even more, cookie permissions could easily be handled in the browser, but most people disable it because many websites are annoying to use if the popups keep appearing. So this directive, which will become law in EU, is a game changer, and it seems to have caught much of the industry by surprise.

However, who says that we should always push the limits of what technology can do, disregarding common sense for how to build a sane society? This new directive just means that cookies are not delivered unless consent is given. How are we going to implement this? You can ask for consent for sending all the cookies you want, so that your site can continue to work as before. Or you can switch to use other methods than cookies, for handling sessions. Using URL-based session identification makes the URLs annoying longer, so changing all links to POST-requests actually makes sense, even though it's surely not nice.

Besides the consent, there is actually something new: The "informed" part. What happens when non-technical users start to learn about what cookies can do? Will they just ignore it and move forward, or will it actually reduce the amount of cookies? Will there be technical changes to how cookies work? Which other technology will be the next to be regulated for privacy?

One thing is sure: technical workarounds are not meant to be legal. If the user can be tracked, no matter if it is by cookie or something else, there must be an informed consent.

Sunday, 1 November 2009

The case for Domain Specific Languages

Instead of wondering why Domain Specific Languages (DSLs) make sense, let's try to look at the number of people doing programming. According to various sources, there could be about:

* 9 million programmers in the world
* 0.5 million professional programmers in USA+Canada
* 25,000 self-employed programmers in USA+Canada

I live in Denmark, and can relate to these numbers - the situation probably looks similar here. However, a recent official statistics about internet usage in Denmark has asked the population, whether they have ever written a computer program. 18% of Danish men answer yes, 7% of Danish women answer yes, giving a total of 13% of the Danish population. This also seems very realistic, since primary schools, high schools, universities all teach programming. Compare this to the fact, that only 48% of the Danish men have tried to compress a file, and 25% of Danish women have tried the same, and connecting peripherials have been done by 72% of men and 51% of women. For background, 86% of Danish families have a computer at home, 83% have internet, 76% have high-speed internet. For families with children, 98% have a computer and 97% have internet. This is age-dependent, of course, and only 65% of the above-60 y.o. have internet at home. Education also influences percentages, and 94% of all university graduates have internet at home - and remember that 15% of the population is more than 65 y.o.

So, if the number of people, who are capable of writing a program, is far larger than the number of professional programmers, it makes sense to use the knowledge of these people to automate processes, that a professional programmer would struggle to understand. That's one place where DSLs makes sense.