Archive for the 'Opera' Category

On URLs in Progressive Web Apps

I’m writing this as a short commentary on Stuart Langridge’s post The Importance of URLs which you should read (he’s surprisingly clever, although he looks like the antichrist in that lewd hat).

Stuart says

I approve of the Lighthouse team’s idea that you don’t qualify as an add-to-home-screen-able app if you want a URL bar

Opera’s implementation of Progressive Web Apps differs from Chrome’s here (we only take the content layer of Chromium; we implement all the UI ourselves, precisely so we can do our own thing). Regardless of whether the developer has chosen display: standalone or display: fullscreen in order to hide the URL bar, Opera will display it if the app is served over HTTP because we think that the user should know exactly where she is if the app is served over an insecure connection. Similarly, if the user follows a link from your app that goes outside its domain, Opera spawns a new tab and forces display: browser so the URL bar is shown.

But I take Jeremy Keith’s point:

I want people to be able to copy URLs. I want people to be able to hack URLs. I’m not ashamed of my URLs …I’m downright proud.

One of the superpowers of the Web is URLs, and fullscreen progressive web apps hide them (deliberately). After our last PWA meeting with the Chrome team in early February, I was talking about just this with Andreas Bovens, the PM for Opera for Android. We mused about some mechanism (a new gesture?) that would allow the user to see and copy (if they want) the URL of the current page. I’ve already heard of examples when developers are making their own “share this” buttons — and devs re-implementing browser functionality is often a klaxon signalling something is missing from the platform.

When I mentioned our musings on Twitter this morning, Alex Russell said “we’ve been discussing the same.” It is, as Chrome chappie Owen Campbell-Moore said “a difficult UX problem indeed”, which is one reason that Andreas and I parked our discussion. One of Andreas’ ideas is long press on the current page, and then get an option to copy/share the URL of the page you’re currently viewing (this means that a long press is not available as an action for site owners to use on their sites. Probably not a big deal?)

What do you think? How can we best allow the user to see the current URL in a discoverable way?

web.next: Progressive Web Apps and Extensible Web

Here’s the keynote talk I did at Render Conference, Oxford in April. (Slides.)

All the other talks are available. Yay!

I told the nice organising types that I wouldn’t accept the speaker fee because public speaking is my job. Rather than just pocket the money, they suggested we donate it to a worthy cause, which is very good of them.

So I asked them to send it to a rural school in Cambodia, where a friend of mine has been volunteering. They’re building a computer lab to train kids and the local people. In one of the poorest countries on earth (average salary is $80/ month) a second hand laptop at $250 is still a luxury. As someone who was a primary teacher in Bangkok, this ticks all my personal boxes: education, S.E. Asia and the web.

Thank you, Ruth and all at Render Conference.

One weird trick to get online — designers hate it!

At the Google Progressive Web Apps afterparty last night, I had two very different conversations within five minutes of each other.

Conversation #1 went

Hey Bruce, lucky you weren’t at REDACTED conference last week. They were bad mouthing Opera! One speaker said, “Anyway, who cares about Opera Mini?”

In the time it took to drink another 5 bottles of free beer (two minutes), conversation #2 happened:

Oh Bruce, hi. We’ve just raised £100million in funding for our business in Asia, and 35% of our users are on Opera Mini.

What’s the difference? Well, for a start, one was apparently said by a European designer to a room full of European designers, in Europe. The second is the word “users”: the second conversation focussed on the fact that a technology is used by human beings, which is always, always the point.

Now, I don’t care about Opera Mini per se (I’m not its Product Manager). In the same way, I don’t care about walking sticks, wheelchairs, mobility scooters or guide dogs. But I care deeply about people who use enabling technologies — and Opera Mini is an enabling technology. It allows people on feature phones, low-powered smartphones, people in low-bandwidth areas, people with very small data plans, people who are roaming (you?) to connect to the web.

Sure, I get that Opera Mini can frustrate some designers and developers; your rounded corners, gradients and JavaScript-only APIs don’t work. But CSS isn’t content, and a progressively enhanced website will work (albeit more clunkily) with JavaScript throttled after 3 seconds. (I wrote Making websites that work well on Opera Mini if you want more information on how Mini works.)

I ran the stats today. Of more than 250 million Opera Mini users, 50% are on Android/iOS and 50% are on feature phones. The second group almost certainly have no choice in which browser to use to get a full web experience. That’s 125 million people that designer-on-stage doesn’t care about. People like Donald from Nigeria, people like Silma from Bangladesh. People.

The top territories for Opera Mini use are India, Indonesia, Nigeria, Bangladesh and South Africa. Because conversation #2 was about tangible stuff – millions of pounds, and numbers, let’s look at the economic growth of these nations full of interlopers to our WWW (Wealthy Western Web).

Country Population PPP Growth Rate
India 1,251,695,584 $6,300 7.3%
Indonesia 255,993,674 $11,300 4.7%
Bangladesh 168,957,745 $3,600 6.5%
Nigeria 181,562,056 $6,400 4%
South Africa 53,675,563 $13,400 1.4%

(PPP= Gross Domestic Product per Capita, figures from CIA World Fact Book)

Sure, those PPP numbers might be low compared with the home countries of designer-on-a-stage and audience, but how do the growth rates compare? These are dynamic, emerging markets. Who cared about China ten years ago?

If you don’t care about Opera Mini users in these areas, you can bet your competitors soon will.

On the proposed Opera buy-out

I’ve had a few tweets, DMs and emails asking about the proposed buy-out of Opera by a Chinese consortium. Here are some answers to your questions (none of this is new; it’s publicly available in Lars’ statements to the press and Opera’s consumer blogs, but I know that many of you are techies who won’t necessarily read those). I apologise for not getting back to you earlier; the news broke on my last day of a press tour of India and I only got back yesterday.

Firstly, it’s not a done deal. An offer has been made, and Opera’s board has recommended that shareholders accept it. But shareholders need to vote and governments need to be consulted.

If the deal goes through, the shareholders change (because current shareholders would sell their shares to the Chinese consortium) but, as Nuno Sitima (Opera’s Lord of Mobile Stuff) wrote,

the people behind Opera remain the same. The same teams will be developing and delivering the [products].

Many of you asked why we’re doing this. It gives Opera access to 500 million Chinese customers of the consortium, and investment to grow bigger. I am not a Biz Guy so I’ll just quote the press release:

The transaction would give Opera access to the extensive internet user base of Kunlun and Qihoo in China as well as the financing and other support of the Consortium that would allow for the full potential of the Company to be realized.

Lastly, and most importantly, I’ve had Opera customers ask about the security and privacy of their data. The answer is simple, and reassuring (I hope):

Assuming the deal goes through (see first point above), Opera plans to continue operating as a stand-alone company (see Nuno’s quote above). We are a Norwegian company subject to Norwegian (EU/EEA) privacy laws. Our shareholders may change but our legal obligations in this respect will not. All data will continue to be handled in accordance with our Norwegian legal obligations — nothing changes in this respect.

(And, yes, I remain employed; thanks to all of you who asked after me personally and offered me other jobs. But, honestly, despite still looking great in a mankini, my pole-dancing days are behind me.)

I’ve got a new job!

TL;DR, I’m moving from Developer Relations to become Opera’s Deputy Chief Technology Officer. Or maybe Deputy Technology Officer, because “Deputy Chief” is almost oxymoronic. Anyway, call me “Bruce”; it’s more polite than what you usually call me.

Co-father of CSS Håkon Wium Lie continues to be CTO, and I’ll be working with him, the Communications Team, the product teams, and my lovely colleagues in devrel, to continue connecting the unconnected across the world.

In some ways, this is simply an evolution of what I’ve been doing for the last couple of years. In a more profound way it’s a return to basics.

My first real exposure to the Web came about working in Thailand in 1999, when I was convalescing after my diagnosis of Multiple Sclerosis. Because M.S. is very rare in Asia, I could find no English language information to tell me how quickly or painfully I would die.

But I’d read about this new-fangled Web thing, and there was an Internet Café near my apartment, so I typed in “Multiple Sclerosis” into Alta Vista and found something extraordinary: a community of people around the world supporting each other through their shared diagnosis on something called a “website” – and I could participate, too, from a café in Pratunam, Bangkok. All strangers, across the globe, coming together around a common theme and helping each other.

I knew immediately that I’d stumbled upon something amazing, something revolutionary, an undreamed of way to communicate. As an English Literature graduate and ex-programmer, I was fascinated, by both the communicative potential and also the tech that drove it. By 2002, I was Brand Manager for a UK book company publishing on books for web professionals, and our first, flagship book was on Web Accessibility.

From accessibility, I began to advocate the general concept of open web standards on my blog and with various employers, so that everyone could access the web. Then, after being invited to join Opera in 2008, I started advocating HTML5, so people could connect to an open web that could compete with the proprietary silos of Flash and iOS. After that, I began beating the drum for Media Queries and Responsive Design so that the people in developing nations (like I was in ’99), using affordable hand-held devices, could connect and enjoy the full web. Then I proposed the <picture> element (more accurately: a very naive precursor to it) so that people with limited funds for bandwidth could connect economically, too. Then I agitated, inside Opera and outside, for Progressive Web Apps, so people could have a great experience on the open web, not those pesky walled gardens.

