dive into mark

Top 10 Mistakes in Site Planning [via milov] Let’s see how my book fares:

1. Not Knowing Your Audience – Got this one licked. I was unhappy with the built-in web site tools provided by my hosting provider, so I wrote a quick Python script to analyze my access logs and build a few useful graphs. For instance, I know that 60% of my readers use IE 5 or 6. 80% are on Windows. These percentages have been constant since forever. On an average day (not right after a release), 5% come from PyUnit; 10% come from Python.org; 20% come from Google. An increasing number are coming from Google; this reflects a larger trend of people using Google to find almost anything. I actually searched Google for “current time” and found that the Google Web Directory has an entire section devoted to it. Amazing. Anyway, when I noticed that the percentage of people coming from Google was increasing, I altered my site layout to give more context information on each page, since fewer people were coming into my site through the front door.
2. Poor Platform Compatibility – I test on Opera (my main browser), Mozilla, Netscape 4, IE5.5SP2, Lynx, iCab, and Konqueror. With the exception of those cute little callout images within my pre-formatted example text, all my HTML is completely valid, but wouldn’t you know it, those damn nonconformant images cause problems in Opera. Damn standards. And I use CSS that Netscape 4 doesn’t understand, so the site (especially the home page) looks like shit in Netscape 4, but it’s completely readable. I use no Javascript, Java, ActiveX, or VBScript, so that’s not a problem.
3. Nonconformance to UI standards – The site layout is very minimal, and very standard. Breadcrumb trails, site logo, and tagline at the top of each page; forward and back links to turn the virtual page; numbered links along the bottom to jump around within the chapter. A search box at the top right of every page. All links have titles so you can see where you’re going. This stuff is straight out of Jakob Nielsen. No frames, no DHTML, no browser-specific tags, no non-standard fonts (at least, I specify several in my CSS and always fall back on generic names like “sans serif” or “monospaced”), no fiddling with the link CSS, no Javascript-based navigation. The color scheme of the colorized source code examples is a bit nonstandard compared to other web sites, but it matches the color scheme of the dominant Python IDE on Windows, and 80% of my readers are on Windows.
4. Inconsistent look and feel – No problem there, every page of my site is generated from a single XML file through a single XSL stylesheet. Except the home page, which is generated from a slightly different XSL stylesheet that inherits all the common templates (header, footer, CSS properties) from a common base XSL stylesheet. I couldn’t be inconsistent if I tried.
5. Inaccurate or outdated content – This can be a problem, depending on what else is going on in my life. I try to update early and often, but it is usually several weeks between updates. It’s a reference site, not a news site, so that isn’t too much of a problem. Most of my readers are new, learning Python for the first time, and the older content isn’t time-sensitive (it doesn’t rot), so they go away happy. I have had some inaccuracies, occasionally glaring inaccuracies, which I fix as quickly as possible once someone points them out to me.
6. Poor Scope of Content – Hey, it’s a niche site. If you want Python news, go elsewhere. If you want code, go elsewhere. It is what it is: a training book on Python. I have links to other such sites, even to alternate training books if mine doesn’t work for you.
7. Pages That Load Slowly – I’ve worked hard on this one. The book is split up into sections, each section being 1 or 2 screenfuls on average. The overhead for the header and footer is minimal. There are no graphics except a few small callout images, which are reused from page to page. Every page links to the same external CSS stylesheet. If you want, you can download the entire book, compressed, in a variety of formats (PDF, Word, WinHelp, plain text).
8. Hard to Maintain – I have written scripts that automate the building and publishing of the entire site and all the downloadable formats. However, the source is difficult to work with (it’s Docbook XML, a very complex DTD). It’s definitely not for the faint of heart; several potential translators have shied away because they are overwhelmed by the unfamiliarity of the XML. However, this daunting nature is what makes possible the downloadable formats, and, ultimately, the site itself. In this case, the content itself is more important than the maintainability of the site. I realize that most sites have different priorities.
9. Weak Security – I’m really at the mercy of my hosting provider for this one. The site is hosted on Apache; the server is running a variety of popular server-side plugins, including PHP, mod_perl, and MySQL. The last time I checked, they were current on all of these. They seem to know what they’re doing, but it’s really outside my control.
10. Bad Advertising Strategy – I got myself on Python.org early on, and that still accounts for 10% of my traffic on any given day. I also got myself into the Open Directory, which is where the Google Web Directory gets its links. Since Google gives higher ranking to sites listed in the Open Directory, and also higher ranking to sites linked from popular sites in their community, I usually rank fairly high. That, and the site does actually have content, lots of it, in a well-structured and organized fashion with no bullshit or spider-fooling tricks. Google likes that. It’s good when Google likes you. I can’t emphasize this enough: the best advertising strategy on the web today is to get Google to like you.

So that’s it. Mostly good (I think), some with some room for improvement. 20% of my readers still use Netscape 4, but my latest site redesign made the site look worse for them (but better for people with newer, standards-compliant browsers). I had a run of broken links for a while (including two on my home page!) because I wasn’t checking my site statistics as often as I should have. Always, always, always keep on top of your site statistics after a major redesign. And since I republish every page on my site whenever I release a new version, every release is potentially a major redesign. Site consistency is nice, but it also means that errors propogate more widely. Automation is nice, but it also means that errors propogate more quickly. Does that mean that I’d be willing to go back to hand-coding each HTML page? Not on your life.

§

Respond privately

I am no longer accepting public comments on this post, but you can use this form to contact me privately. (Your message will not be published.)

§