Design Charrette 2006

Yahoo! Developer Network Technical Evangelist Mattt Thompson put up a long post today on the YDN blog laying out his vision for the future of the web and what Web 3.0 might look like. Says Thompson, Web 3.0 will be all about the ubiquity of desktop/offline access for rich Internet applications.

Thompson framed his case for Web 3.0 by defining Web 2.0 — or at least the technology that made it possible. According to Thompson, regardless of the specifics of the Web 2.0 definition that you subscribe to, most of what we think of as the current generation of the web was made possible by Ajax.

“Asynchronous communication between the browser and servers (a la Ajax) provided the latency needed to recreate the look and feel of a regular desktop application,” he writes. “Not to argue the finer points in this minefield of buzzwords and strong opinions, but the emergence of rich user interaction changed everything. It got people to rethink what a website could be. It was a newer, shinier series of tubes.”

Thompson thinks that other new technologies could have a similarly substantial impact on the web and “make Web 2.0 no more than a distant memory.”

His leading candidates right now are Gears — the open source offline sync API from Google — and Yahoo! BrowserPlus, a similar offline API for web developers that takes a different, more modular approach than Google’s Gears.

Thompson says that even though many bloggers and developers have described Gears and BrowserPlus as competitors, they’re not necessarily so. “With their respective design goals in mind, it doesn’t make sense to look at Gears and BrowserPlus as competitors. Sure, both have an intersecting feature set, including desktop integration, and automatic software updates, but that’s where the similarities end,” he says.

Gears is a back end technology, says Thompson, while BrowserPlus has potential to be used for front end tasks. Together, they reveal his vision for Web 3.0: an Internet in which applications move seamlessly from between online and offline environments, from the web to the desktop, and where that is as expected as all the Ajaxy-bits are today.

“If you think back to how Ajax changed the way people could interact with websites, much of it is completely transparent. For instance, deleting items in a list with real-time feedback is so pervasive that it became an expected behavior,” writes Thompson, who says that he can envision a web where the type of things enabled by Gears and BrowserPlus become “equally pervasive, yet [remain] invisible to the normal user.”

If RIAs are the future of the web — or even the future of computing — then offline/desktop access is supremely important. The browser is not a very good operating system, so being able to run applications on the desktop is an important transitional step toward Thompson’s vision of Web 3.0 and the future of thin client computing.

A couple of days ago, when Cuil launched to the public there were a lot of bloggers and media outlets talking about the new search engine excitedly as a Google killer. Given the grandiose way in which the company described itself — taking shots at Google’s “superficial popularity metrics” and calling itself three times as big — those comparisons were probably warranted. But after trying the service, we all realized that, at least for now, they’re unfounded.

With Cuil search results so consistently worse than Google’s some bloggers began to wonder why they launched with such a flash. Surely they knew their technology wasn’t yet good enough to truly compete with Google, right? “I think it’s a play for Microsoft money,” wrote Robert Scoble. And he could be write. Powerset, another over-hyped search engine that failed to impress at launch cashed out early to Microsoft, who is sitting on piles of cash with the Yahoo! deal off.

But then again, you don’t have to kill Google to make a killing at search. Don Dodge did some back of the envelope math last year and found that for Google, every 1% of the search market is worth about 0 million in revenue and the market values each percentage point at -3 billion in market cap.

“VCs are investing big bucks trying to find the next Google,” he concluded. “New comers like Powerset and Hakia would be quite happy with 2 or 3 percent market share although they have aspirations of much bigger things. Do the math…it is staggering.”

If every one percent of the market is worth 0 million in yearly revenue (or perhaps a bit less since the smaller your share of the market the harder it seems to be to sell ads against your search results), a few percentage points could be a huge deal for some of these smaller, independent search entries. “Even the small search engine players can generate huge revenues and are extremely valuable. Search is not a winner take all game,” said Dodge in the comments on his May 2007 post.

