Home / Taxonomy term

Webinar

Building a Common Drupal Platform for Your Organization Using Drupal 7 [April, 17, 2012]

Click to see video transcript

Hannah: Today’s webinar is Building a Common Drupal Platform for your Organization Using Drupal 7 with Erik Webb, who is a Sr. Technical Consultant here at Acquia. We’re very excited to have him presenting this topic today. I’m Hannah Corey and I’m a Marketing Specialist here at Acquia.

Erik: Today’s webinar is primarily focused around, really trying to look at this newer model of, especially in distributive organizations where there’s lots of teams, lots of different developers, owners, stakeholders that are really spread out across the company’s organization, and really trying to find a common platform for all of them to work off of.

We would rather this than trying to force everyone to be all together on one site and artificially creating those sorts of barriers or having this really wide open landscape of way too many tools. The management gets really difficult at a certain point. We’re going to talk about some methods to be able to standardize on Drupal, but at the same time also give people the flexibility to extend their own sites in different ways or even take ownership in the needs that they have.

First, I just want to talk about a quick agenda of what to expect here. I want to talk about what is a platform. There’s the platform as a service. There are lots of different definitions of what a platform is these days, but I want to make sure we’re all talking the same terminology and understanding what the word platform means, at least in the context of this particular presentation. We’ll look at some types of platforms. How do these platforms actually work in different ways and what are the strengths and weaknesses of each different form?

Achieving buy-ins. One of the biggest things that a lot of people have difficulty with in platforms and trying to centralize people around one sort of idea, is people are afraid they’re losing control or they’re somehow losing the autonomy that they had previously. I’ll be specifically talking about the main points you can use to sell the story.

The last two things that I want to cover is Leveraging Drupal. What are the main features of Drupal that make this kind of platform attainable and even easier, maybe, than some other tools? Lastly, looking at how Acquia fits into all this. In talking about all these different kinds of platforms, how can you leverage Acquia to take advantage of, not only Drupal, but the hosting packages, the reusable templates? What makes this whole process really accelerate and easier for everyone to manage?

First, let’s talk about what is a platform. I’m sure everyone that’s joined us today. It’s a big buzz word that’s out there that means a lot of different things to a lot of different people. Is this a platform? Sure, it’s a platform. It’s a different world, but it works the same way. Train stations, those are platforms. But, even in the technical world, what’s so funny is there are even discrepancies in the technical world. If you look at PC Magazine, their basic definition looks at the architecture of any sort of generic foundation or base, which is about as generic of a definition as you can get. John C. Dvorak is kind of an internet curmudgeon. For those of you who don’t know who he is, he’s an internet journalist. He looks at platforms as really just something that other people can build other products off of, which I think is a very intelligent way to look at it.

Dr. Jeffrey Jaffe, a CEO of W3C, an organization that standardizes the HTML standards and functionality and some of the other standards that make the internet work. I love this little clip from him that says, “It’s a sandbox to innovate and create the next generation of computing applications.” Again, it’s really a generic sort of definition, but, for him, it’s leading towards where technology is headed. It’s not about reinventing the wheel every time. It’s about having that good, solid base that you can innovate on and create new ideas.

Possibly the best definition of it I’ve seen is from Marc Andreessen. He’s a big PC person out in California. I think this is the definition that fits the most of what we’re talking of with Drupal as a platform. He says, “…it’s adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated.” I think this is where you really see the power of building off of a platform is not only looking at how you know the use cases will work, but giving people the opportunity to create something special out of what you’ve done and benefit the entire platform. Kind of feed back in and grow on top of itself.

What are some of the main goals of these platforms we’re talking about? The number one absolute goal is just to make people more efficient. Developers have to spend less time re-doing codes. They have to spend less time bug-fixing because they fixed the same bug in the same place before. It also makes the content-creators a lot more efficient because they seeing the same interfaces, the same types of sites and they’re not having to re-learn every single time how to work on each site. It makes everyone quite a bit more efficient. It inspires collaboration over isolation.

In this case, if you look at the, the analogy we’ll be working through is a higher-ed, university- type examples, and having a platform where everyone’s sharing these common features. You can have all those users talking amongst themselves and figuring out cool ways to leverage those features that you’ve created for them rather than splitting them all off on different pieces of software and having them all struggle to fill the same sort of void that they all have just for them to begin with.

