Re: MSAccess to Web App

RonG <rgafron@xxxxxxxxxxxxx> wrote in
news:a6f2c386-cf7e-4eee-94d3-8921ad8e0b3c@xxxxxxxxxxxxxxxxxxxxxxxxxxx
m:

In looking to the future of the application, we have a couple of
issues that we're trying to address.
1. Access97. A great release of Access, but it's dated. We could
simply upgrade to, say, Access2007.

I agree that an A97 app is long in the tooth nowadays, and there are
minor (but easily resolvable) installtion issues on modern versions
of Windows.

2. We have the usual support issue that anyone would have with a
PC- based application, that is, support of as many different PC
configurations as we have users.

This is something that *you* care about but your clients don't. They
don't have but a limited number of PC configurations, so what your
other clients have is really of no concern to them. Sure, if you
have support issues for all those multiple platforms that take away
time from adding new features, that actually affects your ability to
deliver. But nobody ever bought an app because the developer had an
easy time supporting it on multiple platforms.

This is self-centered view of your situation, not a
customer-centered view.

3. The market we work in has a fairly high percentage of Mac
users. We usually suggest something like Parallels for Mac, but
that's not really a solution, we don't think. We want to be able
to reach that market.

There's always Windows Terminal Server. On Mac, they'd have to run
the Mac version of the RDP client (because IE no longer exists on
the Mac so you wouldn't be able to use the web widget to connect to
the Terminal Server via a browser).

I'm not suggesting this is practical for you situation, just
throwing it out there as an option for those who also desire to
support Mac users.

We looked at various solutions that would give us cross-platform
capability, since there are some out there. It seemed, after all
was said and done, that our best route would be to take the
application to the Web. We get to move to a more modern database,
say, SQLServer or MySQL.

Er, SQL Server is an older database than Jet, as it's a fork from
SyBase, and SyBase predated the existence of Jet.

MySQL is about the same age as Jet, but it was designed from the
ground up as a web database, with high concurrency for read-only
users. This is why it took so long to get modern database features
in to it, because it's original design was for a purpose that didn't
need things like referential integrity and so forth.

Until InnoDB provided RI, MySQL was really just a toy, suitable only
for non-crucial data, in my opinion. That has changed, but at a cost
in performance and flexibility (for instance, you can have RI or you
can have full-text indexing, but you can't have both in the same
database).

We eliminate most of the individual support issues; if you
have a browser, the system will run; nothing to install on the
client PC.

I think it's hilarious that you think there would be no support
issues with the multitude of browsers out there. Have you ever
created a web page of any degree of complexity and checked it in
even a handful of common web browsers? There are tons of things in
just layout, let along in the way HTML forms look and behave. You'd
no doubt want to go with something AJAX-ish these days and that
likely means one of the 3rd-party javascript libraries, and then
you've built a dependency on *that* into your app, with all its
incompatibilities and development issues.

Lastly, it gives us access to any platform that can run a web
browser.

While I see this as a nice thing as an added feature, a
browser-based app can just not equal the ease of use and speed of a
desktop app. It takes more screens to get the same work done, and
the latency can be horrendous. And it's much harder to validate data
-- you have to do it twice (client-side and server-side), whereas a
bound desktop app gives you the database engine's validation right
there in the front end.

And when moving away from Access, think of all the form and control
events you give up! It means a much more complicated codebase, with
no expansion of functionality (and likely a reduction of it).

In addition, moving to a web app model changes our revenue stream.
Right now, we rely on our users willingness to upgrade every time
we have a new release. In a web model, we'd charge a monthly fee
that would be sized to be no more than our current prices, but
provides us with regular revenue.

Again, I think you've not really thought this through from the
customer point of view.

One of the services I provide is not just database development, but
also consulting to help clients determine the best fit for their
needs. I've been hired by clients to advise them and ended up
recommending against hiring me to develope an Access app, because it
was not the best fit. Usually this is a matter of looking at some
existing commercial application. What I do know is that none of the
clients I've ever worked with was interested in paying a
subscription fee. First, they see it as a way to gouge them out of
lots more $$$. Second, they don't feel like they own anything ==
even though they don't own the app, they at least own the license to
use it according the terms under which it was purchased. With
subscription software, the power is all in the hands of the software
provider.

You realize that people really hate Symantec and McAfee and all the
subscription-based AV providers, right? They hate having to
continually pay to use the software (and Symantec is notorious for
having a completely screwed-up renewal process). I see this ALL THE
TIME -- complaints about "why do we have to pay again? We just paid
last year!"

Sure, they know they are paying for only a year, but they don't like
paying and paying and paying again.

Last of all, when you're using hosted software, you're not
guaranteed that your data belongs to you. What happens to your data
if you stop paying? What happens if the provider screws up and fails
to apply a payment and their billing system *thinks* you've stopped
paying? You could end up locked out of your own data.

And what about security?

Most small businesses don't have great security, but they also
aren't targets for hackers as any decent-sized hosted software
website would be.

So, it looks like a *very* tough sell to me. I'd certainly recommend
looking for different software if the old desktop version was no
longer supported and the only option was a subscription-model
web-hosted version.

And, oh yes, what about disconnected users? It may be that your app
doesn't support laptop users leaving the office and working with
data on the road, disconnected from any network, but many apps do,
and hosted software can't do this (unless it's been built in from
the ground up, as with Sharepoint and Windows Live).

Right now, we don't charge for support. You buy
the software, and you get the updates for free until we come out
with the next release.

I'm sure your customers would be just thrilled to start paying for
support.

You guys are absolutely right that there is a concern about our
users willingness to move to a web app. Our solution to that
right now is to continue to support the last PC-based version of
the software along with the web app. New functionality would be
put into the web app only, which we think would gradually entice
them to move to the web app.

I have never had a client who would follow your ap to the web.

Also, it does give us a chance to gauge the response of our
users. We're not doing this to piss them off, but to give us a
better application model for the long run.

I think you're completely misjudging what is a "better application
model." Almost all of your criteria are based on your company's
needs, and not on the needs of your customers.

If the web app just doesn't
gather any positive response, we'll have to address that.

I don't know what kind of client base you have, but the clients I've
had over the past 15-odd years of PC consulting would not be
interested in what you're selling.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.