And of course, Cuil or any other search competitor doesn’t need to steal those percentage points from Google — they can take them from Ask, or AOL, or Yahoo!, or Microsoft, all of whom might be easier to compete with on technology at the consumer level than Google.

Last August Amazon launched their Flexible Payment System that allowed startups to take money using Amazon’s back end. At the time it was hailed as a PayPal competitor, and on some levels, it was — it was a merchant account replacement that could be co-branded and allow developers to take payments from their web site. However, it was far from a simple payment product. When it launched, Amazon’s Jeff Barr warned that using FPS wasn’t for the faint of heart. “Designed specifically for developers, the ‘F’ in FPS shouldn’t be taken lightly,” he said. “This is a very rich service — the API document is over 250 pages long.”

Today, Amazon expanded their payments offerings with the launch of Simple Pay and Checkout. Both are available through Amazon’s Payments page and the new services are aimed at small businesses, but don’t require nearly as much developer knowledge.

Amazon published a comparison chart of their three business offerings. The main difference between FPS, Checkout and Simple Pay is that FPS requires “advanced programming skills using APIs” to get implemented, while the others require just HTML or scripting knowledge. There are further differences between Simple Pay and Checkout as well — Checkout is the more complete product in terms of how much of your ordering process Amazon takes care of, while Simple Pay handles payments only and offers more options for consumers in terms of how they can pay.

The fee structure for each is the same and is competitive with PayPal. For payments over , sellers will pay 2.9% + {content}.30 with volume discounts starting at k in sales per month, and for payments under the fee is %5 + {content}.05 per transaction.

The New York Times notes that many sellers may be wary of using Amazon’s payment services because they view Amazon as a competitor and don’t want the Seattle-based retail giant access to their sales data. “Many larger retailers express concern about partnering with Amazon because Amazon is one of their largest competitors and they don’t want Amazon to know their information,” Scot Wingo, CEO of ChannelAdvisor, told the New York Times. “On the other hand, eBay and PayPal aren’t going to use sales data to go source product themselves because they are not a retailer.”

But given eBay’s recent shift toward fixed-price goods, such as their broad partnership with Buy.com earlier this year, sellers may become increasingly wary of them as well.

Tell us, would you trust Amazon over or as much as PayPal to handle payments for you? Where does Google Checkout fit into this equation? Let us know in the comments.

Ever since I was given The Lettering Book for my eighth birthday, I’ve always wanted to dabble in creating a suite of letters with my own style and flair, but tackling the task using a professional tool always seemed too daunting.

FontShop’s online DIY font app, FontStruct, changes that. Built using a slick Flash-based interface, FontStruct is a perfect example of “social software” done right — a kind of Threadless for typographers. The font construction tool is intuitive and fun to use, and the gallery allows users to share their fonts, comment on other people’s fonts, and download people’s creations.

The tool allows for your masterpiece to be exported in TrueType format, and provides IP restrictions, so you can choose whether to throw your font open to the world or keep access restricted to a trusted group of friends.

There are limitations, of course. The tool could never be used to replace the likes of Fontographer. Notably, a large variety of shapes is possible with the building blocks provided, but they don’t come close to allowing for organic, free-flowing letter shapes to be built.

However, in terms of achieving the goal for which it was created — (re)igniting one’s interest in typography, building a community of budding type designers, and of course, advertising FontShop’s catalogue of professionally designed typefaces, FontStruct does everything in a remarkably slick way.

Oh, and it’s a lot of fun. That is, until you get to about “K”… then you start to realise just how difficult a job creating a beautiful font face is.

If you’d like to play font designer for a day, FontStruct is definitely worth a look.

Early in every web designer’s experience is a crushing moment of realization: the moment you discover that you can only use a small collection of fonts on the Web—and that all the good ones have already been used to death.

“Hooray!” thinks the naive Web newbie, checking out the font-family property for the first time. “I can spend the afternoon picking the font that perfectly reflects my personality for my new blog!”

And yes, sure enough, you can stick any font name you like in your CSS, and your browser will use the font on your system to display it:

