Obviously, you’ve read Yaron Schoen’s ovarian1 article Platform economics in a nutshell. Even Syd Lawrence has.
It’s an insightful piece of meta-analysis, to be certain. But I can’t help but feel that while it’s certainly superficially persuasive, it somewhat disingenuously glosses over some important points.
For example, Schoen writes “tablets and smartphones have been tilted to make better shots on Dribbble, it’s hard to see how that will affect crowdfunding in the future.” This is an obvious truism, wilfilly obfuscated by the needless “Dribble” tangent, invoking the Tinman rhetorical fallacy in order to raise the spectre of declining ARPU which, on closer examination, proves orthogonal to the central question: whither ROI in a world of increasingly unmediated business-to-consumer conversational engagement?
I can’t help feel that Schoen deliberately fails to deconstruct the disruptive effects of hybrid apps’ use of wearable web components (polymers) in the social space.
Footnote 1: “ovarian”, in order to reject the sexist term “seminal”. Is it any wonder no women ever go to conferences? Even Schoen’s title “nutshell”, with its atavistic reference to the scrotum, perpetuates the phallocentric patriarchy that Kristeva so eloquently exposes. Have we so quickly forgotten “Já não há histórias de amor. No entanto, as mulheres desejam-nas e os homens também, quando não se envergonham de ser ternos e tristes como as mulheres”?
Update #1: It’s painfully apparent that Schoen is blind to sparklines showing a huge preference for disintermediated pan-segmental consumption trends.
Update #2: What’s the point of words, when an infograffik explains it all so much better?
Update #3: renumbered preceeding updates.
It’s not often that I post stuff directly related to my employer, but for web/ browser wonks, what Opera’s done (swapping its rendering engine and redesigning) is unusual.
Following Tuesday’s launch of Opera 15 for Windows and Mac, my chum Andreas Bovens and I wrote an overview of the over-arching vision behind it, and some of the design decisions.
When we released our first browser in 1996, most web users were people who weren’t afraid to tinker, and who liked lots of options and configurability. Fast-forward 17 years, and the Web is everywhere. Speedy browsing and sites working properly is the most important thing to many, many people.
That leaves us with the riddle that every software developer faces at some point: how best to make a UI simple enough to be intuitive for a consumer who wants a solid, fast browser that just works, and yet is customizable and extensible so that power users can add the features they want?
The answer is to build a strong, extensible foundation on which to innovate. Opera 15 is a fresh start, to which we will continue to add features.
A closer look at Opera 15
When we took the decision to switch to Chromium, compatibility was one reason — but most importantly, we wanted to spend our time on browser innovation, rather than competing on building a rendering engine. We had a deep look at Opera’s internal architecture and it soon became clear that Quick, the cross-platform UI framework we’d introduced back in 2003, was so entangled with Presto’s code that just swapping Presto with Chromium was far from a straightforward task.
The same was true for M2: adding it to Opera 15 would require rebuilding it from scratch, more to download for users and more UI for those who don’t use the feature. For that reason, we spun it out into a separate download.
At the same time, we also wanted to give Opera a more native look and feel. And hence, taking also into account that native toolkits have evolved over the last 10 years (especially on Mac), we decided to build the whole UI with native code: we stripped away Chromium’s UI layer, and built it piece by piece from scratch — a big undertaking, and what you see today is just the beginning.
At first, we also planned to build Speed Dial, Stash, Discover and so on with native code, but when seeing that the performance of our first functional web-based prototypes was excellent, we decided to go with a web-based (and hence cross-platform) UI for these parts instead. Indeed, you can open Web Inspector and see how they’re built.
So, starting from this fresh base, we decided to carefully consider how to build up Opera again: over the years, Presto-based Opera had become overloaded with features, a number of them confusing rather than helping our users — you can’t imagine how many reports we’ve gotten from users telling us that their favorite site was broken, simply because they had turned on fit-to-width by accident, for instance.
So, the approach when building the new product has been and still is to cater for various browsing use cases, but at all times, to keep the UI really simple, so that anyone can use it.
Let’s have a close-up look at four of Opera 15’s features, and explain the thinking that went into them.
We introduced the Speed Dial concept in 2007. When we extended it allow unlimited Speed Dial entries, we became aware that the conceptual difference between traditional bookmarks and Speed Dial was shrinking. Indeed, rather than browsing through a tree structure in a menu or panel, hunting for the right bookmark, users were relying on the address bar’s auto-complete, Speed Dial entries, or built-in search to get to their site of choice. That gave us the idea to move bookmarks right into the browser window where all the browsing happens. The addition of one level-deep folders with visual thumbnails and super-fast search allows you to find any favorite site in an instant.
We found that modern browsers are hard to do research in. You open tab after tab (comparing different shopping items for instance), and after a while you can’t keep track of what’s where. Sessions and tab stacking attempted to help, but also confused a lot of users, adding extra UI complexity. So we came up with Stash, which is a vertical overview of items you’ve added with super-fast full-text search, so you can compare and filter. This limits the amount of tabs you need to have open, reducing the number of running processes.
Now the Web is everywhere, it’s very common to be lounging on a sofa, or waiting at a bus stop, entertaining yourself with a notebook, tablet or phone. But with a world of content out there, where to start? Discover is a feature that brings pre-selected content, in a range of languages and subjects, straight to your brain.
Not everyone is on a fast connection all the time. Opera 10 introduced Opera Turbo to render pages faster on slow connections, which was subsequently improved by compressing images into WebP format in Opera 11.10. Off-road mode in Opera 15 adds SPDY to the mix so that your pages render even faster.
It’s no coincidence that Opera 15 was released on the same day as our rapid release cycle began. You’ll soon see what’s on the table for future versions. At the moment, we’re looking at themes, syncing between devices and improving tab handling.
If you’re a power-user (and if you’re reading this, you almost certainly are) and you find that Opera 15 doesn’t have a feature you depend upon, first check the growing list of extensions. You may find the basic bookmarks manager extension that I worked on with Stuart Langridge fits the bill — or you may find the cottonTracks extension is an innovative way to solve a problem. If you miss Notes, try the Evernote extension.
If you find Opera 15 is missing something that you absolutely depend on, that’s why we still have Opera 12 out, and why you are not auto-updated to 15. And of course, Opera 16 is just around the corner.
We’re looking at your comments and feedback (as we have for 17 years!). Please send us bug reports if you find mistakes. Inside the company, we all have our own personal wish-lists (I keep harping on about ctrl+enter and Turkish Discover; Andreas harasses everyone about Extension APIs and bookmarks).
Some of these will be rolled out to more than 50 million users. Some won’t — we’re not looking to make a faster horse. Nor are we cloning Opera 12, or any other browser. We will continue to innovate to build the best browser.
It’s five years since I began work at Opera, the plucky Norwegian browser maker. Despite this appalling handicap, Opera’s gone from 48.6 million users in June 2008 to over 300 million users.
Doing my job, I’ve co-authored a book and had the privilege of visiting India, Indonesia, Japan, Australia, Netherlands, France, Spain, Russia, Poland, Bulgaria, Germany, USA, Czech Republic, South Africa, Denmark, Sweden, and (of course) Norway, and met some of the cleverest people in the industry.
I’ve gone from being a man who forced a corporate website to behave itself in IE6 every day (with only Firebug as my sword and a couple of forums as my shield) to someone who rarely makes full websites any more, but reads billions of emails about the next tranche of fascinating standards that take the web to new, ever more-powerful ubiquity.
And they give me money to do it. Mad buggers.
On Thursday, I travelled down to the swanky Mozilla offices in London to an open invitation to meet the W3C Technical Architecture Group (TAG), who were in town (presumably for this week’s Bilderberg meeting). I’ve met many of them before, and they’re all jolly good people, but I’d never met them as an entity.
I’d lugged my laptop down to take notes, as I’d anticipated some sort of relaxed presentation and then a public Q&A (by “relaxed” I mean, not live streamed and in front of the small 30-strong audience enjoying Google’s beer donation). It was unstructured, however, with TAG people mingling around and presumably answering the same questions repeatedly. (I’ve given this feedback to the co-chair, Dan Appelquist, already.)
I asked “What does the TAG do?” after Dan introduced the evening. Dan and TimBL answered that the TAG is an oversight body that ensures W3C specs kind of cohere, and kind of stay within the Architecture of the World Wide Web that TAG defined. Jo Rabin followed up with the question “how does TAG measure its success?” to which there was a less definite response. (However, the Web continues to do rather well, so arguably they haven’t broken anything.)
It’s good that the TAG want to meet developers. Tag member Jeni Tennison asked me what my pet peeve with the TAG is. I answered that there isn’t a representative of jobbing web developers on the team. Sure, there are some people who represent browser vendors on the team, but people like me don’t make web sites every day any more (if they ever did). I’m starting to feel that although lip service is paid to the needs of developers in the Priority of Constituencies, it’s pretty hard for a developer to get his/her voice heard.
Matt Marquis wrote recently
working in web standards is incredibly frustrating. It involves no small amount of interaction with people who seem to have graduated from the Hacker News Commenter School of Diplomacy. We “authors” don’t hold much weight in standards discussions; at least, nowhere near as much as browser representatives do.
Now, do I think more full-time designers and web developers should get involved in standards, after all this glowing endorsement? Absolutely. The fact is, we don’t have the kind of voice we ought to have because we’re not there. “Author preference” is very often used to argue for or against something in a standards discussion, but very few of us are around to agree or disagree. We’re a talking point more than we’re active participants.
The question is, what to do about it? Six years ago, the CSS Eleven announced with a fanfare that it was an organisation “committed to helping the W3C’s CSS Working Group to better deliver the tools that are needed to design tomorrow’s web”, made itself a lovely website and then promptly disappeared. I’ve certainly heard from developers and designers that it’s hard to do a full-time job, keep up with all the new developments and get actively involved in the time-consuming minutiae of standards development.
Perhaps we wound the Web Standards Project up too early. But I don’t think so. Perhaps we need someone embedded in the TAG who is paid by a benevolent employer to devote 50% of his/her time to standards while continuing to work. Perhaps we need someone paid by the W3C full-time to represent developers.
I don’t know. What do you think?