Wednesday, May 28, 2008

blueprintuiThis is the final post in this series, and for a complete reference, here are the previous parts:

  • Part 1 was a general introduction
  • Part 2 talked about the changes in the lower tiers (logic + data, LINQ2SQL)
  • Part 3 discussed the changes in communication (WCF)
  • Part 4 covered important stuff in the user interface (MVC)
  • Part 5 summarized the theory and outlined the new architecture
  • Part 6 started the walkthrough of the architecture code by looking at the business domain
  • Part 7 continued the code walkthrough with a look at the service (WCF)
  • Part 8 covered the consumption of the service with .NET CF
  • Part 9 showed the implementation of the user interface (MVC)

The implemented architecture is published on CodePlex in a project called Windows Mobile Architecture Blueprint, and this means that you can access the full source code as well as discuss it, come with suggested improvements, etc.

On the upper right you see the UX of the sample client included in the architecture blueprint, and the functionality is that the combo box is filled with the categories when the application starts. Then, when a category is selected, the product names are shown in the text box below.

Even if this series is complete, we will continue to build further on this architecture blueprint, and any suggestions on things to add are most welcome. Any other feedback, for that matter, is also welcome!

posted on Wednesday, May 28, 2008 6:31:06 AM UTC  by Chris  #    Comments [0]
 Friday, May 23, 2008

WeI will continue the more practical part of this series by showing how the new mobile architecture looks in code, and if you want some background, please see the previous parts:

  • Part 1 was a general introduction
  • Part 2 talked about the changes in the lower tiers (logic + data, LINQ2SQL)
  • Part 3 discussed the changes in communication (WCF)
  • Part 4 covered important stuff in the user interface (MVC)
  • Part 5 summarized the theory and outlined the new architecture
  • Part 6 started the walkthrough of the architecture code by looking at the business domain
  • Part 7 continued the code walkthrough with a look at the service (WCF)
  • Part 8 covered the consumption of the service with .NET CF

The implemented architecture is published on CodePlex in a project called Windows Mobile Architecture Blueprint, and this means that you can access the full source code as well as discuss it, come with suggested improvements, etc. As I walk you through the creation of the architecture, we suggest you keep the source code handy to check out more details.

It's time to look at how we can implement the MVC pattern in the Windows Mobile client project that we created in the previous part of this series. As we've touched on before in this series, we have built this part of the architecture on a very simple and straightforward implementation by Alex Yakhnin, that he published as a small blog series last fall (see part 1 and part 2).

As Alex, I started with the core interfaces...

interface IView
{
   
void Show();
   
void Hide();
   
void Close();
   
string Text { get; set; }
}
interface IController
{
   
IView View { get; set; }
}

...and then the interface for the main view (form)...

interface IMainView : IView
{
   
Category SelectedCategory { get; }

   
void SetCategories(Category[] categories);
   
void SetProducts(string products);

   
event EventHandler Done;
   
event EventHandler CategorySelected;
}

...which already tells us what the main form can do. It allows us to set a number of categories (to choose from, SetCategories) and it will notify when a category is selected (CategorySelected). It will also make that selected category available through a public property (SelectedCategory) and allow us to set the products for a (the selected) category (SetProducts). Finally, it will notify when the user is done with it (Done).

The implementation of the controller for the main form looks like this...

class MainController : IController
{
   
private IMainView view;
   
private ServiceClient service;

   
public MainController(IMainView view)
    {
        View = view;

       
ServiceClient.EndpointAddress = new EndpointAddress("http://192.168.0.100:5610/Service.svc/basic");
        service =
new ServiceClient();

       
Category[] categories = service.GetCategories();
        view.SetCategories(categories);
    }

   
private void attachView(IMainView view)
    {
       
this.view = view;
        view.CategorySelected +=
new EventHandler(view_CategorySelected);
        view.Done +=
new EventHandler(view_Done);
    }

   
void view_CategorySelected(object sender, EventArgs e)
    {
        Category category = view.SelectedCategory;
       
string s = string.Empty;
       
foreach(Product product in category.Products)
            s += product.ProductName +
"\r\n";
        view.SetProducts(s);
    }

   
void view_Done(object sender, EventArgs e)
    {
        Application.Exit();
    }

