

Ask YC: Best solution for offline access to a webapp? - inklesspen

Our company is developing a rewrite of our flagship app, which has historically been a Windows product, as a web app written in Ruby on Rails. So far it's gone moderately well; our complaints lie mostly with ActiveRecord (so bloody limited) and the lack of documentation of how to write good tests for complex models.<p>However, it turns out that our webapp also needs to be usable when the customer has no internet access. (Perhaps this should have been taken into account when the CEO decided to do the webapp idea, but we're pretty well invested into this approach now.) About 25% of our potential customer base would require this; another 25% would like to use it but do not require it. We sell access to our app as  software-as-a-service to health-care agencies, so if they need to have offline functionality, they need to have it; it's not just a preference.<p>These are the alternatives I and a few others have come up with, but I'm hoping some YCers might have some advice.<p>* Google Gears: Seems to require substantial rewrites to our app.<p>* iPhone version of our webapp: our customers don't have much money to buy iPhones and service plans. also, some of our customers need to do work with the app in places where there is no cell phone service, let alone wi-fi.<p>* Joyent Slingshot: The basic architecture (local install of Rails, with some extra code to transfer data between the local install and the webapp) seems sound, but Joyent seems to have abandoned Slingshot halfway through rewriting it. If we go with this approach, we'd probably implement our own version rather than struggle with Joyent's unsupported code.<p>* Slingshot-esque with eee: Provide a custom install for the ASUS eeePC that launches the user directly into our app, with Slingshot-like methods for transferring data between the eee and the webapp.<p>* Slingshot-esque with VMWare: Same as above, only we provide a vmware image instead of an eee install.
======
corentin
Sorry, I don't have an answer; but I do have a question :) Why rewrite the
thing in the first place? It's not too late to trash the Ruby on Rails project
and focus your effort on improving your current asset (the Windows app).

~~~
mechanical_fish
I hate to mod this up, but, darn it, I have to mod this up.

Web apps have pros and cons. Desktop apps have pros and cons. Desktop apps
written with web-app technologies have... cons. The interface is limited to
what the browser can support. There are more moving parts. You have to worry
about synchronizing the data. You have to worry about pushing out upgrades.
You have the same support costs as any Windows desktop app, and _worse_ ,
because you're supporting a system that nobody else has ever seen because you
wrote it yourself. Etc. Etc.

Of all your ideas, the Asus-eee one seems the best -- just make the customers
buy hardware with the software preinstalled. If they screw it up, have them
mail it in for a new one. If the eee gets discontinued, find another small OEM
Linux PC and port the software over. If you go the vmware route you might as
well be selling and supporting an installable Windows app, which _you already
are_.

But the idea is still crazy. Customers are not stupid. They know the
difference between a full-featured Windows app and a web app that has been
crippled by cutting off the Web part. You're going to throw away all the
advantages of moving to webapps in the first place, and invest mighty
engineering effort, all to replace a Windows program with a program that (from
the non-networked customer's perspective) does _the same thing_ but with a
different, feature-poor browser-based interface. That non-networked 25% of
your user base is likely to respond by either (a) demanding that you continue
to support the Windows version; (b) switching to a competitor's Windows- or
Mac- or Linux-based product; or (c) buying some networking, and joining the
other 75% of the customers. Once that process has shaken down, you'll be left
holding an expensive, tricky Slingshot-esque technology that has almost no
users.

~~~
inklesspen
"Buying some networking"? I admit I wasn't exactly clear with what the app
does, but in the iPhone section I did say the app has to be used in places
where there's no cell phone service, let alone wifi.

It's an app used by public health agencies, who _have_ to be able to visit
clients in their homes and chart their progress. And plenty of homes in the
rural US have no dial-up internet, no broadband, no wi-fi, and no cell-phone
coverage, and no sign of that changing soon.

That said, I agree with you. The decision-maker at this company doesn't, and
as I mentioned below, I've got little leverage to change things.

