The desktop metaphor is stupid

My girlfriend is showing me images on her computer (she uses an Apple because it’s “simple”). After we view all of the files, which are scattered across her computer’s desktop in a random pattern, I watch as she grabs one with the mouse and drags it onto the corner of the desktop. She then drags one file after another onto the same spot, making a pile. Later, she’ll move them one by one out of that pile in order to look at them again.

Pretty much every window manager uses the desktop metaphor of overlapping documents in a messy pile. The desktop metaphor was a dumb idea when it was introduced, and it’s still a dumb idea now. Computers allow us to interact with documents in much richer, more powerful ways than pretending that they’re a mess of overlapping papers on our desk.

Why do we allow icons and windows to overlap? Why would anything ever overlap? It’s a useless functionality. When one window is overlapped partially by another, it’s usually the case that enough content is hidden by the overlap that it makes the visible content useless and just wasting screen space; you can read half a sentence, but the other half is hidden behind the focused window. You have to switch back to the partially-covered window anyway in order to continue using it, so why not just keep it entirely hidden?

We know that this is suboptimal, yet we continue to use it. The computer interface should maximize the usefulness of the information it presents to us. Windows should try to take up as much screen space as they can without infringing on other windows. Don’t overlap the windows, but try not to leave any wasted space, either.

Is this a blog or what?

I have more than 100 entries on Google Docs and hundreds of text files, self-emails, and pieces of scrap paper floating around my life, many of which contain ideas, thoughts, or potential projects that I’d like others to see. So I’m trying hard to get some in good enough shape that I can post them here.

Several people have sent me emails about other parts of my site, which I should migrate to here so they can post such things publicly, and I can respond here as well and everyone can bounce ideas off each other.

WordPress puts everything in chronological order like a stupid blog, which is not what I had in mind for this site. I’d rather organize the “articles” by hierarchical tags/categories and update them over time, reply to visitors’ comments, and so on. I installed the Audit Trail plugin for WordPress so my changes to posts are internally archived to prevent loss of information, and I’m installing other plugins to try to get the desired effect. I guess I should just install a wiki or something.

But until then, I really should post things that I can direct people to. Somewhere, anywhere.

Keeping windows on-screen

Another problem with the desktop metaphor: In every window manager I’ve ever used, if you move a window out of the way, there’s a tendency to move part of it off the screen. This is fine sometimes, but if you are moving it out of the way so you can still look at it, while also looking at another window (and wouldn’t you just minimize it otherwise?), this has all the same problems as overlapping windows.

For instance, if you take a window in any normal window manager:

|                         |
| .==============.        |
| |             ^|        |
| |             ||        |
| |             ||        |
| |             v|        |
| '--------------'        |
|                         |

and drag it off the screen, a lot is now hidden from view, including the scroll bars:

|                         |
|                         |
|                         |
|                         |
|                .========|:::::.
|                |        |    ^:
|                |        |    ::
|                |        |    ::
'-------------------------'    v:

Everything off-screen is now unreadable, and you can’t even scroll to access it.

It would be great if, when you move a window off the screen, the window would “smoosh” up against the edges of the screen, dynamically shrinking or increasing in size as you move towards or away from the edge, to keep everything visible.

In this case the bottom and right borders stop at the edge of the screen and the window resizes dynamically:

|                         |
|                         |
|                         |
|                         |
|                .=======.|
|                |      ^||
|                |      v||
|                '-------'|

Then all the content in the moved window is still accessible by text wrapping and/or scrolling.

Normally, when you maximize a window to fill the whole screen, it “remembers” the previous size and position, allowing you to restore it to its original size.

Similarly, when a window is “smooshed” like this against the edges of the screen, it will remember how big the window originally was. When you drag the window back towards the center of the screen with the title bar, it will “re-inflate” to its original size.

|                         |
|      .==============.   |
|      |             ^|   |
|      |             ||   |
|      |             ||   |
|      |             v|   |
|      '--------------'   |
|                         |

But this means that when the window is smooshed, the borders at the edges of the screen aren’t the same as normal borders. They should then be shown in a different style from normal borders, to differentiate them and remind the user that the window still remembers its previous state. If you resize the window inwards using these borders, it will forget the previous state and remain at the current size forever. The borders of the window will then revert to normal functionality. You could also force the window to forget its previous size just by clicking them, perhaps.

