Taking a Web App Mobile in Two Months

by Jason Ware, Engineering Manager at ExaVault

We’ve been watching our mobile traffic increase over the course of the last year, and we recently decided it was time to make our Simple Web File Transfer (SWFT) application more usable on small-format mobile devices.

The Starting Point for a Mobile Web App

Now you may not think of ExaVault as the type of company whose applications and services make sense on a mobile device — and to some extent, you’d be right. After all, who really is going to upload and download files or use FTP services with the extreme limitations of file sizes, formats, and application data sandboxing within various mobile devices?

The truth is, it’s not just about FTP and transferring files. There are a lot of workflow steps that people need to do on-the-go. For example, previewing files, sharing files, or checking on the status of files that they’ve sent to a client.

Deciding to go Mobile

Once we decided to build a mobile version of SWFT, we wanted to move quickly: in mid-January 2014, we set a goal of two months. We wanted to have the mobile app out by the end of March.

We’re certainly not the first to build a mobile version of an existing web app, and we definitely won’t be the last. We leaned heavily on information that others had written, and we wanted to share in-kind. This blog post tells the story of our web app build — and, we hope — will provide some key insights to anyone trying to do something similar in the future.

Gathering the Essential Information

Given our tight timing, one of the first things we needed to do was determine the actual set of features that our customers most likely wanted to use on a mobile device.  Mobile is moving too quickly for there to be a perfect platform, approach, or process. When it comes down to it you really just need something solid to base your initial build direction on.

Here are some key questions that you should ask if you’re trying to build a mobile version of an existing web app:

1. What do my app’s current mobile usage statistics look like?
2. Are the features that my mobile users try to access presented in a way that I would expect them to function on a small mobile device?
3. Does my current app already work well on tablet devices?
4. Does my current app use an API that I can easily leverage?
5. Do I plan in wrapping my application in a native wrapper (Cordova/PhoneGap)?

Making an Informed Decision

As you collect the answers to these questions, let’s talk a little about what each one means.

1. What do my app’s current mobile usage statistics look like?

The things to look for here are:

• How much of your overall traffic is mobile? If the percentage is low enough, it could be that no one really tries to access your application on mobile devices.  Also, it could be that something about the nature of your application creates an obvious barrier for mobile. Is this something that should be changed?
• How much of your mobile traffic is tablet and how much of it is small phone screens? For us this was pretty evenly split between tablets and phones, which brings us to the next, very related, mobile usage question…
• What features are your users on mobile phones trying to access? Chances are, they don’t need to do everything on mobile, so you should prioritize what’s important.

2. Are the features that your mobile users try to access presented in a way that you would expect them to function on a mobile phone?

The odds are that in many cases you’ll find the default experience is lacking when viewed on a small screen. Why? Because users have come to expect a simpler experience with specific layout patterns when they use an application on a small device. They expect more of a “native” look and feel, and to have to look at less functionality at any given time, while still being able to access all of the features they expect.

All of this can sound like a lot of work to provide, but that’s only the beginning. We haven’t even mentioned the fact that they’ll also expect to be able to do these things based on positioning and iconic cues, so they don’t have to learn how to use the interface.

3. Does my current app already work well on tablet devices?

As it turns out, ExaVault’s existing SWFT desktop application worked well on a tablet. That was largely by design — we’d already taken smaller screen sizes into account and had a somewhat flexible layout. We had also already solved some of the specific issues with downloading and uploading files that occur only on mobile operating systems.

If your web app is not as lucky to be usable on a tablet already (and you have a significant tablet user-base), you may also want to think about building in some basic responsiveness that doesn’t greatly impact your desktop design. In fact if your app is simple enough to begin with, you may find that you can quickly make it responsive all the way down to the smallest size. However, for many applications making it usable on a tablet is a fairly low effort endeavor as compared to making a complex application usable down at the next level of 320 x 480 (and similar) screens, but if you think a similar feature-set and UI approach makes sense in the smallest format and it is already uncrowded enough to where you can just reformat the way features are accessed, then responsive is likely the quick way to go.

4. Does my current app use an API that I can easily leverage?

I’m sure I don’t have to say that building web applications backed by a REST or REST-like API gives you a lot of flexibility. Of course this is a different discussion altogether, but you will see that it ties into our final question shortly.

