WEB SITE MANAGEMENT AND ADMINISTRATION
It doesn't have to be
expensive.
audio file for the visually impaired (sorry, not yet uploaded.)
WEB SITE MANAGEMENT AND ADMINISTRATION
It doesn't have to be expensive.audio file for the visually impaired (sorry, not yet uploaded.)
To the uninitiated, managing and administering a web site sounds like an intimidating project. Well, it can be if you don't know what you're doing, or, if the site depends upon extensive updates requiring massive reorganization and data entry. But most sites are relatively simple to administer, especially if they are well-planned in the pre-design stage. ...Until and unless things go wrong, of course. But then cyber-reality is such that one's brain convinces itself that the pit of Hell you have been dropped within is all only a very bad nightmare, that it isn't real, and therefore isn't really happening.
Managing input from a website - that is, doing the day to day work of interacting with input and requests from site visitors is a bit more time consuming. Fortunately, that set of duties is not the job of the site administrator (whew!)...unless he or she happens to be the site owner as well and doesn't have any "pygmies" (employee(s), brow-beaten family member(s), or slave(s)) to do it for them.
We don't charge a lot to administer most sites - anywhere from a monthly fee of $50.00 to $150.00 (US funds) is usual, especially if we build the sites. (If we don't build them, there is an up-front fee for the time and potential headaches of acquainting ourselves with someone else's ideas of good site organization and program configuration.)
There are exceptions to that however: sites using shopping carts or databases are our bain. We hate them with a passion because they are riddled with potential security holes and because they require labor intensive data entry "fixes." And we are not a data entry service. Good shopping carts and data base programs* which we will consider administering usually have an http side data entry option where the site owner and/or his or her "pygmies" can do all the data entry (and sometimes even the file uploads) themselves. So what need is there for us in such case? ...Maybe only to configure the creature, which can sometimes be an arduous task.
Those wishing more information, please feel welcome to E-MAIL us at
close this popup window to return to the table of contects
| * Good (extreme
emphasis on the word "good," please)
shopping cart and database programs require that the
host's (in house or remote) technical team
install them on server before we can begin to configure
them. Why? Because it requires root access to the server
itself. So unless you own your own server and have your
own expert (hire some good hackers) technical
team (sysops) who know EXACTLY how to ensure
that SECURITY is absolute (no holes to admit criminal
opportunists or mischievious "crackers"),
the remote host has to support that shopping cart or
database program. If you own the program you want to use
and have license to use it on the Internet, the server's
technical team must, at least, install it on the server
before it can be used (that old root access thing
again). Some good database/shopping cart programs
require a special server. ORACLE and FILE MAKER PRO are
examples. MINIVEND which runs on many platforms is a very
good option, but, again, because of security issues (which
can only be addressed by the in-house sysop team),
MINIVEND should be uploaded to server by the technical
team. (We have uploaded it successfully to remote
hosts, but it is not something we have enjoyed, and we
won't do it again until Hell freezes...and then we're not
sure.) Why all the fuss? Because one of the biggest issues on the net is the problem of security. Shopping cart and database programs are notoriously prone to security holes. (Yes, even the good ones, or ones run by companies you think have an absolutely safe system are usually full of security holes.) The majority of such programs can easily be cracked by a skilled ...and sometimes a not-so-skilled hacker. Unless one knows both the specific program and the platform implicitly (note the use of the word "and" here), security breaches are probably a sure bet. ...And even the best technical team can have their system "cracked." So, we won't play. It is this simple: We will not manage or administer any system where the host isn't responsible for security (and the results of security breaches) or where the host is lax on their security. In other words, we won't put our name on the line as webmaster on any system where we wind up being responsible for the results of a "crack," where we don't have complete control of the system (impossible because we don't run host servers, thank heavens) or where we don't have complete trust in the individuals responsible (the "sysops" / technical team) for making sure the system is "crack-proof." |
close this popup window to return to the table of contects
zentao.com