I’d say that all windows should do this by default — when would you ever want part of the window to be non-visible? — but there might be important reasons not to for some types of windows, like a program that really loads down the processor during window resize, or a window that can’t be shrunk below a certain size. Maybe the window manager could just add scroll bars in situations like this, when the window has been squished to its smallest size, which would still enable you to scroll around the window (including menu bars or whatever), though without the benefits of word wrapping, etc.

Joining window borders

When windows are tiled, each window continues to have the usual resizable borders; if you shrink one, the other stays untouched. But if edges and corners of windows can be snapped to each other, why can’t two such snapped edges be moved at once? The border that is shared between two windows should behave more like the “split” view you get in applications that let you view two parts of a single document at once.

Say you select two windows and you move them so they tile the screen horizontally; one is on the left half of the screen and one is on the right half:

|              |              |
|              |              |
|              |              |
|              |              |
|              |              |

Normally, the border in the middle, where the two windows meet (and have snapped to each other), consists of two independent resize handles that happen to be touching each other. If you want to make one window smaller and the other larger, it takes two operations. What should happen is that the borders should “fuse”, forming a split handle between them.

The individual window resize borders would still be present, with differentiation by the cursor changing when you hover over each, as is normally done to find the resize handles. So as you move the cursor from left to right, it starts as a regular arrow, changes to a resize cursor for the left window, then a split cursor for both windows, then a resize cursor for the right window, and then back to a regular arrow inside the right window.

Closeup of joint border between two windows (a few pixels wide):

Inside | Resize     | Resize  | Resize    | Inside
left   | right-hand | both    | left-hand | right
window | border of  | windows | border of | window
       | L window   | at once | R window  |

If you move the split line to the left, the left window shrinks while the right window grows, so they are always using up the entire screen.

|         |                   |
|         |                   |
|         |                   |
|         |                   |
|         |                   |

This could also work for corners, letting you drag both windows’ corners at once:

         | |
         | |
         | |

In fact, such a split line could form any time two windows have adjacent (snapped) edges, even if they’re not filling up the entire screen. This:

.---------.                   |
|         |                   |
|         |                   |
|         |                   |
|         '-------------------'

could be changed to this:

.--------------.              |
|              |              |
|              |              |
|              |              |
|              '--------------'

with one click and drag.

Resizing windows

If you double-click on a window resizer handle (either on the sides or the corners), it should do something helpful like “maximizing” in only one direction; expanding the edge or corner all the way to the edge of the screen, in the same way that double-clicking the title bar maximizes all four borders to the edge of the screen. (Maybe it or a similar function could also be used to maximize to the nearest window border without overlapping?) KDE has some intermediate options:

  • Left-click the Maximize button
    • The window maximizes to the entire screen
  • Middle-click the Maximize button
    • The window maximizes in the vertical direction, but stays the same width
  • Right-click the Maximize button
    • The window maximizes in the horizontal direction, but stays the same width

Although this functionality is useful, I think this is pretty unintuitive. Which button does which? Do people use this often enough that it should use up the default functions of all three mouse buttons?

Also, why not have windows snap to a coarse grid instead of just to the screen edges and each other? Is there any reason that windows have to be resizable down to the single pixel? This is very rarely necessary.

I’ve been using allSnap in Windows, which allows snapping to other window borders and coarse things like grids and half-way marks. It makes resizing and moving windows much quicker. You can always press Alt or Shift while dragging to override the snapping for the few instances you need it, just like you currently do in GNOME.

Electric violin

I made an electric violin. Here are some details for people who might want to build their own.


Photograph of a homemade electric violin

The body was mostly made by my father as a high school graduation present. It is made of one piece of black walnut up the middle, with separate pieces of walnut glued on for the “wings”. The lighter wood on the top and bottom is bird’s eye maple, in five slats per side, also glued. The only finish on it is Tung oil.


Photograph of pickups made from piezo elements and washers

The pickups and electronics are my half of the project. The pickups are industrial pressure-sensitive piezo washers. They’re meant to be mounted under machinery to measure pressure and vibration, probably with a bolt through the middle. Instead, I have them mounted under the bridge to measure vibration.

As these were given to me third- or fourth-hand, I don’t know where to get them.  Google search for “piezoelectric ring sensor” or “piezo ring transducer” should find something.  Here is a company that sells small quantities.  I haven’t tried them or anything, but people keep asking where to get them.  If you try them and they work for you, leave a comment.  You can also check eBay for odd parts like this.

