Media Queries + Server Side Componets

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 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.