http://www.perlmonks.org?node_id=312086

I have wanted this discussion for a long time.

There seems to be a trend going on nowadays, to make some of the internal enterprise applications web-based, and to get away from the traditional desktop application.

I and another guy recently completed the system design of an application. The system design is desktop based, but the direction shifted to web-based application in the second half of the design phase. This is not ideal, but it is still fine, as system design phase mainly focuses on functional module design, database design and capturing business requirements from a more technical view. We tried to tell what to do, not (really) how to do it.

Now we are implementing it, and implementing it as a web-based application.

The application has four main functional modules, and we started the implementation of one of them one month ago.

Today, some of us, started to see a warning sign. The server side implementation has been quickly completed, but the client side coding is still going on, and will require serveral more weeks. This means that we are not focusing on the business logic, instead lots of time have been spent on rendering those web pages. We started to question ourselves, whether it is the right decision to make it a web-application.

Serveral facts here:

At this moment, the biggest benefit everyone agrees, is that web-application does not require client side deployment.

What is your thought? Do you have a successful story or failure to share?

Replies are listed 'Best First'.
Re: web-based application or desktop application?
by davido (Cardinal) on Dec 04, 2003 at 05:14 UTC
    The thing about doing it "web based" is that you get to take advantage of the fact that browsers already know how to understand markup (ie, various types of formatting), and most browsers have built-in "print" functions for creating hard copies.

    This enables the developer to ignore issues such as dealing with printer output, dealing with event handlers, Tk callbacks / window management, etc.

    So the development time is greatly reduced, while being able to present any feature a browser is capable of offering. Look at it like someone's already created an easy to use interface system. Yes, you still have to design the HTML that drives the interface, but that can be trivial as compared to dealing with a full fledged GUI.

    Designing an application, and choosing to make it web based (intranet, etc.) is simply a design choice whos goal is to provide a lot of features with a minimum of development effort. Yes, a desktop based software package can be made to look even more polished. Heaven knows, nobody would really like to be forced to manipulate a web-based interactive spreadsheet. Nobody's going to suggest trying to come up with a web-based alternative to QuarkExpress, or Aldus Pagemaker. But if the objective lends itself to a web-based environment, there are good arguments for going that route.


    Dave

Re: web-based application or desktop application?
by Zaxo (Archbishop) on Dec 04, 2003 at 05:38 UTC

    Another advantage of web apps is that they are automatically platform independent - so long as the page designers permit it to be by keeping it simple. Avoid jazzy dhtml, flash, clientside scripting, etc., etc.

    You can certainly save time on your app by getting designers in. It's good that you don't need to let them go nuts for an internal app. Think templates.

    Don't stint security just because this is your intranet. HTTPS remains a good idea.

    After Compline,
    Zaxo

      Authentication and security is definitely a fact here.

      We have a centralized authentication mechanism implemented for web applications. It defines the set of web pages a certain role can access, and what role(s) each user has.

      We tried to remove the authentication logic away from individual (web) applications, but desktop applications do not benefit from this.

      Another advantage of web apps is that they are automatically platform independent - so long as the page designers permit it to be by keeping it simple. Avoid jazzy dhtml, flash, clientside scripting, etc., etc.
      Yeah, in theory. In practise, many sites aren't simple (and considering the original post, this site isn't going to be simple either), and aren't platform independent at all.

      If you can afford to be 'simple', Java programs can be platform independent as well. And so a (Perl|Python|Tcl|...)/Tk application.

      Abigail

      Quote: Another advantage of web apps is that they are automatically platform independent

      Not true. It may be true for pure HTML, but web apps are much more than just HTML. I've had a case wich the site simply went crazy on a Mac, but worked without any flaws on a win32 environment.

      Aside from that, we have the ever lasting browser issue. Making a good web app that is 100% cross-browser is a royal pain in the a** (sorry, but it is) and that's because a good web app must have a good interface, and well, from here the other replies (including mine below) speaks for themselves :)

      Best regards,

      my ($author_nickname, $author_email) = ("DaWolf","erabbott\@terra.com.br") if ($author_name eq "Er Galvão Abbott");
