870994 - Get user screen resolution stats

Status: RESOLVED FIXED

(Webmaker Graveyard :: General, defect)

Description

[Dale Karp (:daleee)]

* Keep in mind that since Webmaker tools only work on desktop, we probably only need to support desktop resolutions for some specific pages

Comment 1

[Cassie McDaniel [:cassiemc]]

Attachment: Screen Resolution Jan-May 2013

This is looking at the period from Jan to May 2013.

For desktop, our top 6 categories of visitors have higher than 1024 screen resolution. The vast majority have 1280 or higher. Top browsers are Firefox, Chrome, Safari in that order.

For mobile, most users are on 1024 iPad, with non-retina iPhone and iPod taking the next four spots at 320.

Ideally, this would lead to 3 breakpoints: 1280 desktop, 1024 tablet and mobile 320. It seems we'll have to nix one of these, but I'm concerned about nixing the 1280 as a 1024 experience on desktop will quickly make a design look out-of-date. 

Can we instead scrap the 1024 resolution, if we must scrap one?

Comment 2

[Cassie McDaniel [:cassiemc]]

Attachment: Jan - May 2013 Mobile screen resolution

Comment 3

[Ross Bruniges [:boozeniges]]

There isn't a huge difference between 1024 and 1280 - if we treat the min/max as the breakpoints we're aiming for and have everything in between be responsive and elastic in width we can probably get 80% of the way there for free right?

Comment 4

[Cassie McDaniel [:cassiemc]]

I like this plan. 

I still want to discuss the possibility of packery filling in the entire background with makes, I'm not liking the feeling that the exploratory limits are as narrow as the single column we've defined (be it 1280 or 1024). Jen/Humph mentioned on Friday there may be load time issues, but I think we should try to make it work if we can in order to get the experience I'm really aiming for. Like we have so many people in our community doing so many awesome, different things – why wouldn't you want to be a part of this. Similar UX to http://butdoesitfloat.com/ but tighter columns. I can find more examples if necessary.

This would do away with any concerns I have re. building for smaller res, ie I don't care so much where the main nav and CTAs sit if the rest of the content spreads out.

Only other concern is ensuring the min thumb size is small enough to be reasonable, since we are not letting users upload an image otherwise. Currently it's ~400px, which seems easy for most people, eg. old instagram photos are default ~600px. BUT, Is there anything clever we can do with stretching smaller images to a larger size that doesn't make them look all blown-out or pixelated?

Comment 5

[Jen Fong-Adwent [:ednapiranha]]

No we cannot move to 1280 - it breaks the existing layout of those 3 boxes plus the stamping of the one box. We've already spent a week messing around with the following:

1. trying to make divs fit without gaps in between 
2. using a baseline of 16:9 boxes which does not balance out as nicely as perfect squares do
3. because of #2, this is why we have to tightly control the layout under the assumption of 1020.

I just discussed with Ross and he's been notified of why we have this limitation for the June launch.

Comment 6

[Cassie McDaniel [:cassiemc]]

Understandable, but we should bear in mind one of the main advantages to using Packery was that it creates a beautiful responsive grid. Right now, that grid is confined to 1020 and not so beautiful. Last week was exploration to see if what we have is working and to understand the limitations and capabilities of packery, and we did make progress in that regard. We have not, however, tried filling the whole screen with images, no?

It's my strong opinion that a higher res is worth pushing for, because the current experience is confined to a narrow column and that seems not-so-fresh, not as engaging. I can rework the grid in my psd which should help immensely.

But, we can probably solve this in another way as well, e.g. implementing a full-width photo/banner at the top of the page. http://www.googleventures.com/ Makes the page feel more open.

Perhaps front-end and design can regroup and discuss during today's progress call at 11.

Comment 7

[Ross Bruniges [:boozeniges]]

So I wasn't aware of the discussion that was going on last week - sorry for jumping in.

For the sake of around 200px this doesn't feel like a large enough amount of value added for the short term (thinking June 15th).

Would this be something better to pick up on once everything else we have to make has been completed?

Comment 8

[Cassie McDaniel [:cassiemc]]

No apologies Ross, discussion must be had! Let's talk more at today's call, I'm curious to get Beltzner's input, I think you're both probably right. Closing this for now, as we have the user stats.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

A higher res is worth pushing for is a great way of putting things, and also helps with the prioritization of this work: it's not a "must have for June 15th" thing, and very much a "future optimization"

My take is this: let's stick to what we've got (which everyone agreed was awesome) and work through our other outstanding design and implementation issues, and then loop back to this when they're all sorted, yeah?

Comment 10

[Cassie McDaniel [:cassiemc]]

Just adding Gavin and Dale to this, as it's the only real formal place we captured stats from users re. browser compatibility.