Archive for January, 2009
Photoshop Sirens
I’m staring at a gorgeous visual right now. It’s an image of how the Infovark UI might look. I can imagine myself clicking on that tab, and navigating off to a world of beautifuly laid out, useful information…
I really want to see this go into production. I really do…
But it won’t. Our designer used Photoshop.
There’s nothing wrong with Photoshop, of course. Nor Gimp, nor Paint.Net, nor any other image editing tool you could mention. And there’s nothing wrong with our designer, either. She really knows her stuff. But I can’t help but feel that perhaps you shouldn’t let your designer touch an image editing tool when she’s working on a web design.
The web is visually limited
When you open an image editing tool, you’re presented with a blank canvas. And the first instinct of any artist or designer is to fill that canvas.
Web pages aren’t canvas. On canvas, or on paper, it’s just as easy to paint one corner as another. This isn’t true of the web. With a web page, one corner is much easier to reach than all the others. In languages written left to right, it’s the upper left hand corner.
Not all sides of the image are equally easy to reach, either. The top and left edges of your canvas are much, much easier to paint than the right or bottom edge.
It’s as if the upper left corner has its own gravity, and draws all other page elements toward it. Like a black hole, it warps your grid.
It is many times harder to place elements in the bottom right corner of a page than the upper left. You’re fighting the pull of gravity the whole way. You’ll have to build on top of block elements like DIV to get there. And beware of the CSS float property. As its name suggests, it isn’t supported by anything. It can wreak havoc on your layout, setting off a cascade of unwanted effects.
The web also suffers from typographic poverty. In an image editing tool, your designer will have access to hundreds — perhaps thousands — of fonts. They can be used to create images freely. But all but a handful of these fonts can be used on the web. Most designers know what fonts are actually available for use. You can cheat in certain cases, and use images instead of text for certain headers and buttons, but many of the effects you’d like to achieve with typography are simply not possible today.
Your web canvas won’t take all kinds of paint, either, unlike an ordinary image file. Not all browsers support transparency in images, for example. Placing gradients and shadows can be tricky.
The web is in motion
But the biggest challenge can be the dynamic nature of a web page. Looking at a design, it can be hard to imagine the effect a blinking, spinning animated widget will have on your audience. It’s also hard to visualize what rollovers or pop-ups might do to the overall feel of the page.
Unlike paper or canvas, a web page can be stretched and scrolled. What does that do to the positioning of its elements? What happens when a user adjusts the font size in the browser, but embedded gifs and jpgs remain the same size?
But the biggest drawback to having your designer work in Photoshop is that to the layman, the web site looks almost finished. They’re pretty, these Photoshop Sirens, and they sing! They will draw you in…
Only the lonely code monkey hacking away at HTML, CSS and JavaScript knows that a screenshot is as far away from a working web page as a screenplay is from a feature film.
JQuery Turns 3
When we began work on the Infovark user interface, we decided to base it on HTML and JavaScript. Both Gordon and I are very comfortable with web development, so it was a natural choice. We also felt this would give us the most flexibility to run on different platforms with different screen sizes. For better or worse, HTML and JavaScript have together become the lingua franca of interactive design.
Both have their drawbacks, of course. HTML and JavaScript have evolved over time. They each have quirks, particularly with regard to the Document Object Model (DOM). Fortunately there are a wide variety of JavaScript libraries that help programmers working with HTML and JavaScript.
We love JQuery
After doing a little research, we settled on on JQuery. JQuery makes us love JavaScript again. It’s a simple, small library that works across all major browsers. It deals with all the inconsistencies that emerge from the last decade of tinkering with web standards. Most importantly, it helps us get things done.
Microsoft has decided that they love JQuery, too. John Resig, the progenitor of the JQuery project, announced in September that jQuery will be distributed with Visual Studio. Two prominent Microsoft bloggers, Scott Guthrie and Scott Hanselman, also discussed the news.
It keeps getting better
Momentum around the project continues to build. The JQuery blog just posted news about the JQuery 1.3 release and the JQuery Foundation. Most exciting of all (from our perspective as developers) is the release of revamped JQuery API documentation.
Congratulations to the JQuery team! It’s come a long way in three short years.
Digital Watches are a Pretty Neat Idea
The Hitchhiker’s Guide to the Galaxy opens with the following quote:
Far out in the uncharted backwaters of the unfashionable end of the western spiral arm of the Galaxy lies a small unregarded yellow sun.
Orbiting this at a distance of roughly ninety-two million miles is an utterly insignificant little blue green planet whose ape-descended life forms are so amazingly primitive that they still think digital watches are a pretty neat idea.
Though it was published three decades ago, the quote is relevant today. Not only because of our continuing enthusiasm for digital watches, in all their forms, but because our neat little clocks are still amazingly, stunningly primitive.
Computers Can’t Tell Time
From the Y2K bug to the recent Zune bug, the inability of computers to tell time properly — and the inability of programmers to process dates and times correctly — leads to recurring problems.
While some tech bloggers feel the issue is poor datetime programming practices, I think the issue is more fundamental than that. Why else would an established software platform vendor like Microsoft still be struggling to come up with a decent datetime implementation?
The problem is simply that computers can’t tell time. Or rather, that computers worldwide can’t agree on what time it is.
A history lesson
In the early prehistory of the Information Age — prior to 1970 — computers were large, unwieldy assemblages of equipment. ENIAC filled an entire room. Mainframes and supercomputers, descendants of those early digital beasts, share two characteristics with the early computing devices.
- They are not portable.
- They do not communicate with other computers, or if they do so, they usually determine the operating environment of the other terminal computers.
Personal computers, even today, have yet to shake some of this legacy. The upshot of this is, your computer thinks its clock is always right. It never checks the position of the sun, or better yet, checks with the International Bureau of Weights and Measures to get the Universal Coordinated Time. As a result, most computers today rely on the accuracy of their internal clocks, which are typically set to local time or the time at the chip factory.
Some operating systems will adjust this for you. If you’re running Microsoft Windows, for example, you’ll default to U.S. Pacific Standard time. Which is wrong for most of us on the planet, but you have to pick somewhere to start, right?
All your base are belong to us
I know, you’re thinking, “All that crappy legacy left over from the mainframe days. Can’t we scrap it and move on?” Well, buckle up, friends, because there’s far more legacy thinking involved in timekeeping than that! Our system for time is based on work originally done in ancient Sumeria.
The Sumerians used a sexagesimal number system, which is almost as interesting as it sounds. Programmers are used to the everyday decimal number system, the binary number system, and hexadecimal. But base-60 is a complicated system indeed, with many fascinating properties, including the fact that it’s evenly divisible by the first six counting numbers.
So the reason why hours have 60 minutes and minutes have 60 seconds is all the Sumerians’ fault. As is the convention that a circle has 360 degrees.
And yes, they tried hard, but 360 is not quite the number of days in a calendar year. But they felt it was close enough. Though after two millennia, they’d made April Fools of many Catholics.
A modest proposal
My point? Math is hard, and converting between different numeric systems makes it harder, and when real life calendars don’t quite fit into a neat mathematical box, you’ve got the makings of a complicated system that’s ripe for failure. So fail we do — and often!
In the interests of making one tiny, tiny optimization in this all-too-complicated matter of time (And we haven’t even factored in general or special relativity yet!), I propose that we all adopt UTC immediately. Forget about daylight savings, forget about time zones: UTC and datetime calculations are troublesome enough without having to worry about localization.
We now have a globe-spanning GPS system, constantly beaming timing signals to a wide array of portable devices. Our laptops, workstations, minicomputers and mainframes ought to use these as well. Let’s all synchronize our neat digital watches.
Ready? Mark!
The Loop Snooper
Some programmers claim that their code is poetry, but there are few programmers whose poetry might count as code. Recently, Phil Windley posted A Halting Problem in Verse to his Technometria blog. It contains a link to a proof that the halting problem is insolvable, written by Geoffrey Pullum in the style of Dr. Suess.