Re: web-based application or desktop application?
by l3nz (Friar) on Dec 04, 2003 at 09:26 UTC
    Where I work, we have deployed a number of web-based applications and desktop-based application. Customers (internal ones) usually prefer web based applications, because:
    • The look and feel is consistent (they already know how to use a web browser)
    • They load fast
    • Pages are "simpler" and easier to understand
    For us, this means:
    • No versioning hassles (ever tried to manage a project made oh hundreds of separate DLLs that depend on each other and are on a client that breaks 1,000 miles away?)
    • No low-level hard-to-debug errors (the client breaks, leaks memory....)
    • Shorter developement times
    • Less 'layers' and less moving data back-and-fort
    Before starting the project, anyway, we designed a very simple widget tolkit that we use to handle HTML data (things like a scrollable table you can select rows on, a hierarchical tree object, a currecy control...) and then designed the pages to be simple: no (or very few) Javascript on-page events, you always press a button to perform an action, and so on. This means we almost forget HTML in coding and both layout and behaviour are always consistent.

    What you should not do, instead, is to say 'HTML is simple - let's embed it here and there'. This produces a mass (or a mess?) of unreadable code that will be very hard to mantain and understand when the project's over (when you have three or four nested tables, whose TD is that?)

    My 0.02 euros

      The look and feel is consistent (they already know how to use a web browser)
      Consistent w/ what? Have you ever noticed that google, yahoo and msn don't look alike? Just like these sites can look different, so can web pages. I don't but this one.
      They load fast
      Another false statement. The rendering of a page and rendering of a client side app are minimal compared to what they do on the backend, wether it is a DB operation, SOAP call, or something mathematical. I'd even go so far as saying, using an app is faster for more things. Imagine doing a spreadsheet in a web page. It'd be god slow just to add a new row or column.
      No versioning hassles (ever tried to manage a project made oh hundreds of separate DLLs that depend on each other and are on a client that breaks 1,000 miles away?)
      That's why you sandbox your app. Apple did this right, right off the bat. Your app is not a .exe per se, but a .app directory under the hood. When you double click say, Word, it "runs" Word.app. It actually loooks for an executable in the right place in that directory. BUT it uses a lot of internal libraries stored in that directory too.

      Now to argue the other end of things. Web sites can be VERY complex, especially if you develop a common api for common things. You break something very rudamentary, or something in the language that you program with changes a library, you have the same problem.

      No low-level hard-to-debug errors (the client breaks, leaks memory....) Shorter developement times
      Depends. Are you using mod_perl, servlets or something? It's easy to create a memory leak.
      Less 'layers' and less moving data back-and-fort
      Er? You always move data back and forth. if you mean ease of access, a Perl/TK program is just as easy as a perl cgi. Same w/ php/gtk and php.

      Play that funky music white boy..
Re: web-based application or desktop application?
by AcidHawk (Vicar) on Dec 04, 2003 at 05:46 UTC

    I put together a little toolkit as a desktop application which was used by about 20 techies where we work.. Not a lot of users but what struck me as a problem, which made me look at moving the toolkit to a web based application, was that when some-one wanted me to make a change... to say add some functionality, I only had to make the change in ONE place.

      This brought down the maintainence hugely. I never had to keep a record of who had what version of the desktop application and what dll's (we compiled the toolkit) they used when I changed perl versions etc.. I also didn't have to worry what version of perl they had installed etc etc...
      Another benefit which became apparent a little later was that these techies could now move around to other sites and still have access to this toolkit without having to install a desktop app.

    -----
    Of all the things I've lost in my life, its my mind I miss the most.
