Your question is very difficult to answer as stated, since there are so many variables. The combination of the size and makeup of the specific infrastructure, installed base of applications and the degree of help required by the users is essentially unique to each environment. The only thing you can do as a general rule is to get some good software to help automate as much of the support work as possible. "Good" software is evaluated as the best possible fit for your current environment. Once you have that in place, you will be in a much better position to judge how many and what type of people will be required to support your user population.
I have been doing some more research, and have answered the questions posed. As it turns out, the anti-frame dogma seems to be somewhat dated (due to improvements in the newer browsers) and apply mainly to the delivery of content (Internet-style surfing). The limitations of frames would actually seem to be advantages when developing APPLICATIONS to run on a Web server. Navigation needs to be restricted to the starting points of each application process. The Back button, Bookmarks, History, Printing, and valid URL's all represent problems to be solved in this context. Maintaining absolutely reliable state information and preventing people from jumping into the middle of a process are my biggest problems. The characteristics of frames that everyone hates so much are actually going to help solve some of them.
Does your recommendation against frames apply to Web-based applications designed for corporate intranets as well? The applications I am currently designing will replace existing client/server systems with thin-client (browser) based applications running on the web servers. My goal was to duplicate an explorer-like interface with a navigation frame of icons on the left border. Is that a bad thing? Thanks.
Slashdot Mirror
Your question is very difficult to answer as stated, since there are so many variables. The combination of the size and makeup of the specific infrastructure, installed base of applications and the degree of help required by the users is essentially unique to each environment. The only thing you can do as a general rule is to get some good software to help automate as much of the support work as possible. "Good" software is evaluated as the best possible fit for your current environment. Once you have that in place, you will be in a much better position to judge how many and what type of people will be required to support your user population.
I have been doing some more research, and have answered the questions posed. As it turns out, the anti-frame dogma seems to be somewhat dated (due to improvements in the newer browsers) and apply mainly to the delivery of content (Internet-style surfing). The limitations of frames would actually seem to be advantages when developing APPLICATIONS to run on a Web server. Navigation needs to be restricted to the starting points of each application process. The Back button, Bookmarks, History, Printing, and valid URL's all represent problems to be solved in this context. Maintaining absolutely reliable state information and preventing people from jumping into the middle of a process are my biggest problems. The characteristics of frames that everyone hates so much are actually going to help solve some of them.
Does your recommendation against frames apply to Web-based applications designed for corporate intranets as well? The applications I am currently designing will replace existing client/server systems with thin-client (browser) based applications running on the web servers. My goal was to duplicate an explorer-like interface with a navigation frame of icons on the left border. Is that a bad thing? Thanks.