As the developer of www.psd2html.co.uk I can honestly say I am very happy that someone else out there is doing something similar to me...you might ask why?
When I launched Psd2Html in late 2010, I was unable to get on the front page of HackerNews, or any other website for that matter, I was down-voted to oblivion. I had insulting, slanderous comments posted on the Mac App Store which were untrue.
I was ridiculed by "hand coding only" services like www.psd2html.com, the employee lots of people and don't want to make people redundant, but the problem with this approach is that they will never move forward.
I was certain, and I'm still certain hand-coding will go the way of the Dodo.
So Markupwand, thanks for re-validating the idea, and I'm glad I'm not the only one who thought the idea was worthwhile.
I can see that I need to enhance my service/business model/add relative CSS positioning as an option.
"I was certain, and I'm still certain hand-coding will go the way of the Dodo."
I don't think so. How are you going to handle responsive designs or hell even fluid designs? Or deciding which HTML tag to use? HTML tags are meant to be semantic.
More and more people are moving away from designing in photoshop to designing straight in the browser.
edit: I see the link in the OP uses bootstrap and is well put together, but it's still far from perfect.
I totally agree with this and gave my own detailed explanation of the difference between semantic and non-semantic HTML here --> http://news.ycombinator.com/item?id=4284054
Yeah, I'm not a big fan of the heavy usage of Bootstrap that's been going on lately.
Bootstrap not only makes it simple to visualize the construction of a page, but their documentation is really easy to understand (while HTML's documentation can be difficult to go through).
It's great how flexible HTML/CSS is -- it comes pre-built with an existing paradigm (semantic HTML), and tools to create your own (read: <div>s & classes/IDs). Personally, I prefer using the standards already set than creating something new and/or using something different.
Hand-coding isn't going to go the way of the dodo, because in practice, web pages are vastly more complex than Photoshop or Word documents.
They need to respond dynamically to window resizing, have rules about which directions text boxes expand in when they overflow with text, how the page operates when a whole section is missing, etc.
Any tool that appropriately allows for all this complexity to be specified, has already become as complex as CSS itself, thus defeating the purpose.
And in my personal front-end experience, 95% of my time is spent on these harder details. Throwing together the basic HTML/CSS skeleton of a page is trivial, and so fast I don't really need a tool to speed it up, especially when that tool is always bound to get something wrong.
> Any tool that appropriately allows for all this complexity to be specified, has already become as complex as CSS itself, thus defeating the purpose.
This was my immediate issue with CSS Hat. The designers are not trained to set up their photoshop files to be properly evaluated in CSS. They do not know CSS, or how it works. They get their pixels "perfect" (or way off most of the time when doing real math with css), but the fact is to use tools like this they have to get on board 100%. For some designers, this is easier than others.
Don't get me wrong, I'm still interested in trying out the tool. Maybe it is magic...
You might want to check the image magnify links on your home page, Chris: http://www.psd2html.co.uk/screenshots/3.png goes to a css-free html page instead of an image, for example.
Edit: also, the unthemed "Error - Login - Paypal" link from your "Free 3-Day Trial" button probably doesn't convert very well...
The output isn't good enough to use straight up and I don't think it ever will be.
Tools like this, which can create good mark up, have a lot of potential to speed up the coding process. If these tools can get the developer 80% there then its great.
I feel this is as far as these tools will take us.
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 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 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 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.
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
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.
@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.
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.
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.
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".
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.
> 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.
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.
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.
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.
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!
Does Markupwand use scripted Photoshop instances in the background? And if so, how did you manage to work around the fact that the standard Photoshop license does not permit such use?
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!
The problem with this and other photoshop > CSS tools, is that you're still stuck with Photoshop. We should be elevating design by designing web native and making it beautiful, not using the same old fixed desktop beasts. Edit Room [1] and the like (typecast [2], etc.) will be the wave of the future. Great web design requires great human communication, which means great typography. You can't get close to the real web type display with Photoshop, and this tool won't help there.
Unlike Edit Room, using Photoshop + Markupwand generates all units in pixels - not too useful for real multi-device prototyping. Others have mentioned the tag soup. It's fine for those who can't move on from Photoshop, but more and more folks are interested in trying something new.
It's not pixel-perfect, but it is flexible and responsive, and should work decently well across different screens for 5 minutes of work.
(I don't support images yet, so you won't see icons or an avatar, but the type and grid and color and shape and all those important things about design are well-represented)
What you show in the video looks pretty good. A few things that caught my eye:
The signup form is unconventional. that in itself is ok. but the cleartext password text field is a really bad practice. Also the whole thing just looks very hand-stricken, you know what I mean? I'm not that much of a designer myself, maybe others have a different taste.
I really hope you succeed, overall I think it's a very good idea. I like the abundance of CSS options and the format pasting you show in the video very much. The video makes me want to use it right away.
Cool, thanks for the notes. I'll research the password field a bit more, I was going for the increased usability, but security (and perceived security) are important as well.
I'm working on improving the design of the controls, etc, based on some other feedback. It's definitely hand-made, if that's what you're referring to.
Thanks for the good wishes! Glad the video was helpful.
Why are cleartext password fields bad practice? How many accounts are actually compromised via shoulder surfing? They're especially annoying on mobile phones.
edit: Since there are password fields, I guess the question should have been "How many accounts _would_ be compromised by shoulder surfing?" I bet it's a truly insignificant number.
1) As OP has pointed out, security is not just about effective security, it's also about the perceived one. Cleartext passwords are so unusual it makes me question as a user, how things are handled in the backend.
2) I don't see the problem on mobiles. Not sure about Android or WP but at least on iOS I always see the last character that is entered. Still vulnerable to shoulder peeking but not as bad as cleartext.
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.
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:
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.
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!
Very impressive ! and I am sure many people will use this service ..
About the quality of code that it generates :
I don't mind setting some on in my team to work on optimizing the generated code , but having some base html/css to work on is definitely a plus point.
Oh, BTW, You wont share my PSD with any one else right ?
Fireworks has it's own "export to tables + image slices" thing. The end result is not too different, tag soup and fixed dimensions for everything. Next step up is hand-coding. Or really smart robots.
It works in incognito window. It does look like it's an issue with multiple account signed in. Yours is not the first site on which Google auth is failing for me when I'm signed into multiple accounts.
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)
When I launched Psd2Html in late 2010, I was unable to get on the front page of HackerNews, or any other website for that matter, I was down-voted to oblivion. I had insulting, slanderous comments posted on the Mac App Store which were untrue.
I was ridiculed by "hand coding only" services like www.psd2html.com, the employee lots of people and don't want to make people redundant, but the problem with this approach is that they will never move forward.
I was certain, and I'm still certain hand-coding will go the way of the Dodo.
So Markupwand, thanks for re-validating the idea, and I'm glad I'm not the only one who thought the idea was worthwhile.
I can see that I need to enhance my service/business model/add relative CSS positioning as an option.
I hope we'll be good competition for each other.
Thanks
Chris