Re: web-based application or desktop application?
by Abigail-II (Bishop) on Dec 04, 2003 at 09:31 UTC
    This means that we are not focusing on the business logic, instead lots of time have been spent on rendering those web pages.
    I've been wondering. If I look at Java programs, most of them just use the default settings for the widgets, making them all look-a-like. If I look at most Windows program, all the buttons, entry fields, drop windows, and other widgets all look the same. If I look at Tk programs, more of the same. But when I look at websites, many of them go out of their way to have them make "unique", instead of just using defaults.

    Oh well, just a random non-Perl related thought.

    Abigail

      But when I look at websites, many of them go out of their way to have them make "unique", instead of just using defaults.

      I think one big reason for that is that, with websites, it isn't so far "out of their way" as it is with GUI toolkits. It's relatively easy to significantly spice up a web page. Moreover, it's easy enough that a designer can design a website without interacting much at all with the programmers.

      Really, I think the abberation is the slew of programs that adhere to the (usually drab) defaults. Unlike windows programs, Java programs, and Tk programs, most human creations are distintively styled. Publications included. Consider the variations in books... cups... doors... If programmers made all the furniture in the world, would we all sit down to eat our dinners at gray card tables with matching folding chairs?

      I think GUIs will need to mature a great deal before consistent and intuitive interfaces that don't suck aesthetically will become commonplace. Of course, by then, the "intuitive" requirement will take on a whole different meaning by virtue of the fact that most people will be exposed to computing from a very early age.

      -sauoq
      "My two cents aren't worth a dime.";
      
        Really, I think the abberation is the slew of programs that adhere to the (usually drab) defaults ... sit down to eat our dinners at gray card tables ...

        I dont care what the application is, design requires proportionate attention to competing and complementary criteria. For instance if usability is ignored at expense of performance, users are not going to succeed. Consider that in a study done by Nielsen, users failed in achieving successful outcomes for 35% of web sites out of 139 web sites. Trade-offs are required.

        Firmess, commodity and delight, (Marcus Vitruvius Pollio, 90-20 BC) is an often repeated phrase in design literature. Applied to software, the correct balence between this trinity of ideals is critical.

        For in-house built applications as the user suggests, the workmanship required for extra polish (delight) is not warrented ... at least until version 3 - 4 when all the other issues (firmness, comodity) have been addressed.

        I never forget the day pickles bagged his first hippy - mr. burns

      Some GUI programs do go out of their way to look different, and offer the user a way to change the look as they see fit. In particular, MP3/Media players tend to do this a lot.

      ----
      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

        I've worked at a place that provided "skins" for their web app. It was actually quite simple. *shrugs* Granted, the skin had to be stored server-side, but that's because HTML doesn't provide an easy way to choose images on the client machine.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Re: web-based application or desktop application?
by neilwatson (Priest) on Dec 04, 2003 at 14:22 UTC
    It's a pitty that more developers don't see the advantages of web based applications. All applications from calendars to accouting suites could benifit from the many advantages of web based applications:

    • Data is centrally stored for protection.
    • Authentication and access can be tightly controlled.
    • Easily accessable from any internet connection you wish. No problems with customer sites blocking out bound VPN access if your application runs on HTTPS
    • If you avoid the common mistake of using client side java then there are no issues with browser or platform compatability. From Windows to Apple to Linux to PDA all have access to the data.
    • All upgrades from features to performance are done on the server only. No need to touch any clients.

    I know I'm repeating some of what has already been said but I feel you can't overstate the advantages of the browser based application. The cost savings are far to great.

    Neil Watson
    watson-wilson.ca

      Since when did every single network-utilizing application become "web based?" Everything you're describing works perfectly fine as a network-based application. "Web based" only offers the advantage of using a browser as a GUI. HTTPS isn't the only possible protocol and rarely is the best.

      I thought this type of blind sheep mentality became extinct with the dotcoms. Guess I was wrong.

Re: web-based application or desktop application?
by b10m (Vicar) on Dec 04, 2003 at 14:45 UTC

    Well, since noone wants to suggests some negative sides of webbased apps, I'll do it ;)

    "Hot" keys
    With regular apps, you can always use certain keystrokes to reach some goal, and thus, speeding up the use of the app tremendously. I don't see how you could build that into a website
    No piping
    Ain't it lovely to pipe certain output to the next app? Even for the sake of "app | mail -s "Here's your output of app" user@domain".
    Back button can annoy ...
    Since the look and feel is like every other website the users know, you have to take care of the fact that they'll use the back button and don't read warnings about "Are you sure", "POST", "again" ;)

    I'm sure there are more disadvantages ... so bring it on! :)

    --
    B10m

      With regular apps, you can always use certain keystrokes to reach some goal, and thus, speeding up the use of the app tremendously. I don't see how you could build that into a website

      Web apps tend to be simple enough that hot keys usually don't make sense. If your web app isn't simple, it probably shouldn't be a web app (HTML doesn't handle complexity well).

      Ain't it lovely to pipe certain output to the next app?

      Piping is just a means for programs to share data with each other. In a web app, the sharing is usually done by an RDBMS. If you really want to use a pipe, use wget or lynx -source to get the page printed to STDOUT. Certainly, this is far more likely to work than attempting to pipe a traditional GUI program.

      Back button can annoy ...

      Yup, that's a problem.

      ----
      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

        Web apps tend to be simple enough that hot keys usually don't make sense. If your web app isn't simple, it probably shouldn't be a web app (HTML doesn't handle complexity well).

        Umm, I use hot keys so much that web interfaces irritate me because I actually have to move my hand to the mouse. Trying to use keyboard navigation for web pages is painful at best. It doesn't matter how simple your web pages are, the keyboard is just not a good tool for web page manipulation, and when I'm working I prefer not having to use the mouse.

        Don't get me wrong I surf the web as much as the next person, I just usually don't consider it work per say :) I use a mouse a lot too, I just prefer not to when I am typing a lot or "in the zone" as it were :)

        So in a sense I agree with you, web apps are not always the best tool for complex applications :)


        "Nothing is sure but death and taxes" I say combine the two and its death to all taxes!

      FWIW, you can do hot keys after a fashion by using the HTML accesskey attribute.

      example:

      <p><a accesskey="p" ref="http://www.perlmonks.org">Perl monks</a></p>

      How well this works depends on how well it is implemented in the browser, but with mozilla at least I can hit ALT+p to *click* the link. IIRC this doesn't work as nicely using IE.

      --greg
        Mozilla has one very nice feature in that if you see a link you want, say 'free beer', if you start to type f-r-e-e it will then jump to the links on the page that match what your typing. Pressing return follows the link.

        --tidiness is the memory loss of environmental mnemonics

Re: web-based application or desktop application?
by DrHyde (Prior) on Dec 04, 2003 at 09:01 UTC
    I can't believe that no-one has yet mentioned the biggest advantage of http-based applications - you don't have to hassle the desktop support guys to roll out a new app to the users!
Re: web-based application or desktop application?
by Ananda (Pilgrim) on Dec 04, 2003 at 10:07 UTC
    Hello
    As i see from what you mentioned, difficulty encountered in client side programming can be overcome with careful design of the web pages.

    For instance, multiple information that needs to be presented may be captured as mini pages (individual web pages) and included into one page that is actually presented to the viewer.

    Thus regulating the necessary back end activity to the respective mini pages. Which inturn modularizes the application and reduces the complexity.

    Ananda
Re: web-based application or desktop application?
by dragonchild (Archbishop) on Dec 04, 2003 at 15:35 UTC
    To me, the issue is the client and the stateless nature of the Web.
    • Web browsers provide a really convenient, if limited, client interface. They are also non-standard. IE, as an example, is non-standard within itself. (IE 5 and IE 6 render the same thing differently.) But, it does provide a much quicker time-to-market with a standard look-and-feel.
    • The Web's stateless nature is inherently unsuited to desktop-style applications. While the actions of a Word or Excel are stateless, what they act upon is their state. Now, if browsers were to provide more information to the server concerning state and allow themselves to be more configurable (removing the back button or allowing overloading of the back-button's functionality), that would be helpful. But, can you imagine every browser in the world doing that? In a standard fashion?

    Ultimately, them ore control you want over how your users work, the more control you need over how they interface with you. In my mind, the best of both worlds is to provide a client browser to your users, preferably written using something like Perl/Python/Tk. That gives you most of the OS-independence and allows you the server-side benefits. This is the model that most of the MMRPGs use, and it works really well.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      If you want to make HTTP stateful then you could fire up a single server for each user on a special port, and then shut that server down when the session is over. If every request went to the same server instance then it could keep state information between requests.

      Obviously this is not a solution for a large website but if there is one part of your app that really needs this then it could be used - especially internally with few users.

      --tidiness is the memory loss of environmental mnemonics

