There are some inamidst.com design principles that I haven't yet expounded, so I'll take some notes here even though I should probably be using the homepage:
Organize it well!
I make sure as much as possible that the URIs I choose are going to be agreeable in N years time, based on experience from the previous N years. It still doesn't work quite as I'd like it too because I'm still learning, and this site is unlike anything else I've done before in many ways.
For example, I sadly just moved three scripts out of /misc/ and into /svc/ since I'm starting to want to build up a catalogue of services. The problem is that when you deploy a particular service, you're not sure just how important you and other people are going to find it; and one of the most important design principles for choosing a URI is that the more important the resource is, the shorter the URI you choose for it. So it's a bit of a catch-22 situation.
Another point is that you should try to group related stuff in a directory if there's enough of it... but how do you know how much more stuff you're going to make along those lines?
Link small tools together!
This is basically the Linux philosophy: you take lots of small tools, and you make them work properly. To that extent, I have /inside/ which (somewhat like "cat") shows the contents of the files that're passed to it as an argument, /tgz/ (somewhat like "tar -zxvf") which untargzips files passed to it as an argument, and so on.
I also try to separate all the styles into /trove/ in order to promote reusability. So the main benefits here are modularity and ease of reuse. Christopher also notes that big monolithic applications cause drak corners; funny since that term came to us through the gawk manual.
Keep it svelte!
Though clutter is inherent to the mechanism, I try to keep the site as tidy as possible. Keeping it tidy means a few things:
- a) Making sure that my local static copy(ies) are kept free of junk, and synced carefully with the vorpal site.
- b) Making sure that all of the site styles are cleanly designed, and that the HTML used is all nice and tidy etc. (I try to do this automatically anyway).
- c) Checking for any loose ends, and todos. I wrote /misc/todo to try to keep track of the issues that I flag around the site.
Expose as much as possible!
The whole point of a website is to provide information publically, whether for yourself or your friends or other people, so it's important to make sure that it's accessible. One of the ways in which I attempt to achieve this is by making sure that people can simply get to bits that they need: this means making sure that as many pages are linked as possible, and that all of these links are relevant.
Though I've already mentioned it, the /tgz/ tool is a good example of this: it allows people to look through .tar.gz files without having to download them first, and also means that they can give them URIs etc. Another pertinent point is that all of my services allow the use of GET wherever appropriate, so that the pages can be bookmarked and so forth (this again, and in fact all of these points, is a matter of good design).
I'm also planning on adding a service that'll give a nice zebra-striped iTunesy representation of all of the files in the site, rather like "ls" only presently nicely; though XHTML should be the default output, allowing an RDF representation (more parsability) and plain text lists of URIs (for scraping etc.) would also be good. All of these site services are managed carefully so that they obey my own robots.txt file, which gives me more granular control over what they do. It has turned out, though, e.g. in the case of /misc/todo, that I'll probably need more granularity (there the problem is that I need it to ingore the issues in the archived RSS 1.1 files).
Track the metadata!
The recent changes page, /misc/updates, again another bastilon of exporting as much data from the site as possible, makes use of the inherent metadata of the site—namely last-modified dates. But the /misc/ index itself actually makes use of another file where it can wherein I list some of the site titles and so forth. This /eph/ site, and some other services, also makes use of extracting the titles of pages, so it makes it more likely that I'm not going to overlook badly titled pages, which in turn increases their findability via Google and other search engines.
That's about it of the general principles, but it would be easy to expand more on each of them, especially if I were to compare with other sites that I've done, and those of AaronSw etc.