Thumbnail

It seems like everyone these days is texting away on their mobile phone or updating their social network status every 5 minutes. It’s no surprise that the convenience of being able to access the Internet from anywhere at any time has made sharing messages and pictures so popular. I can’t imagine going anywhere without my cell phone on the off chance that something interesting might happen and I can document it as if I were the first news reporter on the scene. This is the first article in a two-part series in which I will show you how to create a photo blog as part of your personal website which you can update from your phone simply by sending an email.

Read the original:
PHPMaster: Creating a Mobile Photo Blog, Part 1

328-firefox-4

Firefox’s rapid release schedule has not been the success Mozilla hoped. Most web developers agree it’s good for HTML5 feature evolution but it’s not without problems:

  • Add-on compatibility. Most of us use extensions which cannot keep up with Firefox’s development progress.
  • Increased effort. The majority of IT departments must test mission-critical applications before a browser update can be deployed throughout the enterprise.
  • Confusion. Few people understand the rationale behind major version increments. Why shouldn’t Firefox 6 be version 4.2?

Mozilla is replicating Google’s release model but Chrome does not necessarily exhibit the same problems. It’s add-ons system is far simpler; more akin to bookmarklets than integrated code. The browser also has fewer legacy hurdles and has silently updated since the early days. Those using Chrome either understand this concept or don’t care.

One solution Mozilla considered was the removal of version numbers from Firefox’s “Help > About” dialog. Mozilla’s logic:

  1. Few users understand version numbers.
  2. Removal would simplify the UI.
  3. Users would be informed when the last check occurred, whether they were using the latest version, and how they could update (if Firefox had not automagically done so).
  4. If you really needed the version number, it could be found in about:support.

Uproar ensued on Bugzilla and the associated newsgroup discussion. The majority of respondents detested the idea (although a large volume of ranting and spam appeared when Mozilla’s intentions went public).

The organization put forward some reasonable arguments but ultimately backed down. Mozilla’s Robert Kaiser:

Can we close this bug report?

Version numbers in software are like coordinate systems in physics: irrelevant and necessary at the same time — it’s completely irrelevant how you do them, but they provide necessary reference points. Not more, not less.

Where ever we go with this, I don’t think it will have either a large impact on version number messaging or on making Firefox useless, so I think the rage on both sides is overrated.

The reply from VanillaMozilla:

Done … I’m having a hard time finding anyone at all who thinks this is a good idea.

The argument become overheated but Mozilla’s proposition had a number of flaws:

  1. It went against established UI conventions that span OSes and 20+ years of IT development. There may be better ways, but removing version numbers is not likely to be the best solution.
  2. The proposal was too simplistic and did nothing to tackle Firefox’s rapid update issues. Version numbering was never the cause or the cure.
  3. Users may not understand version numbers, but removing them was a non-issue. Firefox wouldn’t suddenly become easier to use.
  4. There are multiple versions of Firefox in the wild. Some would have version numbers, some wouldn’t. None of the older editions would state they were out of date.
  5. Version numbers are important to developers and IT support staff. What’s the first question you ask when someone reports a problem in a specific browser?

Version numbers have been rendered meaningless in Chrome and Firefox. Few people know or care what version of Chrome they’re running. Perhaps, one day, the same will be true for Firefox — but we’re not there yet.

Firefox is an older browser with far more baggage and a large, passionate user community. Mozilla ultimately listened to their demands, but the the proposal and subsequent onslaught did nothing for the browser.

522-browser-trends

Despite the ongoing Firefox releases, the browser market has remained quiet during the summer months.

So here are the latest statistics. I’ve changed the table so Firefox 4, 5 and 6 are amalgamated into one; it makes little sense to analyze the separate figures since most of those users update their browsers as new versions appear:

