Introduction
In this article series, we're going to try and tackle a problem (or opportunity, depending on how you want to put it) a lot of business face today: customers expect to be able to use your applications on a multitude of devices, with different form factors, supporting different technologies.
And you're supposed to provide them with the best possible experience on all these devices, if you want to keep them. In today's world, consumers are used to the beautiful experiences they get from apps on their smartphones - and yes, enterprise users are consumers as well -, up to the point that they will prefer a nicely designed application which offers a good user experience to an application which has more features, but a badly thought out UI (on a side note, a very interesting post on why projects need to focus on design, and thus need a designer, can be read at Pete Browns' blog).
The situation, today
So, where are we at? More devices, more technologies, more focus on design. For most business, this means: extra costs. You'll have to hire a designer: arguably, this will diminish costs in the long run, but it definitely is an extra cost when your project is starting. However, don't try cut costs by not hiring one: in todays' world, you will definitely regret this when you see potential customers fleeing to the competition because your application isn't user-friendly and intuitive enough.
You'll typically have to adjust your UI to a specific form factor: it's obvious that a UI designed for use with a mouse and keyboard on a laptop with a high screen resolution is unfit for a smartphone or a tablet, which typically have smaller screen estate and touch-based input. Next to that, every technology has its own specifics, its own quirks even - and its own learning curve: you can 't just expect a Silverlight developer, who is used to a stateful model, MVVM and XAML, to be as productive on, for example, an ASP .NET project - in which he has to keep postbacks in his mind and have some knowledge of HTML + JavaScript + CSS.
Depending on the type of service layer you choose, it will take more code to get it working depending on the technology used by the clients which consume the services. Most client technologies are pretty good at communicating with a variety of services, but we'll see that the choice of this service layer can already have a big impact on the total development time & cost - think about a Silverlight client versus a HTML-based client: your Silverlight client should have proxy classes (or a separate layer + mapping component) that implement INotifyPropertyChanged to ensure binding functions correctly. Preferably, there should also be an implementation of INotifyDataErrorInfoChanged, to get client-side validation (and thus diminish client-server communication) - things which you typically don't need in an HTML-based app (well… sometimes they come in handy, but more on that later). There's the place of validation to think about (server side or server/client-side), authentication and authorization, ... How you expose your service layer can have quite an impact on the total cost of your project.
The different clients we’ll build
SilverlightShow is a site which focuses on Silverlight (or, if you want to expand on it: XAML), so you might argue this is the logical choice for our main client applications. But that's not the reason we'll choose this technology: skill reuse is of importance as well if you want to cut costs, and so is the ability to share code between different clients - more code than just the service layer.
Our main clients will be a Silverlight web application (typically used on every laptop which has the Silverlight plugin installed), a Silverlight Out of Browser application (typically used on the home laptop of the user), and a Windows Phone application (for use on the road) - this ensures we have a bit of skill reuse, but we'll also see we can reuse quite a bit of code: what are the options on sharing Views across XAML applications? What about ViewModels, and splitting up our code in different modules? We'll talk about code reuse, but we'll also talk about when we can reuse code, but probably shouldn't. But we won't stop there: not everyone has a Silverlight plugin - or wants to install it, so we'll dive into a HTML5 based client, as this is becoming more prevalent these days. And, why not, a Windows 8 WinRT Metro client (offering even more skill reuse across technologies)?
Lastly, as we're building an application that can be used on a multitude of clients, you can image the usage of your application going up. We'll also dive into some options on how to tackle this: we’re going to take part of our application to the cloud.
Our business case
But let's start with the beginning: the application itself. What we're going to build is a dashboard application to add, edit and follow-up product sales. The company we're building it for sells this software (as a service) to other companies. Clients of this company expect to get an immediate overview of their running offers, past offers, … and the company wants to offer this to them in a nice, modern, user-friendly user interface.
As can be expected, the sales people of their clients are typically on the road a lot, so they've asked for a mobile client. This client won't be as full-featured as the desktop client: the sales people just need to be able to quickly input a possible opportunity, right when they spot one, instead of having to wait until they're in front of their laptops.
When they are (for example: at the customers' location), they prefer to access the application through a web browser, either via a Silverlight plug-in (if it's installed) or via a HTML5-based web application. And when they're behind their own computers, they could prefer to use a desktop-based application which can interact more with their locally installed application. A typical use case would be that the application can look in their Outlook inbox, to check if they've had contact with a specific customer in the past.
The company also expects a lot of its clients will switch to Windows 8 tablets once they become available, so they're looking into developing a Windows 8 Metro application for this.
As you can see: quite a lot of applications, quite a lot of requirements - and very costly. The main purpose of this article series is looking into what can be done to keep costs (and development time) in check - this is not necessarily the same as building the best architecture for every type of situation; it's about building the best architecture for this specific situation with these specific requirements, when you only have a relatively short time to put your app(s) on the market.
Let’s get started with the technical stuff: the data model
Let's look at the data model of the application first: as most of the people reading this are probably quite technical, this should help to clarify the business case somewhat:
As you can guess from this model, it's actually suitable for more than just one type of dashboard: we've got different roles for different employees, and an employee can have another employee as his boss - this implies we'll have different views in our application, for example: an employee might only be able to view his own opportunities, but his boss might want to get an overview of all the opportunities of everyone in his department. Next to that, there's also room for a back-end application (for user administration), and different modules (you might have one where a user can register a new opportunity, but you might also have one where a user with a specific role can manage customers). The focus of this series lies on clarifying techniques, and not on building the complete application: we're going to take one part of the dashboard app, one module if you wish, the employee/opportunity module, and use that to illustrate this series.
Conclusion & coming up next
In this article, we’ve had a look at the problem lots of businesses are facing today: multiple devices, multiple clients. We’ve also dived into the business case we’ll use throughout this article series, and the different clients we’ll build – all the time focusing on code reuse and keeping costs in-check. Lastly, we’ve looked at the data model we’ll use for our applications.
In the next article, it’s time talk about how we're going to design the service layer.
About the author
Kevin Dockx lives in Belgium and works at RealDolmen, one of Belgium's biggest ICT companies, where he is a technical specialist/project leader on .NET web applications, mainly Silverlight, and a solution manager for Rich Applications (Silverlight, Windows Phone 7 Series, WPF, Surface, HTML5). His main focus lies on all things Silverlight, but he still keeps an eye on the new developments concerning other products from the Microsoft .NET (Web) Stack. As a Silverlight enthusiast, he's a regular speaker on various national and international events, like Microsoft DevDays in The Netherlands, Microsoft Techdays in Belgium & Portugal, NDC2011, ... Next to that, he also authored a best-selling Silverlight book, Packt Publishing's Silverlight 4 Data and Services Cookbook, together with Gill Cleeren. His blog, which contains various tidbits on Silverlight, .NET, and the occasional rambling, can be found at http://blog.kevindockx.com/, and you can contact him on Twitter via @KevinDockx.