Friday, April 09, 2010

Is Windows Phone 7 not having multi-tasking a good thing?

A number of people have been complaining that Windows Phone 7 won't have multi-tasking of apps.  They see this as a limitiation of the platform or some kind of insult to their rights as an application developer to be able to develop an application which works however they want it to.

Typically, the issue here is about creating applications which run in the background.

Firstly, let's be clear. Windows Phone 7 is a multi-tasking operating system. Many of the applications which come with the phone will run in the background. What Microsoft will be doing, though, is stopping other (3rd Party) applications installed on the phone from running in the background.

Why are they doing this?
Simply to preserve battery life. But wait. There's more. This isn't just about mainiting battery life for it's own sake.  It's about trying to ensure that the person who owns/uses the phone has a consistent positive experience with it.  If an application, running in the background, causes the battery life of the phone to be greatly reduced, the user won't blame the application. They'll think "that's a rubbish phone with a really short battery life". There, in one quick decision by the application developer, they've turned the users opinion of Windows Phone 7 (Microsoft shiny new brand) into a bad one. In doing so, such developers are not only hurting the platform they are also hurting themselves. For Microsoft it's more important that the user has a good experience with their phone than the developer can do whatever they want. Yes, you could consider that the bad programmers (those who don't know how to - or maybe even that they should - preserve battery life) have potentially spoilt it for the rest of us. However...

It's not all doom and gloom!
Windows Phone 7 supports a notification service which allows services running elsewhere (be it on a server or somewhere else in the cloud) to notify code on the phone. (i.e. Send a message to an application on a specific device.) This means that many operations which may be done by polling on lots of devices can be done once on a server. This invariably preserves device resources and likely reduces network connectivity (assuming an off device resource being queried by the app).


Why is it good that Microsoft have done this?
Because it forces developers to understand that preserving battery life is important. (This is one of my 5 pillars of good mobile development.)
In time this should help educate developers to better understand the needs of the platform. This should lead to better developers making better apps for happier customers. Everyone wins!


Why do people/developers think they need multi-tasking?
Probably one or more of:
Because they've had it before. (With Windows Mobile)
Because they don't understand the alternatives.
Because they're too lazy to do it another way.
Because they don't understand who Windows Phone 7 is for and therefore trying to do something inappropriate.

This is not Windows Mobile!
Windows Mobile was many things. While Windows Phone 7 is descendant from the Windows Mobile lineage it is a very different creation.
It won't make sense to port a lot of Windows Mobile applications to Windows Phone 7. (even if lots of developers want to.)

Will it always be like this?
For Windows Phone 7 probably.
Beyond that it's harder to say. If it's appropriate to the device and how it's intended to be used  I would expect it to be. I would, however also expect developers to become more used to doing processing in the cloud and therefore not needing to do as much in the background as they may be used to.
Microsoft have said that they will be willing to reconsider this in the future and may allow back ground tasks/multi-tasking in future version of Windows Phone. Even WP7!

What about other background tasks?
Other background tasks such as responding to events on the phone/device currently aren't supported. Maybe some will be in the future. But that's probably a discussion for another day...

Wednesday, April 07, 2010

Windows Phone User Group

I've started to see if there is any interest in starting a Windows Phone focused User Group in London.

As a long time Windows Mobile developer, I have often lamented the lack of a user group focuse in this area.

With the excitement and opportunities which Windows Phone 7 is bringing, now seems like a good time to do something about it. If no-one else is going to do anything, I will.

For a long time, I've found user groups an excellent way to learn about new technologies.  They offer an opportunity to learn from and with other interested people whihc is unique.
While many user groups have previously had the occasional session/presentation/demo on Windows Mobile, I feel there is something extra which can be gained from the depth which can be explored and discussed when focusing in a specific area.

(You may have guessed I like user groups as I run DevEvening.)

First things, first, I'm trying to find out if others also share an interest in this area and would be interested in attending such a user group.
If this is something which might be of interest to you, please show your interest by following @wpug on twitter.
If there is sufficient interest (which it's starting to look like there might be) I'll no doubt be looking for a venue and speakers.  If you can help with either of these, please get in touch.

Please also spread the news to anyone you think may be interested.

Thank you please.

Thursday, April 01, 2010

Frequently Asked Questions?

Almost every website or piece of software comes with a list of 'Frequently Asked Questions' or FAQs.

They exist as a form of self-help for the person who is or may be using the site/app.
In theory they're a good thing.  They answer the questions that people want to know and they don't have to directly contact the provider of the website or service.  This saves time (and money) for both the asker and askee.


Do they actually help?

If you have them on your site are you checking if they are actually answering the questions people have and/or solving their problems?
Are you checking that the people who read them are getting the answers they want or need?


Are they really 'frequently' asked?

How was the list first populated?  Did you just guess at the questions you thought people would ask? or are these the questions that people are asking (during early testing) and you don't have a better way of responding to?
Are you monitoring the questions that people are asking to you? and updating your FAQs appropriately?
If they're not frequently asked, do they need to be in the list? Taking up space and potentially hiding more valuable questions/answers.


Could you do without, at least, some of them?

Is this the best way to respond to genuine questions from customers or prospective customers?
If these questions are important could they answered in a better way than hidden in a list?
If the question is about the benefits or use of the site/app, could the benefit not be made more obvious or the site/app be made easier to use?
If the question is about an error or problem with the site/app, is this being addressed and the FAQ only displayed, temporarily, until this is fixed?

Ease of use is hard - people don't believe computers can be easy

Another lesson I've learnt from spending some time answering support emails recently is that people don't always expect computers to be clever.
This seems contradictory to the (apparently mis-)conception that people think computers are clever and can do remarkable things.

The issue in question relates to the entry of a unique alphanumeric code.  This code is printed on an insert that is distributed with various products.  Anyone purchasing one of these products can enter the code in a website to enable certain movie downloads.  The codes are 16 characters long and divided into groups of four characters with a hyphen. (The hyphen is intened to break the code up and make it easier to read.)

Unfortunately, some people have trouble reading and/or entering the codes.  To try and solve this problem themselves they try and use a different case, or use spaces instead of hypens, or remove the hyphens completely.

Guess what?

In this instance it makes absolutely no difference. The website is smart enough to ignore case and any spaces or non-alphanumeric characters.  This was deliberately done to try and account for variations in the ways people may enter the code.

So why do people try these variations?

Because for a lot of other situations/apps this may [have] work[ed].  That they do respond to this is simply due to not considering the user adequately.  Indirectly, they are also teaching users that they must do things in special ways that are easier for the computer and not them.  This definitely contradicts the idea that computers should make things easier for people.

None of this is the fault of the computer or the person trying to enter the code. This is learnt behaviour, caused by prior experiences with other poorly developed software.

The real problem in this instance is most probably due to the legibility of the printed characters.  A separate issue that is being addressed separately.


The other lesson to learn here is that when making software (or anything?) that works much better than anything people have used before you have to teach (or tell) the user that what you've developed is better.

Monday, March 08, 2010

Installing Hudson as a service on Windows Server 2008 R2 x64

I'm currently installing HUDSON on a VM to handle the CI for a project I'm working on.
Unfortunately I got errors when trying to install it as a Windows Service .
To investigate this further I checked the event log:

 Checking hudson.wrapper.log I saw:

2010-03-08 10:49:21 - Starting java -Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "C:\Users\Administrator\.hudson\hudson.war" --httpPort=8080


 This made me realise that the problem was that it didin't know how to start Java.exe.  So I simply added it's directory ("C:\Program Files (x86)\Java\jre6\bin\") to the PATH environment variable.

Problem sorted.  Hudson now runs as a service without problem.