BrowserJulyAugustchangerelative
IE 9.07.27%8.05%+0.78%+10.70%
IE 8.026.30%25.68%-0.62%-2.40%
IE 7.05.45%5.07%-0.38%-7.00%
IE 6.03.42%3.09%-0.33%-9.60%
Firefox 4.0+17.66%18.10%+0.44%+2.50%
Firefox 3.6-10.30%9.39%-0.91%-8.80%
Chrome22.17%23.17%+1.00%+4.50%
Safari5.15%5.18%+0.03%+0.60%
Opera1.66%1.67%+0.01%+0.60%
Others0.62%0.60%-0.02%-3.20%
IE (all)42.44%41.89%-0.55%-1.30%
Firefox (all)27.96%27.49%-0.47%-1.70%

The table shows market share estimates for desktop browsers. The ‘change’ column shows the absolute increase or decrease in market share. The ‘relative’ column indicates the proportional change, i.e. another 9.6% of IE6 users abandoned the browser last month. There are several caveats so I recommend you read How Browser Market Share is Calculated.

IE9 had another good month. Its progress is remains relatively sedate, but there are two solutions if Microsoft want massive adoption:

  1. Offer Windows 7, the hardware which runs it, installation, migration and training services to everyone. For free.
  2. Alternatively, release a version of IE9 which is compatible with XP. The other vendors support XP and still manage to offer fancy features such as hardware acceleration. And CSS3 text shadows.

IE’s overall drop has slowed a little this month, but I suspect that’s a statistical blip while business users enjoy a summer break.

Firefox 4/5/6 is rising but not at the pace Firefox 3/2/1 is falling. While the rapid releases are mostly good, users are becoming frustrated with add-on compatibility failures and memory usage problems on Mac OS. Mozilla is addressing the issues but they’re losing users who may never return.

There’s little to report for Opera and Safari. Both browsers made modest gains, but neither is setting the market alight.

That leaves us with Chrome. It’s the same story: usage continues to grow at 1% per month — sometimes more. If the current trend continues, Chrome will overtake Firefox in December 2011. It’s already occurred in the UK where Chrome has 23.41% lead over Firefox’s 21.75%.

Personally, I like Chrome and regularly recommend or install the browser; it’s fast, simple, stable and updates without fuss. However, I primarily use Firefox (on Windows 7) because it has a range of essential add-ons for power-surfing and development. I thought others would think the same but, having asked the question on Google+, it appears not. Developers are switching to Chrome in droves. Mozilla is losing the technical evangelists who once promoted Firefox.

Mobile Browser Usage

Desktop browsers account for 92.88% of web activity. The remaining 7.12% is mobile access and it’s evident more people are using their phones for general web browsing. The applications they primarily use are:

  1. Opera Mini/Mobile — 21.61% (down 0.46%)
  2. Android — 19.72% (up 1.55%)
  3. Nokia browser — 16.99% (down 0.11%)
  4. iPhone — 14.91% (down 0.19%)
  5. Blackberry — 11.64% (down 0.66%)

Note there are significant regional variations:

  • In the US and Canada, Android takes the top spot with 34.2% followed by the iPhone with 26.1%. Opera accounts for less than 4%.
  • The iPhone is most popular in Europe at 33.7% with Android second at 23.7%.
  • For Oceania, the iPhone has an almost monopolistic lead of 56.7%. Android is way behind at 19.4%.
  • It’s Asia, Africa and South America where Opera and less-expensive Nokia devices reign supreme.

Remember that these figures are collated from internet access — not sales trends. Users with an older mobile are less likely to use the web than those with the latest 3G handset. That said, in the developing world, users may not have access to a PC so mobile is the only option.

Not very long ago when we were planning the launch of our humble magazine BuildMobile, which you are reading right now, the content strategy included coverage of the nebulous WebOS mobile operating system. Come launch time, there wasn’t enough traction to include it in our platform categories, but we were hopeful for the future. WebOS in 60 Seconds WebOS is a mobile operating system based on the Linux Kernal Initially developed by Palm and first released in January 2009 Acquired by Hewlett-Packard in April 2010 for US$1.2b WebOS uses a “card” UI with a left-to-right flick for app swithcing, flick up for “off” The WebOS broswer, called simply “Web” is based on the WebKit layout engine WebOS “Synergy” feature integrates information from many cloud services into a single list Devices include the Pre , the Pixi and the Veer phones, then the HP TouchPad HP announced in March 2011 that WebOS would run within Windows by the end of 2011 On 18th August 2011 HP announced it would discontinue operations for WebOS devices Potentially even more HP TouchPads will be made and sold at a loss Web Standards based Native Apps A feature that was full of promise, and partly responsible for the underdog adoration WebOS attracted from developers worldwide, is that web technologies like HTML, CSS and Javascript are first class tools for developing native apps for the platform, with full access to hardware APIs like the camera.

