Member Sign In
Not a member?

A Wired.com user account lets you create, edit and comment on Webmonkey articles. You will also be able to contribute to the Wired How-To Wiki and comment on news stories at Wired.com.


It's fast and free.

Sign in with OpenID
Sign In
Webmonkey is a property of Wired Digital.
processing...
Join Webmonkey
Please send me occasional e-mail updates about new features and special offers from Wired/Webmonkey.
Yes No
Please send occasional e-mail offers from Wired/Webmonkey affiliated web sites and publications, and carefully selected companies.
Yes No
I understand and agree that registration on or use of this site constitutes agreement to Webmonkey's User Agreement and Privacy Policy.
Webmonkey is a property of Wired Digital.
processing...

Retrieve Sign In

Please enter your e-mail address or username below. Your username and password will be sent to the e-mail address you provided us.

or
Webmonkey is a property of Wired Digital.
processing...

Welcome to Webmonkey

A private profile page has been created for you.
As a member of Webmonkey, you can now:
  • edit articles
  • add to the code library
  • design and write a tutorial
  • comment on any Webmonkey article
Close
Webmonkey is a property of Wired Digital.

Sign In Information Sent

An e-mail has been sent to the e-mail address registered in this account.
If you cannot find it in your in-box, please check your bulk or junk folders.
Sign In
Webmonkey is a property of Wired Digital.

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

By Michael Calore November 17th, 2009 Categories: Multimedia, Web Basics

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:


Post Comment | Comments | Permalink

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

By Michael Calore November 12th, 2009 Categories: Servers, Web Basics

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:


Post Comment | Comments | Permalink

Review: Typekit Delivers Custom Web Fonts to the Masses

By Scott Gilbertson November 12th, 2009 Categories: Software & Tools, Visual Design, Web Basics

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:


Post Comment | Comments | Permalink

How to Handle Mobile Site Redirects

By Scott Gilbertson November 10th, 2009 Categories: Mobile, Web Basics

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.


Post Comment | Comments | Permalink

Tim Berners-Lee Sees Promise, Challenges in HTML5

By Michael Calore November 4th, 2009 Categories: Web Basics


SANTA CLARA, California — The man credited with founding the world wide web is both excited and cautious about its future.

Sir Tim Berners-Lee, the British physicist who first designed the way web servers deliver pages to web browsers nearly 19 years ago, sees great promise in HTML5, the much-anticipated rewrite of the language used to build web pages.

“I think (HTML5) is great,” he said at the Worldwide Web Consortium’s (W3C) annual member gathering, taking place here this week.

HTML5 is a mixture of several different technologies that allow content creators to do more with web pages. It defines rules for presenting video, audio, mathematical equations, complex layouts, 2-D animations and non-standard typefaces. Each bit of technology has its own working group within the W3C chartered with developing that one component.

“We’ve had the pieces for a while,” he says. “Seeing all these things finally coming together is exciting, and it multiplies the power of each one,” Berners-Lee says.

HTML5 also enhances the way browsers can store and process data, which has led to the creation of more complex and rich web applications that run in the browser like Gmail, Facebook and apps that allow real-time data sharing, like Google Wave.

“Yes, this is a markup language for web pages,” he says, “but the really big shift that’s happening here — and, you could argue, what’s actually driving the fancy features — is the shift to the web becoming a client-side computing platform.”

The HTML5 specification is close to completion. The most recent releases of browsers like Firefox, Chrome, Safari and Opera all support most of the technologies being rolled in to HTML5. Microsoft’s Internet Explorer supports fewer of HTML5’s advancements, but it’s catching up. HTML5 is expected to become an official recommendation by late 2010 or 2011.

Now that the web has been elevated to a more powerful computing platform by HTML5, Berners-Lee says it has also given rise to complicated security issues.

“You got a piece of code from site A, and you’re person B running a browser you got from company C, and that code wants to access data stored with company E for the purposes of printing it on a printer owned by company D — How do you build that so that it’s not susceptible to all kinds of nasty attacks?”

“The technology is very exciting, but there’s actually a lot of work to do in these corridors to make it work on the real web in a secure way.”

See Also:


Post Comment | Comments | Permalink

Same as it Ever Was: The History of HTML is a Conversation, Not a Spec

By Scott Gilbertson November 3rd, 2009 Categories: Programming, Web Basics

Developer Mark Pilgrim has posted a fascinating look at how the HTML img tag came into existence. The history Pilgrim digs up — mailing list conversations between the creators of the first web browsers like Marc Andreessen and the webs early pioneers like Tim Berners-Lee — show that far from being a carefully planned specification, the lingua franca of the web evolved a bit like the early universe — out of a murky chaos.

That from the chaos we got a workable — some would argue good — solution for creating the web is proof on some level that conversations and not abstracts, proposals and design by committee are the key to HTML’s success.

As Pilgrim writes:

HTML has always been a conversation between browser makers, authors, standards wonks, and other people who just showed up and liked to talk about angle brackets. Most of the successful versions of HTML have been “retro-specs,” catching up to the world while simultaneously trying to nudge it in the right direction.

You might be wondering, why did img succeed where other proposals, like an include or an icon tag failed? The answer is simple, because Marc Andreessen shipped code — Netscape Navigator — while those backing the other proposals, for most part, did not.

Of course that doesn’t mean that just shipping code is always good plan. Shipping code before a standard doesn’t necessarily produce the best solutions, as Pilgrim says. Or, put another way by a commentator on Pilgrim’s post, “shipping doesn’t mean you win, but not shipping means you lose.”

From those who shipped without the official blessing of a standard, we’ve come to have an img tag, the basis for AJAX, all of the HTML5 tools available in browsers today and much more.

Critics of HTML’s disorganized evolution will be quick to note that we’ve also come to have the blink tag, cross-browser rendering issues and other pains of web development.

Indeed we’re not suggesting that shipping features without at least engaging in the conversation is a good idea, but, when it comes to the future of HTML, if browser makers don’t ship HTML5 features before the standard is official we’ll be waiting until 2022 to use the new tools.

But while the future of HTML5 might be moving at a rather slow and convoluted pace. Pilgrim’s post is reminder that HTML has always progressed that way.

Perhaps the truly remarkable part is that, for all its flaws and convoluted evolution the core tech behind the web remains essentially the same now as it was then. “HTML is an unbroken line… a twisted, knotted, snarled line, to be sure… but still… Here we are, in 2009, and web pages from 1990 still render in modern browsers.”

See Also:


Post Comment | Comments | Permalink

Typotheque’s Web Fonts Rock, But Old Machines Can’t Learn New Type Tricks

By Scott Gilbertson October 21st, 2009 Categories: Visual Design, Web Basics

Font foundry Typotheque has introduced a new web font system that gives web authors a new set of font embedding options for their website designs. However, as cool as Typotheque’s new tools are, they can’t overcome some larger problems with the @font-face rule in CSS and the state of type on the web in general.

Typotheque, a Netherlands-based font foundry, recently unveiled a set of web licenses and an easy cut-and-paste solution for web developers looking to take advantage of the CSS3 @font-face support in modern web browsers. The solution is particular nice because it doesn’t require the overhead of loading JavaScript libraries like some other proposed solutions we’ve covered, such as TypeKit. Typotheque’s system requires only a CSS file and a simple @font-face stylesheet rule.

Also working in Typotheque’s favor is a web-only license, which is issued and controlled by the company, that’s considerably cheaper than licensing the actual font files.

Unfortunately, in the real world, @font-face’s results aren’t always what you expect. As BoingBoing recently discovered when it tried a redesign using @font-face to embed custom fonts, CSS3’s @font-face rule doesn’t always render correctly on older PCs.

While it’s nice to see font foundries like Typotheque embracing both web licenses and simple embedding tools, the results are decidedly mixed. So long as your site’s users are running a modern OS like Mac OS X, Windows Vista or most Linux distros; and they have modern browsers like Firefox or most of WebKit-based browsers, the @font-face and Typotheque’s new embedding system work wonderfully. The only minor issue is a quick flash of unstyled text appearing when the page loads in Firefox, but that can be addressed with a simple JavaScript workaround.

However, for those users still using Windows XP, embedded fonts are not, by default, anti-aliased and results in jagged, ugly fonts that aren’t going to make you or your visitors happy.

To see how things looked in various browsers, we loaded Typotheque’s Fedra Sans font up in a test page at 72 pixels and then looked at it in various browser/OS combos:

Fedra Sans in various browsers. Click the image for a larger view.

As the image above demonstrates, the results are just fine in Firefox on Mac OS X and Linux, acceptable in IE7 in Windows XP and downright ugly in IE6 on XP. Given the considerable percentage of web users still browsing with IE6 in Windows XP, @font-face clearly isn’t going to work for every site.

