Discovered the Guitar Hero: Air Guitar Rocker in John Lewis yesterday.Got to be up there with some of the best, daft Christmas presents. Perfect for who I bought it for.
Monday, 22 December 2008
I was Christmas shopping with the boys yesterday and was struck with a realisation about the VAT reduction. At checkout after checkout, the price was always a little bit lower than I was expecting.
Most retailers haven't changed the price tickets, so it's not till you get to the till that you see the saving. On a £30 clock it was 75p, not a huge amount but still cheaper.
The feel-good factor was far in excess of 75p.
The continuous little reductions were adding a little shiny glow to each purchase. Put shoppers in a good mood and they'll spend more. Simple but effective.
Like many people, I had some doubts over the impact of the VAT reduction and questions remain over the affordability. However, I didn't consider this benefit of retailers not being able to change the price tickets quickly.
Some good Christmas retailing figures certainly won't harm sentiment and as we've learned recently, sentiment seems to be the foundation of the Western economies.
Picture credit: Simon Aughton
Friday, 12 December 2008
Rummble has real potential to be a mobile location service I would use. The promise of being able to:
- find out what's good where I am right know
- add my own views and contribute to the knowledge map
is a tantalising proposition. With Rummble, unfortunately, it still remains just that.
To really succeed, a service like this has to operate from my mobile. If I've got something to say about somewhere, I'm far more likely to be there rather than in front of my PC. I'll be still queueing because I'm in the middle of a bad service experience or (just finished) enjoying whatever I want to share with the world so they can experience it too.
Enter the Rummble iPhone App, perfect device for this. GPS built in, advanced user interface capabilities, fantastic connectivity. Problem is the Rummble app has taken advantage of the first two and assumed the last one.
If you build a mobile app, you can't assume it will be connected to the internet
I've tried a number of times to Rummble on the move now and it's just painful. For a start the start screen takes an age to load, even on my work WiFi connection it's ponderous. Immediately barriers are preventing me from expanding the network of knowledge.
Trying to add a Rummble when you haven't got 5 bars worth of 3G coverage is a joke and has resulted in a number of app crashes. What's really cute is how the app doesn't remember anything you've typed in so you have to go through the whole painful process again. Probably fair to point out that this hasn't crashed on me since the latest update.
I'm in danger of this turning into a rant and that wouldn't be fair at this stage. I've developed enough apps in my time to understand the issues and I'm also a big believer in the concept. There is still time for Rummble to rethink their mobile app architecture.
I believe mobile apps should be built from the ground-up to be able to operate without network coverage. Especially if they're capturing data. Work from that base and make the app synchronise when the connectivity is available.
The key thing Rummble needs is data, it needs to get enough reviews in enough places that I visit to be useful to me. It must allow users to enter these into the app without connectivity. Even if that means creating stubs that I then need to complete when I'm next online, either with the app or on the website.
The really valuable information is in my head right now, allow me to write a comment quickly, get it off my chest. If I can complete the review there and then marvellous, but don't deny me just because my mobile network isn't giving me the coverage the app needs.
I wish Rummble every success, it would be great for a UK company to succeed in this space.
Our new web application, codename Doyle, is being built on the ASP.NET MVC framework. The primary driver for this was enabing Test Driven Development for web apps. Increasingly frustrated with the brittleness of the traditional approach this represents a fantastic architecture for building robust web apps.
The big challenge however has been conceptual. Patterns the team are comfortable with, have turned out to be unsuited to this approach. Discussing one such question at the whiteboard yesterday, it occurred to me that the issue we were having was we thinking in terms of method based architectures rather than resource based.
To date, our approach has been to have thin Data Objects that are passed to facades and sub systems that perform operations on them. We're a messaging shop so I guess that's where it came from. A message gets passed around, operations are performed on it, decisions are made about it.
The term Controller implied a co-ordination role with knowledge of controlling one or more sub-systems. However MVC tells us that is bad, Controllers should be thin and Models should be fat.
A good example is our new send message page.
The first pass involved the controller iterating through the recipients, constructing message objects and passing them to the Esendex ReST API SMS Message Dispatcher via our C# SDK.
Very quickly the controller got fat, validation, error condition handling, suddenly it was squatting behind the view like a Sumo Wrestler tucking into his 7th chicken of the day.
The light-bulb moment was the realisation that rather than thinking about sending a message, we were actually sending a batch of messages. Enter the MessageBatch resource.
All the controller has to do is load up the MessageBatch resource with the parameters (recipients, body, etc) and call Send. This returns either true or false, successful or failed.
The controller then just has to make one decision go to one page if successful, or another if not. Safe in the knowledge that the MessageBatch object will be duly populated with an error/validation info required for the view to render and give the user the option of what to do next.
Yes this has just moved the logic to another part of the system but being in the Model layer gives the opportunity to refactor, inherit, and most importantly, mask the complexities of sending a message batch from the front end. We're comfortable unit testing and doing it this way forces as much logic as possible into units.
So, if you're making the transition to MVC then consider looking at some of the thinking behind ReST web services (I read: RESTful Web Services as a good primer). I've come to the conclusion that ReST and MVC are intrinsically linked.Photo credit: alarch
Thursday, 11 December 2008
Server monitoring is key to the availability of many business systems so knowing as soon as a server or services is having an issue is critical.
It's also not just the engineers that necessarily need to know. Other stakeholders like support personnel, account managers (who are going to be taking customer calls) and even key customers can all benefit from being kept in the loop about issues.
Most system monitoring solutions can send an email in response to a monitoring event. Just wire that up to an Email SMS service and you can notify anyone, pretty much wherever they are.
However there are times when SMS is not enough. They can be missed. If there are key people that you need to notify and need to know that they've got the message a Voice SMS is a great option.
Using IVR menus you can have the recipient acknowledge receipt of the message. It can keep ringing them until they do or your escalation rules kick in contact someone else.
Thursday, 4 December 2008
A local taxi firm, DG Cars, schedules a call back when your taxi is on its way. This is a great way of improving customer service as well operational efficiency for the cab firm.
- The customer knows when to come outside/get their coat on/say their goodbyes
- The taxi not sitting idle waiting for someone who's not ready when it could be moving onto the next fare sooner.
- Include the drivers mobile number in the message and the customer can all the driver if they're held up.
Dead simple and dead effective.
Wednesday, 3 December 2008
Thought I'd collate my current list of mobile services I'm loving or would find life difficult without.
This has been a bookmark in every phone had I've since 2001. This mobile version of the National Rail enquires web site is a must have for any train user in the UK.
Is on my iPhone dock bar in place of the phone application. Still the original and still the best.
The best twitter client for the iPhone. Simple and fast, two must haves for any mobile application.
GoogleTalk for BlackBerry
BlackBerry have got push nailed, their platform allows third party apps to raise message alerts and push them into the system inbox. The GoogleTalk IM client embraces this and allows me to maintain conversations wherever I am.
Rummble iPhone App
This is a new one and it's early days but it seems more useful than BrightKite. It allows you to log your location, send status updates and post photos but also to "Rummble" about where you are. If it gets critical mass, this could be a winner.
We have some fantastic case studies, from companies like Ocada (using SMS to communicate with both customers and workers) and Taptu (reliable SMS using our API). The problem is this is a tiny sample of the 5000+ Esendex customers, let alone companies that don't use Esendex.I know it's hard to imagine but some companies actually use other service providers.
I'm going to start posting a series of thoughts, ideas and real life examples (without names) about how business messaging can and is being used to delivery real commercial benefit to companies that embrace business messaging into their processes and workflows.
Follow them here: Business Messaging