Responsive Web Design with Drupal and the Omega Theme [March 28, 2012]

Speaker 1: I’d like to introduce you to Kathryn Cornelius, front-end developer from Amazee labs. She is presenting today from Texas. Michael Schmidt, the head of technology at Amazee lab at Amazee headquarters in Zurich, Switzerland. We also have Jake Strong, the founder of Development Geeks and Theme Geeks and the creator and maintainer of the Omega Theme which will be the focus, the technology focus of today.

Kathryn: Ok, to get started. Before Jake starts talking about the Omega theme and how we can implement it using Drupel, I think it is first important to understand the technologies behind responsive web design, which is actually really simple, and then go over a few definitions which are heavily discussed right now around responsive web design.

A very formal definition of responsive web design is what I have on this first slide. It’s essentially an indication that a website is crafted using CSS3 media queries, with proportion-based grids which adapt the layout of the site to a user-specific viewing environment. Basically this just means that users are going to see a single source of content, whether it is their about page or their home page, or any page on the site, optimized for their device or for their browser size.

Basically the major technology behind responsive web design are media queries. Media queries aren’t anything new. They’ve actually been around since CSS2.1, so we’re all already familiar with those. If you’ve ever written a print style sheet, you kind of already have an idea of the concept of how you declare media types. With a media query, it just contains two parts. The media type, which is all or screen or print, and then the actual query which is in parentheses with a media feature and a target value.

If we look at this media queries in the right hand column, there’s a wide layout, a normal layout and a narrow layout. Basically the first one, the wide one is just going to say anytime that the user’s device or browser is greater than 1220, render this style sheet. The same for the normal, it is going to apply anytime the screen is between 980 and 1019, and also for narrow.

Things get kind of interesting when you take a mobile first approach, where in a mobile first approach, the default layout is always the mobile layout. With your media queries, they are basically the exact same as the queries on the previous slide, with the exception that as the queries on the previous slide, with the exception that there is not a max width set. The media queries operate basically in a reverse order, where the mobile layout is first and then you build your way up.

There’s some pros and cons to mobile first. The pros is that it really helps you to focus on your content. It helps people who are wire framing or working with clients to really narrow in on what’s important, because you have such a small amount of screen on a mobile phone that it really forces you to pare down, right down. It’s also considered to be the future of web development, which is challenging for developers like us who have been working on desktops for whoever many years, it really changes our process. How to build things and how to think about building sites, and how to think about planning.

One of the cons is that it’s really difficult to present this approach to clients because it’s really a change in their process as well. They are not thinking mobile first necessarily, so it’s difficult to communicate why you would want to present a wire frame on a mobile device first. Those are just pros and cons, but it’s probably going to be the future. With all the talk, I don’t think this is going to be a trend. I think this is going to be the way that web development goes moving forward.

Moving on to definitions. This is something that is talked about quite often, I hear, not only in the Drupel community but in the web industry. There’s all these conversations about responsive versus adaptive. Those terms can be somewhat vague. The way that I think about it is just a responsive site, everything is fluid. The grids are fluid, the images are flexible, everything is really percentage-based. An adaptive design, you have multiple fixed width layouts, meaning that you declare a scale sheet for a wide layout, for a lap or a desk top. For an iPad, for an iPhone, and those grids are all pixel-based, and your images are also a specified width in pixels and they change from one layout to another.

Here’s a slide, some screen shots from two sites that are both responsive. I interpret the top site, the fore fathers website, as being adaptive and the Smashing magazine site as being responsive. The visual cue that I’m taking to come to that conclusion is, if you look at the desktop version on the right of both sites, you’ll notice that the Smashing magazine website on the bottom really fills 100% of the screen. It looks like it’s going to be really responsive, so no matter what size your browser is, it’s going to fill 100%. Whereas the Fore fathers, you can see those margins on either side indicating to me that it’s probably on a 960 grid, or maybe that’s the wide layout of their site.

I really think that there are pros and cons to each approach. Normally when I think of adaptive I think that the site may have already been designed for a desktop, and then the people who are in charge of the site realized that it is important to have a site that can be used on different devices so they just adapt it. Responsive I think people are really starting a project from scratch and just cleaning it all out to be completely device independent.

You can also have a hybrid, which is basically a combination of fluid and fixed width grid, and fluid with fixed width images. At Amazee labs we have done this. We’ve had adaptive wide layouts, desktop layouts and iPad layouts or tablet layouts, and then any time we have a mobile, it’s always fluid. You can define your own grids with omega, so you can have percentage-based grids or fixed width grids. This theme, Omega, is really flexible in terms of how you want to configure it. You can certainly use their default media queries, but you can also define your own. Same thing goes for the grid.

You can really optimize it as much or as little as you want and it’s just going to work. Having said that about the media queries and the definitions, I think it’s good to go ahead and hand this over to Jake. I’ll pass the host over to you Jake, if you want to take over. I don’t know if your audio is good now.

