A Future Friendly Workflow

A Future Friendly Workflow

My talk from the latest Brisbane Web Design meetup (June 2012) about the techniques I have been using to build responsive, future friendly sites. How it effects designers, developers and clients.

Thanks to these people for their ideas:
Brad Frost - http://www.alistapart.com/articles/for-a-future-friendly-web/
Stephen Hay - Workflow Redesigned: A Future-Friendly Approach - The Smashing Book #3
Andy Clarke - Becoming Fabulously Flexible - The Smashing Book #3
Samantha Warren - http://styletil.es/

1a06ed07575b1a77fa2b324e1385c2ea?s=128

Luke Brooker

June 21, 2012
Tweet

Transcript

  1. a future friendly WORKFLOW @lukebrooker

  2. PREFACE • Not the only answer • Steps depend on

    the size of the project • is is not everything I do (e.g. testing not included) • is is not only my ideas
  3. WORKFLOW SUMMARY • Discovery (not included) • Content Strategy •

    Design • Development
  4. CONTENT STRATEGY

  5. We need to become temporary pessimists and focus on all

    of our problems—focus on them intently, let them incubate. Stephen Hay - e Smashing Book #3
  6. WHAT IS THE PURPOSE OF THIS SITE?

  7. SITEMAP • Start it with the client • “e presumption

    of uselessness” • Build off use cases not features • Make it quick and easy to edit
  8. AN EXAMPLE

  9. THIS GROUP

  10. SITE GOALS • Promote the next event • Get a

    higher rate of RSVPs • Grow the community • Get new speakers • Promote sponsors • Keep in contact with members
  11. USER GOALS • What are they about? Will I t

    in? • When is the next meetup? • Where is the meetup? • Where are the slides/notes from the last meetup? • Can I speak? What is involved in speaking?
  12. None
  13. SCREEN LIST • Use the sitemap • What are the

    different “layouts” or site sections
  14. None
  15. this is UNACCEPTABLE

  16. design from the CONTENT OUT

  17. SCREEN DESCRIPTION DIAGRAM • Clari es the purpose of this

    section • Constructs the hierarchy of each section • Helps de ne important content • Makes it easy to see the user ow
  18. EVENT SCREEN DESCRIPTION DIAGRAM PURPOSE CALL TO ACTION Make the

    details (date, time, RSVP) of an event easy to nd & understand. Emphasise the topics being discussed. RSVP for this event, Share this event
  19. FIRST PRIORITY SECOND PRIORITY THIRD PRIORITY Event Details (time, date,

    speakers, topics) Speak at this event (If speakers are still needed) Get directions Slides/notes/resources from this event (if past) Other upcoming events
  20. CONTENT INVENTORY • A global list of bits of content

    • Collect content from each screen as it is de ned • List the screen it belongs to
  21. BWD CONTENT INVENTORY 1. Logo (all screens) 2. Main Menu

    (all screens) 3. Intro text (home) 4. Event feature (home, event listing) 5. Event lisiting section (event listing) 6. Main content section (about) 7. Event details (event) 8. Speaking details (speaking) 9. Address (location) 10. Map (location) 11. Contact details (contact) 12. Contact form (contact) 13. Latest from Twitter (home, about) 14. Past events (event listing)
  22. IMPLEMENTATION STRATEGY • What types of content need to be

    stored? • What data makes each content type different? • In what different ways will each bit of content need to be displayed? • How will this content relate to other content in the site? • How could this data be used in different contexts?
  23. EXAMPLE • Content type: Event • Fields: Date & time,

    speakers, topics, resources, featured image, location, other details • Displays: Full, general teaser, aside teaser, feature • Categories: Topic, event type • Contexts: Format location for easy selection on smart phones, use hcard for formatting
  24. DESIGN

  25. Rather than tailoring disconnected designs to each of an ever-increasing

    number of web devices, we can treat them as facets of the same experience Ethan Marcotte
  26. CONTENT REFERENCE WIREFRAMES • For every screen type, show different

    layouts • Sketch rst (for ideas) • Use the numbers from the content inventory • Wireframe in the browser
  27. None
  28. PATTERN LIST & WIREFRAMES • Use content inventory • Find

    common patterns • Sketch out each pattern
  29. BWD PATTERN LIST t Menu main (main menu) t Hero

    (intro text) t Feature text (intro text) t Hero listing (event feature) t Teaser (event lisiting item) t Icon list (event details) t Block teaser (latest from Twitter, past events, upcoming events)
  30. None
  31. STYLE TILES • Stops us from create multiple “mock-ups” •

    Keeps the “feel” of the site separate to structure • It’s the deliverable not how where I design • Create patterns and elements all together...
  32. None
  33. DEVELOPMENT

  34. YOUR OWN PERSONAL BOILERPLATE • You need a solid foundation

    • Learn from boilerplates... • But don’t use them blindly • When you learn better techniques, add them • Know your way around
  35. PROTOTYPE

  36. STRUCTURE • SMACSS (Scalable & Modular Architecture for CSS) •

    Base, Layout, Module, State, eme • Modules... pattern list?
  37. SMACSS .menu { list-style: none; } .menu-horizontal li { float:

    left; padding: 10px; }
  38. SPEED or How I learned to stop worrying and love

    the preprocessor • Create production ready code fast • Less or Sass? • Sass has: @extend, compass, respond-to
  39. SASS .menu { list-style: none; } .menu-horizontal { @extend .menu;

    li { float: left; padding: 10px; } }
  40. SASS .menu-horizontal { @extend .menu; li { padding: 10px; @include

    at-breakpoint($medium) { float: left; } } }
  41. STYLE GUIDES • Start during prototyping • Patterns that aren’t

    covered in the prototype, style in the style guide • Add documentation for developer • ink about width, hierarchy, density & interaction
  42. None
  43. None
  44. IN CONCLUSION

  45. goals for a FUTURE FRIENDLY WEB

  46. • Create multiple facets of the same experience • Let

    content in uence decisions, not technology • Design systems, not pages • Stick to some common patterns, but try and break some (we always need new ideas)
  47. • Understand your code, don't blindly build off others •

    Pull things apart, modularise, our systems should be scalable and understandable • Work together with users, designers, developers and clients (everyone has a valuable perspective)
  48. MOST INFLUENTIAL SOURCES • Brad Frost - For a Future

    Friendly Web • Stephen Hay - Work ow Redesigned: A Future- Friendly Approach - e Smashing Book #3 • Andy Clarke - Becoming Fabulously Flexible - e Smashing Book #3 • Samantha Warren - Style Tiles
  49. LEARN EXPERIMENT SHARE

  50. THANKS @lukebrooker questions?