Thursday, December 23, 2010

Adding an item to a list and scrolling it into view #wp7dev

For reasons can't explain rightly explain, it was a bit tricky to add an item to a list (in a Windows Phone 7 application - unsurprisingly) and then scroll the list so the new item was displayed.

I eventually got this working by forcing the call to scroll the new item into view on the UI thread.

Consider this in a default DataBound application:

  private void ApplicationBarIconButton_Click(object sender, EventArgs e)
  {
    App.ViewModel.Items.Add(new ItemViewModel
                                {
                                  LineOne = "new L1",
                                  LineTwo = "new L2",
                                  LineThree = "new L3"
                                });
 
    Dispatcher.BeginInvoke(() =>
      MainListBox.ScrollIntoView(MainListBox.Items.Last()));
  }


Without doing this, the list will scroll to the item which was previously the last on the list.

Tuesday, December 21, 2010

Rolling your own cut and paste is acceptable in the marketplace #wp7dev

I'm sure you'll be thrilled to know that my Scratch Pad app is now available in the Marketplace. More important than creating a custom cut and paste implementation, this proves that it's possible to store data on the device and share it between applications.

In time, I'll explain how I did this. And, also, why you, probably shouldn't!

Until then please feel free to tweet about my app and be sure to use the hashcode #wp7comp or post your comments here.

Friday, December 10, 2010

Cut and Paste with the current #WP7Dev tools

For a lot of people the lack of native Cut & Paste support in the current (initial) version of Windows Phone 7 is a big deal.

I've heard a surprisingly large amount of people tell me that it's essential that they can copy and paste text* on a phone. Personally I hardly ever used this feature when I was using a phone which had it though.

I've pointed out to a few people that it's possible to implement the cutting, copying and pasting of text within an application quite easily. (It actually only take a handful of lines of code.) But no-one (AFAIK) has taken the initiative to do this. Before now...

The issue isn't really being able to cut and paste text though. What people really want is a way to easily share data between applications. When people say "cut and paste" they, typcially, mean they want to take (copy) some data (text) from one application and then use (paste) it in another application.

As native functionality, this isn't currently possible.
However this will be coming in an remote update early next year.

So if we want copy and paste in our apps we have to either wait or try and do it ourselves.

Surprisingly, the sandboxed nature of 3rd party applications on the phone has lead many (most?) to assume that this isn't possible.

I beg to differ!

Take a lok at this video of 3 apps I wrote. 2 accept the entry of text and support methods of multiple word selection (also not currently available natively) and cutting, copying and pasting text. The third app just shows what is in the "Shared Clipboard". Yes. These apps all have access to the same clipboard. And, no, this isn't done by sending the data to a remote web server or anything like that. It's also not using anything not publically available and only uses public, authorized API methods.