Increasing innovation? Same sort of idea. If people are working together and sharing ideas, that’s where the platform shines and grows beyond just a maintenance fast track.

Decreasing risk and making business more successful? Obviously if you have a platform that is tried and true and you can ramp up new sites and organizations on them very quickly, then it reduces risk for everyone because you’ve already solved the problems and you’ve already tested to make sure that everything works well together. Overall, it helps the developer, the content users, the business people behind the projects. It’s really a win-win for everyone if it’s phrased in the right way.

Let’s look at types of platforms. Some of these don’t have platform in the name, but in reality they fit these generic definitions. Infrastructure as a Service. This is something like Amazon Web Services, where they’ve set up all the service for you, all the hardware in kind of an abstracted way so you don’t have to worry about it, but more or less you’re really left with a bare system to work off of.

Platform as a Service is something like Acquia’s Cloud Solutions, where the infrastructure’s not only taken care of, but so are optimizations and the set-up required to get a piece of software on top of it and run efficiently.

And last, Software as a Service is kind of an even farther evolution of that, where now you’re not even concerned with installing the software and maintaining updates to it. You’re really looking at something that is just there so you can just jump in, get things built, and really get out of the way without having to spend a lot of time just on that initial set-up. It’s really about the rapid prototype, rapid site creation. This is similar to the Drupal Gardens Product from vernacular that we’ll talk about a little bit later.

This is what a typical, higher-ed sort of landscape looks like with a lot of different colleges. All these features, some have internal developers, some have external developers. Some are e-commerce, some have student data. Some don’t have student data and don’t need to be secured. One’s in PHP, one’s in dotNet. It’s really all over the place because, realistically, this is how large organizations naturally kind of grow.

As each group comes up with their own needs, their own use cases, their first natural instinct is to go out there and do it. Part of a platform is really sort of a policy issue of trying to get people back in together to make it an organization-wide initiative and not splitting off all these other teams and losing that efficiency that a large organization really needs to run well.

Just looking at some simple examples of a platform, a performance infrastructure is something like Acquia’s Cloud. Something that’s tuned for performance, but it’s built on top of what you would normally think of as a hosting provider.

Container hosting. A very similar idea. It’s usually a little generic just outside the world of just Drupal, but it’s something that’s really built on top of it. Anything below a certain line, you’re not really concerned about. Everything above that is where your specialists lie, where your knowledge is.

Some other great examples are regional publications for a publishing company. All those publications are going to share very similar features, very similar functionality, same type of background for users, but there’s no need for each one to reinvent the wheel and come up with a new solution every time. Using a platform is a great way that they can all leverage that same functionality without trying to do too much work every time a new region is put up or every time a new re-design is needed.

Now let’s talk about how you get the buy-in from customers. I think this is the hardest part of getting people to normalize onto a platform is understanding that it is addition by subtraction. They’re gaining a lot of different advantages even though they are losing some control. That’s the hardest thing to convince. Here’s what I would pitch as to sort of bring in as a platform into an organization.

Let’s start on the negative side. Let’s talk about the problems that, when I’m out on-site with clients, these are usually the types of concerns that come up and are a primary issue for people. The biggest one that I’ve seen is that it’s a common problem that is affecting everyone in the organization. Whether it’s an internal tool or an external tool, it’s something that people think are different use cases where, if you break it down into technical requirements and business requirements, it’s actually not that different. People see the scope or the visibility of the application and assume that these things are somehow unmanageable together. In reality, that’s usually not the case.

There’s also a cultural shift. One of the biggest things is, in most organizations, people are very accustomed to looking at things on a project basis. Meaning, if a new site’s launched, that gets its own allocated resources, its own people, its own servers, its own environment to work off of. Moving to a platform is more of a product or a service where there’s an internal core team that’s keeping that afloat, keeping things running well, and it’s the job of each one of these new projects that spins up to just come in and work with that team. Rather than filing off all this development, it’s kind of a fundamental shift on how resources are allocated and how projects are run at most organizations.

Some of the other things that people are usually scared off by sharing all this use cases and all this information is they think they are sharing content between all these sites because they see it as one large service. A lot of this is positioning of your specific platform, but the biggest things is people are worried that one team in an organization and another team in an organization are going to collide, start unnecessarily exchanging content, or creating some sort of security issues that move between them. That’s something that’s built out of a poorly-built platform. That’s not an inherent problem of platforms. It’s typically something people run into in their first foray into building these common tools and they’re typically scared off because of that original experience. Unfortunately, there are some technical issues that need to be worked out to put everyone’s minds at ease. But, it’s key to understand that that’s not a platform issue. That was simply an implementation issue that happened sometime in the past, most likely.

