|Perl: the Markov chain saw|
Re: web-based application or desktop application?by jdtoronto (Prior)
|on Dec 05, 2003 at 19:34 UTC||Need Help??|
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.