R
Rob Nicholson
(PS. Please suggest another newsgroup for this if not really applicable
here)
I recently came across the following article which really sums up an issue
that's been niggling me for a while:
http://msdn.microsoft.com/netframework/using/building/windows/analystreports
/decide.aspx
We currently have a complex VB6 database application in a traditional
client/server environment. The screen layout is complex and the user
experience has to be immediate and responsive (it's used in a call centre
type environment).
However, many potential clients ask "is it web-enabled" as if that is the
panacea for all that is good in software. Despite us having incredible
success with Citrix & Terminal Services across the Internet (one of life's
mysteries as to why more companies don't use this technology to leverage
non-web apps), we still feel as if we *have* to web-enable our software. Or
maybe end up with a dual user interface - Web forms for simple access and
Windows forms for more complex access.
The usual reasons give for why it must be web-enabled are three fold:
o IT like web-apps as they cost less to rollout, maintain and support
o Remote access across a WAN tends to work better than client-server and
also opens Internet access
o Web apps tend to be easier to use - mainly as a side effect of web-apps
being inherently simpler
The first one carries a lot of weight but is a bit sad when a system is
rejected not on functionality but because IT support is the primary
consideration. But such is life..
One alternative though which I don't see discussed that often is good old
ActiveX technology. In effect, download a mid-sized ActiveX control which
contains the rich user interface into the browser but communicating with a
back end server which has all the other components like Crystal Reports etc.
A Java client is also another possibility but our expertise is really in
Windows applications.
This addresses the first reason (less support) and I feel the data
requirements across the Internet/WAN would be similar to a traditional
web-app (it certainly could be a design goal) so on a par with reason #2.
Complexity is really just part of the design but as we want a richer user
interface, maybe this one would suffer a bit.
A very good common example we use a lot is the grid and the ability to sort.
The otherwise excellent ASP.NET DataGrid has to re-visit the server to
change the sorting. However, the Windows form equivalent is far slicker.
Is this a valid approach - the ActiveX idea? Okay, so we're limiting our
platform base to Windows and IE (practically) but that's okay - 99.9% of our
clients are on that technology anyway. And a dial-up user would have to wait
a while for the (say) 5MB ActiveX control to download
I get the feeling it is otherwise things like FLASH MX and TextControl
ActiveX controls wouldn't exist.
Regards, Rob.
here)
I recently came across the following article which really sums up an issue
that's been niggling me for a while:
http://msdn.microsoft.com/netframework/using/building/windows/analystreports
/decide.aspx
We currently have a complex VB6 database application in a traditional
client/server environment. The screen layout is complex and the user
experience has to be immediate and responsive (it's used in a call centre
type environment).
However, many potential clients ask "is it web-enabled" as if that is the
panacea for all that is good in software. Despite us having incredible
success with Citrix & Terminal Services across the Internet (one of life's
mysteries as to why more companies don't use this technology to leverage
non-web apps), we still feel as if we *have* to web-enable our software. Or
maybe end up with a dual user interface - Web forms for simple access and
Windows forms for more complex access.
The usual reasons give for why it must be web-enabled are three fold:
o IT like web-apps as they cost less to rollout, maintain and support
o Remote access across a WAN tends to work better than client-server and
also opens Internet access
o Web apps tend to be easier to use - mainly as a side effect of web-apps
being inherently simpler
The first one carries a lot of weight but is a bit sad when a system is
rejected not on functionality but because IT support is the primary
consideration. But such is life..
One alternative though which I don't see discussed that often is good old
ActiveX technology. In effect, download a mid-sized ActiveX control which
contains the rich user interface into the browser but communicating with a
back end server which has all the other components like Crystal Reports etc.
A Java client is also another possibility but our expertise is really in
Windows applications.
This addresses the first reason (less support) and I feel the data
requirements across the Internet/WAN would be similar to a traditional
web-app (it certainly could be a design goal) so on a par with reason #2.
Complexity is really just part of the design but as we want a richer user
interface, maybe this one would suffer a bit.
A very good common example we use a lot is the grid and the ability to sort.
The otherwise excellent ASP.NET DataGrid has to re-visit the server to
change the sorting. However, the Windows form equivalent is far slicker.
Is this a valid approach - the ActiveX idea? Okay, so we're limiting our
platform base to Windows and IE (practically) but that's okay - 99.9% of our
clients are on that technology anyway. And a dial-up user would have to wait
a while for the (say) 5MB ActiveX control to download
I get the feeling it is otherwise things like FLASH MX and TextControl
ActiveX controls wouldn't exist.
Regards, Rob.