Archive for the 'Opera' Category

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.

On the styling of forms

The earliest incarnation of the specification that we now call “HTML5″ was an extension of HTML forms, called Web Forms 2.0 (Working Draft 5 February 2004 – almost nine years ago!). It contained lots of cool stuff that’s in the spec today, like <input type=”date”>, <input type=”email”>, the required attribute, and cool stuff that never made it to the final spec like <input type=”location”> and repeating templates (the latter was implemented in Opera, and subsequently removed in 2010).

When I first started talking about HTML5, I’d show these new forms controls to developers, who were all initially very excited. After all, who wants to code JavaScript date-pickers, or email validation routines? But the excitement dissipated after the inevitable question about how you can style the forms and their error messages.

The answer is that unfortunately you can’t very well. You can apply some styling – for example, making invalid or out-of-range inputs have a different border colour with CSS pseudoclasses, as defined in the CSS Basic UI module input:invalid {border:2px solid red;}, but this was badly thought out because, for example, fields with a required attribute are “invalid” at page load and therefore take the ugly styles before the user has even begun to interact with the form. Mozilla implemented their own -moz-ui-invalid mechanism that solves the problem:

If the element is required, the preceding rules apply only if the user has changed the value or attempted to submit the form.

It’s only implemented in Firefox, as it’s proprietary, but it’s a really good idea and informed a W3C proposed :user-error pseudoclass:

The :user-error pseudo-class represents an input element with incorrect input, but only after the user has significantly interacted with it.

This is good, but only deals with styling erroneous input fields. Error messages can be styled in WebKit using proprietary pseudoelements ::-webkit-validation-bubble, ::-webkit-validation-bubble-arrow-clipper, ::-webkit-validation-bubble-arrow, ::-webkit-validation-bubble-message. There’s no cross-browser proposal at W3C, but Peter Gasston has interesting ideas. The only reliable way at the moment to control the appearance of validation is turn it off with <form novalidate …> and script your own, which rather defeats the purpose.

There are no real ways of styling the controls themselves. The HTML5 spec is mostly silent on styling matters (and rightly so); the CSS Basic UI module would be a natural place for it, but that hasn’t been touched for a year, and before that update had languished for half a decade. Of course, this isn’t a trivial problem. <input type=”date”> might be rendered as a pop-up calendar widget on a desktop browser, and you may wish to “grey out” weekends – but are weekends Saturday and Sunday? or Friday and Saturday? How would you achieve that in CSS? input[type=date]::friday {color:gray;}? And the same browser’s mobile version might use the operating system’s native date picking UI, in which case it would probably be unstylable anyway.

And what of sliders? When you have a pointer/ grabber, its track and tickmarks, what would input[type=range] {color: red;} change? Bear in mind that most browsers don’t follow the one styling suggestion that the spec does offer, which is to render vertical sliders when the input’s CSS height exceeds the width.

One thing that working in the web for a decade has taught me is that where there’s a will, clever people will solve the most head-pulsing problems. But I’m beginning to wonder if there is a will. Phenomenally brainy Tab Atkins wrote

I think any arguments that sites will refuse to use the native controls because they don’t match the site’s theme are countered by the observation that most sites using JS-library equivalents today still don’t theme them very well, or at all. I usually just see a very plain mostly-white calendar, using whatever the default color scheme is for the given library.

This doesn’t meet my experience of developers telling me they’ll continue to use things like jQuery UI because of the themes it offers.

It means that developers continue to make forms out of non-semantic elements like <div> and pile on contenteditable attributes and (hopefully) ARIA attributes and tabindex to make them accessible, even though native form controls are accessible by default.

Anne van Kesteren discusssed this in his clean markup plea:

Write whatever the fuck you want with some WAI-ARIA sugar on top is in some scenarios the only thing what works right now. I do not believe that means we should just let it run its course. The real solution to making a button implemented using five div elements and some scripting accessible is not WAI-ARIA. It is to drastically improve the styling capabilities of <input type=”button”>.

Quite.

Co-chair of the W3C HTML5 Working Group, Apple’s Maciej Stachowiak tried to get some traction for specifying form styling in 2010:

