Published on 13 May 2014 - Updated on 16 May 2019
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.
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.
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.
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.
As you collect the answers to these questions, let’s talk a little about what each one means.
The things to look for here are:
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.
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.
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.
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:
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.
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.
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.
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.