I wouldn’t recommend the popular piezo buzzer type elements often used as “contact microphones”, since those are thin and designed to produce sound by bending.  They aren’t designed to have things crushing them, and can be easily cracked.

To mount the pickups, two holes were drilled in the top of the violin, the same diameter as the piezos but about 3 times as deep. (Very professionally drawn MS Paint diagram.) A metal disc and a metal washer were made to the same dimensions as the pickup. The metal washer goes in first, with a wire soldered to it. The piezo sits on top of this, and then the metal disc sits on top of that, with the other contact wire traveling up through the middle of the washer and piezo and soldered to the middle of the disc. (Here is another quality diagram of the assembly.) This way a good, flush, mechanical connection is maintained to the top of the pickups, reliable electrical contact is made to both sides of the piezo, and the only thing visible from the outside is a nice sandblasted metal disc. (Here is a high-res closeup of the assembled bridge and pickups.) I was worried that the metal disc might not be the best transmitter of sound, but it has worked pretty well. Originally I was using tiny wires or metal film wedged under the bridge, but it was very prone to falling apart. Before that, I used a flex-sensitive piezo just jammed under the bridge, like the kind found in buzzers. It worked ok. Before that, I tried bolting the washers to the side of the bridge, sticking pieces of pressure-sensitive piezo in the “kidney” of the bridge, taping flex-sensitive to the side of the bridge, etc. This method seems to have worked the best. The best professional piezo pickups are actually several separate pickups mounted inside of the bridge itself, two or more for each string. I couldn’t afford to buy one, and didn’t know how to make one, but this works pretty well. [Years later: I can afford one now; maybe I’ll buy one someday and compare.]

In building it, I learned that the predominant motion of the bridge is actually a side-to-side rocking. Theoretically, the bass bar (a piece of wood that runs lengthwise on the inside of the top of an acoustic violin) sits directly under the right foot of the bridge and the sounding post sits under the left foot. The bass bar keeps one foot rigid while the bridge rocks back and forth, transmitting vibrations through the sounding post to the back of the violin. I’m sure it’s not really that simple, but the rocking back and forth is pretty accurate. When I first hooked up the piezos I was surprised to see that the waveform coming out of one was upside down from the other. As the pressure increases on one pickup, it is decreasing on the other. Since this would sound weird in headphones, and I wanted to be able to sum the signals, I just flipped one of the piezos over during construction, so that the polarity would be the same for both. Summing them while inverted would cancel out all of the signal except for the tiny bit that is different between channels.

The low frequencies are almost exactly the same from left to right, although the left pickup is louder for low strings and the right is louder for the high strings. The overtones, however, have some phase shift, which gives it a little stereo image. This can be seen on an oscilloscope with an X-Y trace mode. Playing a single clear note results in a mostly diagonal line, with little difference between the two channels. Little loops are visible because of the difference between the overtones. Playing a “harmonic” or plucking the string usually gives more interesting plots.

The waves have a definite polarity to them. When you up-bow there is a positive peak in the waveform, and vice versa.  Absolute polarity of sound isn’t audible by itself, but it becomes audible after passing through any kind of asymmetrical distortion.

For testing the pickups, I made a little assembly with a block of wood to sit on top of the body, under the bridge. This way I didn’t drill big holes and then regret it. Your fingers start hurting pretty bad with all the tension from the very high bridge. The edge of the test base cracked when I was drilling it, so I made the actual holes a little closer to the center. The bridge feet don’t sit right in the center of them this way, but it still works fine.

Preamp circuit

The preamp circuit is an op-amp configuration called a charge amplifier. Piezo sensors can be modeled as a voltage source in series with a capacitor (as shown in the schematic), and charge amplifiers are the perfect complement for a capacitive source. (Similar circuits: 1, 2, 3) The other alternative for piezos is a very high input impedance resistive amplifier. The high resistances create a lot of thermal noise, though, making the charge amp superior. [Edit: Where did I get that idea?  Any thermal noise should be shunted by the capacitance of the pickup.]

J. Donald Tillman points out that an FET preamp’s non-linear response is actually better than an ultra-linear op-amp’s, since an op-amp will clip hard (important as the battery dies). An FET will distort sooner, but not as harshly, which is probably better for an audio preamp. Might be something for others to consider. I haven’t had any noticeable problems with clipping, and gave it significant headroom, but, then again, I play pretty distorted most of the time, anyway…

