This weekend the first Frontend United event took place in Amsterdam. The successor of the Drupal Design Camp was visited by over 200 attendees and really one of the best Drupal events I’ve been to.

What I found special was that a lot of sessions were given by people outside of the Drupal community. As there were two tracks I couldn’t attend all sessions, but I’ll try to give a summary of my highlights. So here goes:

Friday: code sprint & workshop day

On Friday we were invited in an amazing place to do a sprint about the theming layer in Drupal 8 (to give input to the code sprint in Denver the following evening) and to attend a workshop given by Jesper Wøldiche about “Going Mobile First” in your Drupal project. I’ve attended this workshop and while the speaker expected 15 people, actually over 80 people attended.

Going mobile first

The intention for the whole mobile-first approach is universal access. Don’t do device-specific layout, but focus on device capabilities. Designing mobile first forces you to rethink and prioritize your content (because of the lack of space on a small screen) which also helps you designing the full-frame website later on. By making a design responsive you will tackle a lot of issues including:

• Reduce costs for multiple platforms. You only have to create and maintain one website.
• Sustainable and future proof. Will work in the future and new devices.
• One article = one url (update content once).
• 34% more buzzwords per project. Helps selling it ;)

The reason for choosing a mobile version of your website above building a specific app are 1) an app requires an extra investment and 2) it only makes sense if the app is your actual product. If your business (or your service) is your product, don’t create an app without having a very good reason.

A good thing to remember: don’t make assumptions. Don’t think that people don’t want to book a flight on their mobile. That’s wrong. People will, and do.

"Designing for mobile first not only prepares you for the explosive growth and opportunities in this space, it forces you to focus and enables you to innovate." - Luke Wroblewski (source)

The workshop ended with a brainstorm on defining an ideal solution for a mobile-first approach with lazy-loading of content. I believe the outcome of this brainstorm will be posted somewhere.

Saturday: sessions day 1

The first day of the sessions started with a kick-off at the beautiful location named "Pakhuis de Zwijger".

How to Write Efficient CSS and HTML for Drupal

This session was given by Jan-yves Vanhaverbeke (aka jyve) and was focused on improving the quality of the HTML and CSS in a Drupal project. Which means removing unneeded Javascript and CSS of core and contrib modules and analyzing the graphical design to see which HTML elements can be styled with shared CSS selectors (also called Object Oriented CSS). Remove unneeded DIV’s in you HTML (a great tool that can help here is the 3D view in Firebug that shows all layers in the HTML) and make sure you design all common Drupal elements before you start implementing your design. So create a page with all common elements (links, headings, lists, image, etc) and make sure those are styled correctly (check margins line-height, etc). Then style all generic elements (header, footer, nav, colors and links). Optimize the HTML, for instance by using Display Suite and strip the default markup. A nice module that can help here is StyleGuide which add a tab to your Theme settings with a listing of all common Drupal elements including tabs, messages, etc.

Some good tips to keep in mind