Re: web-based application or desktop application?
by BrowserUk (Patriarch) on Dec 04, 2003 at 23:24 UTC

    Like you, the first time I coded an app. to use a html interface rather than a gui interface, it felt like a retrograde step. So many of the things I was used to doing with a gui became horrible to achieve with html. I tried various routes -- dhtml, javascript etc., but even given that the site was a died-in-the-wool MS shop and the latest greatest version of Explorer was the only choice of browser I has to cater to, emulating the typical gui features was a nightmare. Menubars with drop-down menus, drag'n'drop, pop-ups etc. that are so typical of your average desktop app. are extremely difficult to implement and a nightmare to debug.

    After several iterations and a lot of wasted effort, the realisation dawns. Almost all the problems come as a result of trying to emulate the desktop gui approach. If you can clear your mind of the need to approach the interface in this way, stand back from the problem and concentrate upon the usage patterns, then the problems and the solution to them become a lot easier.

    That doesn't mean that all the problems go away. One particularly intractable problem is the need for dynamic updates of some part of the display. Only updating as a result of user interaction just isn't enough for some applications, but using a refresh timer to update the entire display every n seconds or minutes also isn't viable. If there are other parts of the same display that the user might need to scroll to read, the refresh will cause a loss of their position, and if they are entering information, the problem is even worse.

    The best solution I found to this problem was to use iframe tags to create small areas to contain the dynamic content, and use the meta refresh tag to cause them to be updated. The server application then re-writes the dynamically refreshed url whenever required and it gets redisplayed within the refresh time period. If the browser being used has a sensibly configured and enabled caching policy, the body of the iframe will only be updated if the file on the server has been modify, further preventing unnecessary updates.

    It is even possible to provide a crude kind of drag'n'drop, though it requires the use of a little javascript to make it effective, which maybe okay in an intranet environment. Basically, you provide readonly edit fields which automatically select and cut when activated and then when the user drops (pastes) the cut text into another edit field, it automatically submits. Like I said, crude, but possible if needed.

    A couple of other advantages of using a browser is that it simplifies internationalisation of your apps, especially where different character sets are required. It also makes it easier to enable your application for color blind, partially sighted and/or blind users. The ease with which they can override such things as font sizes and colour choices and even use speech-readers if they have the appropriate setup is considerably easier than trying to enable all these features in all of your applications.

    HTML interfaces will likely never be appropriate for all applications -- CAD/CAM, graphic editors and the like -- but for many more, the enforced divorce of interface from business logic, the inherently cient-server/centralised storage and (if used appropriately) the demarkation between content and presentation can become a compelling feature of writing applications this way.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    Hooray!
    Wanted!

      Related to iframes what I would like is something like <icontent> where you could do something like this:
      <p>You currently have <icontent src="http://me.com/basket_count.pl" /> items in your basket. <!-- server determines who user is through cookies -->
      As i understand it this is tricky in iframes as you need to set the height etc which are prone to change.

      This would allow you to create, for example, static product pages on a web-shop and only hit the cgi for the dynamic content such as the number of items in a basket.

      --tidiness is the memory loss of environmental mnemonics

        Why would you want that, and what do you want to accomplish with that? This can already be achieved by a simple Perl CGI script, PHP, or -oh, let's throw this back in- Server Side Includes, if I understand your point (what I probably don't do)...
        --
        B10m
        There's no reason that you can't use <IMG> for that, except that hardly any browser can deal with <IMG> getting back text. Or better yet, the proposed <OBJECT> element, but, Netscape being the dominant browser at that time, suffered from NIH syndrome, so it was never broadly used.

        Oh well, the web could have been great. Instead, we got Netscape to ruin it.

        Abigail