Jake: Okay. Just testing there, can you guys hear me? Looks good. Sorry for audio issues, my quick introduction, Jake Strong, and I operate a little small dub shop here in New Hampshire, and I am soon to be launching the first premium theme community, all based on Omega with responsive and mobile first themes at Theme Geeks. To get started with what I want to go into fairly quickly, it’s no deep dive into any of the responsive handsets with Omega, but goes more into a simple introduction and the feature list.

What we’re going to go through simply is what is Omega, following with how Omega can help site builders, themers, and developers all differently. To start off, what is Omega? Omega has already been around since D6, and has seen several revisions already in D7. The most recent of which included all these responses, enhancements that we are also excited about and so many people have jumped on board with. Out of the box, Omega gives a variety of grid sizes. The defaults are 1200, 960 and 720 pixels, and also includes the fluid percentage based grids as well.

Omega is mobile first, so your mobile / global market is what’s treated first. Any device, any browser that is not media query aware, displays the mobile version of the site, and then progressively enhances as we get to a more capable browser or device, to show any alternative layouts we have. Omega is HTML5, using some of the basic standards and new elements, as much as we have figured out how yet in Drupel. The most important thing I think of Omega is how customizable it is via the user interface. You’re able to quickly configure anything to your heart’s desire, and not through the interface, but implement your own grids and use those through other interfaces as well.

Also quite importantly, is the current adoption level of Omega. It has skyrocketed over the past 12 months, and has over 20,000 installs. It’s, I think, at number five on the all themes list, and is included in distributions now like open publish, the new open enterprise, and others.

To move in first, how Omega can help site builders. With no ill intentions meant to site builders, because it is an advanced, complexity all to itself, but traditionally most site builders may or may not have a very extensive knowledge of code or editing or adding templates. What Omega can give a site builder is the quick and easy method to configure the layout of your theme completely from start to finish.

This can be at times, I’ve seen it done now where somebody may be on the marketing side or the project management side, can actually go in with a clean Drupel install and Omega, and build out the wire frame based on grid sizes, and figure all the regions appropriately, and have it ready to go and show demos to clients, hand over to themers, developers, et cetera.

How Omega can help themers. Again, much in the same way. The structured zones and regions. Zones are a concept only in Omega, currently, based on grid philosophy. A zone is just a container of regions that can contain multiple regions, sized and positioned how you like. Again, the rapid protyping wireframes. Usually it takes me about ten to 15 minutes max to configure an Omega sub theme based on the most simple or advanced wire frames, and have that out the door and be ready to start putting the design CSS toward it and start implementing the cost.

It saves you so much time in having to deal with the traditional layout issues from the days when we constantly created the CSS to place with and position and size our side bars, and then dealt with cross browser issues. It speeds up a lot of that process for themers.

Lastly, how Omega can help developers. The most important things I think here are the exportability. Using the Omega tools module in conjunction with Omega will allow you to, essentially after you’ve made all of these configurations in the interface that then are stored in the database, traditionally there is no real Drupel way yet to get those configurations over to your developers, if you’re working in a large environment, or be able to push that to production without reproducing the clicks.

With Omega tools, you can actually simply go in and once you’ve made your configuration changes, export the settings, place them back into your .info, and then commit them to your repository to pass off any developers staging or production environments you could have. Another feature is the Drush integration, that will allow you to quickly create a new subtheme by a simple, simple Drush command, and also in the latest revision, there is also an interface version of that, that will allow you to step through a couple of pages from your appearance screen. Where you can just click, create an Omega sub theme, and it will ask your for name, description, a few configuration options and then instantly save and write that new sub theme into your themes directory.

With all that being said, and that is really kind of just a quick overview of some of the broad features of Omega. As we continue on, take a look at Omega, give it a download, give it a try, and definitely shout out to the Amazee team as they have been one of the companies that have really adopted Omega and have been able to, all on their own, just put out some amazing designs and implementations with it. With that said, I will hand it over.

Speaker 3: Thank you Jake. Yes, let’s continue. How do we actually plan the responsive design projects? I said we made a couple of customer projects and planning was most times quite hard in response to time. The first thing is, we only got provide to this break point. Like 960, 720 breakpoints. Even if you know the break points, the question is, how does the content change? What is the most important thing? This you have to facilitate during the work theatre, so how do we get there?

What we ask our customers, and if you do your website, your own things you can ask yourself, what is the most important content. Even if you use mobile first, that is what you have to do. In a mobile theme or just in a narrow theme, you have that space, so the content which is most important should be shown first. Another question is, can we get rid of some content? Do we really need every single piece on a mobile phone or a smart phone, whatever it is? Sometimes we can remove stuff that is not necessary there.

