752473 - [Responsive Mode] we need a decent list of presets

Status: RESOLVED WONTFIX

(DevTools :: General, defect)

Description

[Paul Rouget [:paul]]

A preset is defined by:
{
 width,
 height,
 description,
 type
 canRotate
}

Type and description are optional.
Type is "mobile", "tablet", "computer" or "unknown".
canRotate is a boolean.

The definition can be updated if we need more details, or if one these characteristic appears to be useless.

Comment 1

[Kevin Dangoor]

If we're collecting up this info now, does it make sense to also include dpi or any other physical size measurements?

Comment 2

[Paul Rouget [:paul]]

(In reply to Kevin Dangoor from comment #1)
> If we're collecting up this info now, does it make sense to also include dpi
> or any other physical size measurements?

Yes. It might help in the future. What I have listed in comment 0 is what we need today. I don't know what else might be relevant, but feel free to add any data you think might help.

This will be stored as a JSON file.

Comment 3

[Kevin Dangoor]

Attachment: Proposed initial presets

After considering the most popular devices on the market and a desire to have a usable list (plus an option for custom size, of course), I have attached a proposed list of 7 presets.

1. feature phone
2. smartphone
3. iPhone
4. tablet
5. standard desktop
6. large desktop
7. iPad (3rd generation)

Irina pointed out separately in email that we might want to drop the "canRotate" field, because so many devices can rotate these days and there is no real harm in giving people the ability to swap width and height if they want.

Also, I'll note that we have not dealt with pixels per inch at all. Things get a lot more complicated, both in terms of variety of devices and in terms of making the feature useful for developers that are targeting devices of different display densities. ppi is for a later iteration of the feature.

Comment 4

[Kevin Dangoor]

Attachment: Proposed initial presets

Switched the use of (R) character to the cleaner "Apple iPhone" format.

Comment 5

[Kevin Dangoor]

Attachment: Proposed list of presets 3

Adding another preset to cover a specific style of phone.

Comment 6

[Paul Rouget [:paul]]

The dimensions we should expose are not the dimensions of the devices, but the dimensions of the browsers.

On mobile browsers, the dimensions of the layout viewport depend on different things (but not on the device resolutions, at least, not directly).

Here are the 2 situations we should consider:
- HTML5 page with no viewport defined (fall back to the default viewport)
- HTML5 page with viewport width set to device-width

The exposed device-width is a lie (because of historical reasons). And this is helping, because browsers lie in a consistent way.

For Apple devices, we will get those values easily.
For Android devices, sizes depend on:
- android version (4 or not 4)
- browser (stock, Firefox and Chrome seem to behave the same way. Opera has different values, but it's consistent)
- device type (tablets vs. phone)
- orientation (landscape / portrait)

The device-width has some consistency: 1280/800 & 640/360. Apparently, 320 is also used.
The fallback viewport seems to be always 980 (1280 ONLY after a rotation for stock) on ICS.

More info to come (with more devices data)!

PS: here, I NEVER mention height. The alternate values (like in xx/yy) is the width in landscape mode. I think we should NOT expose presets for the height.

Comment 7

[Paul Rouget [:paul]]

All the Apple devices also expose 980 as a fallback viewport.
For device-width, iPhones expose 320/480, and iPads (2 & 3) expose: 768/1024.

I'll add some more data from a Froyo and a Gingerbread device, and then we will be able to come to a good list.

Comment 8

[Paul Rouget [:paul]]

B2G will expose a 320/480 resolution as well.

Comment 9

[Kevin Dangoor]

(In reply to Paul Rouget [:paul] from comment #6)
> The dimensions we should expose are not the dimensions of the devices, but
> the dimensions of the browsers.
> 
> On mobile browsers, the dimensions of the layout viewport depend on
> different things (but not on the device resolutions, at least, not directly).

true

> PS: here, I NEVER mention height. The alternate values (like in xx/yy) is
> the width in landscape mode. I think we should NOT expose presets for the
> height.

true, but it seems like there will be an expectation of an aspect ratio for the view when the user switches between the presets.

Comment 10

[Paul Rouget [:paul]]

What about:

let presets =  [
  {width: 980, height: 1280},   // Default width for mobile browsers, no <meta viewport>

  // Phones
  {width: 320, height: 480},    // iPhone, B2G, with <meta viewport>
  {width: 360, height: 640},    // Android 4, phones, with <meta viewport>

  // Tablets
  {width: 768, height: 1024},   // iPad, with <meta viewport>
  {width: 800, height: 1280},   // Android 4, Tablet, with <meta viewport>


  // Computer
  {width: 1280, height: 600},
  {width: 1920, height: 900},
];

Android < 4 is missing. I'll test on my nexus one today.

I am not sure about the first one (980). Should we include that? I believe that if the user cares about responsive design, he will use the viewport meta tag.

Comment 11

[Paul Rouget [:paul]]

Android 2.* basically behaves like an iPhone (320).

Comment 12

[Paul Rouget [:paul]]

Exposed device-width (portrait/landscape) for stock browsers, Opera, Chrome, and Firefox, on Android and Apple devices:

Phones:
- iPhones (1,2,3,4,4s): 320/480
- Android Phones 2.*:   320/480
- Android Phones (4+):  360/640

Tablets:
- Android Tablets (4+): 800/1280 (Opera: 640/1024)
- iPads (1,2,3):        768/1024

For Android, this is a "generalization" as some devices have some specific resolutions (Samsung Note for example).

Comment 13

[Paul Rouget [:paul]]

Menu layout:

1. Custom, width x height

2. Smartphone
  a. portrait: 320, landscape: 480 (iPhones, Androids)
  b. portrait: 360, landscape: 640 (Android)

3. Tablets
  a. portrait: 768, landscape: 1024 (iPads)
  b. portrait: 800, landscape: 1280 (Android)

4. Desktop
  a. width: 1280, height: 1024
  b. width: 1920, height: 1080

Comment 14

[Kevin Dangoor]

That looks good to me and should cover the common cases that I've seen.

Comment 15

[Paul Rouget [:paul]]

Attachment: patch v0.1

WIP

Comment 16

[Paul Rouget [:paul]]

Attachment: patch v0.2

WIP

Comment 17

[Paul Rouget [:paul]]

Kevin, can you re-run the test for the iPad following these instructions:

1) Keep the iPad in portrait mode, load this page: http://jsbin.com/eyecap/9
   What numbers do you get?
2) Turn the iPad in landscape mode,
   What numbers do you get?
3) Stay in landscape mode. Reload the page.
   What numbers do you get?

Comment 18

[Kevin Dangoor]

(In reply to Paul Rouget [:paul] from comment #17)
> Kevin, can you re-run the test for the iPad following these instructions:

using iPad 3

> 1) Keep the iPad in portrait mode, load this page: http://jsbin.com/eyecap/9
>    What numbers do you get?

768x928

> 2) Turn the iPad in landscape mode,
>    What numbers do you get?

1024x672

> 3) Stay in landscape mode. Reload the page.
>    What numbers do you get?

1024x672

Comment 19

[Paul Rouget [:paul]]

tl;dr: we can't come to a comprehensive list of presets. There are too many details the user needs to understand. We would also need to add some help to explain how to "reproduce" these values (get the viewport "right"). Also, the "height" is not something we can expose easily. At the end of this comment, I explain what I think we can do.

The current approach is not really going to work.
We want to keep the list small, and simple to understand.
But I think it's impossible.

The list needs to be huge and complex, or it will be inaccurate and misleading.

Let me explain.
Let's look at the iPad.

4 common situations:
- If the user uses: "width=device-width", what ever the orientation is, the width doesn't change (768), but of course, the height changes a lot (504 and 928).
- If the user uses: "width=device-width,initial-scale=1,user-scalable=no,maximum-scale=1", the width depends on the orientation of the device (768 and 1024). And the height too.
- If the user introduces "height=device-height", we always get 768 for the width, but the height will change depending on the initial-scale.
- for a page with no viewport, the width is 980.

If you add to that the fact the the "chrome" of the browser can have different sizes, it makes the "height" unpredictable.
We _can't_ expose any height.

We can expose just a set of width depending on the orientation. The iPad, depending on the viewport, has 5 possible "width":
831, 980, 768, 1024, 1520.

We could reduce this to 768 and 1024, which are the most probable cases (if the user use a viewport and doesn't set device-height with no device-width).

So we need a UI that would propose these 2 "width". But we need to make sure the user won't mix-up the 2nd "width" with the "height".

That is why I came with this notation: "portrait: 768, landscape: 1024 (iPad)" in comment 13.

But the generalization here goes too far. This needs more context and explanation. We can't just say the iPad is "768x1024". We are assuming a lot of things already, and the notation will be confusing.

The analyze here is for the iPad.

For Android, we run into more mess:
- there are different browsers, and they expose different values, they have different chrome sizes.
- there are different devices that have other values of device-width
- device-width in mode A changes if the page has loaded in mode A or mode B (before a rotation)

About the list in comment 13.

It's misleading:
1) people will think the second value is the height
2) we don't know what we should use as the height value (keep the current one?)
3) there is a high probability that people will see a different result on their tablet
4) we assume people understand viewport. And I believe people don't (I though I did last week)

Here are some options:
1) we don't expose any preset
2) we don't have a menu, but 4 buttons, horizontally aligned:
  - mobile (on click, we resize to 320x480)
  - tablet (on click, we resize to 768x1024)
  - desktop (on click, we resize to 1280x768)
  - a question mark (on click, we explain the viewport mess, and also we say to be careful about these static values, and that one should implement a fluid design)
3) we parse the viewport meta tag, and do some magic to guess what resolution we should use
4) we don't let the user control the height at all, and we use a slider with "magnetic points" for all the width values that he can run into
5) we just come with a list of 5 or 6 "unlabelled" (no words) width values (a single value per menuitem)

I'd prefer 1) or 5).

Comment 20

[Joe Walker [:jwalker]]

