Screen Size for Mobile

When Mobile browsers first came along the content on the Web wasn't designed for narrow small
screen devices. It was designed for Windows that were around 1,000 pixels wide and wider than they
were tall with easy scrolling. To show this content into a tiny Mobile screen since rendering a Web
Page designed for 1,000 pixels across and a 320 pixel wide screen would mean you'd be scrolling a
lot. Mobile browsers basically lied about the Window width.

They made the Window act as if it were 980 pixels wide, even though the original iPhone was only
320 pixels across. This enabled sites that were designed for a 1024 by 768 screen, that is, that were
around 980 pixels wide to fit on the Mobile screen. Although you needed to do a lot of Zooming to
read the text sometimes. Unfortunately if your site did not happen to match that 980 pixel width you
were either going to overflow or underflow the screen.
Screen Size for Mobile

Either wasting space or forcing the User to Zoom. In order to control this, Apple provided a viewport
meta tag to be added to your HTML to control the default. For how big should my screen act on this
page? The default is 980 pixels. So, if you put 980 pixels here, it would have no effect. The Mobile
browser already defaults to 980. But setting a viewport tells the browser how wide the content is
intended to be, and then the browser scales to make that size fit on the device's screen. There are
two ways to use this tag.
Screen Size for Mobile

• The first way lets us take a page that was designed to be precisely one size. This is an application I
built that's using a fixed layout, and it's a bit smaller than default. It's 916 pixels wide. Notice that it's
not using all the space on the screen because the browser by default is assuming the
• layout wants to be 980 pixels wide.

• So let's a viewport that tells the browser it was designed for 916 pixels across. What would you put
in the viewport to tell the browser that this should be 916 pixels?

• Now the mobile browser will automatically scale that width to fit on the screen, no matter what size
screen the user has, or whatever device width the user has.
Fixed Width

Let us take a page that was designed to be precisely one size. This is an application I built that's
using a fixed layout, and it's a bit smaller than default. It's 916 pixels wide. Notice that it's not using all
the space on the screen because the browser by default is assuming the layout wants to be 980
pixels wide.

• Before tablets and mobile phones, web pages were designed only for computer screens, and it was
common for web pages to have a static design and a fixed size.

• Then, when we started surfing the internet using tablets and mobile phones, fixed size web pages
were too large to fit the viewport. To fix this, browsers on those devices scaled down the entire web
page to fit the screen.
Fixed Width
This was not perfect!! But a quick fix. So let's a viewport that tells the browser
it was designed for 916 pixels across. What would you put in the viewport to
tell the browser that this should be 916 pixels?

The viewport is the user's visible area of a web page. The viewport varies with
the device, and will be smaller on a mobile phone than on a computer screen.

Now the mobile browser will automatically scale that width to fit on the screen,
no matter what size screen the user has, or whatever device width the user
has.
Rescaling On Devices
Let's take a look at an app given below across a few devices with different
width screens, an iPhone at 640 pixels across and a nexus 7 tablet in
landscape, at double that width 1280 and note that it rescales properly on both
of these devices. Note this takes into account orientation as well.
Rescaling On Devices

The default scaling is to available screen width, so it will properly adjust when you flip the screen.
There's also a height property on viewport which you could use instead of width, to control the
scaling based on the height, but of course, most designs are built as width primary. That is, they're
designed to scroll up and down.
Changing Viewport Settings
Although typically View-port is only being set on Load, you can actually play
around with the View-port settings in the development tools to tweak it, and
get it just right. If I go into the page and set the Viewport meta element
contents from the mobile dev tools It will change the page, as if it had been
refreshed, however, and this is where it gets a bit confusing, the zoom level is
maintained by the browser across pager refreshes, so when you change
viewport settings in the source code, and you're reloading, be sure to actually
close the tab first. Don't just hit reload or it won't necessarily show the effects
on the screen.
Changing Viewport Settings

For example, let's go back to our last bit of code. And change that width to something really different.
Let's double the width to 1832. And now let's save that to the server and reload it on our mobile
device. Our new View-port setting doesn't take effect. On the other hand,

if we close the tab first and then reopen it, our new View-port setting now takes effect. So pro tip,
always remember to close the tab.
Downsides of Fixed Widths
• Your content is almost always going to be scaled.
• Users of some devices will have to zoom.
• Text & UI will look small on a large desktop screen