To try and prove that this is really possible I've submitted Scratch Pad to the marketplace. When it's accepted you can try it for yourself. Plus acceptance will show it's not using anything it shouldn't (or you couldn't) and that it doesn't require a data connection.

With native support for cut and paste coming in early 2011 (most people are assuming in January) I'm not planning on sharing the clipboard code as there is a small side effect to using it that it's probably best not to burden users with. But, I assume that you're smart enough to work out how I did this if you really wanted to. ;)

* It's always text that people want to copy and paste. I haven't, yet, heard anyone give a case for wanting this for any other data type on a phone.

Tuesday, December 07, 2010

[WP7Dev] Gotchas when detecting network connectivity

When developing for an occassionaly connected device it's useful to know if there's a connection currently available.

The Windows Phone 7 SDK makes this very easy with the GetIsNetworkAvailable() method on the NetworkInterface class.

There are, however, two gotchas you need to be aware of when debugging.

1. If you call this method in code running in the emulator it will always return true.

2. If you call this method in code running on a tethered device (as you may have connected when debugging on a real device) it will always return true.

In both instances you'll need to code around the issue. (Or set break points and move the next/current executing line.)

You should also write code to handle the situation where a network connection is available but your specific web service/site isn't.

Hope this saves someone some head scratching.

Tuesday, November 09, 2010

PhoneGap for WP7Dev and the RTM version of the SDK

For anyone interested, I've just pushed a new version of my WP7 PhoneGap implementation up to GitHub.
The code can be found at https://github.com/mrlacey/phonegap-wp7/tree/master/rtm/.

Please note that this doesn't do anything special. It's basically just the old code slightly restructured, with the mobile spec tests removed and using the latest project formatting.The only real difference is that it works with the RTM version of the SDK.
I've tested it with VS2010 Ultimate & Express.

Important! This still does not handle tombstoning!
Until it does, this should be considered proof of concept only and is definitely not production ready.
Unfortunately support for tombstoning is going to require a very big change to the structure of the existing code and will impact all the JS/C# interop.
However, as I've found the time to fix the code referenced above that shows I'm working through my to-do list and getting closer to finding/having the time to make the big change.

Thursday, November 04, 2010

Learning, not moaning.

If you follow me on Twitter you may have noticed that I have a tendency to complain about poor service and badly produced apps quite a bit. In an attempt to be a bit more positive I thought I'd see what I can learn from these issues rather than just moan.

Here's what I've learnt in the last few days.


Issue:
If you have an Orange Broadband account and have set up an online account to look at bills, etc. You'll discover there isn't a way to change your password and if you forget it you have to call a phone number to speak to "tehnical support" and have them tell you it. If you then ask to change the password they will tell you not to. Presumably because it's a non-trivial task for them.

Lesson learned:
Understand security. Make sure "technical staff" understand security. Make it easy to change passwords.


Issue:
When trying to speak to someone at Direct Line I had to go through their automated phone system which presented options I had to select by pressing numbers.

Lesson learned:
Make things easy to navigate and test navigation routes.


Issue:
When trying to log in to a website (mentioning no names), I eventually discovered why my password wasn't working. - It was because I had CAPS LOCK on. But I had no way of seeing this as the entered characters were masked. (The username/email had been saved by the browser so I didn't see the upper case characters being entered there as I didn't have to type anything else.)

Lesson learned:
Indicate if CAPS LOCK is on when the user is entering text which isn't displayed - like with a password entry box when characters are starred out.
Or, write a password checking system which accepts either correctly cased passwords or passwords entered with case inversion. This means storing 2 hashes of the password (& salt) but is only a very small amount of work which could save a lot of frustration for any user who can't see why their password isn't being accepted.
I'm holding off on ignoring case entirely in passwords though. That seems like a step to far and would be more of a compromise in security and invalidate the user's attempts to use a strong password.


Issue:
I just installed some of the apps in Windows Live Essentials but it also installed some of the apps I asked it not to install.

Lesson learned:
Thoroughly test installers!
and, in case this is a dependency issue - be sure to indicate dependencies and other things which must be installed as well, clearly.


Issue:
It took 2 phone calls taking over 25 minutes to stop Orange from taking payments from my account which they should not be - due to a mistake that they made. When this was finally sorted no-one said sorry and I haven't been given anything for the trouble (of them taking payments they weren't due or for the inconvenience and time taken for me to identify the issue and get them to sort it out.).

Lesson learned:
Say sorry and provide compensation (of some appropriate sort) when you make a mistake.


Yes that's a lot of issues for two days but I think about these things a lot because I want to make awesome apps (and services) which don't frustrate the user or contain stupid decisions or do anything apart from make it easy on the user and get out of their way.

Friday, October 22, 2010

PhoneGap at LDNUG

On Wednesday I gave my first talk at the London .Net User Group.
I gave a brief introduction to PhoneGap and briefly showed how to use it to create an app for Windows Phone 7.

The main place to go for all things PhoneGap is http://www.phonegap.com/ but if you're after the Windows Phone 7 version this is currently at http://github.com/mrlacey/phonegap-wp7. (Please note that the WP7 version on GitHub doesn't work with the RTM tools. I hope to upload the fix for that tonight. Lots more excciting functionality will be coming shortly too.)


View more presentations from Matt Lacey.

Friday, October 15, 2010

[WP7Dev] Attention to detail is VITAL!

Take a look at this screenshot of some of the apps already in the marketplace, as shown in the Zune desktop client.


Notice how some of the images look very odd. They look very much like they've been created as white images with a transparent background on the intention/assumption that they will always be displayed on a black background. Yes, that assumption was wrong.

Remember, Windows Phone 7 is a platform where quality is essential. How you do something is more important than what you do.

The marketplace is like your store front and the icon is like your packaging. Would you think twice about something with poorly printed packaging? Would it make you question the attention to detail paid in the rest of the production process? And, would you even reconsider buying from a store where products were poorly packaged?


Please don't make this same mistake with your apps.

Bad apps don't just hurt the developers, they hurt all developers as they hurt the platform. If it was up to me apps with images like that shown above would have failed the submission process.

Tuesday, October 12, 2010

WP7Dev at VBUG London

