Twitter has announced a new feature that will give users the ability to send their location with each tweet.

The new geotagging API tools are available only through the Twitter API, and are not part of Twitter.com just yet. So, if you’d like to post geodata with your tweets, you’ll need to use a third-party application that supports the new features. Expect updates to the most forward-looking clients soon.

The geodata tools are also opt-in, meaning that you’ll have to head to your account settings and check “enable geotagging” before any application is allowed to send geodata with your tweets. If broadcasting your location strikes you as an invitation to an Orwellian nightmare, just ignore the new settings.

Judging by the way Twitter has set up the API, the geotagging tools are intended mainly for mobile applications running on platforms like the iPhone or Android, both of which have GPS or similar sensors for detecting location and can offer geodata to applications. Approve the Twitter app of your choice to access your location and it can then send the geotags along to Twitter.

In addition to the obvious — the ability to search for nearby tweets — the added geo information opens up a whole new realm of Twitter mashups — travel guides, local music searches and most likely quite a few things no one has thought of yet.

It also serves as both a boon and a challenge to the various location-based games and services that have sprung up along Twitter’s coral reef. Services like Foursquare, Loopt and Gowalla, which exist as separate apps, but incorporate Twitter for passing status messages, will have the ability to geotag those status messages. Likewise, you could run a simple Twitter search for messages geotagged with the location of the restaurant you’re currently sitting in and get recommendations from other Twitter users about which menu items to try.

Of course given the opt-in nature of geotags (a good decision on Twitter’s part), searches looking at only geotagged tweets will likely be a minority sampling of what’s actually happening on Twitter.

Developers interested in using the new API in applications and mashups should check out the new documentation.

See Also:

• Flickr Makes it Simple to Post Photos on Twitter
• FriendFeed Adds Simple Logins for Twitter Users
• New Twitter Tools Rival Ease of Facebook Connect

Serious work has begun on Internet Explorer 9, the next revision of Microsoft’s flagship web browser.

That sounds like good news, right? After all, IE8 has its moments, but it isn’t exactly a cutting-edge browser. Certainly, any improvement would seem welcome.

Yet, judging by the reaction from the web-development community on Microsoft’s IEBlog, you’d think Microsoft just announced the release of a major virus.

To understand why web developers — and even ordinary users — aren’t particularly thrilled with this early preview of IE9, we need to start by taking a look at IE8’s shortcomings:

• Speed — This is all that matters for the average user, and all of IE8’s competitors are faster, something even Microsoft doesn’t deny.
• Emerging standards — Firefox, Safari, Chrome and Opera have all begun implementing support for HTML5 and CSS 3, while IE8 has not. As more and more web apps take advantage of HTML5 tools, IE is in danger of becoming a second-class citizen on the web.
• Web apps — In addition to lagging in overall page-rendering speed, IE8 is well behind the competition when it comes to JavaScript performance. Though Microsoft has been quick to challenge the relevance of JavaScript benchmarks, regular users of Gmail, Facebook and other JavaScript-heavy web apps do not.

Now let’s take a look at what improvements Microsoft is planning to make in IE9.

Speed

The first item of business on the IEBlog post is IE9’s speed improvements. There are two basic elements, page-rendering times (including JavaScript improvements) and a proposed hardware-acceleration layer that hands off complex rendering tasks to the graphics card.

After a rather lengthy treatise on why JavaScript benchmarks aren’t really an accurate measure of page-load speed, Microsoft goes on to tout IE9’s improved JavaScript performance. Microsoft offers a graph of IE9 running the SunSpider JavaScript test, a common way of measuring JavaScript performance.

The results are split over two graphs, one with IE8 versus the browsers its competitors are currently shipping,�� and the other charting IE9 against other experimental builds.

However, what’s really interesting is combining the two graphs. Doing so shows IE9’s JavaScript speed is roughly on par with Firefox 3.5, but still much slower than Safari 4 and Chrome 3.

Microsoft’s chart showing JavaScript rendering speeds in various browsers. Shorter bars are better.

Why advertise the fact the latest and greatest builds of Internet Explorer still can’t beat the actual shipping versions of the competition? Frankly, we’re not sure. But we assume Microsoft plans to continue improving IE9 before it finally ships. Unfortunately for IE9, we assume Mozilla, Apple and Google plan to do the same with their experimental builds.

