Making Website Mock-Ups in Linux?

The Ubiquitous Web Designer asks: "I am trying to design a rather complex web page and am wondering if there are any tools which will allow me to make non-functioning mock-ups of each page so that a programmer can work from them. Obviously, it's hard to use the GIMP to make radio buttons, check-boxes, data entry fields, and so on. Can something help me design a page without much knowledge of HTML, or am I better off just doing it with paper and pencil by hand?"

Comments

Nvu

[Sodki]

Try Nvu, it's good enough.

Re:Nvu

[Tremor (APi)]

If you're just making a non-functioning mockup, who cares how lousy the code is? I agree completely if you're talking about production source, writing it by hand is the *only* way to go. But if you're just trying to put together visual mockups, and your alternatives are GIMP or pencil and paper, then clearly it doesn't matter what shape the source is in.

Re:Nvu

[Richard_at_work]

His point was that you use the WYSIWYG editor to create the initial mockup, see how it looks and feels, and then code it from hand - you throw out the WYSIWYG editors code entirely, all you are after is the visual 'OK' before starting the actual coding yourself.

Personally, I *always* mockup in Fireworks prior to doing anything. Get the look and feel of the site perfect, then handcode the html. Its significantly easier to move around something in a graphics package or WYSIWYG editor than it is in handcoded html, especially if you are doing it a dozen times an hour.

Re:Nvu

[DittoBox]

I start like this: Pen/Pencil -> Image Mockup in Photoshop -> XHTML/CSS mockup with real structure. The last step is the dove tail into the real thing. It gives me the basic starting point and gives the client a chance to see the real deal and interact with the page elements before I plug it into a back end or start replacing bits of it with server side scripting. I don't start with an xhtml page, I start on pape then move into. I probably did communicate that well in my first post.

At any rate this means I can plan out the semantic structure, and how I'm going to marry this with the CSS and design side of it. I just thought that using NVU or another WYSIWYG editor to do an XHTML mockup wasn't a good idea, especially if you're going to rewrite it by hand later. By writing it all by hand to start with most of the "code" and graphics can recycled for later use.

The problem with WYSIWYG editors is that they rarely can give you exactly what you want. I wasn't worried about code soup or ugly code, I was worried that using NVU would produce oddities in a document that can take any professionalism out of it. They can introduce spaces by creating extra line breaks, by not setting margins and padding properly, they generally are only built with a certain browser in mind (though not NVU I suppose) and generally use tags that have odd defaults in some browsers. If you copy and paste text from other programs they introduce the formatting from that application, often poorly (EG they don't just copy the ASCII text). Deleting the text in the WYSIWYG editor most often only deletes the text and not the tags or CSS, which will cause all sorts of strange text problems, spacing, lines and other garbage that can't be easily fixed. A lot of WYSIWYG editors will even introduce plenty of proprietary tags and other rubbish which might not be treated friendly by your browser(s).

The mockup stage is important to the customer/client. If it's not right and isn't professional they'll go elsewhere. In effect it does matter what shape the source is in if the source effects the visual elements in a negative way.

Re:Nvu

[TheOtherChimeraTwin]

I have to disagree. The best way to create a non-functioning web page is to use Frontpage which is only available on Microsoft Windows.

Not much out there

[Se7enLC]

In short, no.

You can technically find a tool that will let you place checkboxes + radio buttons, etc pretty easily, but you'll find that the visual design of those elements are what require the HTML and CSS skills. You're better off just drawing them how you want them to look and letting the HTMK/CSS gurus actually do all the coding, otherwise all the work you do making them look how you want will have to be redone anyway in code.

just the thing

[greenguy]

Inkscape is perfect for this sort of thing. I've used it many times.

Re:just the thing

[legoburner]

I'll chime in with another vote for inkscape. Takes some getting used to (basically think gimp for vector images), but is very good for this sort of thing.

Re:just the thing

[MankyD]

I was just about to say the same thing. Inkscape (or any vector editing software) is perfect for this sort of thing. You won't draw perfect radio buttons per se, but draw circles with as much or as little similarity to radio buttons as you want. This is what I do for all of my sites after I've created an initial idea.

My Method:
1) Paper and Pen
2) Inkscape / Vector editor
3) HTML

Re:just the thing

[SpectreHiro]