Still, for those that just want to experiment with @font-face, Typotheque’s new system is the simplest, cheapest system we’ve tested. There’s even a free month-long trial available for testing purposes. For more details, head over to the Typotheque website.

See Also:


Post Comment | Comments | Permalink

Pack Up Your Data and Leave Whenever You Want, It’s the New Rule of the Cloud

By Michael Calore October 16th, 2009 Categories: Software & Tools, Web Basics

There’s a certain level of trust that goes along with using a cloud-based web application. You upload your photos and your documents so you can access them everywhere, but you also trust that you’ll be able to pull those photos and documents down any time you want.

It sounds like a perfectly reasonable assumption, but many web-based services make it difficult for you to export your data. Worse, they’ll charge you a fee for the privilege. Some offer APIs — a bonus if you’re technically astute, but a solution that leaves the average user short on options.

To prevent such headaches, Google recently launched the Data Liberation Front, an initiative within the company to ensure every one of its products has a clear, easy option for users to export their data in bulk and take their business elsewhere.

Leading this project is Brian Fitzpatrick, an engineering manager at Google. Brian and his team launched an educational website at dataliberation.org in September where you can track their progress and find instructions for exporting your Blogger blog, your Picasa photos, your Gmail inbox, or whatever service you want to bail on.

It may seem odd as business strategies go, but as a practice, data portability and the trust it engenders are key to fueling the growth of the open web. In the following interview, Brian explains why this concept is especially important now, as more of us are sharing our data not only with Google, but with Facebook, Yahoo, Microsoft and other major players. He also hints at some new export features coming to popular Google products — like the ability to export all of your Google Docs files in a single, downloadable Zip archive.
Webmonkey: What led to the creation of this initiative within Google?

Brian Fitzpatrick: Even before I joined Google, I heard (CEO) Eric Schmidt speak. And one of the things I heard him say time and time again is, “we don’t lock our users in.” If they wish to leave, they are free to do so, and they can take their data with them. After I started, the one thing I kept hearing over and over again from the team was that we focus on our users first, and everything else follows that principle.

In talking to other engineers here, I realized that we don’t lock our users in. But while the door isn’t ever locked, in some cases, it could use a little bit of grease. It’s a little stuck.

We asked various product people if they’ve looked into doing an easy bulk-export type of thing where users can take out their data — and put it in — en masse. The typical response was, “Oh, it’s been on our roadmap for four or five years, it’s just de-prioritized because we have to work on these things our users are demanding.” So, it just wasn’t getting done.

We decided to start a small team of engineers to do just that — go around to our various products and help build those systems.

WM: So it wasn’t a question of evangelizing data liberation since the product managers were already sold on it, but more of a mission to go install the plumbing?

BF: Yeah, but we’re also trying to raise awareness in general. Most engineers don’t typically think about data liberation. They’re more involved in launching products. But I think it’s important because it’s a way for our users to trust us more.

WM: How much do you see the Data Liberation project as good policy for Google internally versus good policy for the web in general?

BF: I would love nothing more for other companies to copy-cat us on this. It’s good policy because we’re in a different world than we were in ten years ago.

If you wanted a piece of software ten years ago, you’d go to the store, buy a box and take it home. If you wanted to try another piece of software, you’d have to go back to the store, buy another floppy and do the whole process over again. There’s a huge barrier to trying different things out.

Today, if you want to try something else out, you just type another URL in your web browser. We want people to try our software, and if we’re going to encourage people to put data in the cloud and use more cloud-based apps, it’s important to show that it should be easy to get that data out as well. I want more people to think about this. It’s an important thing, and most people don’t think “I want to get my data out,” until it’s too late.

To be very clear: It’s not that Google is just an altruistic, lovable, huggable company. I think we’re a good company, but we get a benefit from this. We benefit from the work we do with open web standards, open-source and data liberation. But if you’re using a Google product now and you decide to go somewhere else, the easier we make it to leave and take your data with you, the more likely you are to come back and use something we come out with in the future.

There’s also the “rising tide floats all boats” analogy — the more we contribute to the success of the internet, the more we contribute to our own success since we’re such a big player.

WM: So, are you taking steps to future proof your products as well? Like in the case of Google Docs, or in the case of feed-based data, are you making sure what’s supported today will be supported in 10 years?

