Warning: You are viewing old, legacy content. Kept for posterity. Information is out of date. Code samples probably don't work. My opinions have probably changed. Browse at your own risk.
Apr 14, 2013
I just got back from a fun packed Drupal weekend at London's Cargo, which hosted Frontend United, an annual event previously know as Drupal Design Camp. This is a write up of the notes I made and thoughts I had during the weekend. All the sessions were recorded and should be online soon.
Now is the time to brush up your web products
First up was Christian Heilmann, an "evangelist" for Mozilla Foundation. Anyone who knows me (or read my recent review of Drupal Camp London) will know I have a tendency to accidentally miss key note speeches. But, this was one I really didn't want to miss. When I left my first startup and went freelance, Chris presented at one of the first events I attended (the first ever Social Innovation Camp), and I often remember one of his anecdotes from that event (do you want it cheap/quickly/good? choose two), so I was keen to hear what he was "evangelising" about these days.
Chris set out to explain "why I'm excited to be a web developer right now", and he certainly achieved this, with lots of humour and amusing stories along the way. One of the reasons he quoted was the fact we (developers) use the same tools as our end users. You don't need an SDK like app developers, the tools we need for developing and debugging are built right into the browser. He went on to remind us of that iPhone launch by Steve Jobs when Apple redesigned the phone from scratch. It was Job's vision back then that we'd have the full web on our phones, it was all about HTML5, but the backlash from developers meant that the focus switched to Apps and going "native". The message from Christian was that we're "shooting ourselves in the foot when we try to get parity between html5 and apps". "we can do better". We had a short history of planned obsolescence, and eventually arrive at the conclusion that we're better on the web. Some of Christian's points were reinforced by the "Destroy the Web" presentation that followed at the end of the day, but more on that later.
Responsive Web Design with Sass+Compass
SASS and Compass are used extensively on the MTV project I was involved in, but I never touched it as I was working mainly on back-end stuff. I had played around with LESS (an alternative) before and I'd setup SASS and Compass on a dev environment. I've also used Zurb Foundation for some prototyping (more on prototyping in the second day review) which uses Compass, so I know my way around it, but this session really opened my eyes to the power of what SASS and Compass can do. I honestly think we can stop writing CSS now. In fact, I'd like to imagine a future where no one has to write any CSS.
Sam Richard, senior front-end guy for NBC Universal took us on a tour of Compass focusing on the three things needed for responsive web design: media queries, fluid grids, and flexible media. Sam started with a bit of motivation, first talking about designing mobile first, but clarifying this as actually "content first". An idea that was repeated a few times over the weekend was that mobile first is actually content first. Sam then motivated this further talking about being "future friendly".
The first of the three things required for responsive design is media queries and for this Sam explains use of the Breakpoint SASS extension. Sam explains why we should be designing breakpoints for "when the content starts to look shit", not adding breakpoints for screen sizes, and explains breakpoint em conversion for accessibility and users who set different default font sizes. The Breakpoint extension is really powerful. Not only does it provide a really simple way to keep breakpoint definitions organised, it looks like it can work with media query feature detection fallback without much extra work.
For the second requirement for responsive design Sam introduces us to Singularity. It's not a grid system, it's a grid framework. We all love abstraction so here's another layer of abstraction, this time for front end grid systems. Sam shows how Singularity can be used to create standard 12 column grids, but also gives us all the juicy details on asymmetric grids, nested grids, responsive grids. I got a bit distracted contemplating the mathematics of all this, so I'm not entirely sure where Sam went with this, and I didn't make any notes during the third section on flexible media. Sam did demo some cool looking flexible content - using a video player that maintained the aspect ratio. It uses intrinsic ratio to scale child based on parent. I'm going to have to go look up how this worked as I didn't note it down at the time.
Alice and I decide we're too hungry to concentrate so we skip out of the next sessions and pop around the corner to Barrio for THE BEST EGGS BENEDICT EVER! We also witness the bar staff nearly burn the place down while trying to make our cocktails, then we head back for the afternoon sessions...
Edward O'Riordan gave a fascinating talk with a plotted history of where the "creative" stereotype came from. "Are you a geek or a freak?", he asks. Ed warns against "putting ourselves in boxes", and I'm really enjoying this, particularly after the surprise from some people earlier in the day wondering why I was at a frontend event when I'm a "back-end" guy. The night before I'd just purchased a bunch of tickets for Little Bulb theatre's retelling of Orpheus - I didn't expect the story to be told this weekend, and a weird coincidence that Edward used it in his presentation. He goes on to explain how putting ourselves in boxes limits us, and that programming can help designers create amazing designs.
I think the best way to describe this presentation by Morten is that this is his version of the story of how we got Twig in Drupal 8. It's a long story, it's a long time coming, but it should mean Drupal is a much better place for front end devs. One good recommendation he gave for developers was to look at how the system module does css. This is to have a module.base.css for any important stuff needed by the module's functionality, put any CSS required for the admin area into module.admin.css then put any display CSS into a module.theme.css file. This makes it easy for themers to replace the design.
How to Destroy the Web
Bruce Lawson wrapped up the day with one of the funniest presentations I've seen at a tech event. I didn't make any notes as I was giggling most of the time. He repeated one of the ideas that was mentioned several times over the weekend, in that we should be designing for the future. His take on it was "that device will be in a museum in 18 months time". The way we do this (build for the future) is by using standards. I wouldn't do the presentation any justice by trying to summarise it, so just wait for the video to get online. If you watch any of the videos from this weekend online, watch this one.
The day ended with a live commit to Drupal 8 converting Field API to CMI. Is this the world's first live commit of a large patch to Drupal core preformed live on stage in a nightclub to a huge cheer?
Death of a themer
Day two and I have to rush in because Jim's "Death of a Themer" presentation has been moved forward, and into the bigger room to accommodate the demand. I'd seen this before at Drupal Camp London a few weeks ago, but I was told it had been updated, and I'd briefly debating it with Jim the night before (although after a couple of glasses of wine, so I didn't make total sense).
Ever since I heard about this approach from Jim I've been interested, but not totally convinced, and I'm not entirely sure why. It sounds really good and I like the principles. The idea is to start with Drupal outputting no markup at all, then only add in what you need. This makes sense, and anyone who has done anything with Drupal will have, at some point, battled with Drupal to strip away unnecessary crap it adds in. This allows for a precise, pure translation of the HTML and CSS design to Drupal output.
"We see Panels as an interface for wrapping content with markup [not as a layout tool]"
The approach uses Panels and Display Suite, and Panels Everywhere. Again, I like these modules and they're really powerful. There's a lot of configuration (i.e. site builder work) involved, so you need the Features module. I'm not sure this is where the design should be (don't we strive for clean separation of business logic from presentation?), but perhaps this is better than writing loads of template files. I also tend to prefer code-driven development to Features (no they are not the same thing), and I'm not sure this works with this approach. But, I'm definitely willing to be proved wrong on this. Perhaps having the markup wrapped around the content configured alongside the content will make it easier to maintain in the long run?
I think the key thing here is that it puts the priority on the front end code you're developing, not on Drupal's ideas of what the front end code should look like.
Matt Fielding is Jim's partner in crime, and adds some interesting points. He repeats one of the ideas that gets mentioned repeatedly all weekend, that we should use a "content first" approach, and talks about designing a work process for each job, as each job is different.
Etching wireframes & agile UX
Roy Scholten talks about a methodology he learned while studying art, and applies it to user experience. It's got the acronym PISA, and stands for Problem, Inventory, Selection, Arbitration. First you define your problem, then build an inventory, go through a selection process, and then implement.
Roy gave us three examples of this process, from his experience. His first was a very personal story about his own artistic creations. I was unsure about what he was talking about for most of this as it was all a bit abstract, but then when he showed the finished items it all came together. He was taking about artistic processes (etching) that I know nothing about, which made me think about how web development processes must sound to non-techies when I try to explain them. Thanks Roy for this insight.
We then saw the process applied to UX development for Drupal core. Roy explains the "P" in his analogy is defining the problem, in that it's only effective to tackle a well defined and focused problem, rather than trying to "boil the ocean". For this example Roy takes the UX problem of user's not understanding the "Save" button on content. This was highlighted in UX tests on D7 core, and seems to come from the fact the publishing options are hidden in the vertical tabs. The "I" in Roy's method, inventory, involves taking stock of what the situation is now, looking at what contrib does, and looking at what other systems do, and sketching out ideas of potential solutions. The "selection" phase involves moving on from sketches to a hi-fidelity prototype, which is the point Roy approaches the Drupal community for feedback. Roy warns about asking for feedback too early from the Drupal community, because any post on UX gets 100s of comments. Dealing with these comments takes a lot of effort, and Roy suggests it's best done later on in the process. The final stage of this process is getting it implemented, which in this case means taking it to the Drupal issue queues.
In the final section of this presentation Roy goes on to talk about applying the process to agile UX development. He talks about prototyping a lot and "getting out of the deliverables business" - an idea that is repeated by Leisa in the next session. Here a five day plan is detailed. Day one is setting out business goals and user personas with the client, and recruiting test participants for later in the week. Day two is defining what the site should support. The analogy Roy uses is that you have to generate a map of the territory and then find the path you want to take. This results in sketches of each page in the processes. In day three Roy suggests reviewing all the ideas and deciding what to prototype and what to test. Day four is used to build the prototype (a click-able prototype) working with the client to get real content in there. Then day five is bringing in the test participants, running UX tests and reviewing the results. Roy gave a diagram of a good setup for running UX tests that involved running a separate screen from a laptop that the participant was sat in front of. That way they could point a camera at the user and the laptop screen to record simultaneously the user's face and the screen.
Prototyping your way to UX success
"Not everyone get's excited about abstraction"
Leisa Reichelt's presentation nicely mirrored what Roy had presented. It reinforced the idea of prototyping. Her presentation style is great, and I found more accessible than Roy's. Leisa starts by talking about how things were done before, how she came to realise she needed to take responsibility for the end result, and the change in process that she implemented as a result of this. Design and development are not linear, it's "squiggly" she tells us.
Leisa confirms another of the ideas repeated several times over the weekend - avoid photoshop! I've felt this for years - back when clients would give me photoshop designs to turn into websites. I'm glad we're finally moving away from trying to get "pixel-perfect" implementations, but as Leisa points out, it also means that ideas are easier to throw away. If you spend time making them pretty in Photoshop you fall in love with them too early. The best ideas, Leisa tells us, come only from generating lots and lots of ideas and filtering them down.
I liked the comment about pair programming in true agile "it's beautiful, you can hear the thinking they're doing".
Leisa tells us to move away from wire framing and towards prototyping. "Prototypes are persuasive", she tells us, and "be making, not documenting".
Beauty in order
"The key to universal beauty came from a guy observing rabbits getting laid"
The camp comes to an end with a nicely abstract presentation by Zélia Sakhi about mathematical approaches to visual design. Zelia draws lots of examples from nature of how the Fibonacci sequence (thus golden ratio) define natural beauty. A few useful tools are suggested, such as the golden ratio typographic calculator, and Zelia repeats something we heard earlier in the weekend, that it's important to break the rules, but to break the rules you need to know and understand the rules.
Big thanks to the organisers for a smoothly run, professional event. Wifi didn't work for me all weekend, but that didn't really matter as it wasn't really a "doing" event, I didn't BoF or sprint, just lots of listening and chatting.