Re: web-based application or desktop application?
by hardburn (Abbot) on Dec 04, 2003 at 15:08 UTC

    Doing web-based applications may seem like a lot of fluff, but I think their value of making the client OS irrelevent is wonderful. If they have a reasonable browser, they can access your application.

    The major problem with web-based apps, as you've hit upon, is that HTML is too simplistic. Further, the only viable alternatives (Flash, Java Applets, etc.) have other problems, and often break the cross-platform nature that is the biggest advantage of web-based apps in the first place.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

      The major problem with web-based apps, as you've hit upon, is that HTML is too simplistic.

      XForms look promising. I haven't yet seen XForms mentioned on perlmonks, but I think this is one new technology that makes a lot of sense, especially to automate document workflow inside the company. None of the major browsers currently supports XForms without a plug-in, but this is only a matter of time.

        XForms++

        IE--, which will probably take almost 10 years to support it properly (see also: CSS layout model).

        ----
        I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
        -- Schemer

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

Re: web-based application or desktop application?
by wjw (Priest) on Dec 04, 2003 at 21:53 UTC
    I worked on a web-based project in 2000 which I considered to be very complex. It took myself and a fellow programmer almost a year to get the thing right, but when we did... it was easy to maintain and update. The complexity of the interface involved being able to drill into and back out of some 21 million records spread across 400 databases (MySql) each containing about 15 tables. The basic premise of the app was that business machine cost/performance could be tracked nationwide across all makes/models of machines (mostly copiers). By the time we were done, a user could drill into a particular machine, sold my a given office and maintained by particular technician and find out cost/copy, overall maintenance cost/hour/part/copy etc... . The application is the core service of the company we were coding for, and they are very successfull with it. My point here is that it was a long hard grind to make that UI work, but it did pay off. A distibuted client app would have never worked... . We did (often late at night, with very red eyes) question the feasability of the web approach, and it was worth while spending the time questioning it. But I would venture to say that the company we wrote the code for would be out of business had we tried anything but the web app approach. Just some encouragement... :-)
Re: web-based application or desktop application?
by andreychek (Parson) on Dec 04, 2003 at 21:39 UTC

    Perhaps I'm biased, but we've had a lot of luck coding apps using OpenThought. It's a web application environment which allows you to build web apps which don't require the page to reload. They end up acting like typical desktop applications, except that you get all the benefits of web based apps.

    Internally, it does make use of DHTML to do this, though an app developer doesn't have to know anything about how DHTML works to make use of it. Using DHTML means that there is a requirement of 4.0+ browsers... but for internal only apps, that shouldn't be a problem.

    OpenThought is still under development, but we use it in production here, and it's been working great.

    -Eric

    --
    Lucy: "What happens if you practice the piano for 20 years and then end up not being rich and famous?"
    Schroeder: "The joy is in the playing."
Re: web-based application or desktop application?
by allolex (Curate) on Dec 04, 2003 at 20:34 UTC

    Web-based applications have an advantage which has been touched upon here: many programmers already have the necessary skills to create a web interface. Nowadays, most (I don't think I'm going out on a limb here) people come to programming after having messed with DHTML for a while and discovering they can't do what they want with HTML/CSS/JS alone. It seems like a natural extension of the learning process to do a web-based GUI.

    In my own experience, the web-based path has been the only way to go because many of the people working on our dictionary project have no means of installing software on their systems and are too far away to receive much hands-on support at all. Plus, they can use a familiar tool like a browser to do their work.

    The advantage for us, the developers, is that when we make a change, the deployment is immediate.

    There's not much here that hasn't been said by others, but since you asked for personal experience, you got it.

    --
    Allolex

      For SIMPLE apps.. really simple ones. For anything that like, takes an excel file and flattens it to csv, then processes the data and mails it out.. those are skills that you need just as much as learning to build a page. Learning java or tk isn't hard either. problem w/ pages, or the advantage, is everyone's code is out in the open.

      Play that funky music white boy..
Re: web-based application or desktop application?
by exussum0 (Vicar) on Dec 05, 2003 at 02:47 UTC
    I have a pro-application story for people. I have an app that does a virtual tail onto a web page. Problem is, we can't show ALL the data at once. It takes a lot of time for the page to render. (Think 3000 rows). So we show the top 100 and let it auto refresh so we can eye-ball newer stuff "just in case". This fucker pulls the same data over and over again, generating a lot of database hits.

    So why not cache it you say? Well, we can't. We need the data live. Ticker-style. So if someone hits reload, the better have the newest data. Now lets say we want to find people with only certain attributes. In a web page, we have to either run a new query to pull the specific data. But.. if there is an app w/ all the data loaded (quick to render sits it's using a native widget set), why not use the existing dat aand then filter that. Just hide the irrelivant data. Now we don't need the data again, just un-filter it.

    Now imagine dealing with 8-10 THOUSAND rows of data at 12 columns and doing live manipulations. Whn it comes to doing data manipulartions, an app is usually easier. The JS becomes a pain.

    Also, take a mail app. I tried switching permanently to a web interface.. but lord, it's so slow compared to mutt or Mail.app just because it has to take so much more time to build and render a page. W/ an app, the interface sticks around, you just change the data on the fly.

    Dont' even get me started on maintaining a state. Say that you dont' want peopel to "go back". Say you wanted to have people go through 52 cards on 52 pages, but hit each one once. Then you have to worry about caching and all of this other stuff. W/ an app, you have TOTAL control of what the user can and can't do. No need for encrypted cookies, or doing a db call every now and then to make sure he hasn't clicked back.

    But you know what the web is good for. It's good for arbitrary data and showing it ala book form. If i had to read each email message once w/o managing it.. moving it into folders, performing a search, in chronological order, web pages would be easy.

    One-off's, where state doesn't matter (like a simple calculator) or a search page, those do really well, since state doesn't matter so much. Other things, not so good. :)


    Play that funky music white boy..
Re: web-based application or desktop application?
by jdtoronto (Prior) on Dec 05, 2003 at 19:34 UTC
    And have it you are! Wonderful meditation pg++

    I have been an advocate of client/server operation for many years. I could never see the sense in having a large number of desktop applications scattered around on a variety of machines which no matter what anybody says are not easy to maintain. But I am also specifically an advocate of 'thin-client' systems where you can use just about anything as the client hardware and use a common thin client environment. To that end I often use Citrix Metaframe as an environment to serve up 'desktop' application type products.

    This internal application has lots of complex screens/pages, which we now believe are more complex than HTML pages can handle.
    Perhaps this points out the need to go to either XML rendering or to use a more capable HTML templating system such as Template Toolkit.
    For traditional internet applications, how to translate user requirements into web pages is largely controlled by designers and programmers, but that is not the case for internal applications. Customer first, so non-IT persons have a bigger control here. The business users don't care whether something is right from a technical point view, they care whether it is easy, right and efficient for them.
    Would seem to indicate that the design process has been kidnapped! Design of the user interface and the screens/forms should, I believe, always be in the hands of the user - to a significant extent. This may mean, as I suggested above, looking at a variety of approaches to the UI. In one application here I dropped the original web-application design and replaced it with a Tk based design served over a Metaframe session - the Tk interface is more highly controllable in layout and worked much better than HTML.
    We started to question ourselves, whether we are trying to implement certain architecture just becaue of the architecture, or we really think those web architectures will benefit us?
    Now you address an entire area of the philosophy behind aspects of computer science! In my practice I have six programmer types between 18 and 30. The worst thing is that the 'programmers' we get from the colleges and universities can write code very well. But they have little or no in depth understanding of the theoretical foundations of much of computer science or interface design, witness the monk here recently who asked us for help to get his professor to pay for a set of Knuth for the library.

    Before we start on the design of a product we need to understand very clearly the needs of the users, the business rules involved and how they work with the software they have. One internal app we did was meant to replace and older product based on the Pick database system. They always had the clients name, billing address and shipping details on the screen the entire time an order was being processed. Eventually we prototyped a system where the summary information was on-screen all the time and the detail was popped up when they needed it. They loved it, and were most complimentary about how we saved screen space and made things less cluttered.

    Don't abandon the idea of web-applications, likewise don't abandon the idea of desktop apps. Think about how everything is delivered, think about the lifecycle requirements of the product.

    I have replaced a number of very aged applications with newer GUI destop applications. But ocassionally the users dont like the GUI because they need to use a mouse sometimes. They prefer everything to be keyboard based. Other times we use web-apps where the clients can be remotely located - but we also use them on intranets where the user interface requirements of the users suit the interface. Some times we throw our hands up in despir and use a curses or similar interface where the users can be so much faster at the entry work than any other way.

    My parting word: Make sure the architecture suits the application, not the other way round.

    jdtoronto