Link:
BuildMobile: The Future of WebOS

506-google-page-speed

Google has announced their new Page Speed Service. In essence, it’s a combination of proxy servers, Content Delivery Networks (CDN), and web page optimizers which Google states will produce speed gains of 25-60% for most websites.

The service is being offered to a limited set of web developers at no cost. After the trial period, Page Speed will be released to everyone and, although there are no details, “pricing will be competitive” (source: Official Google Code blog).

To use the service, it’s simply a matter of registering and adding a new DNS CNAME record to your domain. As well as providing a gzipped proxy server for static files, the service can also rewrite your pages for web performance best-practices:

  • CSS files can be combined, minimized, and moved to the HTML head
  • JavaScript files can be combined and minimized using Google’s Closure Compiler
  • images can scaled and optimized

All features are optional so you can, for example, disable the Closure Compiler if it breaks your JavaScript code.

Google provides a page test comparison service at www.webpagetest.org/compare. It estimated that SitePoint.com’s home page would enjoy a 13% speed increase — I suspect that’s primarily owing to JavaScript file concatenation.

Tremendous or Troublesome?

Depending on the price, the Page Speed Service could be ideal for inefficient static pages running on slow servers. It may be more cost-effective than spending money on further development or hosting.

Unfortunately, there are a few downsides:

  • Bare domains are not supported, i.e. you must use www.domain.com rather than domain.com. That’s a shame — I’ve been dropping the “www” from my sites.
  • HTTPS pages are not supported.
  • Flash, streamed audio, streamed video and files over 50MB are not supported.
  • POST requests greater than 2MB are not supported.
  • You’re unlikely to experience significant speed gains on web applications running server-side code.
  • Domains hosted on Blogger, Google Sites or Google App Engine are not supported.

Speaking as a web developer, the service makes me slightly uncomfortable. Like many, I ensure my sites are optimized by combining files, minimizing the code, reducing HTTP requests and using CDNs where possible. For Page Speed to be attractive, I wouldn’t want to lose control, configuration would have to be easy, I wouldn’t want my code to be rewritten, and the price would have to be cheaper than upgraded hosting.

Risk is another factor which needs to be assessed. Will Page Speed offer additional redundancy or two points of failure? I suspect it will depend on the quantity of static vs generated content on your website.

Finally, are you willing to hand your website keys to Google? Their services are more reliable than most, but this is a new product which could experience teething problems. Conspiracy theorists will also see this as another step toward Google’s global domination. Google Search considers page speed factors so could the company become an all-powerful web host which undermines sites not using their network?

Technically, Google Page Speed an amazing solution which should boost the download speeds for most sites — especially those which are inefficiently coded. However, I’m not convinced many good web developers will adopt it. And would bad developers understand the service or care enough to recommend it?

Time will tell if Google’s Page Speed Service is a success. Please let us know your opinions…

You may have noticed the updated background on DesignFestival, currently, it is Blind Date Prep by Alan Dowling . Over the next number of weeks we’ll be rotating the background through the most popular entries to further show off the hard work people applied in this contest. Didn’t catch the contest? The Cicada Principle Explained Gallery of Entries Contribute to the Gallery Thanks again to all of the entrants for their great work, and we look forward to seeing more entries into the Gallery

Original post:
DesignFestival: Celebrating The Cicada Principle

531-banishing-url-bar

Google wants Chrome to be a clean distraction-free browsing experience. They’re possibly about to take their most radical step yet. Interface minimalism will reach it’s ultimate zenith with the removal of the address bar.