.post {
  font-family: Papyrus, sans-serif;
}

The problem is what everyone else sees when they visit your site. If they don’t happen to have that font that is “just so you!” installed on their own system, they’ll see a generic font, most likely a downright boring one like Arial or Helvetica, instead.

Back in 1998, CSS2 proposed a solution to this in the form of the @font-face at-rule, which in theory would let you define custom fonts that would be downloaded by the browser from your web site:

@font-face {
  font-family: Papyrus;
  src: url(/fonts/papyrus.ttf);
}

On the surface, @font-face seems like it would be a godsend to web designers. So why has no meaningful support existed for it until very recently? Read on to find out…

First on the Scene

The problem with custom fonts is that fonts are not free. They are a lot of work to design—especially the ones that contain most of the characters available for use on the Web. Consequently, the vast majority of fonts (yes, even the ones that came with your computer) are licensed under terms that describe how they can be used.

Assuming you came by them honestly, you are allowed to use all of the fonts on your computer to design things from Word documents to logos on the Web, and you can do whatever you want with those things—give them away, or sell them for money—but you can’t give away or sell the font file itself.

This presented a problem for the first browsers that added support for custom fonts. Microsoft Internet Explorer 5.5 and Netscape Navigator 4 both had to tiptoe around the legal issues by developing their own font file formats that enforced the restrictions spelled out in font licenses.

Netscape 4 eventually died off, of course, and was reborn as Firefox, which has no custom font support. Internet Explorer, however, still supports custom fonts in Embedded OpenType (EOT) format today. Nobody uses it, however, because a) it’s IE-only, and b) none of the font companies have said it’s okay to distribute fonts in EOT format, either.

Apple Leads a Renaissance

The Netscape/Microsoft stalemate left designers skeptical about custom font technologies, and they got used to working with Verdana. For a while, it seemed like text on the Web would forever look the same.

Then, late last year, Apple announced that it was adding support for @font-face to Safari, and that it would work with plain, old TrueType font files—just like the ones designers collect in the hundreds and thousands! Would other browsers quickly follow suit?

In March 2008, Safari 3.1 was released with great fanfare. In its marketing for the launch, Apple boldly touted the fact that designers could “use any font they want to create stunning new websites using standards-based technology.” This announcement seemingly ignored the licensing terms of almost every font in the world—including Apple’s own fonts! Font designers were outraged.

The other browsers aren’t rushing to repeat Apple’s mistakes, but Apple has stirred up enough renewed interest in custom fonts for them to take a second look. In response, Microsoft has renewed its commitment to Embedded OpenType (EOT) format by opening it up for implementation by other browsers, and submitting it to the W3C for standardization.

One major font producer has announced its support for EOT, and has launched a site to lobby other producers to do the same.

Embedding vs. Linking

The big difference between linking to simple TrueType font files the way Safari allows and using Microsoft’s EOT format is that EOT can effectively “embed” the font in your web site. The EOT format ties the font file to your site’s domain name(s), so that it cannot simply be downloaded and re-used on another site.

This is effectively the same thing that happens when you use a custom font in a PDF file, or Flash movie. In all these formats, a motivated hacker could extract the font data and reassemble it as an unrestricted TrueType file, but the font data is distributed in a package that makes clear that such use is not allowed under the license. Font embedding is not about preventing piracy, it’s about making it clear that redistributing a commercial font is piracy.

Web designers, font producers, and browser vendors are now joining the debate over which approach to custom fonts makes the most sense for the Web. On the one hand, many designers argue that font producers should trust us to do the right thing. We don’t need a special embedding format for the images we use on our sites, so why do we need one for fonts?

On the other hand, font producers consider a font file to be a software tool for creating content, not content itself. Just as you aren’t allowed to distribute Microsoft Word to let visitors to your site view the Word documents you publish there, you can’t publish a raw font file to enable people to view content designed with that font.