The common thread is people and getting them connected to each other. This matters to me because that happened to me, 17 years ago (spoiler: and I didn’t die).

A third of a billion people use Opera’s products to get them online, fast and affordably. I want to be part of making that half a billion, then a billion, then more; not by stealing customers from competitors, but by opening up the web to people and places that currently have no access. That’s a lot of people; there’s a lot to be done. It’s a big job. I’m a n00b and I’m gonna fuck up from time-to-time.

Bring it on.

(Yikes.)

2013 round-up

2013 was a fun year. It saw my 5 year anniversary at Opera – which I actually missed when it came about, all the more surprising when I consider that I’ve never done one job for this long. (Previous records were Programmer/ Analyst at AT&T from 1988-92, Teacher at Amnuay Silpa School, Bangkok from 1996-2000 and Web bloke at The Law Society from 2004 until starting with Opera in ’08.)

As befits a tech company, I didn’t receive a carriage clock or gold watch. Instead, my CEO began following me on twitter. So now, I always wear a tie when tweeting. Just a tie.

Professionally it’s been an interesting and fun year. I got to visit Italy, Spain and Romania for the first time. Spain saw me in Barcelona twice, although the first time doesn’t really count as I was trussed up in a business suit and incarcerated at Mobile World Congress to leverage synergies in an aircraft hanger-sized conference venue. I have yet to go inside Sagrada Familia, so if any Barcelona conference wishes to have me in 2014, you know where to find me.

I also was invited to return to Scotland, Russia, Germany and The Netherlands and had the “fun” of two week-long trips to West USA in three weeks. Jetlag-a-rama. All worth it though, to mix with people who make the Web.

I’ve been spending time working directly with Opera’s desktop team. In 2013 we moved from using our own Presto rendering engine to using the open-source Chromium engine, and rethinking all of the features and UI. Results have been encouraging, but there’s more to do, so I’ve been working on gathering feedback, community engagement and planning next releases.

Working in products has been as interesting as I hoped it would be. Users talk very little about Web Standards – which has been my focus (=obsession) previously, but are very vocal about features and UI. I think this an encouraging sign for the Web generally; as browsers auto-update faster and rendering engines become more interoperable, there are fewer sites requiring specific browsers (although just as many breaking the web by requiring an iPad/ iPhone).

Due to the shocking revelations from Edward Snowden, In 2013 I’ve gone from the kind of person who mocked tinfoil hatters to someone who’s checking the signature of a Tails ISO. At Handheld Conference, my friend Aral Balkan announced IndiePhone, a new design-led, open-source Operating System and phone. I look forward to seeing how it develops, but fear that the tendrils of the NSA are too enmeshed in the infrastructure of the web to allow anyone to be free of intrusive surveillance unless they join the tinfoil-hatters in setting up the kind of countermeasures that consumers won’t understand or be able to do.

All the best for 2014!

The vision behind Opera 15 and beyond

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.

Speed Dial

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.

Stash

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.

Discover

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.

Off-road Mode

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.

…and beyond

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.

Five years at Opera

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.

Hello Blink

It’s great to be able to talk publicly about Blink, the new engine that will power Opera’s browsers (disclosure: my employer, but this is a personal post) and Chrome henceforth. I know a lot of people worried that there would be less diversity on the Web once Opera Presto was retired, and the forking of WebKit into Blink restores that balance. Opera will be contributing to Blink in future.

[added 22:46 UK time] My boss, Lars Erik Bolstad, said on Opera’s behalf: “Our ambition is to contribute Opera’s browser engine expertise to Blink, ranging from the implementation of new web standards to improvements in existing code.”

My personal feeling (not representing my employer, wife, children or hamster) is that Blink has a lot of promise for the Web. Its architecture allows for greater speed – something that Opera and Google have long focused on. When browsers are fast and interoperable, using the web as a platform becomes more competitive against native app development. I also hope that it’s easier for smaller players and even individuals to contribute to the new rendering engine, with a more transparent gatekeeping process: “Our goal is for anyone to be able to participate, regardless of organizational affiliation.”

It’s also great that there will be no more vendor prefixes in Blink (only legacy ones inherited from WebKit that will be removed or dropped where possible). Vendor prefixes were like Morrissey’s solo career: on paper, a good idea – but in reality, a horrible mess.

So, hello Blink. With Presto remaining in the wild until 2020, and Firefox’s co-incidental announcement today that it’s collaborating with Samsung on two early stage projects to build a new rendering engine called Servo, diversity on the Web has never looked healthier, and interoperability never (er) interoperabler.

Save bandwidth with webP – soon with fallback!

A long time ago, “responsive” didn’t mean “resize your browser window repeatedly while fellow designers orgasm until they resemble a moleskine atop a puddle”. It simply meant “Reacting quickly and positively”, meaning that the page loaded fast and you could interact with it immediately.

One way to do this is to reduce the weight of the page by serving images that have a smaller file-size, thereby consuming less bandwidth and taking less time to download a page. In the last year, web pages download approximately the same number of images, but their total size has increased from about 600K to 812K, making images about 60% of the total page size.

One way to reduce this amount is to encode images in a new(ish) format called webP. It’s developed by Google and is basically a still version of their webM video codec. Google says

WebP is a new image format that provides lossless and lossy compression for images on the web. WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller in size compared to JPEG images at equivalent SSIM index. WebP supports lossless transparency (also known as alpha channel) with just 22% additional bytes. Transparency is also supported with lossy compression and typically provides 3x smaller file sizes compared to PNG when lossy compression is acceptable for the red/green/blue color channels.

Opera uses it precisely for this compression; it’s used in Opera Turbo, which can be enabled in Opera desktop, Opera Mobile and the Chromium-based Yandex browser. This transcodes images on-the-fly to webP before squirting them down the wire and, on slower connections, it’s still faster.

In tests, Yoav Weiss reported that “Using WebP would increase the savings to 61% of image data”.

WebP is currently supported only in Opera (Presto), Google Chrome, Yandex and Android Browser on Ice Cream Sandwich, which makes it difficult to deploy on the Web. Firefox doesn’t like it and IE hasn’t said anything (I wonder if the new confidence about technologies in the VP8 video codec on which it’s based might make them feel better about it?)

However, there’s some handy new CSS coming to the rescue soon (when browser vendors implement it). We’ve long been able to specify CSS background images using background-image: url(foo.png);, but now say hello to CSS Image Values and Replaced Content Module Level 4’s Image Fallbacks, which uses this syntax:

background-image: image("wavy.webp", "wavy.png", "wavy.gif");

(Note image rather than url before the list of images.)

The spec says “Multiple ‘image -srcs’ can be given separated by commas, in which case the function represents the first image that’s not an invalid image.”

Simply: go through the list of images and grab the first you can use. If it 404s, continue going through the list until you find one you can use. Note that this isn’t supported anywhere yet, but I hope to see it soon.

[Added after a reminder from Yoav Weiss:] It needs finessing too; Jake Archibald points out “If the browser doesn’t support webp it will still download ‘whatever.webp’ and attempt a decode before it’ll fallback to the png” and suggests adding a format() qualifier, from @font-face:

background-image: image("whatever.webp" format('webp'), "whatever.jpg");

But what about old [current] browsers?, I hear you ask. Give them the current url syntax as fallback:

background-image: url("wavy.gif");
background-image: image("wavy.webp", "wavy.png", "wavy.gif");

Now all browsers get a background image, and those that are clever enough to understand webP get smaller images. Of course, you have to make a webP version (there are webP conversion tools, including a Photoshop plugin).

It seems to me that the spec is overly restrictive, as it seems to require the browser to use the first image that it can. webP is heavily compressed so requires more CPU to decode than traditional image formats. Therefore, I could imagine a browser that knows it’s on WiFi and using battery (not plugged in) to choose not to use webP and choose a PNG/ JPG etc to save CPU cycles, even though the file-size is likely to be larger.

What about content images?

Of course, not all images on your webpages are CSS background images. Many are content images in <img> elements, which doesn’t allow fallbacks.

There is, however, an HTML5 element that deliberately allows different source files to get over the fact that browsers understand different media formats:

<video>
<source src=foo.webm type=video/webm>
<source src=foo.mp4 type=video/mp4>
... fallback content ...
</video>

Wouldn’t it be great if we could use this model for a New! Improved! <img> element? We couldn’t call it <image> as that would be too confusing and the HTML5 parser algorithm aliases <image> to <img> (thanks Alcohi). So for the sake of thought experimentation, let’s call it <picture> (or, if we’re bikeshedding, <pic> or —my favourite— <bruce>). Then we could have

<picture>
<source src=foo.webp type=image/webp>
<source src=foo.png type=image/png>
<img src=foo.png alt="insert alt text here"> <!-- fallback content -->
</picture>

And everyone gets their images, and some get them much faster.