I measured the voltage output of the piezo by plugging it directly into an oscilloscope and playing hard. It was hard to read an absolute value, since it tends to make very large short duration spikes, but I measured about 10 V peak-to-peak at max. A typical signal was only about 4 VPP though. I decided to cut the voltage in half because a non-clipping signal is more important to me than a high signal-to-noise ratio, and it would probably be plenty acceptable anyway.

The gain for this charge amplifier is

G = Cinput / Cfeedback

Notice that the terms are reversed compared to the typical resistive inverter equation. I measured the capacitance of the piezo with an LCR meter and got approximately 680 pF. So I am roughly halving the voltage (680 pF / 1500 pF = 0.453) to get the peaks well within the ~8 VPP rails of the op-amp (0.453 × 10 V = 4.5 VPP).

The feedback resistor determines the lower cutoff frequency, or the speed at which a DC voltage on the piezo would discharge back to 0 V, depending on your perspective. When I built the first preamp circuit (and there were several failed versions), a “constant” DC voltage would appear all the time, sliding the signal up past the power rails and clipping it off. Because the piezo is under the bridge, any change in the tension of the strings (fingering) or the pressure from the bow translates into a huge pressure difference for the piezo, which would then output a DC voltage. Since there is some inherent resistance in the piezo element itself, this charge slowly dissipates, but it can be very slow. In resistive amplifier designs, a large resistor needs to be connected across the leads of the piezo to dissipate this charge, but it has to be a large value so as not to dissipate the signal, too. In the charge amplifier, the feedback resistor performs the same function. The lower −3 dB point is

fc = 1 / (2 π Rf Cf)

So mine has a low cutoff frequency of about 100 Hz. The lowest note on a typical violin is G3 (depending on your numbering system) = 196 Hz. So I have almost an entire octave below the lowest note I would typically play left over for down-tuning and flat frequency response. One problem with this is that the piezos pickup a lot of low-frequency handling noise from the body of the instrument, but it’s not that bad.  Higher-order filters could be helpful to keep frequency response flat for frequencies of interest while cutting out handling noise.

The non-polar electrolytic capacitor is for blocking any DC that might be present, even though there shouldn’t be any, since the output is referenced to the bias point. It isn’t hurting anything, though. Regular electrolytics are not ideal, since there is no constant voltage to keep them polarized.

I have the two pickups output separately, in a “stereo” approach. Since my amp and effects pedal (and most everything with an instrument input) uses mono, I needed a way to mix the two together easily. Originally I had an elaborate circuit planned to output stereo to a TRS plug and automatically convert the stereo output to mono when a TS plug was inserted, with only one op-amp. It used capacitive summing amplifiers and involved summing the left channel and two copies of the right channel, one of which was the inverted R channel output. L + R − R = L. Then, when a TS plug was inserted, it would ground the inverted R, leaving L + R at the tip (+6 dB). So it would output L + R in mono mode and −L, −R in stereo mode. However, I then realized that I couldn’t use that circuit and also have a gain or volume control (though this may be useful to someone else). Eventually I decided to just use a “backwards Y” connection to mix the inputs.

Connecting two outputs together is almost always a very bad thing, but you can actually do it in certain situations (as I learned). The problem with connecting two outputs together is that they tend to have very low source impedances. When one output is tied to another, it ends up putting a lot of power into that low impedance, which tends to burn them both up. The 5 kΩ resistors on the outputs of the amp prevent the two op-amps from “seeing” each other; instead they see a large load impedance in parallel with a 5 kΩ resistor to ground. So now I have two cables; one is a normal TRS cable for stereo output, and the other is a homemade TRS to TS cable which connects the tip and sleeve together for mono output.

The capacitors from the power supply to ground prevent it from clipping early and doing other weird things. From what I understand, the changing impedance of the output stage of the op-amp causes signal frequency changes in the supply voltage, which is smoothed out by these caps before they can have a feedback effect on the inputs. Before I had them, it was clipping strangely at about half the voltage it should clip at, depending on the signal.

To do

Both the chin rest and shoulder rest are standard models meant for a regular violin, which has a “lip” on the edges for them to grab onto. Mine just has 90° angles, so both tend to slip off. I might try to attach something permanently. I also might try to make a shoulder rest that extends farther down the chest, to give some leverage to counteract the violin’s weight.