Yesterday I gave an introduction to developing for Windows Phone 7 at VBUG in London.
A great bunch of people were there and they asked a lot of good questions and seemed excited about the platform and the opportunities it affords. Respect also goes to the people who travelled down from Stafford for the event.

As lots of people asked for them, my slides are below and (most of) the sample code can be downloaded here.

Monday, October 11, 2010

Windows Phone 7 - How? Not what?

This afternoon (in the UK & jointly in the US at the same time) there is a press conference where Windows Phone 7 will be launched. (We assume.) Unfortunately, I won't be there.

While, I won't be there today, I was able to spend some time with Oded Ran (UK Head of Marketing for Windows Phone) the other week. While I didn't learn anything I hadn't heard before (because I already know loads - not because there wasn't anything interesting said) I did get to see a few more apps that will be available on launch.

The really interesting point that was raised though was that it's about how the phone does what it does and not about what it does.

This is an important distinction and one that has been seemingly overlooked in terms of a lot of what has so far been communicated to developers.

Lots has been said about a lack of third party background processes and cut and paste support (amongst other things). These things matter in small part to most and for those who they really matter to they will be available in time. Having these things is unlikley to be a deciding factor to a lot of people though. It's going to take something special to differentiate these phones such that people will want to buy them.

Let's talk about who those people are for a minute. Not everyone is going to buy a Windows Phone 7 device. That's Ok. Not everybody is the same. Not everyone wants, needs or can afford a smartphone.

So let's consider the people who want and can afford a "smartphone". As far as I'm concerned, in the UK smartphones mean iPhone, Android, Windows Phone 7, Blackberry, some Nokias & Palm (but nobody has one.)
Guess what? there's room for all of them. Despite what some people seem to think there won't be a single/company/platform which ends up being the only one.

Currently (before the WP7 launch/release) smartphones differentiate themselves on apps and features. Windows Phone 7 is different. It differentaites itself on execution and integration.

What does this mean?
It means it's not going to try and differentiate itself based on what you can do with the device. Afterall you can get a phone which will let you access Facebook for just a few pounds. What WP7 does is offer an amazing, integrated experience with Facebook that is a pleasure to use.
It doesn't stop there though:

The mail application is the best I've seen on any device.

Integrated XBox Live gaming is incredible.

The "authentically digital" interface is fast, responsive and beautiful.

It's simple to use and navigate around the different applications.

And it even makes and receives phone calls!

No, it doesn't do everything - yet. But what it does do it does with a level of style, polish and finish that people will love. Personally, I can't wait to get my hands on a final device.

I'm happy that I'm not going to convince you with words that you should consider Windows Phone when you're looking to get a new smartphone. What I will say is that I'm not aware of anyone who has tried using one and not found it great. Borrow one, or try one out in store (when available) and see what you think. Put any perceptions you have based on Microsoft's previous mobile offerings and prepare to be impressed!

Ok, rant over, lets see what the launch brings....

Sunday, October 10, 2010

Saturday, October 09, 2010

Wednesday, September 29, 2010

Project 52 - done

Back at the start of the year I signed up to Project 52.

The idea was that in making some kind of pledge to post once a week it may help me to write at least as many posts as I did in 2009 (53).

I've just realised that this will be my 55th post this year so I'm declaring job done.

I haven't tagged/labelled all the posts with project52 like I was supposed to but I don't think that really matters.

Here's to more posts!

The next step may looks like it will be to try some video blogging. Let's see what happens.....

[WP7Dev] Does large text in titles waste valuable screen real estate?

When it comes to a mobile user interfac, the top of the screen is the most valuable real estate. It should therefore be used for the most important information. It may, therefore, seem odd that the default Silverlight application templates fill the top of the screen with text that doesn't change. Just take a look at the top of the screen from a simple app.


 The top of the screen is filled with the the applicaiton name ("MY APPLICATION") and some text. In this case the "page name". While having this information occupy prime real estate may be good from a branding point of view, this could be seen as a waste.

Fortunately the UI guidelines give us a good reason for this behaviour:
Applications that expect user interaction during a phone call should have a minimum 75 pixel margin on the edge of the device that has the power button. No touchable UI elements should be placed within that margin.

 It's a phone! People will want to make phone calls with it. If they can do this while still using your app, let them.

Tuesday, September 28, 2010

"Awesome apps that improve lives"

This is all I want to make: "awesome apps that improve lives"!

But what does this mean?

Let's break it down into 3 parts:
  1.    awesome
  2.    apps
  3.    that improve lives

