Archive for January, 2008

Canvas: Say Goodbye to Database Backends

Friday, January 25th, 2008

I’ve talked about Sketch quite a bit in recent postings. That project is humming along nicely, and will soon go into alpha testing, but it’s time to introduce the next project on our list. It’s a little thing called Canvas.

canvas_image.JPG

Our products specialise in solving problems for web designers and their clients. Canvas solves a big one: it does away with the need to create a database backend to accomplish various website functions. It’s a web designer’s tool for making reusable content.

Previously, if a client wanted a site that could repeat content in different places, display specific items of content only under certain conditions, or generate content on demand, there was nothing for it but to go to the time, trouble and expense of hiring a developer and creating a database backend. Canvas does away with all that.

With Canvas, you create reusable items using a form, and you create formats in HTML that show Canvas how and when to display the reusable items. Canvas takes these two inputs and gives the data you want displayed the way you want it. No developers, no databases, no scripts for you to write.

Webstruxure’s products empower clients as well as designers. Sketch lets the client participate in the site design and content creation process from an early stage. The simple form-filling interface of Canvas makes it easy for a client to create new reusable items for the site you’ve designed.

Whether you’re Rembrandt or Jackson Pollock, Rita Angus or Colin McCahon, Canvas frees you up to express yourself as a designer. We like to think of it as a work of art.

Small is Beautiful

Saturday, January 19th, 2008

When I’m not working at Webstruxure, I’m an author. One of the things authors like to do is list all the bizarre jobs they have done on their books’ dust jackets. You know the sort of thing:

Malachi Jevons has been a deep sea diver, alpaca farmer, test pilot, oil rig roughneck, Formula 1 driver, social worker and lie detector test administrator. He now lives a quiet life in rural Afghanistan.

My dust jackets don’t match up. Most of my career has been spent working with language: both the English language, as a technical writer, editor and proofreader, usability tester, documenter, and now blogger; and computer languages, as a programmer way back in the mainframe days.

I’ve worked for big organisations, little organisations, and those in between, and I’m here to tell you that when you’re selecting a web development company, small is usually best.

But why? Aren’t you better off dealing with the big players, with their staff in the hundreds or thousands, their battalions of account managers, their reams of legal boilerplate?

We don’t think so. When you’re working with a small company, you get to deal directly with senior staff and with the developers working on your project, not with an account manager who may have very little knowledge of your organisation and your needs.* You get personal service from people who know your name and what you’re all about (yes, I know this sounds a little like Cheers).

Small companies specialise, whereas big companies generalise. By choosing a small company, you can ensure that you are dealing with people who understand both your business need and the best way of meeting that need. That cuts down on overheads and reworking.

Nobody’s perfect, but the track record of big IT projects strongly suggests that there’s a better way. Unfortunately, in the government sector at least, procurement policies can make that better way hard to pursue. I’ll return to this issue in a later post. Till then, when you’re thinking of which company to use for your next web project, think small.

*I’m not knocking all account managers here. A good one can do a great job of keeping a project on track. But when the account manager sees their role in life as being to ensure that the client never talks directly to the designers or developers working in their project, you have a problem.

Content: The Once and Future King?

Saturday, January 12th, 2008

We all know that content is supposed to be king (or queen, if you prefer). Users may be impressed with the fancy graphics and the Flash animations the first time they visit your site, but it’s content and usability that will keep them coming back.

Yet it’s all too common in the web development process for content to be treated as the scullery boy rather than the king. Lots of people want to talk about the design and argue the toss over what size the logo should be, the precise shade of green to use in the footer, and whose photo goes on the “About Us” page. Other people realise how crucial navigation is, and are prepared to sit down with wireframes and card sorts until the site structure is sorted out.

But as for content … all too often, about two weeks before the site is due to go live, some poor schlub from the client company is told to sit down and deal with the content. If the site is new, they’ll be handed a long word processor document and told to cut it up into web pages. If the site’s a redesign, their task is even simpler: copy the content of the old site and paste it into the corresponding pages on the new site.

Problem solved, right? Now everyone else can forget about content and concentrate on important things, like ordering the canapés for the site launch party. They’ll even let the content person attend the launch, provided he or she stands at the back and doesn’t say anything.

Unfortunately, no. Major flaws in a site structure may not be revealed until someone sits down to flesh out the structures with content. But when the site launch date is staring everyone in the face, no-one wants to hear that the structure doesn’t work. “It’s only content,” someone will mutter. “What’s really important is that senior management agrees on the home page colour scheme.”

So here’s an idea: develop the content along with the structure, so that one informs the other. Use a tool that helps the designer and the client work collaboratively. Use a tool that can turn your online prototype into a basic working site at the click of a button (and the payment of a small amount of money).

Use Sketch, in other words. And it’s coming soon.