How all EULAs should be written!

I haven't even finished installing Geosense for Windows but I love it already. Why? Because of their "lengthy license agreement".
I've copied it below:

Geosense for Windows
(license agreement, last updated February 26, 2010)

You cannot:

• redistribute or transmit the software for profit purposes without permission. (We're nice people, so just ask.)

You can:

• use the software for personal and commercial purposes.
• make copies of software for backup or archival purposes. (We won't lose our copies, so don't worry too much.)
• redistribute or otherwise transmit the software for non-profit purposes.

(Sinofsky was here.)

The "I agree" checkbox is even labelled nicely: "I authorize you to slap me if I violate the terms above"

It's so nice to be treated like a real person and be given something I can understand without needing an army of lawyers and a complete lack of a sense of humour.

Why would you use PhoneGap for WP7Dev?

I've had more positive feedback about my PhoneGap code than I was expecting which is all very good, but a lot of people are still asking me "Why would you use PhoneGap to cerate a Windows Phone 7 application?"

There are two reasons:
1. You have a really, really good reason to want to develop with HTML & Javascript, rather than C# and XNA or Silverlight.
2. You want to create an application that will target multiple mobile platforms and you want to only write the code once.

It's this second option which PhoneGap was created for.

And for balance, here are some reasons for not using PhoneGap to create a Windows Phone 7 application:

• You want to use some functionality which isn't available in the PhoneGap implmentation (and plug in support doesn't exist yet)
• You want to use the power of Silverlight and XAML for creating your UI.
• You want to use the power of XNA to create rich 3D graphics.
• You want the benefits of using Visual Studio and Expression Blend.

[WP7Dev] PhoneGap and Windows Phone 7

For all my talk and activities around Windows Phone 7 I'm aware I've shown very little about what I've been working on. Here's where I start to address this.
As you may have guessed by the title of this post, I've been looking at adding Windows Phone 7 support to PhoneGap.
For those of you who aren't familiar with PhoneGap it is "an open source development framework for building cross-platform mobile apps". It works by enabling apllicaitons written using the universal languages of HTML, JavaScript & CSS and compiling them into native apps for each supported platform.
I first used PhoneGap early last year when I needed to produce some proof-of-concept apps for the iPhone and I didn't fancy spending the time moving code to objective-C which I already had in JavaScript. (For the project in question it just wasn't worth the effort.) In the intervening time I've kept an eye on the PhoneGap project but not done much with it. I looked at its Windows Mobile support but didn't feel particularly motivated to do much with it. With the release of WP7 I found new interest in the project and am keen that apps developed for other devices/platforms can (where possible) be migrated to WP7 also. I have therefore written some code to try and implement this.

For those that are interested, the code can be found at http://github.com/mrlacey/phonegap-wp7. I know that others have started some work on this also. (Most notably at http://github.com/filmaj/phonegap-winphone.) I thought I would share what I've been doing to help the project. I'd already got further than the version by filmaj when I became aware of and have solved some issues they haven't dealt with yet.

So what is implemented?
In theory the easiest way to show what is implmented is show some test results. So here we are:

It passes 76 of 98 tests. Not bad. (Even if I say so myself).
As it's a shorter list, the tests that fail are the ones which relate to: HTML5 Storage, Contacts, File IO, Maps and methods which require objects being passed in their callback functions.
Some of these could possibly be implemented (File IO and possibly maps) but others just can't, due to limitations of the web browser control and the available APIs. Due to the way that interop with the browser control is implemented it's only possible to pass strings between the JavaScript and the C# code, it's not possible to pass objects to callback functions directly. In my code I have other functions which act as a wrapper to the callback functions so that they are passed appropriate objects but the automated tests don't pick this up.