Lastly, it’s that autonomy issue that I mentioned earlier. Under the normal landscape without a platform, people are used to being able to add a feature whenever they wanted. They make whatever change they need just whenever the business need arises. But, moving to a platform, you’re often faced with working with unfair development release cycles and their particular work flow of how they build-out the platform itself.

This is a hard balancing act to follow, helping people understand that it may take you another week or two to get that feature that you want in, but because so many more people are using it, it can fit a lot more different use cases, it overall saves the organization money, and even more so, you can allow it to be, it’s tested on so many different platforms, so many different sites, that it’s a more stable product in the end.

Here are some of the direct tradeoffs you run into. You have lower maintenance costs because there are less separate developers working on the project, and there’re less bugs to fix over and over. That’s compared to less flexibility. That’s always the give and take there.

You’re getting shared features updates, but it’s usually on a fixed timeframe. Like I said, if you have a week or two that are really mission-critical, sometimes that just has to fall into the release cycle of the platform itself to make the whole system work efficiently.

Having less internal resources is so important now. With so many people who are somewhat understaffed technically, if you have fewer resources, you can consolidate those and build a bigger single product, then you essentially have the same number of users, but less developers behind it, which makes everything work. There are less contact people, there’s more collaboration and overall, having those fewer resources that are more specialized helps make everything run better.

Of course, what everyone always asks at the end of one of these sorts of presentations out in front of clients is, “What’s in it for me?” With all these drawbacks and all these tradeoffs, what is it really going to take for me to understand why this is the right way to go?

The biggest thing is sharing resources with the web. The way the web traffic works in this case is that most sites don’t experience the same sort of traffic over and over. If you have a shared, especially hosting platform in this case, you can take those ebbs and flows and average them out across all the sites and experience a lot of cost savings without having unnecessary servers and unnecessary resources being tied up by sites that just aren’t used parts of the year or parts of the month.

It helps to normalize that and this is one of the fundamental balancing acts that have made the Cloud so popular as a generic hosting platform. There’s less total lines of code, so to speak, to maintain. So, with that development effort, there’s one platform maybe one or two platforms, its one code base that has to be looked after. It’s easier to on-board new people. It’s easier to run testing’s for that. It’s easier to make the overall development process much lighter and less risk prone.

Also, the documentation. I think one of the biggest problems web projects have, is because the turnover for web projects is so quick, there’s a new product, or a new re-design, or a new team that spins up. Web projects don’t specifically last very long. If you need the time to document a product, it usually doesn’t happen for these short-term developments. But, if you build out a platform that can evolve over time and create new features and has the fundamental work around it to make everyone’s use case better, or work correctly, documentation can be written once for this platform, written well, and then the whole system becomes easier to manage, even by brand new people or contractors coming and trying to help out.

So, what does this have to do with Drupal? First of all, installation profile’s a great tool to use with Drupal. What these basically are, pre-defined configurations that include all the building blocks of the Drupal site stuck together so that people can ramp up quickly for their new site. You can look at this example from Drupal Gardens where if, whether it’s self-service or not, allowing people to quickly spin up an internet site versus a marketing microsite.

There may be most of the same code underneath, but an installation profile gives them sort of a quick start in one direction or another, so then they have the sample concept they need, they have the layouts they need, and it just becomes an exercise in filling in the concept. Installation profiles allow this sort of single-platform idea to be more flexible and make a lot more use cases work and bring in more of those naysayers in to the platform by showing them you can address their exact needs.

It also, one of the benefits, especially in Drupal 7 and moving forward, is because these installation profiles work like a normal Drupal model, I’m not sure this is the right place to go too far on the technical side, but, because it works like a normal module, it can actually do updates over time. This is not something where it’s asked for a blog site to get the installation from today, and then you have no control over it keeping up-to-date later. It’s actually a living piece of code that’s always on their site. If you add a new feature to the blog profile, for instance, everyone gets that. Everyone can benefit on and on and you don’t really have to go back and constantly be bringing sites up to date. It’s a very nice, smooth, automatic process.