I agree with the parent. Vector is by far the easiest way to produce mockups, and Inkscape is an excellent program. However, I'd also like to throw in a recommendation for Xara Xtreme which got slashdotted a couple days back. I'm quickly falling in love with it. I initially started using it because I couldn't get the newest release of Inkscape to run... Now, I don't think I'll be going back.

Paper Prototype instead

[kognate]

Please do not do what you've asked about doing. Instead, pick up a copy of Paper Prototyping at http://www.paperprototyping.com/ then read it, and then you will save yourself a huge amount of time (much more than the time you take to understand the concept).

Your users will thank you.

Re:Paper Prototype instead

[6Yankee]

Seconded. HTML mockups, whether hand-coded or bastardised together in something like Dreamweaver, are too much like hard work. I've also found that if you email them, or put them up on a site for users to look at, people forget that these are mockups and bitch about the things that don't work yet. As long as whatever you use is obviously not a web page, and a programmer can make sense of it, it doesn't matter what you choose.

I would say paper prototype, and use the chance to get some user feedback before you've poured heart and soul into a full-blown mock-up (or, worse, application). You'll probably find it easier to accept when these crude user tests show up problems - once you've got too much emotional investment in your design, it's far harder not to come up with reasons not to change it.

Of course, some people won't believe in paper prototypes. (I have one or two of those around here.) The compromise that works best here is to use - ick - PowerPoint. You might want to use whatever the OpenOffice equivalent is. As long as whatever you use is obviously not a web page, and a programmer can make sense of it, it probably doesn't matter what you choose.

Re:Paper Prototype instead

[Tim C]

HTML mockups, whether hand-coded or bastardised together in something like Dreamweaver, are too much like hard work. I've also found that if you email them, or put them up on a site for users to look at, people forget that these are mockups and bitch about the things that don't work yet.

On my current project, we had an interface developer create an HTML "demonstrator" - essentially, a non-functioning HTML mockup of the site. You could click through a single, typical use case, and it showed you how things would look.

The client loved it - it really gave them a feel for how it would look, how it would work, etc. It also gave them a powerful tool to get buy-in from their sponsors and other stakeholders, who had been somewhat sceptical at first.

However, it was a lot of work. Also, some people did expect rather too much of it, expecting some dynamic stuff (such as sorting of search results) to work. Yes, we could have mocked it up, but the amount of work involved would quickly have become unmanagable. One particular person on the client team was also an absolute stickler for realism of the data, yet refused to provide representative samples (real data couldn't be used, as it's classified); this burnt more time than was necessary.

On the other hand, when it came time to actually build the site, the HTML was already done. All that remained was to tidy it up a bit, slice it up into templates and integrate it with the code.

All in all, it was a useful exercise both for us and for the client, but it was also a time consuming and at times painful one. It's definitely not something I'd recommend for every project.

Paper and pencil

[Doctor Memory]

On one project I worked on, we did a user interface JAD session that consisted largely of hand-drawn diagrams. When the users made a suggestion, we stuck a Post-It note over the part of the page that needed to be changed and drew in the suggested change. Incredibly fast turnaround, and we weren't restricted to whatever we could render in HTML. After the session, we went back and coded up some mock pages in HTML and curculated those as an appendix to the meeting minutes so the users could comment on what the "real" interface would look like. It's not too hard to write up some JavaScript to wire a few dozen pages together to produce a prototype that exhibits a lot of the behavior of the proposed system.

Sounds like a job for denim

[afd8856]

Java tool, optimized for tablets though. http://dub.washington.edu/projects/denim/

These are the steps I follow

[dduardo]

1. Rough sketch on paper
2. Draw the complete layout in Inkscape
3. Export elements into the Gimp for final touch up and optimization
4. Link to images in stylesheet

Inkscape is an excellent tool becuase you can scale you're elements as much as you like without losing quality.

One place I worked...

[blueZ3]

Had a design template in Photoshop that contained all the graphics for buttons, checkboxes, text fields, etc. The designers just grabbed elements from the template and used them to mock up their design. I don't see any reason you couldn't do the same thing using the GIMP.

You should be able to grab screenshots of the elements you want out of Firefox and then reuse them in your layout. The only "hard" part is that for objects that have variable sizes, you have to grab the right and left sides and the middle as separate elements. Then for a "wide" button you stretch the middle portion to the correct width for your text and then place the right and left elements on the sides.

This may sound like too much work to you, but keep in mind that once you have captured all the parts you need, you can reuse them on future projects of a similar sort.

