Ver­sion 1.2 now avail­able on the Down­loads page.

Version 1.1 now available on the Downloads page.

More importantly, there’s usually nobody looking over your shoulder when you log in to a website. It’s just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

While I agree with Jakob’s general observations about usability and the apparent cost of failed password attempts, I think the alternative isn’t quite acceptable.  Because frankly, we’re not all sitting alone in our office.  Many of us, are in fact, in the real world…like airports and coffee shops.

Perhaps the solution would be to implement into browsers a mechanism to un-mask password fields if you’re absolutely sure you’re not being snooped on (or at least confident enough to take the risk).  After all, there’s nothing in the HTML spec that prevents this behaviour.  Desktop operating systems do it all the time these days.  Although, there’s nothing either that says that a plain text field can’t be used just be used either (which kind of makes the whole thing moot anyway).

Regardless, people with fat fingers hamming away on their iPhones should be the last people to complain about password masking: while they’re out there flaunting their precious little gadgets like a prom date, they’re the very ones being protected by masking.  Granted, their passwords are probably something asinine like the name of their cat.  They should use something like 1Password.

When I restarted Firefox, no problem…weird.  I guess this sometimes happens?

For a more complete description, got to the Downloads page.

When I was working at an animation studio back in the late 90s, I was introduced to the avuncular Charles Poynton who has made a career out of sitting on panels, making recommendations to technical boards and writing books on video, color and especially gamma.  I took a course from Charles along with some colleagues because we needed to implement color correction and set a mutual standard across our studios around the world.  So knowing what it was we were trying to achieve was somewhat key.  We had digital ink and paint and compositing people on SGIs, color artists on Macs, a renegade CGI team that switched from Maya to 3D Studio Max and then editors on Macs in Avid but did their viewing through expensive Sony Evergreen reference monitors.  Finally, an art director who looked at the work on all of these systems and wondered why everything looked different.  The majority of people don’t need to ever concern themselves with this stuff and should probably just move on.

The term gamma (more accurately, “gamma correction”) is thrown around loosely by a lot of people without much knowledge or theory behind it.  It’s not something that should be common knowledge (sorry Charles) but the way it’s bandied you’d think everyone is an expert (for the record: I’m not); it’s actually pretty boring and somewhat arcane.  Boring and arcane because there’s a bit of math underneath involving fractional exponents which often terrifies anyone who hasn’t done A-levels or SATs (or whatever your region inflicts on you to make you to learn algebra).

Specifically, gamma proper, historically refers to the exponent of the power function relationship between the CRT electron gun voltage and the intensity of the phospor output.  Blah blah blah.  In simplified terms, it’s pretty much:

intensity = voltage^γ

I say “historical” because the distinction of what it actually represents is blurred by a lot of factors (not the least of which being the introduction of LCD and plasma displays and a myriad of high definition standards).  However, gamma correction is loosely defined as an inverse function (i.e. voltage = intensity^(1/γ)) which would theoretically correct for this, perceptually, to get your display to output what you intended.  Poyton writes:

NTSC historically specified gamma as the value 1/2.2 or about 0.4545. More modern video standards, including Rec. 709 for HDTV, call for the value 0.45 or about 1/2.2222.

This is telling, because it underscores several things you need to keep in mind before creating new color profiles and “Snow Leopard-ing” your gamma.

• the 2.2 number comes from an NTSC standard (1.8 is the traditional Mac number)
• newer standards for video specify different values of this number, i.e. if you’re not doing video, is there really a point in blazing out your display?  Do you really want your display to look like a TV?

If you’re doing graphic work, say for print, web or film you really need to know what you’re output media’s visual characteristics are before changing from any defaults.  Keep in mind that some systems try to take into account source color profiles and do their own correction along the way (often not correctly…but that’s another story).  Some software, like Photoshop, can take advantage of this and embed a color profile of your monitor in the image file.  This may or may not yield the desired results if you, say, send it to a printer.

Also, none of this talk addresses other display systems, such as LCD monitors, projectors, etc.  It also doesn’t address the fact that (a) not all CRTs are created equal (there are manufacturing variances), and (b) even if they were, they don’t all degrade the same way: it’s a moving target.

Finally, it doesn’t address the seldom discussed problem that if you sit too close and stare at a 2.2-gamma display, you’ll go blind.  It’s a scientific fact.

There’s more great stuff on Poyton’s site: it’s more than just Macs and gamma but a bit of color theory as well.

However, I just found this page tucked away which describes how to set the update frequency for OSX (Windows users look here).  You have to get into Terminal and:

$ defaults write com.google.Keystone.Agent checkInterval <frequency>

…where <frequency> is in seconds.  Setting it to 0 (zero) disables it completely.

If you want to manually run an update check, you need to look in either

• /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/
• ~/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/

for a file called ‘CheckForUpdatesNow.command’ and run that.  Convenient, huh?

If I get the time, I might hack together a Pref Pane for this.

I had to take the webapp.css file from the helvetireader.webapp (which is just a zip archive) and drop it into the Prism instance (at /Applications/Helvetireader/Contents/Resources/webapp/).  You could also just directly create this file – it’s contents are just a CSS import as described in that last link.

Unlike the Fluid-based SSB, Prism instances seem to require extensions, plugins and themes separately, i.e. per-instance.  I guess this is a good thing and avoids the kind of snarl that Gears and Fluid are having.