BF: We’re focusing on open formats wherever possible. So, you’ll see things coming out in open-documented Atom feeds, XML feeds.

In the case of Docs in particular, there’s something great we’re working on at the moment. Right now you can get your docs out one at a time. We’re working on a way for you to be able to select multiple docs at once, choose whatever format you’d like — ODF or MS Word or whatever — and our server will convert everything for you, create a Zip file and stream it down to you. (Brian says this feature will launch within the next couple of months).

WM: That’s great for backups.

This is interesting, too. Last winter, we launched Blogger liberation. When you log in to Blogger, there are options for “import blog” and “export blog.” It’s a nice, user-friendly experience, an easy download. We noticed some people were exporting their blog every other day — they were just creating a back up. We have several copies of their blog across several data centers, but these people felt more comfortable having their own copy on their own computers.

WM: There are other Google tools that run back ups automatically, like Picasa, where you can sync your photo library in the desktop app to your album on the web, right?

BF: Right, and we’ve been doing some additional work with Picasa because we’ve recognized we can do a better job with syncing things like your photos’ metadata.

WM: That’s interesting because data portability on the social web isn’t only about your data, it’s also largely about your metadata — your tags in Picasa and who they’re attached to, who you follow in Blogger and your ratings and comments for their posts. Are those bits of metadata being taken into account?

BF: It’s really hard to keep up with the features of individual services and the smaller bits, since they’re all so different. I don’t know if Blogger is exporting follow data. I know in Reader, you can get a list of the blogs you follow if you export your reading list to an OPML file, but you don’t get a list of the posts you’ve starred. There’s some education needed there, and some things that merit more attention. I don’t think we have the answer for all that yet.

WM: It also raises the question of interoperability among social sites. There are emerging standards that don’t yet have broad support but are gaining steam — things like Portable Contacts, OAuth, Activity Streams. How much attention is Google paying to making sure its import and export systems play well with smaller social sites who are adopting these new open standards? Versus, say, the attention being paid to bulk data export?

BF: I think that’s more relevant to the teams working on products that touch on those standards. Our team currently has a pretty sharp focus on data you create in our apps or that you’ve imported into our apps — making it so you can get that out. As far as interoperability, we’re obviously big supporters, and anything we can do to make it any easier to build on the open web, we’re doing.

For example, on OpenSocial we make it easy for developers to write apps that can be shared among different social networks. Google has also done work with OAuth. But the Data Liberation team is primarily concerned with helping you get your data in and out. It’s sort of step one of n steps.

WM: OK, so that’s your first order of business. Is there a list of tasks related to data liberation you’ve lined up to accomplish in your downtime?

BF: One thing we’re studying is the fact that your hard drive capacity is expanding way faster than your network capacity. Your hard drive capacity increases by an order of magnitude every four years. So that means by 2017, you’ll have a multi-terabyte iPod in your pocket.

Network capacity has only increased a little bit by comparison. Ten or so years ago, you had dial-up, or if you were super-advanced, you had DSL. The network speeds we have now are not a lot faster when paired with the growth of hard drive capacity. So, there are a lot of difficulties when dealing with larger data sets. How am I going to get 20 terabytes from Chicago to Mountain View quickly? I’m going to put it on hard drives and FedEx it.

We’re brainstorming about making it easier for people to move that size of data set around, or to gain access to that data.

See Also:


Post Comment | Comments | Permalink

Debunking the Myth of the Page Fold in Web Design

By Scott Gilbertson October 16th, 2009 Categories: Visual Design, Web Basics

Web standards give developers a way to build websites so that anyone can access them. Unfortunately web standards don’t cover more difficult problems, like how to make sure people can find what they want on your site.

For that developers need to turn to common design patterns, but unfortunately many design patterns are outdated. For example it was long held as a common belief that most users would not scroll down the page, so your content needed to be “above the fold” if it was to be noticed — a term leftover from newspapers where the primarily headlines are above the fold, so those walking by a newsstand would see the important stuff even though the paper was folded in half. The web equivalent of above the fold is the area you can see without scrolling.

However, that conventional wisdom is not nearly as true today as it was back when Jakob Nielsen encouraged developers to keep everything above the fold. Of course Nielsen’s own site has plenty of content below the fold — after all, the web isn’t a newspaper.

CXPartners, a U.K.-based design agency, recently posted the results of a study involving some 800 user testing sessions, and on only 3 occasions did the page fold stymie users.

Part of the reason for the shift can be seen in CXPartners’ hotspot study, which used eye tracking software to reveal that users nearly always spend some time glancing at the scrollbar to judge page size. Now, that doesn’t mean you bury your best content below the fold, but it does mean that you shouldn’t worry too much about things that simply don’t fit above the fold.

But one surprising thing thing comes out of the study is that having less above the fold actually encouraged exploration below the fold. According to CXPartners’s study, the judicious use of white space and visual clues that lead the eye down the page significantly increase the chances a user will scroll.

The key is to make sure there are no barriers that would make your users think there is no “below the fold” content. One example cited in the study had a large horizontal bar running across the page, which acted as a barrier — it looked like the bottom of the page even though it wasn’t. Eliminating the horizontal bar encourage users to scroll the page.

Although it might run against your aesthetics as a designer, clipped text and cut off images are also high on the list of things that encourage scrolling.

Here’s CXPartners’ suggestions based on their user testing research:

  1. Less is more — don’t be tempted to cram everything above the fold. Good use of whitespace and imagery encourages exploration.
  2. Stark, horizontal lines discourage scrolling — this doesn’t mean stop using horizontal full width elements. Have a small amount of content just visible, poking up above the fold to encourage scrolling.
  3. Avoid the use of in-page scroll bars — the browser scrollbar is an indicator of the amount of content on the page. iFrames and other elements with scroll bars in the page can break this convention and may lead to content not being seen.

So what would Jakob Nielsen think? Well, actually he seems to have weighed in in the comments, suggesting that what CXPartners discovered is old news. That may be true for Nielsen, but the CXPartners’ write up is much more readable than the technical, jargon-filled document Nielsen points to, and even if “below the fold” is a myth, it’s a well established one and there’s no harm in debunking it again.

Be sure to check out the comments on the CXPartners site for some helpful design tips and techniques from readers, as well as some thoughtful criticisms of the study.

Photo: Matthew Bradley/Flickr, CC

See Also:


Post Comment | Comments | Permalink

Search Engine Optimization Is Part of Good Web Design

By Scott Gilbertson October 14th, 2009 Categories: Programming, Web Basics

One significant aspect of web design that we at Webmonkey often ignore is so-called “search engine optimization,” or the art of making sure Google and its brethren can find, crawl and index your websites.

Part of the reason we typically ignore SEO is that it’s an industry full of what Derek Powazek, who has worked at both Google’s Blogger and Technorati, and is a former Webmonkey contributor, recently called “scammers.” Indeed, black hat SEO outfits are responsible for creating billions of bad results for users — highly ranked sites that actually offer little more than advertisements and spam.

It’s too bad the SEO industry ended up this way, but with the rise of Google and the importance of PageRank, as Powazek puts it, “like the goat sacrificers and snake oil salesmen before them, a new breed of con man was born, the Search Engine Optimizer.”

Naturally Powazek’s rant against SEO raised the ire of folks like Danny Sullivan over at Search Engine Land — people that focus on optimizing sites for Google without resorting to black hat techniques.

Leaving the ranting aspects of Powazek’s post aside, you’ll find that he and Sullivan actually agree. They just use different terms to describe what they’re talking about. The real message of Powazek’s rant is not that SEO is wrong, but that you shouldn’t have to pay extra to get it.

SEO is actually just a subset of good web design. Powazek writes:

Good SEO techniques are just good web development techniques. They should be obvious to anyone who makes websites for a living. If they’re not obvious to you, and you make websites, you need to get informed. If you���re a client, make sure you hire an informed web develeper.

Powazek is actually echoing Google’s own advice, which says: “if you’re thinking about hiring an SEO, the earlier the better… that way, you and your SEO can ensure that your site is designed to be search engine-friendly from the bottom up.”

In other words, if you’re a web developer and SEO isn’t part of your toolset you’re doing your customers and yourself a disfavor.

So what if you aren’t familiar with the intricacies of optimising your site for search engine spiders? Well, perhaps the best place to start is with Google’s own recommendations for webmasters and there’s also the Webmaster Central Blog.

For the nostalgic, we also recommend checking out Powazek’s decade-plus missive on why he loves HTML tables right here on this site.


Post Comment | Comments | Permalink
 
Subscribe now

Special Offer For Webmonkey Users

WIRED magazine:
The first word on how technology is changing our world.

Subscribe for just $10 a year