Oct 03 2013
Oct 03

DrupalCon_Prague_Logo_2013

DrupalCon_Prague_Logo_2013

Coming up to a week  since DrupalCon Prague, caught up with my girls, emails, calls, follow ups and all else… time to reflect.

I stand by my verdict of the 26th of Sept: @drupalcon #Prague No #Munich but No #Croydon either but an informative fun week. That is to some annoyance of a few fellow community members and possibly some folks at DA… folks there was and is no offence intended, someone has to lay it out as it is and I did share the feedback in person with DA and not just tweeted it on my way to the airport HA!

The host city was awesome, the venue was well their congress centre (the best they had to offer I suppose) but the connectivity there sucked! the food though not that important could have been much better, the sessions that I have been catching up on line were good though more diversity is key for the future… representation across the continents please! BoFs were super useful no doubt and some of the SWAG was nice, some just awesome – Acquia and Deeson win the SWAG award!

DrupalCon_Prague_201325 11.51.49

DrupalCon_Prague_201325 11.51.49

Having said all of that the most awesome thing about DrupalCon Prague was the connectedness! on that note Prague won hands down! out did Munich too!

I am going to be at DrupalCon Austin which will be my first DrupalCon across the pond and knowing how conferences go over the Atlantic am sure it will be mind blowing and if not you will hear about it in person. As for DrupalCon Amsterdam… it can be nothing short of epic! but then most peeps who have been to the Netherlands would say that!

It was great seeing old friends and making new ones and looking forward to the next Cons and upcoming Camps across the third rock.

Apr 11 2012
Apr 11

Ah, Drupalcon. Three days of panels and BOFs, one Advomatic code sprint, and some very late nights with the Advoteam. Now I'm thrust back into the land of overflowing diaper pails and spaghetti bits everywhere that is work-from-home motherhood. But I promised myself I'd put my DrupalCon notes into a fancy blog post in the hope that others will find them useful (and so I can find them later). Two weeks later, here goes.

This year's DrupalCon was particularly fruitful for us theme developers. In years past, there hasn't been much new and shiny for us beyond CSS3 goodies we couldn't touch because of legacy browsers. But technology is changing, as it is wont to do. We're seeing a revolution in how we plan, design, theme and QA our sites, thanks mostly to responsive design (and SASS/Compass, but I'll save that for a later blog post.)

If you need any convincing that the mobile revolution is mandating a change in the way we design and build sites, check out Luke Wroblewski's super engaging keynote. LukeW coined the term (and wrote the book) "Mobile First" to redirect planning sites for handheld devices first -- then for computers -- because of the clear trend in how people are accessing sites. A collateral benefit is that by designing mobile first you are forced to prioritize your site's content -- maybe the main thing people need when they go to your organization's website is how they can help the cause, not a letter from the Board. There were a few "future is now" moments in there too, for better or worse. Do check out his Future Friendly manifesto.

At Advomatic, responsive sites are rapidly becoming the norm, and we're figuring out best practices as we go. So these DrupalCon sessions were a top priority:

There was a bit of buzz around the idea of doing "design in browser" versus in a design program like Fireworks or Photoshop, which inevitably mean a fixed width conceptualization of a site (even if the designer creates versions for a variety of browser widths.) SASS and Compass would give you a leg up to design something quickly directly from your browser, and I hope to address that in future blog posts. However, I tend to camp with those that say that starting from the browser will inevitably stunt a designer's creativity:

The browser was intended as a delivery mechanism with HTML and CSS a means of describing content rather than defining it (a subtle distinction I know, but an important one). As such the browser lacks even the most rudimentary tools, such as the ability to draw lines or irregular objects through direct manipulation. Instead this process is heavily abstracted through code. As the best design tools are the ones that put the smallest barrier between the creator and their creation (the pencil is a good example of this) designing in the browser adds an unnecessary level of craft to the process. - Andy Budd, Clearleft

I'm not sure whether Photoshop and Fireworks will soon have built-in flexibility, or if browsers will have built-in design tools, but currently neither is a perfect tool for responsive design.

Another interesting approach to the the problem of graphic design for responsive environments is Style Tiles, which was mentioned in at least four of the sessions I saw. It's a method for designing for a client without creating full comps, somewhere between a "mood board" and a comp. I like that it allows for some flexibility, and look forward to an opportunity to try it out. Another suggestion was designing a few comps for different breakpoints in Photoshop/Fireworks and a style guide -- and then move to designing in the browser.

One Drupal module that would help with in-browser design (and makes testing for different displays easier) is the Style Guide module, which generates a page where you can test all common HTML elements for a site, so you don't miss anything.

There is still a lot of debate on how to handle images in responsive design. While the img {max-width: 100%;} goes a long way, it still means you are potentially downloading a unnecessarily large image on your phone. And unlike CSS background images, img tags have a single, immutable source. The Adaptive Image module for Drupal is suggested, as is Borealis Responsive Images, for creating smaller images on the fly depending on the browser size. It's a complex issue, and you can dive deeper here and here. For video FitVids was suggested (and FitText for flexible font sizes.)

What about content? While there is this mantra of "mobile first" -- designing the site around the smallest of devices first, keeping content super streamlined -- there's another thread that content available to larger screens shouldn't necessarily be hidden on smaller screens. Mobile users may in fact be looking for a more rich experience, not just the bare bones. So think twice before plunking in a display:none on an entire region. However, I imagine that will probably be a site-by-site decision.

Responsive Design Testing

So testing for all these various devices inevitably will be tedious. I collected a little list of some tools to help.

  • Responsive Design Testing Tool - See how your site will look in four different device widths together on a single page.
  • Adobe Shadow - plug in devices to a desktop, pull up your site on one, and view it in all devices (no need to surf to it on all devices.)
  • The Browser Stack, a cross browser testing tool, just added mobile support

And, finally, here's a collection of fun responsive examples to check out for inspiration.

There you have it. Hopefully something in my extended brain dump will be of use to you!

Watch all Drupalcon sessions here, and fill me in on anything I missed below.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web