Let’s go back a little bit to our example of a higher-ed body. In this case, before we looked at all these different colleges and they all have their different features, if you start looking at it in terms of Drupal and features and what features are required and understanding that not every use case really is completely different, you can start categorizing these into these different profiles. Maybe a few of these colleges are internal sites, so internet sites. Document management, Wickes, maybe, more messaging capabilities, those are the types of things that internet, internal site would have, rather than a multi-media site, for instance, that would be going externally and need to handle lots of videos and asset-management tools. You can fit all these different use cases and you can even combine them. If it’s an internal site that needs multi-media, you have both of those sets of codes. All it is is the matter of putting the two of those together.

The App Standard, the Open App Standard is something that’s happened relatively recently, I guess sometime very early this year. The idea is to take a feature which is essentially a Drupal module of configuration, you could think of it like a subset of an installation profile, and the app standard allows these to essentially be distributed.

If you think of the app store in an IOS or Android sense in other markets, the idea is everyone has a common platform on their device. They can go to one central place and start pulling down new features as they need them. The app standard allows people to have some autonomy as they need it, but because they are all connecting back to the same place, you have a really smooth, consistent way to make sure that all those features that all those different people are using can be taken advantage of.

What makes apps different for platforms? I have to be honest. When the app standard first came out, I didn’t get what the benefit was beyond other Drupal’s that already exist. But, if you actually think of it in terms of platforms, it’s a tremendously powerful idea. If you think of how Drupal modules work or how apps in a single platform work, you can make mixtures of it to make things more generic or less generic, based on how tightly controlled that platform is or how distributive it is.

It’s essentially as if you’re going out to an online store, finding a feature you want, and just simply pulling it down to your site. All this is done through the Drupal interface, so it can even be handed off to non-developers to really kind of build their own site, even though you have control over the code itself. It’s also what I’m calling a Voluntary Distribution Model. I like terms like that. (laughs)

What that’s really saying, these new features, if I come out with a new feature tomorrow, you’re in no way bound to going to get that feature. Right? It’s kind of an opt-in model where someone could actually look at it and say, “That’s a great new feature. I want that on my site.” But, the site next to it, the very next site that’s built, maybe they don’t care so much about that. It gives that kind of flexibility that the platform more of an eco-system of all these different sites working together, more so than you’re thinking about it in terms of one site.

This is a slight departure from what you think of as a shared platform, but because you’re sharing all these features and you’re sharing the communication and that innovative approach, you’re really getting all the same perks. It’s just two really different use cases, two different business cases that need to be met.

Let’s go back to our higher-ed model again. If we look at the University of Drupal, we can look at how user’s log in. A single sign-on the cross means our university. An app is something great that someone could just connect out into, pull down the single sign-on app, and now they have all the LDAP or CAS or site-minder, whatever single sign-on solution you are using, they now have all of that configuration locally and you know it’s the same for everyone.

It’s a great new tool to make those new features available regardless of necessarily where people started with the project. So, why create a new search? If you have an Enterprise-wide search solution, it’s not something you really want to write up in a documentation page and send out and hope people do, by creating features or a common platform or apps to do this, it becomes a point-and-click type of interface of making sure they’ve turned on Enterprise Search and that’s essentially the only set-up they need. It’s tremendously powerful to allow someone other than developers to have that sort of ability to create new sites and move things forward.

I want to come back to how Acquia fits into all these models. We talked about platforms and a couple of different contexts initially. But, as we talk about Drupal, it’s platforms that allow Drupal to succeed. What Acquia does, we provide two separate levels of products, essentially, which hit different needs of different people’s platforms.

We’ll start with Acquia Cloud. It is a fully-managed platform from the end structure down. What this means is if you need custom modules or custom functionality that’s specific to your organization, we give you the power and ability to do that without having to worry about how to tune things for performance or where to go for help. Acquia Cloud provides all of that from the level down, and whatever features you guys need you can throw on top and the two will work together to build out that platform however you need it to.

Managed Cloud is one component of Acquia Cloud. Managed Cloud is about pulling in these large sites you have or large number of sites and maintaining them all through one hosting platform. It’s taking that Drupal side of the platform and centralizing it even more. Rather than just sharing code, now you’re sharing the same resource model, the same support, and, again, everyone can benefit from these singular bug fixes or isolate features that get created an all in one safe, stable hosting platform that Drupal simply sits on top of.