It’s very hard to hear yourself while playing with noisy guitars, drums, and the like. It turns out that hearing yourself is much more important for the violin than a fretted guitar, though, as that’s how we stay in tune. We get as close as possible to the right note with muscle memory and then shift into tune with the ear as the note forms. When I can’t hear myself, I’m very out of tune. So I am probably going to build some type of belt-pack in-ear monitor. Another option might be a little speaker on the violin itself, near the left ear. That would use up a lot more power than the preamp alone, though.


If I made another one, there are a few things I would change.

  1. Weight: It is way too heavy. I would not have made it as thick or put the “wings” on it if I realized how much it would weigh. It’s not heavy for a piece of wood, but it is heavy compared to a mostly hollow acoustic violin. I can hold it up with my chin fine, but it gets tiring, and then I tend to use my arm to hold it up, too. It’s not really something I can fix, though the expanded shoulder rest idea might remove some of the torque.
  2. Tuners: Machine heads are far superior to pegs. Especially pegs in homemade holes, which do not turn smoothly and either end up too loose or too tight in different positions. If I could go back in time, I would have done it like most modern electric violins do, with the strings fixed to the end of the violin, and machine heads at the base for tuning; no separate fine tuners, no scroll, and less weight at the end, where it matters.
    • Update: I bought a set of Knilling “perfection” planetary gear pegs. They’re expensive (especially compared to the guitar machine heads I wish I had used), but seem to work, and I have removed the fine tuners from the tailpiece. An alternative is Pegheds, which are even more expensive. I haven’t used them for very long, so they may have wear issues that I don’t know about. They don’t feel as impeccably manufactured as they are priced; the resistance to turning changes slightly as you turn the peg in a full rotation, which wouldn’t happen if all the parts were perfectly symmetrical. There’s also an obvious manufacturing seam, which I sanded off.
  3. Strings: I would have given it 5 or 6 strings. Sometimes I think I should have taken up cello or viola instead; I always want to play lower notes than it is capable of. Sometimes I play with the strings tuned down a step or two, but you can only take that so far. Octave effects work, and can sound really nice, but only for some applications. I have read about specially made “baritone” violin strings, which are very thick and sound an octave lower than normal…
  4. Power: The battery lasts a long time, especially with a jack switch to disconnect it when not plugged in, but phantom power might be a better idea. The in-ear monitor and phantom could be in the same box.

Quick Search Bookmarklets

Update: I do all this with Ubiquity now.

  • Quick Search: A feature of Mozilla browsers that allows you to store a bookmark with a variable and a keyword, to allow custom searches by typing the keyword and a search term into the location bar
  • Bookmarklets: Bookmarks that, instead of a normal URL, contain small javascript programs

What could be better than these? Combine them together!

In November 2005, I was trying to get rid of the Googlebar extension, since I didn’t use most of its features, and the parts that I actually used could be better met by more specialized, less Google-oriented extensions. For instance, the SearchBox Sync and SearchWP extensions have the same functionality as Googlebar’s terms toolbar, but use Firefox’s native search box and sync with any search engine; not just Google. Google’s translation service could be better met by a dedicated translation extension, like translator, or Translate, the Google cache feature could be replaced by a dedicated cache-viewing extension like any of these: 1 2 3 4 5 6 7 8

But what to do about Google’s site: search? (It lets you search for a term within the domain you are currently viewing.) I couldn’t find an extension to replace this functionality, but it’s a feature that I use regularly, so I couldn’t get rid of the Googlebar quite yet. There’s no way to do this with a Mycroft plugin, as far as I know, since it needs to know the site you’re currently on, in addition to the search term. Likewise, it couldn’t be done with a Quick Search, since the URL it generates only varies by search term; not the URL you are currently visiting. It could be done with a bookmarklet, but the search term would have to be entered into a prompt: popup, highlighted on the page before clicking the bookmarklet, or the like.

So why not use the Quick Search functionality for the search term (%s), the bookmarklet to determine what site you’re on (location.hostname), and the keyword for the interface? So I did. After some work (and several revisions), I use this:

If you drag it to your Bookmarks Toolbar and give it a keyword:

Screenshot of bookmarklet properties