Sometimes maybe you need more information, because a user needs this on the road. These are all the things we discuss with our customers and ourselves. What is really needed, what is the most important thing there? How to get there, if we use wire frame, we use mock ups, the wire framing tool. You can also use paper, or whatever else, just to be really fast to maybe make an overlay of an iPhone and just imagine what it will look like. You will realize really fast that it is not easy to find out what is the most important content, because as you can change so much things in response to that.

Sometimes maybe you need sub break points, and by sub break points I mean break points between the normal breakpoints that Omega supplies you. As Kathryn said, basically there are only … that’s the theatre things, and in the queries is in the theatre. You can add yourself, and what we did with specific websites sometimes, is when it gets too white, but the breakpoint is not yet there. What we do is we create sub break points to facilitate that. Okay, after for example 800 pixels, we float the menu to the right or to the left, or we don’t float again. That is all the things you can define in sub breakpoints.

There you have a lot of flexibility. One thing, how you can see it here, is a picture we found. Write it down, there you can define a lot of things like see the menu on the landscape on the iPhone. On the web it flows left and right, the landscape it is left and then on the phone you have or the slider, which changed completely. All the different things. The earlier you do them, the better you can do them. The cool thing about Omega, because all these things you can do really fast in the browser without writing any lines of code. You can really fast get to testing them and finding out if they work or not. That is all about sequence.

The next thing is the grid. What we did is create some pages where we didn’t even know how many pages we would have, because the customer created the page. There you need a way, how to deal with all this stuff. The first thing we use is a grid system; we use it quite heavily. The problem is, maybe problem is the wrong word for this, but sometimes the designer is not really used to a grid. It really depends on the background of the designers, and we just teach our designers really heavily to use a grid.

Sometimes what we even do, we even find ourselves even the grids which are inside Omega are cool, sometimes they don’t perfectly match and I will show you some examples later. We spend sometimes a really long time to find the right grid, the right columns amount, the right gutter. Thinking about all the specifications we need, so this could end up spending one day to find out the correct grid, but this saves you a lot of time issues. If you want to create your own grid there is a website, grids.heroku.com, which is also used by Omega.

You can create your own grid, you can see I need so many columns, I need this gutter, et cetera, you can directly use in Omega. The only thing you have to do, is you have to change the dashes into underline, because Drupal separates the class names with underline, so that is the only thing you have to do. This gives you a really easy way, how to create your different grids for normal, narrow, mobile, et cetera.

Here you see an example of Foto Bout, and we will talk about Foto Bout a little later. As you see, the logo for example has five columns. The menu, each menu item has three. The vote button on the left is three, again and then the user picture which you see up there, it’s not good but that’s two and columns. These help our designers. Everything should be in a grid, of course, it is not proper all the time you cannot define the width. It’s still, they use a space of two columns. Sometimes it’s not possible, like the Today’s Round doesn’t fit at all, so there you cannot use the grid system, but the rest is really heavily used, and Kathryn will show you later how we did this.

Here we’ve got an example where we really heavy, that’s a project we are working on right now, that’s why I can’t show you the whole site, but basically everything is inside the grid. Each button, each input field. Here we have a special column, on the left the dotted line is basically an apparatus of one column which is empty, but gives us a design possibility to separate things. Here we really used a lot of time to design the grid, how can we design it finding how and now we have one and it works awesome.

After we design the grid, maybe the design matters. If you use mobile first, then you design mobile first. If you do desktop first, you’d probably do a design for desktop first, it doesn’t matter. Now the question is, which page do you actually have to design. Does the designer need to design every page in a fluid, in a wide, in a narrow, all these things. We don’t do it. What we do, we talk to the designer, we find out what should move where and because wireframe, it doesn’t really change on design. It just changes width, height and position, so it doesn’t really change. How the design is.

One important thing is the touch area, because on an iPhone or an iPad or whatever, you don’t use a mouse. You use your finger. The finger is quite bigger than a normal mouse, so the space which actually should touch, should be bigger so it is easier. The phones are today really good in guessing which link you want to click, but sometimes it still cannot work. That’s definitely something you have to think about. If you want designers to make a mobile version, think about touch and whatever.

Here an example for you. That’s a specification that a designer made for us, and it’s quite small but I’ll let you move through this. Here we see the three layouts On top is the normal, then we have a narrow, and below is a narrow in portrait mode. As we can see, the design specification picks up because all elements are still the same. We only needed to know, okay, what happens for example if here, the menu, if it gets smaller. We have no space. He said, make it smaller first, so you see the packing between the lines are smaller, and here it breaks. That was one specification we could read out of here.

Another thing is the height of the menu. Here you see it’s around 15 pixels, 20, and here it is 30 pixel. That’s how we made the touch area bigger. All of the things is just in here, and that’s what we used. We had about five designs for all and only one single design for the website, how it looks like in normal, and narrow and mobile. That’s how it then captured the mean went in and did all the responsive capture design for this page.