A fixed width lets you tell the browser what width your webpage was designed
for and the browser will automatically scale that width to fit to the screen no
matter what size screen the user has or what device width the user has. Now
what would be some of the downsides or side effects of using a fixed width view
port?

It is true, that using effects with viewport, means that your content, is almost
always going to be scaled, and not match the native resolution. And definitely, in
some cases, users are going to have to zoom, to be able to see or read
anything, particularly text. Since, everything, all scaled depending on the size of
the screen, fitting the current layout, precisely, into the users screen.
Downsides of Fixed Widths

Whether, it's a four inch phone or a 12 inch tablet, but actually, your text in UI will not change at all on
the desktop. Because, currently, at least, none mobile browsers, don't respond to the view port at all.
In some cases of course, it's the right thing to do, if you just want to get the UI to fit on the screen, to
use, fix with view port, like in my sync app, but of course those dials are awfully small, which makes
the UI very hard to use.
Text Reflow
• Let's talk about how to make truly scalable pages. Now, HTML, by default, is
supposed to reflow text anyway. And text sizes are supposed to be
consistent. But the worst side effect of this viewport stuff, by default, is that,
even with nothing set, the mobile browser is going to reflow text and render
as if the window were 980 pixels wide. And then scale it to fit it on to the
screen.
Text Reflow

This may mean that the text looks really small on my mobile browser by default. So, the second way
to use viewport is if your page knows how to adapt to width. For example, if it knows how to wrap the
contents based on the screen width. You can simply set the width to device width which tells the
browser, my website knows how to adapt to your width. This is really the best approach. To build
applications that scale their own layout and make intelligent decisions about how to do so, rather
than just trying to scale a fixed layout to fit the screen.

<meta name=“viewport” content=“width=device-width”>

So let's try this out on this page. Let's add a device with meta element to a page, and refresh it on the
mobile browser. This is what our page looked like before. Now with the meta tag in place. Let's try
reloading it. And you can see, the page now chooses a better size because it's reflowing at the native
size of the screen.
Other Viewport Controls: Initial Scale

On iOS, if you only set width to device width and you don't set the initial scale, like in this page, when
you rotate the screen the iOS web engine will keep the same view port width and rescale it to fit
across the landscape screen. It's just stretching the portrait layout, to fit, across the landscape width.
Even though I've set width to device width, iOS is still scaling the landscape width.

In fact, the interesting bit is that even if you load this page initially in landscape mode, it still thinks it's
the portrait width, it just rescaling it to fit in the landscape screen. Now, if you have the same page,
but you set the initial scale to 1 in the viewport meta-element along with setting device width, it'll
change the viewport size when you rotate, instead of rescaling. You can see now the window size is
480 pixels across. It's the landscape width, not the portrait width.
Initial Scale
I did want to mention at this point that there are other viewpoint controls.
There's an initial scale property that lets you set what the browser's initial
scaling factor will be. It defaults to one and usually, you don't really want to
mess with it. If you change it to another number, this changes the initial zoom
factor. And the user will probably have to pan or zoom. There is one very
critical use to initial scale though.
Initial Scale

So, in short, this is what you really need to use as your default boiler plate viewport meta-element.
You'll need the initial scale, so that IRS, when flipping from portrait to landscape mode will still scale
correctly. An interesting side note I discovered is that on iphones - Although they are changing the
viewport size properly if an initial scale is that, they are also changing the default font size for the
document and orientation change, effectively zooming up the text when you go to landscape mode.
This means you should probably set a default font size of the page, not just use an percentages. You
may want to use a reset style sheet to do this, if you aren't already.
Fixed VS Device
So really, fixed viewport widths are historical. Resizing by default was an
attempt to shoe horn the desktop web into a mobile device. Fixed viewport
sizes were a quick way to provide some minimal controls on that resizing, with
device whip, gets us back to the same scalable sized canvas that the desktop
web has, so the right way to do fluid flexible design, in the modern mobile web
starts with this tag. This marker let's the browser know your one of the cool
kids and you know what you are doing.

