Design For The Web, Not The Device.md

1. Screen width/size: Just because my viewport is 960px wide, doesn't mean I'm on an iPad, tablet, etc. My desktop, as well as the majority of laptops today, are 1920px wide. 1920 / 2 = 960, which fits two browser windows, side by side, very nicely. I hate having to use hamburger/hotdog menus, when "normal" navigation would work just fine on both mobile & desktop. Lets not handicap users, just because we make assumptions about the device they are on.

2. Device agnostic: Rather than mobile vs desktop, it's becoming a point that we need to design for The Web, not devices. The Web is not just phones, tablets, and desktops. It's also screen readers, TVs, embedded devices, etc. Also, we don't know what's coming next.

3. Input types: There are a variety of devices today that support a variety of inputs. With just these three input types -- touch, mouse, keyboard -- we need to account for 27 different input combinations. And there may be others we haven't accounted for. My little Andriod phone supports mouse, keyboard, and touch. Don't make assumptions about what my device can/can't do.

4. Internet Connection: We don't know the users connection to the internet. Why dump a framework, images, content, -- meant for the desktop -- on the little phone?

There should also be always possibility to use the full desktop view from mobile device. I absolutely hate it when some sites force me to use a crippled mobile view when I could easily use the full desktop view on my iphone.

Screen width/size:

I think this brings up a very good point, and something I've been trying to think about possible ways of fixing, or addressing, and so far haven't been able to come up with anything.

Some questions:

1. If we don't design towards screen size, then is there something we can design towards that would accomplish the goal?
   For instance, on smaller devices, we do need things to be larger, and more targetable for a finger (with the assumption that the small device has touch capability, but larger hit areas benefit small devices with a stylus as well).
2. Is the problem you're mentioning one of the strategy or the design itself? What I mean is, is the problem you're having with your side-by-side windows because of targeting the design towards device size, or because the design for those smaller sizes are so different? Could there be a happy medium where the large design wasn't so drastically different, but instead an augmented or upgraded version of the small screen?

Device agnostic: Rather than mobile vs desktop, it's becoming a point that we need to design for The Web, not devices.

This is a catchy line, except I don't think it really means anything. That prescription, while I agree in spirit, isn't actually prescribing anything. It's telling us not to design for screen sizes, because some imaginary watch phone is coming out, but it doesn't really tell you then how to target your design.
"The Web" (at least in the way you're describing, and the way used by tvs, embedded devices, native apps, etc) is much more than any one specific UI, it's about data end-points, HTTP and REST.
The UI for each of those is completely different (as they should be).
But I think the discussion we're trying to reach is design for the web as viewed through a browser.
Device size is really the only metric we have to determine "mobile" or not, unless there's something else that works better that I'm unaware of (and that's a complete possibility as well).

Input types:

I agree that there's a lot of possible interactions. But this sounds like another dont do but no following do this instead.
If there are no clear right directions, then it's a matter of choosing the less evil, and most common case. Sure your Android phone supports all of those scenarios, but if I have no way of determining from my end which of those capabilities you prefer using, what's the most likely scenario that you'll be using it for.

My gut feeling tells me the device/platform vendor added those features to check something off a feature list, and that if you've used them, it's to test them out, and that keyboard and mouse are almost never used.
I could be completely wrong, but I have yet to see anybody walk around with a keyboard and mouse to use with their phone :)

Internet Connection:

Again, I completely agree. In fact, the point behind mobile first is because of this. Part of our plan is to minimize the amount needed up front and load everything else on demand.
However, there's not a lot we can determine apart from device size and touch capabilities for loading those elements.
Unless there is some more clever way to handle this.

Sorry if all of that came off as more aggressive or overbearing than I intentioned. I think in spirit I do agree with a lot of what you're saying, but I think until the tools catch up with everything we wish to create, but at the same time, I think we should also be pragmatic with solving the pain points we can with the tools we have.

I do look forward to your feedback :)

Thanks Byran!

@mikakoivisto:
Why do you hate it? For me, the most common reason is because of poor decisions to hide content on mobile devices by the designer or site creator.
But if all of the same content is accessible, is there really a need to switch to a "desktop" view?

Alone the lines of Mika's comments. Go to Slashot.org (redirected to m.slashdot.org) on a phone. This is an example of bad horrible execution. Luckily, the site respects Chrome's request for the desktop version. The desktop version works fine minus the width, and actually performs better. They could have easily worked around the width issue, but no, they went all mobile on us.

Okay, so if I could sum up, you're not opposed to Mobile First design necessarily (or RWD), but more or less dedicated mobile sites?

I was just contributing to Mika's comment. I thought I posted my reply, I must have forgot to press send. I hope it's still on my laptop.

About Responsive vs dedicated site, this could lead to flame. There will be also pros and cons and there will be always people who prefer one of another.
Something we tried a few years ago was to allow user to choose "Desktop" version explicitly even if the site was created with Responsive design in mind. What we did this time was to serve different CSS from the server. On practice, we just removed (on the server) the media queries among with their related CSS which applied to mobile devices (or small screens if you prefer). In this case the server served only CSS for "Desktop".
We may try to achieve the same in Liferay?

If we don't design towards screen size, then is there something we can design towards that would accomplish the goal?

I say, do design for screen size, just don't assume that means I'm on a touch device. We can test for touch. But again, don't assume I'm going to use touch. I'll...touch on that below. Get it, touch? Ha ha h..

...is the problem you're having with your side-by-side windows because of targeting the design towards device size, or because the design for those smaller sizes are so different? Could there be a happy medium where the large design wasn't so drastically different, but instead an augmented or upgraded version of the small screen?

Probably the drastic change and the assumption that the device is small. If we had used a "transitional" navigation, rather than going straight to hamburger. It would have been nicer.

This is a catchy line, except I don't think it really means anything. That prescription, while I agree in spirit, isn't actually prescribing anything. It's telling us not to design for screen sizes, because some imaginary watch phone is coming out, but it doesn't really tell you then how to target your design.

It's telling me to be flexible, not make assumptions about the device, to not target the device. I'd imply that we should target features instead.

"The Web" (at least in the way you're describing, and the way used by tvs, embedded devices, native apps, etc) is much more than any one specific UI, it's about data end-points, HTTP and REST.

I understand that "The Web" is more than UI. What I mean is "The Web" as a display medium, that fits into little boxes we call devices. I don't think we should design for those boxes, besides width and some hints as to the input being used.

Device size is really the only metric we have to determine "mobile" or not, unless there's something else that works better that I'm unaware of (and that's a complete possibility as well).

I don't think we should consider any device mobile or not. But rather: What's you current viewport? Do you support touch? It looks like you're using a mouse (see idea below). etc.

Sure your Android phone supports all of those scenarios, but if I have no way of determining from my end which of those capabilities you prefer using, what's the most likely scenario that you'll be using it for.

I was thinking of this, but I'm not sure if it's practical. The idea is: If it supports touch, assume that's the preferred input. But, if we detect mouse moves, not associated with touch events, it's a good chance they are using a mouse. I'm not sure if this is practical.

My gut feeling tells me the device/platform vendor added those features to check something off a feature list, and that if you've used them, it's to test them out, and that keyboard and mouse are almost never used.
I could be completely wrong, but I have yet to see anybody walk around with a keyboard and mouse to use with their phone :)

Correct, I don't use those features. It's just an example of: "Surprise! I support this. Now, why can't I use it on your site?" I understand that it's an edge case. But we really should consider these things, now that more devices like Chromebooks, MS Surface, etc. begin to get more use.

There's a Raspberry Pi project aimed at bringing inexpensive Android Desktops to the consumer/retail level. I don't think we should design for these, but we shouldn't get in these user's way either.

...I think we should also be pragmatic with solving the pain points we can with the tools we have.

I agree. This is a little dreamy, but I'd like to try.

Salads (HTML) are healthy (responsive, accessible, fast)...and then we add dressing (CSS, JS). But, the Salad is boring by itself.

-Me

To revise my early comments about Slashdot; It's not the dedicated mobile site that bothered me, it was the:

You ruined a perfectly fine site, because you "optimized" it for mobile.

@ipeychev:
That's actually a very interesting approach, and one I hadn't thought out. There's only one possible downside I can think of to it:
with mobile first, I would think it would be a bit tougher to pull off, since you're adding media queries to create the desktop experience, not the other way around.
So you guys were stripping out media queries for the desktop view, but for mobile first, we would need to be adding them in, which becomes a little tougher (though technically, I suppose we could find some way to identify desktop media queries, and transform them on the server side).

@blzaugg:
I think overall, we're in agreement about the goal. I agree that we should design towards features as much as possible, in the same way that we should be developing on the client side for features.

I think the tough part of balancing this out is the tradeoff of practicality, performance and best practices.

For example, many of the features you're mentioning, such as touch, mouse events, etc, are only accessible via JS, but not via CSS.

Projects like Modernizr try to emulate that, but then you have 2 issues with that: 1. CSS layout that's based upon the JS running, and 2. Performance (all of those feature tests aren't cheap).

Ideally, we'd be able to know from all layers of the web stack what features a device supports, but right now it's a bunch of cobbling together of hacks, inferences and work arounds.

My worry with relying too much on a Modernizr style system is the FOUC that can often happen if the code is loaded asynchronously, or a performance hit as it runs the tests and locks the page.
Some basic tests may be required though, and there's no way around it.

But others are a bit tougher.

So to sum up, I think we agree in principle, and maybe are hazy around the edges of implementation.

Thanks for your input Byran :)