Tags: facebook

67

sparkline

Thursday, February 16th, 2017

Be More Careful on Facebook | Incisive.nu

Much of our courage and support comes from the people we read and talk to and love online, often on the very networks that expose us—and our friends—to genuine enemies of freedom and peace. We have to keep connected, but we don’t have to play on their terms.

Tuesday, January 31st, 2017

The Schedule and the Stream

Matt takes a look at the history of scheduled broadcast media—which all began in Hungary in 1887 via telephone—and compares it to the emerging media context of the 21st century; the stream.

If the organizing principle of the broadcast schedule was synchronization — millions seeing the same thing at the same time — then the organizing principle of the stream is de-contextualization — stories stripped of their original context, and organized into millions of individual, highly personalized streams.

Tuesday, September 27th, 2016

From WordPress to Apple News, Instant Articles, and AMP - The Media Temple Blog

Chris runs through the process and pitfalls of POSSEing a site (like CSS Tricks) to Apple’s News app, Facebook’s Instant Articles, and Google’s AMP.

Hey, whatever you want. As long as…

  1. It’s not very much work
  2. The content’s canonical home is my website.

I just want people to read and like CSS-Tricks.

Thursday, May 12th, 2016

The inside story of Facebook’s biggest setback | Rahul Bhatia | Technology | The Guardian

The history of Facebook’s attempt to steamroll over net neutrality in India …and how they failed in that attempt, thanks to a grassroots campaign.

Crucially, Facebook itself would decide which sites were included on the platform. The company had positioned Internet.org as a philanthropic endeavour — backed by Zuckerberg’s lofty pronouncements that “connectivity is a human right” — but retained total control of the platform.

Tuesday, April 5th, 2016

Don’t Forget The Web

Here’s the video of the talk I gave at Facebook’s Mobile @Scale event where I was the token web guy. The talk is pretty short but there’s some fun Q&A afterwards.

Thursday, March 24th, 2016

Angola’s Wikipedia Pirates Are Exposing the Problems With Digital Colonialism | Motherboard

The street finds its own uses for colonial internet practices:

Because the data is completely free, Angolans are hiding large files in Wikipedia articles on the Portuguese Wikipedia site (Angola is a former Portuguese colony)—sometimes concealing movies in JPEG or PDF files. They’re then using a Facebook group to direct people to those files, creating a robust, completely free file sharing network.

Wednesday, March 23rd, 2016

Julie Rubicon

The act of linking to this story is making it true.

“I don’t think there’s any law against this,” I said. How could there be a law against something that’s not possible?

Tuesday, March 1st, 2016

@SCALE London

I’m speaking at this event at Facebook in London on St. Patrick’s Day. I’ll be there representing the web.

It’s free to attend, but you need to request an invitation.

Monday, January 25th, 2016

Follow the links | A Working Library

The ability to follow links down and around and through an idea, landing hours later on some random Wikipedia page about fungi you cannot recall how you discovered, is one of the great modes of the web. It is, I’ll go so far to propose, one of the great modes of human thinking.

Friday, January 22nd, 2016

The Facebook-Loving Farmers of Myanmar - The Atlantic

A fascinating slice of ethnographic research in Myanmar by Craig. There’s no mention of the web, which is certainly alarming, but then again, that’s not the focus of the research.

Interestingly, while Facebook is all omnipresent and dominant, nobody is using it the way that Facebook wants: all the accounts are basically “fake”.

What I found fascinating are the ways that people have found to bypass app stores. They’re basically being treated as damage and routed ‘round. So while native apps are universal, app stores would appear to be a first world problem.

Now if there were only some kind of universally accessible distribution channel that didn’t require any kind of installation step …hmmm.

Saturday, November 28th, 2015

Metadata markup

When something on your website is shared on Twitter or Facebook, you probably want a nice preview to appear with it, right?

For Twitter, you can use Twitter cards—a collection of meta elements you place in the head of your document.

For Facebook, you can use the grandiosely-titled Open Graph protocol—a collection of meta elements you place in the head of your document.

What’s that you say? They sound awfully similar? Why, no! I mean, just look at the difference. Here’s how you’d mark up a blog post for Twitter:

<meta name="twitter:url" content="https://adactio.com/journal/9881">
<meta name="twitter:title" content="Metadata markup">
<meta name="twitter:description" content="So many standards to choose from.">
<meta name="twitter:image" content="https://adactio.com/icon.png">

Whereas here’s how you’d mark up the same blog post for Facebook:

<meta property="og:url" content="https://adactio.com/journal/9881">
<meta property="og:title" content="Metadata markup">
<meta property="og:description" content="So many standards to choose from.">
<meta property="og:image" content="https://adactio.com/icon.png">

See? Completely different.

Okay, I’ll attempt to dial down my sarcasm, but I find this wastage annoying. It adds unnecessary complexity, which in turn, I suspect, puts a lot of people off even trying to implement this stuff. In short: 927.

We’ve seen this kind of waste before. I remember when Netscape and Microsoft were battling it out in the browser wars: Internet Explorer added a proprietary acronym element, while Netscape added the abbr element. They both basically did the same thing. For years, Internet Explorer refused to implement the abbr element out of sheer spite.

A more recent example of the negative effects of competing standards was on display at this year’s Edge conference in London. In a session on front-end data, Nolan Lawson decried the fact that developers weren’t making more use of the client-side storage options available in browsers today. After all, there are so many to choose from: LocalStorage, WebSQL, IndexedDB…

(Hint: if developers aren’t showing much enthusiasm for the latest and greatest API which is sooooo much better than the previous APIs they were also encouraged to use at the time, perhaps their reticence is understandable.)

Anyway, back to metacrap.

Matt has written a guide to what you need to do in order to get a preview of your posts to appear in Slack. Fortunately the answer is not yet another collection of meta elements to place in the head of your document. Instead, Slack piggybacks on the existing combatants: oEmbed, Twitter Cards, and Open Graph.

So to placate both Twitter and Facebook (with Slack thrown in for good measure), your metadata markup is supposed to look something like this:

<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@adactio">
<meta name="twitter:url" content="https://adactio.com/journal/9881">
<meta name="twitter:title" content="Metadata markup">
<meta name="twitter:description" content="So many standards to choose from.">
<meta name="twitter:image" content="https://adactio.com/icon.png">
<meta property="og:url" content="https://adactio.com/journal/9881">
<meta property="og:title" content="Metadata markup">
<meta property="og:description" content="So many standards to choose from.">
<meta property="og:image" content="https://adactio.com/icon.png">

There are two things on display here: redundancy, and also, redundancy.

Now the eagle-eyed amongst you will have spotted a crucial difference between the Twitter metacrap and the Facebook metacrap. The Twitter metacrap uses the name attribute on the meta element, whereas the Facebook metacrap uses the property attribute. Technically, there is no property attribute in HTML—it’s an RDFa thing. But the fact that they’re using two different attributes means that we can squish the meta elements together like this:

<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@adactio">
<meta name="twitter:url" property="og:url" content="https://adactio.com/journal/9881">
<meta name="twitter:title" property="og:title" content="Metadata markup">
<meta name="twitter:description" property="og:description" content="So many standards to choose from.">
<meta name="twitter:image" property="og:image" content="https://adactio.com/icon.png">

There. I saved you at least a little bit of typing.

The metacrap situation is even more ridiculous for “add to homescreen”/”pin to start”/whatever else browser makers can’t agree on…

Microsoft:

<meta name="msapplication-starturl" content="https://adactio.com" />
<meta name="msapplication-window" content="width=800;height=600">
<meta name="msapplication-tooltip" content="Kill me now...">

Apple:

<link rel="apple-touch-icon" href="https://adactio.com/icon.png">

(Repeat four or five times with different variations of icon sizes, and be sure to create icons with new sizes after every. single. Apple. keynote.)

Fortunately Google, Opera, and Mozilla appear to be converging on using an external manifest file:

<link rel="manifest" href="https://adactio.com/manifest.json">

Perhaps our long national nightmare of balkanised metacrap is finally coming to an end, and clearer heads will prevail.

Sunday, October 18th, 2015

Wednesday, October 7th, 2015

Rise of the meta-platforms and the new ‘web browser’ - Tales of a Developer Advocate

Paul compares publishing on the web to publish on proprietary platforms, and concludes that things aren’t looking great right now.

Performance is the number one selling point for each of these new content platforms.

Sunday, July 5th, 2015

The Internet That Was (and Still Could Be) - The Atlantic

A fantastic piece by David Weinberger on the changing uses of the internet—apparently in contradiction of the internet’s original architecture.

Some folks invented the Internet for some set of purposes. They gave it a name, pointed to some prototypical examples—sharing scientific papers and engaging in email about them—shaping the way the early adopters domesticated it.

But over time, the Internet escaped from its creators’ intentions. It became a way to communicate person-to-person via email and many-to-many via Usenet. The web came along and the prototypical example became home pages. Social networking came along and the prototype became Facebook.

Wednesday, May 20th, 2015

Instantiation

When I give talks or workshops, I sometimes get a bit ranty. One of the richest seams of rantiness comes from me complaining about how we web designers and developers are responsible for making the web a hostile place. “Stop getting the web wrong!” I might shout, like an old man yelling at a cloud. I point to services like Instapaper and Readability and describe their existence as a damning indictment of our work.

Don’t get me wrong—I really like Instapaper, Readability, RSS readers, or any other tools that allow people to read what they want when they want it. But think about their fundamental selling point: get to the content you want without having to wade through the cruft. That cruft was put there by us.

So-called modern web design and development is damage that people have to route around.

(Ooh, I can feel myself coming over all ranty and angry again! Calm down, Jeremy, calm down!)

And. Breathe.

Now there’s a new tool to the add to the list: Facebook Instant. Again, I think it’s actually pretty great that this service exists. But once again, it should make us ashamed of the work we’re collectively producing.

In this case, the service is—somewhat ironically—explicitly touting the performance benefits of not going to a website to read an article. Quite right.

PPK points to tools as the source of the problem and Marco Arment agrees:

The entire culture dominant among web developers today is bizarrely framework-heavy, with seemingly no thought given to minimizing dependencies and page weight.

But I think it’s a bit more subtle than that. As John Gruber says:

Business development deals have created problems that no web developer can solve. There’s no way to make a web page with a full-screen content-obscuring ad anything other than a shitty experience.

Now you might be saying to yourself “Well, I’ve never made a bloated web page!” or “I’ve never slapped loads of intrusive crap over the content!” I’d certainly like to think that I can look at my track record and hold my head up reasonably high. But that doesn’t matter. If the overall perception is that going to a URL to read an article is a pain in the ass, it hurts all of us.

Take this article from M.G. Siegler:

Not only is the web not fast enough for apps, it’s not fast enough for text either. …on mobile, the web browser just isn’t cutting it. … Native apps provide a better user experience on mobile than a web browser.

On the face of it, this is kind of a bizarre claim. After all, there’s nothing inherent in web browsers that makes them slow at rendering text—quite the opposite! And native apps still use HTTP (and often HTML) to fetch content; the network doesn’t suddenly get magically faster just because the piece of software requesting a resource doesn’t happen to be a web browser.

But this conflation of slow websites and slow web browsers is perfectly understandable. If it looks like a slow duck, and it quacks like a slow duck, then why not conclude that ducks are slow? Even if we know that there’s nothing inherently slow about making web pages:

My hope is that Facebook Instant will shake things up a bit. M.G. Siegler again:

At the very least, Facebook has put everyone else on notice. Your content better load fast or you’re screwed. Publication websites have become an absolutely bloated mess. They range from beautiful (The Verge) to atrocious (Bloomberg) to unusable (Forbes). The common denominator: they’re all way too slow.

There needs to be a cultural change in how we approach building for the web. Yes, some of the tools we choose are part of the problem, but the bigger problem is that performance still isn’t being recognised as the most important factor in how people feel about websites (and by extension, the web). This isn’t just a developer issue. It’s a design issue. It’s a UX issue. It’s a business issue. Performance is everybody’s collective responsibility.

I’d better stop now before I start getting all ranty again.

I’ll leave you with some other writings on this topic…

Tim Kadlec talks about choosing performance:

It’s not because of any sort of technical limitations. No, if a website is slow it’s because performance was not prioritized. It’s because when push came to shove, time and resources were spent on other features of a site and not on making sure that site loads quickly.

Jim Ray points out that “we learned the wrong lesson from the rise of mobile and the app ecosystem”:

We’ve spent far too long trying to compete with native experiences by making our websites look and behave like apps. This includes not just thousands of lines of JavaScript to mimic native app swipes and scrolling but even the lower overhead aesthetics of fixed position headers and persistent navigation.

(*cough*Flipboard*cough*)

Finally, Baldur Bjarnason has written a terrific piece:

The web doesn’t suck. Your websites suck.

All of your websites suck.

You destroy basic usability by hijacking the scrollbar. You take native functionality (scrolling, selection, links, loading) that is fast and efficient and you rewrite it with ‘cutting edge’ javascript toolkits and frameworks so that it is slow and buggy and broken. You balloon your websites with megabytes of cruft. You ignore best practices. You take something that works and is complementary to your business and turn it into a liability.

The lousy performance of your websites becomes a defensive moat around Facebook.

Go read the whole thing—it’s terrific:

This is a long-standing debate. Except it’s only long-standing among web developers. Columnists, managers, pundits, and journalists seem to have no interest in understanding the technical foundation of their livelihoods. Instead they are content with assuming that Facebook can somehow magically render HTML over HTTP faster than anybody else and there is nothing anybody can do to make their crap scroll-jacking websites faster. They buy into the myth that the web is incapable of delivering on its core capabilities: delivering hypertext and images quickly to a diverse and connected readership.

Monday, March 30th, 2015

Want to help prevent online bullying? Comment on Facebook

Proving something that Derek Powazek told us 15 years ago:

When we clearly show what is and is not acceptable, the tone does change. People who want to share thoughtful comments start to feel that theirs are welcome, and people who want to spew hatred start to realize theirs are not.

D’hear that, Reddit?

Tuesday, November 11th, 2014

Mailbox and Facebook App Links by Jon Smajda

When your email client pre-fetches capability URLs, you’re going to have a bad time.

Thursday, October 23rd, 2014

Is Facebook building a colonial web? by Alice Newton

internet.org might more accurately be called very-small-piece-of-internet.org

Tuesday, October 14th, 2014

as days pass by — The next big thing is privacy

Stuart has written some wise words about making privacy the differentiator that can take on Facebook and Google.

He also talks about Aral’s ind.ie project; all the things they’re doing right, and all things they could do better:

The ind.ie project is to open source as Brewdog are to CAMRA.

Tuesday, October 7th, 2014

Why I Joined the IndieWeb Movement - Wingin’ It

I hope that many of you will watch me on this journey, and follow in my wagon tracks as I leave the walled cities and strike out for the wilderness ahead.