    #region IController Members
   
public IView View
    {
       
get { return view; }
       
set { attachView(value as IMainView); }
    }
    #endregion
}

..and upon creation, the controller saves its view, and set up the event handlers to capture event from the view. Then it make the first call to the service to get the category list which is sent to the view. When a category is selected, a string is created (I know, in a real solution it would be a StringBuilder, but this code is simpler to read) and passed to the view.

The implementation of the main view (form) looks like this...

public partial class MainForm : Form, IMainView
{
    public MainForm()
    {
        InitializeComponent();
    }

    public Category SelectedCategory
    {
       
get { return categoryComboBox.SelectedItem as Category; }
    }

    public void SetCategories(Category[] categories)
    {
       
foreach(Category category in categories)
            categoryComboBox.Items.Add(category);
    }

   
public void SetProducts(string products)
    {
        productsTextBox.Text = products;
    }

    public event EventHandler CategorySelected;
   
private void categoryComboBox_SelectedIndexChanged(object sender, EventArgs e)
    {
       
if(CategorySelected != null)
            CategorySelected(
this, null);
    }

   
public event EventHandler Done;
   
private void doneMenuItem_Click(object sender, EventArgs e)
    {
       
if(Done != null)
            Done(
this, null);
    }
}

...and here we see that the categories are loaded in a combo box which is used to determine the currently selected category, and also to raise the event when a category is selected. The products string is simply put into a text box, and a menu option is used to offer the user to exit.

To manage (can cache) the various controllers and views, we use the following singleton class...

class ApplicationManager
{
   
public static readonly ApplicationManager Instance = new ApplicationManager();
   
private ApplicationManager() { }

   
private Dictionary<string, IController> controllersCache;

   
public MainForm GetMainForm()
    {
       
if(!controllersCache.ContainsKey("Main"))
            controllersCache.Add(
"Main", new MainController(new MainForm()));
       
return controllersCache["Main"].View as MainForm;
    }
}

...and the application is kicked off like this...

[MTAThread]
static void Main()
{
   
Application.Run(ApplicationManager.Instance.GetMainForm());
}

...which concludes the walkthrough of the basic architectore! In the next post, we will summarize this series of blog posts on the architecture blueprint implementation.

posted on Friday, May 23, 2008 10:28:58 AM UTC  by Chris  #    Comments [0]
 Friday, May 16, 2008

We will continue the more practical part of this series by showing how the new mobile architecture looks in code, and if you want some background, please see the previous parts:

  • Part 1 was a general introduction
  • Part 2 talked about the changes in the lower tiers (logic + data, LINQ2SQL)
  • Part 3 discussed the changes in communication (WCF)
  • Part 4 covered important stuff in the user interface (MVC)
  • Part 5 summarized the theory and outlined the new architecture
  • Part 6 started the walkthrough of the architecture code by looking at the business domain
  • Part 7 continued the code walkthrough with a look at the service (WCF)

The implemented architecture is published on CodePlex in a project called Windows Mobile Architecture Blueprint, and this means that you can access the full source code as well as discuss it, come with suggested improvements, etc. As I walk you through the creation of the architecture, we suggest you keep the source code handy to check out more details.

We are now ready to consume the WCF service that we created in the previous post, and therefore we have added a new "Smart Device Project" and selected to create a Device application targeting Windows Mobile 6 Standard (a.k.a Smartphone) and the latest .NET Compact Framework (3.5).

As the tools support is not yet in place in Visual Studio, to consume a WCF service, you need to first download and install the Power Toys for .NET Compact Framework 3.5. The tool that you are after is named NetCFSvcUtil.exe, and you use it like this...

NetCFSvcUtil /language:cs http://localhost:5610/Service.svc

