I didn’t attend any responsive web design sessions at DrupalCon Denver 2012 because there was just too much going on under the hood, both for Drupal 7 and Drupal 8. But before this milestone event fades into the past, it is necessary to grab what this historic “reaffirmation” DrupalCon tells us about the state of Drupal is in this key area and how the rest of us should incorporate it into our development process. What frameworks, base themes, standard configurations, and other approaches should we adopt?
This corrects the grave omission of the whole key subject of responsive web design from my recent report back article on DrupalCon Denver 2012.
Here I attempt to address the question by treating myself to an Easter Sunday responsive web design marathon, and grabbing my first conclusions, synthesized with my thinking up to the present (“Mobile first” is the tip of the iceberg and when blithely repeated reduces to a buzzword without addressing the huge multi-server and services, real time and single page app challenges that are increasingly facing the web app builder. While mobiile first (there, I’ve said it) responsive web design is key, promiscuous Drupal with multi-node servlets and services integration is fundamental). But this material is absolutely essential, there’s a lot to learn, don’t go to work without it: I present here my take on each of the following presentations: Rethinking responsive building techniques with drupal – johnalbin, Responsive web design: the past, present, and future – lewisnyman, A responsive project process – daveruse, Creating responsive and mobile-first drupal themes – himerus, Html 4 s – while we’re waiting for the revolution – mortendk, and finally Keynote – Luke Wroblewski. BTW, Panopoly is responsive out of the box (what does that even mean?).
-
Rethinking responsive building techniques with drupal – johnalbin
-
Responsive web design: the past, present, and future – lewisnyman
-
Creating responsive and mobile-first drupal themes – himerus
-
Html 4 s – while we’re waiting for the revolution – mortendk
Panopoly is responsive out of the box
What does this even mean?
-
Part I
-
See Earl Miles presentation on panels https://awebfactory.com/node/488#panels
Rethinking responsive building techniques with Sass & Drupal themes & modules – johnalbin
Session: http://denver2012.drupal.org/program/sessions/rethinking-responsive-building-techniques-drupal
Video: http://blip.tv/drupalcondenver/rethinking-responsive-building-techniques-with-drupal-6036654
Slides: http://denver2012.drupal.org/sites/default/files/rethinking-responsive.pdf
Important reference as point of departure: Ethan Marcotte’s book and A List Apart article
John Albin Wilkins is author of the Zen theme, and people ask: Why isn’t Zen responsive yet? Because John’s been thinking on the best possible responsive solutions and Zen version 5 should be out in a month or so.
Luke Wroblewski just wrote an article “Multi-Device Layout Patterns”, which might imply that for Drupal the obvious method would be a region-based layout (like Stark for Drupal 8): He said: “The most popular pattern was perhaps surprisingly simple: a multi-column layout that introduces larger margins on big screens, relies on fluid grids and images to scale from large screens down to small screen sizes, and stacks columns vertically in its narrowest incarnations”
There are two problems with this: it’s boring, it looks like a lot of other designs. Secondly, it’s dangerous in Drupal because the content is the most important, and the way to build responsive themes is not just filling up the page with extra blocks just to make it mobile. Rather, you should be thinking Mobile First.
Mobile first → content first → users first (see Luke Wroblewski’s talk)
For Drupal sites, if you are thinking about traditional region-based layouts, content first means that your content region should go first. With Drupal 7 there is a huge opportunity to really focus on content first because it has fields as the atomic unit of very structured content. So in the design of the layout you don’t have to move the whole node around, you can move fields around as part of the layout.
Field-based responsive layouts means “responsive content”. This in opposition to most CMS based sites, where a mass of content stuck into a WYSIWYG editor is the rule, so it cannot be made responsive. But with Drupal if you have structured your site correctly, it can.
A great example of responsive content is Palantir.net’s website (the company John Albin works for). Fields are placed in sidebars, layout adapts to different device screens.
How do we get there? Starting with fields, Drupal 7 assumes the worst (multi-value plain text field with a label) and generates semantic HTML accordingly (field.tpl.php). divitis. Impossible to fix for new Zen responsive theme. It is necessary for the site creator to specify the semantics for each of the fields. That’s why the HTML5 based fences module was built, (minute 12:00). It comes with a huge number of template files and choices supporting common HTML5 patterns and practically all markup, and it assumes the norm: there’s already markup in your field content so you don’t need wrappers. The basic pattern is to place the label in an h3 header and all the rest in an element tag or no wrapper at all for the content. Fences specifies the semantics for the field and appears in all view modes, in views and anywhere field.tpl.php is used (i.e. new modules in the future). Lean down your semantic markup! (Fences works thanks to theme hook suggestions).
Fences works great with the Field Collection module (minute 18:00). How to construct an HTML figure tag.
Layout markup: minute 20:30. Custom CTools Layouts. CTools (as distinct from Panels itself, used in this way for example by Display Suite). Steps to include in your theme (minute 21.49). You can use this to configure reusable custom layouts for certain nodes, etc.
For Responsive Images, Matt Wilcox’s Adaptive Images solution is the most promising.
-
Adaptive Image module http://drupal.org/project/ adaptive_image Based on Matt Wilcox’s Adaptive Images.
-
Borealis http://drupal.org/project/ borealis
-
Evaluate the solutions based on the problem space. Jason Grisby explains it best. http://cloudfour.com/responsive-imgs/
Natural vs Unnatural Breakpoints: minute 29:00. Don’t think about existing device dimensions, but rather what your content wants to say…, for example with device sizes in the middle, not on the boundaries. See http://www.palantir.net/blog/re-thinking-breakpoints-responsive-design
Gutters and box-sizing: border-box: minute 32:00. http://paulirish.com/2012/box-sizing-border-box-ftw/ Percentage based borders suck because they fluctuate based on viewport width. With box-sizing you can specify padding in pixels and continue to use percentages for layout in responsive theming.
Statistics: a lot of mobile devices don’t show up on Google Analytics, so don’t rely on that to plan your responsive needs.
How to test on mobile devices: minute 35:00 Emulators and Simulators
Responsive layout building techniques: minute 37:45. How are known tools used to do this as named building techniques. Just adding extra classes isn’t going to work anymore, because you have a single source with four different layouts; so CSS has failed us. Sass, the CSS processor, to the rescue (minute 39:00). Using mixins you can apply the same selector to different media queries. Zen Grids is a responsive grid system built as a Compass extension to Sass and will be released before the end of April, 2012. From the Compass site: “Compass uses Sass: Sass is an extension of CSS3 which adds nested rules, variables, mixins, selector inheritance, and more. Sass generates well formatted CSS and makes your stylesheets easier to organize and maintain.”
Building techniques: minute 42:18
-
Content first
-
Mobile first: content goes first and supporting content goes after that.
-
All the other building techniques rely on this semantic ordering
-
-
The Adjacent Sibling Rule
-
Rows are composed of elements that are next to each other in the HTML source ordering, and floated according to a grid system.
-
But they can be re-arranged within the row, say using the blueprint push and pull features.
-
To start a new row, add a clear to the first sibling.
-
float: left; clear: left;
-
-
-
-
The Opposing Float
-
If rows are organized as per the preceding rule, say, using float left, then in order to get another element to span multiple rows you would use float right, the opposing float. So in minute 45:20, clear element 5 and float element 3 right.
-
Alternate left and right and span multiple rows. This technique can be nested.
-
-
The Lasso
-
Putting a wrapper around a couple of adjacent elements deal with them as a single element
-
The Corset Variant of the Lasso
-
Two lasso’s to constrain, leaving “wardrobe malfunction” to the un-lasso’d un-constrained elements.
-
-
-
The Absolute Exception
-
Very controlled use of absolute positioning
-
If you leave space below and can be sure no other content will overlap, you can apply position:absolute
-
-
The Violator
-
Violate the grid judiciously so an element pops out to create visual interest.
-
Responsive web design: the past, present, and future – lewisnyman
Session: http://denver2012.drupal.org/program/sessions/responsive-web-design-past-present-and-future
Video: http://blip.tv/drupalcondenver/responsive-web-design-the-past-present-and-future-6036605
Slides: n/a
Lewis Nyman (CapGemini).
PAST
The web was stuck inside a lie we had created for ourselves called 960px. Designing sites for the lowest common denomination of screen size. Screens were getting bigger and more varied and we didn’t take advantage of them because it was hard.
Mobile web browsing came of age. Screen sizes suddenly got a lot smaller and forced us to stop looking at the web through the 960px view port and start thinking about how users were experiencing our site on different devices. [VK: so not just “mobile first”! Rather, “device first” including huge retina screens for example for a better UX].
In the past, classical sources were color theory, typography and grid design. From the printing industry also come such terms as page and fold. Like grid systems they had baggage from past use. By 2007 the top ten resolutions were 1024 x 768 (53%), at some point this was taken as canvas width. If spacing was larger, margin, if smaller, scroll! But it stopped becoming the standard resolution. The grid system became the norm as resolutions became split and there was no successor to the prior standard. So 960px became the lowest common denominator.
Until iPhone: “breakthrough internet communication device”. Old way of thinking of web as static page could not hold up any more.
PRESENT
Ethan Marcotte introduced a philosophy called ‘Responsive Web Design’.
Important reference as point of departure (again!): Ethan Marcotte’s book and A List Apart article
It embraces the fact that devices are different and adapts to different contexts. Let’s explore the roots of the philosophy and how it gave meaning to techniques people were already using.
Since the introduction of the term the web community has embraced it and expanded upon the original concepts. Mobile first responsive design is progressive enhancement taken a step further. Conditional loading introduces the concept of economical enhancement. Don’t load what won’t be used.
“Design for flexibility” (Ethan Marcotte). “A greater number of devices than ever before”. Inspiration from responsive architecture which adapts as people walk through them.
-
Fluid grids
-
Flexible Images
-
CSS media queries (based on screen width breakpoints)
Example of a responsive site in action: The Boston Globe.
But if we go back to Responsive Architecture, many ideas and definitions emerge (see video minute 16:36). Rogers Centre. The concept of frameworks for flexible architecture. No reference to technology, only that it must be flexible. there is a separation between Philosophy and Implementation. So fluid grids, flexible images and media quieries are only an implementation of responsive web design. An incredible example from The Man in Blue written in 2004 and updated in 2006 (done in javascript at that time), cited in this article. Another point is that responsive architecture is built to last, and to be capable of responding to future as well as present needs. Mobile first (a concept introduced by Luke Wroblewski several years ago) as a baseline to build upon. Explained at minute 21:00. [VK: see his talk covered below].
Can great design be environmentally friendly? Yes. Don’t waste bandwidth. Speed is an essential part of user experience. Applied to responsive web design, one example is responsive images (200kb image for desktop, 30kb image for smartphone). Conditional loading and content instead of loading all and hiding for small screens if document width is greater than, say 640px. Conditional resource loaders only loads resources appropriate for the device.
FUTURE
There’s a lot more to a mobile device than a small screen. If a larger screen size is considered a device capability then what other capabilities do devices have we can take advantage of to create a better experience.
How to think in a responsive manner.
What is mobile? What are the variables? Small screens? Mobile phones (a moving target through the decades)? Handheld devices? The device or the person? The user is untethered (not at their desk, or walking around in the street carrying a laptop). No keyboard, no mouse. Not plugged in. One characteristic of mobile is a touch-based interface. Buttons appropriately sized. Not all small screened devices have touch screens (think old blackberry). And why are we assuming that large screens are not touch screens?
If we apply mobile first and conditional loading, and apply these concepts to devices with a touch-based interface we can apply things like this on a big or small device, only when it is needed:
if (Modernizr.touch){
// bind to touchstart, touchmove, etc and watch `event.streamId`
} else {
// bind to normal click, mousemove, etc
}
Mobile implies the use of thumbs as a means of primary input (i.e. large buttons on the bottom of smartphone screens are convenient for thumbs). Keyboard splitting in landscape.
@media orientation:landscape
Network is another variable of mobile. Small screen devices may be on faster networks. Throw out assumptions of current and past devices. Network Information API. Assume slowest connection and conditionally load resources.
(Lack of) Color. Amazon B/W Kindle. Cheaper and cheaper. How long before they are free? B/W is feature. Enhances reading experience. What happens when someone goes to our site on a Kindle?
@media monochrome; @media color
Apply principle of conditional loading (only load what you use). And to responsive images (color vs greyscale).
Battery Only one battery for so many uses. Be economical in battery use. How to respond in our designs? Assume low power first. Battery API (charging, percentage left) in Firefox and on its way into Chrome now.
Ambient light For example bright sunlight (need for high contrast). [VK: Google maps changes contrast of maps at sundown]. Sensor API. Motion. Temperature.
We should demand these changes from device manufacturers. A short history of @media queries (minute 40:50).
A responsive project process – daveruse
Session: http://denver2012.drupal.org/program/sessions/responsive-project-process
Video: http://blip.tv/drupalcondenver/a-responsive-project-process-6041316
Slides: http://denver2012.drupal.org/sites/default/files/aResponsiveProcess.pdf
Important reference as point of departure (again!): Ethan Marcotte’s book and A List Apart article
“With responsive web design…. we’ll go beyond the ems, percentages and media queries by sharing how responsive design has affected how we approach and practice analysis, content, wireframes, design, testing and site delivery from a more holistic point of view.”
Some quotes, the first three on how big mobile is, how quickly it’s growing, why responsive web design is so important and prepares us for this growth market:
“Nearly 7 percent of all online purchases were made using iPads, just 18 months after the tablet computers were released by Apple Inc. http://www.businessinsider.com/online-shopping-jumps-164-pct-on-christmas-day-2011-12
“22-25% of US and UK mobile Internet browsers never or infrequently use the desktop Internet. http://www.lukew.com/ff/entry.asp?1405
“1.45M devices shipped per day – 317,124 births http://www.lukew.com/ff/entry.asp?1506
Need to serve the needs of users in front of the screens behind these devices: “The role of the designer, is that of a very good, thoughtful host, all of whose energy goes into trying to anticipate the needs of his guests. – Charles Eames
Traditional process: a linear life-cycle of requirements gathering and baseline sign-off, wireframing, design, comps in Photoshop, sign-off on design comps, site development, then launch.
Responsive design is not an option you can tack on at any point in the project since it affects this entire process. It must start with the initial meeting with the client. Because of the success of the Boston Globe, other publishing projects have taken note and request responsive design themselves in spite of varying degrees of knowledge of the topic and the effort required.
Responsive will affect timelines and deliverables and it is important to communicate to the client what the effect will be. Internally it is important the whole company understand this also for planning purposes. This will involve a learning process.
There can be no waterfall approach where the product moves from one department to the other, receiving client approval as it goes. Instead, there will be a lot of cross-pollination between disciplines involving a rinse and repeat iterative design and critique process until there is something acceptable across the breakpoints.
In the process itself content is king, and that’s what really drives our designs. Content helps frame design decisions. It’s all about getting the message across to the users behind the screen. You cannot demand all the content up front, locked in. Mark Boulton article on this. Work with UX person, establish hierarchy, sketch how page is going to work across breakpoints, even on low-fidelity level. How content will affect grid. Forming your breakpoint based on how the content breaks at a certain resolution.
Copy. Flow is key. Starting with the smaller screen sizes and then building up needs to be done early, and this is good for the client and the team, prepares all for growth. Keep flow in mind, don’t assume page structure or input method (NOT: “click to the right to…”) since different devices vary. Don’t assume positions like “above”, “below”. Use caution when hiding content to achieve flow in moving from desktop to smartphone, for example. Because people are using phones while watching TV or standing in line, they have time to accomplish tasks allowed in desktop site, and hiding those options will frustrate users and confuse search engine indexing. Hiding doesn’t improve page load times either. Don’t punish users because they are using “the wrong device”.
Example: ESPN: removal of bracket view for scanning and reading tournaments.
If you do need to hide very long or complex tasks (long form, application requiring a lot of copying and pasting) take caution. Make sure it is to serve your users and not for appearance sake.
Images: No ideal solution, lack of standards, accessibility techniques. Boston Globe wrote their own system. Imaging pre-fetching interferes now with that. Things are prone to break as technical solutions grow.
One good solution: Responsive-Enhance. Instagram approach (illusion of speed). It serves up multiple resolutions with smallest ones first, and won’t show the next until first one has finished loading; others in higher quality are then served.
Video: mobile friendly formats. fitvids.js lightweight jQuery plugin for fluid width video embeds (vimeo, etc.).
Ads: Usually come in at a fixed width and so breaks page flow at certain breakpoints. Arrive at consensus with clients. No perfect solution, there is going to have to be a compromise. Should ads even appear on mobile? Hide them on certain breakpoints. Solutions are a work in progress.
Wireframes: Do we wireframe each breakpoint? Start small with mobile first then you have a good set of page structures to be transitioned to other breakpoints. In fact, wireframes are great, and emerge at a very low fidelity point in the project. We need to keep things loose early on even though the client wants finality. Because change requests will have a much bigger impact if this is not done. Complement wireframes with prototypes. Collaboration between UX and developers to test out breakpoints, see even at this early stage how copy is flowing. Prototypes help clients more than static wireframes.
Design: It’s not financially feasible at this point to make comps for every page. It isn’t beneficial to the project. “The tool doesn’t make the craftsman.” – Oliver Reichenstein. Responsive design is a great reason to evaluate entire toolset. Workflow starts with Style Tiles, a low fidelity intro for the client into the design process. They are quick and dirty snapshots to set the visual tone, to be applied to site pages and the different breakpoints; this way change requests don’t take as long. It benefits the client in that it gives them an early opportunity to get feedback in.
Where should you design? In the browser (flexibility: Chrome, Firefox, Safari) or using a desktop application (fidelity: Photoshop (Ps), Fireworks (Fw), InDesign (Id))? Or both? The faster you jump into the browser, the better the feedback, but both is recommended. Depends on skillset. Or a designer sitting near a front-end developer, working in partnership. Design one or two pages in photoshop and accompanying breakpoints, and then publish a (downloadable) styleguide so the front end developer can have a reference point (tags, icons, fonts, etc). This method was used by the BBC. Page review sessions with the whole team (even clients!) are valuable (feedback on various devices). Meet at set intervals to ensure iterative design.
Development: Developers should be involved as early as possible, so “they know what’s coming” and don’t have to imagine everything from just wireframes etc. as they start analysis and design tasks. Especially important in the case of outsourcing. Backend developers should not just be handed everything built out in PS, HTML, etc. because at that late point everything may not match up with CMS (for example Drupal). Developers prefer to work more from that style guide; they can look at the comps, know the visual style, and build out from there. See article by Josh Cooper, Death of a Cut-Up Man: “Rather than cutting up a site completely, or inheriting a cut-up from a design shop, it would be best to skin the site through the development process. Not only does this cut down on the budget (the hours spent developing the markup, CSS and images), but it allows the front end developer to better understand the output that is being generated.”
Omega base theme is a great starting point in Drupal for responsive web design. Allows changing grid to adapt to the content you are working with.
Testing: This is where we found the largest impact, the biggest increase in time spent in the responsive process. Re-sizing your browser is not the best tool, doesn’t accurately show usability, neither do Browser Stack or Adobe Shadow. Brad Frost: Test on real mobile devices without breaking the bank (for “…true site performance, device capabilities, form factor, pixel density and the impact of the network”). Sometimes carrier plan can be a factor. See also Stephanie Rieger’s Strategies for choosing test devices. Also test for Bandwidth. Download the Speedtest.net app. No relation to screen size.
Handoff: Launch doesn’t mean done. Even if client has total control after delivery, the client needs to be prepared on how not to break things (images of wrong resolution) or wrong. It’s a responsibility. Different content flows across breakpoints. Build in time for training, documentation, style guids for the client. Starbucks released a styleguide for their content providers for their new responsive site: http://www.starbucks.com/static/reference/styleguide/
So much more cross-pollination among different roles and disciplines. Disciplines aren’t silo’d any more. Helps you work as a real team instead of that linear, relay process [waterfall] talked about at the beginning of the session. But a process for responsive web design is just starting, and this session will be out of date within 6 months or a year as a better process emerges. Also lots of changes coming along (retina display for desktops in the works?).
[VK: A great graphic designer pointed me to this useful general article: http://couchable.co/blog/post/a-responsive-design-workflow ]
Creating responsive and mobile-first drupal themes – himerus
Session: http://denver2012.drupal.org/program/sessions/creating-responsive-and-mobile-first-drupal-themes
Video: http://blip.tv/drupalcondenver/creating-responsive-and-mobile-first-drupal-themes-6041180
Slides: http://developmentgeeks.com/sites/default/files/creating-responsive-mobile_first-drupal-themes.pdf
Jake Strawn (maintainer for Omega Drupal 7 Base Theme)
Responsive Web Design is all the rage these days, and everyone wants a slice of the pie, regardless if it’s for your own site refresh, or something you want to pitch to your next client. Responsive design has exploded in the past year, as can be easily evident by the number of large (and small) sites adopting responsive techniques to serve content to ALL devices at once using the same codebase.
This session will assume that you have a current understanding of what responsive and mobile-first are, and that you come to this session ready to learn EXACTLY how to incorporate these technologies now in your Drupal projects.
This session will guide you through the methods to actually implement responsive, mobile-first themes in Drupal, today… On your way out the door when this session ends, you’ll be armed with the latest knowledge, tools, and inspiration to skip a time slot or two after the session, and start hacking away at your own responsive design!!
Session Outline
(see http://developmentgeeks.com/blog/creating-responsive-mobile-first-drupal-themes )
-
Introduction
-
What you need to know
-
Device detection is BAD
-
Responsive web design is GOOD, isn’t easy and isn’t for everyone (yet).
-
-
What you should learn today
-
Understanding Responsive Media Queries
-
Creating a Responsive theme from scratch
-
Omega makes Responsive theming easier
-
-
-
[minute 2:40] Responsive CSS3 Media Queries (in 10 minutes)
-
min-width/min-device-width
-
max-width/max-device-width
-
orientation (portrait/landscape)
-
-
[minute 7:10] Creating Responsive theme from scratch…
It may be good for some projects that don’t need a complete theme and a more lightweight approach is necessary.
-
Build the .info
-
Adding Responsive CSS (method 1)
Method 1 allows us to separate the CSS media queries into logical files that only hold CSS rules to be applied to a specific media query. So you would have global.css, tablet.css (min-width 768px) and desktop.css (min-width 1024px), for example.
-
Customizing Responsive CSS (method 1)
global.css is doing the mobile (first) styles. tablet.css will override styles for tablet media, and desktop.css overrides for larger viewpoints (for example, put content in middle instead of on left, put sidebar on left, etc.).
-
Adding Responsive CSS (method 2)
Method 2 keeps our number of CSS files lower but uses a single CSS file to organize ALL the media queries and data that we will use at any point in our styles. Both files are always loaded at all times.
-
Customizing Responsive CSS (method 2)
global.css will still handle our defaults. responsive.css will handle ALL our media queries directly in a single CSS file. Our media queries will be ordered (top to bottom) in a way that allows them to be properly cascaded.
-
[minute 16:00] Responsive Images
img { max-width: 100%;}Using the max-width property on all images will allow our images to scale (width AND height) to not overflow the container element around it. This can work (with a little bit of love) on Flash objects and embedded videos as well (fitvids.js).
For older versions of IE there is an issue for images which specify height and width (issue: #1129642). -
Viewport Meta Tag
Most mobile browsers have scaling in place for legacy support that lets a site designed for the desktop render beautifully scaled on a handheld device.
The tag allows us to tell mobile browsers (iOS, Android) that we want to be in control of things like scaling and pinch & zoom when using responsive design. There are arguments in favor and against “user-scalable=no”. -
Browser Support
Older versions of IE (6 thru 8) should be presented with a suitable default layout so that they don’t get mobile version of the site (when using a mobile-first approach). -
Touch Icon
See [minute 23:20] and http://drupal.org/project/touch_icons module! -
[minute 24:20] Responsive Breakpoints
-
1200px laptop/desktop
-
1024px smaller desktop/ larger tablets
-
768px portrait on large tablets
-
600px kindle, smaller tablets
-
480px Landscape on “most” smartphones
-
320px Portrait on “most” smartphones
-
240px Really small mobile browsers
This will change of course very quickly.
-
-
-
[minute 27:00] Making Responsive easier with Omega
-
Omega is Responsive
-
Omega is Mobile-First
-
Omega is Growing
-
Over 20,000 Installs
-
Distributions using Omega
-
OpenPublic – http://openpublicapp.com
-
OpenPublish – http://openpublishapp.com
-
Open Enterprise – http://leveltendesign.com/enterprise
-
-
-
Omega has Grids
-
1200px
-
960px
-
720px
-
Fluid
Investigations into the future into alternatives to grids
-
-
Omega has Friends
-
Omega Tools – http://drupal.org/project/omega_tools
-
Delta – http://drupal.org/project/delta
-
-
Omega is always Innovating
-
Omega has Resources
-
Documentation – http://drupal.org/node/819164
-
IRC – #drupal-omega
-
Drupal Group – http://groups.drupal.org/project/omega-framework
-
Premium Themes – http://themegeeks.com (launching soon)
-
-
Omega has an upcoming Webinar
-
March 28th, 2012 9:00 a.m. EST – http://himer.us/xkzf9d
-
March 28th, 2012 1:00 p.m. EST – http://himer.us/wQsMRN
-
-
Omega has Stickers
-
Omega is a Community Effort
-
Jake Strawn – himerus – http://drupal.org/user/159141
-
Sebastian Siemssen – fubhy – http://drupal.org/user/761344
-
Joel Moore – banghouse – http://drupal.org/user/381416
-
Chris Teitzel – cellar door – http://drupal.org/user/658076
-
Marco Kleine-Albers – e-anima – http://drupal.org/user/255202
-
-
-
Responsive Inspiration for your project
-
Responsive sites built using Omega
-
Question about higher resolution devices like the iPad. It’s still a 1024 x 768 site, with pixel density affected. So low-resolution images will pixelate.
Html 4 s – while we’re waiting for the revolution – mortendk
Session: http://denver2012.drupal.org/program/sessions/html-4-s-while-were-waiting-revolution
Video: http://blip.tv/drupalcondenver/html-4-s-while-we-re-waiting-for-the-revolution-6036718
Slides: http://dl.dropbox.com/u/51287/2012-drupalcon-denver-html4s.pdf
[Note: A lot of the code examples come from http://drupal.org/project/mothership ]
[Note: Also frequently referenced: http://drupal.org/project/displaysuite and http://drupal.org/project/ds]
Intro
“4 s” because 5 isn’t here yet.
“Collaborative Publishing for Every Device”
A front-end developer whose favorite color is Badass: #BADA55 and been in Drupal community for about six years, and has been a front-end guy in a back-end world.
The talk is about:
-
getting some html5 fundementals straight
-
making html5 less sexy 🙁
-
changing you markup the right way & right now even as <time> changes
-
& killing some stuff now were add it!
-
the C word (it’s all about the <code>, the markup that make your <body> move)
and directed at developers, frontend heros, designers
HTML 4 S and Drupal
In 2008, we had Drupal 6, which brought the 960 grid system
In 2010, we had responsive, html5, css3
In 2013, we will have Drupal 8, but we don’t know when Drupal 8 will come out, so we can either do nothing, or decide what we are going to do in the meantime.
The place everything is happening is in the file html.tpl.php which you can copy from modules/system unless you are using a theme that has already copied it for you. It has:
?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php print $language->language; ?>" version="XHTML+RDFa 1.0" dir="<?php print $language->dir; ?>"<?php print $rdf_namespaces; ?>> <head profile="<?php print $grddl_profile; ?>"> <?php print $head; ?>
The HTML5 promise:
?><!DOCTYPE html> <html<?php print $html_attributes; ?>> <head>
ie7 will not be supported in Drupal 8 but we still have to support it. mortendk applies a ie7 tax to his clients in the hope they won’t require it (as he used to do with ie6).
Quick and dirty solution is to insert the following into the html.tpl.php file (html5 shiv):
<!–[if lt IE 9]>
<script src=”//
html5shiv.googlecode.com/svn/
trunk/html5.js”></script>
<![endif]–>
http://code.google.com/p/html5shiv/
So what do we get
-
<article>, <section>, <figure>, etc supported
-
html5 css reset (with normalizer or eric meyers css reset)
When you have done this you are in the HTML5 club! HTML4 S is now superpowered.
Getting HTML4 S into Drupal
How do you get the two footers into Drupal? The markup and css would go something like this:
<header role=”banner”>
header[role=”banner”]{
}
<footer role=”contentinfo”>
footer[role=”contentinfo”]{
}
How do you get blocks into Drupal?
In Drupal everything is based around the idea that “this is a system”. But with HTML5 everything has a meaning, it’s not just tag rules, so things are defined by the content and not by the cms. So <section> and <article> look pretty straightforward, but <aside>? We are learning as we go along.
The <nav> element in say block–menu.tpl.php
<nav <?php print $id_block . $classes . $attributes; ?> role=”navigation”> ...
You need to build a new base theme to support all of these things.
The w3c definition of <article>:
“The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user- submitted comment, an interactive widget or gadget, or any other independent item of content.”
This really reads like the definition of a node. So the solution would be something like:
<article role=”article”> <h2>header</h2> <footer> by : @mortendk <footer> <p>....</p> </article>
The article tag from the node.tpl.php template for the base mothership theme:
<!--node-->
<article <?php print $id_node . $classes . $attributes; ?> role="article">
<?php print $mothership_poorthemers_helper; ?>
<?php print render($title_prefix); ?>
<?php if (!$page): ?>
<h2<?php print $title_attributes; ?>><a href="<?php print $node_url; ?>" rel="bookmark"><?php print $title; ?></a></h2>
<?php endif; ?>
<?php print render($title_suffix); ?>
<?php if ($display_submitted): ?>
<footer>
<?php print $user_picture; ?>
<span class="author"><?php print t('Written by'); ?> <?php print $name; ?></span>
<span class="date"><?php print t('On the'); ?> <time><?php print $date; ?></time></span>
<span class="changed"><?php print t('Last'); ?> <time><?php print $changed; ?></time></span>
<?php if(module_exists('comment')): ?>
<span class="comments"><?php print $comment_count; ?> Comments</span>
<?php endif; ?>
</footer>
<?php endif; ?>
<div class="content">
<?php print render($content);?>
</div>
<?php print render($content['links']); ?>
<?php print render($content['comments']); ?>
</article>
Getting rid of <div>’s is the same kind of revolution that moving from a table based design (with spacer gifs) to a CSS based layout was. I just go in slowly and learn stuff as I go along.
Drupal still has this idea of <div>’s for everything. We build on a system. Fair enough, but dealing with all these layers is like wearing a chastity belt you have to get through to get to the good stuff. Peeling off the onion layers is painstaking. So “keelhaul the div”, “keelhaul the field”, in field.tpl, field—contenttype.tpl, in Preprocess, in the use of #theme, and in Display suite.
Function for no-div #theme [VK: source: mothership/functions/misc.php]:
<?php
//alternatvie to field when we need some goddamn clean content
//use it in a tpl file like
//$content['field_NAME']['#theme'] = "nomarkup";
function theme_nomarkup($variables) {
$output = '';
// Render the items.
foreach ($variables['items'] as $delta => $item) {
$output .= drupal_render($item);
}
return $output;
}
Display suite’s way of handling this is to provide an interactive UI (even on an expert level) field template to generate field markup.
Views (“Views needs more divs” T-shirt unavailable as of yet 🙂 ) has a simple little checkbox in its Row style options “Provide default field wrapper elements” which if unchecked (it’s on by default much to mortendk’s chagrin) will remove the usual views “divitis”.
The HTML5 Tools module [apart from directly supporting the html5shiv plugin] is very valuable in also giving us a UI providing strong support for HTML5.
In general, “the day the world runs out of <div>’s What will drupal do? Well, we are making this better.
In <form>’s, in HTML4 you had to have a <div> inside of your form. You don’t anymore.
Function for no-div form [VK: source: mothership/functions/form.php]:
/* removes the <div> wrapper inside the form */
function mothership_form($variables) {
$element = $variables['element'];
if (isset($element['#action'])) {
$element['#attributes']['action'] = drupal_strip_dangerous_protocols($element['#action']);
}
element_set_attributes($element, array('method', 'id'));
if (empty($element['#attributes']['accept-charset'])) {
$element['#attributes']['accept-charset'] = "UTF-8";
}
return '<form' . drupal_attributes($element['#attributes']) . ' role="form">' . $element['#children'] . '</form>';
}
The <small> tag is now akin to description, so you have <small> instead of <div class=”description”> and as wrappers in drupal around forms and “helper text” for form fields. The Drupal Watchdog (“shameless promo”) has published mortendk’s article DeDrupalizing the login form.
CSS3
Now that the markup is somewhat cleaned up, enter the //FOAD (“f-off and die”) technique, just say no to loading CSS you are not going to use.
IE6 is dead, so why are we doing css as if it were still alive? So now, we can use real selectors:
-
foo > bar(), foo + bar , foo ~ bar
-
rgba(…)
-
input[foo=bar] <- data selectors
-
:first-child
-
css3 pie
The best of all is:
foo[input=”button”]
foo[for=”button”]
foo + bar
foo > bar
foo ~ bar
Now, developers love hooks, but stop treating class names as hooks and bloating css. A library of class names for Drupal, that actually makes sense is difficult. The markup is no more a generic naming scheme. Learn about Scalable and Modular Architecture for CSS (smaCSS) and Object Oriented CSS, where the whole idea is to clean everything up and make it reusable. How to kill CSS? With FOAD!, BAT (use base.css (i.e. ajax stuff), admin.css, theme.css in order to ease updates, less wasted time overriding stuff and general css organization), overwrite n overwrite n methods.
Function to purge needless stuff [VK: source: mothership/template.php]:
/*
// Purge needless XHTML stuff.
nathan ftw! -> http://sonspring.com/journal/html5-in-drupal-7
*/
function mothership_process_html_tag(&$vars) {
$el = &$vars['element'];
// Remove and CDATA prefix/suffix.
unset($el['#attributes']['type'], $el['#value_prefix'], $el['#value_suffix']);
// Remove media="all" but leave others unaffected.
if (isset($el['#attributes']['media']) && $el['#attributes']['media'] === 'all') {
unset($el['#attributes']['media']);
}
}
We can now concentrate on classy markup that gives us identity instead of the mindless <div>.
Drupal isn’t really wrong. Frontenders have to explain what they need to backenders and developers so a dialog can improve things.
the mothership
The idea was a preloader for all the markup and css, done as a base theme. It’s not sexy unless you like to see source, then it’s pretty f-ing hot! The backend interface allows for easy loading of helper stuff like modernizr, the “poor themer’s helper”, bringing in commented out template suggestions, field options (optionally remove specified classes), etc.
See
http://drupal.org/project/mothership
Other resources:
Keynote – Luke Wroblewski
Session: http://denver2012.drupal.org/keynote/luke-wroblewski
Video: http://bcove.me/wky21125
Slides: n/a
For years, most Web teams have designed for the desktop. Mobile, if it even happened, was a port off the desktop version, designed and built before anyone even considered the mobile experience. This made perfect sense for a while. Browsing the Web on mobile phones was painful; carriers controlled access to the Web on their devices; and mobile network speeds made everything often grind to a halt. But things have changed so dramatically over the past few years that starting with the desktop may be an increasingly backwards way of thinking about a Web product. Designing for mobile first can not only open up new opportunities for growth, it can lead to a better overall user experience for a Web site or application. In this presentation, Luke Wroblewski will dig into the three key reasons to consider mobile first: mobile is seeing explosive growth; mobile forces you to focus; and mobile extends your capabilities.
Web products should be designed for mobile first. Early in 2010 Eric Schmidt, Google Chairman, said, “smartphones are the high-volume endpoint of three trends“ (connectivity, computing power and cloud computing).
“We’re just now starting to think about mobile first and desktop second for a lot of our products” (Kate Aronowitz, Design Director Facebook). Words echoing this concern from Kevin Lynch, CTO Adobe. This concern is evident across many domains in web applications.
The reasons for the mobile first approach and mindset:
-
Astounding growth leading to new opportunities
-
Huge number of sales
-
In many parts of the world there are whole generations whose first experience with a computer is with a smartphone; a whole new set of people to reach that are really starting on the web mobile only
-
Kenya: 20% of GDP done in mobile payments
-
In a few years, more mobile traffic than desktop traffic in the US; percentage of mobile vs desktop use leapfrogging for many apps due to the fact that you have these devices with you wherever you go and you are connected to the internet.
-
Facebook has #1 app on many platforms, yet 50% use Mobile Web, 50% (all) Mobile Native Apps (combined)
-
-
Constraints allow (force) you to focus down
-
Screen size
-
320×480 means a loss of 80% of 1024×768 space “which I think is awesome”
-
If you design mobile first, then move to the desktop you will gain in design, usability, simplicity: primary focus on the stuff that matters (facebook, flickr, expedia (!)
-
-
Network bandwidth
-
Optimize for low signal strength, low bandwidth, and it will scream on 4G, desktop
-
“Nobody wants to wait while they wait”
-
-
Focus you to prioritize on the features people really want
-
-
Capabilities lead to innovations which take us well beyond desktops
-
Rethink the way we deliver experiences with a new palette of capabilities
-
Landscape mode (gmail)
-
Tilt scrolling on instapaper, 360 degrees panoramic image
-
Location detection
-
Drag down to refresh on top (touch starting to take over mobile devices)
-
Touch allows direct interaction with the content instead of scrollbars and other “debris”
-
Natural User Interfaces: content is the UI
-
-
Fat finger error (small cancel area right next to login button): error rate
-
-
Combination of capabilities
-
Out in London, sightseeing, find the tube station nearest me; on desktop it involves a lot of work. But nearest tube uses location, camera and digital compass to guide you to station directly.
-
Yelp Monacle: Augmented reality when you point the camera at objects (location, compass…)
-
Mobile barcode sales (in-store!); grocery shopping with QR codes on the subway walls (Korea)
-
Word lense translates what you point your camera at
-
OCR and translation with Google Goggles, Siri
-
-
APIs being developed to take advantage of these capabilities
-
Check out also a cool summary of this talk at http://www.ostraining.com/blog/live/mobile-first/
Panopoly is responsive out of the box
What does this even mean?
-
Part II
-
My next step is to present a series of articles on using Panopoly as a starter kit for the rest of us, taking into account the advice of all these good people for responsive process and responsive user experience.
-
Conclusions
Certainly the overriding theme is to be able to answer the burning question of what to do with Drupal 7 here and now and for the next 2-3 years in order to be able to work with the new, easier, better awesome sauce? This has appeared with responsiveness, with “HTML 4 S”, and certainly with Panopoly (“panels now!”). I have tried to answer this question in my previous sister article on backend stuff, and here it is with the front-end stuff.
An example
Install panopoly, make a base theme (as simple as possible, say based on Stark), and with a few lines of code you have a site as responsive (but with all the panelizer goodness, say with the Panopoly demo running) as the Boston Globe site. Full example with step-by-step instructions coming in a few days with all the code.