After we have the design, we should merge. The cool thing is, basically instead of counting pixels in Photoshop or wherever you do this, it’s not necessary any more. Everything is a grid, you basically just count the grid columns. The idea is in a grid system you have a grid slash one, grid slash two, et cetera, depending on how many columns you have. There is always definition actually what you have to do, we only have to add grid classes to the markup. We never, or we don’t really have to write this inside of our custom CSS. What I would like to now give over to Kathryn, she will show us how we did this in Foto Bout and maybe come back around about Foto Bout. It’s a small design we did and Kathryn, me and Andrew, he is our designer, and we built Foto Bout.

It is a page where we upload every day a picture, and you can vote, everybody can vote, and for us it is really a testing page, again, to show what is possible with grids. Kathryn, show us.

Kathryn: Okay, so this is Foto Bout, and I’m sharing my desktop so hopefully you all see Foto Bout. This is the logged in version, so I have my toolbar at the top, and right now we’re viewing it in the wide layout. I wanted to show you what Michael was talking about with adding these grid classes, versus measuring containers on your website in pixels. If we look at this, if we infect this code, or if we infect this markup, we can see that this grid has a class grid dash five. Right here. There’s a lot of these grids designed, grid dash two, grid dash five, below the image is grid dash 12.

This is not standard Drupel output. They way that we are getting these classes added to our markup is actually quite simple. We are using display sheet. I’m going to go in to my content type, which is a picture. Michael and Andrew both upload a picture every day, and I’m going to manage the display with display suite. If you don’t use the module I would recommend it, it works well with Omega and it really decreases the amount of template files that you’re writing as a themer, if that’s what you’re doing. It doesn’t just decrease it, it eliminates the need for template files in many instances.

Let’s look at the after voting view, which is the past score cards, basically just the results. Here are our fields. We have the rating number, the picture with the link in the middle, and in the footer we have the picture number and the title, so that is all reflected here. The number of, the score, their picture, the main photo, the title, it’s all here, so you can see how that’s all related. The interesting thing, at the very bottom of this display mode, you can add extra classes for regions.

For the left region, you can see that grid size is selected. For the middle region, grid two is selected. I think for the footer, grid 12 should be selected, yes it is. You can see that all right here. That’s where the grid classes are being added. We do that through Display Suite, but you can also add classes like this in various places around your Drupel site. Probably if you are using panels, you can add it to a panels template, or maybe even directly through a page manager. You can add it through views probably, through classes in there. You can really get creative to where you’re adding these grids.

What the advantage is to adding these grids is we’re not defining width anymore. Even if your grid is percentage based, and even if your grid is pixel based, you’re still not having to go in for every single layout and change it. You can see that over here, we’re in the wide layout, and the width is defined as 257 pixels. I’m going to go ahead and resize … sorry, you can also see that it’s being called from the wide style sheet as part of our theme. It’s not from our global CSS or our custom CSS, it’s just the standard grid CSS.

Now, if I resize, and now we’re in the … let me actually get it to … I think this is the narrow, there’s something going on here, maybe it’s because I’m logged in. If I do in and infect the same area, the grid now has a width of 144 pixels and again it’s not being called from a custom or a global style sheet, it’s just from the narrow style sheet that is holding all of our grid width in the theme.

The other really cool thing about Omega that it does, is it makes theming really easier, adding CSS really easy by adding body classes. Here you can see that this layout has a body class, this last one right here, it’s responsive layout narrow. As I resize my browser and I go into let’s say the wide version, my body class should change. Well I’m not in the wide version right now, I’m actually in the normal layout, but you can see that the body class is now responsive layout normal. It would do the same thing for wide, or fluid. It just adds another class that makes adding your own CSS really simple.

I hope that demonstrates the principle behind shifting the way you’re theming when you’re given a photoshop file away from counting pixels, or measuring pixels, and just counting grids. Let’s see. I’m going to go ahead and hand it back over to Michael. If he wants to elaborate more on that please feel free. I’m going to hand it back over to him.

Michael: Thanks, Kathryn, for the presentation. My screen started refreshing. Basically if you want to try it out, go to fotobout.com. We saved it for this presentation to theatre segregation, you see the different theatre styles, how they are loaded and really play around, test it. Use it, copy it, whatever. One thing, what we actually use there, is the display suite, and sometimes we need display suite extra, which gives you way more control about all the different styles and the classes which are loaded into the theatre. For each view, you can add additional things in there, works perfectly with Omega.

One thing with Omega is a small problem. As you saw, we spoke about, the whole area is one stone and a region inside of Omega, there there were those panels. You can load panels whenever you go there. The problem is now, that Omega already gives the rector a grid slash 12, or a grid slash 24. Now if you make nest a script, inside as you saw, grid slash two, grid slash five. You have a marching left, marching right, problem because two times the rec defines marching left and the element also. What we do, and you will find this also on fotobout.com, is you search for no grid inside of the H to stone structure, we end to the stone via Omega a no grid class, and inside there we basically remove the marching left and the marching right again because the inside elements specify them already. That works.

