Make Your Mockup in Markup
24ways.org
24ways.org
Being able to nudge and push things around in Photoshop (or Fireworks, my preferred program) is invaluable. This takes away the overhead of thinking about browser related implementation issues. Don't underestimate this overhead. I find that all my designs start looking the same if I start with markup, in contrast to the more varied and interesting designs that I come up with when starting in Fireworks.
PS is incredibly awkward and unwieldy for web design. You don't realize it though, because there so few options for anything better. It was designed for photo editing and graphic work, not solving layout problems for a flexible medium like HTML.
I really do need to get some examples up there...
I'd love to write about jMockups in our blog, but I try to keep our posts limited to truly interesting apps. Could you summarise a few really unique features that only jMockups has, compared to competing wireframing and prototyping tools?
Plus using HTML elements would be boring :)
This gets at something I never understood about the start-with-PSD school of web design: if it's not possible to get the effect you want in a browser, what is it doing in a mockup?
For the record, I think the ideal situation is to sketch out your design with pencil/paper and agree on a general layout before touching any code.
When dealing with clients though, unfortunately they may expect to see pixel-perfect photoshop mockups before agreeing that a design is what they want, which can complicate things.
The reason you mock up in psd (gross) or fireworks or a sketch book (yay!) or anywhere is because you can be purely expressive in an orthogonal capacity than you would be if you were implementing in code from the start.
You ignore issues like "oh, will this p be in a div or in a series of lis contained by... blërg" while those implementation details are valid to keep in mind, they're not entirely crucial to address when you're sketching which is really the key word here.
Paper, Balsamiq, Photoshop, Code, Design Polish
That works pretty well, but I think getting things into code quicker helps to think through flows and interactions.
http://24ways.org/2009/ignorance-is-bliss
Elliot Jay Stocks also wrote a good one on side projects: http://24ways.org/2009/a-pet-project-is-for-life-not-just-fo...
Although I still think it's fine to start with PS or Fireworks first as long as it's for your own internal creativity and not something that clients or coworkers see, because then they just expect it to be xeroxed straight to the web exactly as is.
Illustrator => Markup => CSS
The strength of this is that Illustrator is extremely efficient for working on layouts at a high fidelity without worrying about pixels. You can and will try out many more layouts in a shorter time than can be reasonably accomplished in pure CSS. Then you jump straight to markup and avoid all the pixel wrangling issues with Photoshop, and you can focus on the fine refinements in actual CSS.
I stumbled upon this at my current startup because our creative director is not a web designer. This obviously comes with a lot of costs, but it also gives the designs an uncommon sensibility that lends a lot to the brand. As long as everyone working on user-facing features is somewhat competent with CSS then it works pretty well even if we spend some extra time shoehorning stuff in. The ultimate brand differentiation is worth the cost.
In other areas of design, I think the answer is "Yes", too, but not in the sense like "every programmer should know C++/Java", but more in the sense like "every programmer should know LISP".
CSS is not so much about the handcraft of designing, but more about separating design from content. This is a principle that should be applied to any kind of design, although to a different degree. For instance, the design of a poster is naturally more coupled with the contents than the design of a booklet or website with its contents.
General: The idea of separating presentation from content is useful in some contexts (including much of the web) where you need to be able to pour the content into multiple different containers. In other contexts, particularly the design of physical objects, presentation and content should be tightly connected. (You use the example of a booklet, but a booklet should be designed in a way that's well adapted to its use, and its use will depend on its content. There's no one-size-fits-all ideal booklet design.)
Specific: Even if you do want to learn to better separate content from presentation, learning the box model, or the different kinds of positioning, won't help in any but the narrowest way. There's no reason to learn CSS unless you're designing for a context that renders CSS. CSS has too many intricacies and perversions to be valuable in the abstract.
I'm not sure at what point programmer's decided that everyone needs to conform to their technologies, or why so many designers have meekly gone along with it, but designers should not have to learn obscure things like HTML and CSS simply to design. It is possible to know the limitations of a medium without knowing the medium, and more importantly, they should not constrain their creativity by these systems.
At Apple, when designers made mockups for desktop apps or iphone apps or whatever, they don't do it by hand coding it in CoreGraphics or whatever drawing technologies are being used by the programmer, they do it in Macromedia Director or Photoshop or whatever it is they're comfortable with, because it would be ridiculous otherwise.
The idea that the proper way to design is by typing text still astounds me today.
If the argument however is that regardless of the way things should be, pragmatically in today's web world you need to know CSS, then it points to a failing of CSS/HTML/web tech/tools.
As in, random variations in styling through jQuery is fine, but multiple, pinned backgrounds for IE6 is bad. (The designers I work with have it backwards.)
Whenever you start with the "limitations" and work your way "up to" the result, you end up with a fundamentally less creative product. You can see this very clearly with people who are primarily programmers: their vision is completely clouded by implementation.
This is not philosophical idealism. I've seen this first hand. Our designers at Apple on the iPhone had absolutely no idea about hard or easy on what is arguably an incredibly more constrained platform than the web, and we made it work. We'd get completely ridiculous designs and grumble about it, but sure enough if you put the work in you could get it there. On occasion did we have to compromise and go back to them? Of course: but that is part of the process. I can guarantee that the result was better because we were forced to try everything and only change it when it absolutely didn't work. And people are surprised at Apple's great design: It's really quite simple, at Apple the designers are above the programmers, the way it should be. Its this mentality that they should be making our lives easy that leads to second rate products.
This of course displays the crux of the problem: design is about the end product, not the difficulty of putting it together. What I'm hearing is less "he doesn't understand the limitations", and more "ugh, this is going to be hard to implement, can't you just give me a dumbed down easier version of this". For years (as CSS struggled to keep up), we've heard things like "do we really need rounded corners?" "is that gradient absolutely necessary". And that's fine. I get it, there are deadlines, but we're no longer talking about being a good designer in any traditional sense, we're talking about being a good deadline-meeter (which don't get me wrong, can arguably be just as important).
But let's not kid ourselves here: this is CS we're talking about, not materials science. We're not dealing with absolute physical limitations. It's putting pixels on a screen: most of the time that I hear programmers complaining that designers don't understand the limitations, what they actually mean is that they have to resort to "inelegant" code or hacks. This of course points back to the false notion that the product is the code: it's not! The product is the website. If you have to use an image because CSS won't cut, thats OK. If you have to add hacks, thats OK. Perhaps someone looking at your code will scoff, but this isn't for them, its for the person looking at the actual website.
However, when you're working with a startup for instance, as I have had the opportunity to do for my previous few gigs, you're dealing with finite financial resources as I'm sure you realize. Talking about limitations and how long something takes to build and everything is the difference between launching or not launching before the money runs out. When you're living in that world, focusing on the limitations of the platform and finding ways to solve problems with minimal resources and in a small amount of time is often what the businesses primary problem is.
If you don't know CSS, you're not a web designer and have no business building websites to begin with. You can't design properly for a medium which has limitations you don't understand.
I don't think anyone would accept a print designer being completely ignorant of what is feasible with ink on paper, especially if you are going to be using mass-produced ink in one of various worn-in press someone else is operating.
Spot on. But it's not just understanding the limitations of a given medium, but its capacities as well.
For instance, the web's capacity to scroll: http://www.designmadeingermany.de/magazin/5/
You might not know how to drive a car, but you know that a car can't fly.
As a side note, why is Photoshop re-implementing text rendering? What's wrong with the OS-provided implementation?
This is a very practical concern because PSDs are regularly opened and edited by users who may not be on the same platform as the original creator. (For example, a designer creates a document on Windows, then sends it to a print house where they need to open it on a Mac.)
I think the point - that an image editor is not what you want to use - is quite right, though. So far, Pencil and particularly Balsamiq have hit my sweet-spot for sketching things out with a degree of structure.
Here are two relevant blog posts we wrote while establishing our direction and attitude about 6 months ago:
* http://blog.quplo.com/2010/04/our-philosophy-design-in-the-b... - what designing in the browser is, why we think it's important, and some other references to thought leaders talking about it.
* http://blog.quplo.com/2010/04/why-were-not-building-yet-anot... - why we think the world doesn't need yet another WYSIWYG, drag-and-drop "prototyping" tool.
Anyway, if you subscribe to the Mockup-in-Markup idea, check out our app, Quplo. It's an online app where you write HTML and CSS and a little custom markup language specifically made for prototypes (eg. <page>, <layout>, <var> etc). You can import an existing website and redesign it quite easily; everything you make is accessible from yourprototype.quplo.com (with or without a password). If you like it, head to http://dev.quplo.com/freeupgrade for a free beta-period upgrade to a higher plan!
IMO this is the way all design is going. Older designers better learn or pick up some young talent to write their HTML/CSS