Madness?

Perhaps. But Mozilla are considering the same UI move.

The idea has received an overwhelmingly negative response from technical users. However, before you reach for your soapbox, be aware that it’s only a proposal which may never see the light of day. If it does happen, it will almost certainly be an option and “compact view” might only be permitted on application tabs. When enabled, the user may have to double-click a tab to view the URL.

So why does Google think a 30-pixel gain is so important? It would provide an extra 5% of space on some tablet and netbook screens, but there are deeper reasons…

I use the address bar. You probably use it too. But many users don’t. Non-technical users rarely understand URLs; it’s plainly obvious when you observe them type www.whatever.com into Google’s search box. So why retain a feature few people use?

We should also consider how web use is changing. We know the browser is a separate application but it’s likely to evolve as operating system vendors attempt a more integrated approach. Icons, application tabs and pinned sites are just the start. The distinction between online and offline is already blurred and, within a few years, users won’t know or care where an application resides.

There’s also been a noticeable shift in internet marketing. While companies still promote their URL on advertising media, many now publish more memorable search keywords for Google or Facebook.

Finally, there are commercial incentives. Without the bar, users must resort to a search engine; they’ll aways see a page of results and revenue-paying adverts before reaching their destination.

But what about the drawbacks? If you can’t see the address bar, it’s more effort to enter a URL. If users really don’t want the bar, it can usually be hidden or they can switch to full-screen mode (F11 in most browsers).

Web developers also depend on the URL — especially when testing web applications or REST services. Removing the bar will make our lives more difficult.

Finally, without the address bar, it’s more difficult to ensure you’re on the correct site or check security settings. Those involved in phishing scams will be eagerly anticipating the UI change.

The idea makes me uncomfortable. Users may not understand URLs, but removing the bar won’t help them learn. I’m sure many car drivers don’t understand hydraulics but that’s not a reason to remove their brakes (OK — bad metaphor, but a web without URLs is not without danger).

I’m all for UI simplification, but this seems like a step too far. If it happens, Google should rename their browser: “Chrome-less” would be more apt.

What do you think? Should the address bar go? Could it be an option? Are the risks too great?

real-world-accessibility-feature

Web designers and developers need techniques that work now while keeping an eye on what lies ahead. To do that, I’ve had one focus in every workshop I’ve taught over the past seven years: getting the best real world solutions for creating accessible websites and applications into the hands of developers and designers.

What do I even mean by real world? It’s very simple: Accessibility doesn’t and shouldn’t exist in a vacuum. The real world is messy. It isn’t black and white but every shade of grey in between. This applies to accessibility but also to our craft in general. We have to make compromises. We have to make choices. We have to change tactics mid-stream. And we have to have it finished yesterday.

And that’s why we focus on Real World Accessibility. You need to know what works now so that you can make informed decisions when you’re implementing modern web technologies. For the last two years, we’ve focused on Real World Accessibility for HTML5, CSS3 and ARIA—the workshop we’re bringing to Australia this month.

In preparation for the @feather Tour Down Under 2011 (I’m @feather on twitter) we crafted a page highlighting the content and details of what you’ll get. It isn’t the first HTML5 site/page we built, but we wanted to do something that created a unique design, was accessible, and gave us an opportunity to test out a few modern techniques for web design and development.

Every time we build something with HTML5, we get a chance to take a closer look at how accessible it is right now and we get a glimpse of what accessibility will be with new technologies.

HTML5 Semantics

I’m a fan of the new semantics that HTML5 brings us, for the most part. It opens new doors for us—authors around the world are excited to use the semantically sound elements that were introduced in HTML5.

And everyone knows that foundation of accessibility is semantics, right? Right.

So what happens when you combine a reasonably semantically rich language like HTML5 with browsers and assistive technology that was written before the semantics of HTML5 were even considered?

Nothing. And that’s the problem.

