Who Chris Sacca Could Be

Yesterday, Sacca posted an 8500-word essay titled “What Twitter Can Be.” It examines the current state of Twitter from a business and investment perspective, acknowledging some good, some bad. What his entire essay lacks, however, is the perspective of a user who is not Chris Sacca.

To wit, from Sacca’s post, his view on the bad:

What’s Not Going Well At Twitter?

New user growth has stalled.

Almost one billion users have tried Twitter and not stuck around.

Direct response advertising has fallen short of hopes.

Wall Street’s confidence in the management team has diminished.

Twitter has been unable to convince investors of its potential upside.

This is an alarmingly one-sided perspective on the issues Twitter is facing, given that none of these problems are concerns that Twitter’s own users have ever expressed. What’s “not going well at Twitter” is, to Sacca’s view, only a matter of why Twitter isn’t making big bucks on Wall Street, and not anything that is actually a real problem with either Twitter the company or Twitter the product.

Throughout the entire 8500-word essay, the terms “women,” “harassment,” “abuse,” “minorities,” “racism,” and so forth and so on, appear a grand total of zero times. Combined. Now that may seem like a particularly social justice set of topics to focus on, but lest you forget, it’s only the actual human beings that are Twitter’s users who can provide value to advertisers, not the many indifferent and emotionless bots (who have no money to buy any advertised products with).

Not caring about the social and/or ethical integrity and health of your userbase will generally lead to its deterioration, and an unhappy userbase is not one that excitedly uses your product, or evangelizes it to others, or posts new content to it as regularly. And it’s not like Twitter’s CEO is unaware of users’ complaints; all the same, it’s been up to users themselves to fix Twitter’s product for them, generally without any compensation.

New user growth has stalled? Twitter’s global reputation for having become a platform that facilitates massively sexist and racist abuse and harassment probably didn’t appeal to people so much.

Almost a billion users tried and left? Maybe they weren’t white guys and still had opinions on things.

Direct response advertising has fallen short of hopes, and Wall Street isn’t confident in the management team anymore? Ever since last August, and the ensuing many campaigns of hate that Twitter is still failing to address, I can’t say I’m surprised in the least.

Sacca is a smart man, witty and funny at times, definitely an incredibly savvy investor, and ruthless at making his own portfolio successful. But you can’t be ruthless at being empathetic, and his essay shows this.

People may not volunteer the idea that Twitter’s easily-toxic environment has made it less appealing to them as a product, but the reality is that awareness of such things has a psychological effect even when you’re not conscious of it. And Twitter’s long series of failures has been very widely documented for the past 10 months on every major news outlet, and national television. Rarely directly attributed to Twitter’s management team, mind you, but you don’t need to explicitly say that Twitter should do better in order for you to know that. The same is true for knowing how toxic being on Twitter can be for people, usually those whose voices are already diminished in our society.

Who Chris Sacca could be is an investor with both a very keen eye for startups and an awareness of how social and ethical concerns that people are constantly repeating are indicative of very real problems that the companies need to address.

I would like to see that Chris Sacca very much, because he still has a lot of influence, and his voice on these matters gets heard far and wide. Sadly, perhaps, more so than the thousands, nay, millions of voices quietly asking Twitter to perhaps better consider how the service is damaging their lives, livelihoods, and relationships, and do something about that.

Wednesday June 3rd, 2015

The Web Doesn’t Get Preferential Treatment (Part 1)

Note upfront: Due to an ever-increasing length this piece has been split into multiple parts, with subsequent installments to be released in the days ahead. This is Part 1.

Several weeks ago Facebook released Instant Articles, a (so far) iPhone-only specialized renderer built with native Objective C and Cocoa frameworks that takes published HTML content and displays it in a reading-optimized format, with great multimedia and UX fidelity. And above all, titularly, no loading times for the content.

Instant Articles exists because Facebook measured that external articles (loaded from within the Facebook app) take between 8 and 10 seconds to render on average, and it—like any savvy business—saw an opportunity for improvement there.

And while it is a significant user experience improvement, it remains to be seen how much content will get this Instant Article treatment, and in what layouts. At the time of writing I could find only one such article between the various launch partners’ own Facebook feeds. Even their own Instant Articles group doesn’t link beyond the launch items provided.

The documentation is still being produced, but Instant Articles may not require much in terms of code changes, as shown in these twovideos. Quite likely it’s not a technical challenge that explains the dearth of Instant Articles from the launch partners thus far. More on that later.

And as always, the reports of the Web’s impending death are greatly exaggerated.

For one, Instant Articles (<abbr>IA</abbr>) are nothing without web-published, HTML-structured content (whether it uses any site-provided CSS and JS at all is unclear). IA is a renderer built in native iOS code; it’s not native iOS-written content. Think of it as a highly specialized web browser, rather than a native app.

Still, there are some major problems looming over the horizon that I think the Web (community and companies) will have to address, lest this world-class platform of technology and information gets relegated to second-class citizenship for the vast majority of content as shared and consumed by people (and monetized by publishers).

The Web Lacks Governing Focus

Apple is deeply invested in its platforms, technologies, and the required innovations it must push to compete. The tools it provides to developers, to build apps and experiences of their own with, reflect that investment as well as its focus. The same holds true (in varying degrees) for Google and Microsoft, and “smaller” technology vendors like Mozilla or Opera.

No company has its existence at stake by the marching beat of the Web that also has enough control over the platform to steer it away from long-term irrelevance. Apple’s livelihood goes away if the Mac OS X and iOS platforms stop appealing to both consumers and developers, and while neither Google nor Microsoft depend on their desktop and mobile operating systems the same way, they would cede too much control and revenue if they didn’t uphold their own platforms.

The result is that these companies have to compete by the tools and (developer) services they provide. The programming standards and conventions are constrained by a single entity having to appeal and cater to a great many third party vendors. This forces a virtuous cycle wherein the incentives are strong and clearly targeted for the platform-owning company to facilitate third-party needs.

The Web lacks such a virtuous cycle; it instead has many smaller community-run ones, much to its credit, but these are not governed or coordinated as one. There is a great deal of value and virtue in this independence, but it does not create a beneficial environment for technological progress and innovation. What one “group” does may get—and often is—rejected by various others, thereby not pushing the web one great stride forward, but two strides in miscellaneous directions. Area spread versus depth.

We cannot enforce any convention on the web; we can only convince people to adopt one by showing how it’s better. By market value, in essence (a small irony, perhaps, that the academic, socialist Web is so fundamentally capitalist in its own ways). Even when many are convinced, the convention remains unenforceable, subjective, and permits use-case-specific exceptions. Those are not criticisms per se, but it is important to recognize that these benefits come with tradeoffs, and that we must understand and acknowledge those tradeoffs if we are to improve on them somehow.

The Web Lacks System-level Integration

Facebook created Instant Articles ostensibly because web pages take 8–10 seconds to load on mobile, if not longer. That’s because the resources they need (or prefer to use) have to be sent along to the user’s browser along with whatever small amount of content they’re requesting. Then, it goes through a slow DOM process in the browser that has to make sense of it all.

And it really is a small amount: I sampled a random page from BuzzFeed (one of the launch partners of Facebook’s Instant Articles), and clocked it in at:

4.5 MB total transferred

7.11 seconds for DOMContentLoaded event

10.66 for Load event

15.22 seconds for final page load with activity completed

Speeds will vary easily from test to test, but my point is about the size any, and it’s a fairly good average representation. The total amount of actual content my request asked for? 730 kilobytes, and that includes all of the content’s images, which comprised the bulk of the weight. That means less than one-fifth of the page was what you actually came for.

There’s a reason we cache things aggressively and try to optimize heavily, but all those efforts are completely in vain if someone is doing a one-time load not from their usual desktop or mobile browser, but from the Facebook app on their phone. This app keeps its own cache, so users only benefit from your hard caching work inside the Facebook app if they visit your site on multiple occasions inside the Facebook app.

The rest of the data transferred above was mostly for plugins, libraries, and ad- and tracking tools and services. Some of that is (re)used by thousands upon thousands of other high-profile websites. But each of them may host some of it on their own servers or CDN, losing cross-site caching benefits.

Native platforms don’t suffer this problem. What tooling resources they get to use are either already included by the OS, or are bundled inside the app. They are also compiled, offering some additional benefits.

Now, I know what you’re thinking: “If websites could make use of a handful of defined and widely agreed-upon resources and utilities that were to come preloaded by the OS the way the Core and Cocoa frameworks are on iOS, would they then have a lot less data to transmit, unpack and process while the user is waiting to see some content?”

Okay, so maybe that’s more my own thinking. The answer, however, is a resounding indifference. Yes, no, sorta, not really.

(By the way, if you’re thinking the web is the only one suffering from slow, tedious user tracking libraries and frameworks, think again: those same or similar services are bundled into most iOS and Android apps today. They just come preloaded when you install the app.)

Having access to popular shared resources locally would save some time, but still be far cry from a real solution. A much bigger slice of the problem pie is that browser engines have to deal with a lot of shit. A lot of shit. Backwards compatibility going back decades is neither easy nor is it great for performance, but it is kind of intrinsically crucial to the Web as a platform. The first-ever web page should always work in something daring to call itself a web browser, as should everything in-between it and the present (poorly constructed or intentionally broken sites and pages notwithstanding).

Then, then, there is the problem of the publishing world and its ever-shrinking capacity to compete with the free resources available on the Web while still making enough advertising money to accommodate a print-based business as well. They have to keep users on the site at all costs, track them, lure them in for more, convert them, sell to them, gather information from them, and so forth.

That Facebook can do Instant Articles makes a lot of sense: for one, they don’t have to do all of those tasks via additional code and side-content on the page itself; they already have that information from you using their app to browse in the first place. This puts Facebook in a better position to advertise to you, and thus charge higher advertising rates, while at the same time freeing up a lot of valuable technical, design and extraneous content-related resources for the actual article or video you requested to shine in the palm of your hand.

Facebook doesn’t need to keep you on the site to browse for more content. It’s already got your eyes and information, it already knows what to sell to you and when. Online publishers, however, do not have these things, let alone have such control over them within a self-contained, somewhat walled-in environment exclusively theirs to operate.

They do have it with whatever native apps they may have created for you to download from the App Store or Google Play (or Microsoft’s Apps+Games). This is why those exist.

Websites don’t get to benefit from this kind of system level integration—and from a privacy perspective, you might exclaim an enthusiastic “thankfully!”, but with the right privacy controls, this wouldn’t actually be a bad thing to have. But, this is not currently the case.

(To be continued)

All that, and I haven’t even gotten started talking about my favorite topic yet: tools. We’ll go into that in Part 2.

About me

Faruk Ateş is a designer, developer, and entreprenerd. He is the creator of Modernizr, and co-founder of Presentate. He lives in Vancouver, B.C. and writes and speaks about technology, social justice, design and business.