Category: Geek

With the release of Mac OS X 10.4.3, Safari becomes the first publicly shipping browser capable of passing the rigorous Acid 2 web standards compliance test. What’s amazing about this test is that its output looks almost idiotically simple, even though it’s testing a very wide range of CSS features (try viewing source on the test page). Note that Acid 2 does not guarantee 100% CSS compliance, focusing instead on features that designers actually want to use (how it works). Even Firefox (v 1.07) fails miserably.

Forget about the iPod Nano — Researchers at Rice University have built a one-molecule car (Red Herring), complete with working chassis, axles, and wheels. Its wheels are Buckyballs — “hollow spheres composed entirely of carbon atoms, known to chemists as buckminsterfullerenes,” named for visionary scientist/philosopher Buckminster Fuller. The car is not, however, self-propelled (one has to wonder what kind of fuel could be put into a vehicle that’s one twenty-thousandth the width of human hair — constantly losing the gas cap would seem to be a major hassle).

Up early this a.m. to join the campus web accessibility group for a tour through a few sites I manage — via speaking screen reader technology for the blind. Like most web managers, nailing accessibility has been one of those things on my to-do list for years, but which has a bad tendency to get de-prioritized in the midst of other needs. We tested both the existing and forthcoming journalism sites, as well as chinadigitaltimes.net. Tested with a reader called Jaws for both IE and FireFox, and then using the screen reader built into Tiger.

Overall, I was impressed at how well our sites did, in part because I’ve paid at least some attention to web standards, Alt-tagging, and form labeling over time, but we’ve definitely got work to do. Probably the easiest-to-implement change will be to place Skip Tags around main navigation elements so people don’t have to hear the main nav read to them on every page view.

We all know by now that tables should only be used for tabular data, not for page layout. But today I got a first-hand demonstration of what a difference CSS rather than table-based layout makes for blind users. And when you do use tables, be sure to use the caption= attribute to label its purpose.

Heading levels are so often chosen arbitrarily, based on font size (layout) reasons, rather than on hierarchical logic. We all know better, but we’re also all guilty of this. But few developers know that when heading levels are implemented logically, blind users can skip between the main points/sections on a page by jumping from, e.g., one H2 to the next, skipping content in between major points.

One thing I didn’t know was that developers should not be religious about attaching Alt= tags to images. Spacer gifs or decorative images that serve no purpose from the perspective of gleaning useful content merely slow blind users down. Even though it will cause pages to fail XHTML validation processes, blind readers appreciate leaving Alt tags empty (as opposed to missing) with non-essential graphics (when the Alt attribute is blank, the screen reader skips the image completely). Use alt=”” for non-essential graphics.

Some of these things I’ll be able to implement easily on the new site; others may not make it until a few months after. But just knowing what to be mindful of, and having now witnessed the experience of surfing blind for myself, is going to make a difference in the way I work.

Cory Doctorow for Boing-Boing on the miserable flop that is Motorola’s new ROKR/iTunes phone:

Wired has a depressing long feature on how the Motorola ROKR iTunes phone ended up flopping so hard. It comes down to this: Apple didn’t want to cannibalize iPod sales, the carriers don’t want to cannibalize mobile music sales, and the labels want to control everything.

All of this reminds me of why Sony had such a hard time bringing the Walkman into the digital age and creating an equally popular MP3 player: Sony has one foot in the music industry, another foot in consumer electronics. Ooops — they found themselves trying to serve two markets that were suddenly in a conflict of interest. To protect their music industry interests they released their first players as ATRAC players rather than MP3. Which of course no one wanted.

The two-year contract on my original cell phone is heading towards expiration and I’ll soon be in the market for a replacement. Can tell you right now the ROKR ain’t going to be it.

Trying out the new Flock browser for the first time — an offshoot of the Firefox project. Released in alpha (bugs thick enough to swat with a butterknife) for Linux, OS X and Windows just a few hours ago. Developers committed to not forking Firefox — we’ll see how successful they are (seems like we’ve heard that one before). Flock is aiming to be the first “Web 2.0” browser, with built in RSS, photo sharing, link tagging and blog posting. In fact, I’m using Flock’s built-in blog editor to post this. It’s no ecto, but nice to have posting factored directly into the browsing experience.

Sometime in the late 90s, a co-worker at Ziff showed me how he could build a web browser in Visual Basic in five minutes flat. Sure, it was a sucky browser, but it worked, and the feat was impressive. It was my first exposure to the power of RAD (rapid application development), and the advantages of using a higher-level development platform that takes care of arcane plumbing for you.

Fast-forward eight years. Reading up on Rails and preparing to unleash RoR on Birdhouse (no, not quite ready yet), has gotten me thinking about the advantages of one web application development framework over another, as opposed to the advantages of one language over another.