Maybe some insight from Omega, have to talk about this in group from Denver, there will be a pseudo color region in the future, which probably prevents you from doing this, so in the future you probably don’t have to do this no grid class anymore.

Now, we have the site done, we designed it, we tested it, we built it, everything else. Now it’s for testing. There are multiple ways how to test a responsive design site. The obvious thing is, use your browser. Retype your password, see what happens. That works quite well and that’s what we use during development all the time. There are some cool sites like responsinator.com, which shows you your website inside of iframe, with the correct sizes of the access, and it just gives you an overview, does it look good. The thing is, it’s not rendered correctly in an iPhone, and this can cause sometimes problems. It is a fine overview, how it looks like, and it also works with local host, so you don’t have to upload your site or where ever to test it.

One new thing which came out recently is Shadow from Adobe, or called Adobe Shadow. What it is, it’s actually a Google Chrome plug in, Internet, for your iPhone, iPad and Android, so iOS and Android. To install it, connect them to each other, and you can have multiple devices connected. If you now visit your site in Chrome, it’s automatically also loaded inside your devices. The devices load the site itself, so it’s no fringe work or whatever, so all media quires are called and you can easily test it on a lot of devices at the same time.

Another really cool thing, you even can inspect. You have your own inspector inside of Chrome, but it actually shows the inspector of the html structure of the phone. If you’re ever need something, you’re not sure what’s happening, use Adobe Shadow, it’s a really cool tool. It is still in beta, but you can download it for free and it works really good. The problem is, with Adobe Shadow, you need the devices.

There are other solutions for this. One we use is browserstack.com. Browserstack is basically a vehicle machine inside your browser, and you can install all the different browsers, like Internet Explorer, really old versions, new versions, whatever. They have recently added their mobile devices. They run an iOS simulator and an Android simulator inside off furium, and you can really easily install it there and test it.

Another possibility is you can actually install the iOS simulator or the Android simulator on your computer directly. The problem there, it is quite hard to install the Android simulator and the iOS simulator that is why we use then Browserstack.

Another thing, responsive images, and already people asked about that. First, it is really, really hard. Why do we even need this? The problem is, if you have a wide version. We have around 1200 pixels. If you show a picture big, if you have a picture of 1200 pixels. If you have an iPad 3, you even show two and a half thousand pixels wide image. We don’t want to show this on an iPhone, because it takes a lot of time to load. There are a couple of things about responsive image.

Right now, there are three projects which can do this info for you, and I have to tell you, all of them are not perfect. The first, on the line image, uses cookies and JS replace. The problem there, you need cookies, which is not really liked by reverse proxies or for caching. If you have a high performance website, with warnings, probably you don’t want to use cookies to do this. Another thing is ais, which is also responsive images but relies on Apache, and again a cookie. Again, if you don’t have Apache or high performance pages, it will not work.

The last thing which is the one we use at Amazee lab is CS Adaptive image. It uses only JS, no cookies at all. What you do basically in your field for making a foreign image, you specify which image cache should be loaded for which width of the screen. You can say if the screen is smaller than 400 pixels, load this image cache preset, if it’s bigger than load this, et cetera, et cetera. Right now, it’s really hard to configure it because you have to do it for every single image field. It’s quite hard. We are trying to fix this right now, so if you are interested in helping us, please contact me. We need some testing development or whatever, and we really would like to fix this responsive image problem for now and also for the future.

That’s it. That was our presentation. I will take over to Chan to make the Q and A.

Jam: Thanks very much everyone. That was very, very interesting. I’m just going to switch to a contact slide here, I think, this will do. What we’re looking at is the contact information for all of us involved in this webinar here today. Now I will hit the questions that have come in so far, if anybody else has a question about the technical side of this, we have a little bit of time, and you can go ahead and put those in the Q and A tab.

The first question … I don’t understand, but I will read it, and one of the three of you, if you feel you understand it, please help me out. Someone says, my worry is support. We still have a lot of people calling in and we have to tell them to click on x in the right corner. Then under that, do you have any experience with that. I suspect that this means if the layout is different on different devices, and they have users who basically need a geographical screen reference that’s going to be trouble. Do you have any thoughts of any type about that?

Michael: I don’t understand the question, so maybe if you could ask it again? Dominick, maybe ask it again; I don’t understand.

Jam: What was that Jake?

Jake: I wasn’t sure of the question either, exactly how it related.

