Mission Critical Applications and Web Based UIs? 10
Jonny Quest asks: "I work for a company with an excellent Client-Server based product. Unfortunately it's not 'Web-Based' (whatever that means). Ours is a 'Line-of-Business' app, i.e. it means that those people who use it absolutely depend on it for making money - if the app is down, they can't process their orders, service their clients & employees, etc. at all - mission critical in other words, and they spend ALL day in the app. What's the best UI that any Slashdotter has seen for a 'Web Based' app? Something with a rich user interface and some decent multiscreen handling (the current app has about 200 screens...)?" 'Web-Based', that's such a loaded buzzword, and like most buzzwords no one is really quite clear on what it means. Does it mean HTML+CGI? Does that allow for Java? Cold-Fusion? Internet operation or just Intranet (if it's mission critical, it better be the latter, and even then...)? Would any of you recommend deploying a mission-critical application over the web? If so, how would you do it? What technologies would you use and what is to be avoided at all costs?
KISS (Score:3, Informative)
I'm sure you probably have a good idea of what those processes are right now, and as long as you can isolate them, you're home free. Once isolated, you can quickly/easily wrap them in a traditional GUI, web front end with PHP or Perl, and any number of "other" interfaces such as eMail.
Make sure you're core logic is tested well, and put in shareable modules (DLL's on windows), and use that logic many ways. If you ever have performance problems, it's due to the technology you're using. Just switch to another type of interface (different development tool, etc.) and see how that works out.
Intranet and Internet (Score:2, Interesting)
BTW - If your curious, I wrote all the server-side stuff in ASP (we're practically married to Microsoft). However, my boss also wants to have a mirrored copy on a Linux server written in PHP so a case like another Code Red incident won't wipe everything out.
Hmmm.. (Score:2)
In that case, you'd do well with a simple GUI wrapper. Seagull Software sells a decent one. The newer stuff supports what people call a 'web-based' interface, as opposed to just a guified wrapper. The end interface can be as flexible and different as you like, with the capability for users to fall back to the regular old interface when it suits them. Try http://www.as400.ibm.com/developer/tools/web.html
Mission critical and web-based apps? Nahh... (Score:1)
If it's mission critical, stick to traditional client-server!
Crewd
Re:Mission critical and web-based apps? Nahh... (Score:2, Insightful)
Re:Mission critical and web-based apps? Nahh... (Score:1)
Crewd
web interfaces save here, lose there (Score:3, Insightful)
a) available through the browser (duh)
b) usually the display layer is done in a high level language, so you save on development time and headaches here over more low level UI platforms (heed what that other guy said above about pulling all the core logic into a tightly formalized set of componants)
c) people are familiar with the web, so some of the tasks they may have to accomplish through your app they will already be familiar with
I recommend using something server-side like PHP or Java to control your display layer
Re:web interfaces save here, lose there (Score:3, Insightful)
Some Lessons From Financial Apps (Score:5, Insightful)
So what are some good examples that accomplish these tasks? Well, there aren't too many that I'm really fond of out on the public networks, but the online brokers (etrade, schwab, datek) are a reasonable start. They have lots of information, pretty good workflow, and fairly robust and clear problem handling. Webvan was pretty good when it was around (relatively simple though it was), but there were too many hierarchies to navigate.
Good Luck, Robert Seymour
Lessions (Score:2)
I mention the above cause I'm working with a product now with a web based interface that only runs on ie 5.5 with the latest java upgrades, on windows. Of course many of our customers are unix shops.
the above aside, Java is slow, at least in our implimentation. Running across a 56k modem is an exercise in frustration. I don't know how much of this is just our implimentation, but it is at least something to watch for.
Ask this question: Is there a 20% functionality that the users spend 99% of the time with, and for the other 80% you can give a difficult to use (but quick and easy to impliment) interface. Perhaps your current interface for those who need everything, and web based for the most common things.
What I think is best is a web based interface that users can use when they are working from elsewhere. At the office use your system, when on the road or working from home use the wbe based system which will let you do everything you normally do. For the few things you can't do from the web visit the office once a month.
Identify who is likely to use this. A salemen on a different continet working from a customer site via a satalite connection (long delay) might find the web base system better if implimented right, and might need functionality that everyone else doesn't need. Work from home users probably just want an interface that works on their chosen OS (mac, beos, windows, linux all come to mind, but others are possibal), but is on a fast (ok, dsl) link so speed isn't such a issue.
Once you know who isn't well served by the current interface, then you build one to fit their needs.