The advantages that the semantics of HTML5 bring to us are not really the boon to accessibility that they should be—yet. (To follow the development of which HTML5 elements are fully exposed by browsers and pass through to the accessibility APIs of different operating systems, be sure to check out HTML5accessibility.com.)

Accessibility continues to evolve in HTML5. There’s a team at the W3C dedicated to HTML5 Accessibility. And while accessibility for HTML5 continues to develop, I’m going to do my very best to ensure that what we’re doing for accessibility isn’t just about what will work in the future, but also about what works in the “here and now.” Why? Because we have “support” for HTML5 in browsers now. And that means that people are going to use it now. Which means it needs to be accessible now.

Here’s the real world situation with HTML5 accessibility as of this writing:

  1. We can use the new elements (article, section, aside, header, footer, nav to name a few) in our websites and apps right now.
  2. We can trick browsers that don’t natively understand those elements exist by using the HTML5 shiv. Yes it uses JavaScript and no, that’s not a reason not to use it. Yes, you need to consider the “JavaScript off” scenario, but we’ll talk more about that later.
  3. We must know that the semantics of HTML5 are NOT expressed or interpreted right now by existing assistive technologies. That’s okay—support will be coming, but it will take some time.
  4. While we’re waiting for support for emerging technologies such as HTML5, we need to find solutions that work now.

Web Content Accessibility Guidelines

I’m happy that we’ve moved on from WCAG 1.0, but I miss one of its hallmarks: the Interim Solutions Guideline. That told us to:

“Use interim solutions.

Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly.”

Let’s be clear: I don’t like the specific interim solutions that were advocated in WCAG 1.0. These checkpoints were all about “Until user agents” allow for X or have the functionality to do Y, use these techniques. User agents now do those things, so we don’t need to worry about them with WCAG 2.0. They’re so unimportant I’m not even going to mention them here.

But the idea behind using interim solutions was all about recognizing that certain techniques may not have full support in older assistive technologies or browsers and that we must think about those scenarios.

And that’s the case with HTML5 right now.

So what “Interim solutions” can we use with HTML5 to help assistive technology understand the semantics?

Using WAI-ARIA

ARIA (Accessible Rich Internet Applications) is a technology that is used to help specify programmatically what web a user interface component (or “widget”) is more clearly, so that assistive technologies can provide more meaning to its users.

It is often referred to as a “bridge technology” —in that it helps us bridge the gaps between the past, the present and the future. In short, if we have an existing legacy web application that uses older markup and coding practices, we can help make that more accessible by applying ARIA attributes to the markup without rewriting the entire application with more modern languages.

Here’s how ARIA helps.

Consider this Google Maps implementation: http://examples.furtherahead.com/aria/slider/index-3.html

real-world-accessibility-1

Note that we’ve used a custom set of controls on the map that allow for excellent keyboard accessibility. We’ve also implemented a custom slider control to replace the standard Google Maps control.

We don’t have a native slider element in HTML (at least not at present), so we built the slider with HTML, CSS and JavaScript such that it approximates the visual appearance and functionality of a slider control. The problem is that when we do so, we’re really creating a complex user interface component that is comprised of semantically meaningless divs, spans, images, links and buttons.

  1. For any complex user interface component, we need to know three basic pieces of information:
  2. What is this thing? (its role)
  3. What general characteristics does it have? (its properties)
  4. What can you tell me about it right now? (its state)

The whole is greater than the sum of its parts; taken together, those divs, spans, images and links create something more (a slider). ARIA lets us precisely specify the meaning of the whole so that assistive technologies can better understand the whole instead of breaking it down and trying to understand its individual components.

Traditionally we might have used markup something like this:

<a href="#"
      id="handle_zoomSlider">
<span>11</span>
</a>

The link gives us a focusable control that we can use for the slider’s “thumb” that will slide along the rail. The link text tells us the current zoom level (11), which is also displayed on the screen. We’d use a foreground or background image for the “rail” to make it look like a slider, and then we’d apply the appropriate JavaScript to allow us to  manipulate the thumb with the mouse and they keyboard.

To assistive technology though, this is just a link with some text in it. There’s no indication of what the link is about or what it does.