Ruby is a graceful language — as clean as they come. But getting up to speed with it is still going to consume dozens (or hundreds) of hours I don’t have to give. PHP may not be as clean as Ruby, but it’s also a great language — easy to start working in quickly, easy to improve your skills incrementally. It’s an extremely productive environment. In many ways, PHP is succeeding through its simplicity and great productivity curve in places formerly reserved for Java. And hard-core Java programmers who have regarded PHP as a “toy” language are being forced to re-think that position.

Over the past five years I’ve put hundreds of hours into learning and applying PHP in the real world. It began to dawn on me that what I’m really lusting after is not so much Ruby itself, but the Rails RAD framework. Surely there must be some equivalent of Rails that sits on top of PHP? Enter the fragmentation problem so common in the open source world. Rather than centering on a single MVC framework as Ruby has done with Rails, at least a dozen different framework projects are out there for PHP, none of them regarded as the standard. Projects like Seagull and Phrame and Yellow Duck all seem to be trying to skin the same cat. Smarty, which is an official offshoot of PHP itself, bills itself as a framework, but really seems to focus on being a killer templating engine (we’re using Smarty for the coming J-School site redesign). Zend’s collaboration with IBM and others on a full RAD framework for PHP probably holds the most promise of providing a unified standard, but who knows how far away it is from release, let alone maturity.

The fragmentation and uncertainty surrounding PHP framework standards means adopting one now is risky. No one wants to write thousands of lines of code on top of a platform that may become marginalized when the world coalesces behind something else in the future. Ye olde data lock-in problem, extended to the code level.

Meanwhile, not every review of Rails development is unequivocally glowing. This post on Rails vs. PHP references a common complaint about Rails: Once you get beyond the scaffolding stage, the ease-of-development advantage diminishes quickly. And debugging a Rails application can be a lot trickier than dealing with simple PHP objects and pages, since code gets so abstracted from the core language below.

For now, I think I’m going to see how far I can push Smarty. Its compatibility with my existing PHP experience and codebase make it a natural choice for framework exploration. Rails may have to wait for some fresh project on the horizon. Looking forward to it, but not sure there’s enough pay-off to warrant dropping everything and jumping ship.

Usability expert Jakob Nielson says the rise of WYSIWYG over the past 20 years has been useful, but may be reaching the end of its life cycle in favor of WYGIWYS (What You Get Is What You See)-oriented interfaces. The idea is that rather than starting with a blank slate (document) and issuing commands to reach a result (chipping away until you have your statue), WYGIWYS software will provide thumbnail galleries that display formatting states and sub-states, allowing the user to select results, applying it to their existing content.

The idea makes a certain amount of sense, but I’m having trouble visualizing how WYGIWYS tools could offer complete control — it seems that formatting results would be limited to the gallery of states built into the software by the developer. Sure, the galleries could be customizable, but then you’d be back where you started. I can see an increase in use of the “Project Galleries” built into current versions of Office and extended to options applicable at the paragraph or even character level, but I can’t imagine menus and toolbars going away, as Nielson predicts. There’s a whole lot more to software than formatting — to make this idea work, you have to be able to visualize presenting “results first” for things like word count, spell check, inserting database records or video clips, yadda yadda.

Total control is precisely what makes free-form software so empowering (and the command-line even more so). I’m having trouble visualizing how a results-first approach could do anything but strip control (i.e. empowerment) away from the user.

This incredible… thing is rolling off my printer, double-sided, at 12 pages/minute. Those who know me know how much I loathe printouts. But I’m making an exception.

Recently feeling like it’s time to offer the Rails development framework to hosting customers*. But it’s hard to do that until and unless I’ve at least dipped a toe into Ruby’s lean, sparkling waters. Stumbled on the Poignant guide and was immediately amazed. It’s got hand-drawn cats. It’s got surrealistic dialog. It’s got punk-rock collaged narratives floating in the sidebars. It’s got photos of car keys sticking out of apples perched on coffee mugs. It’s got clean, well-written, entertaining prose on learning Ruby. This is the rare tech book that doesn’t answer to corporate masters, that exhibits the full, unfettered creativity of a literate, funky programmer unbound by editorial constraint or preconceived notions of how a tech book should look, or work.

Not that I suddenly have time to master Ruby, but I am going to bed with this 126-page PDF right now.

* Actually I’ve already got the Ruby interpreter installed, as well as mod_ruby and FastCGI, just need to do some integration tests, and figure out the best way to offer this to customers in a reliable, consistent way. It’s such a different animal from Perl/PHP/Python, etc. Need to wrap my head around it just a bit before unleashing the hounds.