Whatever works . . .

[Evardsson]

When I worked as an HTML code slave, I would get mock-ups done in Photoshop, GIMP, pencil and paper, Dreamweaver, Word, Publisher, Open Office, whatever. What it all boils down to is that you need to work the way you work best and leave the coding up to the coders. If you are most comfortable doing your mock-ups in crayon, then do them in crayon. The important thing is to be sure that you have gotten your ideas across clearly and plainly, and have a little faith in your coders to do the job. If you can't trust them, then maybe you need new coders. o_O

Paper!

[Peganthyrus]

Paper-making is not a closed source process. You won't be betraying the ideals of the open source movement if you pick up a pen or pencil and just start doodling.

You can probably do a couple iterations on your design in the time it takes you to install and boot up any software package. Hand the best one to the programmer, or scan it and e-mail it to her.

why not use xfig?

[belmolis]

If you just want to show layout and don't want to draw by hand on paper, why not use xfig or some other diagram-drawing program? If you do a lot of this and want higher quality drawings, you can create a library of objects.

Inkscape works great

[mattnuzum]

Inkscape is a great tool. I recently revised the www.bazaar-vcs.org website. My SVG mock-up is here: http://people.ubuntu.com/~mnuzum/projects/bzr/BZR% 20Concept2006-07-26-1.svg (open it in inkscape for the real effect).

I plan on documenting this process soon, because I know a lot of people ask about it, but here's what I do:
  * Get the newest version of inkscape that you can, they really are adding excellent new features with each release
  * Open a new doc and assuming 1024x768 target browser size set the document to 1000x600 px. For 800x600 go for 760x600px
  * Use the layers tool in Inkscape to separate portions of the document
  * Create a layer on the very top called "slices" and in this layer, create rectangles that are 10% opaqe or so that cover individual elements that will become images in the final product. This layer will usually be hidden.
  * Periodically save your document out as png... remember, most people have a screen res of *96 dpi* not 72.
  * When you want to save individual components, for example the logo in the example above, show your "slices" layer, click the square that covers your logo so that it's selected, then hide the slices layer. The square will be selected but hidden. When you choose export, it will export just the visible portion of the image you have selected.

I'm happy to give more details, I'm newz2000 on irc.freenode. I don't have a lot of time to chat, but ping me and I'll help out if I can.

Once we get guasian blur in inkscape I'll probably stop using photoshop. (Yes, I run photoshop in Linux - using crossover office)

Re:Actually, it's not hard in Gimp, but...

[try_anything]

That's not what a web designer does. You can only get it right down to the pixel for users running a single browser at a single screen resolution with a single set of browser settings. A good web designer has to understand what a web page is and design to its strengths and weaknesses, not pretend that he's doing design for television or print media.

Re:Actually, it's not hard in Gimp, but...

[mini me]

A designer's job is to design to the medium. This requires that they have a working knowledge of HTML/CSS/related technologies. Just like a print designer must have a working understanding of paper. You don't expect the print-press operator have the designer's animated GIF run on paper.

Re:A Constructive Observation.

[dhasenan]

He's looking for fast prototyping, and he doesn't need functionality. He can ostensibly do the work in HTML, though that isn't his job; he just doesn't want to spend a week or two developing a prototype when he might be sending out a dozen for a single job. It's inefficient.

The newly open sourced...

[mav[LAG]]

...Xara Xtreme. Yes I'm biased. I used Xara 1.5 to create production quality graphics for a magazine nearly ten years ago and I still haven't come across an illustration program that was as fast or as easy to use until I grabbed the latest build of Xtreme. See here for the Web-specific features. Ignore the Windows-only requirements menu - there's a very stable Linux build in the Downloads section.

For a nice quick design prototype, I'd love to hear if there's anything better.

You are better off not doing it at all.

[LWATCDR]

Find a real web designer. And not I am not being mean.
CSS/XHTML imposes limit on what fonts you can use and what is possible and what isn't
Not only that but you have to make sure it runs on standards compliant browsers and hunk of trash that Microsoft calls IE.
it is the height of arrogance to think that you can design a web page and no nothing about HTML. Kind of like someone that can't change their oil thinking they can design a car.
Find a web designer and tell him what your page needs to do. Then work with them until you like it.
Do not give him a pretty picture and expect him to get it to render on every browser and resolution on the planet.