Archive for November, 2009

File Under: Browsers, HTML5, Multimedia, Web Standards
Nov
17
2009

A Brave New Web Will Be Here Soon, But Browsers Must Improve

By

The great promise of HTML5 is that it will turn the web into a full-fledged computing platform awash with video, animation and real-time interactions, yet free of the hacks and plug-ins common today.

While the language itself is almost fully baked, HTML5 won’t fully arrive for at least another two years, according to one of the men charged with its design.

“I don’t expect to see full implementation of HTML5 across all the major browsers until the end of 2011 at least,” says Philippe Le Hegaret, interaction domain leader for the Worldwide Web Consortium (W3C), who oversees the development of HTML5.

He tells Webmonkey the specification outlining the long-promised rewrite of the web’s underlying language will be ready towards the end of 2010, but because of varying levels of support across different browsers, especially in the areas of video and animation, we’re in for a longer wait.

Most web pages are currently written in HTML version HTML 4.01, which has been around since the late 1990s. The web was mostly made up of static pages when HTML was born, and it has grown by leaps and bounds since then. Now, we favor complex web applications written in JavaScript like Gmail and Facebook, we stream videos in high-definition, we consume news in real-time feeds and generally push our browsers as far as they’ll go. These developments have left HTML drastically outdated, and web authors have resorted to using a variety of hacks and plug-ins to make everything work properly.

HTML5 — which is actually a combination of languages, APIs and other technologies to make scripted applications more powerful — promises to solve many of the problems of its predecessor, and do so without the hacks and plug-ins.

We’re already close. All the major browsers are providing some level of support for HTML5.

“There’s strong support already in Firefox and Safari. Even Microsoft IE8 has some partial support,” says Le Hegaret, referring to some code within HTML5 that enables the browser to pass information between pages.

Browser makers are approaching support incrementally, adding features little by little with every subsequent release. Some, like Mozilla, can build new features into the next release in a matter of months. For others, like Microsoft, it takes much longer.

Google Chrome is maturing extremely quickly and already supports most of HTML5. This is mostly because Google didn’t start from scratch — the company chose to use the open source Webkit rendering engine, the same one used by Safari. Still, this doesn’t mean both browsers support HTML5 equally.

“Video support between Safari and Chrome, despite the fact that they are both using the same underlying engine, is totally different because video support is not part of the Webkit project at the moment,” says Le Hegaret.

It’s actually this very issue — support for playing videos inside the browser — that continues to be one of main factors blocking the broad adoption of HTML5.

The way the specification is written now, website authors will have the ability to link to a video file as simply as an image file. The video plays in the browser without using a plug-in, and the author can create a player wrapper with controls.

But browser vendors are stuck arguing over which video format to support. Mozilla, Google and Opera are interested in the open source Ogg Theora video format. Apple has substantial investments in its Quicktime technology, so it’s pushing for the Quicktime-backed H.264 format. Microsoft wants people to use its Silverlight plug-in, so Internet Explorer isn’t supporting native video playback in the browser at all.

Google has voiced support for Ogg, but it has also recently made a bid to purchase On2, a company that makes a competing video technology. Rumor has it Google might release On2′s video technology under an open source license once the sale is complete.

Until these issues are sorted out, consumers and content providers alike are forced to rely on plug-ins. Le Hegaret says that while these plug-ins have certainly helped the web arrive where it is today, they continue to be a burden on the user.

Setting up any browser to support both H.264 and Ogg Theora requires at least one plug in, which harms the user experience.

“It’s hard today to ask people to install a plug-in unless the payoff is huge,” he says. “What’s driving the most successful plug-in, which is Flash, is video support. If you can’t see YouTube, your life on the web is pretty miserable. You’re missing a lot.”

Plug-ins aren’t just harder on web users, but they’re hard on web developers, too.

“Building with Flash or Silverlight in a way that lets you share information between the content appearing inside the plug-in and the rest of the page presents some challenges,” says Le Hegaret.

