Fronteers Conference 2012 in Amsterdam came and went with a lot of great talks and more importantly, fantastic Q&A. After each talk, Chris Heilmann interviewed the speaker using questions tweeted by the audience. This made Q&A a lot less painful then throwing a mic into the audience and hopefully understanding a word or two of the question. A great way to do Q&A.
Talks where very diverse ranging from technical to comical, so rather then slavishly describing each talk, I will try to weave it categorically and add some personal insights which where inspired by those talks.
Responsive design and all that Jazz
Design and development is focused a lot more on mobile media lately with terms being thrown around like ‘responsive design’ and ‘mobile first’; it is clear that this is a breeding ground for information and innovation. From the talks I gathered it’s all pretty much edge, there is no standard way of doing it and no silver bullets, just theories, good patterns, experimental processes and luckily growing browser support.
Mark Boulton‘s talk; ‘Adapting to responsive design‘ discussed the design aspect of developing for both traditional and new media, which is riddled with hurdles. First of all, how do you design and prototype for all these media, accounting for screensizes and still serve quality content? Mark’s advice was to firstly eradicate wireframes and photoshop rendering from your application design process. Grab a pencil and paper and draw out your application for all media together with your client. This approach might take more time on the long run, but low fidelity designing shortens the feedback loop and allows you to screw up often and quickly so you can remedy flaws faster. This part in your application development process is not about design and branding, it’s about making sense of it first. Once you start photoshop rendering and wireframes, you are more committed to a design concept than you should be. Also, if anything should be agile, it should be your design process since it is THE determining factor of your application.
Secondly, help your clients to stop thinking in terms of ‘pages’. The client has a story to tell (not pages to fill) and a story comprises out of chunks of content like articles, videos and imaging put together in a smart way. Responsive design means it might be put together in one way for one medium and put together differently for another medium to make more sense of it and provide a good quality user experience for all media. A good example of this approach can be found on most news sites, where you have a main story, related stories, updates, video’s and more. Content pretty much works the same everywhere, whether it is a news site or a site selling printer cartridges, the only real difference is the speed in which the content evolves.
The final challenge is to find, adapt or develop a content management system that allows the rearranging of content parts in a dynamic way. Nearly all CMS’s are page oriented (PMS) and work counter intuitive in a responsive adaptive world, they are actually more appropriate for printed media. There are some good CMS’s out there in the wild that can be adapted to responsive/adaptive content, however the real challenge lays in changing the mindset in how we and more importantly the client deals with content.
So far it’s all nuts and bolts, but how do we actually address the ‘artistic design’ part of responsive design. Stephen Hay offers one answer in his talk; ‘Styleguides are the new Photoshop‘ where he confirms that photoshop is impractical for responsive design mockups. Photoshop renderings are for one not representative as it’s too clean, too pixel perfect and induces false expectations, not too mention it’s not possible to make a change and have it reflected over all your renderings quickly. As it turns out, web technologies are very practical for responsive design mockups.
Instead of designing mockups in Photoshop, make a styleguide directly in HTML, designing the layout and parts separately adding descriptions, measurements and context. Later on you can use all created assets to quickly create mockups and prototypes or use tools like Dexy to create documentation. There are some clear cut benefits to this approach of designing.
- You know instantly if your design works in the browser or not
- It’s portable throughout the development process, no one in the team needs to have photoshop to extract precise information
- After you made one html styleguide, you can basically use it for each project, tweaking styles and layout where needed
- Consistency and maintainability gets enforced
It’s important to note, that you do not need to create production-ready html/css, in fact, it’s even better to show screenshots to clients so they won’t think the frontend is already done. Stephen discussed some tools he used to automate his documentation, first of all he uses Dexy which I mentioned earlier along with Dexy’s idiopidae filter combined with PhantomJS + CasperJS to script screenshots and finally jinja to create the actual documentation. What people might see as a downside to this, is the necessity to use the command line, however he argued that Photoshop is way more complex to learn and use. In any case, would be great if there was a single tool to do the above.
To wrap this up, I look forward to the next event and for now here are some handy links:
⁃ (example) http://www.bbc.co.uk/gel
⁃ (information) http://24ways.org/2011/front-end-style-guides
⁃ (example) http://paulrobertlloyd.com/about/styleguide/
⁃ (example) http://oli.jp/2011/style-guide/
⁃ (example) http://patternprimer.adactio.com/
⁃ (guideline) http://smacss.com/