Enterprise Drupal Gardens is more the software of the service solution. In this model, it’s all about allowing people have a fully UI-driven experience to building a Drupal site. There’s no code to maintain, there’s no specific servers to manage or any high-level sites to manage.

It’s an area where you can log in, enable whatever features you need, and then create content and move on. It’s the fastest way to ramp up to a content-driven platform. Rather than giving the flexibility to implement your own code, what Enterprise Gardens does, is it allows you to rely on us as Acquia to develop and create new features that are fully supported.

Rather than relying just on the community modules and how those are all configured together, Enterprise Drupal Gardens supports everything from the content all the way down to the servers. This model fits really well, especially if you think of micro sites or sites that are really design-focused rather than functionality-focused. It gives the ability to duplicate sites and create lots of sites very quickly and puts that into the power of marketing teams or communication teams without even involving the development or back office teams. Like I said, it’s the easiest way to ramp up to Drupal sites that are more content-design focused.

A couple of other key points here, and personally, myself as being an Open Source guy for a long time now, is having something like vendor lock-in. In something like Drupal Gardens, if certain sites outgrow this set functionality, it isn’t a case of having to rebuild that internally. You can actually pull that off of Drupal Gardens, move that straight on to Managed Cloud, add that additional functionality you need, and you still have one resource that’s still providing all of that functionality.

So, you’re not locked-in to Drupal Gardens. In reality, it’s just Drupal, so you’re gaining all the benefits that you already knew about when you chose Drupal initially and Drupal Gardens is really just a layer on top of that. It isn’t, it’s no sort of black box functionality that allows you to grow as your site grows rather than having to pick the full solution of tools that you need when you don’t know what that growth pattern’s going to look like. We allow you to grow and evolve as your site needs to in different capacities based on what your current needs are and where you’re trying to take your organization.

I want to leave a lot of time open for question because, usually for platforms there’s a lot deeper questions we want to move into. If anybody has any questions, please feel free to throw them in the Q&A section and we’ll address as many of them as we can.

Hannah: We had two of them come in. The first one is to install Profile Works for or with Commons.

Erik: Commons itself is an installation profile. I don’t know if you’re referring to Drupal 6 or Drupal 7, but I actually did a lot of the initial work with Drupal 7 with Commons and it’s really great. I’m trying to be objective. But, Commons itself is an installation profile, so you can build off of essentially the code Commons relies on. Because these are living, breathing profiles, you can sort of learn from them and use them all together. So, it’s not that installation profiles work with Commons, but Commons itself is one. You can either use Commons as is, or add to that with your own additional pieces of that profile and sort of layer that on top of Commons as your own rendition of it or your own breed of Commons.

Hannah: Does anybody have any more questions? Please ask them in the Q&A tab now. What is the best way to find developers who work with non-profits?

Erik: I think one, this is a larger question, obviously. I’ll give my perspective on it. One really interesting thing about the Drupal community is so much of it’s been built out of non-profits or out of that background. So many Drupal developers are looking for that next big push or that next big challenge more so than the specific kind of job. Just like with any sort of Drupal hiring, the best way to try and find those resources is to work within the community itself. Even as a business person, or recruiter, or, I obviously don’t know your background, working within the community itself. Attending meet-ups. Explaining the types of problems you’re trying to solve. Get people interested in what greater issues you’re trying to find a resolutions to, whether it’s camps, or local meet-ups, or group-a-thons. In my experience, that’s been the best way to get people on board and building out these kinds of big platforms is a really interesting exercise and typically attracts a lot of people. It’s just a matter of getting that word out there and getting it in front of the right people. The community is a great place to bring up those interesting scenarios and get some buy-in from external folks.

Hannah: We had another question come in. I’m looking at Commons 3 when it releases and Commerce Quick Start, too. How can you combine two different profiles?

Erik: Combining two different profiles is kind of a difficult combination to do. When I say that I mean in a normal, simplified way. Because the profiles are actually working together, you can basically create another layer on top of it, similar to the previous questions with Commons and pull the two in together. The only problem you’ll run into, to be honest I don’t know how large a problem this would be, you may have conflicts between how the two profiles are built because most installation profiles like Commons or Commerce are built to be single purpose, stand-alone sites. In this case, I would say it’s less of a sort of a process issue and more of what types of assumptions are those two profiles using that may conflict with one another? With e-Commerce and the event-based model that Commons 3 is moving towards, to be honest I think this is a place where you may actually have a platform below either of those that’s creating whatever shared functionality you need, and a lot of the time e-Commerce requirements and community site requirements are often different enough that the maintenance of these types of sites is easier separately built on top of a common platform beneath it all. I hope that’s not too much of a non-answer, but I would say the biggest thing is to make sure that you’re putting the two together to complement one another. Figure out what those maybe incompatible assumptions are. Then you can move forward with technical decisions on what you actually need from both.

