Is the Responsive Web a Mobile App Killer? Pt 1

Google thinks the Responsive Web will kill many mobile apps. So do I. To be sure, when Google gets behind something it tends to happen. 

Remember when they said they would photograph every address in the world? 

Did you laugh? 

I know I did. Then Steet View popped up.

It's never a good idea to underestimate Google, or Alphabet, or whatever they want to call themselves. They can call themselves Boogers R Us for all I care. 

I'll still bet on them.  

The boys and girls in Mountain View changed the world. They continue to do so.

From Google's viewpoint, the 7 gazillion mobile apps are keeping people off the web. Google is a web company. No poop they don't like that idea.  

App Ad revenues are not Google revenues.

From our viewpoint, the 2.4 billion mobile devices, the Lord-knows-how-many IoT devices, the smart TVs, the smartwatches, etc cause us fits. 

How can we support all that stuff plus more stuff that we don't even know about yet because it hasn't been invented yet?

The short answer is, "We can't."

If our app is data-intensive how can we keep all that data perfectly up to date?

The short answer is, "We can't."

If we need to make changes to data or software, how do we keep both synchronized and up to date? Remember, we may have thousands, or even tens of thousands, of instances out there.

The short answer is, "We can't."

We need iOs apps, Android Apps, and Windows Phone apps. What happens when a customer who bought our Android version switches to iOS or vice versa?

Are mobile apps really worth the headaches? Maybe. Maybe not. 

Until now, we had no choice.

The Responsive Web It isn't a different web. It's just a system of using advances in common web technologies to make a website look good, and work well, no matter what you use to look at it. 

The fancy term is device-agnostic.

A Short Layman's Guide to Web Tech

First off, don't panic. 

The web is just a bunch of text files sitting on a bunch of servers. Those text files are read by browsers who, in turn, display the site. Firefox is a browser. Chrome is a browser. The jury is still out on Internet Explorer and Edge.

You already know what text files look like. These text files are specific flavors of boring old .txt files. Replace the .txt extension with something else and the browser knows what to do with it. Example, if a file has a htm or html extension, the browser assumes it's HTML code. It shows a web page.

Other technologies have their own extensions, but, they are all just text. 

Nuthin' here to panic about. 

There are a few core technologies at play. Other technologies can also lend a hand, but these are the main ones.

HTML

HTML defines what the site is. It works inside your browser to tell it what your information is and, in a very general way, how it should be shown to the viewer. 

HTML uses tags like < h1 > (spaces added so that it actually shows up here) to tell the browser to display whatever follows as a level one headline. Another tag, < /h1 > tells the browser to stop displaying a level one headline.

There are lots of tags, enough to present your information logically and cleanly. HTML 5 introduces new tags that make the web react. That's cool, but not enough.

What you can't do with HTML is make the site pretty.  HTML by itself is butt-ugly. It just lays out information, but it has no pizzazz, no attitude. The early days of the web were all HTML. It sucked. I know. I built my first site in 1982. YUCH!

CSS

CSS also works in the browser. It stands for Cascading Style Sheets. Most of you already know what a style sheet is. It's "hair and make-up" for a document. Where HTML says "This is a level one headline," CSS says, "Ok, cool, now make it orange, and this high using this font. Add spacing here, and here. Indent it by this much. While you're at it, add a shadow effect. Oh, and animate it in from the left! Etc. Etc Etc."

CSS pretties up the web.

We call these Style Sheets "Cascading" because that's what they do. One can slip right into/onto another. It may add stuff, it may replace stuff. Cascades bring Style Sheets to a whole new level.

It's the latest form of CSS (3) that combines with new HTML tags to make The Responsive Web possible. More on that a little later.

Javascript

Javascript is yet another thing that works in the browser. (FYI: There is no relation between javascript and Java.) Javascript adds interactivity and limited database access to websites. It can also modify CSS on the fly. 

See where we're going with this?

PHP

PHP works at the server level and outputs text.  Originally, back in 1994, PHP stood for Personal Home Page. Since PHP outputs text and HTML is just text, the HTML text was stored in databases. PHP would output it when asked. 

