ImageMagick: One-Second Gradient Images

Command-Line, CSS, Design, Gradient, HTML, ImageMagick, Tutorial, Web2.0

Problem: The great thing about standards-based web development is how easily you can tweak the look by modifying CSS properties. However, contemporary gimmicksconstructs like curved surfaces and gradients aren’t yet supported, which means simple tweaks – like changing a colour – usually require a round-trip between a graphical editor (Photoshop, Gimp, etc) and your CSS file. Or, you might be able to just make the change in your editor, but even that will take a lot longer than editing the CSS file, anywhere between 10 and 100 times as long (usually 1-5 minutes versus 1-5 seconds).

Solution: Generate images on the command line. Using ImageMagick, it’s possible to do tons of things on the command line. ImageMagick, which usually is executed with the “convert” command, is probably installed on your Unix/OSX machine already and your Linux web host as well (many Captcha utilities use ImageMagick to create and warp the image). It’s extremely powerful. Until today, I’d only ever used it for transformations, but now I’m using it for image generation too. Unfortunately, it’s not too well documented – the official docs are thorough, but completely lack examples (a common problem with open-source projects is documents oriented around the features rather than the typical tasks, and often in the absence of any useful examples that in this case would show how to construct a command-line). Fortunately, there’s this set of examples.

You can generate (and therefore easily tweak) logos, curved surfaces, etc, but what I’ll talk about here is gradient images. If you want, jump straight to the one-line examples below. The trick relies on several features of ImageMagick, pseudo-images, image stacks, and appending:

  • ImageMagick usually works by converting one image to another, e.g. “convert -transparent white normal.gif transparent.gif”. But we want to create an image from nowhere, so what ImageMagick lets us do is create an input image from thin air, a “pseudo-image”. To create a pure red image, we use a pseudo-image of type Canvas, mysteriously named “xc”. Go on, type this in right now to make a pure red GIF image:
    convert -size 3000x120 xc:red /tmp/red.gif

    Canvas is only one example of a pseudo-image; there are pseudo-images based on patterns, fractal generation, etc. (In fact, there is a pseudo-image called “rose:” which is actually a photo of a rose that ships with ImageMagick, a brilliant feature as it means people can write tutorials that manipulate the image without requiring you to download it.) We can generate a gradient image using a gradient pseudo-image.

  • Optionally, it’s useful to work with an “image stack” – sometimes you need more than one transformation to get to your desired image. Instead of dumping all those intermediate images in temp files along the way, ImageMagick offers a nice, clean way to build a transient image. It’s like saying “final=a+(b-c)” instead of “temp=b-c; final=a+temp” (the Replace Temp with Query refactoring :-)). A transient image is created with parentheses (example below).
  • Images can be combined together: convert a.gif b.gif -append c.gif will stack a on b vertically to output c. (+append will stack horizontally).

So how to generate a gradient image?

Simplest technique is:

convert -size 2000x100 gradient:#4b4-#bfb /tmp/greenbar.gif

Great! Now we can tweak the colour without going through all the hassle of mousing around a graphics utility.

Say we want that bar to be the top of a box, where the rest of the box is the same colour as the bottom of the gradient bar (so the bar blends directly into it). One way is to keep the gradient image as is, and alter the CSS background-color, so we have a CSS line like:

gradientBox { background-image: url(greenbar.gif); background-repeat: no-repeat; background-color:#bfb; }

That’s neat, but does require two updates each time you want to change the colour (one to the imagemagick command-line and one to the CSS). You could also generate a gradient leading to colour “none”, which means it’s transparent – still have to update the CSS to update the other colour but there’s no redundancy. Another way is to build a big image (at least during development). We can do that by stacking a single-colour image under the gradient image, using the transient image and appending techniques described above (the parentheses are escaped with \ for the Unix command line):

convert (gradient:#995-#cc9 -size 3000x120) -append (xc:#c9 -size 3000x1000) /tmp/greenbox.gif

BTW One thing about these gradient images is that GIF format (and PNG too I think) strangely doesn’t compress them at all well – increase the width from 1 pixel to 100 pixels and the file size will also increase by a factor of 20 to 50. It’s surprising as the information content is virtually identical, but the consequence anyway is that you should generally use just a single pixel wide and CSS style background-repeat: repeat-x to stretch it out.

Now you can update your bling with the touch a key!

Agreement on Sitemaps, but Who Uses it?

The good news is that an agreement has been reached on the Sitemaps protocol by Google, MS, and Yahoo! (via TechCrunch). The Google originally developed this protocol.

The bad news is … who’s using it? Supposedly Sitemaps improves ranking, but a quick sample – techcrunch, digg, odeo – found 0 out of 3 using it (404s for site.com/sitemap.xml and site.com/sitemap_index.xml).

Okay, but it’s kind of complex for a custom website to build in support … so maybe it’s down to CMSs to offer built-in sitemap support. Nup. Neither WordPress (according to this blog) nor MediaWiki (according to Wikipedia) support it. There’s a WP plugin, but …

Maybe this agreement will spur the CMS developers to support sitemaps. I’ve never really understood exactly what it offers that robots doesn’t, and I’m hoping the sparse Sitemaps website will illuminate at some stage.

Five Years On

Ivan Moore’s “Ten Years On” post reminds me of an anniversary I overlooked, it’s been five years since receiving my Photocopying Diploma, Professorship of higher Drinking, Programmership for Hypothetical Developments PhD – picked up five 339-page doorstops from the printer on the morning of September 8, 2001, signed the declarations, and it was accepted in October, 2001 (a formality as it had been through review earlier in the year).

My homepage at the time, notable for its inclusion of the charming tilde character (~) in the URL, is what my present homepage evolved from, in all its rude aqua glory, and the later stages were fortunately captured on the Wayback machine. Earliest archive is from 1998. I didn’t know much about blogging at the time (only robotwisdom which appeared in a usenet .sig), but it (along with pod/vod casting) would be a great tool for anyone performing research today.

The thesis was entitled “Design Reuse in Software Engineering and Human-Computer Interaction” – we looked at techniques for knowledge/design reuse that improve usability. The major problem in this area is a divide between disciplines. This continues to be the case in my experience – although usability is now at least a concern of some decision-makers, most organisations are still unable to do much about it because of the sensitive process requirements and the nature of the staff required. This thesis aimed to demonstrate how the issue could be improved with knowledge reuse techniques, i.e. design and process patterns, as well as other techniques like online knowledge repositories (i.e. the sort of application we now refer to as a wiki).

Here’s the abstract:

Practitioners of Human-Computer Interaction (HCI) have a wide range of techniques and methodologies at their disposal, but few avenues for reusing successful design solutions. A mature discipline of HCI requires a systematic approach to learning from past results. This thesis proposes a number of techniques for improving design reuse in HCI. Some apply specifically to high-level design while others also consider detailed software design.

The major focus is the adaptation of the pattern language concept which originated in building architecture and town planning. It is argued that the properties of pattern languages suit many concerns for HCI. This motivates an investigation concerning how pattern languages for HCI might be documented and used.

This thesis is especially concerned with highly-constrained pattern languages. Rather than producing a universal HCI pattern language, several languages are developed, each with a strong focus on a particular area. A tight scope, it is argued, provides a coherent language structure and therefore provides a strong degree of assistance to practitioners. Three such languages are documented: (a) The Safety-Usability Patterns language focuses on safety-critical systems and demonstrates how a pattern language can provide guidance for high-level design; (b) Multiple Model-View-Controller (MMVC) focuses on implementing a small set of tasks within the model-view-controller architecture, demonstrating how a pattern language can provide guidance on detailed software design and still address usability; (c) Planet focuses on internationalised systems and combines the previous approaches to mix high-level design guidance with detailed design guidance, demonstrating the interdisciplinary capability of pattern languages. Several other forms of reuse are also considered: (a) online repositories, which store knowledge about user characteristics; (b) generic tasks, which capture activities recurring across many applications; (c) reusable software components, which can be documented via design patterns.

Results of this work have been validated in several ways. An experiment with designers using generic tasks indicated that they are useful for rapid brainstorming of software functionality. A second experiment with designers using Safety-Usability patterns led to a set of guidelines for developers and pattern authors. The Online Repository concept has been demonstrated with a prototype website developed in conjunction with this project. Three programs have also been developed which exemplify most of the MMVC and Planet patterns. The results of this work are largely favourable for the techniques which have been proposed. They indicate that pattern languages can facilitate reuse of high-level design, detailed software design, and a style of interdisciplinary design that bridges the various levels of abstraction which HCI must address.

Phobos – Server-Side JS Redux

On Ajaxian, Dion points to Sun’s Phobos project, an attempt to build a new platform for server-side Javascript. Phobos came out six months ago, around the time of the May Ajax Experience.

No-one has taken server-side Javascript seriously since it died a premature death in the mid-90s. But there is great potential…

  • Server-side Javascript would allow for code sharing between browser and server. The most obvious application being validation code, but since no-one really bothers with server-side Javascript, there are probably many other patterns as well. One pattern I came up with a while ago is Dual-Side Templating, where you have the same parametized HTML template on both the server (for initial page load) and the browser (for subsequent additions to the page). I implemented the server templating in Ruby, but it would have been a lot easier if the server was running JS. That’s just one example.
  • Server-side Javascript would keep us Ajax types more sane. Right now, an Ajax developer has to constantly flip between JS and [insert favourite server-side language here]. True, you always have to flip over to other “languages” too, viz. HTML, CSS, SQL; but there’s always a special place in the programmer’s head for the core language of the day. With Ajax, you have two such languages. If those languages are quite similar (e.g. Javascript and PHP), it gets frustrating because of all the subtle differences (new Array() versus array()). If they’re different (Javascript and Ruby), you’re trapped in a Whirf-Brock disconnect, constantly flipping between two different worldviews. Slight exaggeration as it’s certainly do-able, but it would be a lot easier if programming in one main language.
  • Server-side Javascript would pose less of an issue for IDEs. With new improved Javascript, IDEs are being forced to support Javascript in order to keep up. It’s far more important than supporting SQL etc; so basically, IDEs now have to provide solid support for at least two serious languages…it would be easier if it was only one.

Now a framework like Phobos has much to offer the world compared to the server-side Javascript of the mid-90s:

  • Phobos is apparently inspired by new frameworks such as Rails. With the right libraries and improved patterns for OO, inheritance, etc, Javascript can compare admirably against Ruby. Not in every regard, but then there are actually some aspects of JS that are superior (e.g. functions as opposed to blockism; dynamic member creation).
  • There’s a lot more known about Javascript now, and it’s almost certainly the most widely understood language in the industry, even though it’s not the primary language for many (cf. English).
  • Because of all the JS code now running in the browser, there are probably a bunch of synergies with server-side JS – these could be exploited by a well-considered server-side JS framework.

As an open platform, Phobos has the best chance right now to make server-side flourish. But I agree with Dion, that there is reason for concern about whether it will happen.

Sun may already have this. Will they be able to market it? Unfortunately, the track record isn’t there, so it will probably languish. Buy maybe not.