It's probably a good time to point out that all I've done has only been tested in the Beta emulator. (I'd love to have a real device to test this on. Hint, hint!) Because some functionality requires can't be tested in the emulator, some of it is untested (e.g. navigator.notification.vibrate()) while other code always returns the same default values in the emulator.


How much functionality is implemented?

The following functionality is documented as supported across all platforms which PhoneGap supports:
Accelerometer: GetCurrentAccelleration is implemented but the watcher functions are not as these cannot be tested in the emulator.
Camera: getPicture is implemented but currently doesn't work properly as tombstoning of the app currently means that we lose all javascript references and so we don't have access to the callback.

Supporting tombstoning is the biggest issue with the current code. This could probably be worked around by storing all relevant callback details natively so they could be kept in state across deactivation/activation but I'd like to get some feedback on what I've done so far before spending more time on this.

Device: All features are implemented in JS, but limitations of the WP7 API currently mean that not all details are populated. It should be possible to get theses details with the release version of the API.
Events: deviceReady is not implemented as I have been unable to find a way to create events in the browser. It seems this can't be done, so I have implemented the PhoneGap.available property as a test for confirming loading.
Geolocation: getCurrentPosition is implemented (but returning a hardcoded vallue in the emulator). The watcher functions are not implemented as these cannot be tested in the emulator.
Network: this is implemented
Notification: this is fully implemented.

Additionally, the following other features are also implemented:
DebugConsole: log, warn and error methods
Orientation: getCurrentLocation and the watcher functions (as these can be tested in the emulator)
SMS: Send - triggers the compose functionality
Telephony: Call - triggers the request to make a call


To enable demonstration and testing of the implemented functionality I've created a simple app which demonstrates all the implemented features.

What else?
Other points of note in the code:

• While it's possible to load a file included in the project (in the webbrowsercontrol) any files loaded this way can't reference other files (JS, CSS, image or ohter HTML files) A partial work around is to try and merge all content into a single file but this can't deal with images. The browser doesn't currenlty support the data protocol but will in the next version (according to an email I've had from the team) so we would have to live without images if we went that route. The alternative is to load all content into Isolated Storage and view it from there. This is what I've done. Also rather than specify all the files to load manually (I couldn't find a way to query these from the XAP) I'm using a T4 template to generate the list of files to load.
• I'm using a command pattern to handle the different feature implementations. I'm using an abstract base class (PhoneGapCommand) for the commands and two optional interfaces to manage the variations in types of command (IAsyncCommand & IWatcherCommand). This works pretty well but feels like it could be better. I'm keen to discuss/explore alternatives to this.
• I've implemented a custom back stack to support navigation between pages. This recreates the behaviour you'd see elsewhere if navigating between XAML pages or html pages in IE.
• Because of the time it can take to load all the files to Isolated Storage and to prevent the webbrowser control being shown before the content has all loaded correctly I've had to implement my own version of the splash screen image. To use this the image must be set to a resource. In my code I have renamed the sample image to make this more obvious.

What next?
Ideally I'd like to contribute this code to the core project but I guess that will depend on what else others have done in terms of WP7 support.
There is also the key issue of how to work with (not around) the application model and how it affects javascript which really needs addressing before this could be considered publicly usable.

Please feel free to leave any feedback in the comments below, or in the discussion I'm about to start in the Google Group.

4 touch points!

Just wanted to clarify something for a few people.

The Windows Phone 7 hardware specs state a MINIMUM of 4 concurrent multi-touch points. This is not a maximum as many people have being saying.

In theory OEMs could produce devices which support more than 4.

I just wanted to clear that up and warn anyone off hardcoding any support for a maximum number.

WPUG: the first meeting

You may remember that previously I mentioned that I was looking at setting up a User Group focused on Windows Phone development.

The good news is that the group had it's first meeting last week. You can read all about it at
http://wpug.net/2010/07/31/the-first-meeting/

Technical Requirements Vs Implementation Details Documents

The following are some random ranty notes I wrote previously about two of the documents I was asked to prepare for a project and how what I'd been asked to produce didn't match what I thought should be done.
I post them here for my own possible future reference.

These two documents should be created separately. They have different purposes and are for different audiences. They are also created in different time frames as implementation details are dependent upon the technical requirements. (It is noted that the implementation details can be started before the technical requirements are finalised but this may cause rework of the implementation details if affected by subsequent changes to the technical requirements.)


Technical Requirements

What is agreed with the client about how the developed system/app/website (s/a/w) will work.

This document is for review/approval/confirmation with the client.


It may include:

• What technologies are to be used for development. (If relevant to the client/project)
• What hardware should be used. (If relevant to the client/project)
• What data should be captured by the system.
• The different ways data should be captured. Including which data at different points in the s/a/w.
• The different ways data should be displayed. Including which data at different points in the s/a/w.
• Details of s/a/w navigation. (If appropriate for the project)
• End user hardware & software requirements. (If appropriate for the project)
• Details of interfaces with external systems, including details of which data should be exchanged.
• Details of any reports the system should produce.
• Details about performance requirements.
• Details about error handling, reporting and escalation.

Implementation Details

These are the instructions about how to build the system/app/website that is being created for the client.

This is an internal document and should be of no concern to the client.

They may include:

• Any of the above if not already specified. (e.g. If the technologies to be used are not relevant to the client.)
• Database schema(s) for the data specified.
• Details of the internal structure of the code base.
• Coding patterns to use and details about where to use them.
• Additional information about working with any external systems.
• Any additional details about error handling, reporting and escalation.
• Possibly a breakdown of the development work into logical and/or related areas.
• Possibly estimates for the amount of time needed to complete the different areas of work.

Rant over.

WP7 Panoramas are not the same as hubs

There seems to be some confusion about hubs and panoramas, in Windows Phone 7, as many people think they are the same thing. They're not, but let's see if I can clear things up a bit.

Firstly a panorama or panoramic tile. (Please don't further complicate this by confusing this with a live tile though.)

This is the very wide display (typically 4 screen widths wide) that the user can swipe from side to side to navigate. Vertical scrolling is not supported. The background is typically a single picture.

Sample/Example panorama from the UI Design and Interaction Guide for Windows Phone 7 v2.0

A built in control will be provided for developer use in the next/RTM version of the SDK. But, for now, a very good alternative (and very similar to what will actually be shipping) can be found at http://phone.codeplex.com/.

So that's a panorama. It's simply a display and list control for use within an application.

So what about hubs?
Hubs are special applications which come on the device and serve as a central point for collating content, information and applications which are all focused on a single area.
The phones come with 6 built in hubs:

• People: for contacts and social media update integration, etc.
• Pictures: for photos taken on the device and synced from facebook or live.com
• Office: for OneNote, Word, Excel & Powerpoint
• Games: for all games (unsurprisingly) and including XBox LIve integration.
• Music + Video: no prizes for guessing what goes here
• Marketplace: for buying lots of lovely apps, games, music, etc.

As an aside it may be useful to note that only the 'Pictures' and 'Music + Video' hubs offer any level of third party application integration.

So why the confusion?
Because all hubs use panoramas in their main screens.
I strongly suspect that as developers couldn't make their own hubs, nor have they been provided a panorama control, this has no doubt led to the grouping together of these two things in peoples minds.

Anything else?
Well yes. It seems that developers may be able to develop their own hubs in the future after all...
  Windows Phone 7: Developers can build their own hubs
  Windows Phone 7: Microsoft explains and expands hubs



Has that cleared things up now?

Phoebe!!!

If you haven't seen the photos posted on Facebook or elsewhere then here are a few:

[WP7Dev] Why there's no built in integration for Twitter and the people hub

Warning: This post is speculative and my own assumptions. It is not based on any inside knowledge.

When people hear that (in addition to live.com) Windows Phone 7 only currently supports Facebook as an integrated information store. They often wonder why there's no built in Twitter support/integration with the people hub.

I'm not aware of an official reason, but as the question seems to come up so frequently I thought I'd document my thoughts on possible reasons.

1.  To preserve battery life
This is the most obvious reason I can think of. If you're following hundreds of people all around the world and they're tweeting regularly that can be dozens of updates every minute. (If not more!)  All those updates will soon add up to lots of network traffic, processing to handle them and space to store them. Then there's the issue of propogating the most important ones to the users attention. These are issues that I think are better solved by third parties, thereby leaving Microsoft free to focus on other parts of the OS.

2. Because everyone else is doing it
My next thought is based on the fact that everyone and his dog seems to be building a twitter client themselves. For many this seems to have become the new "Hello World" app. With so many other apps already in existence and each offering different features, having something built in at best would lead to duplication or at worst could stifle innovation by causing people to not create something new when part of the functionality is already on the phone. Having to deal with the moving target that is the Twitter API can also be an issue.  If it introduced any new breaking changes or major changes it'd be tough


All that aside, I have heard reports that Microsoft are talking with Twitter about how integration could work in the future.

Silverlight effects and Windows Phone 7

Windows Phone 7 allows us to create the UI for an application in Silverlight. (Or in XNA but just now I'm focusing on Silverlight.) Silverlight is known for it's excellent visual capabilities and ability to easily create great graphical effects. Let's look at what's available to us in Windows Phone 7.

Windows Phone 7 supports 3 effects: BlurEffect, ShaderEffect and DropShadowEffect. Silverlight (on the PC/Web) also specifies a PixelShader but this is not supported on the phone.

Effects can be applied to any UIElement but lets see how the BlurEffect and DropShadowEffect can be applied to a TextBlock. (A ShaderEffect is a bit more complicated and there's an example in MSDN.)

Here's a TextBlock you may recognise from a new "Windows Phone Application"

<TextBlock Text="page title" x:Name="textBlockListTitle" Style="{StaticResource PhoneTextPageTitle2Style}" />

And it (in the designer and emulator) looks like this:

Adding a BlurEffect is as easy as this:

<TextBlock Text="page title" x:Name="textBlockListTitle" Style="{StaticResource PhoneTextPageTitle2Style}">
    <TextBlock.Effect>
        <BlurEffect Radius="10" /> 
    <TextBlock.Effect>

<TextBlock>

which creates the following effect:

Or we can add a DropShadowEffect thusly:

<TextBlock Text="page title" x:Name="textBlockListTitle" Style="{StaticResource PhoneTextPageTitle2Style}">
    <TextBlock.Effect>
        <DropShadowEffect BlurRadius="15" Color="Azure" Direction="325" ShadowDepth="10" />
    <TextBlock.Effect>
<TextBlock>

to create:

Both those effect images are from the designer. But if we look at them in the emulator we see this:

The effect isn't applied.
Don't be fooled. This isn't an error or limitation of the emulator. This is what gets rendered on the phone with the above code.
Fear not though. It's a simple fix. Simply set the CacheMode on the UIElement that the effect is being applied to to "BitmapCache".
Like this:

<TextBlock CacheMode="BitmapCache" 

Then in the emulator we see:

and

So why does this work?

I haven't been able to find out the official reason, but here's my educated guess. If I find out the official reason I'll update this.

Silverlight (on the web/PC) always runs in the UI thread (unless you create any others yourself obviously). On the Phone it's different. The phone has two "main" threads. The UI thread and the "Render" thread which is used by the GPU. (Non-phone Silverlight may not always have access to a GPU while the phone always has one.)
Because the phone runs in a constrained environment it's important for it to be small. It therefore doesn't make sense for things to be specified twice when they could only exist once. I suspect that the ability to generate the effects is one such thing.
As a visual effect it makes sense for it to be calculated/generated/processed by the GPU so having the ability to also produce the effect by the process generating the visuals on the UI thread (the CPU) would just be unnecessary duplication.
Setting the CacheMode to BitmapCache forces the UIElement to be rendered by the GPU (as only it can handle Bitmap caching).
Of course it would be nice if the framework could also realise that these effects can only be applied by the GPU and so automatically use it to render them. Maybe this will be addressed in the future. Until then, at least we now know the work around.

What about the display in the designer?
Well that's WPF running on the desktop and handles the applying of effects without the need to force their rendering by a special process(or).

DevEvening and DDDSW presentations on Windows Phone 7

Below is a version of my slide deck from the presentations I gave last week at DevEvening and at DDDSW. I appreciate that the slides aren't particularly informative as they are mostly just images but hopefully this will be useful as a reminder of what I said at least.
As some people have asked for the stats I used and some code examples I'll hopefully post those soon too.

Why care about mobile? And what is Windows Phone 7?

View more presentations from Matt Lacey.


Some pics from DDDSW, courtesy of Craig Murphy.

These images from http://www.flickr.com/photos/craigmurphy/sets/72157624102207839/

2 questions before you port your Windows Mobile 6.X app to Windows Phone 7

Lots of people who have previously developed applications for Windows Mobile are rightly investigating porting them to Windows Phone 7. If you're one such person, there are a couple of important questions to ask/answer before diving into the code.
 
1. Can the application be ported?
Does your Windows Mobile application use features, APIs, functionality, etc. that does not exist or is not available to developers on WP7?
In many ways, Windows Phone 7 provides a mch more restricted environment for running applications.   If your application needs to use some functionality you won't be able to port it. Alternatively you may have to change the way it works.

2. Should the application be ported?
If you have an internal business application which you need to control distribution of and/or be able to release fast updates to it. You may want to wait until there are distribution options which support this.
If you need this level of control you should strongly consider staying on Windows Mobile for such "task focused" applications. Windows Mobile isn't dead. It will continue to be supported and enhanced for just such scenarios.
Microsoft are currently investigating ways of allowing distribution to only a specific group of people. This feature will hopefully be made available in the not to distant future so may address some issues. This is unlikely to allow bypassing the application approval/verification processes though. If you really need to be able to push out updates in a hurry this platofrm isn't for you. (yet?)

[WP7Dev] Windows Phone 7 books

UPDATED: 21-July-2010
There are a number of books about Windows Phone 7 development, currently being written, that I am aware of. They are:

"Programming Windows Phone 7 Series" by Charles Petzold
Published by Microsoft Press
This will be a free ebook.
Due for release "Fall 2010"
Preview contents available now.

"Learning Windows Phone Programming" by Yochay Kiriaty, Jaime Rodriguez
Published by O'Reilly
Due "December 2010"
2 sample chapters available now


"Windows Phone Secrets" by Paul Thurrott


"Beginning Windows Phone 7 Development" by Harry Lee
(amazon link)
Published by Apress
Due "Nov 2010"

"Professional Windows Phone 7 Application Development: Building Windows Phone Applications and Games Using Silverlight and XNA" by Nick Randolph
(amazon link)
Published by Wiley
Due "October 2010"

Silverlight Programming for Windows Phone 7 by Andy Wigley
Published by Microsoft Press

Microsoft XNA Game Studio 3.0: Learn Programming Now! – Revised to cover Windows Phone 7, by Rob Miles
Published by Microsoft Press

Windows Phone 7 Plain & Simple by Michael Stroh
Published by Microsoft Press

Advanced Windows Phone 7 Programming by Doug Boling
Published by Microsoft Press

Windows Phone 7 Game Development by Adam Dawes
Published by Apress
Due "December 2010"
There's also one in progress for Wrox. But no website, samples or other details available yet.

Windows Phone 7 Videos & Podcasts

There is currently lots of confusion and uncertaintyaround Windows Phone 7 but there is also a lot of information on the web. In an attempt to try and help make some of it more discoverable, here's a collection of podcasts and videos.

Podcasts
.NET Rocks
Charlie Kindel on Windows Phone 7
Daniel Egan talks Windows Phone 7 Live at Launch
Brandon Watson Live in Atlanta

Hansel minutes
Windows Phone 7 Series - The Developer Experience with Charlie Kindel
Charles Petzold on Windows Phone 7 Series

Zune Insider
Windows Phone 7 Deep-Dive

Videos
MIX '10

Channel 9 (lots!)

Dimecasts.net
Creating and using the Application Bar w/ Windows Phone 7
Understanding Navigation on Windows Phone 7

YouTube (official channel)

Ustream
IndyTechFest - Windows Phone 7 XNA 05/22/10

msdev.com
Windows Phone 7 in 7!

MSDN Bytes
Charlie Kindel interview

UK TechDays
here (via Mike Taulty) & here (select Developer days > Friday)

Windows Phone 7 Backstage
Past (recorded) events

ZDNet UK
Charlie Kindel interview - part 1 & part 2


If you know of any others please link them up in the comments.

Notes: Tap is the new click

We're using bodies evolved for hunting, gathering, and gratuitous violence for information age tasks like word processing and spreadsheet tweaking.

—David Liddle

Gesture: any physical movement that can be sensed and responded to by a digital system without the aid of a traditional input device such as a mouse or stylus.

—Dan Saffer

Avoid putting essential features or information like a label below an interface element that can be touched, as it may become hidden by the user’s own hand.

—Dan Saffer

The complexity of the gesture should match the complexity of the task at hand.

—Dan Saffer

The best designs are those that “dissolve into behavior.”

—Naoto Fukasawa

The best, most natural designs, then, are those that match the behavior of the system to the gesture humans might already do to enable that behavior.

—Dan Saffer

Windows Phone Developer Tools CTP - Upgrade Warning

Oh, a nice little upgrade incompatibility (breaking change) warning from the new version of the Windows Phone 7 Developer tools CTP.

Surely that should be: "...created by a previous..."

The XML change:


    
    
    
    
    
    
    
    
    


Note that it's WMAppManifest.xml not WPAppManifest.xml - Another internal reference to "Mobile" rather than "Phone" still hanging around?

The Realities of The Fantastic Tavern #TFTLondon

Yesterday I had my first opportunity to visit The Fantastic Tavern. (It's like a software user group but aimed at designers)  The theme of the night was "[Augmented] Realitites".

A couple of more details write ups of the event can be found at:
http://vinf.net/2010/04/29/augmented-reality-tftlondon/
http://ubelly.com/2010/04/realities-blurring-the-boundaries-at-the-fantastic-tavern/

At the end of the night the open Q&A was concluded with an unanswered question about how to prevent a situation where you look through your AR application to see hundreds (thousands) of additional competing pieces of information all laid over (and probably obscuring) the image?

I have a different but related question though. How do we get to that point? At the moment all AR apps are separate and you could potentially have dozens on a device. How do you combine the information from different applications? Is anyone looking at/making a way to do this?  And are they doing it in a way that avoids the overload feared in the original question?

My othewr question:
All AR apps seem to be driven by the person specifically using a device. Is anything being developed where the location identifies the person and provides additional relevant information to them?  At an extreme case think of the iris recognition in Minority Report.  But on a more practical (and realisitic/easily achievable) level what about ticket booths at railway stations. Why not give me useful information while waiting to buy my ticket? For instance, if I buy a ticket to a location I've not visited before (based on previous purchases made with that card) why not tell me which platform I need and show me directions.


As I was tired and the place was very hot and noisy I didn't hang around for long afterwards. Lots of interesting ideas though.

Please [don't (?)] peek at Orange

 

This is a really poor quality photo (taken with my phone) of one of my local orange stores.  As you probably can't tell. The store is currently closed for a refit.  The entire front of the store is covered with black paper.  In large letters it says "hey, no peeking" and then there are some generic numbers you can call for more information.  On the other window (not shown) it says when the store will be reopening and has details of the nearest alternate store.

While I can appreciate that they are trying to have a sense of humour with the message being displayed. The entire store front basically says "go away".  This doesn't strike me as the best things they could have done with what's a potentially very valuable opportunity to engage with potential customers.

Why not take this opportunity to engage with potential new/future customers?
Instead of stopping people from seeing what you're doing why not show them?
Or better still, why not show them something that intrigues, entertains and encourages interest and word of mouth?

Here's what I'd do:
Instead of having paper covering the whole store front, I'd leave gaps and encourge people to look through.
I'd create the gaps at different heights (including very low and very high - deliberately making it harder for everyone to see everything) and behind each I'd have something different.  Behind some I'd have static images, promtions, info, etc.  I'd also have competitions and discounts avaialble on a text to win basis.  Any such prizes would of course be linked to discounts limited to the day of reopening.
But behind certain key gaps I'd have screens and while some may occasionally provide information on when the store will reopen the real value would be in having unique, entertaining footage.  This could be all sorts of things: It could look like the store was completely missing; what if it looked like the store was being filled with something completely ridiculous - animals, water, a ball pool?; it could look like people supposedly doing the refit but who suddenly break into dance.  The only limit would be imagination (oh and cost) but such footage could potentially be reused across multiple store refits and then made available online.

• How many people just walk straight past a store that's closed for refit?
• How many would stop to peek in if they thought they'd get to see something they normally wouldn't?
• If you walked past a store that was obviously closed but had people clammering to peer in at the window, wouldn't you be at least slightly curious yourself?  Admit it, there's a bit of a voyeur in all of us.
• Who's done something like this before? (in the UK?) Don't you think people would talk about it? And want to come and see for themselves?  And at the same time being educated about the reopening and the brand in general.

In that, as Orange, I'd know who had bought a phone there before or lived nearby and was shortly due an upgrade I'd email or SMS them (subject to previously expressed mailing preferences) to let them know a bit about some of the new phones that will be available when the store reopens.  I'd also, obviously, tell them when it would reopen. And I'd tell them to come and have a peek in the window to see what was going on while the refit was going on.

The aim would be to engage with [potential] customers, promote the newly refurbished store and encourage word of mouth that means that when the store reopens more people will be aware of it and be eager to see what has actually changed.

Well, that's what I'd do.

I hope the refit doesn't get rid of the fish tank they used to have.  Disappointinglyt that was often far more interesting than most of the phones there.

Oh and for the record, I've had (among others) a contract with Orange for more than 12 years, but I'm frequently starting to wonder why.

Avoiding a substandard product

“If you don’t have a triad of a designer, technologist, and business professional all coming to the table with equal skills and equal levels of creativity, the result will be a substandard product” 

– Bill Buxton 2010

More boats in the water

At the start of the year the blogosphere was, as ever, full of predictions for the coming year.
A common trend among many predictions was that there would be a thinning of the numbers of companies in the mobile OS business.

With Palm now up for sale we're starting to see some of those predictions beginning to come true.

A common prediction was that Microsoft would end up leaving the mobile space.

Almost in contrast to popular opinion, I tried to argue that they wouldn't.  I claimed that mobile was to important for Microsoft to not be in the party.  I said they wouldn't just roll over and die.
For over a year Microsoft had been talking about their "3 screens and a cloud" strategy but had hardly made any real indication of what the experience around the phone screen would really be.  I thought this noticeable in it's absence.
At the time Windows Phone 7 hadn't formally been announced - but we all knew it was coming, just not what it would be.

So here we are in mid April.  Windows Phone 7 (now without any reference to "series") has been more positively rceived than most would have expected.  Plus, the Kin has also now been announced to much praise.


So what's all this got to do with boats?
Well, in a Twitter conversation at the time I used that analogy of shipping.  I said that to be successful in the mobile industry you needed the flexibility of a fleet of canoes, while Microsoft had been more like an oil tanker.
Now, while Microsoft is still a large vessel in the water it's giving the impression of being surrounded by a floatiller of smaller craft.

Beware the lollipop!

"Beware the lollipop of mediocrity. Lick it once and you will suck it FOREVER."

- Brian Wilson

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...

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 brining, 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.

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.