Develop looks at the platform with ambitions to challenge Adobe's ubiquitous Flash web player
Initially heralded as the future of
browser gaming and the next step beyond the monopolised world of Flash,
HTML5 has since faced criticism for being tough to code with and
possessing a string of broken features.
The coding platform, the fifth iteration of the HTML standard, was
supposed to be a one stop shop for developers looking to create and
distribute their game to a multitude of platforms and browsers, but
things haven’t been plain sailing.
Not just including the new HTML mark-up language, but also
incorporating other features and APIs such as CSS3, SVG and JavaScript,
the platform was supposed to allow for the easy insertion of features
for the modern browser such as video and audio, and provide them without
the need for users to install numerous plug-ins.
And whilst this has worked to a certain degree, and a number of
companies such as Microsoft, Apple, Google and Mozilla under the W3C
have collaborated to bring together a single open standard, the problems
it possesses cannot be ignored.
That’s what Mozilla’s Director of Research Andreas Gal thinks of
Google’s purportedly ‘open source’ mobile operating system. In Gal’s
view Google’s platform is no different from Apple’s iOS. The entire
platform – including its design, development, and direction – is
‘dominated by Google.’
According to Gal, ‘Google makes all of the technological decisions
behind closed doors and pushes them outwards. You may or may not get a
look at the source after the device comes out. But it’s certainly not
open. And in this sense it’s no different from Apple’s platform, except
that maybe sometimes you get access to the source.’
And this is where Mozilla comes into the equation. Boot 2 Gecko is
based solely on HTML5, JavaScript and CSS and is completely open source.
Mozilla doesn’t even keep a ‘physical’ copy of the source code in its
offices – everything to do with the platform is available online for all
to see.
Brendan Eich, Mozilla’s co-founder (and the inventor of JavaScript),
told Know Your Mobile that the days of native shells (iOS/Android) and
proprietary software (Objective-C) could soon be over as Mozilla
continues to standardise and implement Open Web APIs that will one day
eradicate the need for separate platforms, allowing users to find and
use apps on their mobiles without having to opt into a privately owned
platform.
‘Separate platforms are no longer necessary once you have the correct standardisation and inter-operation,’ said Eich.
Apple’s iOS, Microsoft’s Windows Phone, RIM’s BlackBerry OS 10 and
Google’s Android operating systems are all ‘walled gardens,’ according
to Gal, meaning that all of the above are in it for one reason: to make
money.
‘Google builds Android not for your benefit but for Google’s benefit,
and the shareholders it has to satisfy. This is the same with Apple,’
said Gal. He added: ‘Mozilla is very different – we are a non-profit
organisation. In the past Mozilla was all about making the web better.
But now people are going to mobile, so we’re following them there.’
‘What we’ve developed [with B2G] is a completely open stack that is
100 per cent free. We have a publicly visible repository and all the
development happens in the open. We use completely open standards and
there’s no propriety software or technology involved.’
So what is Mozilla getting at here? Simple: dump the standard
smartphone operating system, forget Apple and Google, and embrace the
freedom of pure HTML5.
Gal tells us that because the B2G stack is based on HTML5 there are
literally millions of developers out there that know how to create
content for the platform. There will also be plenty of opportunities for
developers to make money from their creations as well, according to
Gal.
Google and Mozilla have developed technology that lets web developers
manifest their entire site, including payment methods, into an icon
that can be placed on a B2G device’s homescreen.
But all this, Gal tells us, is still work in progress. Boot 2 Gecko
is still in its embryonic stages at present – but the ball has certainly
begun rolling.
‘We’re working with operators to create an easy way for customers to
pay for content,’ said Gal. ‘Mobile users want to go to a store,
discover content and pay for it easily. We’re working on making this a
reality inside B2G via personal identity systems.’
Persona, featuring BrowserID, is one such personal identity system.
Persona lets users use their email address and a single password to sign
in or buy materials and media. Mozilla demoed Persona at MWC 2012.
‘You own your applications. You own your data and you have the power
to take them wherever you like,’ said Eich. ‘And this will be dependent
on things like Persona, which is the most secure and safe password free
sign-on and the identity providers don’t see all of your details like
they would with Facebook Connect, for instance.’
He added: ‘the end result is an “unwalled garden” where you’re free
to move around without being forced into opting fully into one
platform.’
But what’s most impressive about B2G is how well it runs on low-end
hardware. During our meeting with Gal and Eich, we got a demo of B2G
running incredibly smoothly on a $60 handset with a 600Mhz CPU and just
128MB of RAM. Gaming, web browsing, video and typing were all seamless.
Gal also confirmed that Qualcomm is partnering with Mozilla on its B2G project.
B2G is based on the same web-rendering engine as Mozilla’s Firefox
browser, meaning that it is extremely lightweight when compared to
Android and iOS. For this reason getting smartphone-level performance
out of a budget mobile handset suddenly becomes a reality.
‘There are so many opportunities for technology like this [B2G] in
emerging countries. What people are looking for there is a solid
smartphone experience – browsing, web browsing and applications – at a
decent price point. Users’ in India, for instance, cannot afford
Google’s quad-core devices but they could afford a $60 HTML5-powered B2G
handset.’
‘Google’s Android platform is too hardware dependent,’ says Gal.
‘Android 4.0 demands 512MB of RAM as a minimum for instance. Mozilla’s
web stack allows OEMs to produce $60 handsets with smartphone-like
performance,’ said Gal.
He added: ‘But of course if you add in extra hardware for higher tier phones, the performance will only get better.’
It's no secret that there's big money to be made in violating your
privacy. Companies will pay big bucks to learn more about you, and
service providers on the web are eager to get their hands on as much
information about you as possible.
So what do you do? How do you keep your information out of everyone
else's hands? Here's a guide to surfing the web while keeping your
privacy intact.
The adage goes, "If you're not paying for a service, you're the
product, not the customer," and it's never been more true. Every day
more news breaks about a new company that uploads your address book to their servers, skirts in-browser privacy protection, and tracks your every move on the web
to learn as much about your browsing habits and activities as possible.
In this post, we'll explain why you should care, and help you lock down
your surfing so you can browse in peace.
Why You Should Care
Your personal information is valuable. More valuable than you might think. When we originally published our guide to stop Facebook from tracking you around the web,
some people cried "So what if they track me? I'm not that important/I
have nothing to hide/they just want to target ads to me and I'd rather
have targeted ads over useless ones!" To help explain why this is
short-sighted and a bit naive, let me share a personal story.
Before I joined the Lifehacker team, I worked at a company that
traded in information. Our clients were huge companies and one of the
services we offered was to collect information about people, their
demographics, income, and habits, and then roll it up so they could get a
complete picture about who you are and how to convince you to buy their
products. In some cases, we designed web sites and campaigns to
convince you to provide even more information in exchange for a coupon,
discount, or the simple promise of other of those. It works very, very
well.
The real money is in taking your data and shacking up with third parties to help them
come up with new ways to convince you to spend money, sign up for
services, and give up more information. Relevant ads are nice, but the
real value in your data exists where you won't see it until you're too
tempted by the offer to know where it came from, whether it's a coupon
in your mailbox or a new daily deal site with incredible bargains
tailored to your desires. It all sounds good until you realize the only
thing you have to trade for such "exciting" bargains is everything
personal about you: your age, income, family's ages and income, medical
history, dietary habits, favorite web sites, your birthday...the list
goes on. It would be fine if you decided to give up this information for
a tangible benefit, but you may never see a benefit aside from an ad,
and no one's including you in the decision. Here's how to take back that
control.
Click for instructions for your browser of choice:
How to Stop Trackers from Following Where You're Browsing with Chrome
If you're a Chrome user, there are tons of great add-ons and tools
designed to help you uncover which sites transmit data to third parties
without your knowledge, which third parties are talking about you, and
which third parties are tracking your activity across sites. This list
isn't targeted to a specific social network or company—instead, these
extensions can help you with multiple offenders.
Adblock Plus
- We've discussed AdBlock plus several times, but there's never been a
better time to install it than now. For extra protection, one-click
installs the Antisocial
subscription for AdBlock. With it, you can banish social networks like
Facebook, Twitter, and Google+ from transmitting data about you after
you leave those sites, even if the page you visit has a social plugin on
it.
Ghostery -
Ghostery does an excellent job at blocking the invisible tracking
cookies and plug-ins on many web sites, showing it all to you, and then
giving you the choice whether you want to block them one-by-one, or all
together so you'll never worry about them again. The best part about
Ghostery is that it's not just limited to social networks, but will also
catch and show you ad-networks and web publishers as well.
ScriptNo for Chrome
- ScriptNo is much like Ghostery in that any scripts running on any
site you visit will sound its alarms. The difference is that while
Ghostery is a bit more exclusive about the types of information it
alerts you to, ScriptNo will sound the alarm at just about everything,
which will break a ton of websites. You'll visit the site, half
of it won't load or work, and you'll have to selectively enable scripts
until it's usable. Still, its intuitive interface will help you choose
which scripts on a page you'd like to allow and which you'd like to
block without sacrificing the actual content on the page you'd like to
read.
Do Not Track Plus - The "Do Not Track" feature that most browsers have is useful, but if you want to beef them up, the previously mentioned
Do Not Track Plus extension puts a stop to third-party data exchanges,
like when you visit a site like ours that has Facebook and Google+
buttons on it. By default, your browser will tell the network that
you're on a site with those buttons—with the extension installed, no
information is sent until you choose to click one. Think of it as opt-in
social sharing, instead of all-in.
Ghostery, AdBlock Plus, and Do Not Track are the ones you'll need the
most. ScriptNo is a bit more advanced, and may take some getting used
to. In addition to installing extensions, make sure you practice basic
browser maintenance that keeps your browser running smoothly and
protects your privacy at the same time. Head into Chrome's Advanced
Content Settings, and make sure you have third-party cookies blocked and
all cookies set to clear after browsing sessions. Log out of social
networks and web services when you're finished using them instead of
just leaving them perpetually logged in, and use Chrome's "Incognito
Mode" whenever you're concerned about privacy.
Mobile Browsing
Mobile browsing is a new frontier. There are dozens of mobile
browsers, and even though most people use the one included on their
device, there are few tools to protect your privacy by comparison to the
desktop. Check to see if your preferred browser has a "privacy mode"
that you can use while browsing, or when you're logged in to social
networks and other web services. Try to keep your social network use
inside the apps developed for it, and—as always—make sure to clear your
private data regularly.
If none of these extensions make you feel any better, or you want to
take protecting your privacy and personal data to the next level, it's
time to break out the big guns. One tip that came up during our last
discussion about Facebook was to use a completely separate web browser
just for logged-in social networks and web services, and another browser
for potentially sensitive browsing, like your internet shopping,
banking, and other personal activities. If you have some time to put
into it, check out our guide to browsing without leaving a trace, which was written for Firefox, but can easily be adapted to any browser you use.
If you're really tired of companies tracking you and trading in your
personal information, you always have the option to just provide false
information. The same way you might give a fake phone number or address
to a supermarket card sign-up sheet, you can scrub or change personal
details about yourself from your social network profiles, Google
accounts, Windows Live account, and others.
Change your birthdate, or your first name. Set your phone number a
digit off, or omit your apartment number when asked for your street
address. We've talked about how to disappear before,
and carefully examine the privacy and account settings for the web
services you use. Keep in mind that some of this goes against the terms
of service for those companies and services—they have a vested interest
in knowing the real you, after all, so tread carefully and tread lightly
if you want to go the "make yourself anonymous" route. Worst case,
start closing accounts with offending services, and migrate to other,
more privacy-friendly options.
These are just a few tips that won't significantly change your
browsing experience, but can go a long way toward protecting your
privacy. This issue isn't going anywhere, and as your personal
information becomes more valuable and there are more ways to keep it
away from prying eyes, you'll see more news of companies finding ways to
eke out every bit of data from you and the sites you use. Some of these
methods are more intrusive than others, and some of them may turn you
off entirely, but the important thing is that they all give you
control over how you experience the web. When you embrace your privacy,
you become engaged with the services you use. With a little effort and
the right tools, you can make the web more opt-in than it is opt-out.
Microsoft announced that it will be launching silent updates for IE9 in January.
Despite
the controversy of user control, Microsoft especially has a reason to
make this move to react to browser "update fatigue" that has resulted in
virtually "stale" IE users who won't upgrade their browsers unless they
upgrade their operating system as well.
The most recent upgrade of Google's Chrome browser
shows just how well the silent update feature works. Within five days
of introduction, Chrome 15 market share fell from 24.06 percent to just
6.38 percent, while the share of Chrome 16 climbed from 0.35 percent to
19.81 percent, according to StatCounter.
Within five days, Google moved about 75 percent of its user base - more
than 150 million users - from one browser to another. Within three
days, Chrome 16 market share surpassed the market share of IE9
(currently at about 10.52 percent for this month), in four days it
surpassed Firefox 8 (currently at about 15.60 percent) and will be
passing IE8 today, StatCounter data indicates.
What makes this data so important is the fact that Google is
dominating HTML5 capability across all operating system platforms and
not just Windows 7, where IE9 has a slight advantage, according to
Microsoft (StatCounter does not break out data for browser share on
individual operating systems). IE9 was introduced on March 14 of 2011,
has captured only 10.52 percent market share and has followed a similar
slow upgrade pattern as its predecessors. For example, IE, which was
introduced in March 2009, reached its market share peak in the month IE9
was introduced - at 30.24 percent. Since then, the browser has declined
to only 22.17 percent and 57.52 percent of the IE user base still uses
IE8 today.
With the silent updates becoming available for IE8 and IE9,
Microsoft is likely to avoid another IE6 disaster with IE8. Even more
important for Microsoft is that those users who update to IE9 may be
less likely to switch to Chrome.
Once Upon is a brilliant project that has recreated three popular sites from today as if they were built in the dial-up era, in 1997.
Witness Facebook, with no real-names policy and photos displayed in
an ugly grey table; YouTube, with a choice of encoding options to select
before you watch a video, and Google+, where Circles of contacts are
displayed as far easier to render squares. Be prepared for a wait though
– the recreations are limited to 8kbps transfer speeds, as if you were
loading it on a particularly slow dial-up connection.
This is perhaps the most extreme version of Web nostalgia we’ve seen. On a related note, these imaginings of what online social networking would have been like in centuries gone by are worth a look. Also, our report on 10 websites that changed the world is worth reading- they’re not what you might expect.
Focus in future will be on HTML5 as mobile world shifts towards
non-proprietary open standards – and now questions will linger over use
of Flash on desktop
Adobe is killing off development of its
mobile Flash plugin, and laying off 750 staff as part of broader
restructuring. Photograph: Paul Sakuma/AP
Mobile Flash is being killed off. The plugin that launched a thousand online forum arguments and a technology standoff between Apple and the format's creator, Adobe,
will no longer be developed for mobile browsers, the company said in a
note that will accompany a financial briefing to analysts.
Instead the company will focus on development around HTML5
technologies, which enable modern browsers to do essentially the same
functions as Flash did but without relying on Adobe's proprietary
technologies, and which can be implemented across platforms.
The existing plugins for the Android and BlackBerry platforms will be given bug fixes and security updates, the company said in a statement first revealed by ZDNet. But further development will end.
The
decision also raises a question mark over the future of Flash on
desktop PCs. Security vulnerabilities in Flash on the desktop have been
repeatedly exploited to infect PCs in the past 18 months, while Microsoft
has also said that the default browser in its forthcoming Windows 8
system, expected at the end of 2012, will not include the Flash plugin
by default. Apple, which in the third quarter captured 5% of the world
market, does not include Flash in its computers by default.
John Nack, a principal product manager at Adobe, commented on his personal blog
(which does not necessarily reflect Adobe views) that: "Adobe saying
that Flash on mobile isn't the best path forward [isn't the same as]
Adobe conceding that Flash on mobile (or elsewhere) is bad technology.
Its quality is irrelevant if it's not allowed to run, and if it's not
allowed to run, then Adobe will have to find different ways to meet
customers' needs."
Around 250m iOS (iPhone, iPod Touches and iPad)
devices have been sold since 2007. There are no clear figures for how
many are now in use. More recently Larry Page, chief executive of
Google, said that a total of 190m Android devices have been activated.
It is not clear how many of those include a Flash plugin in the browser.
"Our
future work with Flash on mobile devices will be focused on enabling
Flash developers to package native apps with Adobe Air for all the major
app stores," Adobe said in the statement. "We will no longer adapt
Flash Player for mobile devices to new browser, OS version or device
configurations.
"Some of our source code licensees may opt to
continue working on and releasing their own implementations. We will
continue to support the current Android and PlayBook configurations with
critical bug fixes and security updates."
The decision comes as
Adobe plans to cut 750 staff, principally in North America and Europe.
An Adobe spokesperson declined to give any figures for the extent of
layoffs in the UK. The company reiterated its expectation that it will
meet revenue targets for the fourth quarter.
The reversal by Adobe
– and its decision to focus on the open HTML5 platform for mobile –
brings to an end a long and tumultuous row between Apple and Adobe over
the usefulness of Flash on the mobile platform. The iPhone launched in
2007 without Flash capability, as did the iPad in 2010.
Steve
Jobs, then Apple's chief executive, and Apple's engineers insisted that
Flash was a "battery hog" and introduced security and stability flaws;
Adobe countered that it was broadly implemented in desktop PCs and used
widely on the web.
Jobs's antagonism was partly driven, his
biography reveals, by Adobe's reluctance after he rejoined Apple in 1996
to port its movie-editing programs to the Mac and to keep its Photoshop
suite comparable on the Mac platform with the Windows one.
But
Jobs also insisted that mobile Flash failed in the role of providing a
good user experience, and also would restrict Apple's ability to push
forward on the iOS platform. Studies of browser crash reports by Apple's
teams showed that Flash was responsible for a signficant proportion of
user problems; Apple was also not satisfied that a Flash plugin would be
available for the first iPhone in 2007 which would not consume more
battery power than would be acceptable.
Jobs managed to persuade
Eric Schmidt, then Google's chief executive and a member of the Apple
board, to get YouTube to make videos available in the H.264 format
without a Flash "wrapper", as was then used for the desktop
implementation.
But the disagreements between Apple and Adobe
intensified, especially when Android devices began appearing which did
use the Flash plugin. Apple refused to use it, and banned apps from its
App Store which tried to use or include Flash.
In "Thoughts on Flash",
an open letter published by Jobs in April 2010, he asserted that "Flash
was created during the PC era – for PCs and mice. Flash is a successful
business for Adobe, and we can understand why they want to push it
beyond PCs. But the mobile era is about low power devices, touch
interfaces and open web standards – all areas where Flash falls short.
"New
open standards created in the mobile era, such as HTML5, will win on
mobile devices (and PCs too). Perhaps Adobe should focus more on
creating great HTML5 tools for the future, and less on criticizing Apple
for leaving the past behind."
As mobile devices have continued to evolve and spread,
so has the process of designing and developing Web sites and services
that work across a diverse range of devices. From responsive Web design
to future friendly thinking, here's how I've seen things evolve over the
past year and a half.
If
you haven't been keeping up with all the detailed conversations about
multi-device Web design, I hope this overview and set of resources can
quickly bring you up to speed. I'm only covering the last 18 months
because it has been a very exciting time with lots of new ideas and
voices. Prior to these developments, most multi-device Web design
problems were solved with device detection and many still are. But the introduction of Responsive Web Design really stirred things up.
Responsive Web Design
Responsive
Web Design is a combination of fluid grids and images with media
queries to change layout based on the size of a device viewport. It uses
feature detection (mostly on the client) to determine available screen
capabilities and adapt accordingly. RWD is most useful for layout but
some have extended it to interactive elements as well (although this
often requires Javascript).
Responsive Web Design allows you to
use a single URL structure for a site, thereby removing the need for
separate mobile, tablet, desktop, etc. sites.
For a short overview read Ethan Marcotte's original article. For the full story read Ethan Marcotte's book. For a deeper dive into the philosophy behind RWD, read over Jeremy Keith's supporting arguments. To see a lot of responsive layout examples, browse around the mediaqueri.es site.
Challenges
Responsive
Web Design isn't a silver bullet for mobile Web experiences. Not only
does client-side adaptation require a careful approach, but it can also
be difficult to optimize source order, media, third-party widgets, URL
structure, and application design within a RWD solution.
Jason Grigsby has written up many of the reasons RWD doesn't instantly provide a mobile solution especially for images. I've documented (with concrete) examples why we opted for separate mobile and desktop templates in my last startup -a technique that's also employed by many Web companies like Facebook, Twitter, Google, etc. In short, separation tends to give greater ability to optimize specifically for mobile.
Mobile First Responsive Design
Mobile
First Responsive Design takes Responsive Web Design and flips the
process around to address some of the media query challenges outlined
above. Instead of starting with a desktop site, you start with the
mobile site and then progressively enhance to devices with larger
screens.
The Yiibu team was one of the first to apply this approach and wrote about how they did it. Jason Grigsby has put together an overview and analysis of where Mobile First Responsive Design is being applied. Brad Frost has a more high-level write-up of the approach. For a more in-depth technical discussion, check out the thread about mobile-first media queries on the HMTL5 boilerplate project.
Techniques
Many
folks are working through the challenges of designing Web sites for
multiple devices. This includes detailed overviews of how to set up
Mobile First Responsive Design markup, style sheet, and Javascript
solutions.
Ethan Marcotte has shared what it takes for teams of developers and designers to collaborate on a responsive workflow based on lessons learned on the Boston Globe redesign. Scott Jehl outlined what Javascript is doing (PDF) behind the scenes of the Globe redesign (hint: a lot!).
Stephanie Rieger assembled a detailed overview (PDF)
of a real-world mobile first responsive design solution for hundreds of
devices. Stephan Hay put together a pragmatic overview of designing with media queries.
Media
adaptation remains a big challenge for cross-device design. In
particular, images, videos, data tables, fonts, and many other "widgets"
need special care. Jason Grigsby has written up the situation with images and compiled many approaches for making images responsive. A number of solutions have also emerged for handling things like videos and data tables.
Server Side Components
Combining
Mobile First Responsive Design with server side component (not full
page) optimization is a way to extend client-side only solutions. With
this technique, a single set of page templates define an entire Web site
for all devices but key components within that site have device-class
specific implementations that are rendered server side. Done right, this
technique can deliver the best of both worlds without the challenges
that can hamper each.
I've put together an overview of how a Responsive Design + Server Side Components structure can work with concrete examples. Bryan Rieger has outlined an extensive set of thoughts on server-side adaption techniques and Lyza Gardner has a complete overview of how all these techniques can work together. After analyzing many client-side solutions to dynamic images, Jason Grigsby outlined why using a server-side solution is probably the most future friendly.
Future Thinking
If
all the considerations above seem like a lot to take in to create a Web
site, they are. We are in a period of transition and still figuring
things out. So expect to be learning and iterating a lot. That's both
exciting and daunting.
It also prepares you for what's ahead.
We've just begun to see the onset of cheap networked devices of every
shape and size. The zombie apocalypse of devices is coming. And while we can't know exactly what the future will bring, we can strive to design and develop in a future-friendly way so we are better prepared for what's next.
Resources
I
referenced lots of great multi-device Web design resources above. Here
they are in one list. Read them in order and rock the future Web!
When Tim Berners-Lee arrived at CERN,
Geneva's celebrated European Particle Physics Laboratory in 1980, the
enterprise had hired him to upgrade the control systems for several of
the lab's particle accelerators. But almost immediately, the inventor of
the modern webpage noticed a problem: thousands of people were floating
in and out of the famous research institute, many of them temporary
hires.
"The big challenge for contract programmers was to try to
understand the systems, both human and computer, that ran this fantastic
playground," Berners-Lee later wrote. "Much of the crucial information
existed only in people's heads."
So in his spare time, he wrote up some software to address this
shortfall: a little program he named Enquire. It allowed users to create
"nodes"—information-packed index card-style pages that linked to other
pages. Unfortunately, the PASCAL application ran on CERN's proprietary
operating system. "The few people who saw it thought it was a nice idea,
but no one used it. Eventually, the disk was lost, and with it, the
original Enquire."
Some years later Berners-Lee returned to CERN.
This time he relaunched his "World Wide Web" project in a way that
would more likely secure its success. On August 6, 1991, he published an
explanation of WWW on the alt.hypertext usegroup. He also released a code library, libWWW, which he wrote with his assistant
Jean-François Groff. The library allowed participants to create their own Web browsers.
"Their efforts—over half a dozen browsers within 18 months—saved
the poorly funded Web project and kicked off the Web development
community," notes a commemoration of this project by the Computer History Museum in Mountain View, California. The best known early browser was Mosaic, produced by Marc Andreesen and Eric Bina at the
National Center for Supercomputing Applications (NCSA).
Mosaic was soon spun into Netscape, but it was not the first browser. A map
assembled by the Museum offers a sense of the global scope of the early
project. What's striking about these early applications is that they
had already worked out many of the features we associate with later
browsers. Here is a tour of World Wide Web viewing applications, before
they became famous.
The CERN browsers
Tim Berners-Lee's original 1990 WorldWideWeb browser was both a
browser and an editor. That was the direction he hoped future browser
projects would go. CERN has put together a reproduction
of its formative content. As you can see in the screenshot below, by
1993 it offered many of the characteristics of modern browsers.
Tim Berners-Lee's original WorldWideWeb browser running on a NeXT computer in 1993
The software's biggest limitation was that it ran on the NeXTStep
operating system. But shortly after WorldWideWeb, CERN mathematics
intern Nicola Pellow wrote a line mode browser that could function
elsewhere, including on UNIX and MS-DOS networks. Thus "anyone could
access the web," explains Internet historian Bill Stewart, "at that point consisting primarily of the CERN phone book."
Erwise came next. It was written by four Finnish college students in 1991 and released in 1992. Erwise is credited as the first browser that offered a graphical interface. It could also search for words on pages.
Berners-Lee wrote a review
of Erwise in 1992. He noted its ability to handle various fonts,
underline hyperlinks, let users double-click them to jump to other
pages, and to host multiple windows.
"Erwise looks very smart," he declared, albeit puzzling over a
"strange box which is around one word in the document, a little like a
selection box or a button. It is neither of these—perhaps a handle for
something to come."
So why didn't the application take off? In a later interview, one of
Erwise's creators noted that Finland was mired in a deep recession at
the time. The country was devoid of angel investors.
"We could not have created a business around Erwise in Finland then," he explained.
"The only way we could have made money would have been to continue our
developing it so that Netscape might have finally bought us. Still, the
big thing is, we could have reached the initial Mosaic level with
relatively small extra work. We should have just finalized Erwise and
published it on several platforms."
ViolaWWW was released in April
of 1992. Developer
Pei-Yuan Wei wrote it at the University of California at Berkeley via
his UNIX-based Viola programming/scripting language. No, Pei Wei didn't
play the viola, "it just happened to make a snappy abbreviation" of
Visually Interactive Object-oriented Language and Application, write
James Gillies and Robert Cailliau in their history of the World Wide
Web.
Wei appears to have gotten his inspiration from the early Mac
program HyperCard, which allowed users to build matrices of formatted
hyper-linked documents. "HyperCard was very compelling back then, you
know graphically, this hyperlink thing," he later recalled. But the
program was "not very global and it only worked on Mac. And I didn't
even have a Mac."
But he did have access to UNIX X-terminals at UC Berkeley's
Experimental Computing Facility. "I got a HyperCard manual and looked at
it and just basically took the concepts and implemented them in
X-windows." Except, most impressively, he created them via his Viola
language.
One of the most significant and innovative features of ViolaWWW was
that it allowed a developer to embed scripts and "applets" in the
browser page. This anticipated the huge wave of Java-based applet
features that appeared on websites in the later 1990s.
In his documentation, Wei also noted various "misfeatures" of ViolaWWW, most notably its inaccessibility to PCs.
Not ported to PC platform.
HTML Printing is not supported.
HTTP is not interruptable, and not multi-threaded.
Proxy is still not supported.
Language interpreter is not multi-threaded.
"The author is working on these problems... etc," Wei acknowledged
at the time. Still, "a very neat browser useable by anyone: very
intuitive and straightforward," Berners-Lee concluded in his review
of ViolaWWW. "The extra features are probably more than 90% of 'real'
users will actually use, but just the things which an experienced user
will want."
In September of 1991, Stanford Linear Accelerator physicist Paul
Kunz visited CERN. He returned with the code necessary to set up the
first North American Web server at SLAC. "I've just been to CERN," Kunz
told SLAC's head librarian Louise Addis, "and I found this wonderful
thing that a guy named Tim Berners-Lee is developing. It's just the
ticket for what you guys need for your database."
Addis agreed. The site's head librarian put the research center's
key database over the Web. Fermilab physicists set up a server shortly
after.
Then over the summer of 1992 SLAC physicist Tony Johnson wrote Midas, a graphical browser for the Stanford physics community. The big draw
for Midas users was that it could display postscript documents, favored
by physicists because of their ability to accurately reproduce
paper-scribbled scientific formulas.
"With these key advances, Web use surged in the high energy physics community," concluded a 2001 Department of Energy assessment of SLAC's progress.
Meanwhile, CERN associates Pellow and Robert Cailliau released the
first Web browser for the Macintosh computer. Gillies and Cailliau
narrate Samba's development.
For Pellow, progress in getting Samba up and running was slow,
because after every few links it would crash and nobody could work out
why. "The Mac browser was still in a buggy form,' lamented Tim
[Berners-Lee] in a September '92 newsletter. 'A W3 T-shirt to the first
one to bring it up and running!" he announced. The T shirt duly went to
Fermilab's John Streets, who tracked down the bug, allowing Nicola
Pellow to get on with producing a usable version of Samba.
Samba "was an attempt to port the design of the original WWW
browser, which I wrote on the NeXT machine, onto the Mac platform,"
Berners-Lee adds,
"but was not ready before NCSA [National Center for Supercomputing
Applications] brought out the Mac version of Mosaic, which eclipsed it."
Mosaic was "the spark that lit the Web's explosive growth in 1993,"
historians Gillies and Cailliau explain. But it could not have been
developed without forerunners and the NCSA's University of Illinois
offices, which were equipped with the best UNIX machines. NCSA also had
Dr. Ping Fu, a PhD computer graphics wizard who had worked on morphing
effects for Terminator 2. She had recently hired an assistant named Marc Andreesen.
"How about you write a graphical interface for a browser?" Fu
suggested to her new helper. "What's a browser?" Andreesen asked. But
several days later NCSA staff member Dave Thompson gave a demonstration
of Nicola Pellow's early line browser and Pei Wei's ViolaWWW. And just
before this demo, Tony Johnson posted the first public release of Midas.
The latter software set Andreesen back on his heels. "Superb!
Fantastic! Stunning! Impressive as hell!" he wrote to Johnson. Then
Andreesen got NCSA Unix expert Eric Bina to help him write their own
X-browser.
Mosaic offered many new web features, including support for video
clips, sound, forms, bookmarks, and history files. "The striking thing
about it was that unlike all the earlier X-browsers, it was all
contained in a single file," Gillies and Cailliau explain:
Installing it was as simple as pulling it across the network and
running it. Later on Mosaic would rise to fame because of the
<IMG> tag that allowed you to put images inline for the first
time, rather than having them pop up in a different window like Tim's
original NeXT browser did. That made it easier for people to make Web
pages look more like the familiar print media they were use to; not
everyone's idea of a brave new world, but it certainly got Mosaic
noticed.
"What I think Marc did really well," Tim Berners-Lee later wrote,
"is make it very easy to install, and he supported it by fixing bugs via
e-mail any time night or day. You'd send him a bug report and then two
hours later he'd mail you a fix."
Perhaps Mosaic's biggest breakthrough, in retrospect, was that it
was a cross-platform browser. "By the power vested in me by nobody in
particular, X-Mosaic is hereby released," Andreeson proudly declared on
the www-talk group on January 23, 1993. Aleks Totic unveiled his Mac
version a few months later. A PC version came from the hands of Chris
Wilson and Jon Mittelhauser.
The Mosaic browser was based on Viola and Midas, the Computer History museum's exhibit notes.
And it used the CERN code library. "But unlike others, it was reliable,
could be installed by amateurs, and soon added colorful graphics within
Web pages instead of as separate windows."
The Mosaic browser was available for X Windows, the Mac, and Microsoft Windows
But Mosaic wasn't the only innovation to show up on the scene around that same time. University of Kansas student Lou Montulli
adapted a campus information hypertext browser for the Internet and
Web. It launched in March, 1993. "Lynx quickly became the preferred web
browser for character mode terminals without graphics, and remains in
use today," historian Stewart explains.
And at Cornell University's Law School, Tom Bruce was writing a Web
application for PCs, "since those were the computers that lawyers tended
to use," Gillies and Cailliau observe. Bruce unveiled his browser Cello on June 8, 1993, "which was soon being downloaded at a rate of 500 copies a day."
Cello!
Six months later, Andreesen was in Mountain View, California, his
team poised to release Mosaic Netscape on October 13, 1994. He, Totic,
and Mittelhauser nervously put the application up on an FTP server. The
latter developer later recalled the moment. "And it was five minutes and
we're sitting there. Nothing has happened. And all of a sudden the
first download happened. It was a guy from Japan. We swore we'd send him
a T shirt!"
But what this complex story reminds is that is that no innovation is
created by one person. The Web browser was propelled into our lives by
visionaries around the world, people who often didn't quite understand
what they were doing, but were motivated by curiosity, practical
concerns, or even playfulness. Their separate sparks of genius kept the
process going. So did Tim Berners-Lee's insistence that the project stay
collaborative and, most importantly, open.
"The early days of the web were very hand-to-mouth," he writes. "So many things to do, such a delicate flame to keep alive."
Further reading
Tim Berners-Lee, Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web
James Gillies and R. Cailliau, How the web was born
As new platform versions get released more and more quickly,
are users keeping up? Zeh Fernando, a senior developer at Firstborn,
looks at current adoption rates and points to some intriguing trends
There's a quiet revolution happening on the web, and it's related to one aspect of the rich web that is rarely discussed: the adoption rate of new platform versions.
First,
to put things into perspective, we can look at the most popular browser
plug-in out there: Adobe's Flash Player. It's pretty well known that
the adoption of new versions of the Flash plug-in happens pretty
quickly: users update Flash Player quickly and often after a new version
of the plug-in is released [see Adobe's sponsored NPD, United
States, Mar 2000-Jun 2006, and Milward Brown’s “Mature markets”, Sep
2006-Jun 2011 research (here and here) collected by way of the Internet Archive and saved over time; here’s the complete spreadsheet with version release date help from Wikipedia].
To
simplify it: give it around eight months, and 90 per cent of the
desktops out there will have the newest version of the plug-in
installed. And as the numbers represented in the charts above show, this
update rate is only improving. That’s party due to the fact that
Chrome, now a powerful force in the browser battles, installs new
versions of the Flash Player automatically (sometimes even before it is
formally released by Adobe), and that Firefox frequently detects the
user's version and insists on them installing an updated, more secure
version.
Gone are the days where the Flash platform needed an
event such as the Olympics or a major website like MySpace or YouTube
making use of a new version of Flash to make it propagate faster; this
now happens naturally. Version 10.3 only needed one month to get to a
40.5 per cent install base, and given the trends set by the previous
releases, it's likely that the plug-in's new version 11 will break new speed records.
Any technology that can allow developers and publishers to take advantage of it in a real world scenario
so fast has to be considered a breakthrough. Any new platform feature
can be proposed, developed, and made available with cross-platform
consistency in record time; such is the advantage of a proprietary
platform like Flash. To mention one of the more adequate examples of
the opposite effect, features added to the HTML platform (in any of its
flavours or versions) can take many years of proposal and beta support
until they're officially accepted, and when that happens, it takes many
more years until it becomes available on most of the computers out
there. A plug-in is usually easier and quicker to update than a browser
too.
That has been the story so far. But that's changing.
Advertisement
Google Chrome adoption rate
Looking
at the statistics for the adoption rate of the Flash plug-in, it's easy
to see it's accelerating constantly, meaning the last versions of the
player were finding their way to the user's desktops quicker and quicker
with every new version. But when you have a look at similar adoption
rate for browsers, a somewhat similar but more complex story unfolds.
Let's
have a look at Google Chrome's adoption rates in the same manner I've
done the Flash player comparisons, to see how many people had each of
its version installed (but notice that, given that Chrome is not used by
100 per cent of the people on the internet, it is normalised for the
comparison to make sense).
The striking thing here is that the adoption rate of Google Chrome manages to be faster than Flash Player itself [see StatOwl's web browser usage statistics, browser version release dates from Google Chrome on
Wikipedia]. This is helped, of course, by the fact that updates happens
automatically (without user approval necessary) and easily (using its smart diff-based update engine to
provide small update files). As a result, Chrome can get to the same 90
per cent of user penetration rate in around two months only; but what
it really means is that Google manages to put out updates to their HTML engine much faster than Flash Player.
Of
course, there's a catch here if we're to compare that to Flash Player
adoption rate: as mentioned, Google does the same auto-update for the
Flash Player itself. So the point is not that there's a race and
Chrome's HTML engine is leading it; instead, Chrome is changing the
rules of the game to not only make everybody win, but to make them win faster.
Opera adoption rate
The
fast update rate employed by Chrome is not news. In fact, one smaller
player on the browser front, Opera, tells a similar story.
Opera also manages to have updates reach a larger audience very quickly [see browser version release dates from History of the Opera web browser, Opera 10 and Opera 11
on Wikipedia]. This is probably due to its automatic update feature.
The mass updates seem to take a little bit longer than Chrome, around
three months for a 90 per cent reach, but it's important to notice that
its update workflow is not entirely automatic; last time I tested, it
still required user approval (and Admin rights) to work its magic.
Firefox adoption rate
The
results of this browser update analysis start deviating when we take a
similar look at the adoption rates of the other browsers. Take Firefox,
for example:
It's also clear that Firefox's update rate is accelerating (browser version release dates from Firefox on
Wikipedia), and the time-to-90-per-cent is shrinking: it should take
around 12 months to get to that point. And given Mozilla's decision to
adopt release cycles that mimics Chrome's,
with its quick release schedule, and automatic updates, we're likely to
see a big boost in those numbers, potentially making the update
adoption rates as good as Chrome's.
One interesting point here is
that a few users seem to have been stuck with Firefox 3.6, which is the
last version that employs the old updating method (where the user has
to manually check for new versions), causing Firefox updates to spread
quickly but stall around the 60 per cent mark. Some users still need to
realise there's an update waiting for them; and similarly to the problem the Mozilla team had to face with Firefox 3.5, it's likely that we'll see the update being automatically imposed upon users soon, although they'll still be able to disable it. It's gonna be interesting to see how this develops over the next few months.
What does Apple's Safari look like?
Safari adoption rate
Right now, adoption rates seem on par with Firefox (browser version release dates from Safari on
Wikipedia), maybe a bit better, since it takes users around 10 months
to get a 90 per cent adoption rate of the newest versions of the
browser. The interesting thing is that this seems to happen in a pretty solid
fashion, probably helped by Apple's OS X frequent update schedule,
since the browser update is bundled with system updates. Overall, update
rates are not improving – but they're keeping at a good pace.
Notice
that the small bump on the above charts for Safari 4.0.x is due to the
public beta release of that version of the browser, and the odd area for
Safari 4.1.x is due to its release in pair with Safari 5.0.x, but for a
different version of OSX.
IE adoption rate
All in all it seems to me that browser vendors, as well as the users, are starting to get it. Overall, updates are happening faster and the cycle from interesting idea to a feature that can be used on a real-world scenario is getting shorter and shorter.
There's just one big asterisk in this prognosis: the adoption rate for the most popular browser out there.
The adoption rate of updates to Internet Explorer is not improving at all (browser version release dates from Internet Explorer on Wikipedia). In fact, it seems to be getting worse.
As
is historically known, the adoption rate of new versions of Internet
Explorer is, well, painstakingly slow. IE6, a browser that was released
10 years ago, is still used by four per cent of the IE users, and newer
versions don't fare much better. IE7, released five years ago, is still
used by 19 per cent of all the IE users. The renewing cycle here is so
slow that it's impossible to even try to guess how long it would take
for new versions to reach a 90 per cent adoption rate, given the lack of
reliable data. But considering update rates haven't improved at all for
new versions of the browser (in fact, IE9 is doing worse than IE8 in
terms of adoption), one can assume a cycle of four years until any released version of Internet Explorer reaches 90 per cent user adoption. Microsoft itself is trying to make users abandon IE6,
and whatever the reason for the version lag – system administrators
hung up on old versions, proliferation of pirated XP installations that
can't update – it's just not getting there.
And the adoption rates
of new HTML features is, unfortunately, only as quick as the adoption
rate of the slowest browser, especially when it's someone that still
powers such a large number of desktops out there.
Internet Explorer will probably continue to be the most popular browser for a very long time.
The long road for HTML-based tech
The
story, so far, has been that browser plug-ins are usually easier and
quicker to update. Developers can rely on new features of a proprietary
platform such as Flash earlier than someone who uses the native HTML
platform could. This is changing, however, one browser at a time.
A merged
chart, using the weighted distribution of each browser's penetration
and the time it takes for its users to update, tells that the overall
story for HTML developers still has a long way to go.
Of course, this shouldn't be taken into account blindly. You should always have your audience in mind when developing a website,
and come up with your own numbers when deciding what kind of features
to make use of. But it works as a general rule of thumb to be taken into
account before falling in love with whatever feature has just been
added to a browser's rendering engine (or a new plug-in version, for
that matter). In that sense, be sure to use websites like caniuse.com to
check on what's supported (check the “global user stats” box!), and
look at whatever browser share data you have for your audience (and
desktop/mobile share too, although it's out of the scope of this
article).
Conclusion
Updating the browser has always been a
certain roadblock to most users. In the past, even maintaining
bookmarks and preferences when doing an update was a problem.
That
has already changed. With the exception of Internet Explorer, browsers
vendors are realising how important it is to provide easy and timely
updates for users; similarly, users themselves are, I like to believe,
starting to realise how an update can be easy and painless too.
Personally,
I used to look at the penetration numbers of Flash and HTML in
comparison to each other and it always baffled me how anyone would
compare them in a realistic fashion when it came down to the speed that
any new feature would take to be adopted globally. Looking at them this
time, however, gave me a different view on things; our rich web
platforms are not only getting better, but they're getting better at
getting better, by doing so faster.
In retrospect, it
seems obvious now, but I can only see all other browser vendors adopting
similar quick-release, auto-update features similar to what was
introduced by Chrome. Safari probably needs to make the updates install
without user intervention, and we can only hope that Microsoft will
consider something similar for Internet Explorer. And when that happens,
the web, both HTML-based and plug-ins-based but especially on the HTML
side, will be moving at a pace that we haven't seen before. And
everybody wins with that.
What if one of the world's most popular 3D engines, the same one used to power many of the most popular console games in the world, also ran in your web browser? That would be pretty interesting, right?
Things just got interesting: Epic Games has announced that their incredibly popular Unreal Engine 3 now works in Adobe Flash, demoing a version ofUnreal Tournament 3 running inside the new Adobe Flash Player 11.
That means porting existing games to work in a browser-based solution—and there are aton of games on Unreal Engine 3—would be more or less turnkey.
A quick look at the screenshots provided by Epic indicate that the engine isn't as powerful as a non-browser-based engine—no big surprise there—but that it's still very much a "real" 3D experience. (I haven't yet seen the engine in motion.)
Even better, developers will be able to migrate their games from, say, iOS over to a browser-based environment without much hassle, making it possible to easily sell browser-based games that play the same games as apps on mobile devices.
But the real thing that should make you arch an eyebrow is Facebook.Nearly every game you can play on Facebook runs on Flash. And now Flash can run hardware-accelerated 3D, just like Real Games.
Despite
the controversy of user control, Microsoft especially has a reason to
make this move to react to browser "update fatigue" that has resulted in
virtually "stale" IE users who won't upgrade their browsers unless they
upgrade their operating system as well. 
