Friday 29 January 2010

My Website Sucks

The result of adding haphazardly to a system, illustrated with a stack of mains power adaptors. Don't try this at home.
I know why it sucks ... it's not because I don't know how to write a proper website ... I do ... it's because it's a personal site, and I kinda tinker with it and add things from time to time, and experiment ... and because I've been using HTML for too long.

I was designing the site for someone else, I'd be less indulgent and more brutal with it. I'd insist that the owners had a clear brief of exactly what they wanted the site to do, and how to judge success. It'd be focused and lean and mean. I'd decide a visual theme, and a hierarchy, and apply it strictly. But when it's your own site, the tendency is to drift and add things and sections and use the pages as a sandbox for playing with different techniques until you end up with an indulgent hodge-podge of themes and style ideas that don't really gel.

If it was someone else's site, I'd tell them to delete the whole thing and start again. Don't just fiddle with the layout, start with a blank sheet of paper and a pen, doodle a brand new layout based on CSS, set up some default templates and rebuild the site from the ground up.



When you drift and add bits and pieces haphazardly, you end up slipping into old habits. I started writing webpages before we even had html tables. My first site (Erk's Relativity Pages) was a 300-page monster written entirely in Windows Notepad, and back then, a site designer had to learn all sorts of odd layout tricks (like using invisible GIFs as spacers) to produce efficient layouts. When tables were implemented by Netscape (and then by MS), we redesigned our pages to suit, with nice orderly auto-resizing panels – they were a pain to begin with, but the quirks and incompatibilities smoothed out with time, and we ended up using them everywhere. Tables became the answer to everything, from navigation panels to equation-setting. Then there was a craze for breaking a page up into sections and writing those sections as separate webpages embedded in frames. I managed to avoid that one (since I could see the long-term search-engine problems), but for a few years, using frames everywhere was supposed to be the mark of a "pro" designer. And then a couple of years later, the importance of search-engine optimisation became obvious, the fashion swung into reverse, and any frame-based sites began to look terribly dated.

Back in the 1980's and 1990's, the way to produce a flashy (but legible) site was to use a dark background with light text. The old CRT monitors tended to be strongly curved, with a display area that didn't extend quite to the edges, so a dark background made your page appear larger. With low-res CRT displays, "inverted" light-on-dark text was often easier to read, because the the outward blurring of light from the letters produced a sort of natural antialiasing effect. With dark text on pale backgrounds, the surrounding light tended to bleed over the characters, making them more difficult to read. Adding background patterning made the pages look more exciting, made the screen defects less distracting, and helped the user forget that they were staring at a fairly nasty little computer screen.

In 2010, things have flipped. Legibility isn't a problem on modern LCD displays, and because the screens are now flat, stark white rectangles actually look good. The monitor glass is thinner, so "snow blindness" due to light-scattering from large bright areas isn't so much of a problem, and you no longer need to add a faint background texture to pale or white backgrounds to disguise the "bitty" red, green and blue phosphor dots of a low-res CRT screen.

Nowadays, we practically squander space. On large screens, we use column layouts that waste most of the screen display, so that the central vertical column corresponds to what the user sees if they try to view the site from an iPhone. The web in the 1980s was content-starved, and you'd try to impress visitors with how much you had on your site and how much you could cram onto a small screen. In 2010 the visitor is spoilt for choice, so now designers try to keep things minimal and direct their visitors as quickly as possible to the information they actually want, otherwise they'll just click back to Google and try somewhere else.

After tables and frames, we now have Cascading Style Sheets. CSS is genuinely cool, and I really ought to rip up the existing pages and redo all their elderly table-based layout completely using CSS. Trouble is, it'll require a certain amount of work, and the immediate result will be that certain existing things (like same-height panels) won't work so well. There are bodges and workarounds, CSS isn't quite perfect yet.

The site's "look" also badly needs an overhaul. It was originally going to just be a few pages supporting the book, with a navy blue block across the top and down the left side referring to the book cover art (front and spine). On the subsequent pages, that morphed into a "program window" theme, with a title bar and an icon in the top left corner. I never quite worked out what to do with the spine. It's now an inconsistent mess, with pages on almost unrelated subjects like fractals, and should really be torn down and rebuilt.


Relativity theory is in a similar mess. A number of themes have come and gone, and left their mark on the subject. There are artefacts and traditions in the way that theory is presented that don't really make sense in the new context, and older methods that aren't compatible with newer principles. We teach special relativity as having destroyed aether theory, but we still teach SR using the length-contraction idea, which was an old aether theory concept borrowed from Lorentzian electrodynamics.

In theoretical physics, we probably have a feeling deep down that we know that we really ought to be tearing up the current system and starting again. But it'd require a lot of work without an immediate payoff, and some of the things we currently do would stop working for a while as the new system found its feet. The current system is bodgy and patched and held together with string and duct tape, but we know how to use it, and over time the bugs and fudges have started to feel like old friends. We invested a lot of time in special relativity (like website designers spent a lot of time learning the quirks of HTML tables), and now that we know that system, we tend to use it everywhere. With special relativity, we've gone further and actually redefined some key parts of relativity theory in such a way as to make SR inevitable and unavoidable, and this lock-in frees us from having to make awkward upgrade decisions.

So while it may seem that I'm sometimes a bit harsh on the theoretical physics community for being welded to obsolete and archaic systems that don't really make sense in the C21st, I do actually sympathise and empathise with their problem. They ought to rip up their SR-based structure and redesign, just as I ought to rip up my table-based webpage layout and redesign. But there's a difference between knowing that you ought to do something, and actually rolling up your sleeves and starting work, especially when there's no external deadline forcing your hand, and you always seem to have other more pressing things demanding your time.

So to help the theoretical physics community, here's a time-point. The book came out in late 2007, and sketches out the principles and the rough shape of the suggested next-generation replacement for our current general theory of relativity. This is early 2010, and the book's now been out for two years. That book is the roadmap to what comes next. So perhaps we can have a concerted start on plotting out at least a rough preliminary schedule for a replacement to general relativity, some time in 2010?

Meanwhile, I'll try to think of a way of cleaning up the website.

No comments: