We need to start thinking and talking about what approaches we're going to take in Drupal 8 with regards to design for mobile.
My own opinion is that we should probably be looking really closely at responsive design and how we might apply or adapt the patterns emerging in that field. The idea of "one web" and a unified design and user experience independent of device appeals to me. I don't want an impoverished mobile experience, so please don't assume what I want to see or do just because I'm on a tablet or handset.
I want to pose another, more radical question - is desktop design as we know it fundamentally flawed? Are we are somehow approaching mobile design with a view that the desktop is a "solved" problem, when in fact the problems are not solved and we actually need to rethink "web design" from the ground up?
Should we be designing for mobile first or is this a complete misnomer - how can we differentiate between the needs of the mobile user and the desktop user, is this even possible? Can we be so brave as to make such drastic assumptions?
These are pretty high level questions, yes, but they (amongst other ideas) should underpin our design for mobile approach. We need to figure out what our approach is going to be and how we're going to solve the ensuing issues.
Comments
I have been pondering this
I have been pondering this issue myself. After creating a few responsive Drupal sites, I have asked the question to users, do you want to see a mobile site, where you can choose to see the desktop version, or do you want all the content formatted for mobile without an option to see the "desktop" version.
I am not sure what the best approach is, if the user preference is for a desktop version option...
One at a time
Let's take these universe-busting questions one at a time.
Responsive design as we see it today is not what I would call true responsive design. More a 'Response-lite'. Adaptive/Responsive design is meant to be more context aware.
Currently the one context we take in to account is screen size. We are using this as a divining rod to make assumptions about the device it is being viewed on. We already see this in starter kits like HTML5 Boilerplate and 320 and up. To many Media Queries make bold statements like 'below 420px = a smartphone' and '768px – 1024px = iPad'.
They are going to be lucky if they survive the next year still intact, we are still at a stage where tablet = iPad but that really isn't going to last.
Isn't "Responsive" about more than screen resolution?
@lewisnyman, I guess this is what you're getting at, but isn't responsive design about "Can you run Javascript?" and "How fast is your connection?" — and more — in addition to "How many pixels are you packing?"
And aren't there ways to probe those other issues?
And, deep as these questions are, I'm glad that they're being probed. Device-independent design needs to be our goal... unless we want to rebuild our websites every time a groundbreaking device is released.
...
What you're asking about Cliff is "capability detection", which is something we've been discussing. Its something I am personally quite cagey about (as in putting something like that in core), we'd need to have some very good reasons to do this and I would very much like to explore these other emergent ideas (such as Responsive Design) first, before leaping headlong into capability detection.
Smashing magazine have a good roundup of RD: http://www.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web...
Just as a side note I was having lunch with a client the other day and he was checking some stuff on his iPhone and made the poignant comment that he really disliked the site he was on because it reformatted the normal site into one long column. Now this is something we keep getting told is "good for mobile", but his view is that is takes away is ability to quickly pinch/zoom and forces him to scroll. On the normal view the site is quite wide and has 3 columns, its easy to pinch/zoom your way around the page to get to what you want. Food for thought.
Interesting client story -
Interesting client story - but I wonder if he hasn't just got used to the 'bad' UI of pinch and zoom web sites and now feels inconvenienced by just scrolling. Would it be the other way around if most sites were already using adaptive layout?
...
What my client is saying that is that he prefers to just have the website layout the same as the normal desktop layout because "that is what he is most familiar with", but now he has to learn a new layout, options are moved (even removed) and the whole experienced is totally different on his iPhone.
So yes he is used to this - however I'm not sure if this will suddenly change even if all sites use an adaptive/responsive layout, because the layout of the desktop version of the site is frequently substantially different. This is really the point he is making, so what hes saying is "please don't change things because I have the tool to navigate the familiar and known". Don't force me to learn something new (don't make me think).
This is why I ask if we need to rethink web design per se, to think more about creating unified experiences regardless of device, screen real-estate and so fourth so we don't break the users mental model of what the website "is".
This is based on the
This is based on the assumption that the user has an expectation of how that web site should look based on their desktop experience. I think it's seems more appropriate to assume that the user has a UI expectation within that device. I think iPhone users, for example, expect web apps to behave like native apps do on their phone.
Agreed...
I know I personally prefer to just have things simple and scrollable on my phone, it just makes sense to me that a touch screen scrolls really, really easily... However, I do see the point the Burnz brings up re: client being used to how the desktop experience works. At the end of the day however, I feel like I have more people complaining that desktop sites DON't function exactly how they expect on their smaller devices rather than that they wish it worked exactly the same and are upset by seeing something different. A lot of desktop formatted sites are terrible at the screen resolutions and ratios of smart phones both in layout and in functionality—rollovers and fancy hover effects are the bane of my touch screen existence. Anyway...
Bottom Line: Let the User Choose
No matter how well we can detect what a device is able to do, the user needs to be able to choose the experience they get. Jeff, I empathize with your client fully. Because I use an iPod Touch, I at first had no idea why our site's layout was a concern for mobile. After all, you just pinch and — what's the opposite? unpinch? — zoom to move around the site, right?
And then it dawned on me that not everyone could do that with their small screens.
There will continue to be many of us who want one "look" that we can navigate according to the abilities of whatever device we have at the time. And there will continue to be folks who just want the content served in whatever format works best on the device they're using at the time.
At best, we can sniff capabilities and serve accordingly. But, still, we must let the user choose a different presentation if that's what they insist on working with.
After all, if I were blind, my screen resolution wouldn't matter at all in determining the way I could best receive the content. Even on my desktop device with 80-bejillion-megapixel resolution, I might want you to serve me the content in a presentation optimized for mobile.
OK, I have to admit that I am
OK, I have to admit that I am playing a little bit of devils advocate here, although the client story is 100% true.
Drupal already has many ways to serve content to mobile devices - both capability detection and device detection modules exist (Modinizr, Browsecap). Its actually not that hard to build a dedicated mobile site with custom theme and serve only what you want to that site. I think in D8 that will actually get easier to do (thank goodness, its easy for me, but for others maybe its a lot of time and effort to figure things out).
For us the challenge is providing an out-of-the-box mobile experience that works, with zero config and zero knowledge. I think that is what I am driving for, so maybe its not perfect, but works pretty good for the 80%.
> For us the challenge is
> For us the challenge is providing an out-of-the-box mobile experience that works, with zero config and zero knowledge. I think that is what I am driving for, so maybe its not perfect, but works pretty good for the 80%.
This. Exactly.
I like the RD approach a lot more than the old "fluid layouts" (you know, the layouts build with % and ems only that supposedly adapt to any width, and often end up looking ugly at any of them.)
Both are a lot of work, but the former makes more sense regarding usability/readability AND visual design.
We can look at what mobile
We can look at what mobile apps do.
In the Apple world separate apps for iPhone and iPad (and Mac OS of course) are encouraged, but they essentially have to deal with two sizes.
In the Android world there are lots of different resolutions and device sizes, how do they solve this problem? From what I've seen it's a bit of a mess, not unlike what we do for web pages.
It's also not just a matter of user interface, mobile versions of websites are lighter and faster to display and use, especially on low-end devices. Less work for the browser also means more battery life.
Also, media queries examples at Design Shack :
http://designshack.co.uk/articles/css/20-amazing-examples-of-using-media...
If D8 offers baked-in
If D8 offers baked-in capability to serve a lighter site I wonder how that can work - device detection + separate theme (load less blocks, load lightweight theme etc). Mostly I've been using Domain Access, Browsecap, Mobile Tools + Panels and mobile specific themes to load only what we want to mobile devices. The panels layouts are all custom built + a lot of panels theming to rip out excessive markup. For the most part it works pretty good.
Our problem is how to deliver something that requires near zero configuration or knowledge; we know our core theme has to support (look good and work as UI) for wide cross section of mobile devices out-of-the-box.
screen resolution
Tend to agree that the whole point of the iphone et al is that it brings the full browser experience to a mobile device. So why have a separate mobile version?
Also the way things are going with the ipad and even the desktop experience is that people are now using their fingers etc for navigatiing the screen etc and can zoom in and out. For example one can zoom into a thumbnail slideshow and get quite a good view without having to view the modal window, (which is quite cool)
So with regards screen resolution surely we should not be too concerned with this but make a website so that it works cross platform, screen resolution etc irrespective of the device that is using it. I mean good typography means that the ;length of a line shpuld not be that long anyway. I mean text needs to be readable when someone touches or zooms in on that particular article. So this consideration is relevant to both mobile and desktop platforms.
I agree with your client. Its like WAP pages, a dumbed down version for mobile devices.
Concentrating on browser capabilities etc using modernizr et al is alot more interesting. e.g. supplying a suitable video /audio stream, irrespective of which browser platform the user is browsing from. Making the user experience with out the user having to think about whether the should be on the mobile-lite site or full featured version. Even worse is when the website routes you to the dumbed down version to start with. How patronising is that?
http://www.danlobo.co.uk
Screen size and resolution
Screen size and resolution still needs to be considered, this should come to light when completing the user research; pre design/build. If the project requires the need to be available on different on displays, as is more often the case, you could build one site using responsive [adaptive] design techniques such as; fluid grids, flexible images, and media queries.
Responsive design isn’t limited to layout changes. Media queries allow us to practice some incredibly precise fine-tuning as our pages reshape themselves: we can increase the target area on links for smaller screens, mobile versions and multiple columns. In theory, this allows the same web page to be served to devices with differing resolutions, allowing the design to dynamically adjust, providing the optimal viewing experience for that particular device. Unfortunately not all web browsers support media queries, but thankfully it’s fairly easy to ensure a reasonable default design can be displayed in these browsers.
Some examples can be found here http://www.dereckjohnson.co.uk/design/great-examples-of-responsive-websi...
Responsive Design
Yes. Not sure which designs you are referring too exactly but the ability to increase the link size for those browsing on mobile devices still sounds patronising to me.
Unfortunately not all web browsers support media queries, but thankfully it’s fairly easy to ensure a reasonable default design can be displayed in these browsers.
I think you have made my point right there. Why not have it the other way round. i.e. show visitors the default page and if they have a a larger screen resolution etc, perhaps they can access the value added site?
Anyway, these might be good examples of responsive design but I can also give you some bad examples:
All show a dumbed down version of the site when viewing from iphone. And then you have to find the link to request the 'full' version once the page has loaded. Also worth a mention is the BBC website that still doesn't seem to work without having flash installed.
Also with regards user research , where do you get this from. Personally I would take most research with a pinch of salt as generally you can make this tell you want you want to see. Users are not generally experts on Web Design or UI, nor do they necessarily want to be.
p.s. I quite like old VW's too.
http://www.danlobo.co.uk
As with any good examples,
As with any good examples, there will always be bad ones too. I find the ebay site very good on an iPhone, a lot of work has been do on the IA and as such rather being 'dumbed down' it has been streamlined allowing quick and easy access for the user; without having to zoom in/out of the full site on a small screen device.
User research is an important requirement of the design process. Without an understanding of the target audience, and their requirements, you can't design a product that meets their needs. Very rarely are either yourself or your client the target market.
Your comment about using research to tell you what you want is not correct, although you can make stats tell whichever story you wish to convey.
zooming in and out
yes well personally I don't mind zooming in or out. In fact I quite like doing this to zoom in on images to see details etc.
One thing I don't like doing is scrolling left or right to read a paragraph of text.
http://www.danlobo.co.uk
Those are not examples of
Those are not examples of responsive design, but of dedicated mobile sites. Responsive design is not about dumbing down the site, quite the oposite, some say, start with mobile, define the essential, than add more visual appeal (bigger images), interaction (JavaScript) and position the page content according with the space available.
I would suggest reading the responsive design book from abookapart.com it's a very light read and you get a good sense of what we should be aiming for in D8.
I have to say I dont agree that responsive design is the solution for every site. But for majority I think it fits. A new core theme for D8 should be build with this in mind and I would also like to know if Jen Simmons would be interested in revamping Bartik design to be responsive. But that's another issue :)
You're quite right, one size
You're quite right, one size will never fit all, but building a site which is responsive will answer a lot of issues. Having this option built into a core theme could really help.
In my blog article I have also suggested the reading of the following;
Responsive Web Design by Ethan Marcotte http://www.alistapart.com/articles/responsive-web-design
Fluid Grids by Ethan Marcotte http://www.alistapart.com/articles/fluidgrids
Fluid Images by Ethan Marcotte http://unstoppablerobotninja.com/entry/fluid-images/
Adaptive Web Design by Aaron Gustafson http://easy-readers.net/
A responsive mind by Jeremy Keith http://adactio.com/journal/1696/
Although not Drupal specific, these books & articles are a great resource.
I agree
I agree that some responsive web practices will help a lot if they were baked into core, but mobile will always have to be thought of separately.
Another great read if you are reading up on responsive web...
http://www.cloudfour.com/css-media-query-for-mobile-is-fools-gold/
Always is a very strong
Always is a very strong word...
Just think of all the simple drupal sites used by bloggers or module developers, We are not talking about the big drupal sites, but the majority of them, the ones that don't have the resources, need or the time to develop a dedicated mobile site.
We really should stop thinking that mobile is different for our use case. In the last WWDC Apple just made the desktop another device, not a special one, from where you access the web. They did it because of icloud, but it will affect everyone else in 2 years.
Agreed
I should have said for larger drupal sites that care about performance. I think we are all in this bikeshed to think about information being fed going to all devices not just mobile as a specific case.
...
I have an open issue for converting Bartik to RD: http://drupal.org/node/1077094 - help would be awesome as I am pretty darn busy these days :)
We're looking at Seven and Toolbar as well, as part of d8mux.
I checked it out
Hey Jeff, I saw your sandbox and I'd like to help. Lemme know if you can grant me commit access or if I should just clone it and fork
Best, Hans
Awesome, I gave you commit
Awesome, I gave you commit access to the repo, and edit privileges of the project page which might be a good place to keep a log or something.
Cheers!
rsponsive design = fluid?
Yes I am a big fan of the A List Apart website.
So what you are saying is that responsive design = fluid design with the advanced capability of adjusting paragraphs and layouts and even image sizes depending on the viewport of the user?
One limitation of fluid design is that designers and marketeers often struggle with not having pixel perfect control of how their websites look which is hard enough to achieve at the moment with the plethora of different browsers out there with a fixed width.
http://www.danlobo.co.uk
You can look at it in two
You can look at it in two ways. You could be really specific with your definition and say that Responsive Design is Fluid Grids + Fluid Images + Media Queries.
Or you could be broader and define it as a design philosophy, making a site change depending on the context it is situated in. The most common example of that is screen size and that is what we are trying to solve here.
Context
@lewis: When you say "context" are you referring to the Drupal sense of the term - such as where in the site you are (e.g the front page, a site section etc), what language the page is in, the date and time, what tags are used and so on, as opposed to the more traditional usage of the term as it relates to mobile development i.e. where the user is (at home, on the bus), what are they doing (busy cooking dinner, relaxing on their way home from work) etc.
All of the above.
All these and more should be available to a responsive site. I mean context is the broadest possible term.
There are already themes that make 'Drupal context' available through body classes. This kind of responsive design is something CMS theme developers are used too. 'If side bar exists do this', 'If this content exists, do this'.
We can expand on the context available to us by scraping the HTTP request for information and by using front end techniques to get information like screen resolution, geolocation and touch capabilities. I think testing for capabilities will become more and more important as devices become more diverse. It makes it possible to actually enhance apps based on the capabilities of mobile devices rather then detracting. It's progressive enhancement where the mobile is the benefactor. This is something the W3C are currently working on.
The context of the mobile user is the other pillar and it's the only one we can't extract without getting them to fill out a questionnaire when they visit the site. I think this is where user testing is most important and something we are going to plan in detail for D8MUX. We can't make assumptions on this context based on another context like screen size. We need to make sure the design is sane by testing it in various situations and devices.
We grapple with this on most
We grapple with this on most projects now, with the issue usually discussed in two distinct ways:
As an out of the box experience, I like the approach WordPress takes with this - tick a box to enable a really basic mobile theme immediately. For D8, it'd be great if the default theme (i.e Garland or equivalent) had two checkboxes in the theme settings: * Enable smartphone display, * Enable tablet display.
The step up from here would be some kind of module/config setting that allows you to target specific nodes at these mobile versions.
This approach would at least get all designers, themers and devs starting to think about creating mobile display from the start of each project, not as an afterthought as usually occurs.
As for the desktop vs mobile debate... Desktops should dominate for at least the next 3-5 years in terms of sheer numbers for most sites, so I'd keep the focus on that for now.
What version of WP are you
What version of WP are you using, I installed the latest (3.1.2) and couldn't find such an option, I could find some Plugins though, most seem to rely on user agent, but I did find quite a few Responsive WP themes also.
I think its probably a valuable exercise for us to at least look at some of these other systems and what they are doing, I know eZPublish has an mobile theme that displays automatically out-of-the-box for iPhone (not sure about other devices).
Perhaps even if we narrow down a few approaches we can go out and research how others are solving the problems these approaches pose and come back with data to look at?
I believe it's an option only
I believe it's an option only on wordpress.com
Moot
This is a moot point, as I think this conversation is about figuring out how to apply responsive/adaptive design principles to D8 from the start. This isn't just about clicking "I want a mobile site" but saying systematically try to figure out what people want on a mobile device, and then how do we serve that to them from the same site, with all the same content, with just adaptive themes and functions... hmmm. Although without knowing a use case or the kind of content a website has this is basically impossible. Also, just clicking "yes, mobile site" might make the average user capable of putting that out there, but part of adaptive/responsive design is to both allow the easy flexibility of the device and screen change, but to also actually try and plan for all these use cases from the very onset. I also like the trend online I see of people discussing the "mobile first" ideal, where you decide what people want the most, and make that as easy to show/get to on people's phones... then you design the rest of the desktop version to make that possible no matter what.
Re: Desktops, We'll always need to design for some sort of large-format device, I for one know that as a designer (both print and web) I'll always have some large format screen to work on, it would literally be impossible to design and build a book just on an ipad, so we're always gonna have 1200, 1500, 1900, 2200, etc. pixel sizes to continue to deal with. The great part is that you could show some crazy amazing visuals to those people to take advantage of their colossal screens, and (as in the case of Southwest) just the thing your visitors need the most for a smart phone.
Separation Content/Design
How about completely separating the content from the design?
Here I describe a demo I've created for mobile devices using Sencha Touch, an open source JS framework specifically tailored for mobile:
http://groups.drupal.org/node/103244
The mobile UI is here:
http://teasencha.net/
But the site (our shall I say, the sites) are still powered by Drupal:
http://green.teasencha.net/
http://yellow.teasencha.net/
Not Adaptive
This is a mobile only UI, if I follow that link to my desktop, I see what you want me to see on my phone, not what you want me to see for my desktop. I don't think this fits the adaptive/responsive idea of using one site to serve all devices.
I think this will be the key
I think this will be the key part of the answer we're looking for. Drupal has gone a long way toward separation of content and design. We need to go further. Without that clean separation, your ability to give each user and platform what they need is very limited.
bjornmeansbear and Tschet are
bjornmeansbear and Tschet are pointing the right way. The current set of desktop, notebook, mobile and pad-type devices are just that 'the current set'. It is unwise in the extreme to assume that this state of affairs bounds the problem. For all we know future individual devices may support widely varying interface styles that will be customized by the user who will expect to see the internet accordingly. This is a huge problem looking for a simple elegant solution.
I suspect the range of device manufacturers will eventually agree upon an interface protocol to ease the burden of universal support.
What are you guys designing?
If you aren't designing content, what are you designing exactly?
A blank page? A pretty wrapper?
A design is meant to complement the content, we should be designing around the content not around devices.
Content IS the design.
Design around content is
Design around content is correct. Having platform device-aware and making design more meaningful and powerful up to trends - is a good way to go.
Content isn't the only factor
Come on, the content isn't the design—otherwise no one that called themselves a designer would have a job. Though you are correct that the content must be taken into account. Having a theoretical discussion of general principles with no real content or use case can be frivolous. However, there are also things like context to consider—the design of the same content should change based on context. Context truly being king, there will be rules and patterns that can help govern decision making regardless of the content.
Separation Content/Design
@bjornmeansbear: yes, it's a mobile UI only. But my emphasis is on the separation between content/design. Once we have that, we can build an adaptive/responsive UI.
@Tschet: "Drupal has gone a long way toward separation of content and design. We need to go further." Exactly! You got the point!
Adaptive layout vs Responsive design
I'm actually thinking the terms being used in this debate (and I mean web wide, not just here) are a little fuzzy.
Adaptive layout = using media queries and CSS to change layout based on screen dimensions.
Responsive design = well, this I find very ill defined or rather all encompassing. It encompasses everything, adaptive layout, adaptive content assets like images, visual design and how the site/app works.
I also think we need to keep in mind that low bandwidth and small screen size don't always go together. Small screen + high bandwidth and Large screen + low bandwidth also need to get the right mix of content and design. In particular I think the 'mobile theme' approach fails to address that.
Capability testing is pretty much a requirement, and fine as long it's done right (lets not go back to the days of browser sniffing). The really obvious one is imageapi, and having imageapi generate a series of size/quality presets that can then be delivered as part of a responsive design. But not just responding to size, also responding to available bandwidth (how do you measure that can it even be done with Drupal/php or does it require other server-side tech?).
This idea of having classes passed to the theme is also a great one.
...
Yeah, I totally agree with your points here.
Responsive design is pretty fuzzy right now, I've even seen it described as "flexible everything". I suspect since its an evolving school we don't have anything more than a fuzzy idea of what it entails, exactly, or what patterns we can bring away from it that are usable with any certainty. Right now to me at least its a very interesting idea that's well worth exploring; how might this change how we think about web design?
Imageapi is the most obvious candidate for attention or at least some way of pushing different presets to different size screens. The bandwidth issue is something that's well worth investigating, I don't have an answer for that.
If It is a question of Definition
does that mean we need to just layout out our criteria for what the words mean? Or call it something else?
I really like the idea of different images for different use cases that can sort of on the fly load/reload — I've been looking for something like this now actually, and if I figure it out will post it.
HTML5 Less Framewrok starter theme
Hi all,
I agree that mobile first might be a better solution when designing adaptive/responsive websites ...bottom-up approach is preferable imho. Maybe this way, if the website is built carefully, normal users will not complain about desktop layout being the right layout and mobile one being just a remake with less features (it shouldn't be too difficult to get used to the new mobile interface anyway ...thinking can be a good excercise at times). I feel both bottom-up and top-down approaches need to be explored to the fullest to see pros and cons imho.
But for now I was just experimenting with Less Framework (CSS) applied to drupal as a Boron subtheme.
here is my sandbox theme: http://drupal.org/sandbox/farsaid/1099826
and here its demo page: http://demo.openconnection.it/lessframework/
Here is a tween project sandbox I wasn't aware it was there already being new around here: http://drupal.org/sandbox/jover/1096848
Due to the lack of free time it's quite a while I don't put my hands on it, but it can give you an idea already ..it's not perfect, but neither useless i think. So you can have a new toy to play with if you wish.
Every comments, suggestions, are always welcome. And you're free to bring it forward of course. If you want to become co-mantainer just ask
Thanks
Flexibility
Listening in on this, my two cents is that one cannot really anticipate all the ways in which an audience will use a web resource. So the question of mobile vs. desktop is really one that should be in the hands of the client -- what is their target audience, and what do they expect (or measure) that audience to need most?
Drupal should be able to respond quickly to the web designer insofar as s/he is creating what the client needs. To me this isn't locking in mobile or desktop, it's not a button that lets the user switch, it's not browser (or capability) detection. It's whatever information is needed in Drupal's core to allow modules and themes to decide how to display content. (I'm a strong opponent of CMS core generating HTML.) And ideally, the community will have nice modules and themes that make all the suggestion above very easy for web designers to achieve.
Great conversation! While I
Great conversation!
While I don't purport to be a designer per se, this discussion regarding who determines the format to be delivered makes me think that it's the end consumer that ought to be the decision maker. Thus, it's up to the designer to reliably transform as needed.
Obviously it's reasonable to place bounds on how much the styling can transform, but in the most general terms, I think it's the end user that ought to make the decision as to how they want to consume the content.
Project Management: http://www.sagetree.net
Coaching Services: http://burtlo.info
While I think it's good to
While I think it's good to let people choose how they want to display/use a website to some extent, I also think we should provide sensible defaults because most people never tweak/hack/modify anything (and they shouldn't have to.)
@elv I agree in principal.
@elv I agree in principal. But my initial reaction to your message was "What?!?" Drupal's defaults are, imo, very bare-bones. Not really a usable system for anything other than a personal web site. Since I'm using Drupal primarily for its power and scalability, I really want a user interface and Drupal core settings that are going to make that mission much, much easier. I'd love to see D8 (or really D7.1) with a more comprehensive approach to quick starts -- e.g., sites that are primarily skins (no PHP) and that don't require a PhD in modules to create. (Even a set of Drupal.org defined recipes for different types of sites would be awesome; it's very frustrating in module land for the uninitiated masses.)
(Slight OT: BTW, a huge step forward in Drupal would be to trash (or segregate) all the old documentation related to D4.x and D5.x. As someone who came to Drupal as 6.x was rolling out, I really can't see why any of those old patches or workarounds should still inhabit D6.x and D7 documentation pages.)
its all about design
In terms of design for mobile we need sensible defaults for our core themes, the hard bit is balancing the lowest common denominators with unrelenting great design. elv is exactly right when he says that most users don't tweak/modify or hack their themes, some do but the reality is that most don't.
We have Stark in core, we have 25+ starter themes for users to hack away with, the whole Drupal 8 Design Initiative is not about providing a bare bones starter theme, its about delivering great design, with purpose, that a wide audience will find appealing and useful. Lofty goals, indeed, but I didn't take on the job because I thought it would be easy ;)
@Jeff - Perhaps I don't
@Jeff - Perhaps I don't really understand what you mean by "design". I see several possible points of view: module and theme designers (primarily programming), web designers (visual design with some programming/tweaking), usability design for administrators and moderators (core or theme options), content creators (for whom usability of admin themes is preeminent), and site visitors, who see the results of all the former effort on whatever device tickles their fancy.
I have been underwhelmed by the quality of visual design among the Drupal sites I've visited (other than a few very high-profile sites, which rock), and really fear exposing content creators to the admin themes I've encountered thus far.
Can you be more specific about what are the goals of your group? I'd like to participate, but I rather feel that this discussion isn't taking into account the realities of the non-programmer user base.
...
Primarily I mean visual design. You can learn more about the initiative here: http://drupal.org/node/1089096
Thanks, Jeff. That helps. So
Thanks, Jeff. That helps. So you're thinking that the D8 design you create will look great, and have enough out of the box features that people can either 1) choose from standard looks, 2) roll their own graphics, or 3) add basic branding and be done? You're not talking about something like Zen that is ground up visual and CSS-oriented. Do I have that right?
Base and start themes do have
Base and start themes do have their place but it makes sense to have them in contrib. Starter themes tend be be very bulky and over excessive. You don't want all these additional hooks running that people might not be using.
subscribing
subscribing
The radical question should be the first one
I tackled that question in a blog post about 3 weeks ago. http://www.palantir.net/blog/users-versus-mobile-desktop-divide
- John (JohnAlbin)
Good question. I wouldn't say
Good question. I wouldn't say the desktop is a solved problem, far from it, but in Drupal we do tend to consider the "desktop" website to be the "normal" one, and any alternate version is treated as a special case.
But a large part of what we do on a website is still dictated by the device we use, as much as the context we use it in. As Merlin commented on your blog post, people just want the content. But how is it best served, and do they need the same content? I think trying to give a "similar experience" on both devices is a flawed goal.
The problem is, the frontier between these use cases is fuzzier than ever. If we can't rely on the screen size or the kind of device, how do we give users what they need/expect? Is a 7" tablet used more like a phone or like an iPad? Is a netbook considered "mobile" the same way a phone is?
Do we actually have the relevant data to make these decisions?
Websites are becoming crazy
Websites are becoming crazy these days, but to me, this is market/client driven, and the tools should support whatever the client wants/needs. From a "good design" point of view, I see it as my job (as a web designer and consultant) to talk the client out of terrible ideas and confusing interfaces and then to make the best of it when I can't.
That said, when the clients wants the whole enchilada, I'm curious about the tools we as designers can use to lessen the bandwidth necessary to provide content to mobile users. To me, this (if technically possible) would be a great aim of this project, so that we're not left using CSS to simply hide or repackage things.
@JohnAlbin Isn't the recap
@JohnAlbin Isn't the recap from your blog post, mobile users are not neccairly in a rush and we shouldn't focus on certain mobiles but rather small screen devices?
We can take it even further...
We can take it even further then that Bojhan. Are we sure that mobile devices are even small screen? Look at the iPad.
And if we do, at what range of pixels do we define 'small screen'? Will that change in one or two years time?
Does a small screen mean that the device is touch capable or has low bandwidth? We can't make these assumptions. If they aren't tripping us up now they will be in a few years, when the frame of reference has completely changed.
This feels like a good time to mention that my proposed Drupalcon session, Designing without Borders is all about this shift away from assumptions. Last day of voting!
Mobile
All those are valid issues to think about. But it is true still, that there is often times a demand to build a site, and then - "a mobile site". There are many mobile devices that can display usual web sites no problem. But because of smaller screen, it's not nice. There IS a demand for that. And if we could identify such device out of the box and display a mobile theme (no sidebars, links adjusted for touch screen) - then is would be a little but big improvement.
Jeff touched a right question - mobile design is REQUIRED today. Would be good to approach it in an organized and thoughtful way.
One web
Before speaking about where to go, I'd like to know where we are. As far as I know (but I know little), adaptive content is still impossible with Drupal, while it's possible (and easy) with Apache and without any CMS. Am I wrong?
To my mind, the one web principle should be dealt with along with internationalisation: 1 content, one URL, several pages according to the device negotiation (language, screen size etc.), and a different URL for each version, that is, on total n+1 URLs, n being the number of versions. So far, automatic translation is not acceptable for most websites, so this is a human job. Since the number of languages are multiplied by the number of type of devices taken into account to produce the number of versions, 4 human languages in desktop, tablet and handheld versions means 12 versions. I bet 90% of webmasters provide and will provide only 1 version of their content, and 99% of them, no more than 3 versions. This means that device-dependent adaptation should be as automatic as possible. To my mind, good devices are entirely automatic, with the possibility to disable one by one all the automatisms. For instance I could use my video camera minutes after having bought it, getting acceptable results, but, little by little, I learnt how to adjust myself every setting when needed (and only when needed because I've still widely used automatic tunings). The default is not "no settings" but, of course, "a usually good settings". Zen theme would not be less configurable if it were by default as beautiful as Garland is…
I'd suggest a good theme propose to reduce automatically image sizes, to switch automatically from several columns to 2 and to 1, to transform automatically tables into lists, to move automatically long menus to the bottom of the page, keeping only the few first items at the top, etc., according to thresholds regarding screen size and, if we can get that information, network speed. These thresholds would be automatically updated by connection to a page in Drupal.org (as modules are, but without human intervention), so that they could follow the evolution of technology, but this threshold automatism should also be "disablable" and the thresholds configurable by the webmaster. Moreover, all automatic reducing features should be one by one configurable by the webmaster. For instance, it's crucial that he can easily choose the few menu items to leave at the top of the page for a small screen. Moreover, the webmaster should be able to rewrite by hand the entire page for such or such device, not from scratch, but form a degradation proposal provided by the theme. There should also be links between versions of a same content.
And I think, for a website designed for desktop and smaller devices, it's better to design first for the desktop, because degrading the design can be done automatically, but the opposite is nearly impossible: no way to get a good one-million pixels photo from a 10 000 pixels photo.
The maxim "good devices are
The maxim "good devices are entirely automatic" is something we're trying to live by - I agree, for the majority automatic defaults that require no thought and just "work" are what we need. Not many Drupal users want or should need to build separate mobile websites, their view is, increasingly, that their sites should look fine in mobile devices out of the box.
Some things I think we need to support, and can, all plans coming to fruition:
These things would be mostly automatic, although the image presets need to be configurable.
Some of the other features such as menu splicing and table-to-list transforms are not impossible, just quite difficult. Not sure those ideas are right for core, certainly be interesting to see something like this in contrib.
Where is Drupal 7.2?
Thank you. But you forgot to answer my 1st question: is there already any possible content adaptation in Drupal 7.2, except within the internationalisation module?
Drupal has disadvantages (notably, it's horrible to install), its best known advantage, and the reason why Fiable.biz chose it, being it is highly configurable. I hope we'll not lose this in an adaptive theme. In my opinion, it's important that the webmaster can modify or rewrite by hand the mobile version of any page if he wishes to.
The answer to your first
The answer to your first question is - it depends. For example its entirely possible to do responsive images (flexible images with %) that scale with the size of the browser. Its relatively easy to build a responsive design and make it work using media queries or adapt.js. The difficult thing is pushing pre-scaled images (a preset) base on device or browser size - that is what we cannot to in Drupal core at the moment, and there is only one contrib module that uses the Filament group concept that can do it. Of course if you are not using images then you have no issues.
We're not talking about taking any features away from Drupal - I understand your concern about reducing Drupals flexiblity by doing silly things in the theme layer - I am highly aware of this.
This is something different, you're talking about dedicated mobile site or version of the site - that is something more advanced, for those with the time, money or expertise to have such a thing (and of course the need), what I'm talking about is the 90% of people who have none of those things and just want their site to work in mobile devices, without any special effort at all - in which case the responsive/adaptive approach appears to be an excellent fit.
Links
Thank you very much Jeff. You wrote:
Do you just mean the size of the image is adapted browser side thanks to CSS? Is there a module enabling a redactor who doesn't know CSS to do so for the pictures he uploads? Or do you mean an adaptation made server side?
You also wrote:
These techniques too are adaptations done client side, so they are OK for visual aspect, but do no good for the bandwith, do they?
Two links describing media queries, for future readers of this thread: Responsive Web Design by Ethan Marcotte, and CSS 3 media queries candidate recommendation, by the W3C.
The module "that uses the Filament group concept" you mentioned is Responsive Images, which is a good piece of news, though still in beta version.
Do you just mean the size of
Its done client side, however we have to send the dimensions of the containing element (e.g. a DIV), an image with width: 100%; will do exactly that - expand (or shrink) to 100% of its containing element. This is the tricky part - that container itself must have its width set in percentages, not so tricky if you are building one specialized theme for a particular site, but quite problematic for a generic theme or base theme for Drupal.
Correct, all done client side and make no impact on bandwidth. This is the essential problem to solve - how to push different image sizes to different clients to reduce bandwidth.
Hello, I've got a responsive,
Hello, I've got a responsive, flexible grid theme for one of my clients and I have found the combination of imagecache with the img max-width: 100% trick works well... browsers get the sized down image from imagecache and the css rule overrides the pixel width when applicable. Of course, my site is still in drupal 6, and it is a custom theme, not a base theme, but this approach is working nicely for me.
The concept of setting up something like this for a base theme is certainly interesting!
-- Julia v.
http://www.pfvdw.com
The first thing to go: Position Named Regions?
I was thinking about this last night, and I think one of the first things to go, may be the concept of menus in sidebars at all. Not that the constructs would go away, but that names like "left sidebar" and "right sidebar" would be a thing of the past? These are just different layouts of the same content, yes?
Has anyone experimented with concepts like mobile slideshow based navigation within a theme? What I'm thinking is that the device might load the whole page, but provide navigation to differing components with a main nav menu and then scroll left/right actions. Kind of like thinking of each page as jquery slideshow of each region in the page, that could auto transition based on a timer but would then allow "click" navigation as well?
If you think of the "sequenced" of presentation of your web site, it also helps with screen reading accessibility issues as well?
This could be a fun theme/contrib to build.
One project that has yet to
One project that has yet to be mentioned is Drupal Omega 3.x Base theme http://drupal.org/project/omega. Over the last couple of months, great stride has been made to create a truly responsive base theme. Why reinvent the wheel-take a look at what has already been achieved and apply it to this discussion.
...
Its too early to be thinking about implementation, its highly likely Drupal 8 is going to bring in new ideas and concepts with regards to block handling and page layout, and over time the whole responsive concept will evolve, for that reason we want to leave the actual theme building to later in the Drupal 8 development cycle, so these discussion's are more about bootstrapping the process and raising awareness rather than actually deciding on a particular code direction.
That said I'm tracking many projects, the most interesting ones are about truly responsive images, just as JohnAlbins sandbox http://drupal.org/sandbox/johnalbin/1110358
Architecture of the UI
I'm struck by the recent comments that Drupal needs some kind of themable injection point for device recognition, but being a Drupal novice, I'm not sure whether a) it doesn't already exist, and b) where people are currently adding this kind of behavior.
My personal experience with mobile interfaces is a lot of hacking and guessing -- device detection now much like browser detection or Flash detection was a few years ago. Ideally, a good mobile Drupal implementation/core/theme would generalize this to something akin to check boxes for Drupal web masters. But I honestly don't know enough about Drupal's architecture to know where the obstacles are for detection and device oriented theming. (It would majorly suck if we had to create .tpl file overrides for every mobile View.)
Has anyone put together a screencast or webinar on this subject? Such a thing would not only clarify this discussion, but potentially be a nice contribution to the Drupal community.
WURFL
There's a long-running open source project called WURFL that has been doing a great job of mobile device detection.
There are also 2 PHP APIs for that WURFL data. The first, older API is file-based and is what is used in the current WURFL module. The second is a newer database-driven API which is faster.
There's a new discussion in the WURFL module queue on replacing the old API with the new API over at http://drupal.org/node/1183246
- John (JohnAlbin)
I have used the
I have used the http://drupal.org/project/mobile_tools module a few times when building dedicated mobile sites (a separate version of the site only for mobile devices). For example on one project I used the Browscap module + the excellent Domain Access module, and Panels + Views. Browscap does browser detection. I'm not going to say this was perfect but it did the job.
What would be very outstanding is if we could, even via contrib, provide Drupal with device-as-a-context. In the above setup I could get the domain as a context, which is not very useful if you are trying to build a "one domain fits all" sort of thing, although for our purposes it worked very well.
This is all great if we're talking about building a separate mobile site, when there is a case for such a thing, that said in the context of Drupal core themes this would require extensive setup by the site builder (I don't think we're ever going to see device detection in core), so what we are really driving at here is a way to provide a "pretty good" out-of-the-box mobile experience for those with low/no site building skills - which is why I approached this with the "responsive/adaptive approach".
Check out Context Condition Theme
Check out Context Condition Theme; it looks like it's using Context to serve mobile.
Here's what it says:
Best, Marilyn
Help me ................please!
Hi ,
I have created a adaptive mobile site .It run properly but only one thing is missing ,when i run my sub folder it shows header image
but when i run my created mobile site from desktop the header image not display by my mobile site .
Now i don't understand what to do next ?
if anybody knows the answer of that question please give me suggestion.
Thank you,
Nilofar
Not a good assumption
I'd say most people understand the difference between 'local' and 'distant'. It's fundamental to both telephones and the internet. There aren't 'mobile users' and 'desktop users'; but there are plenty of users who own multiple devices and switch between them. An increasing portion of content consumption involves two screens. So I'd argue it's better to design user experiences that perform well across many devices.