Jam: Okay. To me, it feels like we’re talking about when I do tech support for my 80 year old relative who needs to be told to click the blue thing an inch from the top left, and if it’s not an inch from the top left they are going get confused. That might simply be an issue of user training at this point. The next question, someone is curious to hear about form UI switching based on device. Form element behavior, dropdown menus, transforming to select list, et cetera. How is that actually set up so when I look at a site on a desktop it has one set of widgets and elements, and on my telephone it might have a different set?

Jake: I can talk on that one. Just from the Omega side, there’s a lot of ways to go about some of those type of enhancements. It is pretty common now, when you get down to a mobile site, maybe primary navigation is in that select list. It’s possible, through a variety of ways, Omega has Java script, J query behaviors that are fired each time that responsive layout changes, such as Java was trying to demonstrate on that body class changing. That is all happening on the back end via Java script. You’re able to fire off any type of custom J query that you want to do any enhancements to any resolutions, in Omega specifically.

Jam: Okay. I do notice a few technical and interesting questions coming in the chat tab, but I can’t really monitor that very well. If you do have a question, please put it in the Q and A tab. The next question, I think we’ll shoot this straight to Jake. Does Omega provide editable interfaces for HTML type video and audio tags, that is browser independent audio and video controls?

Jake: It does not. Omega is set up for any HTML5 you want to integrate, and I think currently the status of a lot of those types of elements are still in flux enough that there is no way on the basing level that I could make assumptions of a certain element and put in that specific a markup. I think that really relies on each new case and each project you’re implementing it on. There should be no problems integrating any custom
audio or video elements with html 5 in Omega.

Jam: Okay, great. I think the next question is probably appropriate for Kathryn. Are multiple grids available as a starting point within Omega?

Kathryn: There are. I think the default, I think there are three. I think it’s 12, 18 and 24 that are shipped out of the box. If you want to define your own with maybe a 15 column grid, you can add your custom grid in your Omega sub theme and it becomes available to you to define your zones and regions when you’re configuring the Omega theme. You just go to the appearance tab and select your custom grid. It’s just with three out of the box, and then you’re free to customize it to your heart’s desire.

Jam: Fantastic. The next question is, how does the Omega tools module compare to or work with the features module?

Jake: Okay. It really is a separate entity. It’s exportability just provides, after clicking on the export link, a simple text array with the settings array you would see normally in your themes.info file. This is one method of exporting that variable that’s stored in the variables table, in order to get everything to code. You could use, rather than that method you could use Strongarm with features to do it there, but essentially by itself features isn’t going to tie into that. I would have loved for that to essentially be a features exportable, the way it is also with the companion delta model which is features exportable, but it’s just not really realistic on the theme layer.

Jam: Okay. If I’m running a D6 site with the D6 version of the Omega theme, how well does the upgrade work and how do I make that into a responsive site, which is only possible in the D7 version?

Jake: Who wants to take this one?

Jam: Michael?

Michael: Sorry, I didn’t hear. Good question, we never had it yet. Maybe one important thing, the question is if he uses Drupel 6 already with omega or not, because Drupel 6 Omega has no response design possibilities. I guess it’s not specifically more harder than the normal Drupel 6 to Drupel 7 update, which in my experience depends really on the site size. I guess it doesn’t really make a difference from normal Drupel 6 to Drupel 7.

Jam: Okay. The next question asks about what wireframing tool you use, and I believe you said you use Velpamic, is that right?

Michael: Yes, Velpamic. I can type in the …

Jam: I’m just actually pasting a link to that. If everyone can see the answers in the Q&A tab, I just put a link to Velpamic markups there and also in the main chat. It’s a tool that I’ve used a lot over the last couple of years and it’s fun and it’s a way of making a look and feel so that your clients understand that this is not the style that you’re talking about. I’ve had pitches with clients where they would be defected by the fact that I was using gones in green and they would say, our corporate colors are not green, and I would I’m just trying to show you how the feature works. It’s a helpful sketching tool, especially for people who are not so good at the whiteboard.

Someone asks, I’m hoping to use responsive design on a site where accessibility for blind and partially sighted users is essential. I would particularly like to use WRI Aria Markup. How well is Omega suited for that? I was also looking at the Yamo Framework.

Jake: I wouldn’t personally think there is any issue with integrating any of that. I’ve worked on a few 508 compliant sites and had no issues. I think all the templates are editable, you are able to customize it as you would a theme to implement those types of items. I think the biggest issue is dealing with potentially modules that may or may not provide appropriate mark up or theme function.

Jam: Right, so I know that you’ve been working with phase two on marking Omega the overall base theme for now public and also for one or two of their other distributions, which ones is that?

Jake: That’s correct. Open public, and open publish.

Jam: Right, so open public is certified to be used for US Government websites and the 508 compliance that Jake mentioned, if people don’t know what that is, that’s a whole set of standards that provides among other things an acceptability baseline for users with different kinds of browsers, for example audio browsers for blind users and a bunch of other standards. I figure if it’s in open public, and Jake says it’s also, doesn’t have any special configuration that prevents you from using any other mark up, I think you’re probably in good shape to try it out.

