Responsive web design? Today's tools just aren't up to the job
Summary: The weaknesses in web design tools and processes are being exposed by responsive web design. But until a truly native web design tool arrives, there are ways to ease the transition
There's a mighty seismic shift grumbling just under the surface in the world of web design — and it's a two-fold grumble. As Andy Clarke says in his slides from An Event Apart Austin, "Design doesn't work when it's separate from development", and this point is as true for the tools as it is for the process.
Let's face it, Photoshop is pretty useless when it comes to communicating responsive web design. Liquid layouts? Forget it. Instead, web designers are forced into a dualistic world of Photoshop mock-ups and designing in the browser, with all its concomitant pitfalls.
Process and workflow are equally hampered by a miscommunication, this time between designers and clients. In a thoroughly entertaining and thought-provoking post, entitled "UX Design at Digital Agencies is F*cked", Ross Popoff-Walker bemoans the exclusion of web designers from the development process. Rather than being included from the beginning of a project, "Only after every pixel has been pushed and use-case documented, will something be made that is working and actually functional".
Leisa Reichelt, in a follow-up post, "Client/Agency Engagement is F*cked, Waterfall UX Design is a Symptom", rightfully points to the client-agency relationship as the root cause. The client expects the final package to match the pixel-perfect mock-ups exactly.
If only we could travel back in time to the days of scamps and Magic Markers, where a mock-up was rough and only ever a guide to what could be. As it is, all web designers are waiting with bated breath for the truly native web design tool. Will it be a browser within Photoshop or Photoshop in a browser? Who knows.
Tools for now
Until such a tool arrives, here are some handy pieces of software for easing the transition:
- Typecast App: test your type in a real browser, with fonts from TypeKit and Google Fonts among others.
- Gridset: an online tool for creating layout grids beyond your wildest dreams.
- Responsive Wireframes: handy tool for a quick preview of what could be, by James Mellers.
- Ultimate CSS Gradient Generator: generate gradients and CSS, by the creators of the ColorZilla browser plug-in.
- Blends in CSS: Wow — hot off the press from those clever folk over at Adobe.
And some closing words by Ross Popoff-Walker: "It's damn time things change".
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Mostly Agree
You're missing the most important point
We did
The current version is .Net and it can produce website, simulations or bread and butter eLearning in standard HTML. Although you don't need programming skills, it also supports user defined variables and conditions so very complex interactions or simulations can be created.
As for rendering differently, we can support all the major browsers on all platforms and the rich text will appear the same as when you create it on the desktop. The only difference appears in the new sub-pixel text location of IE9/10 and Safari, which due to more exact placement can be slightly different. We finally gave up on matching the text placement in these browsers and provide an option PNG capture for thsoe who want exact placement.
Our current tool does more than our previous tool that only produced Windows modules and we haven't yet touched on the other benefits of HTML 5. THe development process is WYSIWYG and users never see the HTML or our Javascript libraries.
We did
The current version is .Net and it can produce website, simulations or bread and butter eLearning in standard HTML. Although you don't need programming skills, it also supports user defined variables and conditions so very complex interactions or simulations can be created.
As for rendering differently, we can support all the major browsers on all platforms and the rich text will appear the same as when you create it on the desktop. The only difference appears in the new sub-pixel text location of IE9/10 and Safari, which due to more exact placement can be slightly different. We finally gave up on matching the text placement in these browsers and provide an option PNG capture for thsoe who want exact placement.
Our current tool does more than our previous tool that only produced Windows modules and we haven't yet touched on the other benefits of HTML 5. THe development process is WYSIWYG and users never see the HTML or our Javascript libraries.
Microsoft is as close as it gets...
Odd
I also hope that WPTouch and non-high DPI mobile websites die in a fire.
As a developer...
When building web-apps you now have to worry about: state management, a vastly increased attack surface (XSS, CSRF, script injection) and other common "mistakes" (id numbers in the query string), dealing with compatibility against the quirks of IE7, IE8, IE9, the various versions of Chrome, Firefox, and Safari in terms of HTML, CSS, and JS differences. Then add trying to add in AJAX to make the website more responsive, dealing with users who click the back button after submitting a form. And lately add in the current trend of "responsive design" where things scale as needed.
Time and experience has helped me not suffer through the problems most of the time and I'm used to it but there are days when I really miss MFC, GTK, and Winforms.
Holy bad Grammar batman!
thoughts
But yeah - dealing with the internet's languages is a royal pain. They were NEVER designed for this scale, and they were NEVER designed to become full replacements for desktop apps.
HTML was designed for hyperlinked documents. It was never designed for dynamic pages.
JavaScript was designed for small scale stuff, back in the days when the most you'd really do with it was make web pages flashy. It was never designed for full scale applications.
CSS was designed for basic styling, again back in the days when the most you'd do was flashy pages. It was never designed for professional use.
So here we are, trying to make full blown apps in 2012 using languages designed for static pages way back in what, the '90s?
Today's web apps may look pro on the sufrace, but underneath there's an enormous amount of baling wire and duct tape.
We can hope !!!!!
Dig in
Another decision I took a couple of years back is to embrace "hand-coding", that is - to learn HTML/Javascript and also server side tech and work on raw codes rather than using tools like photoshop, dreamweaver, etc. Whatever server side language you use, adopt a framework as it mitigates tons of repetitive tasks that you should not be too bothered with, albeit you need to know what they actually do for you. Once you learn and gets comfy with one framework, your leaning curve to understand another one would be easier. They are all built with their strengths and weaknesses, but similarly based on MVC.
On the front-end, there's a great deal of testing and tweaking that needs to be done before production deployment. Use Chrome/Firebug to gain insights to each element and their respective CSS behaviors.
The point is - would you rather spend years learning those "translator apps" that spits out HTML/Javascripts, most of which you have not much control, or would you rather invest your time to learn the actual tech. I think your value as a technologist should increase if you choose the later, even if you take your off hours to learn them.
Without passion to learn the core technologies, designers/coders will always be half-baked when it comes to web design and development. I'm not sure how segmented front-end/back-end work are these days, but I believe someone who knows both would be more sought-after.