(In reply to Paul Rouget [:paul] from comment #19)
> ...
>
> Here are some options:
> 1) we don't expose any preset
> 2) we don't have a menu, but 4 buttons, horizontally aligned:
>   - mobile (on click, we resize to 320x480)
>   - tablet (on click, we resize to 768x1024)
>   - desktop (on click, we resize to 1280x768)
>   - a question mark (on click, we explain the viewport mess, and also we say
> to be careful about these static values, and that one should implement a
> fluid design)
> 3) we parse the viewport meta tag, and do some magic to guess what
> resolution we should use
> 4) we don't let the user control the height at all, and we use a slider with
> "magnetic points" for all the width values that he can run into
> 5) we just come with a list of 5 or 6 "unlabelled" (no words) width values
> (a single value per menuitem)
> 
> I'd prefer 1) or 5).

Excellent analysis, thanks.

I think a key way we can make our tools better is to explain the 'why' to the user more than we do. It's not that the explanations are not 'out there somewhere', but they're rarely to hand when the user needs them.

Also both option 1 and 5 are indistinguishable in the users eyes from us not really being that bothered. So perhaps we could have #5 with an option which explains things? (like the ? in #2)

It's possible that we could also have a command that handled the complexity, without any UI noise:
>> viewport ipad
  Output: "Assuming iPad running Safari held in Portrait = 768x1024 for your width settings"
  Action: Resize to 768x1024

>> viewport s2 firefox landscape
  Output: "Assuming Samsung Galaxy S2 running Firefox held in Landscape = 800x480 ..."
  Action Resize to 800x480

I'm assuming that there are 4 variables - the device, the browser, the orientation and the page settings, and we only need the user to tell us the first 3. Did I miss anything?

I'm not saying such a command would be easy, but I think it could be a help to the user.

Comment 21

[Paul Rouget [:paul]]

Adding an "help" or "about" links/menuitem/button sounds, indeed, important here. I agree.

A viewport command that parses the current viewport to resize the page sounds like a good idea, but very tricky to implement. We will have to maintain a database of devices and browsers per devices. Here is a table that "summarize" the situation: http://tripleodeon.com/wp-content/uploads/2011/12/table.html (and this is far from being exhaustive, and I think we only want window.inner* here). But this is not about responsive design anymore, but a mobile simulator.

Both can be done later.

Comment 22

[Paul Rouget [:paul]]

What if we just have a textbox with the width and the height? Just that.

Comment 23

[Kevin Dangoor]

Paul: Thank you for working through these details!

What I like about option 2 in comment 19 is that it feels more like a rough approximation (which is exactly what it is).

Here's are three responsive design examples:

http://twitter.github.com/bootstrap/
http://hicksdesign.co.uk/journal/
http://bostonglobe.com/

In all three cases, having those proposed buttons makes it quick to get an idea of what the site looks like on my mobile devices. While I could do the same thing by typing into text boxes or grabbing the resize handle, it's just more convenient to have buttons that approximate those devices.

I think that having a ? that takes the user to a page (on MDN, I'd assume?) with all of those details would be valuable, regardless of the final choice here.

So, my vote would be for option 2, possibly with textboxes for width and height as well (in case the user wants to check things right around the boundaries of their media queries and such).

Comment 24

[Paul Rouget [:paul]]

I think we need someone from UX to help us here.

But I don't want to block the release of the tool because of that.
I suggest that we work on an intermediate solution in the meantime.
Something good enough to land and pref-on the tool.
I consider the current solution (menulist with sizes) being a not-too-bad-intermediate solution.
This work (and discussion) will happen in bug 751910.

Comment 25

[Kevin Dangoor]

(In reply to Paul Rouget [:paul] from comment #24)
> I think we need someone from UX to help us here.
> 
> But I don't want to block the release of the tool because of that.
> I suggest that we work on an intermediate solution in the meantime.
> Something good enough to land and pref-on the tool.
> I consider the current solution (menulist with sizes) being a
> not-too-bad-intermediate solution.

Agreed.

Comment 26

[hsablonniere]

Excellent research work Paul.

I agree on the pref-on with menulist with sizes!

Like I said in bug 751910, I really think zoom is needed.

About the custom size, a resize handle should be the next priority. I use my responsive tool everyday at work. Apart from the preset, finding breakpoints is what I use the most.

Comment 27

[Paul Rouget [:paul]]

(In reply to hsablonniere from comment #26)
> Excellent research work Paul.
> 
> I agree on the pref-on with menulist with sizes!
> 
> Like I said in bug 751910, I really think zoom is needed.
> 
> About the custom size, a resize handle should be the next priority. I use my
> responsive tool everyday at work. Apart from the preset, finding breakpoints
> is what I use the most.

There is a resize handle already. Two actually.

Comment 28

[hsablonniere]

My mistake. I forgot that.

Comment 29

[Rob Campbell [:rc] (:robcee)]

Really nice analysis, Paul.

The menulist with sizes is probably a good enough option. I would suggest including some different aspect ratios. The Samsung Galaxy Tab 10.1 are 16:10 (1280x800).

I guess it's a thing we can add to if needed.

Comment 30

[Paul Rouget [:paul]]

I believe that the current approach is the right one.