Paul "Pablo" Croubalian en Professions, Workers, Careers, Directors and Executives, Marketing Independent Authorized Agent of Pivotal Payments • Independent Authorized Agent of Pivotal Payments and others (beBee Ambassador) 16/9/2017 · 5 min de lectura · 1,3K

Is the Responsive Web a Mobile App Killer? Pt 1

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;}
}

So what does that gobbledygook mean?

The first line asks for information about the user's device. Specifically, it asks if the screen is between 375 and 667 pixels wide. (In this example the actual width would be one or the other depending on orientation.) If the screen falls in the right range, do the stuff between the { }.

The two middle lines act on the < p > tag, paragraphs. Guess what they do. Go ahead. I'll wait.

Right! The first line, font-size=300%, triples the font size. (duhhh) The second line tells the < p > tag to use the full width available, but no more. No one likes to scroll. The etcs are just placeholders for other layout rules. You can get as detailed as you like with this stuff.

This post is getting too long.

I was going to talk more about how the Responsive Web can replace apps. I wanted to talk about the benefits a company can get from it. 

The Responsive Web can largely replace mobile apps. That isn't really what has me excited. More importantly, it can pull mobility applications from Marketing's world into the realm of Operations and Sales.

That's huge!

With the Responsive Web, a company can send its intranet out on the road. Anything your employees can do in the office, they can do at the clients' office, at home, in their cars, or even sitting on the john. (Ok, that may be too much of a good thing) 

It can do even more. 

Because it's centralized on your servers you have no limits on what you can do. Servers are waaaaay faster than phones. Leave data processing to them.

You can connect your Responsive Site to APIs to add charting and mapping functions, calculate the fastest route between multiple waypoints, pull in weather data, flight arrivals, corporate info, World Bank stats, notifications, traffic alerts, or anything else that might help you. There are APIs for just about everything.

You're only limited by your imagination.

Oh, and don't worry about App Developers. The Responsive Web will probably kill much of the mobile app market. It won't kill Developers' skills. If anything, it will open a vast new market for those people.

Any company who has any type of road-warrior employees needs the Responsive Web. 
They just don't know it yet.

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

Cheers.














Paul "Pablo" Croubalian 21/9/2017 · #31

#30 You hit on a super important point, @Jim 🐝 Cody. Most people don't understand what the web is. That doesn't stop them from using it. We're used to it. It just works.

This post is the start of a series that is not really aimed at the masses. It's aimed more at Operation and Sales folk. The next post, https://www.bebee.com/producer/@paul-croubalian/is-the-responsive-web-a-mobile-app-killer-pt-2, introduces a semi-fictitious company use case for the Responsive Web. The ones after that will explain its implementation from a sales-automation and overall Operations view.

+1 +1
Jim Cody 21/9/2017 · #30

Interesting @Paul "Pablo" Croubalian. I don’t understand all of it but Google is one powerful tech company

+1 +1
Paul "Pablo" Croubalian 21/9/2017 · #29

#28 True enough, put security is an issue in either path, on-device or web app.

+1 +1

IMO, apps not only eat up data but they expose the user to increased vulnerability. They constantly need to be updated, as well.

+1 +1

Can be , they are trying ... #26

+1 +1
Paul "Pablo" Croubalian 20/9/2017 · #26

#25 Agreed, @Flavio 🇯🇵 Souza 🐝, and that is yet another incentive for Google to push the Responsive Web. They can also circumvent Apple altogether by having app developers pull Google ads into their code.

+1 +1

Yes @Paul "Pablo" Croubalian I think that will be an easier task , putting google search and ads in the smartphones (TVs and appliances) , but they will need to have a deal with Apple to break into their system somehow and that is the hardest part #23

+1 +1
Paul "Pablo" Croubalian 19/9/2017 · #24

#21 Merci, Bernard. I'm curious. Do you use the English or French pronunciation of your name?

0