The webpage didn't even exist until you asked for it. That approach was cheap as all get out, but had its drawbacks. Web crawlers can't crawl pages that don't exist.

Its original function has all but disappeared. Now, PHP is the glue between databases and HTML. PHP makes server-side data available to HTML when and as it needs it. A website can have as much access to your data as you want/need it to have.

Now you really must see where we're going with all this stuff!

Relational Databases (ex: MySQL)

We don't need to say very much about databases here. You all know what they are. They're a repository of whatever data you or your business collects and consumes.

In their simplest form, databases are flat tables like a spreadsheet. That's handy, but no great shakes. They become much more powerful when they become relational. That's a fancy-pants way of saying they can "talk" to each other. They can combine themselves, interconnect themselves, refer to each other, pull or push data to each other. 

They can even create more tables or subsets of data on the fly.

To my mind, a website without a database is just a brochure.

Putting it all together: The Responsive Web

Let's start with an extreme example.

Imagine this: Bob opens your website on his Apple Watch. He has a screen resolution of 312X390 pixels (total: 121,680 pixels). Mary opens it on her 8K (UHDTV) smart TV. Mary has a screen resolution of 7680X4620 pixels (total: 33,177,600 pixels). Bob is on his cellular data plan (LTE). Mary is on her WiFi.

The HTML tag that defines an image is < img >. The link to the image itself is in a thing (attribute) called src for "source." So, src="thatPicture.jpg" would show the picture, thatPicture.jpg.

If you show Mary a picture sized for  Bob, it would be so blurry she would have no idea what it was. No worries just make the picture big enough for Mary and let Bob's browser shrunk it to fit his screen. CSS can do that easily.

Problem solved! Right?

Nope.

If you show Bob a picture sized for Mary, he would download 273 times more data than he needs or can use! That might slow him down a tad (More like a ton!), not to mention cleaning out his data plan.

You obviously need two different pictures.  One problem is that src can only point to a single image. 

We already saw that HTML works in the browser.  That's the other problem. A browser can't tell how big an image is until it downloads it. That doesn't help, by then it's too late. Bob would still hate us.

The solution is brilliant in its simplicity. The browser can't tell how big an image is, but we know. We just need to tell the browser how big the image is before it downloads it.

HTML5 introduced the srcset tag. That's less complicated than it sounds. The srcset tag, as its name implies, is a set of src's. Each one tells the browser how wide its related picture is. The browser can then choose the best one for the job.

So here, rather than use src="thatPicture.jpg" we could use srcset="thatPicture320.jpg 320w,  thatPicture7680.jpg 7680w" The browser knows it can choose from pictures 320px wide or 7680px wide. 

The browser already knows how wide the users' screens are. Mary gets the huge image, Bob gets the little one.

Okay, that's one problem solved. Here's another.

Have you ever open a web site on your phone and found the text too small to read? You need to zoom and pan around to see stuff. Sometimes links are so close together that you can't click the one you want. A cursor on a laptop is a lot smaller than a fingertip on a phone screen.

Not the best experience is it?

CSS3 media queries

The latest version of CSS introduced media queries. In a nutshell, media queries apply different layout rules for different device capabilities.

NOTE: You don't need to match every conceivable device. You'd go nuts trying to keep up. You can use ranges. On myTweetPack.com's new responsive layout, we use 3 break points. At less than 601 pixels wide, we figure it's a phone and set the layout for that. Between 601 and 992 we assume it's a phablet or tablet. Over 992 we assume it's a laptop. 
We don't do anything special for smart TVs. We don't use much in the way of images. Smart TVs have the same aspect ratio as a laptop, so we're good. (The fully responsive layout on myTweetPack.com will start rolling out on September 18th, 2017)

Let's use an iPhone6 as an example. Here's what an iPhone6-specific media query might look like.

@media only screen and (min-device-width: 375px) and (max-device-width: 667px)  { 
p {font-size=300%;
max-width=100%;etc;etc;etc;}
}

The next post will examine a specific, semi-fictional use case.

Cheers.