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.
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.
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.
For what seems like the thirteen-thousandth time, I just accidentally pushed the F1 key while I was writing some code. It’s pretty close to the escape key. I didn’t mean to push it. I guess I just have fat fingers.
I really, really hate pressing F1 in Visual Studio. Usually, it takes about a minute to display Microsoft’s help documentation thingy, which is impossible to navigate, frequently wrong and and generally not very helpful. This afternoon, the document explorer decided it had to go and update itself, which took about five minutes before it could take it’s usual minute to load the non-relevant, non-help, that I didn’t even want in the first place!
During this time, Visual Studio was COMPLETELY Unusable. The help dialog blocks the main visual studio thread – and all attempts to get back to work were greeted with a friendly, informative “This may take several minutes” dialog.
Time Passes…
Time Passes…
Time Passes…
Arggh! Gord Mad!… And it turns out it’s not just me. This annoys other folks, too!
Right. That’s it Visual Studio. You’ve made me go through this song and dance for THE LAST TIME!
For starters, where do we all go for help? To Google, that’s where. So, I added an external tool using the Tools>External Tools Method:
Adding an External Tool
I set up my command to point to Firefox, and passed as the arguments:
http://www.google.com/search?site=&hl=en&q=$(CurText)+c%23&
(The +c%23& part of the command appends “C#” to whatever is highlighted in the IDE. If you’re not using C#, you could leave it out, or substitute it with whatever else you usually search for)
Then, I flipped over to the Keyboard bindings screen (Tools > Options > Keyboard:)
VS 2008 Keyboard Binding Screen
And I re-mapped the F1 key to my new ExternalCommand1.
There! Now, whenever I press F1, Visual Studio opens a new tab on my web browser, and searches Google for whatever I have highlighted in the IDE.
Purposefully punishing developers with a minute or two wait everytime they press a certain key is just plain unforgivable. They get really distracted trying to work around the “functionality”, and then further distracted writing ranty blog posts about it…
It’s been a common meme over the past few years that command-line interfaces (CLIs) are making a resurgence. Jeff Atwood noted in 2005 that the Google search box is a command line of sorts. In early 2007, Lifehacker’s Gina Trapani listed several examples of CLIs showing up in a variety of applications.
The return of the command-line interface is striking. It was pronounced dead, replaced by the graphical user interface (GUI) more than two decades ago, after usability research discovered that novice users were much more comfortable with GUIs. But a CLI has three big advantages over a GUI.
The first advantage is speed. Expert users find that command-line interfaces are significantly faster than GUIs. People can type much faster than they can identify a link or button, move the mouse to it, and click. This is especially true if the user’s hands are already positioned above the keyboard. People that do a significant amount of word processing (or writing code) often memorize keyboard shortcuts to avoid having to grab the mouse. It might save only a fraction of second, but if you do it many, many times over the course of the day, those split-second differences add up.
The second advantage is that a command line interface is a linear interface. Neither the user nor the application have to worry about the exact position of the pointing device over a two-dimensional surface. This makes command-line interfaces ideal for devices that have tiny screens, or whose pointing devices aren’t very accurate. It’s much easier to text a few commands on a cell phone or PDA than it is to use a stylus or manipulate a touch screen.
These first two advantages of CLIs are are well-known. The third advantage is less obvious: It turns out that CLIs are also much easier for computers to use.
Why do we care about making things easier on our silicon-based friends? Well, one reason is that it indirectly makes things easier on those of us humans that give instructions to computers. (As a programmer myself, that’s a big selling point.) Another reason is that if it’s easy enough for a computer to figure out, then it ought to be brain-dead simple for a human to understand. As I’ve pointed out before, computers just aren’t very bright.
So the advantage of having a command-line interface is that if you, a human, get bored of typing the same silly commands over and over, you can easily write a small program that instructs a computer to do it for you. This is the reason why every office suite has some kind of macro language. It allows humans to hand off repetitive tasks to a machine so that people can get on with the important creative stuff.
So what’s this about using a browser’s address bar as a command line? With AJAX technologies, the URI is no longer merely something that a human types into the address bar to get a web page. It’s also an interface that computers use to interact with data. This means the humble web URL shares most of the key characteristics and advantages of a command line interface.
It’s this insight that’s led to increased interest in the REST architectural style. REST has begun moving into the mainstream because the patterns it promotes allow the URI to serve an audience of computers as well as an audience of humans.