Sketching With HTML5 And CSS3

Before getting into a specific sketching example, there’s one last another thing I want to do in my template: add the <header> and <footer> elements.

Typically, for web application sketches, the <header> is where your branding goes. (And while you might be saying “Yeah, yeah, of course.” it’s important to block out a place for the application’s brand, especially if your application will be white labeled. If that’s the case, you should include a lot flexibility in your design, to anticipate a broad variety of branding styles. Chances are small that your customer’s brands are similar and will take up a similar space in your layout. Or you could do a quick survey of your customer’s, and potential customer’s, brands. What do you think that their branding standards manual will allow? )

The header could also include application navigation, utility navigation, log in status, and a log out control. All of these application controls will have a relationship with the brand. More reasons to think about how that is going to work.

At the other end, in the footer, you might include any copyright and trademark information for your company, repeat your application navigation, and maybe, just maybe, may take some of that meta information about your sketch that you put in the comments, and include it in the View not just the Source, like a blueprint has information about itself.

Lots of helpful information about the header and the footer element is out there. Now about that <div>…

For a quick sketch of a web application interface, it’s been my experience that you want to be able to grab everything that’s not in the header and footer, and work with it as a single unit. While, by process of elimination, you can identify everything that is in the main content area (i.e. anything not in the header or footer), managing that stuff as individual elements is best left to production implementations, where you have time to plan it out and comment it in. Want to work with the main page content area adding a margin, or padding, or border? Wrap it in a div, and go. 

We know that we can still use the <div> tag. Okay?

And why, exactly, is the <h1> and the <p> not in the header? Because, again, this is the habit I’ve gotten into from previous web app work. In another project, it might make a lot of sense to keep the page title and instruction in the header. But web applications - where you are asking the user to move page to page to complete their task- the page title and introduction are critical parts of the user answering the question, “Where am I?”. Don’t hide it in the header.

Just to make the point more generally, if you’re looking for hard-and-fast, right-and-wrong rules for using HTML5 elements, this series isn’t the one to be reading. Like a sketch, these ideas are loose and meant to be adopted and rejected as needed. Having a <div> wrapping the main content area of the page has let me work faster, especially when I start to work on the look and feel of the sketch via the CSS.

Which is coming up next (when we get to calling the <div> “main”).

Sketching With HTML5 And CSS3

If you followed any of the links in the last post, you will have seen that HTML5 (and CSS3) are working drafts. They’re not done. Not. Done. Depending on who you are reading on the interwebs, these drafts will be done in 12 years, or you can use some of them right now. The answer is somewhere in the middle. Depending on what has been implemented in the browser you are using, you can work with some (or none) of the features of HTML5 and CSS3.

This is why HTML5+CSS3 so well suited for sketching. Both are a test, an exploration, a proof-of-concept, a draft. There is a strong synergy between these working drafts and a sketch. That you are sketching with features from a working draft puts your work in the right context.