You can then search for a term anywhere within the domain you are currently viewing by doing one of the following things:

  • Enter “site searchterm” into the Location bar
  • Highlight a search term on the page and click the “Site:” button in the Bookmarks Toolbar
  • Highlight a search term on the page and type “site” in the Location bar
  • Click “Site:” in the Bookmarks Toolbar and then type your search term in the prompt() window that pops up
  • Enter “site” in the Location bar and then type your search term in the prompt() window

So many possibilities!

Also, when I first wrote it, I could highlight a word and then select Site: from the context menu using the SmartSearch extension, which allowed me to leave the bookmarklet in my Quick Searches folder and still access it with the mouse without cluttering up my Bookmarks Toolbar. I rarely used this, though, and it appears to have broken; I don’t know if one of my changes broke it or if a change to SmartSearch broke it.

Other search keywords I use:

  • wp: Goes to the shortcut that I typed on Wikipedia. So if I type “wp wotta” it capitalizes it and goes to WP:WOTTA
  • wayback: Goes to the Wayback Machine listing for the page I am viewing (this isn’t actually a Quick Search, since it doesn’t involve any search terms, but I access it by typing “wayback” into the location bar, so I’m using a keyword and bookmarklet at the same time)
  • latest: Goes to the most recent archived copy on the Wayback Machine, like above

Don’t trust Google calculator

The term “kilobyte” means 1,024 bytes.



Most people reading this are experienced with computers and know that, in many computing contexts, kilobyte means 1,024 bytes. Descriptions of file sizes, memory, and so on. However, in some situations (and in the minds of most non-technical people; I’ve asked), kilobyte means 1,000 bytes. More importantly, units like kilobit usually mean 1,000 bits rather than 1,024. (Especially in the unit kilobits per second, or kbps, which always means 1,000 bits per second.) Google gets this wrong, and just uses 1,024 for everything. Wrong wrong wrong.

So any time you’re using Google to do computer-related calculations, be very sure you’re getting the result you want. I was first miffed by this when (at work) I stupidly trusted Google’s result about the bit rate requirements for streaming audio, for instance.

At the very least, they should provide a short explanation and disclaimer for calculations involving computer units, to explain the discrepancy to people who don’t know about it, especially given that confusion about the issue has resulted in litigation. Google calculator doesn’t seem like a huge target for lawyers, but they care enough to provide a little warning and disclaimer when you do a currency conversion:

Rates provided for information only – see disclaimer. More about currency conversion.

Even better, they could just do it right. Unambiguous units have been around since 1999, and have been adopted by standards organizations and open-source software.

Ironically, Google is aware of these units, but still uses 1,024 for both. For shame.

Update January 2008

I’ve actually talked to one of the employees who worked on Google Calculator.  He had already largely convinced the other maintainers that they should fix this, but left the company before he had a chance to implement it.

I’ve since discovered that GNU Units implements a lot of the same functionality, but:

  • You can use it offline, without webpage-loading delay.
  • It handles a lot more units and prefixes.
  • You can create your own units in a ~/.units.dat file.
  • It uses the standard definitions for “kilobyte”, “kB”, and “KiB”.
  • It runs on Unixes, Apples and Windows.


> units -1v "3 kilometers + 500 feet" yards
	3 kilometers + 500 feet = 3447.5066 yards

> units -1v "16 bit * 44.1 kHz * 2" kbps # Compact disc bit rate - Google gets this wrong.
	16 bit * 44.1 kHz * 2 = 1411.2 kbps

> units -1v "5 million pounds" megakilogram
	5 million pounds = 2.2679619 megakilogram

> units -1v "one hundred V / 5 ohms" A
	one hundred V / 5 ohms = 20 A

> units -1v "1/(2*pi*sqrt(10*microF*100 mH))" Hz # resonance frequency of an LC circuit
	1/(2*pi*sqrt(10*microF*100 mH)) = 159.15494 Hz

> units -1v "sqrt(mu0/epsilon0)" ohm # impedance of free space
	sqrt(mu0/epsilon0) = 376.73031 ohm

> units -1v "sqrt(4 k stdtemp 1 kohm (20 kHz - 20 Hz))" nanovolt # thermal noise of a resistor
	sqrt(4 k stdtemp 1 kohm (20 kHz - 20 Hz)) = 548.99727 nanovolt

> units -1v "furlong per fortnight" cm/minute
	furlong per fortnight = 0.99785714 cm/minute

> units -1v attoparsec/microfortnight inch/sec
	attoparsec/microfortnight = 1.0043268 inch/sec

