If you’ve visited Google’s home page Tuesday, you’ve seen the bouncy ball demo. The Google logo is made of little colored balls that run away from your mouse and jump around furiously when you click on them. The balls will also jiggle from side-to-side if you move your browser window around.
The company did it using CSS positioning and some JavaScript math.random functions, so it works best in non-IE browsers with fancy JavaScript engines. In the useless-but-freaky-cool department, it ranks up there with the playable Pac-Man doodle from earlier this year.
Not content to let Google have all the fun, Rob Hawkes created an alternate version using HTML5 canvas that reproduces most of the functionality. His code is on github, too.
If you’ve played around with optimizing your website for small screens, you know one of the big headaches is resizing images. You can set the viewport in your head tags to make sure your main content is the focus on mobile devices, but you can’t easily shrink images.
On many mobile devices, rendering the images is what slows down page load times. That’s where TinySrc comes in. It’s a clever service that parses your images and presents scaled-down versions to mobile devices.
Using tinySrc is pretty simple, all you need to do is prefix your image URLs with the tinySrc domain, something like:
http://i.tinysrc.mobi/http://foo.com/foo.pngTinySrc will then detect the device that’s visiting your site (tinySrc has partnered with Device Atlas so its device listings are extensive) and serve out an appropriately shrunken version of your image.
If you’d like complete control over the size of your images, you can specify parameters in the URL. For more details on all of tinySrc’s settings see the documentation.
While you are relying on a third party service — a choice which always carries the usual concerns about speed and reliability — tinySrc is definitely one of the fastest, easiest ways to shrink your images for the small screen.
[via Ajaxian]
See Also:
Google is now letting any Yahoo users sign in to Google using OpenID, the company announced Tuesday.
When you’re signing up for a Google account, there’s now a new button you can click on that says “Verify by signing in at Yahoo.com.” Click it, and you’re sent to Yahoo, where you’re asked to allow Google and Yahoo to link up your accounts.
Tuesday’s development marks Google’s first attempt to be an OpenID relying party — a website that accepts OpenID logins from third-party providers. Also, this only works for Yahoo users for now, but Google says it’s going to start offering support for other OpenID providers soon.
On the surface, this may look like an attempt by Google to poach users away from Yahoo by making it even easier for them to switch. In fact, it’s a real-world example of the type of interoperability that OpenID has been promising to bring to the open web for some time.
The more services, web apps and social networks we sign up for, the more places we have to create an account, remember a password, find friends, and build up a user profile. OpenID and the other twiddly bits in the “open stack” of social web technologies — like OAuth and Portable Contacts — make it easier for us to securely re-use this data across numerous websites and applications while only having to maintain one user account and one password at the provider of our choosing. With OpenID and OAuth, your data can easily be forklifted into other social networks with just a few clicks. OpenID currently powers the majority of third-party logins on the web.
This new Google/Yahoo system works because Yahoo is an OpenID provider. If you have a Yahoo account, you can use it to log in to any website that accepts OpenID. Google has simply started using the Yahoo OpenID API, the bit of code that makes it easier for third parties to create a simple, streamlined login experience for visitors who want to use their Yahoo ID to log in.
The same type of third-party login is possible using your Google account, since Google exposes the information necessary to make that happen in its own OpenID APIs.
So there’s no poaching happening here, just an open door policy on Yahoo’s end, and the implementation of one of Yahoo’s APIs on Google’s end.
Google is currently only offering OpenID logins for Yahoo users, the company says. The Google Code blog gives some more detail: “As [the new login feature] is based on an internet standard, we plan to use it in the future with other e-mail providers that add support for this usage of OpenID and related standards like OAuth, such as in the Microsoft Live identity APIs.”
Google is also experimenting with an OpenID/OAuth hybrid called Step2, which builds on similar community efforts to build a new system based on those two technologies. Among other things, these new hybrid systems aim to make the process less confusing for users, and to make OAuth sign-ins easier for applications that run on a phone or on the desktop rather than in a web browser.
See also:
Six Apart is shutting down its Vox blogging service. Users have until Sept. 30 to export their data to other services, including Six Apart’s TypePad blogging service. After that, Vox will be gone.
If you’ve got a Vox blog, there are several export options — Six Apart has instructions for moving to TypePad, Posterous and WordPress. There’s also an option to move your photos and videos over to Flickr.
Of course none of those services quite combine the privacy and small social network features that endeared Vox to users, but at least you can retrieve your content in some form.
The export options also make no mention of the fact that Vox is an OpenID provider, which means that, presumably, when your Vox URL is gone, your OpenID is gone with it. That means any site you’ve signed into using your Vox account will no longer let you sign in. In some cases that could mean a total loss of access to the third-party site — exactly the sort of thing OpenID is supposed to help prevent.
UPDATE: Six Apart vice president Michael Sippey responds to this issue in the comments. We’ve added it here:
Quick note. Vox will continue to serve as an OpenID provider through September 30. If a Vox user chooses to migrate their blog to TypePad, OpenID requests at the original Vox address will delegate to TypePad for authentication.
We know that shuttering a service is never easy on users; We’ve invested a lot of time and effort in making sure that there are tools in place to migrate content off of Vox, and that if folks are using Vox as their OpenID provider that there’s a solution in place for them.
If there’s a moral to Vox shutting down, it’s pretty simple: choose your OpenID provider with care. It would seem that the bigger the provider, the safer you are. Alternately you could be your own OpenID provider, ensuring that you retain control over your identity.
Six Apart’s blog does not give any reason for the shutdown, and the company did not respond to requests to comment on this story. However, it seems likely that Vox was simply supplanted by Facebook, Twitter and other, more popular means of sharing content with your web friends.
The social network landscape has also changed considerably since Vox launched in 2006. Much of the initial appeal of Vox — namely, its tightly controlled privacy — is less of a concern for many of today’s users.
See Also:
Google is celebrating the second birthday of its Chrome web browser with the release of a new, improved version.
Chrome 6 arrives with an updated user interface, better syncing tools that include support for web form data and extensions, and — as should be expected with every new browser release these days — increased speed and numerous bug fixes.
If you don’t want to wait for Chrome to automatically update, head over to the download page and grab Chrome 6 for Windows, Mac and Linux.
Google’s browser is in an enviable position right now. It recently passed Safari in user share — new data from August shows the lead it snagged in June is stretching — and it’s gaining on Firefox and IE. Also, in a market where raw speed is the most important metric, Chrome is enjoying a solid reputation as the one of the fastest — if not the fastest — browser on the scene.
Chrome has also had considerable impact on how other browsers in the market look and behave since it arrived in September, 2008. It kickstarted a shift toward minimal interfaces that Firefox and Internet Explorer are mimicking. Chrome also started the trend of tightly sandboxing web browsers to improve stability and security.
If you’ve been using early builds of Chrome 6, there isn’t much here that’s new, but if you’re upgrading from the older, stable release of Chrome 5 there are quite a few changes.
Perhaps the most noticeable thing about Chrome 6 is what’s missing — almost all the toolbar buttons. Chrome has consolidated nearly everything into a new menu button to the right of the URL bar. Click it and you’ll find the browser’s most-used menu functions.
Other nice touches include a new green padlock icon in the URL bar to indicate you’re on a secure HTTPS connection, and a less-cluttered new tab page that serves as your starting point for new browsing windows.
Chrome 6 isn’t just a visual update — new features like form auto-fill make for faster checkouts at e-commerce sites and faster sign-ups on new services. Chrome can now also sync both your autofill form data and any installed extensions across all your computers.
Chrome may be celebrating its second birthday, but it isn’t resting on its laurels. The Chrome dev channel already contains an embryonic version of Chrome 7 with hardware acceleration and the new “Tabpose” feature for quickly switching between your open tabs.
Browser data from NetMarketShare, chart from Google. Browsers with less than 2 percent share have been omitted.
See Also:
With all the attention being paid to HTML5’s <video> tag, few have clued in to what is perhaps the most useful magical pixie dust hidden inside the web’s next markup language: the new semantic tags.
Rather than using <div> tags to wrap your page sections, HTML5 offers much more sensible elements like <header>, <nav>, <section>, <article>, <footer>, <aside> and <time>.
Of course, cool as the new tags are, they don’t cover every situation, which is why, as with HTML 4, you can extend HTML5’s tags to add even more semantic meaning to your pages.
One of the more useful ways to extend HTML is with microformats — small chunks of semantic markup for address book info, event listings and machine-readable metadata. In HTML 4, this is done using the class, rel, rev and profile attributes, along with some established design patterns and nested tags.
However, HTML5 tosses out the rev and profile attributes and adds some new things like WAI-ARIA’s role and aria- attributes, as well as the new data- attribute system.
So where does that leave microformats? Well, the answer is a bit complicated, but our friends over at HTML5 Doctor recently dove into the confusion and have published a rough guide to what works in HTML5. There are some great tips, not only about implementation, but also what you should avoid and what might change in the future.
The article walks through a number of common microformats like address cards and licensing information, showing how they work in HTML 4 and what elements might be extended in HTML5 — like using the time element within the hCalendar microformat.
In the end, while the article has some caveats you should read up on, the good news is that you can safely use microformats in HTML5. Also, be sure to read through the comments on the post as Tantek Çelik, one of the authors of microformats, has some important clarifications and suggestions for using microformats in HTML5.
See Also:
We all want our websites to load faster, but speeding things up can be tricky. There are numerous tried and true tricks we all use to keep page load times down, but once you’ve done a few rounds of optimization, you tend to hit a plateau where it’s tough to squeeze any more speed out of your code.
Most web developers are familiar with tools like Yahoo’s YSlow and Google’s Page Speed. If you haven’t ever used them, go install both right now — they’re available as add-ons for Firefox. Both tools are designed to help you speed up your site’s page load times by showing you exactly what’s slowing them down, and used in tandem, they can alert you to some optimizations you never knew existed.
I recently sat down and tried, as best I could, to do everything that YSlow and PageSpeed recommended and I managed to shave my page load time roughly in half. When I started, my homepage took between four and six seconds to load. Now, it loads in one to three seconds on average.
To compare load times I used both YSlow and PageSpeed, as well as WebPageTest. Those numbers aren’t exactly benchmarks, since there’s some speed variation depending on what’s loaded in the cache, but a performance increase of about 30-40 percent is what you can expect if you haven’t yet explored these methods.
Some of what YSlow and Page Speed will tell you should be obvious — limit your HTTP requests, minimize, compress and combine your JavaScript and CSS files, use CSS Sprites, put your script tags at the bottom of the page and compress your images.
However, some of the more obscure and less-used (judging by viewing source code around the web) techniques these tools point out can make a surprising difference.
Before we get to the “how to” part, keep in mind the old saying “premature optimization is the root of all evil.” What I did with YSlow and its ilk was the last bit of optimization I did. In other words, be sure you’ve taken care of the big problems before you try to stamp out the smaller ones.
That said, I was surprised by how much of a difference some very small changes made.
The Good
Long before I turned to YSlow, I optimized my backend code to minimize database hits, installed Memcached to further reduce the database load, and set up a separate domain to serve static files. The later change made a huge difference since the main instance of my site is running Apache and the static files are now served by a much lighter-weight, faster Nginx server.
The site I set out to test YSlow and Page Speed on is my travel blog, which is somewhat image-heavy. So, the first thing I did was run all my images through SmushIt, Yahoo’s lossless image compression tool that’s part of YSlow.
All of the images on the site were already compressed using Photoshop’s “Save for Web” exporter, but I still managed to shave an additional 2-5kb off my images without any loss of quality using SmushIt. When you’re loading ten or more images per page, that’s a significant savings.
In fact, I could compress my images quite a bit more if I were willing to make some trade-offs in image quality. I’m not in this case, but you might be able to. The best approach in my experience is to see what your overall image size is, run everything through SmushIt and, if you still aren’t happy with the results, go back to your image editor and see if you can compress things even more using lossy techniques.
The BadWhile I managed to squeeze down my images somewhat, for the most part I was already following the more obvious best practices — loading JavaScript last, using multiple domains and so on.
It wasn’t until I turned to my style sheets that I saw where I had really gone wrong.
Perhaps the most overlooked thing you can do to speed up your page is reduce the complexity of your style sheets. Wherever possible, use classes to group similar elements and make sure you take advantage of the cascade. If all your body text is going to be Georgia, define that rule once under the body tag rather than littering it throughout your style sheet.
Another thing you may notice Page Speed telling you to do is “Use efficient CSS selectors.” Browsers read CSS from right to left, so the more specific your selectors, the less time it takes the browser to figure out what to do with that element. The less specific the selector, the greater the number of nodes the browser needs to evaluate.
Consider this HTML, a fairly typical HTMl5 navigation menu:
<nav id="top"> <ul> <li> <a href="/" title="My homepage">Home</a> </li> <li> <a href="/" title="My Blog">Blog</a> </li> <li> <a href="/" title="My Photos">Photos</a> </li> </ul> </nav>
Now suppose you want to style the actual link element. The most inefficient way to do this would be something like this:
nav#top ul li a { color: red; }
In order to figure out which a you’re talking about, the browser needs to traverse four tags. Let’s redo that with something much more efficient:
<h1>top a { color: red; }</h1>
Now there are just two tags to traverse. And note that we got rid of the nav selector with the ID, and the ID is already unique. There’s no need to add the tag as well.
If we wanted to be even more efficient, we could add a class called “red” to each of our a tags and simply do this:
.red {color: red;}
So how much does this gain you? In my case, re-writing my CSS — which had grown pretty sloppy over the years — dropped a full second from my page load time. That may not sound like much (and it isn’t if you have inefficient database queries or other, bigger problems), but when it comes to this stage of optimization, every little bit helps.
The UglyA few of YSlow and Page Speed’s suggestions aren’t possible in some cases, mine included. One big thing that could speed up my static content would be to use a CDN. Unfortunately CDN’s are expensive and outside the price range of small blogs like mine. Also, a shared server is cheaper than a dedicated server, but can be slower.
Other unfixable problems are due to my hosting setup. I can’t set the expires headers for my static files because my Nginx server is global for all shared hosts on that server. Luckily, with Nginx, the first load is pretty fast. The browser may not cache images and static files as aggressively as I’d like, but for now it works well enough. I could compile my own instance of Nginx, and thus set the expires headers myself, but I haven’t tried that yet.
Another problem that Google’s Page Speed tool likes to nag you about is using cookie-less domains for static images. In my case, I serve my static files from the subdomains media and images. Because my top-level domain needs cookies, the subdomains inherit them as well. This is why big sites like Yahoo use an entirely separate domain for static files (usually some subdomain of yimg.com in Yahoo’s case).
There are some other areas that didn’t apply in my case, but may be slowing down your site. One big culprit is third-party content. If you’re loading JavaScript from other sites — to add social networking or bookmarking buttons, for example — pay close attention to how fast those scripts load. They are notorious for slowing your page down.
Another easy way to speed up your pages is to make sure your CSS and JavaScript files are served using GZip compression. Good web hosts should offer a way to do this. If yours doesn’t, consider jumping ship for one that does.
As with any kind of optimization, there are trade-offs involved with nearly everything that YSlow and Page Speed will suggest. For example, to make your CSS selectors more efficient, you may be tempted to litter your HTML with IDs, which is a no-no if you’re trying to maintain good semantic code. Likewise, compressing images is all good and well, but turn them into a pixelated mess and you’ll turn people off no matter how fast your site is.
The secret to good optimization is to find a balance. Provide quality content and wrap it in well-written code, but also make sure what you create loads as fast as possible. Don’t sacrifice too much quality in the name of speed, and vice versa.
Illustration from “Physics for Entertainment” by Yakov Isidorovich Perelman from Archive.org
See Also:
Word is out that Firefox 4, when it ships at the end of October or thereabouts, will probably not include support for older, non-Intel Macs.
Mozilla’s director of Firefox Mike Beltzner hinted at the change on a Mozilla developer mailing list last week: “I am gathering data on the number of PPC users we have, but the likely outcome is that we will not be supporting PPC for Firefox 4. More on that as I get the data.”
PowerPC Mac users have precious few options for modern web browsers these days. Firefox 3.6 will likely be the last Firefox option for PowerPC Macs, and Google Chrome only runs on Intel machines. Apple is still supporting PowerPC Macs with Safari releases, but the latest version, Safari 5, requires Mac OS X 10.5 or later — users still running 10.4 (Tiger) can only run Safari 4.1, which has many of the features found in Safari 5, but is likely the end of the line. Opera 10 runs on older PowerPC Macs, but it struggles. Opera 9 is more reliable, but has fewer features. Slim pickings, and getting slimmer.
Of course, the problem could be solved by upgrading. And we have — most of us already have second or third machines at this point.
Our aging computers, especially laptops, are often put into service as dedicated devices for streaming music, checking e-mail or browsing recipes in the kitchen. In today’s cloud-based world, you need a good web browser to do most of those tasks.
An old machine that still runs but doesn’t have a decent browser is basically worthless.
I have one such old Mac — a G3 iBook — and my personal savior has been Camino. It’s a fantastic browser built on Firefox code. It can handle all the necessary music streaming and Gmail duties, and it’s lightweight enough to do so without beachballing. I don’t need all my add-ons and doo-dads, just Flash Player and a reasonable level of stability. I’ve been using it for years.
Charles Moore over at GigaOM has been experimenting with other choices on his old Macs, trying SeaMonkey, iCab and an old build of Opera, all with varying levels of success.
What’s your favorite browser for your aging Mac? What web tools do you use to keep those old boxen cranking past their prime? Let us know in the comments.
See Also:
Twitter is killing support for basic user authentication in third-party apps on Tuesday morning, the company says. Instead, Twitter will now require all third-party app developers to use OAuth for user authentication.
This is a planned move Twitter first announced in December, and the company has posted a help page on its developer site with some resources meant to ease the transition to OAuth.
The Twitter API team has been dialing down the number of requests an app can make using the basic authorization method. That number will hit zero at 8AM Pacific time Tuesday.
Some bloggers have given the event the catchy name, “OAuthcalypse” — a bit of a mouthful, but so is “user authentication protocol” — the implication being that when basic authentication is switched off, it will break old software and leave users in the dark. But since Twitter has given developers ample warning of the change, the switch will only lock out a small number of apps.
Twitter’s move mirrors a broader trend on the social web, where basic authentication is being ditched for the more secure OAuth when services and applications connect user’s accounts.
In basic authentication, a website or app will say, “Hey, do you want to share whatever you’re doing here with your friends on Twitter? Give me your Twitter username and password and I’ll hook up your accounts.” By passing along your info, you’re giving that app or website unlimited access to everything in your Twitter account. Pretty dangerous, and not secure.
In OAuth authentication, the website or app will send you to Twitter where you sign yourself in, then Twitter will tell the website or app “Yeah, they are who they say they are.” The website or app only gains the ability to do certain things with your account — post, read, reply, search — while staying locked out from the more sensitive stuff.
The biggest advantage of OAuth is you don’t have to tell your Twitter password to anyone other than Twitter. Also, OAuth connections are token-based, so once a connection is established, you can change your Twitter password without having to re-enter it into the website or app.
The only disadvantage is that old apps that haven’t updated to use OAuth will stop working this week. All of the popular ones (Seesmic, Tweetdeck, etc.) have already updated.
Twitter has been recommending developers use OAuth as an authentication method for some time.
Almost all of the biggest social services, including Facebook and Yahoo, use OAuth to connect their social services together and to let users share photos, status updates and links in multiple places.
In fact, Facebook’s new Like buttons and its Social Graph API, launched in April, use the newer OAuth 2.0 to handle user authentication.
OAuth 2.0 is a simplified version of OAuth. Twitter plans to eventually move to OAuth 2.0 for its entire platform, and Tuesday’s switch is part of that broader transition.
Twitter was originally going to move to OAuth in June, but the transition was delayed because of the increased volume of tweets around the World Cup.
Real-time search link via Dave Winer
See Also:
The good folks at Google have published a very cool multimedia showcase for what’s possible in HTML5. Using music by Arcade Fire (the 21st century hipster equivalent of ELO), filmmaker Chris Milk has made an interactive video of sorts that spans multiple browser windows.
Eliot Van Buskirk has a full write-up, including an interview with Milk, over on Wired’s Epicenter blog.
“The Wilderness Downtown,” features HTML5 native video and audio, canvas-animated birds that fly away from your mouse clicks, interactive SVG fonts, and photo panoramas from Google Maps Street View. You enter in the address of where you grew up and it pulls the images for that neighborhood. The neighborhood of my childhood home wasn’t available, so I opted for the section of Burlington, Vermont I lived in throughout college. It was creepy to see my old house in an Arcade Fire video.
Being Google-produced, the experiment works best in Google Chrome, of course. It had problems playing back properly in Firefox 4 beta.
If you have Chrome and can watch it, it really strikes a chord. It goes beyond all the HTML5 vs Flash dogma and presents what’s possible with these new technologies in a way which resonates on a level that’s more emotional and immediate than nerdy and intellectual.
So who do I talk to at Google about getting them to do one of these things for my band?
This post was updated at 2:45 PDT. The original incorrectly said it was a YouTube experiment. The site was created by the Google Chrome team, not YouTube.
See Also:
It’s been two years in the making, but Ruby on Rails 3.0 is finally here. You can grab the third generation of the popular web framework from the official website, or update via the command line with: gem install rails --version 3.0.0
Rails 3 is a major overhaul for the framework and merges the Rails and Merb frameworks to create a single lightweight code base for web applications written in Ruby.
The goal for this release was to make Ruby on Rails faster and more modular. Developers can now mix and match libraries, swapping out their favorites for Rails’ default choices.
If you’d like to know what’s new, what’s changed and why you might want to upgrade to Rails 3.0, head over to the Ruby on Rails screencast page, which has videos covering the biggest changes in the new release, as well as a number of smaller, but very useful new features.
See Also:
Google’s Chrome web browser will soon gain hardware-accelerated graphics — the latest trend for web browsers that has already shown up in early builds of Internet Explorer 9 and Firefox 4.
Hardware acceleration allows the browser to offload intensive tasks like image scaling, rendering complex text or displaying scripted animations to your PC’s graphics card. It has the benefit of freeing up the PC’s main processor and speeding up page load times.
Today’s faster graphics cards have created a new playing field for hardware acceleration. Microsoft has been trumpeting IE9’s accelerated capabilities since the first developer preview was released, and Firefox 4 will also take advantage of the new technology. Both of those browsers should be released before the end of this year.
Chrome 7, which is currently available in developer build form, is the latest browser to take advantage of hardware acceleration. Chrome’s tightly sandboxed rendering model — which prevents web pages from interacting directly with the OS — means that hardware acceleration is a little more difficult for Google than it is for IE or Firefox.
Of course it may be some time before any of these features make it to the stable release of Chrome. Chrome 5 is currently the shipping version and Chrome 6 — which features a considerably revamped interface — is currently in the beta channel. Thus far Google has not confirmed any release dates for Chrome 6, nor when Chrome 7 will move to beta status.
But If you’d like to test the early builds of Chrome with hardware acceleration, you can do so now. Grab the latest developer build of Chrome 7 and launch it from the command line with the new --enable-accelerated-compositing flag.
As with Firefox, the hardware acceleration features in Chrome are only available in the Windows version.
Hardware acceleration isn’t the only new trick up Chrome’s sleeve. The Mac version of the browser is also experimenting with something Google calls “Tab Overview” or Tabpose. Tabpose is similar to Mac OS X’s Expose; it allows you to visually pull back and see all your tabs as thumbnails and quickly switch between them.
Some early reports have compared Tabpose to Firefox 4’s new Panorama tab organizer, but Firefox’s version is considerably more sophisticated, with extra features like drag-and-drop organization and the ability to group tabs and switch between groups. If you’ve used both Panorama and Tabpose, the differences are obvious.
In fact, in the build we tested Tabpose was pretty bare bones, lacking even rendered thumbnails of the pages, let alone info bars, bookmark tools or other planned features.
Tabpose showcases another new feature in the development builds of Chrome: the ability to turn on Google Labs experiments. Just like in Gmail, the Labs experiments are interesting features created within Google that are meant more for niche tasks or hardcore geeks than the general audience. Some of them will eventually become real features, but for now they are just for testing.
So far, Tab Overview is the only experiment available for Mac, but the new about:labs page sets the stage for Chrome to add more experimental features in the future, and it sure beats launching Chrome from the terminal with loads of flags (which still works if you happen to prefer that method). Given that there are some 100 flags (or switches, as Google calls them) that you can throw at Chrome as it’s starting up, eventually the About:Labs page could become a very crowded place.
Windows users can head to About:Labs to activate a tabs-on-left experiment, which, as the name implies, shifts your tabs to a column view on the left side of your browser window, much like what Opera has offered for some time.
See Also:
The first official pre-release version of Mozilla’s mobile Firefox browser for Android devices has arrived, the company announced Friday.
Curious users with phones running Android 2.0 and above, or with Nokia N900 devices, can download and install it right now.
Codenamed Fennec, Firefox mobile is based on the same code as the big daddy desktop version of Firefox. It supports the same web standards and it even accepts add-ons. It also syncs up with your other versions of Firefox, so your history, Awesomebar searches, auto-fill form data and passwords will be the same as you move from desktop to mobile and back again throughout your day.
One of the strokes of genius design in the Fennec browser is the unique side-to-side swipe action, which brings up menus for things like tabs, bookmarks and settings. It minimizes the browser chrome and leaves more screen real estate for web pages. This new version has the sync features as well as pinch-to-zoom browsing.
We’ve seen pre-release versions of Fennec running on Android in the past, but they were patchy and bare bones. This is a real-deal alpha release. It may not be entirely stable yet, but it’s come a long way since its meager beginnings.
In a blog post, Mozilla tells us about some of the secret sauce in this release:
The main focus of this release is to increase performance and responsiveness to user actions. This is being implemented using two major technologies, “Electrolysis” and “Layers.” This Alpha release includes Electrolysis, which allows the browser interface to run in a separate process from the one rendering Web content. By doing this, Fennec is able to react much faster to user input while pages are loading or CPU intensive JavaScript is running. The upcoming beta release will start taking advantage of Layers to greatly improve performance in graphic intensive actions like scrolling, zooming, animations and video. We’re also working to optimize these actions using the hardware-accelerated graphics rendering capabilities showing up in today’s mobile devices.
And here’s a video demo:
Last year, I took an in-depth look at Fennec for Maemo (mobile Linux) on the Nokia N900. It’s pretty sweet.
See Also:
The web is littered with design galleries showcasing beautiful websites, but most such galleries focus on the site as a whole — where do you turn if you just want some inspiration for a navigation menu or a really slick sign-up form?*
We stumbled across Pattern Tap, which is a design gallery of sorts. But it breaks the showcased site down into specifics, like sites with awesome navigation menus, great looking web forms or really eye-catching typography.
In some cases, the overall designs of the featured sites are great. In other cases, not so much. But that’s bound to happen with you start breaking a design down into tiny components like great-looking code snippets or often neglected aspects of web design like sites with really good copy.
Pattern Tap also emphasizes the social stuff by offering “user sets” — if you find something you love, you can easily see who posted it to the site and what else they’ve contributed.
If you’re looking for some inspiration for that weekend web project, head to Pattern Tap and narrow your search. Just remember, Pattern Tap is a site for design inspiration, not your ticket to wholesale design theft.
* Yes, such a thing exists. Like pornography, you’ll know it when you see it.
See Also:
Every programmer wants to write better software, whether that means writing cleaner, faster code, sticking to best practices or documenting your work for long-term upkeep. But if your code doesn’t serve the needs of your users then it’s worthless, no matter how great it may be. So how do you make sure your beautiful code isn’t just an abstract work of art, but actually serves the end goal of making your users happy?
Tom Preston-Werner, the co-founder of Github, has some advice: write your README first.
That is, sit down and write out exactly what you want your software to do before you start writing any code. “Until you’ve written about your software, you have no idea what you’ll be coding,” Preston-Werner says.
Some developers may recall the days of the Waterfall model, a design and coding practice that advocated detailing all the minutiae of, well, everything. Today’s buzzword- systems like Agile Development are in many ways a deliberate attempt to move away from the complexities of the Waterfall Model.
Preston-Werner isn’t advocating a return to it. He carefully points out that the Waterfall model is overly complex, but “there must be some middle ground between reams of technical specifications and no specifications at all.”
That the middle ground is the good old README.TXT file. It’s typically much shorter than full-blown documentation driven development, but still forces you to go through an abbreviated, but very helpful part of development — making sure everyone, including you, is clear on what you’re trying to do.
Treat it like a mission statement: “[The README] document should stand on its own as a testament to your creativity and expressiveness. The README should be the single most important document in your codebase; writing it first is the proper thing to do,” writes Preston-Werner.
Wondering what constitutes a good README? Preston-Werner points to Gollum — a wiki built on top of Git — as a well-done example.
Not everyone is going to agree. There’s an interesting discussion about his post on Hacker News with a roughly fifty-fifty split. It’s a surprisingly civil discussion, free of dogma as well.
See Also:
HTML5’s canvas tag is a blank slate that allows you to manipulate all sorts things with JavaScript — everything from complex animations to interactive infographics to videos.
For those that want to trick out their images — including background images set in CSS — developer Dave Shea has released PaintbrushJS, a lightweight image processing library that can apply various visual filters to images on your page.
Behind the scenes, PaintbrushJS uses the HTML5 canvas tag to apply its effects, automatically inserting canvas tags based on class names. You can set effects and control the amount by adding attributes to your tags.
PaintbrushJS works in any modern browser — so, of course, IE 8 and below won’t see the effects.
PaintbrushJS can blur images, add a sepia tone, overlay colors or add noise. For a full list of the effects available, check out the documentation or head over to the demo page to see it in action. If you’d like to experiment with the effects, you can grab PaintbrushJS from its home on Github.
See Also:
Mozilla Labs has announced an update to its Jetpack extensions system that makes it easier for developers to write browser add-ons that more closely interact with a person’s computer desktop.
The new Jetpack SDK is version 0.7. It is quickly reaching the level of maturity required for it to become a standard feature in Firefox.
Jetpack is a new extensions framework for Mozilla’s browser designed to offer developers an easier, faster way to build browser add-ons using common web development tools like HTML, CSS and JavaScript. The Jetpack extension framework will not replace Firefox’s existing framework, which uses heavier code. But Mozilla expects to see many developers switch to the new framework once it’s complete.
While Jetpack was innovative when Mozilla first announced it, Google has since added an extension system to its Chrome browser that works on the same principles as Jetpack — using web-based tools like HTML and CSS. More recently Apple joined the fray by adding a similar extensions system to Safari 5.
Firefox’s lightweight extension framework has spent a long time in development. Jetpack graduated from Mozilla Labs (though the project is still hosted there) in March of 2010, but, while there was some speculation that Jetpack might end up in Firefox 4, that appears unlikely.
Still, the developer SDK is now at version 0.7 which brings three new APIs for developers to test. The panel API creates floating modal popups that appear on top of web content and browser chrome and persist until dismissed by users or programs. There’s also a clipboard API for interacting with the OSes clipboard and a notifications API which mimics the look of Growl to display messages to the user.
The Jetpack roadmap calls for another SDK release near the end of September and then Jetpack should hit 1.0 sometime in the fourth quarter of 2010. Once Jetpack 1.0 is stable look for it to begin working its way into Firefox.
In the mean time, if you’d like to test out Jetpack and see what the fuss is about just install the Jetpack add-on, which allows Jetpack to work within current version of Firefox. Yes, it’s a little weird, but for now Jetpack is an add-on that you use to install add-ons.
See Also:
The group that oversees patents on the H.264 video format has announced it will not charge royalties for H.264 videos that are freely broadcast on the internet.
The MPEG Licensing Association (MPEG LA) holds patents on AVC/H.264, the most widely-used video format on the web.
The group announced earlier this year that it would extend a moratorium on royalty fees for H.264 videos on the web from 2011 until the end of 2015. Thursday’s announcement extends this royalty-free period for “the entire life of [the AVC Patent Portfolio] license.”
This means that as long as H.264/AVC videos are around, publishers can post them on web pages and people can watch them in their browsers without having to pay any licensing fees.
The moratorium is only for the Internet Broadcast AVC video patent, which covers videos that are freely available via a web browser. Thursday’s announcement basically extends the status quo until the end of time — you don’t have to pay MPEG LA royalties to watch H.264 video on the web from free services now, and you won’t have to in the future.
The MPEG LA says it will continue to collect fees on AVC/H.264 video that consumers pay for. The video format is used on Blu-Ray discs and on most on-demand and paid video delivery services, such as iTunes. It will also continue to collect fees from software that ships with the coders and decoders required to play H.264 video — even software that’s distributed for free, such as web browsers.
Clearly, the MPEG LA is feeling pressure from the WebM Project, a new initiative launched in May that seeks to build a patent-free web video format. The project has created the WebM format as an alternative for H.264 and other patent-encumbered formats. WebM has already gained the support of Mozilla, Google and Opera, all of which are shipping new versions of their browsers with support built in. It has also gained the support of developers passionate about free and open web standards, especially as the web increasingly moves towards HTML5-based video experiences that work without the aid of plug-ins like Flash.
As promising as WebM’s advancements are, H.264 remains the dominant format for video on the web by a very wide margin — about two thirds of web video is H.264. By extending the royalty moratorium, the MPEG LA is likely trying to maintain that dominance on the web and encourage content providers to continue to use its format for publishing videos. By doing so, it also guarantees the group a revenue stream of licensing fees from the tools used to create, encode and watch those videos — cameras, editing software, authoring suites and web browsers.
Meanwhile, open web advocates like Mozilla are encouraging the W3C to adopt WebM as a standard for HTML5 video. Right now, the web’s governing body doesn’t require a web browser to ship with any specific video codecs.
The WebM project was spearheaded by Google after it acquired video company On2 last year, and the WebM format is based on On2’s VP8 codec. The MPEG LA has suggested that VP8 does infringe upon some of its patents, though this hasn’t been proved. Google says it has thoroughly audited the technology and found no patent complications.
If WebM does run afoul of MPEG LA’s patent portfolio in any way, it could zap any momentum the format has gained, as content providers would have no incentive to switch from H.264 to WebM. Also, any patent infringement would torpedo WebM’s chances of being adopted as a W3C standard.
Google and MPEG LA did not respond to requests to comment on this story. Mozilla declined to comment on the record.
See Also:
The new design for Microsoft’s next web browser is expected to be unveiled September 15th, but the company’s Russian press site may have inadvertently spilled the beans a bit early. A screenshot of what appears to be the new IE9 made a brief appearance on the site before being yanked down.
It wasn’t taken offline fast enough to escape the press, though. Long-time Microsoft specialist Mary Jo Foley at ZDNet grabbed a screenshot that shows a much simplified user interface for IE 9.
Leaked Photo: This may be the new look for IE 9
Internet Explorer 9 promises to be a boon for the web — the modernized rendering engine is faster and much better with emerging web standards. We’ve seen four developer previews of IE9, but thus far the focus has been on the underlying code and rendering engine. There’s been no real hint as to what the final browser interface will look like until today.
Among the notable details visible in the screenshot are a unified search and URL bar a la Google’s Chrome browser, an enlarged back button, much like what you’ll find in Firefox, and a noticeable lack of menu items in the main bar.
In short, it looks like Microsoft has decided that less is more by greatly simplifying the browser UI. This is keeping in line with something Ryan Gavin, director of platform strategy at Microsoft, said previously: “The browser is the theater, we’re not the play.” In other words expect IE9 to have a cleaner, less in-your-face design. As the Russian site stated (in translation), “Now the user sees only what you need to navigate.”
Until the official launch, only Microsoft knows what the browser looks like, and it wouldn’t comment to Foley or to anyone else about the screenshot.
See Also:
With the two most-popular web browsers ready to drop new versions within the next couple of months, you’re going to have to adjust a few twiddly bits on your website if you’re sniffing user agent strings. Of course, you should be sniffing for capabilities and not blocking browsers, but nonetheless, it’s helpful to see what the new strings look like.
Internet Explorer 9Microsoft’s new browser, due in September, has a new UA string. Details are on the IE blog, but here it is:
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Firefox 4Likewise, the new version of Firefox — version 4 is due October-ish — will have an updated UA string. Unlike IE, Firefox runs on several platforms, so there are a few:
Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/yyyymmdd Firefox/4.0.1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/yyyymmdd Firefox/4.0.1
Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/yyyymmdd Firefox/4.0.1
Easy enough to decipher. The “year month date” part is where the Gecko build id will show up. This build id will be different for each platform. Mozilla developer Daniel Witte covers the changes in depth on his blog. There’s also a more complete reference on the Moz Dev Center wiki.
Mobile browsersBoth Mozilla and Microsoft have new mobile browsers in development. Firefox Mobile was once known by the codename Fennec, so the mobile UA string is the same as desktop Firefox, but it has Fennec/fennecversion appended at the end.
The new IE mobile UA string is:
Mozilla/4.0 (compatible; MSIE 7.0; Windows Phone OS 7.0; Trident/3.1; IEMobile/7.0; <DeviceManufacturer>;<DeviceModel>)
There are more details on the Windows Phone IE blog.
All this talk of strings gives me the itch to hear a little “Foggy Mountain Breakdown.”
See Also:
