My first Drupal Camp Toronto experience is sadly over. There was a whole lot to absorb and although I found that I did learn a few new things, the most beneficial part of the conference for me was the inspiration I gained from others. I met many kindred spirits and future partners in crime. It was really interesting to learn about some of the initiatives that others are pushing forward. Overall I would say that Drupal Camp Toronto 2012 was a great event and really well organized. I would recommend it to anyone that is remotely interested in Drupal to go checkout the next such event, which for me will likely be Drupal Camp Ottawa 2013 and then Drupal Con Portland! Here is a quick summary of some of the sessions I attended.

A Responsive Design Case Study - What We Did Wrong Building ResponsiveDesign.Ca (And How We Fixed It)

This session was given by Aidan Foster and he essentially went through the process they took in building responsivedesign.ca from base theme selection to their attempts at optimizing image and page load sizes. He had some great tips such as:

• put your media queries in css files and not in the header of the doc.
• don't use pixels use em(s)
• learn sass and compass as they come with great tools and mixins that are already optimized for cross browser compatibility and can do the complicated math involved in converting pixels to em.
• use a grid system with natural break points rather then creating widths based on specific screen sizes such as desktop, tablet and mobile. Natural breakpoints are points in the dimensions when things start to look messy.
• there is a breakpoint mixin for compass
• let Internet Explorer (IE) be IE. Use an IE specific css file that sets fixed widths, because this is what IE users are used to anyway. "Buggy slow responsive is worse then fixed width."

Aidan also did a comparison of different techniques and tools for responsive images as well. The issue here is that if you are just letting the browser resize the images for the different breakpoints, then you are always loading the largest image and this adds to creating a bloated page load. For some mobile devices (espescially your mobile data plan) this can be an big issue. So in the end he and his team decided to go with the 'Adaptive image' tool that uses a client side approach for image loading. This approach loads the smallest image first and then loads a second image using js if the screen size is larger. This means that images are likely loaded twice except when using a mobile. At least this is what I understood From his talk. Other responsive image tips were:

• image styles quality is a useful tool to optimize image quality vs size
• you can use sprites with compass
• before adding images everywhere, ask yourself if you really need it?
• base 64 encoded background images in css if it makes sense to
• svg with image fallback could be useful
• look into progressive enhancement techniques
• enquire.js could help with media query management
• adobe edge inspect can help find cross platform issues. (costs money)

Fearless Development With Drush, Vagrant And Aegir

This was an advanced level talk given by Christopher Gervais. And advanced it was. I highly recommend checking out his slides on this and listening to the presentation when you get a chance. This talk will be interesting if you ever manage server admin and especially if you would like to standardize your server environments between all your servers. This isn't even necessarily Drupal specific. Much of it was over my head and I will have to watch it again and do a little research before I can actually do it any justice in trying to explain it all. But for the context of this blog I will summarize a little of what Chris went over. He essentially goes over how at Koumbit they use Puppet to creating and managing a standardized server environment. Do so allows you to ensure that your sites will work consistently between your dev and live servers. It also brings down the time to set up new servers from hours to about half an hour. Using drush make in conjunction with Vagrant and Puppet  allows them to create a distributed Drupal platform including backups, easy rollbacks, git versioning, regression testing, updating the database. This also becomes very useful when considering updates to code or security releases as it will create a new version of the platform (a mirror of the live server), applies the updates, fully runs a set of regression testing and if all goes well changes the apache vhosts file to point the live instantly to the new version. Then if anything goes wrong there is a full rollback mechanism. Automating everything = Pretty awesome! 

Drupal As A RESTful Backend For Client Side Applications

