 |
Dan Bricklin's Web Site: www.bricklin.com
|
|
Back to:
|
Web Authoring and Storage Location
Web site authoring has been proven to be one of those places where the general populace has shown they would rather let others provide a service and hold their data.
|
After reading my Web Services, Business Models, and Storage essay, some people have asked me: "Does this mean you don't believe in the server-based authoring and web hosting that Trellix Corporation sells?" The answer is "Of course not!" In fact, it makes an interesting case for analyzing a particular type of ASP offering.
I addressed the issue of where to do web authoring, client-side or server-side, in "Server vs. Client Authoring". I ended by extolling the virtues of site-oriented tools over page-oriented ones for "real" web sites. When it came to client-based or server-based, though, I explained that there were advantages and disadvantages to both and that both types of tools were necessary.
When it comes to the type of web sites produced with Trellix's main system today, though, I can go into greater detail about the advantages to server-side authoring. Trellix's product is called "Trellix Web Express" (TWE), and it lets the user author and maintain a web site using a browser. The user feels like they are editing a copy of their actual web site, but in actuality they are editing an XML description of their web site stored on the server. When they press "Publish" the HTML for the site is produced and stored on a regular page server for serving to visitors. In some cases Trellix also provides the servers and software for doing all this (including page serving). In all cases, the TWE system is customized and integrated into the hosting environment.
First, let's look at web serving itself. Web serving is inherently a service. Whether you do it "yourself" or have it done for you, there is constant maintenance required to keep the server hardware and software running and up to date. The connection to the Internet is a service that is paid for like a service -- in ongoing fees for performance. Associated with the web serving, there are often other "services", such as usage statistics, form-submission handers, credit card handling engines, and catalog databases. These have ongoing real costs and are naturally a service.
The actual storage of the pages that are served are also naturally on the server. That's how web servers work.
For the authoring population served by TWE, it makes the most sense to have all of this serving done outside of the user's system. The small businesses and individuals have no interest in maintaining a server (doing all the backups and security patches) and ensuring 7x24 uptime of their Internet connection. As I pointed out in my "Small Business and Web Sites" essay, the price of the service is a minor expense for most of them.
This makes sense in many ways, because to a small business, a web site is like an ad in the Yellow Pages or a 800-number telephone line. They are used to producing such marketing material and having it work for them as long as they continue to pay the service fees.
The only question is where should authoring be done. Looking at history, it's clear that a large percentage of people would rather do their authoring using a browser. The problems of downloading and/or installing software with its own unique interface for something they may only do once or infrequently are too great. Many of us techies found this hard to comprehend, but that's the way it really is. Even in the somewhat techie world of weblogging, server-based products like Blogger and Manila are quite popular, probably more so than client-side editing. When it comes to web sites like those created with TWE, with heavy use of templates and wizard-like creation, a browser-based tool is quite appropriate. For authors who are willing to take the time to install and learn some of the more professional tools (a smaller segment of the population it seems) client-side authoring tools can and do work fine. That's why most TWE installations give you the option of using those tools, too, if you'd like. Some Blogger users mix Blogger-produced pages with other pages produced using other, often client-side, editing tools, too.
One issue with web authoring is the ability to make changes to the entire site at once before posting the updates. Many early, page-oriented server-based tools didn't let you do this. TWE does. The web site visitors see isn't updated until you press the "Publish" button, no matter how many pages you change. Until then, though, you can see how it would look in both an authoring and a cleaner preview mode.
In the case of web sites that make use of special services connected to their server, such as forms-submission handlers, the author must have special knowledge of the particular hosting platform they are using. When the authoring is integrated with the hosting, such as with TWE, this can be done very naturally and be successfully used by relatively inexperienced authors. You just choose the functionality you want from a gallery and add it to your web site like clip art. When such functionality must be integrated into the web site with a general purpose client-side tool, though, the author is usually forced to find and understand more esoteric instructions. (They range from the user-unfriendly "Paste this in exactly to your HTML" to "modify the HREF tag to..." to "after uploading a control file in the following format, use a FORM to POST with the following hidden fields..." to "modify the following CGI script" or worse.) Given the population TWE is aimed at, there isn't much choice. The problems with installing and learning to use a client-side system completely cut off large parts of the potential audience. Even if you pay someone to do it for you to start, if you ever want to modify it yourself it helps to be in an integrated browser-based tool.
Another issue with server-based editing is that you must be connected to the Internet while editing, while with most client-side editing you do not. When you start integrating various services into the web site, though, even the client-side systems need to be online to allow you to access the integration information (e.g., query for the "magic URL" or other code to paste) and for previewing (e.g., "Does the button really bring up a map to our correct location? Do I need to add explanatory text?").
The only question left is does the author feel that TWE keeps something they "own" away from them inappropriately. I don't think so. Most of the web sites we are talking about are quite small, just a few or a dozen pages or so. The actual writing of any large amounts of text is probably done in a word processor first and then pasted into the browser fields. Any proprietary pictures are similarly created on the PC and then uploaded. In fact, much of the text and most of the decorative images start out as part of the templates proposed by TWE. If you want to switch tools, the final product, HTML pages, are easily downloaded to any professional web authoring tool, or copied piece by piece into other authoring systems. Finally, the type of web sites created this way are either pretty much left alone after they are created (like a brochure or essay), with only minor changes, or are completely replaced by new material periodically. Putting your material into TWE is like "publishing" it, a feeling of sending it on to the reader. All in all, the switching costs are pretty minor since all of the "data" appears right in front of you on the web site itself. The main thing you want to "keep" is the ownership of the domain name, which most hosters let you do.
This is not the same as a transaction processing system, which may have the private ordering and shipping information of thousands of non-current customers where you might feel helpless if the data was locked up on a server that you must pay for every month thereafter in case of an audit. Web site authoring has been proven to be one of those places where the general populace has shown they would rather let others provide a service and hold their data.
|
|
© Copyright 1999-2010 by Daniel Bricklin
All Rights Reserved.
|