"Awesome"
  • Because mediocraty sucks.
  • Because just doing enough isn't enough.
  • Because expectations should be exceeded. I want to deliver more than was promised. Not be justifying why someone is getting less.
  • Being awesome is easier than you might think. Because so few people do it.
  • Hopefully being awesome will get harder.  Hopefully this will be because more people are also making awesome software.

"apps"
  • Why apps? (By which I mean software.)
  • Because that's what I know and have made, studied and continued to learn about for the last 15+ years.
  • A few years ago I did some consultancy for a couple of mobile device manufacturers based on some prior work I had done on evaluating handheld computing devices.  Apart from that I've always focused far more on the 'soft' side of things.

"that improve lives"

What does it mean to "improve lives"?
  • To make things easier.
  • To make things faster.
  • To make things cheaper.
  • To make things a pleasure, not a chore.
  • To allow people to focus on the important rather than the trivial or mundane.

Simples.

Alternatives to polling

Recently I blogged that "Polling is a smelly anti-pattern!".

I think it will be useful if I expand on this a bit.
I should probably also have been clearer that this is about polling on a timer. i.e. Every X seconds (or minutes) query the server to look for updated data,  new messages, current status, etc.

Avoiding polling in a mobile app is a rule.
While I don't subscribe to the idea that "rules are made to be broken", I do believe that rules can be broken when appropriate (It's laws that can't be broken and I'm don't know any laws of software development!) but only on the following basis:
  • Firstly learn the rule.
  • Secondly, learn the reason(s) the rule exists.
  • Thirdly, learn the consequences of breaking the rule.
  • Fourthly, do the same for the alternatives to the rule.

Only once you've been throught the above four steps should you consider breaking the rule.


Ok, back to basics, why is timer based polling a bad idea in mobile apps?

2 reasons:
1. It may (depending on the platform) prevent the device from going to sleep/standby. If the device is prevented from going in to standby means that the battery will drain faster. When the battery runs out the device is useless so it's in the interests of both the users and the person wanting the application to be used for the battery to last as long as possible. SOme platforms may even wake the device when the timer fires - almost completely avoiding the benefit to battery preservation which a standby mode can provide.

2. By making a request just to see if there is some new data on a server the application is using the devices data connection. While a request that only responds with a message that there are no new messages is likely (hopefully) to be a small message it still uses network bandwidth. For some users, the cost of network access can be very expensive. A few bytes every minute (or however frequently you check) can add up.

So, breaking the rule may mean you run the users battery down and push up their data charges. See, I told you polling could be bad!


What about the alternatives?

There are a number of alternatives but their usefulness and availability depends on the platform you are using and the particular scenario.

If the application needs to be notified when something changes remotely this could be pushed from the remote location. This could be done with true push messages or with in a cruder method such as HTTP long polling.

Some platforms offfer the ability to subscribe and respond to system level events. This may be a change in the time, network connectivity or something else. This can be a very effective alternative to polling when it's available.
Subscribing to the hour changing can put much lower demands on the resources of a device when compared to running a timer which will only fire once an hour.
Subscribing to notification of email or SMS being recieved can be a good time to also check for new messages, etc. as there is a much greater chance of a network conenction being avaialble (You hadn't forgotten that you need to account of occassional connectedness - I'm sure.) It's also more likley that user will be in a position to see any new message and react to it - as they've just responded to an email or SMS notification.

Or check when the device is woken from sleep (if the platform offers the ability to detect this). This avoids the need to update status or list of unread messages when the screen is off and the user won't see them.

There is of course another scenario which is important to remember: when you must used timer based polling because the platform does not provide any other way of implementing the functionality. Obviously in this scenario you have to use it. Just make sure that you are aware of the consequences.

If you must poll, reconsider how often you do it. You can probably do it less often than your users think you need to ;)

To summarise:
Use polling when you must. But, avoid it if you can. And see if you can do it less often.

[WP7Dev] in 7 minutes

Thursday, September 23, 2010

[WP7Dev] What do developers still want?

The RTM version of the Windows Phone 7 development tools are now available for download. But what do the people who are using them think is still missing? What do developers really want added to the platform?

At the last WPUG meeting I asked some. Here are the results:

The most popular requests:
  • Cut & paste / clipboard support x7
  • Background processing / 3rd party multitasking x4
  • Camera APIs x4
  • Contact detail access (people hub integration) x3
  • Built in barcode scanning x2

Other requests:
  • A built in Physics engine
  • A complete implementation of HttpWebRequest
  • A personal details card that could be passed to apps to fill in my details
  • Ability to change system wide background colour
  • Access to tile sizing
  • Dynamic language support
  • Good twitter stuff
  • Integrated security with user's Windows Live account
  • Jump list silverlight control
  • Managed Facebook wrapper
  • More Metro integration from within XNA
  • Peer comms
  • Shared data between apps
  • Built in animations
  • SQL DB
  • Swipe navigation elements
  • VOIP
  • XPath

And then the things that people didn't realise were already there:
  • Bing Maps control x3
  • Multiple calendars
  • Pivot & Panorama controls
  • Support for accelerometer in XNA
  • OTA Updates

I'll let you draw your own conclusions from the results...

Thursday, September 16, 2010

Thank you NEBytes

Yesterday I went up to NEBytes to talk about Windows Phone 7 development. (Were you expecting me to talk about something else?)

I had a really great time and the audience seemed engaged and had lots of questions. (Which I take as being a good thing.) Thank you to the NEBytes teams for inviting me and organising the event.

Looking forward to the other user group talks I'm doing in the next few months. ;)

Tuesday, September 07, 2010

Polling is a smelly anti-pattern!

 As someone who reads my blog I'm sure you're well aware of good practices around mobile development so this won't come as a surprise to you.
In response to a question on Stack Overflow, today, I wrote the following.

"Polling a server from a mobile device is at best a code smell but typically an anti-pattern as it has resource usage (and possibly performance) implications."

It seemed worth repeating. ;)

Friday, August 20, 2010

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.

Thursday, August 19, 2010

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.

Tuesday, August 17, 2010

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

Tuesday, August 10, 2010

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.

Monday, August 02, 2010

Will Windows Phone 7 be successful?

A few days back I posted a comment on this computerweekly.com article about Windows Phone 7. I had some positive feedback about my comments via twitter - including the following from the author of the article:
"how long have I been doing this - 15 years? Quite the longest & most powerful comment I have ever seen. Thanks VERY much!"

I thought I'd repost some of it here:

Is Windows Phone 7 going to be popular enough to be worth considering developing apps for?

Obviously no one knows the answer for sure yet, but as you've probably guessed, I think they will be popular enough to invest my time learning about and developing applications for.
But why?
  • They are amazing devices. Please don't write them off till you've used one.
  • Microsoft knows this industry. Windows Mobile was really good back in the day and while they've drifted off course in the last few years all the evidence seems to be that they've been carefully watching the market change around them and learning from it. And they've also been learning from their own experiences. (Arguably, while Android re-make a lot of the mistakes which were made with Windows Mobile.)
  • Windows Phone is designed specifically for mobile use in a way that we've not seen on other devices before. Plus it's not trying to be something it isn't or shouldn't be - a PC on phone hardware.
  • Microsoft has spent the last 5 months trying to convince developers to build apps for the phones. And developers have been responding. There will be a lot of high quality apps available in the marketplace when the devices launch.
  • There are also a lot of desktop and web developers who are currently using Microsoft technologies who are keen to build for mobile as it
  • The (fully transparent) marketplace policies Microsoft are putting in place will ensure the quality of applications and avoid data security issues which are notorious on some other platforms.
  • Despite all the criticisms of a lack of hardware variations there are a lot of manufacturers signed up to produce devices. The fact they think they can make money selling devices which many think will be hard to differentiate from those of a different manufacturer should be seen as a string endorsement.
  • The email and calendar integration puts almost all other devices to shame. I've heard lots of people who have used actual devices say that they'd get one for that reason alone.
  • Xbox Live integration is a strong selling point for a lot of mobile gamers.
  • Microsoft is not afraid to try new things. And learn from them and move on if not successful. (Cough-Kin-cough)
  • Microsoft can't afford not to be successful. Mobile is the future and Microsoft needs to be there if they are to survive long term.
  • Plus I've heard from trusted sources what the ballpark marketing budget is. (My lips are sealed though.)
  • I've also noticed that a lot of the people who are panning the phone are the same people who said the iPad was pointless and no-one would ever buy one. ;)

Sunday, August 01, 2010

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/

Friday, July 30, 2010

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.


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?

Friday, July 23, 2010

Thursday, July 22, 2010

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

Saturday, June 12, 2010

Silverlight effects and Windows Phone 7

Note: As Christian pointed out in the comments, effects were not included in the released version of the SDK.

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

Wednesday, June 09, 2010

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.

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?)

Tuesday, June 01, 2010

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

Tuesday, May 25, 2010

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.

Thursday, May 20, 2010

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

Tuesday, May 04, 2010

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?

Friday, April 30, 2010

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

Wednesday, April 14, 2010

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.

Tuesday, April 13, 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.

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?