Unlike its predecessor, HTML5 has been designed with web applications in mind. The current HTML5 specification includes a media API that makes it easier to connect animations or video and audio elements — things traditionally presented within a Flash player — with the rest of the content on the page.

“You get a smoother application if you use HTML5. You’re not crossing a software layer. It’s all part of the same application.”

Unfortunately, the YouTubes of the world aren’t going to make a baseline switch from Flash to HTML5 unless they know there’s strong support for it in the browsers.

But they are testing the waters: Wikipedia is experimenting with HTML5 video support by serving Ogg Theora video to browsers that can handle it, and Flash to everyone else. YouTube and the video site Dailymotion have also set up special demo pages using this technique.

Le Hegaret says we’ll be in this period of transition — a dual-experience web where content sites serve HTML5 video along with a Flash fall-back — for a while.”

Web developers will continue to have to understand that not everyone is using the latest generation web browser, and that’s OK in the short term.”As far as being able to make the switch to a pure HTML5 web altogether, Le Hegaret says that’s only possible once browser vendors sort out their differences.

Once that day arrives, the final switch to HTML5 will be in the hands of the content providers. It’s up to them to begin coding for HTML5 standards and ditching support for old browsers.”

There are still a significant amount of people out there using IE6,” says Le Hegaret. “As a developer right now, you can’t really ignore it. Hopefully, in two or three years, you will be able to start ignoring IE6.”

See Also:

Tags: , , , , , ,
File Under: Browsers, Software, Web Services
Nov
17
2009

Mozilla Weave Goes 1.0, Firefox Sync Almost Ready for Primetime

By

Mozilla’s Weave, a free add-on for Firefox that syncs your personal data across multiple PCs and mobile devices, is just about to graduate from a lab experiment to a stable, ready-for-primetime add-on.

The latest release of Weave brings the add-on to 1.0 status, though for now it remains a beta release. Weave 1.0 isn’t significantly different than the Weave 0.8 release we covered earlier this month, but Mozilla does say that the latest version is significantly faster than earlier releases thanks to yet more refinements in Weave’s incremental syncing tool.

The new syncing process happens in “chunks,” which means even if you’re syncing hundreds of pages at once, Weave shouldn’t slow down your normal Firefox browsing. That said, we did experience a bit of a slow down on the initial sync. However, once Weave has uploaded your data, it runs transparently in the background and has little, if any impact on Firefox’s performance.

Weave 1.0 also improves its integration with Firefox’s preference pane, adding some sync options when setting up your Weave account. Instead of simply syncing from the PC you’re using, Weave now gives you the option to sync from the current PC, to the current PC or merge to current PC with existing data.

Syncing itself has been tweaked slightly as well using what Mozilla calls an “interestingness” algorithm. The process is similar to how the Awesome Bar works in Firefox — pages you visit frequently and those you’ve visited recently will sync ahead of less used pages in your history. For other data like bookmarks, the frequency data is combined with where the bookmark is stored. So, items visible in the bookmarks toolbar are ranked as “more important” and will sync before other bookmarks.

Weave 1.0 still carries the beta tag, but in our experience Weave is stable enough for everyday use. If you’d like to give it a try, head over the Mozilla Add-ons page and install Weave.

See Also:

Tags: , ,
File Under: Multimedia, Software
Nov
17
2009

Adobe Releases New Betas: AIR Gets a Boost, But Flash Player Disappoints

By

As promised, Adobe has released beta versions of both Flash Player 10.1 and AIR 2. Originally announced earlier this year at Adobe’s MAX conference, the goal of Flash Player 10.1 is to create a unified platform that works on every operating system, both on the desktop and on mobile platforms.

Unfortunately for the mobile platforms, the key enhancements to the current beta release are limited to desktop environments. However, an Adobe spokesperson tells Webmonkey that support for Palm’s webOS will arrive later this year with Android, Windows Mobile, BlackBerry, Symbian and Nokia support arriving in early 2010. Due to Apple’s developer restrictions, Flash will not be available on the iPhone.