How can we make this better? We add some ARIA attributes:

<a href="#"
      id="handle_zoomSlider"
      role="slider"
      aria-orientation="vertical"
      aria-valuemin="0"
      aria-valuemax="17"
      aria-valuetext="14"
      aria-valuenow="14" >
<span>11</span>
</a>

The markup is fairly simple. We did a few things:

  1. indicated a role for the component (role="slider"),
  2. used aria-orientation="vertical" to specify that it is oriented vertically in the page, and,
  3. added several properties to that slider (aria-valuemin="0", aria-valuemax="17",aria-valuetext="14", and aria-valuenow="14").

When we use JavaScript to change the position of the thumb on the rail we also change the value of aria-valuenow and aria-valuetext to match the zoom level. The ARIA properties are updated, and provided we’re using the right pieces of assistive technology, we get the appropriate announcements or interaction with that interface component. A screen reader user, for example, will hear that the user interface component is a slider, and they will hear values being read out as the value changes in response to moving the thumb along the rail.

This is what ARIA gives us: the ability to provide better programmatic accessibility for complex user interface components. There’s a lot more detail to it, but that’s ARIA in a nutshell.

Now, then … I told you that to tell you this.

ARIA and HTML5

Remember we talked about the idea of Interim Solutions? That’s where ARIA and HTML5 come together.

ARIA has decent support in assistive technology. It isn’t perfect, but screen readers and magnifiers and other technologies are much further along in supporting ARIA than they are supporting HTML5. Why? Quite simply, even though ARIA is still “new,” it is older than HTML5. Assistive technology vendors have implemented support for certain parts of ARIA, and that support continues to grow.

Because of this level of support, we can add ARIA to give us some of the semantics that HTML5 should give us, but isn’t supported in or exposed to assistive technology just yet.

We use ARIA to complement the semantics of HTML5 in the sites that we build. We relaunched our accessibility focused site Simply Accessible in October of 2010 and defined a number of ARIA landmark roles that help give meaning where it can’t be delivered via HTML5 yet.

We added role=”main” to the main content on the page that is also marked up with HTML5’s <article> element. We used role=”complementary” on the <aside> element for the related content in the sidebar. And we used role=”navigation” on the <nav> elements at both the top and the bottom of the page.

See how it works? We are still using HTML5’s elements, but we’re supporting that with ARIA for those assistive technology and browser combinations that don’t “get” HTML5 yet.

We consider things in this order:

  1. What is the most semantic HTML5 that we can write to solve a problem?
  2. How can we convey as close to the same meaning with ARIA for technology that doesn’t understand HTML5?
  3. How can we convey as close to the same meaning for technologies that don’t understand either of HTML5 and ARIA?

Let’s wrap this up with one final example.

Figures in Web Pages

In a recent article Accessibility and HTML5 Block Links I talk about some of the issues that the block link structure creates with screen reading technology. In that article I use an HTML5 figure element to express the relationship between the image and the caption that is below it:

real-world-accessibility-2

<figure>
<img
      src="../blocklinksvoiceover-500-2.png"
      alt="Screenshot of block links with Voiceover on the Mac.">
<figcaption id="figcaption1">
<strong>Screenshot</strong>: We use block links on the promo page...
In other screen readers, parts of the link aren’t read at all.
</figcaption>
</figure>

This structure creates an explicit relationship where it didn’t exist before. The parent <figure> element contains a <figcaption> element with a sibling <img> element. This HTML5 structure formalizes what people have been doing for years — placing an image in the page and including a paragraph of text after it in the markup.

How does this work for a browser and assistive technology combination that doesn’t understand HTML5? Well, a browser that doesn’t understand an element just skips that element. So when we don’t have full HTML5 support, we fall back to the association by proximity: the image and the paragraph are siblings in the source code, so they must be related.

What can we do, though, for assistive technology that understands ARIA, but not <figure> and <figcaption>? We can create a programmatic association by adding the aria-describedby attribute:

