Thanks Peter, you totally went into all my areas of insecurity and answered
them.
Did you re-create a desktop app for the web ? If so, was it hard to get
people to pay subscription prices instead of a single price ? If I can ask,
how much did you app cost and how much do you charge now ?
Trausti
On Tue, Jun 30, 2009 at 3:15 PM, Peter De Berdt
<peter.de.berdt@pandora.be>wrote:
> On 30 Jun 2009, at 00:23, Rick Praetzel wrote:
>
> I am on the other side of it.
>> I find web apps to be unsightly, slow, and awkward because they run in a
>> browser which is unsightly, slow, and awkward.
>> So I write apps that run over the internet as desktop applications.
>>
>
> Not necessarily.
>
> Breaking down your arguments:
> - Need to write for at least three browsers: this is really not so much of
> an issue as most ppl make it. Internet Exploder is about the only browser
> that can possibly hold you back and even there Javascript frameworks and a
> bit of CSS knowledge can easily resolve those things
> - Unsightly and awkward: if you hire a good designer (or have one inhouse),
> a web application can in fact feel more natural than a desktop app. Even a
> desktop app takes a lot of GUI design in order to feel right on every
> platform. If you want to adhere to the UI guidelines such as button
> placement, you'll have to jump through hoops to get them both right on
> Windows and MacOS X at the same time. The only excuse you really have for
> not doing so is that most Windows applications don't follow the guidelines
> anyway. Also a web interface will have a more consistent look and feel
> across platforms. We also have drag-and-drop and all those little bells and
> whistles that used to belong to desktop apps and they are fairly easy to
> implement.
> - Slow: I totally disagree on that one, especially if you have a very
> data-intensive application. Our Javascript (and AJAX) heavy application in
> fact perform better than a rich desktop app that communicates directly with
> a remote database (i.e. one that is accessed over the internet), even on
> older computers. On the local network, our web apps are screaming fast. Add
> to that that a powerful server can serve so many requests per second that a
> multi-user app greatly benefits from having all processing server based.
> I'll even go as far as saying web apps perform extremely well on older
> hardware, better than a REALbasic app will ever do. I'm sorry to tell you,
> but database communication, even when compressed, is in general a lot more
> verbose than serving HTML views
>
> That said, switching from desktop app development to web development is a
> big leap and requires a totally different mindset. If you want to stick to
> pure browser built-in features (excluding flash based solutions like Flex
> apps), it requires you to learn at least three different syntaxes: (X)HTML,
> Javascript and your serverside language (in our case Ruby, with
Rails as the
> framework). It takes time and effort to get comfortable with them.
>
> When we switched from desktop apps to web apps a few years ago, we had the
> same concerns as you have. However, looking back now, it was the best
> decision we ever made for our business and our way of deploying apps (rapid
> release cycle). Some things that played out a lot better for us:
>
> - License management and piracy: since we have total control of the server
> and our customer is paying for a hosted solution, we don't have to worry
> about our app security being circumvented. It works a lot better than
> internet activation (which seems to be just as easy to work around these
> days) and gives us one centralized management point
> - Pricing: we have been able to cut our software prices by half or more in
> most cases due to a number of reasons: server cost is divided over all
> customers, use of open source software and databases
> - Bug fixes and upgrades: since the end user never needs to download the
> new version, quick deploys of bug fixes are less of a hastle for us than
> they used to be. Add to all of this that the number of bugs we
actually have
> in the application are far less than they used to be in REALbasic due to
> being able to rspec (unit/functional/integration testing) our
whole app. I'm
> not saying you can't write your own testing framework in
REALbasic, but when
> we did it back in the days, we never got it up to the standard
we're used to
> right now. Overall our customer satisfaction has gone up significantly,
> which brings me to...
> - Less support: right now we have about 5 times the number of customers we
> used to have, yet our support load has been slashed.
> Common causes:
> - no more application crash related tickets: those took us a lot of time
> to track down, since we couldn't reproduce most of them on our own test
> systems. Our customers used to run a variety of operating systems: Windows
> 2000, Windows XP, MacOS 10.2, MacOS 10.3, MacOS 10.4 (and if we continued,
> Leopard would also have come into the picture), some Linux variants. On top
> of that, the background processes run on those computers sometimes caused
> the crashes (virus scanners, spyware scanners, other utility apps). I
> literally had 5 different virtual machines on my hard drive to be able to
> test properly. In my opinion, this is a lot worse than supporting three
> browsers and it's a lot easier to ask a customer to install a new
version of
> Firefox/Safari than it is to force him/her to upgrade his operating system
> or even buy a new computer.
> - better error reporting from within the app itself: the automated stack
> trace we are sent from our web apps (when an exception is raised) is a lot
> more informative than what you can report through REALbasic (if
the error is
> actually caused by a mistake in the code). We rarely have to ask a customer
> for reproducable steps to determine the error.
> - faster upgrades and fixes: I can honestly tell you it usually takes us
> no time whatsoever to deploy new versions. Our next major upgrade (new
> features etc) is done in a separate git branch, so we can fix small bugs in
> the master branch. If needed, I write a simple new test to cover the issue.
> Then we just run the complete test suite to check if nothing else
broke, and
> then it's a matter of typing "cap deploy" and 10 seconds later everyone has
> the updated version (without anyone ever noticing a new version was
> released).
> - Mobile accessibility: all of our apps run out of the box in Safari on the
> iPhone for example, no need to write yet another app. Even so, we
do provide
> an iPhone optimized version of some of our apps if there's a need for it,
> but it takes us almost no time add that feature.
> - REST-based API out-of-the-box: this is more related to the framework we
> use, but we can give a third party a fully functional API in no
time using a
> REST-based interface and we still have complete control as to what is
> actually exposed.
> - Offline access: this was our main concern, but it turned out to be a
> non-issue. Our customers only want very limited offline access to the app
> and Google Gears and now HTML5 fitted right in there. But to be
honest, both
> wired and wireless internet access coverage is so widespread that we rarely
> have the need for it.
>
> All in all, for our business segment (database driven CRM/ERP apps), web
> apps were definitely the way to go. I'm not saying desktop apps don't have
> their place, I can't imagine a Photoshop or Final Cut clone anytime soon.
> The web has evolved a lot over the last couple of years and the boundaries
> that once ruled out a web app are quickly fading away. But of course there
> are a lot of web apps out there that still give the impression
that web apps
> are dumb, unresponsive and inferior.
>
>
>
> Best regards
>
> Peter De Berdt
>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>