Popular sites are applying a great deal of custom styling to form controls. One example page we love to use here is google.com. If you take a peek in, say, Safari or Firefox, you can see that Google has put a lot of custom styling on the text field and the two <input type=submit> buttons on their home page. This lets them have a custom look while still working in old or obscure browsers, or in browsers with script disabled, and to provide good accessibility while maintaining fairly compact markup. But by styling form controls at all, they are in a no-man’s land in terms of standards. We need to bring this technique into the real of interoperable-specified behavior.

…but to no avail. So what is to be done? The Shadow DOM may help. Shadow DOM gives you access to the internals of browser widgets; for example, the buttons in a <video> element that the browser provides when you specify the controls attribute. It’s a work in progress, part of the suite of specifications called Web Components. Spec editor Dimitri Glazkov writes

Shadow DOM specifies that all HTML elements must behave as if they already have an existing, UA-provided shadow tree, which in turn allows the author-created shadow trees to properly override and even include) those UA-provided shadow trees.

You should be able to do the same exact thing with every other element (though there’s a very tricky issue with IMG, VIDEO, OBJECT, et al. about the nature of “the insides” of the actual replaced content that will need to be first resolved by CSS WG).

So, again, back to the CSS Working Group. I’d like to ask them, when they’re specifying the insides of replaced content, that they do the same with form controls, and give us pseudoelements.

As Tab Atkins continued:

…us devs are mostly lazy, and love being able to write a simple element instead of piping in a library just to do a crappy calendar.

Tab’s absolutely right. And developers really start to use features when they’re specified in languages they already use. We’ve seen this with CSS transitions, animations and filters, all of which were possible for ages in SVG but that was something extra to learn.

The Shadow DOM is potentially a great advance in web development, but it’s a whole new set of technologies. Allowing form styling through CSS would make it simple and allow developers to satisfy the marketing department’s demand for sliders in corporate heliotrope and goldenrod, while using native, accessible controls rather than JavaScript libraries, ARIA bolt-ons and abusing semantics.

If you’re a developer, let me know if you use the native HTML5 form inputs, or – if you use some JS library – do you adjust them to suit your site?

Notes on Contents Strategy Forum 2012, Cape Town

I was fortunate enough to be invited to speak at Content Strategy Forum 2012 which was previously in Paris and London, and this year went to Cape Town. I used to be a content bloke; in fact, I now realise that at The Law Society I was a Content Strategist, there just wasn’t a name for it in 2008.

But that was four years ago, so for this conference I was firmly out of my [American accent] “comfort zone”. Fortunately, I had a preparatory natter with Rellington Annett-Baker to ensure my introductory HTML5 for content specialists talk was likely to hit their sweet spots and tickle their fancies. (It seemed to work.)

The conference was headlined by Kristina Halvorson, and Luke Wroblewski, both of whom seemed to disagree with each other. I’m not well-versed in Content Strategy schisms to have an opinion either way, although Luke’s assertion that we now have a write-read web rang true. Kristina is the godmother of Content Strategy, so her talk was a “state of the nation” speech from paper notes (she’d lost her laptop), largely about how she’d grown her agency to 28 people and then laid off all but five.

Other notable talks were by Razorfish’s Rachel Lovinger who talked about structuring content for re-use, using standards and responsive design in Content in the Age of Promiscuous Reuse.

Relly Annett-Baker’s “Guerillas in their midst” was a fun, British talk about guerilla content strategy. Relly is a black belt at on-stage swearing (I was on best behaviour; these are her friends).

Richard Ingram did an interesting talk about visualising data and recommended the really good Scraping for Journalists book which taught me loads in the first chapter.

John Alderman gave an entertaining talk on how to use Big Data. In it, he spoke about meet-ups where people discuss data they’ve collected about their own bodies. (Yup.) He’d probably be interested in Pete Fletcher’s sneezecount project documenting his sneezes since July 2007 (also see his 5 minute Ignite video On the Counting of Sneezes) and Manu Sporny open-sourcing his genetic data on GitHub.

Great thanks to the organisers: Kerry-Anne Gilowey, Rian van der Merwe, Nathan Blows and Irene Walker. Organisation was perfect; they even managed to get a Cheetah!

Bruce and Luke W stroking a cheetah

I’m no Content Strategist, so I might be entirely wrong, but it felt that this conference was somehow a pivotal event in the solidifying a community. It reminded me of the @media conference of 2005, in which loads of UK web developers first met each other and realised that there is actually a community of UK front-enders and we’re not just a collection of lonely weirdos who read A List Apart. Friendships began; businesses were formed, networks opened and a community came of age. I wonder if Content people in Africa will look back at CSForum 2012 like that.

South Africa

I stuck around in Cape Town for a while, hobnobbing with the great and the good, doing five press interviews, giving some tech talks for developers and business people at Saatchi and Saatchi and the workplace of an old friend Allan Kent who’s Head of Digital at South Africa’s leading media group, Primedia.

An impromptu meet-up was arranged by a Sean O’Connell, a front-end dev, and hosted by Paul Cartmel at New Media Labs (thanks chaps). It was over-subscribed, and too many pizzas and beers were bought; we soldiered on, drinking too much beer and eating too much pizza. (Banana on pizza is wrong, by the way).

I did a talk on why standards are great and good for business (sorry about ugly slides; there wasn’t much time and I preferred gawping at penguins, Chapman’s Peak and brunching with beautiful people to wrangling presentation software!).

In amongst meet-ups and press interviews I did some sight-seeing, mostly under the kindly protection of Allan and saintly Wendy who drove me round to look at Cape Point, Simons Town, Kommetjie, Boulders and other gorgeous places. Their hospitality meant I saw so much I wouldn’t otherwise have done. Thanks so much to both of them.

On my last day, I skived emails after the last press interview and went to Robben Island where the apartheid-era political prisoners were kept. Having been to Auschwitz and Cambodia’s killing fields this year, I didn’t need another reminder of how vile people can be to each other. One redemptive thing about Robben Island, though, is that there are still ex-prisoners and ex-guards living on the island, giving tours around the prison.

On my last night, South Africa’s leading pointillist painter, Gavin Rain, picked me up in his posh car and we drove to Camps Bay where all the beautiful people go. Unfortunately, I was so affected by some twilight Death Pollen that I had to wear my shades all night (not uncommon in Camps Bay). But it did mean my attempts at mild flirtation with the gorgeous Kenyan waitress came to naught, as she doubtless thought Gavin and I were a gay couple splitting up and that I was crying in grief.

My guidebook – which should be renamed “The Alarmist Guide to Cape Town” – had cautioned me never to step out of my hotel or I’d have my kidneys removed. I never felt at all threatened in Cape Town’s CBD. In fact, just the opposite; it was vibrant, friendly and fun.

I don’t know what I expected of South Africa. I suppose I imagined lots of grumpy Afrikaanas trying to pretend they’d never been racist, and desperately poor black people. There certainly are many desperately poor black people; white South African households’ income is six times higher than black ones according to the latest census. And it seems to me that the elder statesmen like Mandela, Sisulu etc are gone, leaving a outrageously corrupt group governing the country.

But it felt to me (from my admittedly brief visit, cocooned in nice hotels in a prosperous city) that South Africa is on its way up, rather than down to Zimbabwe-like failed statehood. The workplaces I visited were highly multi-racial, as you’d expect given the demographics but as you might not expect given the recent history of the country.

Cape Town is probably the most beautifully situated city I’ve visited, with excellent cuisine (mmm, ostrich steaks and Bunnychow). All that, plus I got to talk to interesting people about cool stuff meant that I had a splendid time. Thanks so much to all those I met who made it so memorable.

Reading List

NEWT

Industry

Misc

I had a lovely week in Norway, where my Opera devrel colleagues and I illustrate how we open the Web.

members of Opera's devrel team pull open a large red letter 'O' Opera logo

Reading list

CSS

Standards

Industry

Super-NSFW Corner

  • Fifty Shades Generator – Traditionally, print and web designers had to make use of placeholder text known as Lorem Ipsum. Now, creatives can excite clients in more ways than one with Fifty Shades of Grey-inspired filler text.”

Reading List

NEWT

Sublime Text 2

I haven’t actually enjoyed using an editor since VAX EDT in my old programming days, but Sublime Text 2 is an excellent program that not only doesn’t get in the way but has lots of utilities and features.

Industry

Dell Extends Ubuntu Retail into India – Unreported, of course, because it’s about FOREIGNERS, but Dell have been featuring Ubuntu on a wide range of Dell computers in China, starting at 220 stores and expanding to 350. They’re also expanding in to 850 stores across India.

misc