The final release of Flash Player 10.1 is expected during the first half of 2010.

For now you’ll have to content yourself with improvements to the Flash desktop experience, and fortunately there are several welcome new features in Flash Player 10.1:

  • Support for multitouch and gestures — Flash Player 10.1 understands gestures on hardware that supports touchscreen interfaces. However, since the mobile support is still lacking, we’re having a hard time seeing where multitouch is useful beyond Windows 7 devices with touch screens (which are scarce).

  • GPU acceleration for H.264 video in Windows — This is good news for Windows users, but leaves us scratching our heads as to why the same isn’t available for Mac and Linux when plenty of other apps on both platforms already offer GPU-based acceleration.

  • Support for local microphone access — This may well be the best news for developers since it paves the way to create online audio editors capable of the same sort of sophistication we’ve seen with online image editing apps.

The GPU acceleration is particularly noteworthy since is means that underpowered PCs like netbooks will be able to offer smoother video playback while also cutting down on the battery drain. Flash Player 10.1 also offers much improved buffering that lets you drop offline and still keep watching a video.

However, while Flash Player 10.1 offers some new features, this beta release is almost as significant for what it doesn’t include. Although Adobe says it’s in the works, you won’t find support for 64 bit operating systems, nor, if you happen to be on Mac or Linux, will you be able to take advantage of the new GPU acceleration.

Adobe already plans to have several updates to the beta before Flash Player 10.1 is officially released, but with mobile support still not ready and Flash Player 10.1 features varying considerably by platform it’s obvious that Flash still has a long way to go before it will fulfill Adobe’s goal of making Flash work everywhere.

And that’s an important goal, since there’s a new player in the multimedia world of the web that also plans to work everywhere: HTML5.

HTML5 has been touted as a “Flash killer,” making the ubiquitous plug-in unnecessary with new tags to embed video and create animations directly within HTML. The only problem is that HTML5 is not finished and browser support is far from complete.

But judging by today’s beta release, Flash Player 10.1 is also far from complete. If Adobe hopes to continue fending off HTML5 — which has strong support from the likes of Google and Apple — the pressure is on to deliver something more impressive than this beta by the time final release in 2010.

While Flash may be struggling a bit, Adobe AIR 2, the company’s runtime environment for making web-like native apps on the desktop and on mobiles, fares much better in this beta release. In fact, the new version of AIR, has some welcome new features and none of the cross-platform confusion.

In this release, AIR, which is perhaps most notable for its Twitter clients like TweetDeck, Alert Thingy or Twhirl, gains a very nice a native process API that will enable AIR apps to communicate with OS-native tools.

For example, TweetDeck could tap into Spotlight on Mac OS X to deliver search results from your system’s hard disk. The nice thing for developers is that the native process API means that the application itself is still cross platform. Also welcome is the ability to deliver OS-specific installers like .exe, .dmg, or .deb instead of the somewhat confusing .air installer.

AIR applications can also now detect and use attached USB devices — for example, plug in a USB stick full of photos and an AIR-based image editor can now import them for you.

Other AIR improvements include support for drag-and-drop file exporting, a faster version of WebKit (for AIR’s HTML support), as well as the same microphone and multitouch support found in Flash Player 10.

Webmonkey editor Michael Calore also contributed to this report.

See Also:

Tags: , ,
File Under: Programming, Software
Nov
13
2009

Great Documentation Is Key to Open Source Success

By

Listen up open source developers, if you want your project to succeed you’re going to have to do more than write great code; you’re going to have to document it, teach new users how it works and provide real-world examples of what you can do with it.

That’s the message from Jacob Kaplan-Moss, one of the creators of Django, a very successful open source, Python-based web framework. At least some Django’s success can be attributed to its thorough documentation which is not just reference materials, but also includes tutorials, topical guides and even snippets of design philosophy.

Of course Django is not alone in having great documentation; Ruby on Rails is another highly successful open source project featuring great docs, tutorials and reference materials. Beginning to see a pattern? Great docs == happy, enthusiastic users == open source success.

Too often open source projects seem to turn up their nose at documentation, arguing that the code is well-commented or that developers should be able to figure it out for themselves — with the implicit suggestion that those who can’t don’t matter. That’s fine for some projects, but if you want your code to be more than a random page on Github, you’re going to need good documentation.

In an effort to help other projects improve their documentation, Kaplan-Moss has embarked on a series of articles outlining what he and the rest of Django’s developers have learned from the countless hours spent creating and refining Django’s docs.

While it’s worth reading through the entire series (and there’s more on the way), the basic message is quite simple: good documentation is more than just technical reference material.

What makes Django’s documentation stand out (and Ruby on Rails as well) is that it covers the details as well as the high-level overview of how the details fit together. Kaplan-Moss breaks down the types of documentation into three basic categories:

  • Tutorials — Tutorials are a great way to introduce users to your software and demonstrate high-level concepts in real world examples. Too many tutorials teach you little more than how to create a “hello world” script. Good tutorials should help your users actually build something, which is much more exciting for a new user than printing out a line or two of text. As Kaplan-Moss says “that rush of success as you work through a good tutorial will likely color your future opinions about the project.” Tutorials are the best way to make a great first impression on your potential converts.
  • Topical Guides — This is the real meat of good documentation and will be what users return to over and over again as they learn how to use your software. Kaplan-Moss’ advice is to aim for comprehensiveness: “the reader ought to come away from a close read feeling very comfortable with the topic in question… they should feel that they know the vast majority of the possible options, and more importantly they should understand how all the concepts fit together.”
  • Reference — Sadly reference materials are in fact what passes for documentation in much of the open source world. That’s not to demean reference guides; complete lists of class names and methods are absolutely necessary, but don’t stop there. As Kaplan-Moss writes, “think of guides and reference as partners: guides give you the ‘why,’ and reference gives you the ‘how.’”

If you’d like to see an example of well-done documentation that covers all these ideas, look no further than the Django Project website, which hosts all of Django’s documentation. The Ruby on Rails community has also produced excellent documentation.

Kaplan-Moss has two more parts to his documentation series, one in which he delves into topics like writing well, developing a clear, grammatically correct style and another that focuses on editing.

Kaplan-Moss’ post on technical style also covers things like markup and structural layout of documentation, since even the best documentation is useless if you can’t find what you need. For example one of the best parts of Django’s documentation is that every topic and reference page has a liberal dose of inline links that make it easy to jump from one section to another. While we wouldn’t suggest using wiki software, the everything-is-a-link model of wikis makes a good starting point for marking up your online documentation.

One of the biggest hurdles for many open source projects is finding good writers to create documentation. While Kaplan-Moss has some suggestions for making yourself a better writer, many developers don’t have the time to improve their writing skills. To that end we suggest paying close attention to your community.

Watch for blog posts from your users that offer tutorials or provide an in-depth at some aspect of your software. Contact the authors and see if you can incorporate their posts into the documentation. Give your users a chance to contribute not just code, but their understanding of the code — ask them to write more and make them a part of the project when appropriate.

Finally, perhaps the most important message of Kaplan-Moss’ post is that ultimately… some documentation always trumps no documentation.” Maybe your documentation isn’t on par with Django or Ruby on Rails, but don’t let that stop you from producing at least something. And be sure to check back with Kaplan-Moss’ site for more articles on creating good docs for your project.

See Also:

Tags: ,
File Under: Backend, servers, Web Basics
Nov
12
2009

Move Over, HTTP. Say ‘Hello World’ to SPDY

By

Google plans to introduce a new protocol for web transactions it says is more than 50 percent faster than HTTP.

A post on Google’s Chromium blog describes the new protocol, SPDY, pronounced “Speedy”:

SPDY is at its core an application-layer protocol for transporting content over the web. It is designed specifically for minimizing latency through features such as multiplexed streams, request prioritization and HTTP header compression.

The Chromium team, which is in charge of developing the Chrome browser and its associated technologies, reports that SPDY has been able to load web pages 55 percent faster than the HTTP protocol in lab conditions using simulated home-network connections. The team says its goal is to make SPDY eventually run twice as fast as HTTP.

HTTP is the language currently used by servers and browsers for the vast majority of common tasks on the web. When you request a web page or a file from a server, chances are your browser sends that request using HTTP. The server answers using HTTP, too. This is why “http” appears at the beginning of most web addresses.

So, Google’s proposal would involve rewriting the web’s most commonly used and baked-in transaction method.

“HTTP has served the web incredibly well,” the post’s authors write. “We want to continue building on the web’s tradition of experimentation and optimization, to further support the evolution of websites and browsers.”

If such a massive shift were to ever take place (and nobody’s promising it will at this point), it would require a whole lot of buy-in from outside Google. To that end, the company is releasing its early-stage documentation and code for SPDY along with a call for feedback.

It may seem like a brash move, but the Chromium team seems to enjoy ruffling feathers. In September, the same group released the Chrome Frame plug-in for Internet Explorer which essentially embeds Google’s browser inside Microsoft’s, giving the ability to render websites that IE wouldn’t normally be able to handle.

To contribute to the SPDY discussion, visit the Chromium Google Group.

Image: Warner Brothers

See Also:

Tags: , ,
File Under: CSS, Fonts, Web Services
Nov
12
2009

Review: Typekit Delivers Custom Web Fonts to the Masses

By

A new service called Typekit is now offering a legal, cloud-based method of using more elaborate typefaces on the web. The service has come out of beta and is serving up its fonts to web designers.

Despite some inconsistencies between browsers (not Typekit’s fault) and a few other quirks, we found Typekit to be a viable option for web designers looking to incorporate custom fonts into their designs.

Typekit is like a YouTube for fonts. Browse through Typekit’s library of available fonts, pick one you like and cut and paste some code into your site. As we noted when we first looked at Typekit earlier this year, the service is one of the easiest ways for web designers to use creative fonts without sacrificing web standards or violating font licenses.

Of course, that ease and convenience doesn’t come without a price. There is a free trial option for Typekit, which allows you to test out the service. But if you’re serious about custom fonts, you’ll want to go with one of the paid options which range from $25 to $250 per year. The more you spend, the more font choices, domains and bandwidth you’ll get.

Typekit arrives at a time when type on the web is at a crossroads. For years, designers have been limited to using only a set of five or six common fonts on web pages. But thanks to new font-rendering tools within the emerging HTML5 and CSS3 standards, web designers now have the ability to use newer, more visually interesting typefaces — and make that type appear more consistently across browsers, operating systems and screen resolutions. Even with these new abilities, intervening forces like DRM, licensing restrictions and varying levels of support from the browser makers have stalled progress, forcing the modern designer to resort to a variety of workarounds and hacks if they want to use these new fonts.

Along with Typekit’s arrival, we’ve seen other promising developments recently, like the move by some browser makers towards adopting a new font format called WOFF which would allow better control over layouts and designs.

To see how Typekit performed in the wild, we opted to try out the free option and see if Typekit was good enough to warrant the expense. The short answer is yes, but with some drawbacks.

Before you dive in to Typekit, it’s important to remember the one very large caveat — Typekit only works in browsers that support the CSS @font-face rule. That means Firefox 3.5 and higher, Safari 3.4 and higher, and Internet Explorer 6 and higher.

While that’s not ideal, the good news is that browsers that don’t understand Typekit’s fonts can simply fall back on a default you’ve defined.

There is another slight problem, though. In some cases, fonts rendered in browsers on Windows XP can look jagged and difficult to read. The problems is that Windows XP often doesn’t have anti-aliasing turned on by default. Of course it’s worth noting that even if you don’t use @font-face, standard fonts will also be jagged on such systems. The difference is that most of the standard fonts are still readable, while in some cases custom fonts become a total disaster.

To get started with Typekit, just create an account and tell Typekit the domain where you’ll be serving the fonts. We were happy to see that Typekit will support the localhost domain for testing purposes, something many online services and APIs overlook.

After your account has been created and your domain set up, Typekit will then give a snippet of HTML to include on your site. The code simply loads Typekit’s JavaScript library; all you need to do is paste the HTML in the <head> of your site.

Now it’s time to pick some fonts. Typekit’s range of fonts depends on the amount of money you want to spend. For a trial account, you’ll have just under 70 fonts to choose from. The “personal” library ($25/year) has roughly 230 fonts and the full library ($50/year) nearly 300.

The Typekit font-browsing interface is very well designed and offers some nice tools for choosing a good font — like a live preview of the font and numerous size previews for judging readability.

Typekit’s live preview tool with custom text. Click the image for a larger view.

Once you’ve selected a font, you’ll need to configure it for your site. The Typekit editor lets you control which CSS selectors your custom fonts will be applied to, which weights and styles to use, and what font to fall back on for browsers that don’t understand @font-face.

If you’d rather apply a font to all elements on your site, you can define your own custom font-family rules in your CSS file, for example h1 {font-family: "tenby-seven-1"} would apply the Tenby Seven font to all headlines on the site.

Typekit’s editor tool for customizing fonts. Click the image for a larger view.

The next step is to publish your font, which then makes it available on your domain.

The results looked great in our testing, especially in Safari 4, which seems to render type a bit thinner than Firefox on the Mac. On the Windows side, the results were roughly the same between browsers that supported Typekit.

One thing that seems unavoidable with @font-face, whether it’s through Typekit or otherwise, is a brief flash of unstyled text. It’s annoying, but for now there doesn’t seem to be anything you can do about.

There are some other drawbacks — the need for JavaScript and the additional data that increases page load times — but so long as you’ve already accepted @font-face‘s shortcomings, Typekit makes the process of using it simple and easy. Other possibilities for broadening your type selection include Typotheque and a new service Kernest.

See Also:

Tags: , ,
File Under: Ajax, Programming
Nov
11
2009

Meet Go, Google’s New Programming Language

By

Google has released a brand-new programming language it hopes will solve some of the problems with existing languages such as Java and C++.

The language is called Go, and it was released under an open source license Tuesday. Google is no stranger to the open source world. The company has released the underlying code for several of its tools and services under open source licenses over the years. Just last week, Google released its Closure JavaScript tools for building Ajax web apps. And now Google has considerably upped its investment in free software with the release of Go, which is an entirely new programming language.

At first glance, Go looks a bit like C++, but borrows some elements, such as garbage collection, from scripting languages like Python and JavaScript. But Go’s real standout feature is its speed. A demo video shows the entire language — over 120K lines of code — compiling in under 10 seconds.

As a systems language, Go is intended to be used for developer applications like, for example, web servers. In fact, the golang.org website is being hosted by a Go program. But as Go developer Rob Pike says in recent Google Tech talk, “although Go is designed as a systems language, it has a much broader use than that.” Pike goes on to cite front-ends and other general purpose programming that Go can handle.

One of the most appealing parts of Go is its ability to handle multicore processors and, as Google’s FAQ explains, “provide fundamental support for concurrent execution and communication.”

Existing systems languages like C++ evolved long before today’s modern, and very fast, processors hit the market and make supporting multicore chips more difficult. While Google could have concentrated on writing libraries that can handle those tasks in C++, the developers behind Go say that “too many of the problems — lack of garbage collection, long dependency chains, nested include files, lack of concurrency awareness — are rooted in the design of the C and C++ languages themselves,” and decided it was time for something entirely new.

Like many of Google’s open source projects, Go began life as a 20 percent time project (the time Google gives its engineers to experiment) and evolved into something more serious. Go has been in development for over two years now, but Google is hoping that, by releasing Go under a BSD-style license, a community will develop and build Go into a viable choice for software development.

At the moment, Go is still very young and experimental. Even Google isn’t currently using Go in “large-scale production” applications. While the site that’s hosting the code is running a server built with Go as a proof of concept, the primary purpose of this release is to attract developers and help build a community around Go.

Despite its fledgling status, Go already supports many of the standard tools you’d expect from a systems language and even includes support for other Google tools like Protocol Buffers.

Also, it’s worth noting that Google’s Go is not to be confused with an existing language entitled Go! (note explanation point). Google Blogoscoped reports that Go!’s developer Francis McCabe would like Google to change the name of Go, but thus far Google has not responded to that request.

At the moment Go is only available for Linux and Mac OS. If you’d like to learn more, check out the video of Pike’s tech talk below (it’s long, but offers a pretty thorough overview of Go) or head to the new Go website.

See Also:

Tags: ,
File Under: Web Apps, Web Services
Nov
11
2009

Google Cuts Online Storage Pricing, Fuels Anticipation for Cheap Cloud-Based OS

By

Google has dropped the prices for extra storage space in Gmail and Picasa. Ostensibly the prices have gone down because storage costs have dropped, but it might also be a necessary move anticipating the coming Chrome OS, which will likely need sizable online storage space.

For now, if you need some extra space for your Gmail or Picasa Web Albums, you can get it at a much more reasonable price. You can now buy 20 GB of storage for $5 a year — that’s twice as much storage for a quarter of Google’s old prices.

If that’s not enough, you can pick up 80 GB for $20 a year, 200 GB for $50 a year and so on, all way up to 16 TB of storage for $4096 per year. The Google Accounts page has a full list of pricing and storage options.

Compared to other online storage solutions, like Dropbox, which charges $240 per year for 100 GB, Google’s new pricing looks pretty good. Of course Google’s extra storage doesn’t sync files between computers like Dropbox does, but it might when Google’s Chrome OS finally emerges.

Chrome OS is little more than a vague press release at this point, but based on what we know, Google plans to make Chrome OS a lightweight operating system for netbooks with a strong link to the cloud — think a web browser on top of a bare-bones Linux kernel.

Given the space limitations of netbooks, and Chrome OS’s integration with online Google Services — like Google Docs — it makes sense for Google to offer large amounts of storage on the cheap. In fact, Google wouldn’t be the first to do so. Many netbook makers, like Asus, already offer free online storage in conjunction with the purchase of a netbook.

There’s also, as Google Operating System speculates, the possibility that the storage increase will go toward the long-fabled “GDrive.” According to rumors that have been circulating for years, Google is hard at work on a Dropbox-like, cloud-storage and syncing service. It’s already known Google has a massive storage grid called Platypus which the company uses as its storage back-end for most of its web-based tools.

While there’s no question that such a service would be a huge sell at these prices, GDrive remains a mere rumor, one that, quite frankly, we stopped believing years ago.

There’s no telling what Google plans to do with its additional storage offerings in the future, but at least, for now, you’ve got a much cheaper way to back up all those hi-res photos in Picasa or expand your Gmail account far beyond its current 7+ GB limit.

We should also point out, if you’ve already paid the old prices for additional storage, fear not, Google will automatically bump your storage space. For example, if you paid for 10 GB of storage at the old pricing you should now have 80 GB of storage available.

See Also:

Tags: ,
File Under: Browsers
Nov
11
2009

Mozilla Paves the Way for Firefox 3.6 With Second Beta Release

By

Just two weeks after the first beta release of Firefox 3.6, Mozilla has already pushed out a second beta for users to test. Mozilla is making good on its promise to deliver Firefox 3.6 without the extended delays that plagued the 3.5 release.