<figure>
<img
      src="../blocklinksvoiceover-500-2.png"
      alt="Screenshot of block links with Voiceover on the Mac."
      aria-describedby="figcaption1">
<figcaption id="figcaption1">
      <strong>Screenshot</strong>: We use block links on the promo page...
      In other screen readers, parts of the link aren’t read at all.
</figcaption>
</figure>

Now there is a stronger association than just having the two pieces of content related by proximity, created by adding ARIA. The value of the aria-describedby attribute does just what you think it does: it contains an id value of the node in the page that describes the content. The detailed description of the <img> is provided by the node with the corresponding id—in this case, the <figcaption>.

What about the case where we have no HTML5 or ARIA support? We fall back to the age-old method of association by proximity: the image and the description are right next to each other in the code.

And that’s Real World Accessibility. It works now and will work better in the future.

Working through these kinds of scenarios is a pragmatic way to learn about Real World Accessibility, and these are exactly the kinds of scenarios we explore—in about as hands-on a way as you can imagine—in our full-day workshops. If you’re in Australia, you can register today, otherwise keep a look out for when we’re in your part of the world.

And in the meantime, let me know what you think about all this.

Screen shot 2011-07-05 at 2.52.15 PM

The tech media has spent the vast majority of the last week focused on Google’s newest product, an ambitious platform called Google+ that the company hopes will break through their dry spell in the social arena and make them competitive.

It’s early days — for many people it’s next to impossible to even get in — but things are looking positive. The app has been met by a largely positive reception and my stream shows no sign of slowing down as users keep posting after the novelty wears off.

Circles

Circles is a foundational feature of Google+, and it’s what makes it so different from other social networks — and bridges the gaps between them. With Circles, you control who you share what information with, making mutual relationships where intimate information can be shared, Facebook-style, a possibility, while still allowing the unidirectional model of Twitter that allows you to follow people you find interesting without them having to follow you back.

The interface for organizing your Circles is pretty cool too, but I don’t think it’s the animations that’s blowing people away.

If I want to make a post that is viewable only by my family members, I can. If I want something to be viewable by the public, that’s possible too. There are no “all or nothing” scenarios here as there are with Facebook. This means Google can perform the roles of both Twitter and Facebook and puts it in a very powerful position.

The Circles interface.

Stream

The stream is where you can view incoming information. It’s much like the Facebook news feed or your Twitter stream, but Circles gives you control over what you’re looking at here — it’s not just for deciding who to share content with.

In the screenshot below I’m viewing content that has been shared by people I know from my role at The Next Web. I can easily jump between Friends, Family, Acquaintances, or the Following Circle that’s like a bucket for interesting people I’ve never met.

As is the de facto standard today, the stream updates in real-time. There are some issues that Google engineers are actively working to fix — old posts tend to float to the top more easily than on other networks.

The Google+ stream is the equivalent of your Facebook news feed.

Sparks

Sparks is billed as one of the main features of Google+ but doesn’t get as much airtime at the moment. That’s because it’s one of the few areas where Google seems to have not invested much effort into creating something truly useful. Sparks are feeds of information based on defined topics, but if you take a look in the screenshot below where I’m looking at the pre-defined Spark called “Films” there’s no curation to the content. The second result has something to do with a sniper shooting a civilian who was filming him in Syria — tragic, but not exactly what I’m thinking of when I want information about recent films.

This feature could be a lot better. It could make discovering and subsequently sharing interesting information a breeze, but not until the results are much better. This would be a perfect place for some sort of integration with Google Reader, where the content has already been curated by both publishers and subscribers.

The Sparks interface.

Hangouts

Hangouts is one of the most impressive parts of Google+. The underlying technology isn’t that incredible — we’ve had Skype video conferencing for years. But Hangouts can handle ten or twenty people at a time without problems, and more importantly, it’s not the technology but the execution that makes this feature impressive. Video calls need to be arranged and specific people need to be called in, but with Hangouts, anyone from selected Circles can drop in and out. It’s an evolving social space like your local bar, not a rigid call structure, and that distinction is important. It makes Hangouts pretty revolutionary.

