Media Queries + Server Side Componets

benjaminkyta's picture

Hello

Is there a way i can use a given layout for big screens (eg 980 and above) and when it comes to small(er) devices, i drop off some of the Zones or even just regions eg sidebars? Which means the full layout is only viewed on large screens, and when it comes to smaller screens, only the header and the main content is loaded in the browser.

Note that in the example am giving, i don't want the browser to load the content in the other zones or regions eg sidebars, completely. (Which means CSS[display: none;] cannot help)

Thanks very much

Comments

This can be done

zoon_unit's picture

Use display: none to hide the components in the default mobile CSS. It would be great to not transfer the hidden content at all, but that would require a separate module or other way to detect the layout. Hopefully the Context guys will eventually add media queries as a context trigger.

Hope so too.

benjaminkyta's picture

In fact this should be introduced in Drupal8 since one of the objectives is to make drupal mobile friendly. It will boost drupal's performance on mobile devices.

Thanks alot

Media queries as a context

samwillc's picture

Media queries as a context trigger would be marvellous!

Sam.

Yes. I use Mobile Tools +

jorgbert's picture

Yes. I use Mobile Tools + Browscap + Panels to create mini-panels, that I then insert into the Omega regions.

  • Mobile Tools 7.x-2.0-unstable1 (Do NOT use the new 7.x-2.x-dev version. It is broken, and has parts missing!)
  • Browscap 7.x-1.x-dev
  • Panels 7.x-3.0
  1. Activate

- Panels Mini panels, which will also activate Panels
- Browscap
- Mobile Tools Browscap, which will also activate Mobile Tools

  1. Configure Mobile Tools as desired. Select Browscap. Ignore WURFL.

  2. Create Panels Mini panel, eg LeftSideNav. Insert block or content as usual into mini panel. I have a stripped down sidenav menu for mobile, and a regular sidenav menu for narrow, normal, wide. Set minipanel context to node, to reference node attributes, if desired. Set block visibility to Mobile Browser. This is a new visibility context that Mobile Tools adds. Click . Check "Mobile Browser", or select specific User Agent, eg iPhone, iPod, Android, Opera Mini, BlackBerry, Mobile Device. You also have "Reverse (NOT)" to give you the best of both worlds. iPad is not considered to be a mobile device by Mobile Tools, since it fits the narrow/normal screen widths.

Recognizing that Mobile requires much lighter graphics, etc, I'm creating a Body-Mobile section to my nodes in addition to the normal Body section. Using the Panels visibility rules described above, I can load it into my content area, instead of the regular body. Display: none, and displaying large images at reduced sizes on a mobile device, is counter to the whole idea of making the smartphone version a lightweight version of the SAME content. I want to display the SAME content, on the same URL, but just strip out all the fat, and go with lightweight images, etc. The above configuration handles that nicely, and is certainly no more work to have both a Body-Default (renamed Body), and a Body-Mobile field, using CCK, for each node. Since the content is in a node, instead of a "Panels Page" page type, the Body-Default content is included in the standard Drupal Search.

I actually go one step further, but this is beyond the scope of your question. On our large sites, we have a two-level Main Menu for the desktop version, and a single-level Main Menu equivalent for the mobile version. We also have numerous sidenave menus, associated with specific sections that make up groups of pages. To give us the granularity, we create two taxonomy lists - "SideNav-Sorted" (select one) and "SideBar-Sorted" (multi-select). We add this to each node edit form, and when we edit a page, we then simply select the appropriate sidenav menu to go with the page, and however many sidebar blocks, ads, etc, we want on that page from the second list. That's all that is required to associate those items with the node. In Panels visibility, we then create a visibility rule that looks at the node term context for that taxonomy list to see if we have a match. If so then that block displays. It's simple, intuative, and easy for our site maintainers to work with. With this combination + Mobile Tools, we can produce almost anything.

Media Queries are great for figuring out the screen width, and applying the right CSS. That is as far as it goes. It's client-side only. To control what content is sent from the server in the first place, requires Media Tools (or an equivalent) to pick the right content to send. Panel's visibility rules, caches accordingly (especially important if we are on the same URL), and sends only the content that is appropriate for the device. Omega controls the Header, Content, and Footer areas and provides 960gs support. We start with the light-weight mobile version first, of course, but treat smartphones as a first-class portal web access device, instead of dumbing it down. In other words, we provide the same content, with lighter weight graphics, etc. Media Queries will never be a context trigger, because that is not the right place to do it. Media Queries deal strictly with screen size. You get the same result with a narrow browser on a desktop. Our approach is that a mobile device is even smarter than a desktop. Think GPS, etc. We want to know the client device, and the server dishes out intelligent content, sized appropriate to the device. That is way outside the scope of Media Queries.

Thanks @jorgbert

benjaminkyta's picture

Let me give this a try. Am positive this will work for me as well.

Thanks for the info jorgbert

samwillc's picture

Thanks for the info jorgbert :)

I'm all for a lightweight mobile version but you still have to guess what device someone is using and if you're going to add different bits here and there for a mobile version, you may as well have a separate mobile site. Menus can be manipulated with css for different sizes and a hidden menu is hardly going to slow anything down. Actually, even larger images load up fairly quick on a mobile, dial-up is dead and buried. Also, are we talking display:none on a 5000px x 4000px image here or 500px x 400px image?

Granted, you can't hide regions (or do the stuff that you do jorgbert) with media queries, but I feel they satisfy the situation very well (as long as my site resizes according to width, it doesn't matter what device someone is on). Images could ideally be smaller on a mobile to save a bit of time but I really don't consider this a big issue.

As far as saving space/bandwidth, if mobile usage doubles, does that mean unique website visits also double? When someone is on your site on a mobile, they aren't also on it on a desktop at the same time. You expect a certain number of visitors whatever device they are using. Is it pointless for a mobile user to download a full size image and only see it at 3" across? Maybe, but aren't mobiles going towards HD already now and will indeed be able to download and display such high resolution images? What will happen to media queries when mobile browsers use high resolution screens?

Personally, I don't think detecting a device is a good option. I am very interested to hear other peoples' input on this as I think it's an important one.

Sam.

Agreed

Kendall Totten's picture

One thing to be aware of when using Mobile Tools is caching issues:
http://drupal.org/node/996838

If you switch themes based on device type, there is a chance that caching will bypass the device detection for the next user and pull the incorrect theme from the cache. This can be solved by reading the documentation in the mobile_tools_cache.inc file and adjusting your settings.php file accordingly. Relying on user agent detection on the server to decide which device class specific components to include could be an issue for some. There's a lot of debate about how accurate user agent detection is:
http://www.w3.org/TR/2001/NOTE-cuap-20010206

Omega Framework

Group organizers

Group events

Add to calendar

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: