AUSTIN, Texas — Opera Software has a version of its Mini browser prepped and ready for the iPhone. Opera Mini 5 for the iPhone will be available in the App Store in a matter of weeks, but the company is demoing a beta version of the tiny mobile browser here at South by Southwest Interactive.

We got to see a live demo of the app in action, but we weren’t allowed to photograph it due to the company’s agreement with Apple. The screenshot at left is all that’s been approved for distribution.

Opera Mini 5 has the same features as all other implementations of Opera Mini for other mobiles. It syncs history and preferences data (like Speed Dial), it has a customizable search field, and it can discover and subscribe to RSS feeds. It also has an elegant tab switcher that lets you browse your open tabs like you’re shuffling a stack of cards.

All versions of Opera Mini use proxy servers to squish pages and images before they’re delivered to your phone, greatly speeding up page loads over slower connections. Opera claims a 90% compression rate, which is impressive, but the trade off is that you lose one of the iPhone’s special features. There’s no multi-touch on the iPhone version of Opera Mini. You can double-tap to zoom, but not pinch to zoom. Even so, it’s nice to have the option to load an alternative browser onto the iPhone, which right now only has Mobile Safari.

Look for it in the App Store some time in the next few weeks. An Android version was recently released as well. Try it out at Opera’s site.

Cliqset has produced this nifty web app that aggregates status updates and check-ins sent from people in and around Austin to all of the different major location-sharing services — Gowalla, Foursquare, Twitter, Brightkite and of course Cliqset. It’s called Cliqset Crowd

It’s a nice tool you can use to get in on the location sharing game if you, like me, are one of those people who prefers to observe from the outside. With this all inclusive map, you certainly won’t miss anything big.

We’re headed to Austin, Texas tomorrow along with the crew from Wired’s Underwire blog to attend South By Southwest Interactive. The week-long nerd fest starts Friday, and we’ll be reporting from the trenches.

If you’re headed down to SXSWi, here’s what Webmonkey will be checking out. If you’re not going this year, you’ll be able to follow along from home here on the blog and everywhere else on the intertubes using the hashtags #sxsw, #sxswi and #sxsw2010.

The Wired Party, of course. Monday, March 15th at 5pm.

Molly Holzschlag from Opera leading a discussion about the current issues surrounding web browsers. Saturday, March 13 at 12:30pm.

The ActivityStrea.ms crew talks up their data format, which aims to let real-time status updates work across the entire social web. Saturday, March 13 at 9:30am.

The Beauty in Web Design panel, where designers will contemplate what it takes to move beyond usability and into real beauty on the web. Friday, March 12 at 2pm

New Publishing and Web Content, Jeff Zeldman’s panel about the use of web standards in e-books, e-magazines and the future formats of digital publishing. Saturday, March 13 at 5pm.

The Mozilla Party, happening right after the e-publishing panel. Saturday, March 13 at 6pm.

The SXSW Web Awards on Sunday night.

Google’s Hackathon, a hands-on app-building workshop. Sunday, March 14, all day.

Evan Williams’ keynote. We think he’s going to talk about Twitter or something. Monday, March 15 at 2pm.

Fun with HTML5 Video. As messy as the landscape is, there’s still some cool, creative stuff being done on the bleeding edge. You’ll see some of it here, Sunday, March 14 at 3:30pm.

Google Talks About Gmail and Buzz on Sunday, March 14 at 5pm.

The Bigg Digg Shindigg, with a live Diggnation broadcast and a live set from The Walkmen. Saturday night at Stubb’s BBQ

Scott Gilbertson will be holding down the daily coverage on the blog while I’m attending these (and other) fabulous SXSW events. I’ll also be tweeting as @webmonkey whenever anything interesting happens, which should be often. So stay tuned!

Flash: quick or dead?

A new study released Wednesday pits Flash Player’s video performance against that of native HTML5 video playback in several different web browsers.

The verdict? Flash is a CPU hog in some cases, and native H.264 video is a CPU hog in some cases. That’s right — both options threw strikes and gutters.

Video playback in the browser has been a central issue of discussion in the tech world of late. The forthcoming HTML5 spec allows for native video in the browser. But with patent issues causing squabbles between browser vendors over which codec to support, and with Apple rallying against Adobe’s Flash Player — which none of Apple’s mobile devices, including the iPad, will support — there’s been a great deal of debate over what the future of video on the web will look like.

Continuing that debate, Jan Ozer of the website Streaming Learning Center has posted a study of the performance differences between Flash video player and H.264 video playback in Safari and Chrome on both Windows and Mac.

H.264 video playback through HTML5 performs admirably on Mac Safari, but was neck-and-neck with Flash on Chrome for Mac. On other platforms, Flash outperformed native H.264 video. Ozer notes the latest version of the Flash Player is actually quite efficient at video playback on platforms where it can access hardware acceleration. On systems where it can’t, it tends to gobble up resources just like Flash Players of old.

Flash Player 10.1 can access a system’s GPU on Windows, giving a large boost to performance. But Mac OS X users are left out, because Apple doesn’t allow browser plug-ins to access the proper APIs. So, as Ozer argues, “the ball is in Apple’s court” to fix that limitation.

This study essentially backs up the arguments we’ve been making since the debate began — that the current crop of web browsers are not ready for native video playback and that Flash isn’t going anywhere anytime soon.

However, there’s one troubling omission here: Ozer’s study leaves Firefox out. He chose YouTube’s HTML5 demo pages to do his testing, and YouTube is currently pumping out H.264 videos on those pages, which Firefox can’t view. Firefox only supports videos in the Ogg Theora format. He does include Firefox in the study, but only uses it to measure Flash performance.

It doesn’t help that the author keeps referring to H.264 video as “HTML5″, when they are certainly not the same thing. H.264 is a patent-encumbered video format, so it’s disingenuous to treat the format as a fair test subject for measuring native video performance across browsers.

This isn’t ignorance on Ozer’s part, just an oversight — the man has written numerous books and articles about video codecs, after all. It’s an interesting study, but be aware that it doesn’t provide a complete picture of where native video playback is today.

[via Read/Write Web]

If you have Google Apps running on your domain, now you can install third-party apps that fully integrate with Google’s apps.

Google has debuted the Google Apps Marketplace, an online store where Google Apps users can browse different cloud-based applications and add the ones they like to their suite of online tools. The apps can share data with the standard Google apps like Gmail and Docs on whatever hosting environment you’re using. Basically, you get to build your own web-based productivity suite.

The apps currently in the store (Google launched with 50) are skewed towards the business and education customers, which make up the vast majority of hosted Google Apps users right now. If you browse the store, you’ll find gobs of apps for things like project management, customer retention and administration. No games just yet, sorry.

There’s a significant amount of buzz around Manymoon, one of the handful of companies that demoed at Google’s launch event Tuesday night and currently the most-installed app in the store. It’s a team collaboration app that divvies up tasks, sets project goals and tracks the progress of team members. The browser-based image editing tools from Aviary are cool, too.

Personally, I’m most fond of eFax — certainly an app with its eye on the future of communication.

Some apps are free and some are paid, with most of the paid apps adopting a subscription model.

When you install an app, it plugs into the user account and application data you already have stored in your current suite of Google Apps. So, you’re basically adding another app to your Google stack. The new app appears alongside Gmail, Calendar and Documents in the horizontal menu at the top of the browser and there’s very little friction as far as user experience goes.

If you want to build a browser-based web app and make it available in Google’s store, the company has posted its guidelines and docs for developers.

The apps can use OpenID or OAuth for user authentication (since Google credentials act as OpenIDs), and they can access various Google Apps APIs using the Google Data protocol. So if you want to build an app that harnesses a users’ contact information, calendar events or presentations from Google Docs, the company has made it very easy to do so.

Here’s a video of the announcement from Tuesday’s Campfire One developer event, which was held at Google headquarters, featuring VP of engineering Vic Gundotra:

Citing unnamed sources, The New York Times’ Bits blog says there will be two components, “a service offered directly by Facebook that will allow users to share their location information with friends,” and a set of APIs other location-sharing services can employ to allow Facebookers to update their location info using outside services.

NYT’s Nick Bilton says Facebook will shed light on the new service at the company’s upcoming f8 developer conference in April.

Facebook has certainly taken its sweet time getting in on the location-sharing game — services like Foursquare, Gowalla, Google Latitude and Yahoo Fire Eagle have been blowing up over the last year. But the whole idea of “check-ins” raise new privacy concerns for many social network users. Some view it as over-sharing, others have concerns about invasion of privacy or cyberstalking — which is why all of the most popular location-sharing apps have extensive privacy controls built in to their opt-in services.

Earlier this week, reports surfaced that Google is experimenting with rolling location-based features into Buzz activity streams, and that the company is even working on a new location-based ad format.

Photo: Mr Ush/Flickr/CC

Google has announced a new geocoding web service app authors can use to better plot locations on a map.

The new Google Geocoding Web Service includes some enhanced capabilities that not only make it possible for app developers to provide more accurate and granular locations in their apps, but it also lets them increase the performance of their apps through precaching.

First off, the new service employs the Google Maps JavaScript API version 3, which has a handful of improvements over the previous versions. Users will get more well-formed and easier to parse data from each request. The service can return full names as well as local-language abbreviations for countries, states and territories. Users also have the ability to apply multiple tags to each address component.

Second, the new service lets apps precache data. From the announcement on the Geo Developers blog:

The Geocoding Web Service is intended to enable precaching of geocoder results that you know your application will need in future. For example, if your application displays property listings, you can geocode the address of each property, cache the results on your server, and serve these locations to your API application. This ensures that your application does not need to geocode the address of a property every time it is viewed by a user. However we do ask that you regularly refresh your cache of geocoder results.

It’s important to note that the new service must be used in conjunction with a Google Map, generated either by the Google Maps API or the Google Earth API.

Browsing the web on one of Amazon’s Kindle e-readers is like taking a step backwards in time. It’s clunky and has only limited support for web standards, and bare-bones JavaScript capabilities.

But now Amazon may be looking to add browser engineers to the Kindle team, according to the job listings on the company’s website.

A job posting for a browser engineer at Lab126, the division of Amazon that develops the Kindle, indicates the company is looking for somebody to develop “an innovative embedded web browser” for a consumer product.

The role at Lab126 includes designing new features for a new browser while supporting the existing code. Job requirements include familiarity with current web standards and web rendering engines, as well as experience with Java and embedded Linux, both of which the Kindle runs.

The Kindle’s current browsing experience is notably subpar. It’s good enough to check your e-mail, post to Twitter or read Wikipedia, but it doesn’t handle images or more complex web apps particularly well. It certainly doesn’t live up to the same vision of the mobile web being outlined by the iPhone, or Android phones like the Droid or Nexus One. And with the coming of the Apple iPad and other threats to Amazon’s dominant e-reader, which should behave on the web about as well as (if not better than) the iPhone, the Kindle had better improve its browser if the device is going to continue to compete with these more capable devices.

Amazon recently launched a beta program for third-party app developers who want to build software for the Kindle.

Apparently, the job listing has been up for a month, but I only became aware of it once CNET’s Stephen Shankland tweeted about it.

Calls to Lab126 and Amazon on Monday morning went unreturned. I’ll update this post if and when I get more information from Amazon or anyone else.

Meanwhile, if you have any advice about improving the Kindle’s browsing mojo, leave it in the comments.

Photo: Charlie Sorrel/Wired.com

We’re giving away a pair of passes to Google I/O today.

A little over a week ago, we kicked off our contest, encouraging you to send us any HTML5 web apps or Google Chrome browser extensions you’ve built. Alternatively, we asked you to tell us how you’d describe a web app to your grandmother. We got a heap of submissions, but we worked our way through the field and picked two winners.

Abraham Williams and Mike Cantelon will be heading to Google’s premiere developer event, which takes place May 19 and 20 at Moscone Center in San Francisco, free of charge.

