2008-06-17
A simple request for vendor websites
Dear vendor websites, I have a simple request for you, or more specifically for your search people: there should be a search box where I can plug in either a product name or a part number, and the first thing that comes up should be that product's or part's webpage. This should work even for parts that you don't normally sell separately, and it definitely should work for the product codes that you put on your boxes. In specific, I should be able to take a mysterious box from you (perhaps containing rack rails), punch its cryptic code into your website, and find out exactly what it is and what it goes with.
(I do not mind if this is an advanced search option, just as long as there is an obvious path to it from basic search. But it really should be part of your basic search, because it's not going to be often that people enter a product name or part number and want something other than the product's page.)
Doing this sort of a smart search engine is one of the few ways that you can do a better job of search than Google can, because you have domain specific knowledge. Conversely, if you cannot manage to do this you might as well outsource your entire website searching to Google anyways, because your search technology and your search interface are both likely to be worse.
(If you must override Google's results for specific queries, there are ways to do that while still using Google for most everything. But if you are overriding queries to start with, you can perfectly well do this too.)
Unfortunately I do not expect the current depressingly bad situation with vendor website search to get better any time soon; vendors that actually do a good job of this are, to put it one way, extremely uncommon.
(This entry is brought to you in part by the fact that we turn out to have quite a lot of female to female DB9 null modem cables, because Sun gives you one with each X2100 M2. They just don't tell you what the cryptic connector is, so in the end I had to use a pair of paperclips and a multimeter to find out.)
2008-06-07
Why 'file as blog entry' blog engines have problems
One enduringly popular model for blogging engines is that entries will be files in the filesystem, and the blog engine will just wrap them up in various simple ways. This approach has a clear and attractive simplicity and thus an obvious appeal, but as I have found out from following this route myself this simplicity hides a number of subtle problems.
All of the problems can be summarized in one word: metadata. Blog entries have (or need) quite a lot of of metadata associated with them, and making files your entries does not give you very many good places to put this metadata:
- you can infer the metadata from things surrounding the file itself;
for example, you can infer the entry's publication date from the
file's last modification time.
There are two problems with this: first, this doesn't cover all of the metadata you need, and second, this creates awkward problems when the blog engine's use of file metadata clashes with things you want to do with the file, such as updating an entry without changing its publication date.
- you can embed the metadata in the file itself, but this clutters up
the file contents and makes authoring more annoying.
(If you go this route, I suggest putting the metadata at the end of the file, not the start, so that it is at least less obtrusive.)
- you can have your blog engine invent or learn the necessary metadata
the first time it sees a new entry and record it somewhere else
so that it's stable.
The problem here is that you've effectively created a database (or you're using a real one), with all of the associated management issues, but things are half in the database and half outside for extra fun.
One popular additional non-answer is that you can decide to ignore the need for certain sorts of metadata; however, this will limit what your blog engine can do and periodically cause explosions.
(Ironically, a stable master identifier for entries is one of the easier things to arrange; if the filename is otherwise meaningless, and it probably is since you can't really use it as the entry title, you can just use it for the master identifier. Of course this will give you a blog directory full of peculiarly named things that you can never rename, but that's life without metadata.)