Many web developers believe that embedding formats like EOT amount to Digital Rights Management (DRM), a technology that has proven disastrous to the music industry. Some have even suggested that the Web can do without commercial fonts entirely, and that we should make do with free fonts. It turns out that even popular “free” fonts like those created by Ray Larabie come with licenses that limit how they can be distributed. Larabie had this to say when discussing Safari’s font linking approach:

When it comes to my freeware fonts, I’m more reluctant to allow them to be used that way.

On his personal blog, Microsoft’s Chris Wilson has weighed in with a pragmatic analysis of the situation: Commercial font producers will never agree to allow font linking as supported by Safari, and open source fonts are unlikely to stack up in terms of quality or variety anytime soon. If we want to use commercial fonts on the Web legally, some form of embedding must be used, and EOT is the only open format for font embedding currently on the table.

What do you think? Should other browsers implement Microsoft’s EOT format, or should we push for Safari-style font linking, no matter what font producers say?

Anyone logging into the super popular Scrabulous board game application on Facebook today from the US or Canada was greeted by this message, “Scrabulous is disabled for US and Canadian users until further notice.” The demise of Scrabulous, one of Facebook’s most popular applications, was a long time coming and pretty well expected by anyone following the story.

Last week, Hasbro’s general counsel, Barry Nagler, said that Scrabulous was a “clear and blatant infringement of [Hasrbo’s] Scrabble intellectual property” and suing the application’s creators was an effort to protect “the integrity of the Scrabble brand.” However, it’s becoming a bit had to sort out just what intellectual property Hasbro owns regarding Scrabble.

According to the US Copyright Office games are not protected by copyright law:

The idea for a game is not protected by copyright. The same is true of the name or title given to the game and of the method or methods for playing it.

Copyright protects only the particular manner of an author’s expression in literary, artistic, or musical form. Copyright protection does not extend to any idea, system, method, device, or trademark material involved in the development, merchandising, or playing of a game. Once a game has been made public, nothing in the copyright law prevents others from developing another game based on similar principles.

Some material prepared in connection with a game may be subject to copyright if it contains a sufficient amount of literary or pictorial expression. For example, the text matter describing the rules of the game, or the pictorial matter appearing on the gameboard or container, may be registrable.

So strictly speaking of copyright, the only thing Hasbro can lay claim to in the US are the rules, the box art, and the visual cues on the game board and game pieces. Scrabulous doesn’t appear to infringe on any of that — they don’t print any rules (they link to a copy on Wikipedia), nor have they reproduced the Scrabble logo or any box or board art. Their game board is very similar, but methods can’t be copyrighted.

They can be patented, though. However, patents generally only last 20 years — so any patents on Scrabble, which was sold starting in 1948 — have likely long since expired. Which means that only leaves trademark.

The name Scrabble is a trademark of Hasbro in the US and Canada (and Mattel in the rest of the world). Colors and product design can also be trademarked. Scrabulous most definitely infringes on the Scrabble trademark — it is close enough that there is a likelihood of confusion between the two products. The colors and design of the game board could also be trademarked, which Scrabulous also would have infringed upon. But could a name change and slight redesign of the game board (tile size, fonts, colors, text placement) have been enough to save Scrabulous?

That’s what Bogglific — a Boggle clone also served a take down noticed by Hasbro this past winter — did and they’re still around. Blogglific is now called Prolific, and made very slight changes to scoring (the game’s creator added a bonus tile and changed how much found words are worth). The game, though, is essentially the same as Boggle in both look and game play. Scrabulous could try the same thing and skirt any lawsuits that Hasbro tries to throw at them.

Caveat: I am not a lawyer, so if I’ve gotten any of this wrong, please tell me why in the comments! (For example, though copyright law doesn’t protect games, the Copyright Office page does talk about copyright’s inability to stop others from creating games based on “similar principles,” whereas Scrabulous was a direct copy of Scrabble. That goes beyond “similar” and perhaps that matters — does anyone know?)

Selling web sites is a hot business right now. In fact, in the startup world, selling your site at auction on sites like eBay or the SitePoint Marketplace has become viable exit strategy. So many startups have gone that route that blogs have even come up with pet names for startup auctions: TechCrunch calls it the “eBay Exit” and Mashable calls it the “eBayquisition.” Very often, startup sites that exit this way sell at auction because the founders are having a hard time turning a profit or building a user base. That doesn’t mean that they’re necessarily bad sites, but that they perhaps need a little love. And that’s precisely the idea behind “web site flipping,” in which developers purchase undervalued web sites, fix them up and then sell them for a profit months, weeks, or even hours later.

The New York Times published an article today about web site flipping, which is a full time job for many people. Web site flippers “use little more than home computers and free software to buy Web sites that appeal to a small and specific niche,” wrote Abha Bhattarai. “Then they fix up the sites with hopes of reselling them for far more than they paid.”

The best place for buying and selling web sites is right here on SitePoint where over a million dollars worth of web sites are bought and sold each month in the Marketplace. “It used to be that if you had a site worth a million dollars, you’d hire an investment bank or a broker to sell it,” SitePoint co-founder Matt Mickiewicz is quoted as saying in the Times article. “But if you had one that generated less than that, you’d just have to sit on it. Now you can sell anything for any sort of profit, whether it’s or 0,000.”

Sites like eBay and the SitePoint Marketplace have clearly filled a niche for web site buyers and sellers in the sub- million range. At eBay, web site sales have doubled over the past month, and they’ve quadrupled over the past year here at SitePoint.

For anyone seriously looking to sell a web site, though, the SitePoint Marketplace is hard to beat. The average selling price at SitePoint is about 00 vs. for eBay (according to the NYT), and the sell-thru rate is 35-40% for web sites at SitePoint compared to just 12% or so on eBay. There are more than 1700 sites for sale at SitePoint each month, and many of them sell for considerably high bids — this year the highest priced sales were 0,000 (v7n network) and 5,000 (pictiger). The highest price paid for a blog was ,000 for wpdesigner.com, also earlier this year. Not quite .65 billion for YouTube, but certainly not pocket change either.

The Times article warns that when buying a web site from any online marketplace, you should always do your due diligence and make sure you’re buying what’s being advertised. SitePoint has some unique methods in place to protect buyers from fraud, including seller phone number verification and site access verification. We recommend that buyers and sellers at least get on the phone with one another before closing any large deal, and to consider using an escrow service for large transactions.

Anyone interested in buying and selling a web site should check out Clinton Lee’s excellent web site valuation guide.

The World Wide Web Consortium (W3C) today released the 1.0 version of their Mobile Web Best Practices document. The guidelines offer mobile web developers a consistent set of best practices to apply when creating content for consumption on mobile devices. “The principal objective is to improve the user experience of the Web when accessed from [mobile web] devices,” according to the W3C.

In Japan, there are already more mobile web users than PC users, and the rest of the world is catching up. Jupiter Research expects that mobile Web 2.0 revenues will hit .4 billion by 2014, with the biggest growth areas in mobile social networking and user generated content.

Developing content across such a wide array of mobile devices and creating a consistent and enjoyable user experience is not an easy task. The W3C hopes that its new mobile best practices guidelines will make it easier for developers to create content and applications for cell phones and other mobile devices.

“Mobile Web content developers now have stable guidelines and maturing tools to help them create a better mobile Web experience,” said Dominique Hazaël-Massieux, W3C Mobile Web Activity Lead in a press release. “In support of the W3C mission of building One Web, we want to support the developer community by providing tools to enable a great mobile Web user experience.”

The W3C also announced the release of the XHTML Basic 1.1 Recommendation today as the preferred markup language for the best practices document. “Until today, content developers faced an additional challenge: a variety of mobile markup languages to choose from,” said the W3C. “With the publication of the XHTML Basic 1.1 Recommendation today, the preferred format specification of the Best Practices, there is now a full convergence in mobile markup languages, including those developed by the Open Mobile Alliance (OMA).”

They don’t exist, but wouldn’t that be so cool? I’ve no idea how hard it would be to implement, or how to expensive to parse, but wouldn’t it just be the bomb?

Let’s say I have a bunch of elements, all with similar class names, which have some shared styling but also need individual rules, for example:

<ul id="menu">
	<li id="menu-home"><a href="/">Home</a></li>
	<li id="menu-products"><a href="/products/">Products</a></li>
	<li id="menu-about"><a href="/about/">About</a></li>
</ul>

I could do image replacement on those list-items to create a graphical navigation bar, with rules like this:

#menu li
{
	background:none #fff no-repeat;
}

#menu li#menu-home
{
	background-image:url("home.png");
}

#menu li#menu-products
{
	background-image:url("products.png");
}

#menu li#menu-about
{
	background-image:url("about.png");
}

Not too bad, but as the structure grows in size, so the CSS grows too. If the structure got very large so the CSS would become equally verbose; not to mention the fact that I have to manually edit it each time a new item is added.

But what if I could just do this:

#menu li[id%="/^menu\-([a-z]+)$/”]
{
	background-image:url(”.png”);
}

Now my menu styles are infinitely extensible — I can add any number of new items, without ever having to touch the CSS!

Just a thought…

According to CNET a new paper out of Microsoft Research Asia (PDF) details what may eventually be Microsoft’s answer to the Google PageRank algorithm that was in a large part responsible for the Mountain View-based company’s ascension to the search engine throne. Microsoft’s version, called BrowseRank, would rank pages based on user behavior and not based on linking.

The basic idea behind Google’s PageRank is that the more a page is linked to, the most important it must be. Microsoft says that link analysis algorithms like PageRank are flawed, though, because they’re easy to be gamed and don’t take user behavior into consideration. Of course, Google’s actual implementation of PageRank is far from that simplistic and the company updates its search algorithms hundreds of time each year. Further, Google reminds us often that PageRank is just one of many things that it uses to rank search results.

Still, Microsoft thinks that it can do better — and it better hope that it can do a lot better. As we discussed earlier beating Google with technology means you have to beat the pants off of them and really wow users with dramatically better search results.

Microsoft Research Asia’s BrowseRank algorithm ditches the link graph model that was popularized by Google, and instead creates a user browsing graph that looks at things like which links users clicked on and how long they stayed on each page.

“User behavior data can be recorded by Internet browsers at web clients and collected at a web server,” according to the researchers. Microsoft Research Asia said they gathered anonymous data from an “extremely large group of users under legal agreements with them” to put their theory to the test. The idea is that you can take anonymous browsing data from hundreds of millions of users and create a user browsing graph that can paint a picture of which pages are most important to users.

“The user browsing graph can more precisely represent the web surfer’s random walk process, and thus is more useful for calculating page importance. The more visits of the page made by the users [sic] and the longer time periods spent by the users on the page, the more likely the page is important,” say the researchers. “With this graph, we can leverage hundreds of millions of users’ implicit voting on page importance. In this regard, our approach is in accordance with the concept of Web 2.0.”

Of course, by itself, user browsing behavior probably isn’t enough to rank pages — if BrowseRank was used on its own, it would be easy to see MySpace and Facebook and video sites like Hulu shoot to the top of search results pages. However, Microsoft researchers think that it could be combined with other web page ranking algorithms to greatly enhance search results. “It is also possible to combine link graph and user behavior data to compute page importance,” they write. Researchers said that initial results from their tests using BrowseRank showed better performance than existing methods.

It wouldn’t be surprising to learn that Google had something similar under development. Google is already capturing user browsing behavior via its popular Google Toolbar, and appears to have put some of that data to use earlier this year with the launch of Ad Planner and enhancements to Google Trends that include web traffic. Using that data in search engine results rankings — or at least experimenting with doing so — isn’t a huge leap. Google is hardly a sleeping giant.