And that cuts to heart of why developers and anyone with an interest in the using the web of the future today has long since lost faith in Internet Explorer: The competition continues to deliver improvements at a pace that far outstrips Internet Explorer.

Standards and HTML5

While speed is probably the most obvious and important feature of a web browser, the faster development time of IE’s competitors also means they are able to add new, experimental features long before IE.

That’s why Firefox, Safari, Opera and Chrome already have support for large portions of HTML5 and CSS 3, while IE 8 has next to none.

IE8 saw Microsoft catching up and finally getting the basics of HTML 4.x and CSS 2.1 right (we’ll overlook IE8’s lack of support for CSS pseudo element syntax), but unfortunately for IE8, the web is already moving on to HTML5 and CSS 3.

The good news is that IE9 will finally support most of CSS 3. There’s a screenshot on the IEBlog that appears to show IE9 rendering 41 out of 43 selectors in the CSS 3 selector test.

That’s great news for web developers, because it means less work building standards-based websites — provided IE9 delivers on this front.

However, when it comes to HTML5 support, IE9 appears decidedly less progressive. Microsoft appears to be sticking to its rather hard line on HTML5 — it’s not an official recommendation, so we’re not going to build support for it until it is.

While Microsoft is technically right about HTML5 (it is expected to become a recommendation in about a year), the truth is the web moves at the speed of the people actually building and using it, not the speed of recommendations from the W3C. At this rate, the lack of HTML5 support is looking more and more like Internet Explorer’s death knell.

The IEBlog does mention the HTML5 storage API, which was included in IE8, but ignores other elements already enjoying support in IE’s competition. For example, there’s no mention of HTML5’s audio, video or canvas tags, nor is there any discussion of the Geolocation API, Web Workers or SVG tools.

The thing to remember is that HTML5 support isn’t just a question of making web developers happy. If Microsoft wants IE to continue to be relevant to the future of the web, it’s going to have to step up its HTML5 support. The lack of support for the emerging standard gives Google a great way to attack IE — simply build sites that don’t work in IE and offer a link to download Chrome Frame.

That’s exactly what happens if you try logging into Google Wave with IE8. Clearly, Google and others are planning to use HTML5 with or without IE at the party. The short story, from what Microsoft has revealed thus far, is that IE9’s standards support will be catching up to where Firefox, Safari and Opera were two or three years ago.

Other Features

The IEBlog also touts the fact that IE9 will use Windows’ DirectX APIs to move graphics and text rendering from the CPU to the graphics card using Direct2D and DirectWrite. That means that IE 9 should be faster at rendering pages, particularly on PCs that have more-powerful graphics cards.

Of course, once again, the competition is already moving in the same direction. In most cases, the other browsers are using WebGL, which handles not just 2-D rendering, but also 3-D as well.

The IEBlog also touts IE9’s improved text-handling with sub-pixel positioning and much better anti-aliasing. Again, nice to see IE9 catching up with the competition.

Conclusion

Microsoft needs to hit a home run with IE9, or the IE franchise is going to go the way of Geocities. Unfortunately, based on what Microsoft has shown so far, IE9 looks to be a base hit at best. Certainly IE 9 will be good news on several fronts, notably the speed improvements and the increased CSS 3 support. But once again IE is catching up, not leading the way as it once did.

The typical rebuttal to IE’s shortcomings is that it doesn’t matter — IE still maintains a dominant market share, and will continue to do so, because it ships alongside Windows on new computers. It’s true that IE controls a majority share of the web. Microsoft got that majority because it bested the competition. Keep in mind that IE’s majority share used to be much, much larger, and it continues to slip with every passing month.

While we’re sure there are plenty of people who would love to dance on IE’s grave, the truth is that competition is a good thing. We want to see Microsoft make a better browser. Sadly, thus far, IE9 doesn’t look very competitive.

See Also:

• A Brave New Web Will Be Here Soon, But Browsers Must Improve
• Google Throws Its Weight Behind HTML 5
• Mozilla Pushes the Web Forward With Firefox 3.5

“What if your browser was your operating system?”

That’s the question Google is hoping to answer with Chrome OS, the open source operating system centered entirely around its Chrome browser. All your apps — e-mail, communications, docs, photo management — are delivered through the web browser, which sits on a lightweight Linux-powered desktop.