Somebody says, I’m totally sold on using Omega but I’m under a really tight timeline to develop and launch a new site. Are there any steps, instructions or tutorials out there for configuring and installing Omega that could get me going ASAP? I was thinking that Kathryn might address this. You’ve talked about how easy and intuitive it is to set up once you’ve wrapped your head around this morning Kathryn, why don’t you tell us a little more about that?

Kathryn: When I first started with Omega, I was constantly in the documentation and I still refer to it often. I don’t know the link off the top of my head but maybe someone can find it and post that in the chat. There is really good documentation. I think they are working on the version three documentation, but everything that is existing online is very helpful. In the previous section that we did this morning, I talked about, I had a friend, a developer who had used Xen in the past. When I made a switch to Omega, it just took a little bit of time to become familiar with the tabs, because there are more configuration options in the theme than many of the other themes that are available.

I think that it’s worth spending, I don’t know how long, maybe a couple of hours playing around, starting to understand how regions and zones and sections all interact. How you can add your own grid. It’s really just going to take some time reading the documentation and just playing with it, but it is easy to set it up and start going if you just use all the standard, out of the box settings that ship with it, you can have a responsive site, pretty much immediately. Yes, so somebody just posted the Omega handbook link. It’s in the chat now.

Jake: If I can add to that very quickly, we do also have a very active IRC channel on Drupel/Omega on FreeNote. That’s usually 50 to 70 people in there as well that can help you get over some of the immediate hurdles that you have and help you on your path.

Jam: Fantastic. Somebody asks if there’s a version of Omega that works with Drupel 6. Yes, Omega started it’s life as a great but non-responsive theme for Drupel 6. I believe that there is no reason not to use it, but Drupel 6, I don’t know of anybody running Drupel 6 sites that have a responsive and therefore device agnostic theme running. If you want to take advantage of the stuff that we’ve been excited about today, you really need to be running a Drupel 7 site and the Omega theme is one of the ways you can have a responsive Drupel site.

The module that Kathryn used for field formatting via the UI is … we had this come up this morning as well, that’s Display Suite. Is that right Kathryn?

Kathryn: That’s right. It’s project/ds on Drupel.org.

Jam: I’m typing this as we go, not even looking it up. I put that into chat now and I will add it to the question as well. Drupel.org/project/ds for Display Suite. That’s the tool she was talking about. Ah-ha. Someone says, 2011.drupelcampchicago.org uses Omega 6 one and has custom responsive break points with JS. All right, thank you, Eric Baldwin, I’ve learned something for the day. Now I can close my mind down for the rest, no I’m kidding. That’s great to know. I believe that this is less common and I believe that it’s easier to do with Drupel 7, so I’ll just let that stand where it is.

Someone is asking, are there performance speed tests run on this output for mobile phones and tablets with live network speeds. They ask what sort of range those responses are in. I’m asking myself if that is more or less device or network dependent. Does anybody have experience with the delivery speeds of Omega sites when they’re delivering different versions of the site?

Michael: Basically, as you said, it really depends on network speeds. One thing that we actually would love to have is when you deliver a menu or image, that you know how fast the network is right now, so that you could provide an end user with a really, really small image and if you are in Wi-Fi, you get a big image. That’s not yet possible, we’ll see how this will be in the future. Basically, smart phones are getting faster and faster, and rendering theatre, politic, whatever. You can use really cool and a lot of theatre. Still it’s more so in the last chapter, but I can’t really tell you of tools that can. It really depends on the network.

Jam: Okay. When you said, I just want to clarify, the point you said. Did you mean that it’s currently not possible to detect the network speeds of any given person connecting to websites?

Michael: Well I heard from things that people are using Java Script to find out how fast an image is loading and then creating a cookie, so that is like a work around to do this, but there is today no possibility from the browser to be informed how fast the network is.

Jam: Is there a best practice to determine what type of device is hitting the website, something like [Motheriser 00:55:13]?

Michael: Yes, there is. J Query has already some capabilities testing stuff, and the other thing, there are a lot of user agent testers, I guess it’s called mobile tools. The problem is with all these stuff, with mobile tools it’s happening on the server which makes it really hard to cache. Basically what you would have to create, a cache for each single user agent its own website, so if you are on a cached website, this is not going to work. We really use only responsive time and say well, we don’t care who actually uses the device. We only want to know how big you are, and depending on how big you are, we give you a different size.

Not depending on the type of device, you already change something. You maybe take J query browser that’s already in J Query.

Jam: Okay. I think this is probably a question for Jake. Have any of the presenters used Omega in conjunction with Delta and Context modules? At least two of those are your modules, or Delta is definitely your project Jake, so can you talk about that?

