Proxcom - Which way to go ?

Which way to go ?

Character, GUI, Web Browser, WebClient. so many interfaces, so little time to redevelop an application into each one. So which direction should we be taking ?

This is probably the most important question facing the development strategist at this present time. The decision is pressured by commercial need, flavour of the month, Directors or End-User clients feeling that the "web is where we need to be" without completing a full business justification. The development Manager is now faced with choosing where to use his finite resource first.

Should they create GUI, should they create Web, should they contract to have one or other created for him with the on-going problems surrounding support, on-going maintenance and enhancement.

Wouldn't it be wonderful if you could develop once, support once and deploy in two of the most advantageous popular modes. If this approach appeals then consider "Thin WebClient" as the way forward. If planned at the outset, applications can be created that can subsequently be deployed for both GUI and for WEB.

The deployment of a "GUI application" on the Web has the distinct spin off of making available functionally rich software with excellent interface to remote clients without the "bandwidth downside" that plagued the WAN deployment of "Client Server" applications.

Character (See Figure 1)

The main merits of character deployment are well known and accepted, they are as valid today as they were ten years ago, character has its place and is here to stay.

Graphical - Client/Server (See Figure 2)

The main merits and pitfalls of GUI Client/Server deployment are well known and accepted (lived with), they are valid depending on the environment and the type of usage.

Graphical - n-tier (See Figure 3)

Graphical n-tier avoids the bandwidth issues associated with Client/Server deployment but at the cost of increased development time. This option will allow future interfaces to be created with less effort.

Graphical - Thin WebClient (See Figure 4)

Graphical Thin WebClient avoids the general operational bandwidth issues associated with Client/Server deployment but at the cost of increased download time at the commencement of the first session. This mechanism is well suited to the heavy workload company connectivity but is relatively unsuited to the casual occasional user, i.e. "Joe Public".

The time taken to "set up the first session" needs to be justified by a relatively long and heavy usage to justify the 10MB download. An alternative to this is that the initial download of software could be supplied to users on CD, this would avoid the long download. It would however be at the cost of flexibility. Future upgrades may be a problematic if shipped by CD rather that a download.

Browser Internet / Intranet (See Figure 5)

Internet or Intranet networks are restricted by the capability of the browsers available. The application has to be suitable to the minimum quality and version of browser if the application is to be used in the wide public domain.

Avoids the bandwidth issues associated with Client/Server deployment but at the cost of slightly increased development time and the browser restrictions.

The options are varied and the route needs to be chosen with the "end deployment objective" in mind. If one accepts this approach then an option that provides "two end results for one lot of effort" would seem to be the logical choice.

It is also possible that the best solution would involve more than one of the above.

For example in a sales organisation you may want to deploy character within the warehouse on terminals and RDT units. In the office, on the LAN/WAN a GUI n-tier environment could be used to provide a rich, simple user interface to internal staff. Where clients require connectivity to check and work with staff on a day to day basis, the GUI n-tier WebClient could be used, reusing a number of components from the office system providing the client with a very functional interface. Finally, the browser technology can then be called upon to provide the end customer with access to the current status of orders that have been placed. With facilities for changing key information like addresses and contact numbers.

In the above example all the different methods come together to create a really good system.

Michael Syree

Proxcom Limited

Figure 1.

Character
Positive Aspects	Negative Aspects
Very fast development	Does not look good on screen
Ideal for data entry	It is old technology with a perception that it is out of date and of no use
Very Low Bandwidth Requirement (probably maximum of 2k per screen)
No Client installation required, client runs on server.

Figure 2.

Graphical Client/Server
Positive Aspects	Negative Aspects
Development time is reasonable	Bandwidth Requirements are very High - Can cause performance issues
On Screen Appearance can easily rival other products, i.e. Microsoft	Bandwidth issues may hinder use over WAN or even LAN in some situations
Very rich user interface	FAT Progress Client must be installed on Client Machine
Complex screen layouts can be achieved
Requires a mouse (depending on circumstance be problem)

Figure 3.

Graphical n-tier
Positive Aspects	Negative Aspects
Split business logic provides quicker integration with future interfaces	Development time is increased with requirement to split business logic from interface
Can be used over a WAN with decreased bandwidth requirements	FAT Progress Client must be installed on Client Machine
On Screen Appearance can easily rival other products, i.e. Microsoft
Very rich user interface
Complex screen layouts can be achieved
Requires a mouse (depending on circumstance be problem)

Figure 4.

Graphical Thin WebClient
Positive Aspects	Negative Aspects
Split business logic provides quicker integration with future interfaces	Development time is increased with requirement to split business logic from interface
Can be used over a WAN with decreased bandwidth requirements	Must be n-tier in architecture to use Webclient
On Screen Appearance can easily rival other products, i.e. Microsoft	Requires a 10 Mbyte download to PC from Internet or loaded via CD
Very rich user interface	Download must be installed on client machine
Complex screen layouts can be achieved	Download not suited to light/casual public use
Can run same code as n-tier
Ideal for Corporate Client Access as GUI interface looks good
Secure
Requires a mouse (depending on circumstance be problem)

Figure 5.

Browser
Positive Aspects	Negative Aspects
Can be used over a WAN with decreased bandwidth requirements	Development time is increased over character but less than GUI
Can run same code as n-tier if required	Restricted by Browser Capabilities
Ideal for Joe Public Access	Restricted Functionality due to Number of Browsers Available (if you want it to work on all of them)
No download (software already present)	Reduced appearance limited to browser capabilities
Appearance can be improved by 3^rd party utilities	3^rd Party utilities require download to client machine
	If Stateless environment causes increased development time
Requires a mouse (depending on circumstance be problem)

[Top]