Here are the winning apps, chosen by the Webmonkey staff, along with a couple of honorable mentions:

Winner: Intersect by Abraham Williams

Williams came up with this cool extension for Chrome that shows additional information about a user’s followers on Twitter — in particular, it shows where you and another user’s social graphs overlap. Install the extension and visit somebody’s Twitter profile page. You’ll see additional grids loading below their stack of followers. You see which of your friends are also following that user, which friends you have in common and which followers you have in common. It’s an excellent social discovery tool for Twitter power users, and the best extension for Twitter’s stock web interface we’ve seen yet. Congrats, Abraham!

Winner: Blood Funnel by Mike Cantelon

Cantelon created this funky little game called Blood Funnel using JavaScript and HTML. It’s basically Space Invaders, except with flying, demonic Goldman Sachs bankers standing in for the buglike aliens. The paranoia is amped up by an awesome, thumping techno soundtrack — served up as an ogg file, of course. Check out Cantelon’s JavaScript source, it’s elegant. Caveat: Blood Funnel is nimble in Chrome, but it’s slower in Firefox. Congrats, Mike!

Runner Up: TabTweet by Nathanial Smith

Smith developed this Chrome extension which adds auto-complete functionality when you’re addressing @replies through Twitter’s web interface. When you go to start a new reply, you type the @ symbol and the extension kicks in, offering a dropdown list of your friends. It will continue to auto-complete the addresses as you type.

Runner Up: BitTorrent demo by Chris Lee

Lee took the old Aphid animated demo of BitTorrent (which you may remember from when we wrote about it, though the original link has gone the way of the ghost) and updated it using Processing.js. It runs in any browser that supports the <canvas> element, but, again, this one performs better in Chrome than in Firefox.

Best ‘Grandma’ Explainer by Curtis Tasker

“When you pull out your iPod and hit the Knit Buddy button to manage your needles and yarn, that’s what we call an ‘app.’ Now, let’s say you’re at the yarn store and you need to access your yarn and needle inventory to figure out what you need to buy for your latest creation. You realize you forgot your iPod at home. There’s no easy way to get access to the information you stored there. You could drive home and get your iPod, but it’s a long way. You could call Grandpa and attempt to have him look up the information, but what if he’s napping, or has the TV turned up too loud again? What if you could access your knitting inventory from your iPod, or your friends phone, or by the store’s computer? That’s what we call a “web app.” Instead of being stuck running an ‘app’ on a single device, and having your information locked to that device, you run a ‘web app’ on any device attached to the web, and you can access your information anywhere.”

Congrats to the winners, and thanks to everyone who sent in a submission for the contest. We’ll see the two of you — along with many more of you out there — at Google I/O in May.

Github user Alan Dipert has posted the source code for NCSA Mosaic 2.7 on the code-hosting website.

You can download it and run it on any modern Linux installation. It seems to run on Ubuntu just fine, though PNG support is a little wonky. The good news is that the folks on Github are actively submitting patches.

Mosaic was the first graphical web browser. It was born in the early ’90s, created by a small team headed by Marc Andreessen. The same crew would go on to found Netscape Communications and build the Netscape browser, which would eventually lead to the Mozilla browser, and finally to Firefox. So, running Mosaic is basically taking the browsing experience all the way back to its roots.

Dipert acknowledges the work of two other coders who ported the old code to run on the modern Linux: Sean MacLennan and Alan Wylie. As MacLennan says on his site, “If you are going to run a 10-year old protocol (HTML), you might as well use a 10-year old browser.”

I first started using Mosaic at the beginning, in 1993. We had it running at my college radio station, and we DJs would use it to download the news wires we’d read on air at the top of every hour. I also used it to browse Wired’s gopher server and read the magazine articles on my computer in my dorm room. About two years later, HotWired arrived on the web proper, and I used Mosaic to browse it.

OK, I’m getting misty. Somebody cue up some Pearl Jam.

Screenshot and hat tip from Tomayko.