There are also minimum scale and maximum scale properties too. Which is a
way to limit the extents, that the system is allowed to scale the page on the
device. That seems a little esoteric at first, but, there is one use that, I wanted
to mention I don't want, you to think, that I'm biased.
Min and Max Scale

So, after describing how you need to add initial scale, for iOS to work as expected. I wanted to give
equal time, for, Android. If your page, with device width happens to forcibly, overflow the page, like
this page, where I've added an element that's very wide, Android will actually, do some rescaling,
when you change screen orientation, to, try to get the whole page to fit onto the screen. Now,
unfortunately, it gets it wrong, and it tries to zoom it the wrong way.

Now, the only way that I found, to get around this, other than not overflowing the screen to begin
with, is to set the minimum scale and maximum scale properties, to one, which will prevent the user
from zooming altogether. As well as, disabling automatic scaling. Let's do that in the dev tools now.
Now let's try rotating again.
Min and Max Scale

We're back to normal here, and now, you see that even in landscape mode, we get the proper width.
Now, the problem with this, of course, is i can't zoom anymore. We really don't want to disable
zooming, for, your users; this is an accessibility problem. So, don't do this in production pages, but, it
can help your testing, in, general just don't overflow the page and you'll be good.
User Scalable

There is one more property you can set. You can disable users zooming
entirely by setting user scalable to no. Fundamentally, you really shouldn't do
this. It's bad for accessibility and you're more likely to just annoy your users by
preventing them from zooming than to make their experience any better.
Viewport Units

There is one more thing, on viewports. You're naturally, going to want to lay out, elements on the
page, relative to the size of the viewport. Particularly, when you're sizing columns on the page, for
example. So, we have a new unit type, in, CSS called, viewport units.

You can use these units, to size things, in percentage of width of viewport or percentage of height of
viewport. Without having to push percentage sizing, everywhere, which makes things a little easier.
The really exciting thing, is, these unit types even work in desktop browsers, as well as in mobile
browsers.
VMin and VMax
There are also vmin and vmax units, which let you size things based on the
smallest or largest units of width and height. This helps make layouts that stay
consistent across portrait and landscape mode. Using this feature, it's pretty
easy to create a button that takes up 1/3rd of the biggest square that will fit in
the screen. Now using these units, the button stays as large as it can be and
still fit in a third of the space.
Separate Desktop and Mobile

So you've had about wraps it up, for how to design for a particular view port. With all of this
complexity though, you might have noticed, some developers decide to build two separate
applications, a desktop app. And a separate mobile web app, but there are some problems with doing
this, which of these problems might you encounter with having separate mobile and desktop sites?
Rules for Mobile Only

First, you really need all your features to be available and fully usable on the mobile version. If you
try to guess what content or features your users won't miss on the mobile, you'll probably get it
wrong. It might seem logical, right up until the point where I try to browse store inventory for my
mobile device, only to find that feature is not availbale. Secondly, with two apps or sites, there's a
natural tendency to focus on one or the other and to get out of sync between them.

Maintaining two separate applications and keeping them fundamentally the same is hard to do. And
finally, there's the problem that it's difficult to identify when you really want the mobile version. My
tablet for example has nearly as big a screen as my laptop, and it's actually higher resolution than my
laptop. Mobile design is actually more of a spectrum that spans all the way from low-resolution
devices up into desktop design.
Rules for Mobile Only

At the very least, there are three simple rules if you want to offer a mobile-only site.

First, you want to make sure a user can still get to the full site from the mobile site if they want to, in
case you forgot any features.

Secondly, you should put canonical URL in meta-information. This is commonly done for search
engine optimization, but it's also important to keep your mobile site and your desktop site together.

Finally, if someone links to a specific page on your desktop site, you shouldn't transfer them to your
top-level mobile page. You need to transfer them to that specific page or its equivalent, on the mobile
site. It's really frustrating when you get redirected to the top-level page.
Don’t Block Access
It's great if you've sunk development money into developing a native mobile
app, and it's fine if you want to make sure your users know it's available, but
you shouldn't block access to your web application with a full page ad for your
native mobile app. Make this offer unobtrusive, and make my decision to
ignore it sticky. Now, you can use smart app banners, in iOS, to make this
offer a little less intrusive, but if I open a URL in a browser, I probably want to
stay in the browser.