Arvin Singla gave a quick summary of what the Services module can do and then gave a full example of using Drupal to deliver data for a web service. It would be a good learning experience for anyone looking to implement a service in conjunction with their drupal site. The main downfall for Drupal currently, as Arvin points out, is that every time the service is accessed, Drupal does have to do a full bootstrap. A full bootstrap has quite a bit of server overhead and database accesses. He also mentioned that there are initiatives for Drupal 8 to change this so that Drupal can have a minimized bootstrap and optimizations for Service implementations. Caching can be used to improve performance, but only on open data. Any requests that require authentication cannot be cached unfortunately. One thing that I learned through this presentation is that the services module not only delivers data for a service, but it can handle the full suite of http requests such as post, get, update and delete. It supports multiple interfaces such as REST, xmlrpc, json, json-rpc, soap, amf, etc. It also supports authentication through Drupal and OAuth.

Snatching Usability From The Jaws Of Drupal

Michael Kera's talk was by far one of the most inspired talks of the conference in my opinion. It got me excited about the future for Drupal in terms of the whole user experience side of things. His talk made me long for the future and realize the pains that I have been living with but not knowing any better. It was kind of like living my life with 4 fingers and then realizing one day that I could also have a thumb. Michael's talk was more about looking to the future then a guide. He discussed what we need to consider to make Drupal an easier and more enjoyable experience for the most basic user. He says that going forward its important to understand roles. Once we understand who is doing what and how they use the system we can then remove the bloat and make page building more enjoyable. An example of a role and bloat would be a user's who's role it is to enter new page content. A simple role, but likely the most common. Currently they need to navigate to the content creation area and fill out the page creation form. Now if they want to arrange specific items in the sidebar they have to navigate to the block building area and configure it using a completely different interface. The bloat is in the interfaces and where they are found. Its actually confusing even for myself that has used Drupal for the last 3 years. Now wouldn't it be nice if you just had one place to go to build a page and add content into different areas? Drupal doesn't have a mechanism to add content into a null space. Meaning an area that doesn't yet exist without a path and/or alias. You'll have to checkout the slides and audio to get the full picture, but Michael suggests a way to arrange page configuration components in a way that is reusable and makes sense to any user regardless of their amount of experience.  He also mentioned that this may not come to be a reality until Drupal 9, so this is looking far ahead, but perhaps there will be some contrib initiatives for drupal 8 that can get us closer to the end goal.

Going Mobile

Blake Hall and Sally Young gave this joint talk that chronicled how they used Drupal and jquery mobile to fairly easily build a mobile application that works across many platforms and devices. They also did a live demo of creating such an app. The source code can be found at https://github.com/lullabot/omgponies.git and their slides are available at http://lullabot.github.com/omgponies. There isn't much I can summarize here since it was fairly technical but I can mention that checkout out this presentation will definitely put you light years ahead if you are just at the beginning stages of tying to create a mobile app. I will list some of the tools they mentioned to check out:

Tools:

• jquery or zepto(much less bulky then jquery)
• jquery mobile framework
• hammer.js (easy touch event handling for mobile devices)
• dragswipe (built on top of hammer.js for mobile carousels) - http://xoxco.com/projects/code/dragswipe
• phonegap - compiles your code & theme into a app for different platforms
• titanium - phonegap alternative

JSON to fuel data:

• views can be used as the data source
• can use straight up JSON wrapped view or services module for more robust interactions
• for cross domain issues you can use JSONP or CORS (cross origin resource sharing). CORS are not yet supported in all browsers.

Templating systems:

• handlebars (helps with markup design)
• twig - server side compiling (Added to drupal 8 core)
• twig.js - client side compiling (the exact same code)
• router.js (written by xoxco.com to handle #hash urls)

The full slides and audio of each session will eventually be online and I'll post a link here when I find them. The other sessions that I managed to catch a bit of that are worth noting are Suzanne Kennedy's Views configuration talk, Sebastian Lesch's Open Advocacy, as well as James Walker's Keynote on Saturday. I missed Angela Byron's opening keynote on Friday, but I heard it was pretty good.

I will close this blog off with my favorite statement of the Conference from James Walker (walkah):  "There is a drupal adage 'Come for the software, stay for the community', but really, just come for the community." There couldn't be a more truthful enough statement.

Thanks Toron'a,  you're a different kind of animal.