Unfortunately, it cannot calculate the answer to life the universe and everything, but you should probably have that memorized, anyway.  You know, just in case…

Content Management System

There’s a lot of stuff I want to write and publish on the web, including some that I’ve already published by hand on this site and elsewhere, but typing in raw HTML is very sub-optimal. I want a quick and easy content management system to do the low-level stuff for me, and, ideally, I’d convert my entire site to run on it. But which? I’ve ran little test setups for WordPress, Drupal, and textpattern, and none really do what I want. So what do I want, exactly? Hmmm… I’m not even that sure. The ideal system would have some of the features of a blog, some of the features of a wiki, and some of the features of just a generic hand-programmed website:

  • I don’t want this to be a “blog”. I want it to be a… “collection of pages or articles”. With headings and such. The chronological order in which I wrote them is not important, but their subject is, so I’d want things organized by categories or tags instead of by date. Most of the blog/CMS systems have some type of tagging feature like this, but I don’t know if the main organization of pages can be based around it. Usually it’s incidental, for finding posts related to the one you are reading, but everything is presented chronologically with the latest posts first.
  • When I edit an article (even before publishing it; during the writing process), I want each revision saved separately, like a wiki, CVS or versioning file system. After publishing, the log of my revisions/edit history should be viewable by visitors so they know when something has changed and how up-to-date the page is.
  • I want users to be able to comment on an article in a publicly-viewable way, like a blog. Maybe even comment on each other’s comments in a threaded fashion? Of course, if I can edit articles and create new revisions, how would outdated comments about older revisions of the text be handled? I guess in blogs the post editor just notates this by responding with “Thanks, I edited the blog as per your suggestion”.
  • A rich text editor would be nice, simply because typing HTML tags is a pain. Wiki markup or textile is not horrible, but I’d rather just type and use shortcut keys for formatting. The formatting should be restricted to basic, bare, semantic, and correct HTML tags like <h1>, <p>, <em>, and <code>, and not things like <i>, <br/>, and <font size=...>. I’ll handle the formatting with site-wide CSS and classes, thanks.
    • But I should to be able to switch (quickly) back and forth with a raw HTML display and edit the (automatically well-formatted, syntax highlighted) source code, too, if I need to, and my HTML changes won’t be overwritten by the rich text editor.
      • Should allow me to insert arbitrary code when desired, like JavaScript, when needed.
    • The rich text editors where you can paste HTML from other pages/sites would be nice, but strip out bad markup like setting CSS styles explicitly? I dunno.
  • Images. I want to be able to include images in my posts without any hassle. Maybe inline, maybe floating alongside. With captions. Automatically generated thumbnails that link to full-resolution images. I want to upload the pictures as I’m typing, and have them organized on my server in a way that makes sense. I shouldn’t have to refer to them by meaningless numbers or img tags with cryptic URLs.
  • When editing with Google Docs, I have been using the title tag of a link to hold a summary of the page’s content. It would be awesome if, while editing, I could enter a URL and the title tag and beginning text of the linked page was suggested automatically.
  • I like the idea of semantic HTML, and it would be awesome if certain types were added (semi-)automatically, like abbrev tags, OpenURL/COinS, …
    • If I’m quoting, it would be nice if it automatically added blockquotes, attributions with links, URN citations, etc.

Anyway, that gives an idea of the general idea of what I’m looking for. I am trying a combination of Google Docs and WordPress for now. This probably isn’t the best system, but it’s the best I’ve found.

(Google Docs isn’t grouping my text in paragraphs when I create a double newline, for instance, but putting two <br/>s instead. And, instead of setting off text with <code> tags, you have to change the font to Courier New, which implies to me that my basic paragraphs have an explicitly-defined font, too? And (oh geez), it’s adding <span style="FONT-STYLE:italic"> where I really just want <em>. It’s meant to be more like Microsoft Word than a web page editor, I guess. I’ll probably edit the HTML to fix these things after importing to WordPress. But that’s so much manual tweaking work for a trivial (but Proper) change! Completely negating the whole point of using these tools in the first place. I’d rather the tools just do that stuff for me.)

Anyway, yeah. These are the things I want, and navigating the huge list of content management systems and their even huger lists of plugins is mind-boggling. So I’m just going to go with this for now so that I can start publishing. Recommendations would be greatly appreciated.