• Use generic classes above IDs.
• Replace module specific HTML (date.css, etc).
• Theme a semantic element, not a drupal module. So .article-teaser instead of .views-articles .views-row
• Keep your CSS flexible. Work generic (.field instead of .page-article #content div.node div.field-title).
• Dare to rework existing CSS as features are added. 
• Optimize your CSS using CSS standards (http://drupal.org/node/302199). 
• Use comments to add structure to your CSS
• Compress cached pages (under performance settings). 
• Optimize your images.
• Use image styles with Image Resize Filter
• Use hook_css_alter and hook_js_alter to remove Drupal JS/CSS
• Combine different CSS groups into one using hook_css_alter() and put them all in CSS_DEFAULT.
• Finally, test your site with Yslow.

UX Under Fire – On Communicating the Value of UX

This session was focused on how to explain to customers and managers the need of UX and how it can save money in the long run. Tremendous business value can be achieved by understanding how something has to work in order to be usable and a pleasure to use.

UX is key to making sure websites achieve intended business goals by bridging the gap between business requirements and implementation by capturing the needs of users.

The most important lesson of the presentation for me was that it is really important to make clear before you start building a website what the reasons are for building the site. What is its use and how can you measure the success after a few months? Don’t (re)build a site just because the current one is outdated, but make sure and specific what the client wants to achieve. So write down: what to measure, how to measure and when to evaluate.

Two good links: http://uxmag.com/articles/communicating-the-ux-value-proposition and http://www.uie.com/articles/three_hund_million_button

Drupal & javascript performance, a reality check

This session was given by Théodore Biadala aka _nod, the JavaScript lead for Drupal 7 & Drupal 8. He explained the problems with the use of JavaScript in Drupal 7 and some examples were the lack of asynchronous loading. The jQuery in core is 32kB (!) loaded by default, even if you don’t use it. It’s outdated (v1.4, where the current version is 1.7) and there’s no way to nicely override a script except for copying it in your theme (so its downloaded twice). It’s not good for mobile usage (because of its size and the lack of processing power).

Théodore vision was to use Drupal.events instead of Drupal.behaviors and that we need to load a piece of Javascript only when needed. For example: if you have an overlay on a page, just load the overlay JavaScript when a users clicks the link, not on beforehand. It would be a good thing to use Asynchronous Module Definition (AMD) in Drupal (which could now be done using RequireJS) and… to drop jQuery. Yes, that’s right. To drop jQuery. To do so, we must first clean up the current JS in Drupal. And you can help! UPDATE: on Sunday evening, just after the conference, Theodore opened an issue to use AMD for the JS architecture.

The State of HTML5 Video

One of my favorite sessions of this day, given by Jeroen Wijering (know of his JWPlayer). There are several reasons to want HTML5 video:

• No Flash support on Apple iOS
• Ease of use for developers (<video src=”myvideo.mp4” controls />)
• It’s accessible by humans and robots (Google) and you can use existing tools like CSS and JS.

Currently, there are two major video formats (H.264/MPEG4 and WebM). MPEG4 is supported by Chrome, IE, Safari, Flash/Silverlight and Android/iOS. WebM is supported by Opera, Chrome and Firefox. (both 50% of the current market). There are some small limitations by using the <video> tag: not all browsers handle it equal and the layout of the control differs per browser.

There are several good players out there that handle HTML5 video, like VideoJS, Sublime Video, JW Player and Mediaelement.JS. What they basically do is, using Javascript, check for <video> compatibility and if not available, fallback to Flash. Or, like the JW Player, check for Flash and fallback to <video>. Some attributes of the <video> element that are still to be finalized are the <track> element for subtitles and audio transcription. For more info, see this great HTML5 video player comparison.

Data Driven Visualizations

This presentation was given by Jan Willem Tulp, a non-Drupal person, working on data visualizations for clients like World Economic Forum, Schiphol Airport and Popular Science Magazine.

He showed a lot of examples of displaying big data other than pie charts or flow charts. I did not write much down, other than the tools he used to create those visuals: http://processing.org/ and http://processingjs.org/ .

How to Tackle the New Hot Shit in an Accessible Way

The last session of the day was a session about accessibility and how browsers and assistive technologies handle new stuff. It was given by Eric Eggert aka yatil and he gave some very good examples of techniques to improve accessibility without losing functionality. He started with the showing the Web Accessibility WCAG Theme Song. Some basic tips he gave were “Never use text-size-adjust: none; Use text-size-adjust: 100%;” so people can adjust the font size if they want. And use CSS animations instead of JS animation. He mentioned that we can use vw and vh units instead of percentages to let content adapt to the viewport and that we need to implement WAI-ARIA information to our theme. WAI-ARIA gives a description to HTML elements (for example <nav role=”navigation”> instead of just <nav>. Some Drupal themes like AdaptiveTheme already take care of this. He also created a polyfill that adds WAI-ARIA support to HTML5 elements and shared this on github. Not much new information for me (as my company LimoenGroen already focuses on accessibility in Drupal) but it’s great so see more people advocating the need for it.

In the evening many people went to brewery De Prael, propably because of their logo and their good beer.

Sunday: sessions day 2

The Sunday sessions started a bit later in the morning so the early birds were invited with some coding and coffee in the lounge. My first session of the day was a session about writing Object Oriented CSS.

Object Oriented CSS for Rapid, Scalable and Maintainable Development

This great session given by Graeme Blackwood gave tips for writing scalable CSS. Some basic principles he mentioned were “Separate layout from HTML” (use a grid system and you’re already half-way), “Separate the container from the content” and “Look for shared styles” (you will see them everywhere). Here’s a list of how to implement it:

1. Use a grid system
2. Use a reset stylesheet (HTML5 boilerplate's normalize.css). Don't use Eric Meyers reset CSS, it conflict with lots of stuff in Drupal.
3. Set good base styles to minimize later overrides. Tip: * {box-sizing: border-box} is pretty handy!
4. Build HTML prototypes with Drupal in mind.
5. Clean up what Drupal throws at you. Don't just style, theme!
6. Lose unnecessary markup if it affects you. Some divs are totally pointless.
7. Don't be too obsessed with perfect markup. Just enough is OK.

SASS & LESS are great tools to writer better CSS, but you must only use them if you understand the theory behind Object Oriented CSS. A good tip is to read the book Scalable and Modular Architecture for CSS (SMACSS).

Managing a Client With Multiple Devices

While this was a very good session by Jason Yergeau aka aquariumtap on how to work with responsive designs and how to explain this to clients; I failed to make notes of his slides. What I did note were a few links. A great resource is a bunch of PSD files of the main Drupal base themes so you can send them to the design bureau that is going to work on your design (so they know what HTML elements to style).

What the f**k is a Polyfill?

After lunch I attended this great session by Alan Burke (@alanjosephburke) about Polyfills. A polyfill is basically a piece of Javascript code to let older browsers make use of newer technology. For example, the Modernizr script that let IE6 work with HTML5 elements.

"A polyfill is a piece of code that provides the technology that you expect the browser to provide natively." – Remy Sharp (source).

Or, as Alan stated it, this is basically what a polyfill is:

What he also mentioned is that, after a debate of over 150 comments, the polyfill HTML5shiv is added to Drupal 8 core! The point Alan made in his presentation was the need for progressive enhancement. And a link I must share is an extensive guide with HTML5 cross-browser Polyfills on github. And because of all the extra effort needed to get older browsers like IE7 work with newer technologies, mortendk shared a tip to overcome this. Just add a 25% tax for clients that persist on IE7.

Clean CSS using Sass and Bourbon

My last session of  the event was a session given by Phil LaPier about writing clean CSS using tools like SASS and Bourbon. CSS2.1 reached its official recommendation state on June 7, 2011. And it's dinosaur already. CSS is not finally recommended and still we want to use it in every project. To overcome this, we need to write vendor-specific CSS (and lots of it). New techniques like SASS (and LESS) help us by supporting variables, functions, loops and includes in CSS so we don’t have to write redundant code. Bourbon is written by Phil is it is a lightweight mix-in library of SASS. It can do amazing things like this:

To implement Bourbon in you Drupal project you can use tools like CodeKit (an amazing tool to generate the CSS version of a SASS file) and FireSass for Firebug to debug your CSS files.

Final words

I want to thank all sponsors, speakers and attendees for making this amazing event happen. I had a great weekend, learned a lot of new stuff and met great people. Let the next Frontend United be as amazing as this one!

For those interested: I shared the most links that I bookmarked this weekend on a Delicious stack: http://delicious.com/stacks/view/Lv3kWR

Tags: 

Planet Drupal
Frontend United
Drupal