Need ideas on responsive design for group of mobile devices

Hi guys,

My web site project is almost finished and I'm thinking of making it mobile-friendly for a set of devices ranging from iPhone 4 to 14-inches laptop.

Since there are too many devices out there I would group them into 4 to 5 inches, 5 to 7 inches, 7 to10 inches and 10 to 14 inches kind of thing.

So what is the best bet to make my site rendered silkily smooth on any devices.

- First things first

• I would use the code below to eliminate 300ms mobile loading latency on Chrome:

<meta name="viewport" content="width=device-width,initial-scale=1,minimum-scale=1,user-scalable=no">

Code (markup):

so, users may not be able to zoom in or enlarge text, which is not quite my concern, due to most of it kind use fixed size (it's multimedia-messaging web site--snapchat kind of thing--with video and audio features).

Question is, what is the best practice idealistically making the web site fit to all mobile devices like those native apps.

Thank in advances,

 

First, STOP screwing with values there is NO legitimate reason to be screwing with in that viewport META; set "width=device-width,height=device-height,initial-scale=1" and be done with it. I don't know what 300ms 'latency' you're thinking of or what makes you think that would remove it... but that's just pissing away functionality.

Second, STOP thinking fixed width -- make the video or images or what have you scale with max-width when the device is too small for them, that's realistically about all you can do reliably.

Third, STOP thinking "devices" and think the needs of the CONTENT. Start out with a non-media query desktop layout (I realize that's backwards from the 'mobile first' asshattery, but again to me that's NOT the lowest common denominator!) and make it narrower until it breaks -- when it breaks, there's your breakpoint for a media query to re-arrange things. Lather, rinse, repeat until you hit 192px wide, the narrowest you are likely to encounter on a real device.

IF you are thinking physical size of devices, you're doing it all wrong. If you are thinking specific pixel widths for your media queries (other than a 192px min-width when queries are working), you're doing it all wrong. Even making the distinction between "mobile" and "desktop" is doing it all wrong as you are then designing your content to the devices instead of having the layout adjust to the needs of the content within the capabilities of the device.

To that end, since like a good little doobie you should be using EM's or fonts, your break-points should be declared in EM's... again, GOOD layouts aren't just responsive, they're also dynamic, elastic and semi-fluid. Dicking around with fixed sizes is the road to failure, and ANYONE telling you otherwise is so full of **** you'd think they were the back-end of the centipede with someone yelling "Feed her, feed her" at the one in the middle.

 

Hi, thank you for suggestions.

I'd like to discuss about this a little bit if you don't mind.

First off I begin with the code you have suggested on this thread: https://forums.digitalpoint.com/thr...tching-page-width-on-mobile-any-help.2701673/

Here's it again:

body {
    font:normal 85%/150% arial,helvetica,sans-serif;
}

#pageWrapper {
    min-width:40em;
    max-width:68em;
    width:95%;
    margin:0 auto;
}

Code (markup):

It works great. But how do I make sure that the em have the same behavior on different devices. Are they rendered the exact look on different devices.

Let's break it into pieces, for device like the iPhone which is 320px width and old Samsung Galaxy model which is 350px width. Is the code above a panacea for those different width.

I'm looking for one code fits it all (for group of devices). Sorry if this is stupid idea, there is no way to know that I'm wrong if I don't make mistake.

The idea come from here: http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away

They said there are 300ms page-load delay on touch-base devices. The code is widely used by Google engineers and they are influenced me.

Why this is bad? I don't really know about it. Can you tell me more a little bit?

Agree, I've just finished the first phase of design.

Does this mean I have to target every device I can think of? As I asked above, can I just grouping them?

What does this mean, can you be specific and give sample codes.

Thanks,

 

You... don't... if you are thinking "the same on different devices" you aren't designing right or thinking right. Different devices are different, your page should be adjusting to that difference.

Assuming both have the same default font size, the above... well, that min-width would screw you over which is why you turn that OFF (or more specifically down to 192px) with a media query. Once that is done, the one with more pixels would show more text on a line and wrap everything differently so as to best make use of the available space.

It really hinges on what you mean by that. If you mean code that auto-adjusts the layout changing how much text is shown per line and shrinking images to fit, then sure... if you want the exact same layout and appearance on all devices you are COMPLETELY missing the point of responsive design.

That is there so that attempts at scrolling or other gestures aren't mistaken for a click... so turning that off is, well... really shortsighted and stupid. NOT that "google engineers" would ever piss all over functionality in shortsightedness and/or ignorance. (looks at how Google search has a less useful UI than it did a decade ago)

You're breaking zoom -- one of the core bits of functionality and accessibility... for NO reason since initial-scale is in 99.9999% of cases all you really want. Don't screw over potential users by using values that probably shouldn't even exist in the first place. Though honestly mobile browser makers wouldn't have their browsers screwing us developers over forcing us to use those META if more developers pulled their heads out of 1997's backside!

Again, stop thinking by device. Think about when/where the content breaks and use that for your "@media (min-width" values when making it responsive. Usually that's only two or three media queries averaging a quarter k of code apiece.

dynamic -- using EM's for fonts so that it's based on the OS or browser default, which users (like myself) do change so we don't have to dive for the zoom if the site was PROPERLY developed... this is as opposed to declaring fonts in pixels which leaves users like myself diving for the zoom.

elastic -- using EM's for your width, min-width and max-width declarations so that if that default font size is different, the layout auto-enlarges/contracts to fit those fonts.

semi-fluid -- having a minimum and maximum width that the whole layout (typically the center column) can expand and contract between. Usually the max-width is so that really long lines of text don't get hard to follow, while min-width is declared for non media-query capable browsers so the layout doesn't break/become hard to use when the screen is too narrow. You then unset that min-width in your first/widest media query so that it can go narrower as you re-arrange the layout stripping off things like columns and re-arranging other elements to fit the available space.

Take this site of mine as an example:
http://www.ewiusb.com/

I started out with semantic markup of my content, so that non-visual user agents (screen readers, braille readers, search engines) still get something useful -- which is why what "search" would see is basically this:
http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNoCSS.jpg

Also handy if you are stuck on something like Lynx or an older system where CSS support is incomplete.

I always start out with pre media-query design as my starting point, here it is at the "default" 96dpi / 16px most people have at desktop resolution:
http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNormal96.jpg

At 120dpi/20px browser/OS setting, that same layout does this:
http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNormal120.jpg

Notice that the images don't change size, but the text and layout does. Unlike zoom which can make template images look like arse, it leaves those alone.

As the screen gets narrower, so does the content column:
http://www.cutcodedown.com/images/ewiUSB/ewiUsbCom800Wide.jpg

Until at a really narrow width, it strips off the extra column and images that would appear broken:
http://www.cutcodedown.com/images/ewiUSB/ewiUsbCom640wide.jpg

As it uses progressive enhancement for template images, it also gracefully degrades images off even at wider widths:
http://www.cutcodedown.com/images/ewiUSB/ewiUsbCom800WideNoImages.jpg

Even when the page gets down REALLY narrow, it's still functional.
http://www.cutcodedown.com/images/ewiUSB/ewiUsbTinyMobile.jpg

... and that's how I was doing it six years ago. I've actually upped my game since then as that site was still using px for the media queries when I wrote it.

That's what responsive elastic semi-fluid design is about and how accessibility should be done. DIFFERENT layouts off the same content and markup based on how well the content fits the available width.

These days, usually I have two, maybe three sets of media queries after the base layout. Those queries strip off columns, add columns, or just plain re-arrange things to fit -- and those queries are often easy to code because I make the content areas fluid to being with, so they always expand to fit the space made available to them.

See my personal site: http://www.deathshadow.com/

Which does the same basic thing, but in a far smoother manner. (now that I fixed the typo on the media query for the menu).

 

Thank you for your time and reply.

I see it. That's kind of wow!
You don't hide any part when layout breaks while most web sites do and novice developers are being told to. Plus, you reassemble them anywhere at your will while most sites push layout from left to right. So left column always comes on top. Those nav menus break apart as they should be.

That's rare breed, and you do it with few lines of code. I like it. That's what I'm talking about in the first place.

Now I think I've collected enough ideas to begin with.
It's time for coding.

Cheers,