Does your application interact with a separate service to do what it needs to do? If not, that doesn’t mean that a simpler, stand-alone, application tailored to mobile usage is out of the question. But you might find it easier to update your front-end code to make your desktop app responsive. On the other hand, having the ability to write a fully client-side mobile web app opens up a lot of possibilities. Also if your current app uses an API, you know you probably won’t have to modify your current back-end in order to create new, more mobile-oriented ways of presenting your application’s features.

At ExaVault we already had an API, but it was being called by way of other server-side code. A lot of thought went into it from the beginning knowing that it would eventually be opened up, but it had naturally been tailored to some of the specifics of our existing applications.

At around the same time we started on the mobile app, we were also looking at opening up our API so our customers could start using it. It turned out that by building our mobile web app, we were able to find and fix all of the things that might make working with our API difficult. Now we have a mobile web app able to function completely client-side using JavaScript, and a solid API that is open for the world to use.

5. Do I plan in wrapping my application in a native wrapper (Cordova/PhoneGap)?

This one is pretty simple. If you do plan on doing this, you will likely need to build a stand-alone application. Even if your current application runs purely as client-side code, which is necessary to deploy this way, performance is still a big issue to consider in “native” wrapped JavaScript applications.

You want your wrapped code to be as lean as possible and only centered around the stripped-down set of features that you want to deliver in the small-format mobile experience. Extra markup and JavaScript that doesn’t apply to the case used in the small format app will only slow down the app for your users, and will likely make the debugging process much more difficult than it has to be.

Now that we know

We now have the information needed to get us on the most streamlined path to a mobile experience that we can quickly launch and iterate on, so we’re all set right? Maybe, but there is often a little more to it:

The Features

One of the most crucial bits of information you gathered was what features your users are trying to access from small mobile devices in your current application. When it comes down to it many applications only warrant having a small portion of their feature-set appear on a small mobile device. The set of features that your users actually use is generally all you want to present, as extra features in a mobile application are purely clutter and generally make for a less desirable user experience.

It can take a little getting used to this idea, but the fact of the matter is that people tend to interact with mobile devices differently. They access applications with different goals in mind, expecting to do a simple task within a couple clicks. Often getting your small-format mobile experience down to just the necessary features makes your users happier, and gives the additional advantages of less development time and a more maintainable codebase.

The Platform

This is always a tough decision and the answer will greatly differ based on whether or not you are extending or using your current codebase, plan on writing a stand-alone client-side application, or any combination thereof. There is probably no wrong answer here, but if you are going with a platform that is new to you, remember to look at things like the current rate of adoption, documentation and user-generated examples, performance in the context of mobile devices, and device/browser compatibility.

In our case, we found that the best choice for us to ensure certain flexibility, fully utilize our API – decoupled from any other server-side dependencies, and provide a nicely simplified user experience, was to write a client-side JavaScript app. We had a bit of recent experience with AngularJS and have found that it not only speeds up writing JS applications by reducing the amount of code necessary and providing two-way data binding, but also tends to be very performant on under-powered devices as compared to many options out there, thanks to dependency-injection, a light codebase, and conventions that tend to help keep you from developing “spaghetti code”.

Plus, there are a ton of modules designed to help you solve common problems that currently have very active development and support. Once we added the Bootstrap 3 CSS library and the (Angular) UI Bootstrap JavaScript library to drive the UI, we were able to develop a straightforward and very intuitive application at a lightning pace.

Choosing a platform that helps you work quickly while also helping you avoid common stumbling blocks can certainly make all of the difference in the world.

What We’ve Learned

Every time we embark on a project like this there are many valuable lessons learned. Every situation is different, and as the accepted mobile standards and approaches have changed and grown quickly over the last few years sometimes it seems like there is no “right” decision to be made.

All approaches have their own costs in one way or another, but hopefully, you are able to use some of our experience in this area to help you make more informed decisions and get your mobile web app out the door in record time like we did.

We hope this has been helpful. If you’re a current ExaVault customer, we’d love to have you try our mobile application and give us your thoughts. Login to SWFT ( https://swft.exavault.com/ ) on your mobile phone.

Update: In 2019 SWFT officially retired and we have a new interface with a more streamlined look and responsive design. To log in, use your ExaVault domain or go to https://app.exavault.com/login.