Facebook Instant Articles - May 2015

• http://techcrunch.com/2015/05/12/facebook-instant-articles
• https://news.ycombinator.com/item?id=9536807
• http://instantarticles.fb.com
• video
• http://media.fb.com/2015/05/12/instantarticles
• http://mediagazer.com/150513/p1#a150513p1
• http://recode.net/2015/05/12/facebook-starts-publishing-the-new-york-times-buzzfeed-and-more-with-its-instant-articles-program
• http://marketingland.com/facebook-instant-articles-slippery-slope-for-google-128596
  • I doubt Google will be able to create anything to compete with Facebook. Google+ still exists, and it's used a lot, but it's not in the same category as Facebook. Worlds apart.

This could be a reason why Facebook will rule the media landscape too.

Snapchat's Discover is interesting, but the service does not have the reach of Facebook.

And I don't know what Twitter can do beyond the breaking news and discussion format that has been its forte for years.

Forget about the concerns by many media people and tech geeks, if the general audience enjoys Instant Articles, then the feature will expand to more publishers who won't have much of a choice but follow.

The media industry, especially the newspaper industry, brought this upon themselves with their failure to adapt and innovate.

Instant Articles is only a mobile app. I'm unsure why it would exist in any other format.

I still have a Facebook account that I rarely access. I was about to delete my account a few weeks ago, but I kept around because of the forthcoming Instant Articles feature. I installed the Snapchat app strictly for their Discover media feature.

I do not, however, have the Facebook app installed on my iPhone.

I'm guessing that most users access Facebook on their phones, and most phone access is through the Facebook app.

Many media websites see most of their traffic now coming from mobile devices: tablets and phones. But most of the mobile traffic is from phones.

It makes sense that Instant Articles starts as a phone app. It might also be a tablet app. But what would be the point of supporting mobile web and desktop/laptop web?

Naturally, most of the geeks posting in the HN thread are bothered by Facebook and Instant Articles. Simple solution: don't use the site. Harder solution: create something better. Easiest of all solutions: whine.

The promotional video makes the stories look fascinating with the video and animations. And text still plays a big role, depending upon the publisher, of course. The samples look sharp. If that's how it works all the time, then I can see users (normal people) loving Instant Articles.

Walled garden, silo, whatever. Facebook has the intellectual horsepower to innovate new ways of disseminating information.

Not every project is a success at Facebook, but they keep hacking and trying. Instant Articles could eventually end up being a failure, but I doubt it. It will slowly grow more important over time.

Heck, Instant Articles could encourage more people to use Facebook more often. People like me.

Some people believe that Instant Articles will further hurt the web. Maybe, but the web began getting damaged years ago with bloated web designs that created slow, clunky, horrible user experiences.

Media sites would have functioned better with a plain, vanilla 1995 look with bare bones HTML. Add a smattering of CSS with media queries, and it would be possible to create small, lightweight, fast-loading web pages in 2015 that are still comfortable to read.

My test pages with NO JavaScript:

• http://testcode.soupmode.com/simple2.html
  • uses default web fonts Arial and Georgia
• http://testcode.soupmode.com/article/post4.html
  • Google's Open Sans
• http://testcode.soupmode.com/article/post5.html
  • Google's Lora and Open Sans

In my web apps, I employ JavaScript in the browser only when I'm creating or updating a post with the JavaScript editor that I created by modifying code that provided a live preview for Textile markup. The editor came with split screen mode, which I kept, but I removed the live preview because it was annoyingly distracting. I also added a single-screen mode, full-screen mode, and reverse color mode (light on dark). I added auto-save with the option to change the auto-save interval. I added buttons for preview and save. I added keyboard shortcuts for many of the above functions.

But in my web apps, I can also create and update a post by using the standard HTML textarea box. This is fine for quick-hitting activities.

My favorite view is the stream view with the postings displayed by modification date, youngest to oldest. Formatted or typical blog displays are nice, like what I use with my websites built with my Grebe code, such as ToledoWinter.com. The notes stream within my Grebe code and the stream displays for my Junco and Scaup apps, which contain notes and articles all display a very small HTML textarea box at the top of the site, so that I can easily add notes and links without first clicking a "post" or "create" link.

The point is that I like client-side JavaScript for logged-in dashboard functions like what's used with my Digital Ocean account. Their usage of JavaScript is elegant. It's not overdone. They don't use JavaScript just because they can. The JavaScript usage serves a purpose and makes administration of my droplet pleasant.

Ditto for my Fastmail.fm account, which is my favorite email service. I like Fastmail much more than Gmail and Yahoo. Fastmail's web app on desktop/laptop and especially on the phone work well. Again, elegant usage of JavaScript, CSS, etc. It's not bloated and overdone. I don't think that Fastmail offers a native app for phone, but that's fine with me because I like their web app for phone.

For content sites where I don't log into the site, I don't understand the misuse and overuse of client-side

#mobile - #app - #media - #socialmedia