Deciding how to deliver applications is becoming a challenge, especially now that Web apps, touch interfaces and...
slimmed-down workspaces are becoming more common.
Applications in the future aren't necessarily Windows apps. Windows is going to be something of a middleware solution. It isn't going anywhere; it's just that the different ways we use applications are growing. When it comes time to upgrade or redevelop an app, or access an application from new devices, things can get especially challenging.
If you're struggling to determine what app delivery method works best for your environment, try thinking about applications in four categories: native vs. HTML; touch vs. keyboard; full-featured vs. focused; and create vs. consume. Using this application delivery management worksheet, you can go through each category and determine what types of applications suit your needs and users' expectations.
Native vs. HTML
The native versus Web-based app debate isn't an entirely new discussion. We've been fighting over the decision to create native apps or deploy them via the browser since Internet Explorer 6 (and probably before). At that time, it was browser plug-ins, ActiveX controls and Flash, and each browser upgrade or software exploit had us scrambling to adapt.
Today, this conversation focuses on HTML 5 and whether we can create an application that lives on the Web and delivers the same experience as a native app. Gmail is a great example of a Web app that works well; its HTML 5 version could even be mistaken for a native application. You get that high fidelity experience in any modern browser and on mobile devices, which is more than we can say for Outlook Web Access.
More on application delivery
Four mobile application delivery methods
All about application virtualization and streaming
Options for enterprise application delivery
HTML 5 applications exist in the browser, so they are limited to features that the browser allows. Sometimes that means you can't access aspects of the hardware such as GPU, camera, GPS or sound. It also means you usually don't have offline capabilities. Offline support has to be reliable, and with offline Google Drive apps, for instance, my experience has been hit or miss.
There's also an issue with cross-browser and cross-platform compatibility, which can sometimes be coded around, but that just adds to the challenge.
Native apps, on the other hand, get you access to lower-level OS and hardware functionality -- plus reliable offline access. So, do you need platform-agnostic? Were you going to have to redevelop an app anyway? If so, maybe HTML 5 is the way to go. If you need reliable offline support and lower-level access to hardware and OS components, then you should probably look at native applications.
Touch vs. keyboard and mouse
Is your application touch-capable, or is it best used with a keyboard and a mouse?
When you're considering how to deliver Windows applications, we're largely talking about keyboard and mouse. But mobility -- and desktops with Windows 8 -- requires touch. That's when people start talking about the post-PC era and that we don't need to take our laptops on trips anymore because we have tablets and phones. The way your users interact with the application is important in deciding how to proceed with each one.
Full-featured vs. focused
What is the use case for this application? Does the user need a complex, full-featured interface to everything, all the time? If so, you're probably looking at a native Windows application with all the bells and whistles, including the keyboard and mouse requirement. On the other hand, if a user only needs a focused interface, you can deliver an application that works on many platforms and input methods.
The challenge when creating a focused application is deciding which features to remove. Sure, a focused application looks more elegant, but is it really? Do your users appreciate the focused nature of the app at the expense of features? Does it fit their needs, or does it mean they have to jump through more hoops to get their job done?
Create vs. consume
Determining whether your application is meant for creating or consuming information can be tricky because some apps are designed to do both. Generally speaking, if the application is for consumption, you have more options for finding or creating an interface that works across your organization.
Creating content is an intensive process that can require other applications and lots of integration. Take writing an article as an example (I just broke the fourth wall, I know). I need to have browser windows open to find links and references, image editors up to make pictures and an app to write in. That’s hard to do on a device or platform made for consumption.
So in the case of "should I create a mobile app or HTML 5 or Windows?" the answer is often dependent on whether or not the user is creating content.
What will you decide?
All this should get you thinking about the ways users can use applications and how they fit in with the different platforms and deployment methods you have. Remember, users should be involved to tell you how the app will be used.
Also consider: Is the application used in-house or on the road? Is it used constantly or occasionally? What, exactly, are they doing with the app, anyway? You can then use that information to decide whether to deploy it as a Windows app (which could be local or from the data center), HTML 5 app or mobile app, as well as what level of functionality is required.
Just a warning, though: If for you go through this process and decide that deploying a full-featured Windows app to an iPhone via VDI is the surefire way to go, think twice!