Firefox 3.6 beta 2, released Wednesday, brings 190 more bug fixes to the table and offers the same performance boosts we saw in the first beta release. Firefox 3.6 also includes a number of new features like support for Personas, native tab-previews for Windows 7 and Web Open Font Format support for developers looking to use new fonts on their sites.

For a more in-depth look at what’s coming in the next version of Firefox — due to arrive in final form sometime before the end of 2009 — have a look at our coverage of the first beta release.

While Firefox 3.6 is still a beta release, if you’d like to test out the new features you can grab a copy from Firefox beta page. Also, if you’re running beta 1, you’ll notice Firefox probably gave you an alert as soon as beta 2 was ready.

So far, we haven’t noticed any show-stopping bugs in beta 2, but keep in mind that most extensions haven’t been updated to work with this release. That said, a few of our favorites do indeed work, notably AdBlock Plus and Firebug, though in both cases you’ll need to make sure you have the latest versions of the add-ons.

You can help out add-on developers by grabbing the Add-on Compatibility Reporter, which will run all your extensions even if they haven’t been updated. Any resulting bugs or strange behaviors can be easily reported to the developers through the Add-ons Manager.

See Also:

Tags: , ,
File Under: HTML, Mobile
Nov
10
2009

How to Handle Mobile Site Redirects

By

Building a mobile-optimized website is an increasingly common task being asked of web developers. Mobile-optimized designs take into account small screen size and often compress content for delivery over slower networks.

Mobile sub-sites are often the first strategy developers turn to. But at the same time, full-fledged mobile browsers like Safari, the Android browser and Opera Mobile mean that many users don’t necessarily need a mobile site; their browsers are capable of rendering any page, albeit with some pretty tiny text.

This creates something of a problem for web designers — how to you handle mobile visitors? Should you redirect them to your mobile site? Just serve the full size version? Offer links from one to the other?

Those are the questions Django developer Eric Holscher recently raised on his blog asking the community how to handle mobile browsers. Holscher breaks down the possible use cases for a mobile site as follows (note that all of these scenarios involve some sort of user-agent detection):

  • No Redirects — In other words, the mobile site lives at a distinct URL, but by default the main site is served to everyone, regardless of browser. The advantage is that those who don’t want a mobile site don’t get one, but at the same time some of your visitors might want a mobile site and in this case they can’t get to one without some effort on their part.
  • Redirect once (opt in) — As Holscher defines it, this “allows the mobile user to get a glimpse of your mobile site the first time they visit, and can then choose to visit in the future.” The problem here is that mobile browsers don’t always do well with cookies.
  • Always redirect (opt out) — In this scenario, users are always sent to the mobile site, but offered a link to the full site. If you do use this scenario, for the love of angle brackets, make sure you direct to the full URL of the page your visitor is currently reading. Redirecting from a blog permalink to the mobile homepage is about as useful as giving away free buckets of hamster vomit.
  • Interstitial page — Holscher doesn’t mention this one, but it does come up in the comments on his post, where several developers suggest offering a link before the page loads. Something along the lines of, “would you like to view our mobile site or the full size version?”

So what’s the best solution? Well, there is no one-size-fits-all answer. Which option will work best for your visitors depends on several factors.

Is your mobile site functionally identical to your full-sized site? If so, then there’s no real harm in redirecting to the mobile version. Just make sure you offer a link to the same page on the normal site for those who don’t want the mobile version.

This seems to be one of the more common workflows for mobile sites — Google’s mobile apps, Wikipedia’s mobile site and even Facebook.com take this approach.

If your mobile site lacks certain features found on your main site, we suggest avoiding redirects. The thing to keep in mind with a functionality-limited site is that, while your mobile site might not be a full-class web citizen, there’s a good chance your mobile visitor’s browser is a full class browser, which means they might not want to deal with your mobile limitations.

Regardless of which solution you chose, pay attention to your logs and watch your user’s behavior. If you see a lot of redirect traffic immediately clicking the link back to your main site it’s time to rethink your strategy.

Tags: ,
« OLDER POSTS