You're given a chance to fix your hair before you enter a Hangout.

API

No doubt you’re wondering: when’s the API coming? Google says it will be here soon, and if they’re telling the truth they’ll have introduced an API much faster than Facebook did. It’ll be interesting to see what sort of apps come out of Google+ that weren’t possible using other social platforms.

There have been clues that Google+ Games is coming, and rumors that there’s a partnership with social gaming giant Zynga involved. Will Google+ be the next platform for casual game developers to tackle? We’ll have to wait and see, but I’m leaving at the first hint of Farmville spam.

What do you think about Google+?

522-browser-trends

It’s increasingly difficult to keep track of the browser market. Chrome 12, Firefox 5 and Opera 11.5 were released last month. Some browsers auto-update, some don’t. Some vendors have lavish launch promotions, others don’t mention it.

The big news for July is that Chrome usage has passed 20% for the first time. Let’s examine the full StatCounter statistics in more detail…

BrowserMayJunechangerelative
IE 9.04.57%6.18%+1.61%+35.20%
IE 8.029.06%27.67%-1.39%-4.80%
IE 7.06.39%6.00%-0.39%-6.10%
IE 6.03.84%3.72%-0.12%-3.10%
Firefox 5.00.00%2.81%+2.81%n/a
Firefox 4.014.23%14.04%-0.19%-1.30%
Firefox 3.5+13.95%10.44%-3.51%-25.20%
Firefox 3.1-1.12%1.05%-0.07%-6.30%
Chrome19.38%20.67%+1.29%+6.70%
Safari5.01%5.07%+0.06%+1.20%
Opera1.83%1.74%-0.09%-4.90%
Others0.62%0.61%-0.01%-1.60%
IE (all)43.86%43.57%-0.29%-0.70%
Firefox (all)29.30%28.34%-0.96%-3.30%

This table shows market share estimates for desktop browsers. The ‘change’ column shows the absolute increase or decrease in market share. The ‘relative’ column indicates the proportional change, i.e. another 3.1% of IE6 users abandoned the browser last month (yay!) There are several caveats so I recommend you read How Browser Market Share is Calculated.

In June, Chrome 11 toppled Firefox 3.6 to become the world’s second most-used browser. Confusingly, the launch of Chrome 12 has split Google’s user base so Firefox 4.0 has now taken second place. Despite being available for little over a week, Firefox 5.0 has already gained 2.8% market share as Firefox 3.x and 4.0 users migrate.

However, there’s little good news for Mozilla. Firefox’s overall total dropped by almost 1% in June: three times worse than IE and one of the biggest falls the browser has ever experienced. There doesn’t appear to be a particular reason; Firefox 4 and 5 have been well-received but they haven’t halted Chrome’s progress. Perhaps the changes were too radical for some? Or did users investigate other options rather than upgrading?

IE9 has made good gains although IE8 remains the most popular browser version. IE6 and 7 continue to drop although the pace is slowing.

Opera also experienced a small drop. However, version 11.5 may be able to reverse that trend and there’s better news for the company in the mobile arena…

Mobile Browser Usage

According to StatCounter, desktop browsers account for 93.47% of web activity. Mobile browser usage grew by almost 1% last month to 6.53%. This may be a seasonal anomaly since it’s summer in much of the western world — net users may be out enjoying the sunshine (or drizzle for those of us in the UK).

Movements within the mobile browser market are quite unusual and possibly influenced by seasonal factors. Nokia may be experiencing business issues, but they will be pleased to discover that their (fairly basic) browser has overtaken Android and Safari on the iPhone. Opera has also made gains following the latest release of their mobile editions:

  1. Opera Mini/Mobile — 22.81% (up 1.00%)
  2. Nokia browser — 17.66% (up 1.16%)
  3. Android — 17.25% (up 0.24%)
  4. iPhone — 15.22% (down 1.49%)
  5. Blackberry — 11.98% (down 0.78%)

If you’ve not done so already, perhaps it’s time to consider how your business will be affected by the rapid rise of mobile platforms.