...and in the source code you can find a batch file (CreateServiceClient.bat) that will run this command (note that you may have to change the path to the NetCFSvcUtil utility depending on whether you're running on 32- or 64-bit). Note that the WCF service must be running when you run this command, and the out of running this batch file looks something like this...

netcfsvcutl

...with the result that two files are generated (Service.cs and CFClientBase.cs). As there files are already part of the source code, they will simply be replaced and the procedure with running the batch file is the next best thing to what you would expect from integrated support in Visual Studio.

Now, with these two files in place, we can start consuming the WCF service with code like this...

ServiceClient.EndpointAddress = new EndpointAddress("http://192.168.0.100:5610/Service.svc/basic");
ServiceClient service = new ServiceClient();
Category[] categories = service.GetCategories();

...and the first thing we do is to set an endpoint of the service that the mobile device can reach (in this case an IP address). Then the service proxy (ServiceClient) is instantiated and used to retrieve the list of categories. Note that the business entity (Category) that was declared back in the business domain (automatically generated by LINQ2SQL, and automatically serialized by WCF) is readily available on the mobile client (thanks to the proxy we generated above).

In future posts, we will cover more parts of the architecture blueprint implementation.

In some projects, we have used a very simple and straightforward implementation by our former fellow MVP, Alex Yakhnin (he's now employed by Microsoft), that he published as a small blog series last fall (see part 1 and part 2).

posted on Friday, May 16, 2008 10:28:31 AM UTC  by Chris  #    Comments [0]
 Friday, May 09, 2008

WeI will continue the more practical part of this series by showing how the new mobile architecture looks in code, and if you want some background, please see the previous parts:

  • Part 1 was a general introduction
  • Part 2 talked about the changes in the lower tiers (logic + data, LINQ2SQL)
  • Part 3 discussed the changes in communication (WCF)
  • Part 4 covered important stuff in the user interface (MVC)
  • Part 5 summarized the theory and outlined the new architecture
  • Part 6 started the walkthrough of the architecture code by looking at the business domain

The implemented architecture is published on CodePlex in a project called Windows Mobile Architecture Blueprint, and this means that you can access the full source code as well as discuss it, come with suggested improvements, etc. As I walk you through the creation of the architecture, we suggest you keep the source code handy to check out more details.

The next step in building the architecture is to create the service interface (i.e. the service), and therefore we have added a new "WCF Service Application" project called Blueprint.Facade to the solution that already included the business domain project (Blueprint.Domain). Our first service will be publishing the very simple functionality that the business domain provides (the ability to retrieve all categories from the database). First, we have renamed the service interface to IService and the service implementation to Service (removed the "1" at the end on both), and here you need to make sure that all references are updated (four occurences in the web.config file and don't forget the one in Service.svc). The implementation of the service interface (IService.cs) can be done like this...

[ServiceContract]
public interface IService
{
    [
OperationContract]
   
Category[] GetCategories();
}

...and with a reference to the business domain project, the service implementation (Service.svc.cs) can be implemented with this code...

public class Service : IService
{
   
public Category[] GetCategories()
    {
       
using(NorthwindDataContext dc = new NorthwindDataContext())
           
return dc.GetCategories();
    }
}

...to complete the implementation of the service. When the project is built and run, the WCF is ready to be consumed, and therefore it's a good idea to remember the URL to the service as we will need it in the next post when we will look at how this service can be consumed from a mobile client application.

posted on Friday, May 09, 2008 10:27:52 AM UTC  by Andy  #    Comments [0]
 Friday, May 02, 2008

In this part, we will get more practical by showing how the first parts of this new mobile architecture looks in code, and if you want some background, please see the previous parts:

  • Part 1 was a general introduction
  • Part 2 talked about the changes in the lower tiers (logic + data, LINQ2SQL)
  • Part 3 discussed the changes in communication (WCF)
  • Part 4 covered important stuff in the user interface (MVC)
  • Part 5 summarized the theory and outlined the new architecture

The implemented architecture is published on CodePlex in a project called Windows Mobile Architecture Blueprint, and this means that you can access the full source code as well as discuss it, come with suggested improvements, etc. As I walk you through the creation of the architecture, we suggest you keep the source code handy to check out more details.

nwdatacontext Ok, let's start building the architecture from the ground up!  To make things really simple (remember the KISS principle), we have started with a plain class library called Blueprint.Domain where we will keep my business domains. My first domain will be covering a small part of the classic Northwind database. I started by creating a LINQ2SQL data context called Northwind and dragged two of the Northwind tables into it (if you're like me, and don't have the Northwind database installed, you can get it here) as you can see on the right (note that we have removed the Picture field in the Category table to save bandwidth).

When that is done, a neat trick that will come in very handy is to select Properties on the design canvas of the data context and set Serialization Mode to Unidirectional. By doing this simple task, the code generated for the data context will include the necessary decorations (attributes) to make the data context ready to be published by WCF. If we look at a stripped version of the generated code (in Northwind.designer.cs)...

public partial class NorthwindDataContext : System.Data.Linq.DataContext
{
    [DataContract()]
    public partial class Category
    {
        [DataMember(Order=1)]
       
public int CategoryID
        {

...you will see that each class (entity) has a DataContract attribute, and each field (attribute) has a DataMember attribute. These attributes will be use by WCF when the entities are communicated.

In the code above, please also note that the generated class for the data context (NorthwindDataContext) is declared "partial" which perfectly matches our intention of implementing the business logic in a parallel class. By creating such a class (Northwind.cs), and putting in some simple code like this...

public partial class NorthwindDataContext
{
   
public Category[] GetCategories()
    {
        return Categories.ToArray();
    }
}

...we have implemented the first (however sparse) service into our first business domain, and the functionality is that it returns the list of all categories. Note that behind the scenes, LINQ comes into play, and to show a more obvious example, we can do this instead...

var q = from c in Categories select c;
return q.ToArray();

 

...and this will create the same result as the code above. Worth mentioning already is the fact that even if the Category entity holds a relation to all products in that category, those child entities are not loaded by default. This is a good thing as you probably don't want to load all products with all categories, but when you want to load related entities, you can do this by explicitly call...

var q = from c in Categories select c;
Category[] categories = q.ToArray();
categories[0].Products.Load();

...to load all the products for the first category. There are some other options for controlling how related entities are loaded, but it's out-of-scope for this blog post. In future posts in this series, we will cover more parts of the architecture blueprint implementation.

posted on Friday, May 02, 2008 10:23:32 AM UTC  by Andy  #    Comments [0]
 Friday, April 25, 2008

In the previous parts of this series, we have discussed the changes that affect the architecture design. It's now time to conclude what this all leads up to architecture-wise, and we propose that the architecture should look something like this:

newarch Most of the fundamental parts (three tiers, common services, etc), and even many of the more specific (service interfaces/agents, data access, business entities, etc) are exactly the same as in the Application Architecture for .NET that I've mentioned before in this series of blog posts.

Note that a significant change is the merge of the lower part of the middle (business services) tier and the bottom (data services) tier. As we've outlined before, this is where the business logic and its data comes together in a nice mix called the business domains. With technologies like LINQ to SQL and WCF, most (if not all) of the data services tier are actually created using code generation. This means that any changes made to the different sources (data sources and services) can be captured by regenerating the code. The tools support is actually prepared for this kind of evolution in the integration between systems, and a simple "Update Service Reference" menu selection is all that is needed.

Another similar change is the clear separation between the service interfaces and the business domains. Where the business domains have a clear responsibility to handle the logic and data for a certain business domain, the service interfaces (designed according to the facade pattern) has a different set of responsibilities. The primary distinction of a service interface is that it probably fulfills a specific part of the system's functionality (use case). Also, as they are the "first line of defense", they should handle things like basic security (authentication, authorization, encryption, etc) as well as secure coding techniques (parameter checking, prevent things like SQL/code injection, etc), compression, transactions, logging, etc. A consequence of the separation with the business domains is that the service can be placed in a separate assembly. This is a good thing because a service interface probably uses a number of business domains that may (or may not) exist in numerous assemblies.

Finally, the user interface parts have been renamed to align with the use of the MVC pattern, and as already mentioned in previous posts, this will allow for better testing and the use of the same user interface logic for different clients (thin Web interfaces built with ASP.NET, rich interfaces built with WinForms, WPF or Silverlight, and of course mobile clients built with .NET CF and soon Silverlight, etc).

In upcoming posts, we will continue with more of my thoughts on the changes in mobile architecture, and of course also some code samples to show the theory in practice. Stay tuned!

posted on Friday, April 25, 2008 10:22:54 AM UTC  by Andy  #    Comments [0]
 Friday, April 18, 2008

This time we will look a little closer at an important change on the user interface side of the architecture. We're talking about applying the MVC pattern (or rather its variation, the MVP pattern), and even if this change is far from recent (both mentioned patterns have been around for quite awhile), the importance of applying this pattern has increased. The reason is an increased focus on automatic testing, TDD, and continous integration. By applying the MVC pattern, the bulk of the logic of the user interface (located in a "controller"), can be tested independent of the actual user interface. This, and the more traditional benefits, that you can apply different "views" (user interfaces or more general, channels) to the same user interface logic, makes the MVC pattern a common part of any modern software architecture.

If you do some browsing on the Web, you quickly find that there are many implementation of the MVC pattern, but there are not that many specific to Windows Mobile developers (although most .NET implementations should migrate without much hazzle). One great initiative was the MCSF by Microsoft's patterns & practices team, which included a solid implementation of the MVC pattern (among many other) that was migrated from various application blocks for the full .NET Framework. However, the MCSF was so solid that it took a great deal of time to learn before you could be productive. Also, the MCSF is now a bit outdated, and judging from the lack of news or updates about it, our hopes are not up.

The community (and us too) wanted something simpler, and in some projects, we have used a very simple and straightforward implementation by our former fellow MVP, Alex Yakhnin (he's now employed by Microsoft), that he published as a small blog series last fall (see part 1 and part 2). In those blog posts Alex also showed a simple solution to a very common problem when building great UX for Windows Mobile, and that is to handle the caching of forms. Loading a form is an expensive task in terms of performance, and therefore it's necessary to cache the forms in memory.

In upcoming posts, we will continue with more of my thoughts on the changes in mobile architecture, and of course also some code samples to show the theory in practice.

posted on Friday, April 18, 2008 10:21:55 AM UTC  by Andy  #    Comments [0]
 Friday, April 11, 2008

I'm continuing the series that started with part 1 and part 2 by talking more about the changes in a modern mobile multi-tier architecture. We can see that the most important changes are happening on two levels, and the first is the tighter bond between the business logic and it's data that I talked about in my previous part in this series.

classicntier As I already mentioned in the previous post in this series, the second major change to the classic Application Architecture for .NET that you see on the left is the change in the way that clients exchange information with the server (or more general, the way that two systems or peers exchange information). As soon as Web Services arrived, we instantly understood that this would be the future way of communication between systems. At the time when we wrote our book, the basic plumbing wasn't in place, and most had to be done by hand. Since then the basic Web Service technologies (XML, SOAP, HTTP, etc) has been complemented with both new exiting ones to enable better support for security, sessions, transactions, etc, as well as much better tools support. The beauty of Web Services is that they can open up a "locked" architecture (that can only deliver a fixed UX, like most Web sites on the Internet) to any client. That client could be anything from a custom made application to another system that simply want to use only the services and the data. This is what my series on Windows Mobile Web Services (e.g. Movie Lookup Web Service) is all about. Most of you probably agree that cool sites like IMDB, and FlightExplorer become even better when they can participate in a mash-up application to deliver greater value.

One technology that is important in this change is WCF as it builds on the good things about Web Services, and also takes the concept one more step. It's what .NET Remoting should have been in the first place, and even if it can be confusing as a consequence if its versatility, the main message is that you can do everything that you can do with Web Services and so much more (and it also performs very well). Therefore, my recommendation is to take a hard look at this technology and evaluate if it brings something that you need in your mobile applications. Just to make you more interested, it can travel over a number of transports (HTTP, TCP, Named Pipes, MSMQ, etc). However, not all of these transports are supported out-of-the-box on .NET Compact Framework yet, but a great thing about WCF is that it can be extended on multiple levels (transport, bindings, etc). What is supported though, is the ability to solve a classic problem with mobile applications: How can I communicate efficiently with a device that may be shut down and that is very hard to address (changing IP addresses, etc)? It's possible using the WindowsMobileMailTransport class that allow messages to be sent as e-mail. In combination with Exchange Server, and it's push e-mail technology (a.k.a. DirectPush or Always-Up-To-Date), this means that mobile application can be built that communicate very efficiently with the server (or another peer).

In upcoming posts, I will continue with more of my thoughts on the changes in mobile architecture, and of course also some code samples to show the theory in practice.

posted on Friday, April 11, 2008 10:18:41 AM UTC  by Chris  #    Comments [0]
 Friday, April 04, 2008

To continue this series that started with A New Mobile N-tier Architecture (part 1), we will talk more about the changes in a modern mobile multi-tier architecture.  We can see that the most important changes are happening on two levels, and the first is the tighter bond between the business logic and it's data.

classicntierBefore, we had a distinct separation in the two lower tiers between the logic and the data. The thinking was that the data services could be used by several parts of the business logic to handle basic CRUD operations. This is shown in the Application Architecture for .NET from 2002 that you see on the left where the business logic and the data access was divided into the lower two of the classic three tiers. However, the problem was that data without logic is almost useless, and even if the logic existed (in various business components) the natural relation with the data was not manifested.

The other change is the change in the way that clients exchange information with the server (or more general, the way that two systems or peers exchange information), and that will be the focus of the next part in this series.

newntier

If we look at technologies like LINQ and specifically LINQ2SQL (LINQ to SQL) the traditional separation between the logic and the data is encouraged. On the right you find an illustration what is happening in the lower two of the traditional three tiers. The observant note that the business entities is moving down to he data tier (where they belong), but more importantly, the two tiers are actually moving together. With a LINQ2SQL, the business logic can be implemented in the same data context (the ORM) class (by using the ability to define partial classes). We would like to call these merged entities domain components as they define and handle both the data and the logic for a specific business domain. So, the service interface (facade) would actually work with a number of domain components to deliver functionality to its clients. The challenge is how the functionality (logic + data) is spread among the domains to make them a perfect tradeoff between versatility and reusability. The bigger, the more versatile, the smaller, the more reusable. The general message is probably to keep them small and distinct.

In upcoming posts, we will continue with more of my thoughts on the changes in mobile architecture, and of course also some code samples to show the theory in practice.

posted on Friday, April 04, 2008 10:15:32 AM UTC  by Andy  #    Comments [0]
 Friday, March 28, 2008

When we wrote our book Pocket PC Development in the Enterprise back in 2001, one of our goals was to help developers with an architectural blueprint for building solid mobile multi-tier applications. At that time, most focus for mobile developers was on the user interface and the device side of the mobile solution.

Since then, a lot of things have changed. The Windows Mobile development platform with .NET Compact Framework as the foundation, has evolved into a very powerful offering to mobile developers. Technologies has constantly migrated from the desktop (full) framework, even if it sometimes seems too slow when one is eagerly waiting. Who else is eager to use LINQ to SQL with SQL Server Compact, full WCF support, or build mobile Silverlight applications?

But, some things remain the same, and one of these is the view on mobile solutions as being a part of a bigger whole. Almost no mobile applications live alone! In most cases, they are part of an integrated solution that extend existing business processes to reach further out in the hands of the employees. Therefore, a modern mobile architecture starts with a solid architecture on the server, and can be extended to support multiple channels (thin/rich clients, fixed/mobile devices, etc).

During the years since we wrote the book, the blueprint has evolved with the changes in technology. We say evolve, because most changes only meant that the architecture was upgraded to embrace the new technologies. Recently, however, some major changes has occurred that force some more drastic changes to the architecture. The most significant are LINQ (specifically LINQ to SQL and the upcoming ADO.NET Entity Framework), WCF, and Silverlight. The observant reader notes that these technologies span the whole architecture spectrum from data access, via communcation links to UX. In addition to these, there are also a number of enhancements for the mobile developer that spice up an architecture that in addition to support traditional clients, it also needs to support mobile clients as well.

As you will see, when we move forward in this series of blog posts, we're a big fan of the KISS principle. Therefore, the primary goal is to keep things as simple as possible to minimize the learning curve while at the same time still create a valid architecture that is easy to implement, test, and maintain.

In upcoming posts, we will continue with more of our thoughts on the changes in architecture in general and more specifically on architectures that suite mobile solutions.

posted on Friday, March 28, 2008 10:12:19 AM UTC  by Andy  #    Comments [0]
 Friday, December 07, 2007

For weeks I've been avoiding it, but today (during lunch) I had to do the pre-insurance inspection of my car. The reason for pushing it back should be obvious for anyone that have gone through the procedure. Even if I'm used to catching up on my blog readings while waiting, it's a testing experience. My hopes didn't exactly go up when I arrived and was ordered back to the far end of the long line.

photoinspectionBut, this time I was greatly surprised! Even if I had time for a few blogs, the wait was not close to what I had expected (about 30 minutes with five cars before mine). The inspector hardly looked at me (yes, he was an efficient guy), took the papers of my car, and got instantly busy. I was amazed how fast he worked, and when I saw that he was constantly tapping in everything that he saw and heard (from both the car and me), I asked what he was using. He showed me the device (a Qtek 9100 a k a HTC Wizard), and when I said "Ok, you got Windows in that" he instantly replied "Yes, it works great!". You can see the only photo I got (as I said, he was a busy man) on the right, and I'm sorry for the bad quality. But I can tell you that the application was very well designed and I was surprised that the UX had so much information (really small fonts were used to fit in as much info as possible). All the necessary photos of the car was captured with the built-in camera and there was no hassle what so ever for the inspector (he took the picture, tapped a few times, and took the next, and so on). He said that an inspection that took more than double the time before, created even more work afterwards (data entry, photo transfer, etc).

Apart from the great UX, I was really impressed by another thing - EVERYTHING ended up digitalized. The parts of the process that was governed by law (or the insurance company) to be on paper was rapidly filled in (hardly readable) and then he took a photo of the paper, and threw it in a large green bin with a yellow label saying "to archive" (it actually looked like a large recycle bin, which it probably what it should have been if the correct laws and directions were in place). After I had signed the final paper, he took a photo of it, threw it in the bin, shook my hand, and turned to the next in line. I was AMAZED! The inspector expected that from the point where the insurance company assigned them an inspection to the point where the completed inspection was approved by the insurance company was reduced by 80%. Still, he said that the largest benefit for him was that many irritating and stressing events (the person responsible for data entry coming back with questions, the need to start another inspection before one was completed due to wait for some manual step, etc) was gone.

To my point, and the title of this post. I have been involved in WM development for eight years, and I have seen many systems come alive. All have led to increased productivity and efficiency, and all have led to large cost cuts or even revenue and profit increase. But I haven't seen many examples of where the legacy process was completely replaced by a digitalized and mobile process. Often many manual steps remain for various reasons (mostly legal or related to company policy), and often it is those steps that reduce the possible gains drastically. The post title is a reference to a British movie about going all the way, and my lesson again today, and hopefully yours too: We need to go all the way in making processes (mostly papers) digital (yes, everything that Bill Gates wrote is true), and that is many times more important when designing mobile solutions. The inspector I met today was doing his work in the "current moment" or "now" by performing what I call "JitBiz" ("Just-in-time Business", referencing both managed compilers as well as the old idea by Henry Ford not to keep any stock), and by doing that he was also relived of "worry" (for things that was waiting for him) and "regret" (for things that needed follow-up). This is the way all companies should work for the sacred trinity; the customer, the business, and the (holy) employee.

posted on Friday, December 07, 2007 8:31:16 PM UTC  by Chris  #    Comments [0]