Hannah: We had a technical question come in. What is your preferred method of including default content in an installation profile? Is it a Deploy module, default content module, custom code, and quick install?

Erik: I’ll actually say there are two different scenarios here. One is, or I should say the two scenarios are based on who’s maintaining that default content? If it’s just basic stub content where there’s really no meaning to it, then I think putting it in the profile itself is really the simplest, most straightforward way to do it. However, if that default content is more of boilerplate content or something that content, content managers are building rather than developers, I would actually say something like feeds would be a better option. The reason, it’s similar, I guess while you’re asking about Deploy, the main fundamental difference with Deploy, it needs to know all the different sites to send it to. So, as you roll out new sites, you have to go back to that base content depositer and keep adding new sites. Whereas, something like feeds, you would just have an open XML feed or some sort of feed to pull from and every time you install a new site it could just reach back to that URL and bring it into the site. I would say it depends on who’s maintaining the content is really the big difference here, in my opinion, of which technical solution makes sense.

Hannah: The next question is, in your experience, what is best theorem for membership management?

Erik: Unfortunately, I have to say I don’t have a lot of hands-on experience with a lot of CRN systems as part of this. I wish I could give an answer there, but, unfortunately, I’d be speaking on second-hand knowledge.
Hannah: There has, two more questions came in. If you want to have a community with fee-based activities events, is that practical for Commons?

Erik: Yes, absolutely. The main, I guess the Commerce Quick Start versus Commons issue that I was referring to was Commerce Quick Start is so much more than just adding individual feeds to sites. It’s so much more than that. If I were going that, the way I would look at it is Spin Up, Commerce Quick Start, and learn what of that you’ll need. And then there’s some integration you’ll need with events. There are various events modules out there that allow you to do basic payments. One thing that you and I, maybe what would be interesting to you is you look at the COD distribution, so this is their Conference Organizing Distribution, this is what all the Drupal Con Sites and most of the Drupal Camp Sites work off of, those actually have really specific use cases for buying access to individual trainings. In those cases it’s actually simpler than Commerce, where the Commerce Quick Start and the whole Commerce Suite really go for full-service e-Commerce sites. Now I pay for registration-type sites, so I would say, to sum it up, I would say Commons is probably your right starting point if there are lots of community events. And then I would learn from, I think even COD may be a better place to start. Learn what they use to accept payments and add-up pricing, because, as far as I understand in use cases, Commerce Quick Start may be a bit too much that particular case.

Hannah: I think that’s it for questions. If anybody has any additional questions, please ask them now. All right, I think that’s it. Erik, do you want to end with anything?

Erik: No. I want to thank everyone for attending and want to reiterate kind of the higher-ed background I have in working with these sorts of platforms. I really want to emphasize the innovation part of it. It’s not just about business processes, but if you get 10 people in a room with the same tool, they’ll all use it differently and everyone will learn from that. So, I just want to put that out there that platforms can actually foster innovation more than just thinking about it as a process or efficiency tool.

Hannah: Thank you so much, Eric. And thank you, everyone, for attending. Again, the Webex has been recording the webinar and we’ll post it to Acquia.com in the next 48 hours. Thanks.

Maxim and SEMI Gain Significant ROI from Migrating to Drupal and the Cloud [April 10, 2012]

Today’s Digital Agency: the Business Case for Converting to Drupal [April 4, 2012]

Drupal without borders: Achieving your internationalization goals with Lingotek [April 3, 2012]

Using Drupal to Drive Website Conversions [March 27, 2012]

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

Click to see video transcript

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.

Enterprise Drupal Gardens - OpenSaaS Site Factory [March 29, 2012]

Benefits of Adopting Drupal for Higher Education [March 22, 2012]

Perfecting Permissions and Editorial Workflow [March 14, 2012]

Achieving Continuous Integration with Drupal [March 7, 2012]

Pages