Re: web-based application or desktop application?
by petercooper (Acolyte) on Dec 10, 2003 at 02:00 UTC

    A few people have commented here on how Web browsers can be limiting environments for client/server apps. Another suggested supplying your own client to users. What I'm wondering is.. is there another 'standard' for a remote interface standard?

    That is, it's not a Web browser, but a kinda 'app browser' which can connect to remote applications, receives markup, and then renders the app in the local machine using the native OS widgets. Then all data input and output goes back and forth to the server (if necessary) and on screen data can be updated, etc, but not requiring page updates all the time (unless you change view).

    I know you could produce something like this with Perl/TK, but I was wondering if work has already been done in this area, or if there are any standards.

Re: web-based application or desktop application?
by metadoktor (Hermit) on Dec 11, 2003 at 18:49 UTC
    Web-based or Desktop Application?

    It depends...

    If the complexity of your interface is too great then a web-based app may not be what you want.

    You might want to consider a Java applet if you have to go the web-based route and have to deal with a complex interface. Java applets seem to be pretty portable across modern browsers but you obviously want to test against your target browsers.

    metadoktor

    "The doktor is in."

      Another option is to use ActiveX components generated by Delphi (I've seen some nice thing done with it), but I'm not sure how portable this would be...

      Best regards,

      my ($author_nickname, $author_email) = ("DaWolf","erabbott\@terra.com.br") if ($author_name eq "Er Galvão Abbott");
Re: web-based application or desktop application?
by DaWolf (Curate) on Dec 09, 2003 at 01:14 UTC
    Great post!

    It has an eternal place on my favorites! I love this post because I've ran into the same problem but in my case it was the other way around: my boss started to ask things that:

    1) The site couldn't do
    2) The site could do, but it would be too complex and time consuming to develop

    And this is exactly where many people make mistakes: unfortunately a web based app CAN'T do everything a desktop app can.

    Quote: non-IT persons have a bigger control here.

    So, non-IT persons don't have the knowledge to know what they can and what they can't deploy in a web app.

    So, non-IT persons usually make crazy requests to the webdevelopers.

    So, since they have such control, non-IT persons don't like a "no can do" for an answer...

    Pretty sad, I must say.

    I have a practical case that I would like to share with you:

    I've been asked several times if I could make a form field of a web page to have an "autocomplete" feature, like the address bar of the web browsers. For an example, I have the field "Monks" and I type "da" and then I get on my page a combobox with DaWolf and davido.

    My answer to this? YES and NO. YES, it could be done by JavaScript (believe me it's not THAT hard), but NO, it wouldn't work out.

    Why? Because when you deploy web apps you must consider at least two things:

    1) Bandwidth, both server and client side. You must have a good bandwidth on your hosting service and the client must have a fast connection.
    2) The client's machine. It must be decent.

    If you miss one of these points - and believe me, there's no possible way to be sure about them today - things will go wrong. For an example, the client's machine slows down and he/she pushes the submit button or worse the reload button over and over. Can you imagine the nightmare?

    So, web apps have several limitations as well as several advantages.

    In my humble opinion, some things are better on the web, others are better on the client's desktop.

    Just my two cents.

    my ($author_nickname, $author_email) = ("DaWolf","erabbott\@terra.com.br") if ($author_name eq "Er Galvão Abbott");