While it can be argued that neither of these specifications are ready to support production applications (although others might disagree, all you need to know for your sketches, all you need to ask, is “Can I sketch the design I need to demonstrate?” A lot of the time? Answer = yes. 

There are well implemented parts of these specifications that will certainly speed up your work, like a non-repo blue grid on your paper. For example, the <header> and <footer> in HTML5 give you well defined, semantic elements that help you quickly organize your page’s content. Or the border-radius property in CSS3 - a much easier, and faster, way to implement rounding rectangles than any method preceded it.

Keep in mind that  to demonstrate a particular feature you may have to pick and choose what browser you are viewing your sketch in. As of this post, Opera is the only browser that supports <input type=”date”> and <input type=”time”>, but if you need a quick date picker, or time picker, dropping these elements in your sketch, and viewing them in Opera is a really, really quick way to go.

For these posts, I’m using the nightly build of Webkit to view my design. You could just as easily choose the IE9 beta, or the Firefox 4 beta, depending on what features you need for your sketches. Your choice.

But head’s up, things change. Look at what the WebKit blog told us last Friday

Over the past several months, the CSS Working Group has had extended discussions about making the gradient syntax easier to use, and recently Tab Atkins included a proposal in the latest draft of the Image Values and Replaced Content module. WebKit and Mozilla have now implemented this proposal so that web authors can experiment with it, and provide feedback to the Working Group. Note that the proposal is still an editor’s draft, which means that it’s still possible, and even likely to change due to user feedback.

So proceed with caution, if you’re uncomfortable sketching in a (kind of) volatile medium. Like can of markers where some of them have dried up, and you never really know which ones, just be ready to drop that marker, and pick up another one.

Here’s a cheat sheet:

• IEBlog
• Mozilla Developer Network
• Opera Desktop Team
• Surfin’ Safari

Sketching With HTML5 And CSS3

If it isn’t intimidating, a blank page is inviting. Everything you need is there, waiting to be drawn out. A blank page is a unit: a window, a frame, a dialog, a screen, a cell, or, well, a page. A blank page is part of whatever document you are working on: a wireframe, a storyboard, a mockup, a prototype, or, maybe, just an idea.

A blank page is inviting (if it isn’t intimidating) because you chose the paper. You like that sheet of tabloid paper folded in half, or that green engineering paper, or that blank legal paper grabbed from the photocopier, with holes punched up the side for a three ring binder. The paper works for you. So does the pen, or pencil, or marker, but that’s a whole other thing.

Which gets us, in a roundabout way, to the HTML5+CSS3 sketch. Where’s the blank page? Because it isn’t here:

and it isn’t here:

With an HTML5+CSS3 sketch, you have to remember that you’re working with three files (more on that later) and two windows: the View and the Source. With a blank sheet of paper everything is bundled up into that one sheet, it’s the View and the Source. So it’s frustrating to look at the browser and see a blank page, but not be to work with it, not be able to sketch right there.

The first thing you have to do is, in your head, split what you’re doing into those two views, like when you’re drawing and it’s being projected on the wall, and you’re looking at the projection as you draw. Source and View. Your browser is the View, where you see your sketch. And your text editor is the Source, where you make your sketch.

The next thing you have to do is to create a file, a template you can use over and over, like a pad of your favorite paper. As time goes on, your template will change, or you’ll start to use two, or three templates. Just like when you switch to different paper. Call it whatever makes sense to you. For this post, I’ll call it:

sketch-template.html

With HTML5, starting your blank page is a lot simpler than it used to be. After you save your template file, all you need to do is add this:

<!DOCTYPE html>

<html>

Done! (Okay, not really, but you’ve just declared what your page is.) You also will need the document head, (with a couple of lines in it we’ll talk about later):

<head>

<title>Sketch Template</title>

<meta charset=“UTF-8”>

<!- -

<link rel=“stylesheet” href=“main.css”>

<script src=”main.js”></script>

- ->

</head>

And you need the body:

<body>

<h1>[PAGE_TITLE]</h1>

<p>[PAGE_INTRODUCTION]</p>

</body>

</html>

and now you’re done. For now. There’s the beginning of your blank page. Depending on what you like to put on your page, there may be a couple two, three things you want to add at the top of the <head> element, just below the <title> element, but these are just comments in the source:

<!- -

PROJECT: your-project-name-here

AUTHOR: your-name-here

CREATED ON: date-file-was-created

LAST EDITED: date-file-was-last-edited

- ->

There’s more you can add to these comments in the head, a version number, or a client name. If your template is going to end up in a version control system, then you may not need to do any of this, version control will take care of if for you.

But right now, that’s it. This is just a blank page that you’re going to use for a sketch. Like an endless pad of paper, waiting for your ideas, good and bad (No throwing away!). There you go. Blank page:

More next time.

If I had a choice, I’d probably be sketching most of my IxD work.

Because once you get over yourself and stop throwing out the drawings you don’t like (Stop. Just stop. None of them are that bad. I promise.) you can take a pad of Stickie Notes, hang a day’s work on the wall, and start a review - or critique, for you fellow art school types.

In the conference room, in the hall, on the windows, it doesn’t matter where you hang them. As soon as you get people looking at the drawings you’re moving forward. Good solutions are marked, bad ideas are flagged and, most importantly, the things you just completely missed are pointed out. Now you’ve started a conversation on the IxD. Next iteration, please.

Drawings are cheap, portable, accessible, tactile, iterative, transparent, and easy to learn. Can you write the alphabet? Then you already can draw most of what I’m talking about. There’s lots of good resources out there, like the VizThink discussions, or the Interactive Sketching Notation system, or the examples at I Heart Wireframes that you can refer to. And while I’m not the marker expert, in the past I’ve been able to get my marker sketches to a fidelity where the developers on the team could build from them.

On the other hand.

There’ve been the times where the drawings didn’t work. The projects where documentation had to be more formal (think Big Government formal), or the projects where time and distance had an impact (think half of the team is an ocean away). These are the projects where the drawings don’t seem to have enough information, enough detail, to get the conversation started. These are the projects where you end up building out lots of wireframes in Visio, Axure, or InDesign.And while I have nothing against using any of these applications - I’ve used them, they’re all great, and they get the job done - they all have one thing in common: they cost a lot.

I know, I know. If you’re working at a Microsoft Gold Partner you probably already have a license for Visio that your team can use (and a license for SketchFlow which you should use). There are student teacher discounts on CS5 if you’re still in school. But if you were looking at your department’s budget with Axure at about $600 per seat, Visio at about $600, or $1,000 per seat, and CS5 at $1,700 to $2,600 per seat (I have never known anyone to buy just a single application out of the Creative Suite. “Come on, for just a little bit more we get Photoshop. Photoshop!”) you might start thinking about alternatives. Free alternatives.

Here’s the deal.

With this stuff? I’m cheap. I’ve been thinking about ways to not spend all this money. Okay, fine, I’ll be honest. I’ve been thinking about spending all this money on Copics and engineering paper. In the meantime, I look at my RSS feeds and they are filled with what’s going on with HTML5, CSS3 and the latest browser daily builds, specifically WebKit’s.

So I’m going to try something. An experiment. I’m going to see if I can translate what I do with pencil and paper into higher fidelity HTML5+CSS3 sketches. I feel like the wins in cost to the project, in transparency across the team, and in removing the problem of wireframes as disposable artifact are there.

Let’s find out.

To open, tear across dotted line. This is the dotted line.