Forum Moderators: phranque
It seems strange to me. For traditional software, the newly opened error of every day should decrease as the software become stable. Actually the website I concern was relatively stable during the studied period.
As I find that every day during the month there is new errors arise. I just wonder if this can be explained as the website is maintained or changed every day that cause the new errors?
Also a large portion of the errors keeps fail until the end of the observation period. Does this mean that the errors was not fixed at all?
There do have a small amount of errors that stopped to fail latterly, I think there should be one reason, one is that the errors were fixed the other one is that people just stopped to visit the specific pages.
Upon this, I think there is a big difference in the maintenance of website as compared with that of traditional software. But how different it is? Personally I¡¯m not a webmaster or developer. I don¡¯t know much about the actual development and maintenance process of website. I¡¯m just curious about that when I reach above questions. Would you guys please share your experience?
"/sumthin"
"default.ida" (code red virus?)
"command.com", "win.exe", and similar exploit-attempts (hello, it's a Linux box!)
Since then, I've added zero-byte default.ida and various windows-exploit files, made one of the world's most annoying pages, with javascript, flashing text, the world for mydomain.com/sumthin/index.html, and am always very careful to check, double check, and check again my HTML before putting it online.
The vast majority of errors I get these days are proxy attempts, and usually misconfigured attempts at that.
I'm sure it's harder for folks with ASP, PHP, lots of cgi scripts, and what-not...
As you said, maybe maintenance is not a big problem for small size website.
I just learned that in software engineering, there is a subject about maintenance and configuration management. They proposed some procedure about change in software to protect the quality of system from the bad impact of changes.
Compared with general software, website is changed more frequently.I think for big website, when there is a large number of pages and they refer to each other, its likely that change of some pages will impact other pages as well. And if the website is maintainted by several persons, the situation may be even worse.
In those cases, maybe maintenance is a big problem to deal with. I'm not sure if this problem for website is addressed with similar methods as for general software or different methods are used due to the different peroperties of website.
If you decide a page is to become unavailable, and the content of that page is generated from a database, rather than deleting the database entry and effectively, the page, it's better to have a boolean "Disabled" variable set to 0 by default (some prefer "Active", but it's easier to check for "Disabled" where you DONT want the file than "Active" where you DO want the file). Then, on pages where a disabled database entry is encountered, you can tell users that the page is no longer available (and perhaps by using the database information you've stored, redirect them to an appropriate resource or listing).
I recommend storing all your information in a database for any site that plans to be more than 50 pages. It will save you headaches in the long run and allow you to do some pretty amazing stuff.
For sites that are purely HTML based, fixing errors can just be a headache after another. There are some good software suites out there (e.g., Macromedia Homesite 5/Dreamweaver MX) that will find broken links in a web for you, but I recommend following the same kinds of principles that you would with a dynamic site. When you decide to delete a page, rather than deleting it outright, rewrite it so it says the page was removed, and point to other appropriate pages on the site. This way, you lose no traffic going to your site, and still provide relevant resources for your users.
I never recommend doing a straight Server-Side or META redirect for two reasons:
1. You're not presenting users with the information they planned to see (and not offering any explanation for why). Basic user-friendliness. This also benefits you because, if you tell a user where they can go to get more information, they will still see you as a relevant resource.
2. Search engines don't like it.
If you're getting search engine traffic to a page that has been removed, then that page is relevant to a particular keyword phrase. If you find out what that is, then you can link FROM that page TO other pages on your site that you feel will be equally relevant, and thus increase their rankings (hopefully the search engines will update so your other, content-filled pages will get ranked instead of the now-defunct one).
Of course, there are different routes you could take for any particular site, it all depends on the project.
The real difficult situation arises when you're redoing an entire site.
The HTML book I taught myself from was, well, let's just say it might have some collectible value. It covered HTML, you know? Not HTML 4, or 4.01, or 4.01 Transitional, or whatever. So I had no clue that something like a third of all the HTML tags I was using were "deprecated". :)
Fortunately, I still only had a single, twenty-five page site, but, yowza, fixing each page to validate as 4.01 Transitional was not something I ever want again.
Ranked better after the next update, though.
You do have to plan ahead, though. One of my sites uses a sort of "hub" layout, where every page has links at the top to several main "theme" pages, and those pages each lead to several different, narrowly-focussed pages, plus the home page and contact page. "If you'd like organic widgets, click here. To see our selection of recycled, nonbiodegradable widgets, click here. For unique, one-of-a-kind...". I think it makes navigation, for the human visitor, very easy. However, I planned this in advance, and know that if I ever add another broad category of service, it's eithe going to have to go under an existing category, or I'm going to have a long weekend changing /every/ page. :)
Here I get a general idea about the maintenance of website.
It depends on the size of your website, the focus of your website...and depends on the person who maintain this website.
Compare with general software, website is still in its early age. I think we can learn a lot from the way the general software was developed and how it become more mature.
Actually, as in above posts, some efficient techniques or schemes for maintenance of website are already adopted, such as using database to store information, plan ahead...
With the cumulation of those skills and shcemes, we can gradually improve the quality and the productivity in website development. Then some general rules of design, development and maintenance can be established.I think this is the way software grows. So it seems we still have lot of things to do in this field.
Thanks again for all your reply!
