The Yin and Yang of Responsive Web Design

Responsive design has revolutionized the way we create websites, yet there is a strong tendancy to still use traditional workflow methodologies. Such workflows can make a project far less efficient while adding a gamut of risks. This session will explore this dilemma, propose alternate workflows for responsive website projects, and offer respective approaches and tooling options for both designers and developers.

Yin and Yang:We’re speaking in terms of equal forces that work in a complementary fashion to complete a common objective.In this regard, we’re speaking of designers and developers.With Responsive Design, this is more important that ever because the core responsibilities are now much more multifaceted and complicated.There’s more and more opportunity for efforts in break into tangents and distractions, causing confusion, miscommunication, and rework.We’re going to speak about workflow that:Mitigate these risksEmpower both designers and developers to do what they do best.Have and end product that everyone is happy with.Mat not fit every situation… So take from this what’s useful to you.

Responsive Demands and Challenges:Resource management pressure on project timeline level of customer involvementHow does this change my 9-5Traditional Workflows:Not obsolete, but not a perfect matchApproaches and Tools: to compliment these new workflows.Responsive Workflows:Not perfect, but an important paradigm shift.

TODO:Crawl text?

My Core Technological Philosophy (a very YIN / YANG perspective to take)Your best chances for a project succeeding is by taking approaches that are somewhere between necessity and indulgence.The practical balance isn’t always a the mid point, it depends on the project.I don’t think we have to worry about the necessity side in this room. By being at this conference, you’re showing:Passion for your craftYou have the interest to learnYou want to stay competitive in a changing landscape.The real danger in project success happens when we’re too indulgent, aggressive, ambitious.The danger in taking this approach is that you risk failure. Then we determine what we can salvage – which drives is to necessity.At this point, we’re faced with permanency. It’s all bad and will probably encourage more bad practices, but there’s seldom the resources to fix it entirely.

Width-Specific Presentation:Example: http://www.gizmodo.comContent is more important than ever.Viewport space limits content. – that’s a good thing and a great place to start. Pick which content is most important for each viewport. Hopefully when you get to the desktop, you won’t have Las Vegas.Content as a Foundation – Not only what will fit on the screen. Also prioritization of content.

More Work:It’s not uncommon for responsive to be though of and sold as an add-onfeature instead of a holistic architectural approach.Awkward HCI:Most of the time, we’re using a finger for interaction. After all, that’s how it was designed.If Traditional Web site workflow – waterfall (even thought the steps can be agile)

TODO – Get complicated wireframes

Call it what you will, but the entire project uses waterfall workflow.The premise is that one stage begins when another ends.Develop: Most likely portion of the software development lifecycle to see Agile Workflow is in development.

Call it what you will, but the entire project uses waterfall33 workflow.Iteration can happen at every step (especially design)Develop: Most likely portion of the software development lifecycle to see Agile Workflow is in development.

Each stage creates it’s own independent set unique set of requirements.

We’re already designing:At this point, we’ve already done much of the design without input from graphic designers.Stephen Hay calls refers to this step as “coloring by numbers”Premature? Presumptuous:Very high fidelity. Do we know if this wireframe will jive with the design or dev strategy?Customer may have given sign-off, but have they been given enough yet to make good decision?Looks good on paper:It’s usually at high-fidelity design where the customer is able to relate to the message.

Dangerous Presumption:Person A is making the decision that person B should

Benefits:Collaborative, not bureaucraticIterative gain in fidelityProactive and reactiveCross-functional &amp; results-basedALL TEAM MEMBERS ARE PROBLEM SOLVERS EXAMPLE: LOFI

Benefits:Collaborative, not bureaucraticIterative gain in fidelityProactive and reactiveCross-functional &amp; results-basedALL TEAM MEMBERS ARE PROBLEM SOLVERS EXAMPLE: LOFI

Collaboration and Specialization

Benefits:Collaborative, not bureaucraticIterative gain in fidelityProactive and reactiveCross-functional &amp; results-basedALL TEAM MEMBERS ARE PROBLEM SOLVERS EXAMPLE: LOFI

Benefits:Collaborative, not bureaucraticIterative gain in fidelityProactive and reactiveCross-functional &amp; results-basedALL TEAM MEMBERS ARE PROBLEM SOLVERS EXAMPLE: LOFI