You're viewing old version number 22. - Current version

10 min

Facebook Instant Articles - May 2015

The first nine publishers to use Instant Articles :

The New York Times
National Geographic
BuzzFeed
NBC
The Atlantic
The Guardian
BBC
Spiegel
Bild

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.

March 2015 gloom-and-doom post, nearly two months before Instant Articles was released.
- http://fusion.net/story/108799/how-facebook-could-kill-the-news-brand/

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 use 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. I'm updating this post with the JavaScript editor.

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 JavaScript. That's why I surf the web with JavaScript and other things disabled by default, thanks to the NoScripts plugin for Firefox.

I also don't care for the overuse of images on websites' homepages and irrelevant images on article pages. And huge images are unnecessary most of the time, since most readers are accessing the sites on phones.

Over the past few years, media sites have redesigned to be responsively designed in order to have one website that functions well on all devices. This is good. But unfortunately, many of these sites bog down older computers with too much code bloat. Single web pages are slow to load and have a size in the megs. Absurd.

And I don't understand why many responsively-designed websites display in such a tiny font size on phones. It's an uncomfortable reading experience. What numskull opined about the need for small font sizes on phones with responsive design?

My prefs for media homepages and article pages:

No JavaScript.
Minimal CSS if possible. This is hard to do.
Small images most of the time.
Useful images that are related to the article.
Homepage with a stream or feed view.
Don't break the back button or create an abnormal action with clicking the back button like taking me back to the top of the site instead of where I left off.
Don't break the right-click or open in a new tab function. This occurs way to often, and it's infuriating. Repulsive.
Don't break highlighting and copying text for excerpting.

Since 2012 or 2013, the web experience has grown increasingly frustrating, thanks to bloated, obnoxious designs caused by the misuse of JavaScript. It seems like website owners have intentionally created miserable web experiences across all screen sizes in order to convince people to use their native mobile apps.

http://jothut.com/cgi-bin/junco.pl/blogpost/48261/12May2015/Breaking-the-web-in-2014-2015

I'm sure that the bad user experiences on newly-designed websites is unintentional. I'm guessing that many site owners, designers, and developers deploy what's currently popular because it uses cool technology even though the tech does not always improve the reading experience.

"The user experience sucks but that animation is cool." - pointy-haired media boss

Back to Instant Articles, the gnashing of teeth by media people can be addressed by simply choosing not to participate with Facebook. What's hard about that?

It's still a choice. 10 to 15 years ago, the media industry choose to act slowly, regarding the rapidly changing digital information landscape.

It's a waste of time to complain that NatGeo, NYTimes, BuzzFeed, and others will use Instant Articles.

But over time as more media sites see the success of others using Instant Articles, then the sites on the sidelines will participate.

Wait three months, six months, a year, two years. Check back in May 2017 to see what's happening.

http://www.nytimes.com/2015/05/13/technology/facebook-media-venture-to-include-nbc-buzzfeed-and-new-york-times.html

Facebook clearly plays an important role as a gatekeeper to news. Nearly half of American Internet users said they got news about politics and government on Facebook during the course of a week, almost as many as got such news from local television, according to a survey last year by the Pew Research Center.

That's higher than I realized. I thought a study within the past year stated that only a small percentage went to Facebook for news. I guess being subjected to news links is different from the intent of using Facebook to get news.

https://twitter.com/petersterne/status/598356862938021888

The launch of Instant Articles could be seen as a nail in the coffin for the idea of an open, browser-based mobile web.

I definitely prefer a browser-based open web, including on mobile, but when obnoxious web experiences are created, this leads to Facebook innovating something new to improve the user experience.

I don't blame Facebook. I blame other site owners for building bloated, clunky websites over the past few years.

"the open web isn't well-suited for mobile devices"

"The mobile web is tough to navigate."

True for poorly-designed websites. Bloated and clunky with unnecessary JavaScript.

For pleasantly designed websites that are kept simple, the web works well on mobile, and the mobile web is easy to navigate.

Simplify and make the experience comfortable. Focus on the individual article page. Strip it down to the bare parts or skeleton:

article header:
- title
- maybe the author
- maybe the created and updated dates
article body:
- obviously, the content.
article footer:
- maybe the author
- maybe the created and updated dates
- maybe a way to contact the author
- maybe a way to share the article

Nothing else is needed on the page, except for a "Home" link, located in the upper left or upper right corner of the page.

Use little to nothing in the web site footer area of the article page.

Save all of the website header, navigation, and footer info and links for the home page. Why repeat all the crap on the article pages?

Keep the article pages as lightweight and simple as possible. Let the negative space shine.

Embedded images and videos that are part of the article body will get loaded in more slowly than the text, but at least the text displays quickly, especially if the article page is pulled from cache.

But media sites add dozens of trackers and other "things" to a single article page. It's offensive.

https://twitter.com/jbenton/status/598346568455061504

If Facebook’s Instant Article justification gets news orgs to care about speed/webperf, good for Facebook.

https://twitter.com/daweiner/status/598345186532528128

The type of people using Facebook for their news (which is apparently everyone but us) don’t care which publication they’re getting it from.

About David Weiner: "Executive Editor and Creative Director @Digg."

#mobile - #app - #media - #socialmedia

From JR's : articles
1904 words - 13294 chars - 10 min read
created on May 13, 2015 at 07:24:15 am
updated on May 13, 2015 at 09:17:46 am - #
source - versions