Jake: Yes, I do use them, the Delta module still quite frequently and I’m a really big fan of Context. I use, essentially the Delta module for anything that will decide to, on different sections or pages, or sections of a website based on any condition in the Context module. It allows you to set up a whole different configuration for your regions, their placement and things like that on different sections. Depending on the project, I use it or I don’t, just depending on performance needs, the complexity of getting that all set up.

Jam: Okay. What impact do the new ultra high resolution displays, the Apple retina displays, what impact do they have on responsive design?

Michael: Yes, so basically that’s the same questions as the second. From theatre’s point of view, it doesn’t change anything, because an iPad or an iPhone 4S with a retina display, still says to the browser, I’m 320 pixels width, even it is actually has 640 pixel hardware, it says I am 320 pixels. It doesn’t change anything on your end. That is probably how it will work in the future, the device still says I have 320 pixels. That is also the question, the next one, what is the future of your pixel based model. As long as they use this same thing, it’s not going to change at all.

There are possibilities with non-responsive devices to change this behavior. There is identity DTI setting which you can do in the header; if you have 640 hardware pixels, use 640 hardware pixels for example. We will not adjust it because then stuff gets really, really small, because the pixels right now are really small with a high resolution. One important thing there is images. That’s one thing I also tried to fix with the responsive images modules we’re planning. If you show an image which is 320 pixels to a device which has high density, the picture will look, sorry for the word, crap. It will not look good.

That’s why for example at Foto Bout we don’t use responsive images, because we want to show really good pictures, as they are already. That’s why we basically just change the width of the image via theatre or html. Then, what the high resolution screen will do is to show this in a way that is good. To round up, on theatre it doesn’t change anything, on images it does and I hope we can fix this in the future.

Jam: Great. What underlying CSS framework does Omega use? Does it support a vertical grid for typography? Anyone?

Jake: Yes. By default, there is no vertical grid included, but there is once again absolutely no reason why someone couldn’t add the additional CSS in their own subtheme to make that quickly and easily possible.

Jam: Okay. I think we’ve come to the last question of the day. We touched on this this morning as well, and it’s an interesting problem space so I expect the answer will take a few minutes. How well does the Omega theme work with modules like panels and panels everywhere? Does Omega make panels irrelevant?

Michael: Jake do you want?

Jake: I will start off and you guys can jump in here. I have used panels in the past. It’s a great technology, I haven’t used it in quite some time. However, a lot of people do still rely on panels and I know there are quite a few big projects going out the door that have already gone out that combine Omega with panels. I think the biggest challenge there is kind of by its nature with the interface, you’re building out a panel display that’s … let’s say you’re using that flexible model where you can resize your panel layout regions right there, you have to deal with that when now you’re thinking about these other breakpoints and what happens.

There is no reason at all why panels cannot be used with Omega. I have seen some great examples. It’s just going to take a little extra love and care in order to do that. If you were to set up your panels in a way that they’re using the items that you place in maybe a single column panel, are using grid classes so then those are laid out appropriately, something like that would immediately take effect with the responsive enhancement with Omega.

Out of the box you may have some tiny difficulties to start with, but a little attention to detail and it should never be a problem.

Michael: Yeah, I can definitely jump in there. We never use Context, even we tried it out. The problem is for us, most of the time when customers have access to the panels, it’s just something that really doesn’t work for them instead of Context, where you have one big place where you have to edit all the blocks. In Omega already there are some panel samplers, which already have the grid stuff in, so you don’t have to do the things which Kathryn showed you. Sometimes it’s not the correct one, but you still can create your own panel template via the panel builder. They are actually inside the panels, and just assign the grid slash x, whatever, to the column or create your own template. It definitely works with Omega.

No, Omega makes panels not irrelevant.

Jam: All right. Thank you all very, very much for coming. Thank you to my presenters. I’ll run through a few details and then we will sign off for the day. This recording of this webinar will be posted in the next couple of days at Acquia.com at resources, recorded webinars. Acquia also has a slideshare account and I have asked the presenters for permission to post them there to make them available for people, is that all right with you presenters? Great. I will make an effort to get those online in the next couple of days as well.

Check out acquia.com/resources/webinars for some more interesting presentations coming your way in the next few weeks. If you’re looking for a Drupel job, Acquia is looking for people in North America, Europe and around the world. Thank you very much Kathryn Cornelius, kcornelius on Twitter, from Amazee labs in Texas. Thank you Michael Schmidt, schnitzel on Twitter, coming to us today from Zurich, Switzerland, also Amazee labs. Jake Strong, development Geeks founder and creator of Omega, himerus on Twitter. My name is Jam, my Twitter handle is horncologne. Thank you all for coming.

Jake, Kathryn, Michael, any last words?

Michael: No, have fun with Superbowl.

Kathryn: Have fun with Omega.

Jake: Thanks everybody for showing up.

Jam: All right, thanks very much everyone.