I agree with the 37Signal way of mocking up web stuff, using HTML/CSS straight-up. It’s fast, it pushes you to know your tools better, and produces layouts that can actually be solved in the medium. There is still a place for Photoshop/Gimp/Illustrator/Inkscape, however, as you still need to explore the look and feel, textures, colours, and shapes.

For my own sites, I use Inkscape sketch out new ideas. It covers most of what a web designer needs, and is freely available.¹ Today’s 10 minutes of mock-up produced a very blue, boxy alternative layout for my blog. I limit myself to 10-20 minutes of sketching, then I put it away for a few days/weeks and look at it compared to other sketches made over the year. When I find something I like, I move on to slice it into a theme.

Today’s sketch:

• Inspired by Eric Wendelin’s excellent blog. I’m thinking of a 1-column version, with the sidebar in the footer, with subtler colours (I’m not sure I can pull off his excellent bright colours).
• Background is 2 layers, one as a background colour, the second as a diagonal texture (pattern-fill, rotated + sized, at 10% opacity)
• The body is another 2 layers, one as the shadow for the second (a 2% layer blur, reduced color level)
• The header is in two parts, one for the text/menu, the second will be some sort of art (hopefully classy vectors, or a high contrast photo)
• The date callouts are a simple box combined with itself rotated (with a second layer for the shadow)
• I’m not sure about the blue, and textured charcoal is a good possibility. The blue was the first colour I picked from my current Inkscape palette (Khaki).

Download the SVG.

1. I just purchased Adobe CS3 ($1600+) for my commercial design work. It isn’t cheap, but it is an excellent set of tools. ↩

One of the projects I’m working on this year is an interactive fiction engine built in a wiki interface. The game engine uses a markup similar to wikitext, with a helpful UI to simplify building world elements. The player interface is a webified version of a z code type of game, supporting MUD features for authors who want it.

The game editor

A SVG mock-up for “thwarter”

1. The main location editor. A location is a wiki page with a bunch of state attached to it. In the mockup example, you’re looking at “The Meadow,” in its “Chapter 1″ state. The text is like wikitext, allowing you to tag other areas, objects, and so on as you write. The approach differs from zcode, allowing you to write the story parts first (and worry about connecting the programming parts later).
2. The object editor pulls meta data from the wiki page (and things you add directly), allowing you to edit their properties. All concepts in the games are objects like this, including NPCs, things, paths, and game event triggers.
3. The object editor tabs show each kind of world element.
4. The location timeline for each location shows the story states. State can be used for description of an area over time or other story variants like branches, portals, and so on. Each area can have an unlimited number of these states, allowing the author to write all of the story for one area in a single interface. World objects can have a timeline too (not shown here).

The art of prototype

I use Inkscape to mock-up user interfaces. It’s a good starting place as it’s quick, vector-based, and it uses text (SVG plays nice with Subversion). I sketch the interfaces directly in Inkscape now, skipping paper prototypes for everything but the earliest concept sketches. I sometimes take the vector drawings to completion too, polishing them, and dissecting them later with the Gimp for HTML templates.

Notice that the editor mockup has no icons or colours. It’s a habit I’ve developed over the years, limiting my thinking in terms of highlights instead of worrying about the details. I get bogged down with details early on, so I have to force myself to sideline the distractions until later. I limit mock-ups to 10-20 minutes too, to avoid getting sucked in to trying to perfect ideas early. The time for polish comes later, after I can prove the utility in the approach.

Prototyping

I am also careful while building the prototype not to get too lost in the details. The purpose is to test the viability of the interface and the initial approach. So far, I’ve discovered that I need to be able to parse the wikitext in both client and server, as well as parsing the NL text from the game interface on the server. I’m considering externalizing the parsing rules (via regex or similar) so it can be shared between Javascript and PHP, so I can provide a rich UI and storage. This complexity is a good discovery to make in the prototyping stage, as it gives me lots of time to consider alternative–and hopefully simpler–approaches.

Another test of the prototype is to see if CodeIgniter is a good fit. I’ve been pleasantly surprised so far, and have found it an extremely comfortable framework. I’m also looking at hosting needs (AWS, Slicehost, Dreamhost), considering how DNS and DB partitioning will work, and what sorts of load might be put on the system. Some of this thinking is early, so I have to try not to get stuck in it.

Level up

Next up, I’m going to start to prototype the game play interface and expand the schema. The game implies a great deal of state, something that I want to be careful to contain simply. I’m siding on partitioning the games in their own databases (or tables), especially for the live game states. A live game will have large multipliers of the number of locations, their states, by the number players and their time in the game so far. At a small scale it won’t matter, but thousands of players multiplied by hundreds of locations (and dozens of states each, dozens of variables per state) becomes a large persistent data problem.¹

1. And there I am again shearing the Yak ↩

I’ve had several hours to play with Inkscape 0.46 since it was released, and despite the minor version increment, a lot has changed.

New features

• A “fill” tool, making it trivial to turn bitmaps into vectors quickly
• 3d drawing shapes (including perspective)
• A tweaking tool, making it easy to nudge/blur/soften shapes
• Several new effects (including path effects)
• Many performance improvements, including huge improvements in blur speeds
• Better gradient tools
• Dockable tool windows (nicely done too)

I’m especially excited about the “fill” tool, as it simplifies tracing scanned sketches and logo bitmaps. The tool creates vectors using a flood-fill algorithm, based on the zoom level and configurable limits (fill method, threshold, gap-closing, etc.). In my tests so far, I’ve been able to turn pencil sketches into vectors quickly¹, as well as scans of real-world-objects.²

1. Normally tracing complex sketches takes me hours ↩
2. I created the fuji logo by scanning + fill-tracing an old, decaying T-Shirt logo ↩

A large set of handy Inkscape tips and tricks, and a forum with more of the same. I use Inkscape for most of my web design these days, as it’s mature, stable, and polished.

Today I was thinking about how to write a web app that draws comic bubbles. There are many parts and solutions to the problem. It’s one of those things that gets complex quickly, unless you’re willing to remove some of the harder features.

I need to spend some time thinking about compromise, as a perfect solution is unlikely given the tools available for web applications.

Some of the problems:

• Embedding special fonts
• Resizing irregular bubbles
• Adding/positioning bubble parts
• Positioning fonts based on irregular edges
• Clipping bubbles to strip edges
• How/where to render (client or server, svg, js, raster, etc.)

I can see a few different approaches. Each solves a few of the hard problems, and each has its own rough spots.

One approach would be to perform the rendering on the server side. Something like Inkscape could be pared down to run as a web service. Comics would be stored in SVG, but rendered to GIF/PNG to embed in the web pages. Comic authors would edit their strips using rich Javascript approximations (edit boxes over the rendered form), and readers would see the already-rendered strips. This allows for high quality rendering, for authors who wanted to go to press with their strips.

Another approach would live within the limitations of xhtml/css/javascript. Fonts would be limited, and all rendering would be done client-side. Features could be added to this as browsers matured, but would depend heavily on browser vendors and compatibility. This approach would initially limit things like clipping, available fonts, etc., but would likely be easier to build.

There are dozens of other approaches too. Flash or the canvas widget could be used, or something written in Java. Luckily I don’t have time to start today, so I’ll have to let my subconscious gnaw on it for a while.