Good catch on how us designers hack websites together-"Positioning a gray colored copy of a layer just below the layer, to get shadow effect." Looks like you certainly solved this problem. Cool stuff!
Now how about hire a little army to manually split my page to pieces, make it compatible to get markupwand to work, then give me back the whole page as if you did it all by magic. Imagine the premium I'd pay for that!
I don't have much experience with prototyping-with-PSD...how standardized is that process among designers? This is a neat tool but it seems like it might be very dependent on good practices by designers, and seeing how adherence to best practices -- in naming conventions, file types, layer arrangement, etc -- can be highly variable among coders, I can only imagine what it's like among pure visual designers.
As a designer, I've never "implemented" in Photoshop. Ever. Illustrator, yes (a long time ago), but there's nothin' like coding your own design.
In fact, I design entirely with HTML/CSS (using the Live CSS Editor feature of the Web Developer add-on for FireFox) and use Illustrator to mix and pick colors.
I remember years ago when I had the revelation I was wasting time designing so much of the site in photoshop and that I could design much more usable and "organic" sites in HTML. I became adamantly HTML/CSS-first, using photoshop only for graphics.
These days I tend to do more of a mix, I like the expressive freedom of photoshop and the rigid grid structures and typography of HTML.
But I almost always start in photoshop after mocking. Probably from habit.
@dmix: Totally feel you on "organic HTML". Yes, Photoshop is a fabulous tool for making graphics, and playing with ideas... but something about handwritten code feels really good.
I cannot tell you how much I wish all designers worked this way. I spend more time cutting PSDs than I do building the backend of the site (which is what I am actually hired to do).
Yep, every web development job I've ever had has required me to get Photoshop installed, usually sooner rather than later. Then the company moans and drags their feet about licensing costs etc. My current Mac has one old cracked version of Photoshop, one version with an expired trial, and the Gimp...
I always find this sentiment funny. As a programmer, and one with 15+ years of HTML/CSS experience, I find it much easier to layout a website design in Photoshop. That being said, I usually jump to markup about 2/3rds of the way through the design. Everyone has a different comfort level, I suppose.
I find myself jumping in and out of Photoshop all the time. Quite often I'll have a working design in HTML/CSS, then as the requirements change, take a screen grab of the page in the browser and start pushing things around or laying new elements on top.
I used to always start in Photoshop and when I had 2/3rds of the design start coding. But since I started using CSS3 attrs like 'box-shadow', 'border-radius', etc. I only open Photoshop for tweaking icons, patterns, gradients; but never to design the actual page.
Exactly. Not taking advantage of what you can do - and how easy you can do it - in the code right away just means more time wasted. Once you get the basic layout out, all Photoshop is good for is finding the colors you're going to use (which a lot of times, tools like Colllor in addition to preprocessors with color functions can supplement) and quickly prototyping something just to see it (which is easier in Illustrator, anyhow).
With things like this and CSSHat, I fear that people will use these tools not to learn from, but to immediately sell themselves as devs and further worsen the state of an industry that's already lost its passion for the combination of art and experience by cutting all corners possible.
Right? I spent a good chunk of time trying to figure out who was behind it so I could send them some money, but couldn't. They finally added a form so I hit them up to put a donate button on there. If it interests you at all, I try to put all of the color and general prototyping tools I find on my snip.it -- http://snip.it/collections/1064-design--development-web
You are right. Lot of designs we have seen doesn't have good naming conventions. We are trying hard not to enforce it as it requires to change their work-flow. While generating pages, we do not consider layer set organization/naming.
Depends on how you work… Photoshop use is not really standardised, it’s just that you are expected to put individual elements in individual layers.
Large web consulting forms expect the visual designer to work this way, to drop a PSD that they can then convert to a template for their CMS… But working in this way you’re relegated to a role of providing a visual look, not really designing the interaction of the site…
Also on a technoligical level it becomes harder tot exploit the possibilities of javascript etc. if you think in a static fashion. if you want more influence you either need to work in a more ping-pong fashion with a developer, or develop yourself.
In both cases I find myself rarely using Photoshop, preferring an iterative process, with sketches on paper and in HTML.
As a visual designer who has learned to code, I feel that this is not a good idea for the simple fact that it outputs non-semantic HTML (divs are not semantic HTML) and CSS "class soup".
I am all for getting more designers to output code (thus saving a lot of developer time), but these sorts of things not only reinforce non-semantic (& unmanageable) coding practices, but also handicaps those who use them by not teaching them how the web works.
How on earth are div's non-semantic? Most things on a page are just "boxes" -- not lists or links or images or paragraphs, just boxes. And div's are the correct thing to use in this case.
Also, "class soup" is a proper CSS programming practice in many people's opinion -- many CSS style guides explicitly state that it's preferable to use descriptive class names in CSS rules, rathen than element names.
Mainly because, as a site evolves, changing a single element name might break your entire CSS rule structure, while basing your CSS on class names makes everything much more robust and maintainable.
> How on earth are div's non-semantic? Most things on a page are just "boxes" -- not lists or links or images or paragraphs, just boxes. And div's are the correct thing to use in this case.
Because most things on a page are not "just boxes". <header>, <article>, and <footer> are not "boxes" -- they have semantic meaning.
> Also, "class soup" is a proper CSS programming practice in many people's opinion -- many CSS style guides explicitly state that it's preferable to use descriptive class names in CSS rules, rathen than element names.
Everyone is welcome to their own opinion, but I'm of the persuasion that the fewer CSS rules the better. Not only does fewer CSS rules mean that there are fewer things to remember when styling a page, it also means a smaller file is requested.
It's better to use HTML like this...
<article>
<hgroup>
<h1>Page title</h1>
<h4>Written by so-and-so in such-and-such categories.</h4>
</hgroup>
<p>This is a paragraph.</p>
</article>
... than like this ...
<div class="content">
<h1 class="page-title">Page title</h1>
<div class="meta-data">Written by so-and-so in such-and-such categories.</div>
<p>This is a paragraph.</p>
</div>
There is so much more semantic meaning in the former bit, than the latter.
Too, semantic HTML can help with SEO.
> Mainly because, as a site evolves, changing a single element name might break your entire CSS rule structure, while basing your CSS on class names makes everything much more robust and maintainable.
No need to argue with that. Building web apps is a whole other animal, and (having used Bootstrap) I can see why using lots of classes could be beneficial in certain situations.
However, I am still of the opinion that semantic HTML > "class soup".
You're right that a bunch of divs like this is non-semantic. Anyone who thinks otherwise is crazy.
As far as the classes goes though, I would recommend that you check out a style like OOCSS or SMACSS (which I prefer) and give it a shot on a project. I style almost everything with classes currently, and I've found it much easier to maintain and extend than the style that you're describing.
It's a personal choice obviously, but I think you should definitely give it a shot and see what you think.
I've been wanting to try out a number of pre-processors, but I haven't figured out a way to be able to edit it live (which REALLY speeds up development).
However, I'll definitely give SMACSS another (more thorough) look.
Semantic html is overrated in my opinion. As if every web page or application could semantically fit the header, article, footer, summary, section, nav, menu paradigm. I'm not against it, but probably, we will have another set of semantic tags in 5 years, and 10 years later yet another set of semantic tags.
Not every, but 95% do. For the rest, there are other pssibilities and tools to make sense of it (microdata, ARIA attributes, etc). Just ignoring semantics altogether won't do any better.
> As if every web page or application could semantically fit the header, article, footer, summary, section, nav, menu paradigm
I know, that's the whole thing I'm talking about. A page is full of the div inside the header that centers the header. Then the header has three horizontal bars, two of which are split into right and left side, each of these are full of multiple kinds of items...
These are all <div>'s, and are supposed to be, and they usually make up the majority of elements on any reasonably complex page.
This is very wrong, divs are as semantic as you want them to be. If you have an element that looks like this:
<div>
<div>
<div><p>Hello World<p></div>
</div>
</div>
Then yeah sure it's not semantic because you have two unnecessary divs holding a paragraph, but if it was just the one div holding a paragraph tag it would be perfectly acceptable in HTML 4.x onwards. The only cases I can see a div being non semantic are the silly example I gave above, self closing divs in HTML (not extensible) and empty divs.
<div class="content">, <div class="post-title">, <div class="meta-data"> all have semantic CSS class names. But they are not semantic HTML names. Remove the CSS, and all you have is <div>, <div>, and <div>. This makes it difficult for screen readers (and web surfers who don't use CSS (are these people even real?)) to understand what the page is saying.
However <article>, <header>, and <aside> all have semantic meaning that can be discerned whether or not CSS is used.
Also: Whether or not something validates is not a good indicator of it being "semantic".
You cannot use ONLY these "meant to be" semantic tags (<article>, <header>, ...) to describe semantically all the content you have.
Divs is then the only way to go I know.
"Not every, but 95% do. For the rest, there are other pssibilities and tools to make sense of it (microdata, ARIA attributes, etc). Just ignoring semantics altogether won't do any better."
Your understanding of semantics is a bit hazy. Conversely to the pull quote you grabbed from me any semantic element can be used in a non-semantic way.
How on earth does this not use absolute positioning, but actually figuring out the full width of text boxes, whether they are expandable vertically or not, etc.?
I'd love some insight into the technique.
I mean, I work with designers who often don't even know what their intention was in the first place, what should happen if a line of text turns into two...
I've just seen that some of the technique/some of your questions are answered after sign up! I'll c/c here for your convenience (without the explainations and examples available on sign up)
Five tips given on the website to get good results (I have not tested myself) :
- Break your page into smaller pieces (header = 1 .psd, same for body, footer, sidebar, etc)
- Use one text layer for each logical piece of text
- Each icon or image should be a single layer or a smart object
- Want CSS buttons? Use shapes; not images.
[edit] I know there's only four. Fifth being avoid any hacks, it's probably not understandable by someone not really very familiar with Photoshop. Or I just couldn't figure out what photoshop-design-hacks are used by actual webdesigners.
Sorry about the fifth point not being clear. Will try to make it clear.
Some designers produce effects using indirect methods instead of using the photoshop effects. These should be avoided as much as possible, for the code to be clean.
I can see this as a great product for designers who would like to code, but don't have the time to learn. Now they can take this instant output and simply tweak it, which is a lot simpler than to learn from scratch. Great job guys!
This is really impressive, but I'm very hesitant. Obviously this html output won't be useful until you can modify tags, and as far as the CSS goes, this is not really ok:
Probably because chrome (and/or ff) doesn't handle decimal point sizes well (18px =~ 13.5pt) 13pt works fine though, as does 14pt (after adjusting the word break)
I just tried it out with a .psd, the downloaded zip contained what appeared to be other users projects. This may be disconcerting to some, and will hopefully be quickly addressed.
The tool, however, is very impressive. I'll try to respond with a list of bugs I notice once I figure out how to fix them through hand-coding. Good work!
This is definitely a problem worth solving, and I am glad these guys are doing it. I've worked with designers who hated doing, and developers are not fond of it too. As it improves, it has lots of potential.
Are you guys looking into methods that don't apply widths and pixel-perfect margin/padding to everything? Obviously much harder, but until these converters can do that they just aren't substitutes for handwritten CSS.
I almost never define a fixed width for elements. Here every single element has a fixed width.
128 comments
[ 4.6 ms ] story [ 205 ms ] threadHow does it know to put clever class names like ".social-actions"? Is it gleaned from layer metadata or something?
It has a editor which quickly allows you to name classes (Screenshot: http://cl.ly/image/0q2O0O0y2B1P)
Now how about hire a little army to manually split my page to pieces, make it compatible to get markupwand to work, then give me back the whole page as if you did it all by magic. Imagine the premium I'd pay for that!
Splitting page into pieces is only a temporary fix. We are working on getting the entire page work (automatically), it will be out pretty soon :)
For prototyping, its either gomockingbird, balsamiq or some quick HTML (plus the odd photoshoping) to simulate interaction.
In fact, I design entirely with HTML/CSS (using the Live CSS Editor feature of the Web Developer add-on for FireFox) and use Illustrator to mix and pick colors.
These days I tend to do more of a mix, I like the expressive freedom of photoshop and the rigid grid structures and typography of HTML.
But I almost always start in photoshop after mocking. Probably from habit.
With things like this and CSSHat, I fear that people will use these tools not to learn from, but to immediately sell themselves as devs and further worsen the state of an industry that's already lost its passion for the combination of art and experience by cutting all corners possible.
I actually started doing it this was because products like TypeKit don't supply the fonts to use in anything other than the the web browser.
I don't think it's the case any longer that to be a designer you have to be tied to a particular piece of software to produce your work.
Disclosure: I am not owner of moqups. Just an enthusiastic early adopter/evangelist ;)
Large web consulting forms expect the visual designer to work this way, to drop a PSD that they can then convert to a template for their CMS… But working in this way you’re relegated to a role of providing a visual look, not really designing the interaction of the site…
Also on a technoligical level it becomes harder tot exploit the possibilities of javascript etc. if you think in a static fashion. if you want more influence you either need to work in a more ping-pong fashion with a developer, or develop yourself.
In both cases I find myself rarely using Photoshop, preferring an iterative process, with sketches on paper and in HTML.
I am all for getting more designers to output code (thus saving a lot of developer time), but these sorts of things not only reinforce non-semantic (& unmanageable) coding practices, but also handicaps those who use them by not teaching them how the web works.
Also, "class soup" is a proper CSS programming practice in many people's opinion -- many CSS style guides explicitly state that it's preferable to use descriptive class names in CSS rules, rathen than element names.
Mainly because, as a site evolves, changing a single element name might break your entire CSS rule structure, while basing your CSS on class names makes everything much more robust and maintainable.
Because most things on a page are not "just boxes". <header>, <article>, and <footer> are not "boxes" -- they have semantic meaning.
> Also, "class soup" is a proper CSS programming practice in many people's opinion -- many CSS style guides explicitly state that it's preferable to use descriptive class names in CSS rules, rathen than element names.
Everyone is welcome to their own opinion, but I'm of the persuasion that the fewer CSS rules the better. Not only does fewer CSS rules mean that there are fewer things to remember when styling a page, it also means a smaller file is requested.
It's better to use HTML like this...
<article> <hgroup> <h1>Page title</h1> <h4>Written by so-and-so in such-and-such categories.</h4> </hgroup> <p>This is a paragraph.</p> </article>
... than like this ...
<div class="content"> <h1 class="page-title">Page title</h1> <div class="meta-data">Written by so-and-so in such-and-such categories.</div> <p>This is a paragraph.</p> </div>
There is so much more semantic meaning in the former bit, than the latter.
Too, semantic HTML can help with SEO.
> Mainly because, as a site evolves, changing a single element name might break your entire CSS rule structure, while basing your CSS on class names makes everything much more robust and maintainable.
No need to argue with that. Building web apps is a whole other animal, and (having used Bootstrap) I can see why using lots of classes could be beneficial in certain situations.
However, I am still of the opinion that semantic HTML > "class soup".
Edit: I accidentally a word.
As far as the classes goes though, I would recommend that you check out a style like OOCSS or SMACSS (which I prefer) and give it a shot on a project. I style almost everything with classes currently, and I've found it much easier to maintain and extend than the style that you're describing.
It's a personal choice obviously, but I think you should definitely give it a shot and see what you think.
I've been wanting to try out a number of pre-processors, but I haven't figured out a way to be able to edit it live (which REALLY speeds up development).
However, I'll definitely give SMACSS another (more thorough) look.
I know, that's the whole thing I'm talking about. A page is full of the div inside the header that centers the header. Then the header has three horizontal bars, two of which are split into right and left side, each of these are full of multiple kinds of items...
These are all <div>'s, and are supposed to be, and they usually make up the majority of elements on any reasonably complex page.
Semantic HTML makes the web a better, more consistently understandable, place.
Back when I was learning how to code my own HTML/CSS, I really could've used something like this to help understand how HTML/CSS works together.
Being able to edit tags is a great feature :-)
This is very wrong, divs are as semantic as you want them to be. If you have an element that looks like this: <div> <div> <div><p>Hello World<p></div> </div> </div>
Then yeah sure it's not semantic because you have two unnecessary divs holding a paragraph, but if it was just the one div holding a paragraph tag it would be perfectly acceptable in HTML 4.x onwards. The only cases I can see a div being non semantic are the silly example I gave above, self closing divs in HTML (not extensible) and empty divs.
Then they are not semantic at all.
<div class="content">, <div class="post-title">, <div class="meta-data"> all have semantic CSS class names. But they are not semantic HTML names. Remove the CSS, and all you have is <div>, <div>, and <div>. This makes it difficult for screen readers (and web surfers who don't use CSS (are these people even real?)) to understand what the page is saying.
However <article>, <header>, and <aside> all have semantic meaning that can be discerned whether or not CSS is used.
Also: Whether or not something validates is not a good indicator of it being "semantic".
"Not every, but 95% do. For the rest, there are other pssibilities and tools to make sense of it (microdata, ARIA attributes, etc). Just ignoring semantics altogether won't do any better."
I'd love some insight into the technique.
I mean, I work with designers who often don't even know what their intention was in the first place, what should happen if a line of text turns into two...
Five tips given on the website to get good results (I have not tested myself) :
- Break your page into smaller pieces (header = 1 .psd, same for body, footer, sidebar, etc)
- Use one text layer for each logical piece of text
- Each icon or image should be a single layer or a smart object
- Want CSS buttons? Use shapes; not images.
[edit] I know there's only four. Fifth being avoid any hacks, it's probably not understandable by someone not really very familiar with Photoshop. Or I just couldn't figure out what photoshop-design-hacks are used by actual webdesigners.
Some designers produce effects using indirect methods instead of using the photoshop effects. These should be avoided as much as possible, for the code to be clean.
The explaination and screenshots on your website made this fifth tip very clear to me !
Design something > run it through some secret sauce > output HTML/CSS + provide explanations/advice/best-practices/etc.
The tool, however, is very impressive. I'll try to respond with a list of bugs I notice once I figure out how to fix them through hand-coding. Good work!
Any thoughts on where tools like Adobe Muse (http://www.adobe.com/products/muse.html) fit into the picture?
Great start guys!
But a few photoshop files failed, since Markupwand isn't yet capable of handling full pages and a few complicated cases.
have you thought about maybe options to split html into ejs/jade/other templates as well
you could in theory be able to do the reverse (html to image ) as well ?
I almost never define a fixed width for elements. Here every single element has a fixed width.