The company debuted Chrome OS Thursday morning during a press event at its headquarters in Mountain View, California. Wired.com’s Dylan Tweney was there to bring us all the details, and you can expect a post from him Thursday morning [Update: Dylan’s post is up on Gadget Lab].

In the meantime, Google has posted a video (below) making an argument for why you’d want an operating system that funnels all of your productivity tasks through a browser: “It just gives you the internet, which is all most of us use our computers for now, anyways.”

And here’s a demonstration of the user interface. It’s striking — the browser is all there is to it.

Read the overview on the Google Blog. Also, be sure to check out some of the initial design specs, including the OS’s ability to auto-update silently and daily.

See Also:

• Five Questions About Google Chrome OS
• Google Takes On IE, Firefox With Chrome Web Browser
• Google Shows Off Chrome Themes With Cool YouTube Hack

Mozilla has released a third beta for Firefox 3.6 with more than 90 bugfixes since beta 2, which was released just last week. If you’d like to take beta 3 for a spin, head over to the Mozilla downloads page.

Although beta 3 doesn’t contain any significant new features, it does have some welcome bug fixes and is considerably more stable than the previous betas. There is one feature not found in previous releases — add-ons can now access Firefox’s built-in geo-location features.

Unfortunately for Windows 7 users, much of the Windows 7 integration — like Aero tab previews and jump lists — has been removed. It remains to be seen whether or not those features will make it in the final release or will be postponed for Firefox 3.7.

The good news is that more than half of all add-ons now work with Firefox 3.6, including the recently released Weave update and other popular add-ons like Ad Block Plus and Firebug.

One big change on Firefox’s backend being introduced in beta 3 is a new restriction on how third-party add-ons integrate with Firefox. The Firefox components directory is now off limits to third-party tools. According to the Mozilla Developer Blog, “there are no special abilities that come from [accessing the components directory].”

The move is mainly designed to make Firefox more stable by preventing add-ons from accessing lower level tools that could cause crashes.

As the Mozilla Links blog points out, current Firefox 3.6 nightly builds are labeled as “preb4,” which might mean we’ll see a fourth beta before Firefox 3.6 arrives in final form. If Mozilla continues to crank out new betas every week, look for beta 4 around Thanksgiving with the final release arriving during December.

See Also:

• Mozilla Paves the Way for Firefox 3.6 With Second Beta Release
• Firefox 3.6 Beta 1 Arrives: More Speed, Better Video, New Tab Tricks
• Mozilla Throws Its Weight Behind Improving Web Type, Adopts WOFF for Firefox
• Mozilla Readies Windows 7 Support for Firefox 3.6

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:

• Tim Berners-Lee Sees Promise, Challenges in HTML5
• W3C Drops Audio and Video Codec Requirements From HTML 5
• Adobe Fights Off HTML5 Threat With New Flash Player 10.1
• Mozilla Pushes the Web Forward With Firefox 3.5

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:

• Update Moves Weave Closer to a Starring Role in Firefox
• Mozilla Updates Weave for Faster, More Reliable Syncing
• Weave Update for Firefox Syncs Your Web Identity
• Mozilla’s Weave Ties Your Desktop and Your Personal Web Together

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:

• Adobe Fights Off HTML5 Threat With New Flash Player 10.1
• Adobe Debuts New Flash Tools for Building and Tracking Social Apps
• Google Throws Its Weight Behind HTML 5
• How HTML 5 Is Already Changing the Web

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:

• Django Project Looks Toward the Future With Django 1.2
• Making Open Source Software More “Humane”
• Flush With Choices, Developers Still Dig Django the Most

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:

• New Google Plug-in Embeds Chrome Inside Internet Explorer
• Mozilla VP on Why Google Chrome Frame Is a Bad Idea
• Chrome Hits 3.0, Mac Version Due Later This Year
• Mac Chrome Starting to Look Like a Real Browser

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:

• Typekit Hopes to Become the YouTube of Fonts
• Boing Boing���s Redesign Uncovers the Dark Side of Web Fonts
• Typotheque���s Web Fonts Rock, But Old Machines Can���t Learn New Type Tricks
• The Future of Web Fonts Looking Brighter