Performance should be a concern of yours if you do front end work. Speed is of the essence, and it’s (rightfully) becoming a focus. A simple thing to do to boost page speed and performance is to reduce HTTP requests. There’s science behind it, but the generalist view is: the fewer HTTP requests the better. A stellar way to reduce requests is to use image sprites in your style layer.

A sprite is a conglomeration of all the (non-repeating) image assets of your design into a single image to be referenced and obscured and in doing so having a single HTTP request to retrieve any number of pseudo-’images’. The trouble with spriting is that it takes planning and can be tedious. Luckily, spriting can be automated to a certain extent, and tools like Spritemapper make that a bit easier.

Spritemapper seems very well put together, and I can not wait to find an automated solution that will help me not have to keep track of my sprites manually.

Lukas Mathis:

The goal is not to make your user interface as realistic as possible. The goal is to add those details which help users identify what an element is, and how to interact with it, and to add no more than those details.

Great post by Mathis for the UX Magazine.

∞

Learn to Program, by Chris Pine is a wonderful introduction to programming. I recommend this book to everyone that asks me how to get started.

For me, an essential web development tool is Apache. Regardless of whether I’m working on something that will actually be deployed in an Apache environment or just prototyping something that will be built on some other platform, having Apache enabled and with support for virtual hosts, PHP, and SSI makes things so much easier.

All of these things come built-in with Mac OS X, which makes it a great web development platform. However, none of it is enabled by default, and there are some configuration changes I like to make. I find that when I set up a new Mac or explain to a colleague how to do it, I need to look up what to change and stuff like that. To make that a little bit easier I thought I’d write a post with step-by-step instructions for my own future reference.
Read full post
Posted in Mac, Productivity.

“Facebook is like jail, you sit around and waste time, you write on walls and you get poked by people you don’t know.”
— @WillFerrell (a parody account)

Masculine, masculine, masculine. Klaus Bischoff, head of design for the Volkswagen brand, kept returning to the word to describe the design of the successor to the New Beetle, the car Volkswagen calls simply “the 21st century Beetle.”

I love it. It looks a bit like an Audi, and definitely like something I’d want to drive.

✚ Permalink

Sublime Text 2, also known as TextMate 2 in my office, is becoming increasingly useful to me. The only trouble thus far is the lack of community involvement to the extent of TextMate. That’s to be expected, it’s an alpha that went cross platform two seconds ago.

All that aside though, it’s an impressive alpha. I seriously love it’s potential and I’m really hoping to make it my own over the next few months. Naturally, the biggest hangup is the lack of tools I’ve become so accustomed to in TextMate. The great thing there is that the snippets and color schemes can be carbon copied into Sublime Text 2, the only outstanding items are Commands. Those aren’t directly portable from TextMate to Sublime Text 2.

I work in HTML, CSS, JavaScript, and PHP. In TextMate I make heavy use of the validators because it’s not an IDE and doesn’t have inline validation as you would find in an integrated environment. Sublime Text 2 doesn’t come with any such validators out of the box, but there are some forum posts. I found some resources on getting JavaScript validation working in Sublime Text 2:

Sublime Text 2 (Alpha) Google Closure JavaScript Linter Build package
(V2 only) JavaScript Google Closure Linter Build

I went through the process of getting Google Closure Linter installed and running fine via Terminal, but got [Errno 2] File not found errors in Sublime Text 2. Additional Googling to find out why got me nowhere so I went with JSLint for the time being and thought I’d share how.

Adding JSLint validation to Sublime Text 2
To implement JSLint we’re going to first need JSLint. There are a number of resources for this, but I went with an OS X executable provided courtesy of javascriptlint.com. I made a new folder in my Applications folder and called it a day. JSLint is prepped and ready to go.

The other half of this puzzle is integration with Sublime Text 2. To do that, you’ll need to create a new Build System:

Upon invoking that menu, Sublime will give you an empty file to work with, outlining the structure of Build Systems. Sweet, but what to do with that? We want to send the current file we’re working with to JSLint for validation. To do that, our Build System will look like this:

{
"cmd": ["/Applications/jsl/jsl", "-process", "$file"],
"selector": "source.js"
}
Note the path to Applications/jsl/jsl — that’s where I store my JSLint install, but you will need to modify that to the path on your system. The next parameter is the -process flag that JSLint uses to define the file to validate, and the final parameter is the $file flag that will be replaced with the file path to the file you’re currently working on.

The selector will help Sublime Text 2 automatically use this JSLint Build System when you’re working within a JavaScript file.

After modifying for your system, save the file to the default path Sublime Text 2 brings up in the save dialog and restart Sublime. Open up a .js file and hit CMD+B, or use Tools > Build. An inline prompt will appear giving you the JSLint results:

I’ll continue fiddling around with getting Closure Linter to work as I’d like to have the option, but if anyone’s got a tip regarding the error I was getting I’d love to hear some feedback.

Great simple idea for showing off prototypes.

Gary Taubes examines the mounting evidence that refined sugar is killing us:

If it’s sugar that causes insulin resistance, they say, then the
conclusion is hard to avoid that sugar causes cancer — some
cancers, at least — radical as this may seem and despite the fact
that this suggestion has rarely if ever been voiced before
publicly. For just this reason, neither of these men will eat
sugar or high-fructose corn syrup, if they can avoid it.

“I have eliminated refined sugar from my diet and eat as little
as I possibly can,” Thompson told me, “because I believe
ultimately it’s something I can do to decrease my risk of
cancer.” Cantley put it this way: “Sugar scares me.”

It’s not often that a magazine article inspires me to change my life. This is one.

 ★ 

Thomas Baekdal:

It is 10 times more secure to use “this is fun” as your password, than “J4fS<2″.

∞

I've favourited a YouTube video: If the brilliant actor Dustin Hoffman had been born Scottish things may have been a bit different.

After being accused of quartering a supporter of al Qaeda, American citizen Syed Fahad Hashmi was extradited from Britain and placed in solitary confinement:

The federal government established SAMs in 1996 for gang leaders and other crime bosses with demonstrated reach in cases of “substantial risk that an inmate’s communication or contacts with persons could result in death or serious bodily injury to persons.” After September 11, the Justice Department began using SAMs pretrial, with wide latitude to wall off terrorism suspects before they had been convicted of anything.

Fahad was allowed no contact with anyone outside his lawyer and, in very limited fashion, his parents—no calls, letters, or talking through the walls, because his cell was electronically monitored. He had to shower and relieve himself within view of the camera. He was allowed to write only one letter a week to a single member of his family, using no more than three pieces of paper. One parent was allowed to visit every two weeks, but often would be turned away at the door for bureaucratic reasons. Fahad was forbidden any contact—directly or through his lawyers—with the news media. He could read only portions of newspapers approved by his jailers—and not until 30 days after publication. Allowed only one hour out of his cell a day, he had no access to fresh air but was forced to exercise in a solitary cage.

The government cited Hashmi’s “proclivity for violence” as the reason for such harsh measures—even though he had no criminal record and was not charged with committing an actual act of violence or having any demonstrated reach outside of prison. Given the number of people convicted of a violent crime behind bars in the United States, “proclivity for violence” seemed an implausible justification for the harsh measures.

After nearly three years of solitary confinement, he plead guilty to providing material support to terrorism in April 2010. He was never allowed to review evidence held against him, because it was deemed classified.

The federal government alleged that he provided support to al Qaeda by allowing an acquaintance to stay at his apartment in London with luggage filled with “military gear”—raincoats, ponchos, and water-proof socks, apparently—that later delivered it to al Qaeda in Pakistan. This acquaintance, by the way, testified against him in court.

He was sentenced to 15 years in prison. He is now being held at Colorado’s Supermax prison, in solitary confinement.

Perhaps, as the government argued, Hashmi was radicalized and was attempting to support terrorism. It’s certainly possible; while pursuing his degree in political science in New York, he advocated Muslim religious law as a “utopian” society and called the U.S. the world’s largest terrorist. I don’t deny that he may very well have been a threat, and imprisoning him based on these rather flimsy charges may have prevented greater crimes.

But I don’t know. It may also be that an innocent man—a man who advocated a political system I strenuously disagree with and that runs counter to our system, yes, but an innocent man—is now being held in solitary confinement, serving out a 15-year sentence. The only people who know are Hashmi and the federal government officials which have access to the evidence held against him, evidence we have never seen.

The government is asking us to trust them; I am generally inclined to do so on issues related to terrorism, but this isn’t acceptable. Not only is this a slippery slope, but we may have already slid down it: there may very well be an innocent man rotting away in prison. That’s too much power for the federal government to hold. We are not very far away from the situation in China, where the government uses state secrets laws to throw dissenters in jail. The only thing which prevents the federal government from abusing “Special Administrative Measures” (SAMs) and classified evidence rules is their own moral rectitude, and if that is all we have, we are in trouble indeed.

We are at risk of a government with arbitrary power, where the law does not define their power and constrain it, but rather enables them to do as they please.

Like most programmers starting a new gig, I spent my first day at 37signals setting up my work environment. I thought it might be interesting to keep track of what I installed along the way…

SizeUp for managing windows



Alfred for launching applications



More...

That pile of paper in that box on your desk can be imposing. I turn my back and it seems to grow, to double. Sometimes I think I can hear it breathing. But I don’t care. Whenever I get bogged down on a project I’m working on I take a break and process everything in my inbox.

Yes, I should do it everyday and most days I do. But sometimes, like when I’m away on business or when I’m in the thick of things, the pile reappears and it grows.  And important things tend to hide in that pile.

Here’s your tip for today: completely empty your inbox and process everything.

Let me be clear about this: you don’t have to DO everything, simply process it.

Take everything out and set it in front of you or to the side of your keyboard. Next, start at the top (or turn it over and start from what was placed in your box first) and process everything, one thing at a time. Do not cherry pick. Do one after another.

If you follow Getting Things Done (GTD), you know what to do. If it will take under two minutes, do it. If it’s for reference, file it. If it’s trash, throw it away or recycle it. If it belongs to someone else, put it in his or her inbox. For everything else, create an action and file it with the appropriate project or context.

If you’re not a GTD devotee, you can do pretty much the same thing: do it, recycle it, pass it on, or make a to-do and file it.

But here’s what’s most important: once you pull something out of your inbox, don’t put it back! Deal with it now.

Once your inbox is empty and all of your tasks are processed you’ll find that you’ve completed something. I typically feel better once that happens. You can and should do the same thing for your email: leave nothing in your inbox.

Take that sense of accomplishment and turn back to your project. I’m betting you’ll find that you can now move forward.

 

Simple Productivity Task Of The Day: Process Your Whole Inbox is a post from: First Today, Then Tomorrow. If you enjoyed or benefited from this post, please share, tweet, or link!

 
Share/Bookmark

Want an example of what I meant by “no strategy, no future”?

Here’s what Microsoft did to Courier, a promising (and original) tablet concept they were working on:

So when Robbie Bach, who led the company’s entertainment and devices division at the time, presented his idea to CEO Steve Ballmer and Microsoft’s senior leadership, he expected enthusiasm and additional funding for the project. There was just one problem: The Courier prototype borrowed from Windows, Microsoft’s vaunted computer operating systems, but had an operating system all its own. (That’s what Apple did with its iPhone and iPad — it built a new operating platform based on its existing Mac OS X.)

Bach learned a hard lesson about the power and might of Windows within Microsoft. Not only would Bach not receive the extra funding he sought, said Ballmer, who personally delivered the blow, but there would be no Courier because it was unnecessary. The best of Courier, where appropriate, would be folded into the next version of Windows, Windows 8, due at the end of 2011 or in 2012 — or maybe even Windows 9. Several months after its death, Bach announced his retirement.

The problem is very simple: they are so beholden to Windows that anything that might threaten it—whether it comes from outside the company or inside—has to be eliminated. Effectively, Microsoft is protecting Windows at the expense of the company’s long-term success. That’s not only a mistake. It’s absolute idiocy.

Microsoft has the potential to be successful in the mobile market; Windows Phone 71 is well designed and original. They have the talent. Their issue is management. Microsoft’s management refuses to threaten the company’s current business to be an important player in the mobile market. In other words, they would rather be irrelevant in the future than possibly—oh, no!—give up Windows.

Their tablet strategy is a perfect example of this. Microsoft thinks tablets should use the same operating system as PCs, with a user interface “optimized” for touch. Tablets, then, aren’t completely new devices, distinct from PCs, which would require a new use paradigm and thus a completely different user interface; instead, they are just a different form factor for using the same PC operating system we’ve been using, with the same basic use concept and user interface, just with a nice touch layer overlaid.

Why would Microsoft want tablets to be merely derivative of PCs? That’s easy: because it means what they’re currently doing, licensing a PC operating system and selling software for PCs can continue unchanged.

Microsoft’s management isn’t thinking about where computing is moving, how they can improve people’s lives and how they can capitalize on it. They’re thinking about how they can preserve their current business. And that’s a fantastic path toward irrelevancy.

Their phone operating system’s name is symptomatic of their inherent problem: they put “Windows” in the name of a mobile operating system that doesn’t even have windows. They are so dependent on Windows they are afraid even to name their mobile operating system something different.

Recently, Shawn Blanc, Patrick Rhone and others have been discussing attribution on the web. The tech web is especially incestuous, as the same 8-9 stories hit site after site daily. It’s important to identify both the source and the reference, or “via.” Here’s how I do it.

Imagine that website.com wrote a nice original piece. I first became aware of it by reading a link on coolstuff.com. In re-posting the story myself, I’ll note and link the website.com story in the body of the post. At the end of the post, I’ll include a link to the reference at coolstuff.com as a footnote of sorts, like so:

[Via coolstuff.com]

That way both sites get a link. The source is clearly identified in the body of the post while the reference (or “via”) follows, always using the same syntax. If you do it differently, I’d like to hear about it.

I’m curious how many developers have worked with “decoupled” content management systems.  This is a system that sits behind your firewall, manages your content, and pushes it into your delivery tier on-demand.  In these environments, you have a “repository server” and a “publishing server,” and never the two shall meet, except for the conjugal moments when you push content over the wall.
The existence of these systems is very stacked towards the upper end of the content management scale.  Decoupled systems are usually very enterprisey, and most often Java-based.  (More on why this is later.)
I’d guess that a relatively small percentage of developers have experience here.  I’ve done a tiny bit of work in this space, but my stock-in-trade has always been coupled systems where the CMS and delivery server are one-and-the-same – systems like Drupal, Ektron, EPiServer, eZ publish, etc.
When I was presenting at Gilbane Boston last December, I took an impromptu survey of the attendees at my session.  Of the 60 or so people with active CMS projects, only one of them was on a coupled system.  The fact that this was shocking to me is probably proof of how sheltered I am.  There’s a huge installed base of decoupled systems out there.
If all you’ve ever worked with are coupled systems (and there’s a lot of us), you might be pondering all the limitations this architecture brings with it and wondering why anyone would need this.  It seems so…out-dated, right?
The primary benefit to decoupled systems is that you don’t have to run a CMS in your delivery tier (in most cases – more later on this).  This imparts all sorts of secondary benefits.
It allows your repository system and publishing system to be on different architectures.  You could easily have a Java-based repository pushing content onto a Windows server running .Net. You can usually make your delivery layer more secure.  If you’re just publishing static HTML assets to a stripped-down Apache server, your attack surface drops through the floor – the potential hack points an a well-maintained Linux/Apache server are miniscule compared to your average Joomla install.  Having a full-blown CMS in the delivery tier has been known to give panic attacks to paranoid sysadmins. You can publish content to multiple servers. A large media enterprise might have hundreds of servers in dozens of countries on multiple continents.  Deploying content is much more complex than changing the “published” column in some database table.  Edge servers need to be updated, media needs to be pushed into a CDN, reverse-proxies need to be reset, failover servers need to be updated, etc. Since you don’t need to install a CMS on all these delivery servers, you don’t need to license them (usually – again, more later).  Depending on the size of your delivery environment, this could save enormous amounts of money. It can be easier to scale a decoupled delivery tier.  Bring a new server online, add it to your publishing script, and tell your load-balancer about it.  That’s a bit of an over-simplification, but I’ve heard about installs on grid networks like EC2 that can bring a new batch of servers online in literally minutes. Reliability is usually higher.  No CMS in the delivery tier means less moving parts.  Static HTML files usually don’t throw exceptions. You can publish content from multiple repositories and systems.  Your CMS may only be one system of many that generate content, so your delivery tier needs to publish content without knowing nor caring where it came from.  (For much more on this, see The Dawn of the Web Content Delivery System from last year.) In some cases, the content of the Web site is secondary to its purpose.  Wells Fargo’s Web site, for instance, is a massive, custom-built banking platform that incidentally also displays some content.  You can’t drop a CMS on top of this.  The CMS has to be subservient to it, exist somewhere else, and push content into it. Some editors want a “staging environment” in which to develop content.  I think these are overblown and usually unnecessary, but a lot of people are still in the mode of developing and reviewing content in one environment, then publishing it to another.  The idea of “editing content in production” freaks them out. Late last year, I was researching my session on a related subject for Gilbane, and I had the privilege of talking to a lot of really smart people in the content management field about publishing models.  People like Kevin Cochrane from Day, Seth Gottlieb from Content Here, Tom Wentworth from Ektron, Tony Byrne of the Real Story Group, Peter Monks from Alfresco, and John Peterson from Sutro Software, among others.
What I learned is that being coupled or decoupled is not a binary state.  Between the two extremes, there are lots of shades of gray and levels of “purity.”  This has evolved over the last decade-and-a-half.
Way back in the day, decoupled systems were really decoupled.  Many, many systems did nothing but push static file assets through to the delivery tier.  You’d run some batch job, and a bunch of HTML files and JPGs would get pulled out of your repository and FTPed or copied somewhere to be consumed.
This is what we’ll call “pure” decoupling.  I’m thinking of Cascade Server, the old Serena Collage, and even Movable Type (the humble blogging platform on which this very site still runs).
Today, this is more and more rare, even among systems that call themselves decoupled.  A lot of systems can still do this, but it’s not the preferred way of delivering content anymore.
The fact is, things need to happen in the delivery tier.  There’s a reason we no longer code static HTML files in FrontPage – because a decade or so ago, we decided we wanted our Web pages to do things.  They suddenly had to act like databases, react to the user, be searched, allow personalization, and all those other great things.  This can’t be done with static HTML.  (There’s a reason why ASP, PHP, CGI et. al. were invented, after all.)
(One other challenge with decoupling we’re not going to talk about much is what to do with user-generated content.  Some content, like comments, for instance, is created in the delivery tier.  When you’re decoupled, you need to somehow push that content “backwards” to your repository if you want it managed.  Pure or not, figuring this out is tricky in a decoupled environment.)
If you’re publishing pure static content, you can have very basic problems due to the fact that your content is frozen at publish time. For example, if you generate the navigation elements at publish time, then you essentially have to re-publish every page when even one thing changes, because you have no way of knowing if Page X appears in some menu on Page Y.
What usually happens with this model is you start publishing file includes, or scriptable files that execute or assemble at request time.  This site, for instance, uses Movable Type to generate PHP files that define a “Post” class and are templated when requested.  But you still have the limitation that you need an “overhead view” of your content to make decisions about how to display it, especially when rendering navigation and making decisions based on context.
To make this easier, static publishing naturally evolved to push data rather than files.  You had systems that were now able to contact a database server in the delivery tier and “publishing” now meant just throwing database rows over the wall.  With this, you could have all your pages in a table, and render them dynamically out there in the templating language of your choice.  This pushes your templating to request time, rather than publish time, which is much easier to develop against (the classic “baked” vs. “fried” dichotomy).
I wrote about this eight years ago when I had a sudden epiphany that managing content was not the same as delivering content: The Value-Add Side of Content Management.  A year later, I opined about rendering a site in an entirely different language than the one in which the content was managed: CMS Administration vs. Presentation Languages.
So, this concept of pushing data over the wall – is this still “pure” decoupling?  Yes, because the delivery tier has no idea where the content came from.  It’s published as a neutral format.  With either HTML files or database records, your delivery server really has no idea where the content came from and doesn’t really care.  You could even swap in another CMS, so long as it published stuff in the same format.
And this is where we saw the rise of “the runtime” (I totally stole that word from Kevin Cochrane of Day).  By runtime, I mean code on your delivery server which acts on the content to render a Web site.  These systems were built to make sense of all the published content assets and generate a dynamic  Web site out of it.  They didn’t manage the content (that was being done somewhere else, remember), but they delivered it.  The runtime enables things like dynamic navigation, personalization, permissions, etc.
So long as our decoupling is pure, these runtimes don’t have to know anything about our CMS.  This can be handy, because you could have entirely different sets of developers working on the runtime and the CMS.  The runtime developers would just explain to the CMS developers what content they needed and in what format, and the CMS developers would see that they got it.
Additionally, there’s an entirely different set of skills required for developing in the runtime.  As general Web developers, we tend to look at our skills as all bundled together, but there’s actually a clear dichotomy.  HTML, CSS, user interaction, analytics, social media integration, public user interaction, etc. are content delivery concerns.  Conte[…]

J-P Teti:

The iPad only does less than a regular computer to us geeks. To
everyone else, it does more. This is what Motorola and Google and
Samsung and BlackBerry and everyone else, with the sole exception
of Apple, do not get about “open” computing.

Astute analysis of the iPad to regular folks.

 ★ 

Not the kind of thing i’d wear personally, but I was impressed by how well these were done!



Available from Forbidden Planet for about 17 of your earth pounds.


Tagged: drwho

Years ago, when using CSS for layout was still rather new, one of the common arguments for using CSS instead of tables for layout was that it enables you to change the layout order without editing your markup.

A typical example is a page with a vertical sub-navigation to the left, a centered content area, and a sidebar to the right. If you use tables for layout you will need to change the HTML to move the columns around, say if you wanted the navigation on the right and the sidebar on the left. With CSS you can change the visual order of the columns without touching the HTML.

But, there is a but.
Read full post
Posted in Accessibility, CSS.

I’ve never built an iOS application, and I don’t know if I will. If I were to start dabbling with it some day I do know that I would want to make sure the applications I build are as accessible as the platform allows.

Thanks to the accessibility features of iOS, the iPad, iPhone and iPod Touch can all be quite accessible, particularly to visually impaired users. It does require that developers keep accessibility in mind while building their app, but fortunately that does not seem to involve a lot of work.
Read full post
Posted in Accessibility, iOS.

Everybody is Spamming Everybody Else on MTurk -- one researcher found >40% of HITs are spammy, but this author posted a Mechanical Turk HIT to supply recommendations for visitors to a non-existent French city and got responses from people expecting that every response would be paid regardless of quality.
Javascript Garden -- a growing collection of documentation about the most quirky parts of the JavaScript programming language. It gives advice to avoid common mistakes, subtle bugs, as well as performance issues and bad practices that non-expert JavaScript programmers may encounter on their endeavours into the depths of the language.
A 5 Minute Framework for Fostering Better Conversations in Comments Sections (Poytner) -- Whether online or offline, people act out the most when they don’t see anyone in charge. Next time you see dreck being slung in the bowels of a news story comment thread, see if you can detect whether anyone from the news organization is jumping in and setting the tone. As West put it, news organizations typically create a disconnect between the people who provide content and the people who discuss that content. This inhibits quality conversation.
Full Text RSS Feed -- builds full-text feeds for sites that only offer extracts in their RSS feeds. (via Jason Ryan)

Good comeback for the old "oh you delete stuff therefore you actually are responsible for every comment left by every person on your site" legal threat

For years now, we've used a number of techniques for hiding content offscreen for accessibility purposes. We do this because the content is still accessible to screenreaders while being removed from the interface for sighted users.

An article over at Adaptive Themes reviews a number of techniques for hiding content that were considered for inclusion on a Drupal 7 project (but certainly applicable to any project).

Here is a summary of those techniques and the pitfalls of each technique:

Text Indent

.element-invisible {
text-indent: -9999em;
outline: 0;
}

Unfortunately, this technique doesn't work with RTL (Right-to-Left) languages.

Position Absolute and Collapsed

.element-invisible {
height: 0;
overflow: hidden;
position: absolute;
}

In this case, Apple's Voice Over will not read content within an element that has zero height.

Position Absolute and Offscreen

.element-invisible {
position: absolute;
top: -999999em;
left: auto;
width: 1px;
height: 1px;
overflow:hidden;
}

In this case, if you have focusable content within the positioned element, the page will scroll to that element, thus creating an unsettling jump for sighted users.

Clip Method

.element-invisible {
position: absolute !important;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
}

The article ends with this final technique and is the solution they ended up using on their project.

With the work I've been doing at Yahoo!, we had been using the Position Absolute and Offscreen method. But sometimes we wanted to set focus to offscreen content. We had switched our technique to the Clip Method but uncovered differing behaviour between browsers.

Everything works great in Internet Explorer and Firefox. However, in Webkit (Chrome and Safari) and Opera, there's an interesting behavior when the element is at the edge of the screen. If the element, when unclipped, is large enough to force a horizontal scrollbar, will force a scrollbar even when clipped.

This seems to go against the CSS 2.1 guidelines that say:

Content that has been clipped does not cause overflow.

However, by forcing a scrollbar in Webkit and Opera, it does, in fact, seem to cause overflow. So how did we get around this?

Positioned, Clipped, and (almost) Collapsed

We combine a few techniques into one:

.element-invisible {
position: absolute !important;
height: 1px; width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
}

Using absolute positioning, we take the element out of flow so as not to affect the layout of anything around it. With a height of 1px, the element should still be visible for Voice Over to read the content. The clipping removes any visible trace of the element from the page.

Any focusable elements inside are still focusable, so depending on placement within the overall layout, some considered placement may still be of concern. Although, I might question why you are focusing on an element that was so far removed from the overall flow of the document.

We've only begun using and testing this technique, so even this may not be perfect. Any feedback and suggestions are quite welcome.

Jon Hicks just announced his upcoming book:


For the last 5 years I’ve been wanting to write this book – I keep looking around for other books of it’s type on the market, but never find any. Now the conditions are right – namely a decent publisher that cares about the quality of the printed book, and the right team of people to make it happen!



I’m a big fan of all Jon’s work, and the fact that it’s being published by Mark Boulton’s Five Simple Steps only makes me more excited about this book.

Tags
fivesimplesteps, jonhicks
Short URL
maxvoltar.com/117

About a month ago, I got a call from Brian Ford, who happens to be my cousin. Brian’s wife, Carolyn, had come up with an idea and Brian wanted my thoughts. Amazon had recently rolled out a new feature that allows users to lend Kindle books to others using their e-mail address. This, in effect, means you can really only lend books to people you know (because you probably don’t know many stranger’s e-mail addresses). Carolyn’s idea was simple: what if there were a site that could hook you up with a stranger that has the book you want, so they can lend it to you?

Although I owned exactly zero Kindle books and in the past five years have literally written more books than I’ve read, it sounded like a pretty great idea, and I was interested in building it. The first thing I did was call up my homeboy Nathan Borror, whom I trust implicitly on all things, but especially all things web and all things books. Nathan runs social book site Readernaut, and I figured he’d be able to help me understand the ins and outs of how a service like this might work, and he’d probably also know if something similar was already out. Nathan dug the idea and said wasn’t aware of anyone else already doing it. I was sold. That same night, I dug into Amazon’s Product Advertising API to see if I could make this thing happen.

Carolyn, Brian and I also brought in my Dad, who is a great business man and marketing guy, as well as plenty of thoughts from my wife Nobu, and we all started sorting out what this thing would really be. We quickly ran up against some constraints that ended up shaping the product:

First, we learned that Amazon only allows each copy of a book to be lent out one time. That is, if you buy Water For Elephants, you can loan it to a friend one time, and then you’ll never be able to loan it again. This meant that for our book lending service, it wasn’t good enough to have a copy of a popular book available from one of our users—we needed lots of copies of popular books.
Second, we learned many Kindle books are not lendable. That is, their publishers have decided they are not on board with the lending concept and have forbid Amazon from allowing certain books to be lent. To make matters worse, Amazon’s Product Advertising API doesn’t include book lendability information, so we had to resort to—let’s call them “less elegant”—methods for getting that information.
We had initially wanted to target Nook, as well as Kindle, since that platform also allows for book lending, but Barnes and Noble doesn’t have the APIs to make a really great service available, like Amazon does, and we decided that it was better to make a great Kindle site than a not-so-great Kindle and Nook site.

The first two restrictions are clear indications that the publishing industry isn’t yet convinced that book sharing won’t ruin their old school business model. And while I don’t really give a damn about their business model, I am a published author, and it was important to me that any site we built encouraged people to buy books as well as lend them. I didn’t want to build the Napster of books.

Unsurprisingly, one of the most contentious point of the proceedings was coming up with a name. I really wanted a fun, “producty” name, but I also suck at coming up with such names. Some others in the group wanted a name that was a bit more obvious and straightforward (primarily for SEO reasons). In the end, Brian suggested “Lendle,” which I thought was perfect. I suggested a pairing with the .me TLD, and we ended up with Lendle.me. As Brian said in his post about Lendle, “I’m not sure that it was a universally loved choice, but I can’t imagine calling it anything else, now.”

We spent a great deal of time hashing out the model for how the site would work. We consider the idea of book trading, but ended up going with a system that enforces a lending/borrowing ratio—that is, if you’re not willing to lend, you won’t be able to continue to borrow. When you join Lendle, you’re given two “borrow requests.” You can request to borrow two books from our users. Then, we ask you to tell us what books you own. The more lendable books you own, the more borrow requests you’ll accrue. And when a user requests one of your books and you lend it to them, you get rewarded with even more borrow requests.

One of our early concerns was that mooches would quickly deplete our supply of available books, but so far, this has not been the case. In just a few days of being live, our users have added over 1300 copies of over 800 unique lendable books, and despite several hundred borrow requests fulfilled, the vast majority of the books are still available. So far, our users have proven to not only be willing to lend, but actually to be more interested in lending than borrowing. Also, so far, our users have bought almost as many books from Amazon through our “buy it” buttons as they have borrowed from other Lendlers (yes, we’re calling them that). We gots good people.

Anyway, I spent most of my evenings and weekends for about three weeks hashing the thing out, and then we had a short one-week beta period before launching this past weekend. A real whirlwind, but it’s been fun, and worth it. In the meantime, we discovered that we do, in fact, have some competitors, including a couple that launched before we did. But we think we’re better, for a few key reasons:

At Lendle, we are 100% transparent about what books our users have and don’t have, and which books are lendable and which aren’t. Our competitors don’t tell you how many members own the book you’re requesting to borrow, so you have no indication if you’re likely to actually receive that book anytime soon or not. And some sites don’t even let you know which books have been deemed “not lendable” by their publisher, so you may request a book that it’s impossible to get! On Lendle, you’ll know what you’re getting into before you request a book.

Lendle does everything humanly (and roboticly!) possible to protect your anonymity. No one has to know what books you own, no one has to know you’re the one who lent a particular book, and no one has to know which books you want to borrow. And while borrowing a Kindle book requires your e-mail address be shared with the person lending you the book, we do it in the safest, securest way possible.

Book-sharing sites like Lendle can’t work unless people are willing to lend, not just borrow. Lendle rewards you for being willing to lend books, and ensures that “mooches” don’t deplete the available supply of books.

For those interested in some technical details: Predictably, the whole project was built using Django and Python, and is hosted at Rackspace Cloud. The stack is pretty typical for Django projects: Python, Memcached, Apache, nginx, MySQL, Django 1.3, etc. The site makes very heavy use of the Amazon Product Advertising API.

All in all, it’s been fun and exciting to watch Lendle sprout from a simple crumb of an idea Carolyn had to an actual product with an impressively high number of users for only having been live a few days.

Hell, even I now own some Kindle books—I might even read them!

Today we launched Viewer 2.5, now out of Beta. The most significant update is a new, web-based profile system, which allows profiles to be viewed and edited both on the web and in the Viewer. For example, here's mine. Please note this is just a starting point for the web-based profiles; we’ll be doing a lot of work to refine the usability and make them richer over time.
In response to your feedback from the early beta versions of Viewer 2.5, we've added some privacy settings that will allow you to control just how public your profile is. Once you’ve logged in, click on “Privacy Settings” in the upper right corner of your profile. Group settings set in the Viewer will be overridden by these group privacy settings.
"Everyone" means that the information is available to the whole Internet and can be picked up by search engines."Second Life" means that the information is available to all Second Life Residents who are logged into the website or inworld. This is the default for all existing Residents using Viewer 2.5."Friends" means that only your Second Life friends can see the information on the web and inworld.This is why we have a beta process--to address concerns and improve your user experience. We will continue to iterate as we get more feedback. Thank you for all your help and comments. Please attend the Viewer 2 User Group meetings if you would like to share your thoughts and feedback directly with me and the Snowstorm team.Viewer 2.5 also has some other new features. The one I like best is that you can now have your Favorite landmarks also appear on the login screen, so that you can log directly into your favorite locations. Torley made a video about this, so check it out! We've also improved some texturing performance and fixed another batch of bugs. Watching the internal data, we've already seen a noticeable improvement in stability and performance--on par with Viewer 1.23.Download Viewer 2.5, try it out, and keep the feedback coming! And, if you Twitter, please use the hashtag #slviewer2.Helpful Links
Download Viewer 2.5:Windows | Mac | LinuxViewer 2.5 Release NotesSL Forum on Viewer 2SL Answers on Viewer 2

It's annoying when a web page is loading and gets stuck downloading a Javascript file from a remote domain. Until the file has downloaded, rendering on the page stalls which could potentially lose you traffic as people give up waiting. Instead it's a good idea to load the remote Javascript asynchronously so the page can continue to render and the code is downloaded in the background.

How to download the remote Javascript asynchronously
Pop this bit of code in the <head> section of your web page template. Alternatively it should also work nicely in your own external Javascript file but by putting it in the head it will load earlier. Obviously change the 'http://www.example.com/somefile.js' filename to the file you want to load.

(function(){
var a = document.createElement('script');
a.type = 'text/javascript';
a.async = true;
a.src = 'http://www.example.com/somefile.js';
var b = document.getElementsByTagName('script')[0];
b.parentNode.insertBefore(a, b);
})();

If you've ever inserted Google's asynchronous analytics tracking code into a page template you'll note the method used is the same, although they put several lines of code into single lines.

Deferring the functions in the file from running until the page has rendered
Now that the Javascript file has started downloading while the rest of the page loads and renders, it's more or less random when the code in that page will start to execute. If it's in the cache it will run sooner; if it has to download the file it could be any amount of time (or not all if it times out).

If the code in the remote Javascript file needs to modify something in the DOM then it needs to wait until the page has rendered before doing anything. If all it's doing is sending off some tracking information (or similar) then this step may not be necessary.

To defer running the script functions until the page has rendered, put the code into a function and then attach an event to the page which runs that function when the page is ready as shown in the example below.

function my_initialization_function() {
// do something
}

if(document.readyState === "complete" ) {
my_initialization_function();
}
else if(document.addEventListener) {
window.addEventListener("load", my_initialization_function(), false );
}
else if(window.attachEvent) {
window.attachEvent("onload", my_initialization_function());
}

The test on line 5 will run the initialization function is the page has already finished loading. This is important because if the page has loaded already and an load event is subsequently attached it will not be fired.

The section on lines 8 to 10 adds an event listener for the browsers that support it (all non IE browsers) and lines 11 to 13 for browsers that instead support attachEvent (IE browsers).

Now when the page has finished loading, or if it had already finished loading when the script has fully downloaded, the initialization function will be called.

One final note
I have seen some examples show the last two lines as one line like so:

(document.getElementsByTagName('head')[0]||document.getElementsByTagName('body')[0]).appendChild(a);

However, when I tested asynchronous loading, I found using this method would prevent the whole page loading in Internet Explorer 6, although it was fine for all other browsers. IE6 would display a modal dialog saying the page could not be loaded. For this reason, it's best to use the way I have presented in the first example in this post.

Related posts:

Detect IE6 with jQuery or Conditional Comments (Wednesday, August 18th 2010)
jQuery: hide text when the page is loaded and show it later (Monday, June 21st 2010)
Using Javascript's setTimeout() with variable parameters (Tuesday, March 9th 2010)

A Web without video would be a dull Web and consumers, developers and businesses want video on the Web to just work. As an industry we know this and have, until recently, been on a path to make this a reality with HTML5 by integrating video into Web pages more natively using H.264. There is more detail and discussion below but I want to be unambiguous on some key points:
IE9 will support H.264. Microsoft has released an add-on for Firefox on Windows to support H.264 and today we are releasing a plug-in for Google Chrome on Windows to provide support for H.264. We will provide support for IE9 users who install third-party WebM video support on Windows and they will be able to play WebM video in IE9. Many parties have raised legitimate questions about liability, risks, and support for WebM and the proponents of WebM should answer them. For context, Google recently stated (and then clarified) that their Chrome Web browser would drop support for the H.264 video format in favor of exclusively supporting Google’s new WebM format. There are many thoughtful articles questioning their decision, for example Google's dropping H.264 from Chrome a step backward for openness and The backlash over Google's HTML5 video bet and By dropping H.264, is Google avoiding a trap or walking into one?.
Setting aside the speculation about the reasons and objectives, this announcement has created instability and uncertainty around video on the Web. To get back on track, technical enthusiasts, developers, businesses, and consumers need consistent and sustainable answers to many questions about WebM. These groups also deserve to be part of an open discussion.
Below, we set out the main questions we’ve heard as part of the public conversation with many individuals and groups across the community and industry over the last few weeks and months. Broadly, the questions cover three areas:
Who bears the liability and risk for consumers, businesses, and developers until the legal system resolves the intellectual property issues; When and how does Google make room for the Open Web Standards community to engage genuinely; What is the plan for restoring consistency across devices, Web services, and the PC. We’ve been clear from the first public demonstration of IE9 that the community deserves a reliable platform for delivering video as part of the modern Web. The goal of this post is to raise the visibility of some of the legitimate questions that the community needs answered from WebM proponents in order for a new technology to become part of the Web standards we all rely on. The climate around intellectual property issues in general and video formats in particular is often highly charged. Anyone suspicious of Microsoft introducing “uncertainty, fear, or doubt” might examine the historical evidence of intellectual property issues around standards and media formats, some of which is covered below. That evidence should leave little doubt that what is needed is a more open dialog about these issues. Our public work on Internet Explorer has made clear our focus on providing the best implementation and validation of established Web standards, helping to move the Web platform forward, and providing the safest and most trustworthy browser for consumers who use Windows.
While this blog is focused on Internet Explorer, we think it is a good forum for a broader conversation about the browsers and technology that the community expects to all work well together. As part of the ongoing transparency in developing IE9, we’re using this forum to put forward questions for the broad community.
Microsoft’s Point of View and Plan for IE9 As context for the questions below, here’s a re-cap of Microsoft’s point of view and plan for IE9.
IE9 will play HTML5 video in the H.264 format. Why H.264? It is a high-quality and widely-used video format that serves the Web very well today. We describe many of those reasons in blog posts here, here, and here. Any browser running on Windows can play H.264 video via the built-in Windows APIs that support the format. Our point of view here is that Windows customers should be able to play mainstream video on the Web. We’ve provided Windows 7 customers who choose to run Mozilla Firefox an add-on to enable playing H.264 video on Web pages with the HTML5 video tag. Today we’re making available a similar plug-in for Google Chrome. IE9 users who install third-party WebM video support on Windows will be able to play WebM video in IE. We chose this path (supporting one additional video format that the user has installed on her machine) because we recognize that other video formats exist and we wanted to give customers a convenient way to view video in those other formats without specifying a particular one. With this approach, we provide a more stable platform overall given the many documented risks with arbitrarily downloaded video codecs including their use as vectors for malware and phishing. Our point of view is totally clear. Our support for H.264 results from our views about a robust Web and video ecosystem that provides a rich level of functionality, is the product of an open standards process like the W3C’s HTML5 specification, and has been free from legal attacks. Microsoft is agnostic and impartial about the actual underlying video format for HTML5 video as long as this freedom continues.
Our commitment to play WebM videos in IE9 for users who have installed WebM demonstrates our approach. We have worked closely with Google to help them deliver a WebM implementation on Windows and Google engineers are on the Microsoft campus this week; we appreciate their positive feedback to date around this work.
Industry Questions We want to make sure that what becomes a standard can stay a standard and that the standard serves the industry and customers well. An open dialog about the issues that come from new and unproven technology is an important part of how the Web works.
Let’s start with who bears the liability and risk for intellectual property?
Looking at video format support as a vote on who is for or against an open and free Internet is tempting but also naïve. Regardless of the debate on the interplay between patents and video formats for the Web, there is absolute certainty that some parties believe they hold valid and unique inventions (patents) and they will assert those rights if they think they are being infringed. Historically, providing new audio-video-image formats that are entirely free from infringement has been a lengthy and challenging process. Even when we have set out to do this ourselves, we have ultimately ended up being challenged. The targets of lawsuits around the JPEG image format, for example, included a shoe seller, an NFL franchise, and a company best known for its cheese. The real-world risks here apply broadly to many, many companies and agents. Wishing these risks away doesn’t work.
Offers of “free” or “royalty-free” source code and strong assertions that the technology is “not patent encumbered” don’t help when a patent holder files a complaint that your video, your site, or your product infringes on her intellectual property. The only true arbiter of infringement, once it’s asserted, is a court of law. Asserting openness is not a legal defense. Whether one supports open technology or not, there are practical liability issues today that need to be examined. These issues motivate different potential approaches to risk protection. One path is indemnification. For example, will Google indemnify Mozilla, a PC OEM, a school, a Web site, a chip manufacturer, a device company, or an individual for using WebM? Will they indemnify Apple? Microsoft? Will they indemnify any or all of these parties worldwide? If Google were truly confident that the technology does not infringe and is not encumbered by patents whatsoever, wouldn’t this indemnification be easy? It’s one way to move away from conversations about unknown and unbounded risk to a rational conversation about costs and liability. Whether one agrees or disagrees with the notion of software patents, the risk remains and the standard business practice of one party indemnifying another is well-understood. Or, does Google instead plan to protect WebM participants from risk by creating a patent pool containing the third-party intellectual property in WebM and making a license available? That is another way in which risks like this have been addressed in the past. What would the terms of that license be? Or, does Google plan to work with an existing patent pool to help provide Web developers get certainty quickly, as is already the case with H.264? These are difficult questions for sure, but they deserve answers if the Web community is to move from a well-established and successful video format for which the intellectual property landscape is more certain. We think the community is looking for meaningful answers to this risk question.
The risk question is a legitimate business concern. There are hundreds if not thousands of patents worldwide that read on video formats and codec technologies. Our experience with trying to release WMV for free and open use, and the subsequent claims against Microsoft, support this history as do the cases against JPEG, GIF, and other formats. By way of comparison, Microsoft provides and has even expanded the indemnification provided to end-users of Windows. Looking at the notes from a recent “WebM Summit” (here, slide 12), Google says that there are “No known royalty requirements.” That’s quite different from no royalty requirements, and the former might be a more accurate description of the IP situation.
These questions have many potential follow-ups. For example, Google’s blog posts have indicated a strong desire to use open formats for the video tag; will this pattern apply to plugins in general[…]

Michael Wolfe, on Quora:

Well, let’s take a step back and think about the sync problem and
what the ideal solution for it would do:

There would be a folder.
You’d put your stuff in it.
It would sync.

They built that.

Yup.

 ★ 

This is part of a series of guest posts covering tips and tricks for working with CSS. These techniques, along with web fonts, make rich interactive sites achievable with simple and accessible standards-based markup and CSS. Today’s guest post was written by Andy Clarke, author of Hardboiled Web Design.

In this example we’ll use CSS3 two-dimensional transforms to add realism to a row of hardboiled private detectives’ business cards.

There are a number of transform properties we can use, including:

translate: moves an element horizontally and vertically
skew: distorts an element horizontally and vertically (not covered in this article)
rotate: rotates an element
scale: increases or decreases the size of an element

The basic syntax for transforms is simple:

transform: transform type(value);

There’s no getting away from the fact that CSS transforms are an emerging standard. But there’s already widespread support for them in contemporary browsers; Firefox, Google Chrome, Opera, and Safari have all implemented transforms using vendor-specific prefixes and Microsoft is soon to follow. For the transforms we’ll be covering in just a minute, we’ll need vendor-specific prefixes for Mozilla, Microsoft, Opera, and WebKit, followed by the W3C’s official transforms syntax. (From now on, I’ll use only the W3C’s official transforms syntax. I’ll leave it up to you to add the corresponding vendor-specific prefixes.)

.vcard {
-webkit-transform: translateY(90px);
-moz-transform: translateY(90px);
-ms-transform: translateY(90px);
-o-transform: translateY(90px);
transform: translateY(90px);
}
Quite a fistful I know, but necessary, because these vendor-specific prefixes allow each browser maker to perfect their implementations as the standard develops. Two scripts make Hardboiled Web Design possible. First, selectivizr enables CSS3 selectors in older versions of Internet Explorer. Then, Modernizr tests a browser’s ability to render CSS3 two-dimensional transforms and adds class attribute values of csstransforms or no-csstransforms to the HTML element, depending on the result.

Setting up the HTML
Here we have four microformat hCards, each with its own set of values to describe a detective’s contact information. These act as styling hooks and enable our users to extract the data from each hCard more easily:

<div class="vcard">
<h3 class="fn">The Fat Man</h3>
<p>Private Investigation</p>
<p>$50 a day plus expenses. By appointment only</p>
<p>Dial: M for Murder</p>
</div>

<div class="vcard">
<h3 class="fn org">Nick Jefferies</h3>
<p><span class="role">Private eye</span>
<span class="tel">WA6-0089</span></p>
</div>

<div class="vcard">
<h3 class="fn org">Shoes Clues</h3>
<p>Finding the footprints they leave</p>
</div>

<div class="vcard">
<h3 class="fn org">Hartless Dick</h3>
<p class="role">Private investigations</p>
<p>Dial <span class="tel">#333</span> for a quick fix</p>
</div>

Laying out the hCards
Let’s start by writing styles that will be common to every card. We’ll float each one to the left and give them identical dimensions:

.vcard {
float: left;
width: 300px;
height: 195px;
}
Our next task is add individual background images to each card. But how? Remember there are no id attributes anywhere in our HTML?

The :nth-of-type pseudo-element selector targets an element based on its type and position in the document. Want to target the first, second, third, or fourth card, no matter where they appear in the document order? Not a problem. This makes :nth-of-type pseudo-element selectors one of CSS’s best-kept secrets:

.vcard:nth-of-type(1) {
background-image: url(c01.jpg);
}

.vcard:nth-of-type(2) {
background-image: url(c02.jpg);
}

.vcard:nth-of-type(3) {
background-image: url(c03.jpg);
}

.vcard:nth-of-type(4) {
background-image: url(c04.jpg);
}
As we only want the background images to show and not the HTML text, indent every element inside those cards to move them off-screen:

.vcard * {
text-indent: -9999px;
}

The best way to learn transforms is to see them in action, so we’ll use scale, translate (move), rotate, and a combination of all three to adjust the size, position, and rotation of each card.

Transform ‘scale’
When we use the scale property, we make elements appear larger or smaller. By how much and on what axis is determined by a scaling factor, which can range between 0.99 and 0.01 to make an element smaller, or 1.01 and above to make it larger. A scaling factor of 1 maintains the intrinsic size of an element. You can scale elements along the horizontal (X) or vertical (Y) axis, or a combination of the two. Other elements remain unaware of a new size and so don’t reflow around it.

To vary the size of several hardboiled cards, we’ll scale them in two dimensions using the combined scale property. Scale the first card down to 80% (.8):

.csstransforms .vcard:nth-of-type(1) {
transform: scale(.8);
}
Next, increase the size of the second and third cards by 10% (1.1):

.csstransforms .vcard:nth-of-type(3),
.csstransforms .vcard:nth-of-type(4) {
transform: scale(1.1);
}
Transform ‘translate’
Moving elements with translate behaves in a similar way to relative positioning, where an element is offset visually but keeps its position in the document’s normal flow; translate moves elements on the x- and y-axes. We can specify how far they move by using pixels, ems, or percentages that are relative to the size of the element. We’ll translate each card along both the horizontal (X) and vertical (Y) axis:

.csstransforms .vcard:nth-of-type(1) {
transform: scale(.8) translateY(90px);
}

.csstransforms .vcard:nth-of-type(2) {
transform: translate(150px, 60px);
}

.csstransforms .vcard:nth-of-type(3) {
transform: scale(1.1) translate(144px, 55px);
}
Look carefully and you’ll notice that in that last example, we combined two transform values into a single declaration. To set multiple values, string them together and separate each with a space. A browser applies these transforms in order — reading from the left.

The space you see between the first and second cards is a perfect spot into which we can position the fourth and final card.

Transform ‘rotate’
We can rotate an element between 0 and 360 degrees (clockwise) and even use negative values to rotate an element counterclockwise. The syntax is quick to learn. First, declare the rotate value, then the angle inside parentheses. The fourth card’s artwork has a portrait orientation whereas all others are landscape. Fix this by rotating that errant card ninety degrees clockwise (90deg), scale it by 10% (1.1) and finally move it into position by translating it down 20px and left 630px:

.csstransforms .vcard:nth-of-type(4) {
transform: scale(1.1) rotate(90deg) translate(20px, 630px);
}

Embracing the natural differences between browsers
No two browsers are the same, so to make the most from emerging technologies such as HTML5 and CSS3, we need to banish the notion that websites should look and be experienced exactly the same in every browser. We should design around browser differences instead of hacking around them. That will likely mean that designs will look different — sometimes very different — across browsers.

To make this simple alternative, adjust each card’s margins to float them into a simple grid.

.no-csstransforms .vcard {
margin: 0 20px 20px 0;
}

How adventurous your alternatives are depends on you, your clients, and the project you’re working on. Be under no illusion though: CSS3 selectors and properties give us the power to create designs that are tailored to browsers of all capabilities. With this variety comes new opportunities to show our creative skills and new opportunities for business. It’s time to grab those opportunities with both hands.

Author of Hardboiled Web Design, Andy Clarke is a seasoned brand steward, a fancy pixel wrangler, and no mean hand at code. A triple talent. The bastard.

37signals Product Blog: We’ll be retiring our support of OpenID on May 1. The support costs far outweighed the benefits to customers, especially now that 37signals have their own single sign in mechanism that works across all of their products.

Handy when developing mobile-optimized layouts. (I’m using it now, to investigate a recent problem where DF looks way too small, sometimes, on the iPad.)

 ★ 

Among the speculation and hints on the forum about the direction of TXP 5, we thought it was about time to open the envelope and reveal all.

And the nominations are…

First of all, we would like to welcome Jeff Soo as a core developer. Jeff has been an avid plugin writer, patcher and Txp tester for a while now and brings a wealth of programming knowledge and skill to the team. And, as you know from his forum posts, he’s a jolly fine man. We’re very much looking forward to working with him.

Best Picture

Secondly, we have decided to take the huge step of modernising the core from its humble origins into a 21st century application. Namely, utilising the MVC (Model View Controller) pattern.

Over the last eighteen months, Sam has been very busy creating his own CMS (Escher) from the ground up, which is built on a custom, lightweight MVC framework called Spark/Plug. We are going to adopt Spark/Plug for Textpattern and build on its considerable, yet slender, shoulders. If you’re curious to learn more about Spark/Plug and Escher, feel free to visit Sam’s Spark/Plug site and/or Escher site.

Best Performance

To anyone who’s shrugging / shaking their head in bewilderment, the benefits of modernising Textpattern’s core code include, among other things:


greater flexibility/extensibility
more power to plugins
increased performance via public-side cacheing
public-side templating/theming


And Spark/Plug will accelerate our ability to do all of the above. We’re pretty excited about what this means for Txp as a platform. But there’s a catch.

Uh-oh. A catch?

Yes. It’s a lot of work. And all the while we’re moving the codebase across to the new framework, it may seem like little is happening in terms of the end-user features we all want. Especially given that we don’t have infinite time to devote to our beloved CMS between day jobs and life.

Best Direction

We agonised for ages on how to approach this before reaching the following plan.


Txp 5 will be developed in phases:

The admin side will be moved across to Spark/Plug.
A compatibility layer will be built to help plugins, templates and sites work under the new framework. Plugin authors can then adjust their code to fit the new paradigm and the layer will eventually be removed.
The admin side will be given a facelift to improve workflow.
The public side will be migrated to Spark/Plug, along with a new default template.

The dev workload will be split:

Robert (primarily) will continue to drive new features into the existing codebase ready to move the application across when the framework is ready.
Sam, Jeff and Stef will work on migrating to Spark/Plug and putting the compatibility layer in place.



This is going to be a pretty major undertaking, and we would like your help. To that end, we will be moving to Mercurial for Txp 5 and later. We are looking for as many people as possible to help us transition the codebase to Spark/Plug and encourage you to clone the repo and publish your contributions so we can rapidly merge them into the core. The quicker we can do this part, the sooner we can fold Robert’s work into Txp 5 and start adding the new features you’re all asking for.

Sam will be posting a quick howto for accessing the new repo in the near future, so watch this space.

Best community

We really would like this to be a true community effort. We’ll co-ordinate things from here and the forum, and regularly publish who’s doing what to minimise duplication of effort.

So if you’re interested in taking our little CMS from the shadows of historical review into the bright light of tomorrow, please get in touch, get involved and get coding. Thanks!

Brett Smith, for the Free Software Foundation:

We applaud Google for this change; it’s a positive step for free
software, its users, and everyone who uses the Web. For a while
now, watching video on the Web has been fraught with peril. Most
of it is delivered with Flash, which is proprietary, nonstandard
software. Free software alternatives like GNU Gnash are
available, but the user experience isn’t always as seamless as it
ought to be.

To say the least.

In order to make sure the Web stays free for everyone, we need a free codec to prevail as the de facto standard with HTML5. WebM can be that codec: Google provides a patent license with the standard that is compatible with free software licenses, and even got the development ball rolling by releasing a free implementation.

All it takes now is for everyone to switch entirely to free software. Easy.

Some reaction to Google’s move has suggested that it represents a
step back for standards on the Web, because H.264 is supported by
more hardware and software. Those comments represent a fundamental
misunderstanding of the vision of the Web as free and
unencumbered. We can only be free if we reject data formats that
are restricted by patents.

This paragraph represents a fundamental misunderstanding that standards and freedom aren’t the same thing.

Today, we’re also urging Web site operators to distribute videos
in the WebM format, and abandon H.264.

Free beards for everyone.

 ★ 

Today (Jan 19, 2011) is Boycott a Meeting Day
Just say NO to meetings. Every minute you avoid spending in a meeting is a minute you can get real work done instead. Click the button to show solidarity with the anti-meeting movement!

Before I get started with the topic this week, it appears I need to make a clarification on the purpose of this blog.  As with my Production Guides, this blog’s only purpose is give me somewhere to voice my thoughts on different topics.  I’m not trying to say my ideas or working methods are the ...

Inspired by my friend Peter who writes summaries about the ongoing progress with WebKit I thought I should try writing such a summary about the WHATWG. If this works out you might see another one. Obviously a lot has been happening thus far so to not make this ridiculously hard I will restrict myself to everything that happened fairly recently.

Aryeh Gregor took it upon himself to write a specification for window.btoa and window.atob. These methods originate with Gecko and have been adopted by other browsers since, but have never been formally specified. This also explains why implementations are different. If you want to help out standardizing something take a look at companion specifications on the WHATWG Wiki.

The device element (see What’s Next in HTML, episode 1) continues to be discussed on the mailing list (subscribe). Though from sharing a video/audio stream the focus in the discussion has shifted towards allowing applications to interact with non-typical hardware and the implications to security thereof. Consider attaching certain sensors to your computer or maybe your model train set and wanting to interact with it directly from a web application without having to install plugins of any kind.

Web Workers and the DOM was discussed to quite some extent on the mailing list. Evidently developers want more out of Web Workers and are running into limitations. Web Workers do not have access to a DOM, because existing DOM implementations are not thread-safe. Various threads on the mailing list are about overcoming this hindrance.

Silvia Pfeiffer who apparently has been contracting for Google recently (congrats!) wrote a lengthy email: Google Feedback on the HTML5 media a11y specifications. I.e. feedback on WebVTT — the WHATWG way of doing captions — and the new track element. Mark Watson with Netflix wonders how captioning will work in an adaptive streaming context.

It does not stop here. Really:

There was a long thread on frame accuracy in HTML5 video.
Ryosuke Niwa provided use cases for having an API that makes it easier for applications to provide their own Input Method Editor.
Benjamin Hawkes-Lewis suggests a better reference for Windows 949.
Mikko Rantalainen gave input into how the required attribute ought to work when applied to radio controls.
Marijn Haverbeke requested control over selection direction
Aryeh Gregor gave feedback on Web DOM Core — a new attempt to get DOM Core to reflect reality.
Emiliano Martinez Luque wrote a lengthy email containing feedback on Microdata. Mark Pilgrim wrote a chapter in his HTML5 book on Microdata in case you are curious about it: “Distributed,” “Extensibility,” & Other Fancy Words.

Have a good week!

He’s downright giddy:

The VIDEO tag was simply not well-considered at the outset. Its
original rationale was: “You don’t require a plug-in to view
images… video is the next natural evolution of that.” But from
the very start the practical questions about use were swept under
the rug… at least until the rug started piling up too high. It
wasn’t sustainable.

So, (a) he thinks Chrome just killed the HTML5 <video> element.

Video publishers need the VIDEO tag for one purpose only: to
support Apple’s non-standard HTML browser and its denial of
third-party extensibility via APPLET, OBJECT, and EMBED.

And (b) Dowdell thinks <video> is needed only for iOS devices, and (c) that MobileSafari is non-standards-compliant because it doesn’t support plugins like Flash. I.e. Flash is standard, <video> is not, and we’ve always been at war with Eurasia.

(a) Might be true, (b) obviously is not, and (c) is pretty much the craziest thing I’ve read in a while.

But: we have an answer to my question about who’s happy about Chrome dropping H.264 support.

 ★ 

Ryan Naraine:

Zero Day blogger and malware researcher Dancho Danchev has gone
missing since August last year and we have some troubling
information that suggests he may have been harmed in his native
Bulgaria. […]

Last month, we finally got a mysterious message from a local
source in Bulgaria that “Dancho’s alive but he’s in a lot
of trouble.” We were told that he’s in the kind of trouble to
keep him away from a computer and telephone, so it would be
impossible to make contact with him.

 ★ 

Marco Arment makes the case that the plethora of Android devices has numerous downsides. One point of several:

The manufacturers and carriers have very little incentive to
maintain the software on devices that are still relatively new and
under contract, because they want everyone buying the newest ones
instead. We’re already seeing carriers and some manufacturers
refusing to release new Android versions to handsets that were
launched as recently as 6 months ago, even though most users
bought them with 2-year contracts.

He also mentions the lack of cases for any individual Android phone, compared to the iPhone, where there are just two form factors covering the last three years of iPhones: 3G/3GS, and 4. Update: Maybe two-and-a-half form factors, given the slightly different positioning of the mute toggle on the just-announced CDMA iPhone 4. But still.

 ★ 

Getting Started—Google URL Shortener API. The API for the goo.gl URL shortener is really nice—no API key required, easy to create a short URL and you can retrieve detailed stats breakdowns (similar to bit.ly) as JSON for any URL.

“Znu”, on Slashdot:

This serves two strategic purposes for Google. First, it advances
a codec that’s de facto controlled by Google at the expense of a
codec that is a legitimate open standard controlled by a
multi-vendor governance process managed by reputable international
standards bodies. (“Open source” != “open standard”.) And second,
it will slow the transition to HTML5 and away from Flash by
creating more confusion about which codec to use for HTML5 video,
which benefits Google by hurting Apple (since Apple doesn’t want
to support Flash), but also sucks for users.

Don’t be evil.

 ★ 

Captured from Twitter, here is Tom Henrich’s partial reconstruction of my conversation with Tantek Çelik, Glenda Bautista, Andy Rutledge and others on the merits of self-hosting social content and publishing to various sites rather than aggregating locally from external sources.

via Own Your Data / technophilia

David made a comment on Twitter about some markup he was working on:

Feels dirty setting id’s on main HTML5 page header and footer, but overriding inheritance they cause seems needlessly laborious.

I know the feeling. I don’t like using IDs at all, unless I want part of a document to be addressable through the fragment identifier portion of the URL. While I think it’s desirable to use the id attribute to create in-document permalinks, I don’t think it’s desirable to use the id attribute just as a styling hook. Its high specificity may seem a blessing but, in my experience, it quickly leads to duplicated CSS. IDs are often used as a substitute for understanding the cascade.

Nicole feels the same way about ID selectors, and she knows a thing or two about writing efficient CSS.

Back to David’s dilemma. Let’s say you’re targetting header and footer elements used throughout your document in sections, articles, etc. All you need to use is an element selector:

header {
// regular header styles
}

But what about the document-level header and footer? They’re probably styled very differently from the headings of sections and articles.

You could try using a child selector:

body > header

But there’s no guarantee that the document header will be a direct child of the body element. Hence the use of the id attribute—header id="ID":

header#ID {
// page header styles
}

There is another way. In HTML5 you can, for the first time, use ARIA roles and still have a valid document. ARIA landmark roles add an extra layer of semantics onto your document, distinguishing them as navigational landmarks for assistive technology.

Some of these landmark roles—like IDs—are to be used just once per document:

Within any document or application, the author SHOULD mark no more than one element with

banner
main
contentinfo

That’s useful for two reasons. One, the existence of role="main" means it is not necessary for HTML5 to provide an element whose only semantic is to say “this is the main content of the document.”

A lot of people have asked for such an element in HTML5. “We’ve got header, footer and aside,” they say. “Why not maincontent too?”

But whereas header, footer and aside can and should be used multiple times per document, a maincontent element would, by necessity, only be used once per document. There are very few elements in HTML that are like that: the html element itself, the title element, head and body (contrary to popular opinion—likely spread by SEO witch-doctors—the h1 element can be used more than once per document).

Now the desired functionality of semantically expressing “this is the main content of the document” can be achieved, not with an element, but with an attribute value: role="main".

The rough skeleton of your document might look like this:

<header role="banner"></header>
<div role="main"></div>
<footer role="contentinfo"></footer>

Now you can see the second advantage of these one-off role values. You can use an attribute selector in your CSS to target those specific elements:

header[role="banner"] {
// page header styles
}

Voila! You can over-ride the default styling of headers and footers without resorting to the heavy-handed specificity of the ID selector.

And, of course, you get the accessibility benefits too. ARIA roles are supported in JAWS, NVDA and Voiceover

Tagged with
html5
css
aria
accessibility
standards
semantics

Indexes are critical to good performance. However many people don't understand how indexes well. MVP Gail Shaw provides us with an introductory article on the basics of indexing.

HERE’S A REALITY check for those of us who can’t believe fax machines are still necessary in 2011. I have just learned, to my astonishment, that half the lawyers in New York create their documents in WordPerfect. That is not a typo.

The version of WordPerfect they use saves in its native format. It can also save as RTF, but it loses formatting when it does so. It can save as a particular version of Word ’97 for Windows which is not compatible with other platforms, and which also loses formatting. And it can save as ASCII, because, well.

If the lawyer wishes to preserve the document’s formatting while saving a copy for someone (say, a client) who doesn’t own WordPerfect and hasn’t seen it since DOS ruled, said lawyer and said client are out of luck.

But what of PDF, you ask?

There is no option to save as PDF. Maybe Adobe charged a licensing fee that the makers of WordPerfect weren’t able to afford (hampered as they are by the fact that nobody besides New York lawyers buys their product). Or maybe the makers of WordPerfect died before PDF became ubiquitous.

Advanced Windows users can probably finagle a PDF out of WordPerfect, say, by buying Adobe Acrobat Pro and installing a plug-in, but the lawyers in New York do not seem to be advanced Windows users.

Oh, also, IE6 is the cat’s pajamas in this world. Twenty-three skidoo!

And you ask why we still use fax machines.

As I continue to use Twitter, I find I have more to say about it.  I’ve collected some additional thoughts below.

But first, the elephant in the room is of course Gruber’s response to my original post.  In a nutshell, he says that yes, OS X is changing, and Apple is the banner-bearer for that change by themselves discarding the HIG and forging individual UIs for each of their apps.

This change is indisputable, and it is no doubt effected by (or at least affected by) the Web.  Gruber’s piece is largely agnostic regarding where he stands on this matter, as I suspect his opinion on the matter may still be nascent.  Personally, I do not deny that applications like Twitter are beautiful; the problem is they can also be inconsistent and confusing to use. (Twitter certainly is at times.)

Apple makes it very easy to make an application that behaves as you would expect; all you have to do is use the existing Cocoa UI elements as intended.  Usability comes free.  The curiosity for me is when designer/developers exert time and effort rewriting UI elements from scratch, merely to make them look differently from the Aqua UI.  Now the onus is on the developer to replicate the behavior of the UI element he is approximating — and it’s hard to get all the details right, which means few developers do.

For example, consider how the Twitter app handles the process of clicking a button, holding the mouse button down, and moving the mouse.  You will find one of four different behaviors:

If you do this over a sidebar or toolbar button (such as those in a user detail view), the button highlights briefly, then deactivates, allowing you to move the window.
If you do this over a “stoplight” button, the button does not deactivate, but remains highlighted, but moving the mouse moves the window.
If you do this over a button on the bottom bar (e.g., the Follow/Unfollow button in a user detail view) or in the main view, the window does not move, and the button remains active.
Worse is that the top, side and bottom bars are all draggable areas allowing you to move the window, but click-holding on buttons to drag the window works only in the top and side views.

Most, but not all buttons highlight when you click-hold on them.  The Reply buttonlets next to DMs, the delete buttons next to saved searches, and the avatars next to tweets are all buttons that give you no feedback when the mouse is clicked on them.

Most buttons, when clicked, will darken or brighten, but clicking the More Actions button on a user profile view or the clear button in the search field causes the button to lighten instead, a look I find more appropriate for the disabled state.

In my mind, the worst offender among buttons is the Follow/Unfollow button.  You may not even recognize it as a button at first: If you are viewing the detail page of someone whom you follow, a “Following” — I’m not sure what to call it, so I’ll call it a state indicator — is displayed on the left of the bottom bar.  (This state indicator is not to be confused with an activated button, which it appears deviously similar to.)

Hovering over the “Following” indicator reveals that it is in fact a button that you can use to un-follow the Twitter user.

It took me a matter of minutes to figure this one out.  I suppose I don’t see what’s wrong with doing something more like this:

It’s not like the horizontal space is being used for anything else.

I mentioned the pitfalls of the “stacking” UI concept in my previous post, and upon further use I discovered that some views slide in from the left (toolbar buttons), whereas others slide in from the right (search results).  This isn’t such a huge deal until you consider that the “close” button for the latter views (which, in Web tradition, is actually a “go back” breadcrumb) is an arrow pointing to the left:

If you click the left-facing arrow, the view unexpectedly slides out to the right.  The root of the problem is that the “stacking” UI concept doesn’t jive with the “tree” navigation that you’re actually performing.

Twitter could also be more consistent in how it portrays drop-downs.  As a Mac user I am conditioned to expect a drop-down when I see a down-facing arrow, as used in the “more actions“ button at the bottom-right of the main window:

However, the “more actions” button in the user detail page looks, for all intents and purposes, like a normal click-to-action button.  It is, however, a drop-down:

The purpose of laying out these nitpicks is two-fold: First, if Loren Brichter happens to read this, maybe he’ll agree with me on some points and implement fixes.  Second, the purpose is to show that good design and good UI are two separate things.  The classical way of thinking is that good design and good UI coincide: Design to the HIG and it will both look good and feel right.  With the push for individuality (as Gruber puts it), the way we design applications for the Mac falls apart.  Developers are forced to rewrite UI functionality which causes gaps and inconsistencies in behavior.

The way I see it, there are two solutions to this problem: You can give up your individualized UI in exchange for the comfort of the tried-and-true Aqua interface (unacceptable to the “new generation” of Mac developers), or we can change the way user interfaces are developed on the Mac.  Perhaps it’s time that Cocoa got a solid, full-featured skinning layer on top of the UI toolkit, so that appearance and behavior are finally separated in the Application Toolkit APIs?

If you use FeedBurner to handle your RSS/Atom/whatever feed, make sure to subscribe to it so you can verify that your posts show up properly. Also follow the links to your posts to check the URLs – they may be a bit mangled by FeedBurner without you knowing it.

It’s probably been like that for a long, long time, but I only recently noticed that FeedBurner added a bunch of querystring parameters (utm_source, utm_medium, and utm_campaign) that I wasn’t aware of to the post URLs in my feed. So instead of http://www.456bereastreet.com/archive/201011/bye_bye_flash/ URLs would look something like this:

http://www.456bereastreet.com/archive/201011/bye_bye_flash/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+456bereastreet+%28456+Berea+Street%29

Ouch.
Read full post
Posted in Search Engine Optimisation, Usability.
Jobs from Authentic JobsWeb Developer at O'Melveny & Myers LLP (San Francisco, CA, US)FRONT-END DEVELOPER at Hanson Inc (City of Maumee, OH, US)Marketing Coordinator at The First Rehabilitation Life Insurance Company of America (Great Neck, NY, US)

Kyle Baxter on Google’s motivations for Android:

Google isn’t a web application company—they’re an advertising company. That’s what they do best, and that’s what drives their company. Of Google’s $23.6 billion of revenue in 2009, all but $760 million of it was derived from advertising, and nearly 70 percent of it was from Google’s own websites.

Everything Google does must be understood within this context.

 ★ 

Continuing where I left off yesterday, the latest round of "RSS is dead" articles is partly the result of this post by Kroc Camen which claims that RSS is in trouble because browser vendors are failing to make RSS usable.
While I don't see this as any real threat to RSS, I do agree that browsers do a poor job handling RSS.  But I would argue that browsers shouldn't try to be RSS readers, any more than they should try to be email clients.  I'm obviously biased here since I develop FeedDemon, but I'm far from the only one who doesn't need their browser to be a full-fledged RSS reader. 
I might think otherwise if any major browser vendor was visionary enough to "bake" RSS reading into the entire browsing experience and make it an equal partner to reading HTML.  As Camen says:
Why do we go through the same daily routine of checking certain sites over and over again? Can’t our computers be more intelligent here? Isn’t the purpose of the computer / browser to save us time!? Why doesn’t the browser, when you open it, tell you how many new items there are, on what sites you commonly visit, without you having ever configured this? That's certainly a web browser I would use, but I don't see it happening.  Browser vendors consider reading RSS to be too much of a niche activity to re-design their products around it.  (Aside: this is why I use FeedDemon as my primary browser - it's a full-fledged web browser that has RSS baked into it.)
Since browser vendors are unlikely to substantially improve the RSS reading experience, I think they should drop it entirely, but at the same time they should make the benefits of RSS accessible to less tech-savvy users.  Browsers are being extolled as platforms these days, so how about making these platforms more helpful when dealing with different types of content?
Provide obvious RSS auto-discovery and perhaps basic RSS viewing, and make it easy to subscribe to feeds in an external RSS reader.  Just as clicking a mailto: link opens your email client, clicking a feed link/icon should open your RSS reader (regardless of whether it's desktop- or web-based).
If the user doesn't have an RSS reader, don't simply show a cryptic error message that says there's no associated application, or the MIME type isn't recognized.  Provide some basic info about what RSS reading is.  Some browser vendors could go a step further and link to the RSS reader category in their app stores.
Browsers don't need to provide image editing features just because they can display images, but they do need to make it easy to copy or save the images so they can be opened in whatever application you like.  Likewise, browsers don't need to offer RSS reading features just because they can detect RSS - they just need to make people aware of RSS, and make it easy for them to use an RSS reader.

Let's look at where stackoverflow.com traffic came from for the year of 2010.



When 88.2% of all traffic for your website comes from a single source, criticizing that single source feels … risky. And perhaps a bit churlish, like looking a gift horse in the mouth, or saying something derogatory in public about your Valued Business Partnertm.

Still, looking at the statistics, it's hard to avoid the obvious conclusion. I've been told many times that Google isn't a monopoly, but they apparently play one on the internet. You are perfectly free to switch to whichever non-viable alternative web search engine you want at any time. Just breathe in that sweet freedom, folks.

Sarcasm aside, I greatly admire Google. My goal is not to be acquired, because I'm in this thing for the long haul – but if I had to pick a company to be acquired by, it would probably be Google. I feel their emphasis on the information graph over the social graph aligns more closely with our mission than almost any other potential suitor I can think of. Anyway, we've been perfectly happy with Google as our de-facto traffic sugar daddy since the beginning. But last year, something strange happened: the content syndicators began to regularly outrank us in Google for our own content.

Syndicating our content is not a problem. In fact, it's encouraged. It would be deeply unfair of us to assert ownership over the content so generously contributed to our sites and create an underclass of digital sharecroppers. Anything posted to Stack Overflow, or any Stack Exchange Network site for that matter, is licensed back to the community in perpetuity under Creative Commons cc-by-sa. The community owns their contributions. We want the whole world to teach each other and learn from the questions and answers posted on our sites. Remix, reuse, share – and teach your peers! That's our mission. That's why I get up in the morning.

However, implicit in this strategy was the assumption that we, as the canonical source for the original questions and answers, would always rank first. Consider Wikipedia – when was the last time you clicked through to a page that was nothing more than a legally copied, properly attributed Wikipedia entry encrusted in advertisements? Never, right? But it is in theory a completely valid, albeit dumb, business model. That's why Joel Spolsky and I were confident in sharing content back to the community with almost no reservations – because Google mercilessly penalizes sites that attempt to game the system by unfairly profiting on copied content. Remixing and reusing is fine, but mass-producing cheap copies encrusted with ads … isn't.

I think of this as common sense, but it's also spelled out explicitly in Google's webmaster content guidelines.

However, some webmasters attempt to improve their page's ranking and attract visitors by creating pages with many words but little or no authentic content. Google will take action against domains that try to rank more highly by just showing scraped or other auto-generated pages that don't add any value to users. Examples include:

Scraped content. Some webmasters make use of content taken from other, more reputable sites on the assumption that increasing the volume of web pages with random, irrelevant content is a good long-term strategy. Purely scraped content, even from high-quality sources, may not provide any added value to your users without additional useful services or content provided by your site. It's worthwhile to take the time to create original content that sets your site apart. This will keep your visitors coming back and will provide useful search results.

In 2010, our mailboxes suddenly started overflowing with complaints from users – complaints that they were doing perfectly reasonable Google searches, and ending up on scraper sites that mirrored Stack Overflow content with added advertisements. Even worse, in some cases, the original Stack Overflow question was nowhere to be found in the search results! That's particularly odd because our attribution terms require linking directly back to us, the canonical source for the question, without nofollow. Google, in indexing the scraped page, cannot avoid seeing that the scraped page links back to the canonical source. This culminated in, of all things, a special browser plug-in that redirects to Stack Overflow from the ripoff sites. How totally depressing. Joel and I thought this was impossible. And I felt like I had personally failed all of you.

The idea that there could be something wrong with Google was inconceivable to me. Google is gravity on the web, an omnipresent constant; blaming Google would be like blaming gravity for my own clumsiness. It wasn't even an option. I started with the golden rule: it's always my fault. We did a ton of due diligence on webmasters.stackexchange.com to ensure we weren't doing anything overtly stupid, and uber-mensch Matt Cutts went out of his way to investigate the hand-vetted search examples contributed in response to my tweet asking for search terms where the scrapers dominated. Issues were found on both sides, and changes were made. Success!

Despite the semi-positive resolution, I was disturbed. If these dime-store scrapers were doing so well and generating so much traffic on the back of our content – how was the rest of the web faring? My enduring faith in the gravitational constant of Google had been shaken. Shaken to the very core.

Throughout my investigation I had nagging doubts that we were seeing serious cracks in the algorithmic search foundations of the house that Google built. But I was afraid to write an article about it for fear I'd be claimed an incompetent kook. I wasn't comfortable sharing that opinion widely, because we might be doing something obviously wrong. Which we tend to do frequently and often. Gravity can't be wrong. We're just clumsy … right?

I can't help noticing that we're not the only site to have serious problems with Google search results in the last few months. In fact, the drum beat of deteriorating Google search quality has been practically deafening of late:

Why We Desperately Need a New (and Better) Google
Dishwashers, and How Google Eats Its Own Tail
Content Farms: Why Media, Blogs & Google Should Be Worried
On the increasing uselessness of Google
Google, Google, Why Hast Thou Forsaken the Manolo?

Anecdotally, my personal search results have also been noticeably worse lately. As part of Christmas shopping for my wife, I searched for "iPhone 4 case" in Google. I had to give up completely on the first two pages of search results as utterly useless, and searched Amazon instead.

People whose opinions I respect have all been echoing the same sentiment -- Google, the once essential tool, is somehow losing its edge. The spammers, scrapers, and SEO'ed-to-the-hilt content farms are winning.

Like any sane person, I'm rooting for Google in this battle, and I'd love nothing more than for Google to tweak a few algorithmic knobs and make this entire blog entry moot. Still, this is the first time since 2000 that I can recall Google search quality ever declining, and it has inspired some rather heretical thoughts in me -- are we seeing the first signs that algorithmic search has failed as a strategy? Is the next generation of search destined to be less algorithmic and more social?

It's a scary thing to even entertain, but maybe gravity really is broken.



[advertisement] JIRA Studio - SVN hosting, issue tracking, CI and Google Apps integration. Free trial »

RSS is Dying and You Should Be Worried -- If RSS dies, we lose the ability to read in private.
What Could Have Been Entering The Public Domain on January 1, 2011? -- a list of the works that won't be entering the public domain in the US because the copyright term was extended in 1976. Think of the movies from 1954 that would have become available this year. You could have showed clips from them. You could have showed all of them. You could have spliced and remixed and made documentaries about them. (You could have been a contender!) Instead, here are a few of the movies that we won’t see in the public domain for another 39 years .... This list will be viewed two different ways by different groups, reinforcing instead of changing their views: copyright minimalists will say "what a tragedy" but copyright maximalists will say "look at these great works we protected, they're still earning money for their creators therefore they're still valuable and thus worth protecting". (via Bill Bennett on Twitter)
ProxClone -- cloner for proximity cards, cost of parts around $30. (via Hacker News)
2011 Is The Year of Server-Side Javascript -- explanation of why the author will be doing back-end coding in Javascript this year. Good to see an honest assessment that it's still early days for server-side Javascript: Most of the libraries out there are young, buggy and incomplete. I got Node.js to segfault a few times. There’s no killer framework on the same caliber as Rails, nor anything that comes close to ActiveSupport and a decent standard runtime library (hmm … that gives me an idea). But then, it’s not much different than what Ruby was five years ago, or Java back in the late 90′s. We’ve all got to start somewhere.

Methinks the alarm system in iOS is in need of a good code auditing.

 ★ 

Addy Osmani has compiled a large collection of resources for developers building large-scale JavaScript applications with jQuery. We've already mentioned JavaScriptMVC and how it can be used to break JavaScript applications into smaller, testable components in the past, but Osmani provides many more resources. Osmani recommends JavaScriptMVC but mentions several alternatives and components you can use to roll your own toolkit.

Sponsor

The resources are organized into the following sections:

Dependency Management
MVC & Organization For Large-Scale jQuery Applications
Templating
Communication Between Modules
Build Process & Script Concatenation
Script Minification
Testing

Discuss

Pretty cool hack

Our new office has a dishwasher. It’s sleek, modern, and silent. It blends into the stainless cabinets and countertops just perfectly. It has the same handle style as the drawers and doors to the left and right. It has no buttons or lights or anything on the outside. You don’t even know it’s there.

And this is why it’s bad.

This is it, right there in the middle:



Looks great, right? Well that depends.

At least once a week when I open it up to add a dirty cup or plate I get sprayed. Water shoots out the sides and splashes me and the floor. It’s on, but there’s no indication it’s on. It’s so good that you can’t even hear it. That’s actually bad. It’s so integrated that it doesn’t look like a dishwasher. That’s actually bad.

I used to curse it, but now I’ve made peace with it. I actually like having it around. Every time I see water on the floor, or on my shirt, I’m reminded of the subtle differences between good and bad design.

Subtle because sometimes all it takes is the smallest little thing to turn bad to good (or good to bad). A tiny bright LED light in the upper right corner could indicate ON. When the light’s on, don’t touch. When’s its off you don’t even see it. It doesn’t interfere with the overall design. That little light would make everything else — the visual design, the silence, the integration with the rest of the kitchen — worth it.

Or it could lock when it’s on, unlock when it’s off. You wouldn’t be able to unlock it once it’s on because there’s no exterior lock handle, but that seems like a small sacrifice to stay dry.

Or…

A quick WordPress tip regarding Custom Post Types: when giving a custom post type a name, make sure that its length is 20 characters or less, or weird things will happen.

I recently ran into this and spent way too much time trying to figure out why things weren’t working as expected. For some reason the “Publish” button on the “Add New” page for my custom post type was replaced by a “Submit for Review” button. Huh?

At first I thought the problem was related to permissions, but it turned out to be the length of the name I’d given my custom post type.
Read full post
Posted in WordPress.

There Is No Such Thing as the Government -- absolutely spot on there is no spoon moment for government. And that matters. It matters because once you recognise that fact, you can start to do things differently. People do, of course, recognise it at the level of caricature I have described here and nobody will admit to believing that they can get things done simply by pulling the levers of power. But inactions speak louder than words and the myth of the lever is harder to eradicate than any of us like to admit.
The Blast Shack (Webstock) -- Bruce Sterling on Wikileaks. No hacker story is more common than this. The ingenuity poured into the machinery is meaningless. The personal connections are treacherous. Welcome to the real world. No army can permit this kind of behavior and remain a functional army; so Manning is in solitary confinement and he is going to be court-martialled. With more political awareness, he might have made himself a public martyr to his conscience; but he lacks political awareness. He only has only his black-hat hacker awareness, which is all about committing awesome voyeuristic acts of computer intrusion and imagining you can get away with that when it really matters to people.
Word Lens -- finally, useful AR: it replaces foreign language text with translations.
Staging Servers, Source Control, Deploy Workflows, and Other Stuff Nobody Teaches You -- this guy has a point: when you emerge from programming school, you're unlikely to have touched this kind of real-world programming.

I liked a YouTube video: Subsonic - The Noise Of 'The Axis Of Evil'

Noise Version of our Club Hymn in Second Life :)
All tight rights belong to me and myself, ha! :p

Music is done with Skale Tracker.
The Computer Voice is done with Cepstral's text-2-speech
The video is ...

Short Review

ATV2 may lack support for playing any video codecs other than mp4’s, and any apps/expandability, but it’s bloody good at what it does do. It’s tiny, inexpensive, silent and doesn’t even get warm. It streams far smoother than I expected it to. I absolutely love it, and may have to get another one for another room.

Long Review

Yeah, I couldn’t resist. I got an Apple TV 2 as well. If you’re bored of all this, imagine how my wife Leigh must be feeling!

My main fear about using this as my Media Centre, was that it required a Mac running to serve the files, and where those files could be stored. Computers will never have enough space to store everything I need, and I’d rather that I stored them on a RAID drive so that I don’t lose everything when a HD fails.

As it turns out, I can stream just about any content from NAS to iMac to Apple TV. The NAS stores all the media, iTunes on the iMac accesses it from there, and serves it to the Apple TV, all over N wifi. It sounds (and is a bit) clunky but streams brilliantly. I expected stuttering and buffering over such a setup, but there wasn’t. It buffers for a few seconds before playing, but once it’s going, it’s flawless. Very impressive! Only on large 1080p content did it have a couple of hiccups (I know ATV can only output 720p, but it does accept 1080p input and I wanted to test a big file) but still not enough to spoil the movie.

The hardware is non-descript compared to the Boxee Box, but it’s tiny, silent and runs cold! The opposite of my PS3 basically. I also own the 1st generation Apple TV, which while quiet, was large and hot enough to fry eggs on.

The ATV interface itself is pretty bland and unexciting, but at least its inoffensive, (unlike the current Boxee). Besides, the best interface for the ATV2 is actually the remote app for iOS devices. It now lists all the iTunes Libraries and their content on the network, so you can play all your files using the remote without ever having to use the UI. This is especially useful if you want to play music without having the TV on. Unlike ATV1, sharing is setup by turning on Home Sharing, rather than inputting a passcode to pair it – so much easier. Also, the decision to stream, rather than store and sync on the limited ATV1 hard drive, turns out to be very wise. While you can’t purchase directly from the ATV, it does remove the doubt of whether something has synced or not.

Airplay works as well as advertised, and if it’s enabled for third party apps (as Steve himself has apparently promised) that opens up things like BBC iPlayer too. In general though, Airplay feels like a bit of Red Herring at the moment. Native apps would still be better in most use cases. Handy if you’re watching a movie on the iPad, and then want to finish it off in the living room. AirFlick looks like a promising addition in this area, allowing streaming from Mac to ATV.

More functionality is going to be added by Firecore with their ATV Black hack to add a browser and Plex Client. Be warned though – what the product page conveniently doesn’t tell you is that you need to jailbreak your ATV first, and at the time of writing, there isn’t an updated pwnage tool that works with the latest version (ATV 4.1, which is iOS 4.2.1). My experience with a hacked ATV1 wasn’t great, it wasn’t very stable and felt like more trouble than it was worth. Hopefully ATV Black will change this.

Downsides


No support for codecs like mkv or disk images (.iso’s and .img’s). ATV Flash may yet solve that.
The UI is bland and unexciting (but inoffensive, and with the remote app and Airplay, you needn’t really look at it all that much)
I’d still prefer to go to ‘Movies’ rather than ‘Computers > iMac > Movies’.
The ‘TV Shows’ menu item is missing in the UK, as we don’t have any TV Shows to rent yet. Obviously Netflix won’t work in the UK either.
iTunes Extras don’t work on the Apple TV2 (but did on 1st generation) which is very odd. Surely these will be available in a future update?


There is perhaps one more downside. Buying DRM’d Movies and TV Shows from iTunes is a whole lot more convenient than ripping and handbraking DVDs or Blu-Rays. The Apple TV2 just gives more more motivation to do that, especially when it scratches the ‘quick, we need a new movie to watch RIGHT NOW’ itch.

As for the advantages:


Streaming local media quality is excellent, and Airplay will be a winner when third party apps can access it
Streaming rented movies works well
YouTube app is what the Boxee Box app should’ve been like
Remote App makes it possible to choose any content from any iTunes library on the network
The Podcasts app allows you to store favourites, allowing easy access to all sorts of online content like Onion News and The Big Web Show.


If you already have the 1st generation ATV, you may be wondering why you want this one? After all you can’t store anything on it, and it’s rental-only – no other purchases. Well, dramatically better streaming (presumably due to N wireless card, rather than just G), easier operation (no syncing) and the whole smaller and colder thing.

As the saying goes, your mileage may vary, but is it ‘the one’ for me? It might just be! In the last few weeks I’ve had the PS3, Boxee Box and Apple TV all set up. When I want to watch something, or listen to music, I’m finding it’s the ATV that I go to instinctively. The PS3 is still in use for iPlayer, 4oD, DVDs and BluRays (and gaming of course), but the Boxee Box doesn’t get a look in. This might have been different if the v1.0 Boxee firmware wasn’t such a downgrade from 0.9. It still might be different with future Boxee updates, but at the moment, it’s the Apple TV 2 that I’m glad I bought.


Tagged: appletv,
geekmediabox,
mediacentre

Must-read for developers. Both a good high-level overview of what accessibility really means and who it helps, and a technical overview of how iOS developers can take advantage of it. iOS is simply leaps and bounds ahead of the competition in accessibility.

 ★ 

In a post last week about lessons learned using Amazon Web Services, Netflix's John Ciancutti revealed that the company built something called "Chaos Monkey" to ensure that individual components work independently. Chaos Monkey randomly kills instances and services within Netflix's AWS infrastructure to help developers to make sure each individual component returns something even when system dependencies aren't responding.

Sponsor

For example, if the recommendation system is down Netflix will display popular titles instead of personalized picks. The quality of the response is degraded, but least there is a response. Ciancutti explains it this way: "If we aren't constantly testing our ability to succeed despite failure, then it isn't likely to work when it matters most - in the event of an unexpected outage."

Here are the lessons Ciancutti writes that Netflix has learned:

Dorothy, you're not in Kansas anymore ("You need to be prepared to unlearn a lot of what you know")
Co-tenancy is hard
The best way to avoid failure is to fail constantly
Learn with real scale, not toy models
Commit yourself

Chaos Monkey fits into number three.

For more advice on migrating to the cloud from Netflix, check out our article Netflix's Advice on Moving to Amazon Web Services.

Discuss

A few months ago I posted a tip on how to Minimise file size with the YUI Compressor TextMate Bundle. The idea is to get minifying of CSS and JavaScript files into your workflow even if your server or CMS isn’t setup to do it automatically for you.

It works well, but I recently ran into a YUI Compressor bug that had me scratching my head for quite some time. Some of my media queries simply weren’t working. I checked the Media Queries specification, read various tutorials and examples from around the Web, and despite my syntax being correct some things just wouldn’t work.

Incredibly frustrating, but I found out what the problem was and how to fix it.
Read full post
Posted in CSS, Coding.

Google has quietly launched a new Labs project today - Google Shared Spaces. Based on Google Wave gadgets technology, Shared Spaces is designed to be an easy way to create and share collaborative applications.

As Shared Spaces uses Wave technology, there are already 50 different gadgets available, including shared maps, scheduling tools, polls, Sudoku games, and drawing boards.

Sponsor

Shared Spaces seems to be a fairly easy way to quickly share a workspace with a friend or colleague. You simply share the space's URL to invite others to join. There's a chat box for real-time communication, but it appears that the work space persists, meaning you can use it for longer-term work as well.

So, will more folks adopt Wave in this format?

According to the description on the Google Labs site, Javascript developers will be able to build their own gadgets in order to build more Shared Spaces tools. However, the link to Shared Spaces via the Google's Labs page returns an error message, so perhaps Shared Spaces - (oh dear) much like Wave - isn't quite ready for prime time.

(Here's the direct link to Shared Spaces.)

Discuss

As a web designer I’ve always felt that I’d somehow cheated the system, having been absent on the day God handed out the ability to draw. I didn’t study fine art, I don’t have a natural talent to effortlessly knock out a realistic bowl of fruit beside a water jug, and yet somehow I’ve still managed to blag my way this far. I’m sure many of you may feel the same.

I had no intention of becoming an artist, but to have enough skill to convey an idea in a drawing would be useful. Instead, my inadequate instrument would doodle drunkenly across the page leaving a web of unintelligible paths instead of the refined illustration I’d seen in my mind’s eye. This – and the natural scrawl of my handwriting – is fine (if somewhat frustrating) when it’s for my eyes only but, when sketching to communicate a concept to a client, such amateur art would be offered with a sense of embarrassment. So when I had the opportunity to take part in some sketching classes whilst at Clearleft I jumped at the chance.

Why sketch?

In UX workshops early on in a project’s life, sketching is a useful and efficient way to convey and record ideas. It’s disposable and inexpensive, but needn’t look amateur. A picture may be worth a thousand words, but a well executed sketch of how you’ll combine funny YouTube videos with elephants to make Lolephants.com could be worth millions in venture capital. Actually, that’s not bad… ;-)

Although (as you will see) the basics of sketching are easy to master, the kudos you will receive from clients for being a ‘proper designer’ makes it worthwhile!

Where to begin?

Start by not buying yourself a sketch pad. If you were the type of child who ripped the first page out of a school exercise book and started again if you made even a tiny mistake (you’re not alone!), Wreck This Journal may offer a helping hand. Practicing on plain A4 paper instead of any ‘special’ notepad will make the process a whole lot easier, no matter how deliciously edible those Moleskines look.

Do buy yourself a black fine-liner pen and a set of grey Pro Markers for shading. These pens are unlike any you will have used before, and look like blended watercolours once the ink is dry. Although multiple strokes won’t create unsightly blotches of heavy ink on the page, they will go right through your top sheet so always remember to keep a rough sheet in the second position as an ink blotter.

photo by Tom Harrison

Don’t buy pencils to sketch with, as they lack the confidence afforded by the heavy black ink strokes of marker pens and fine-liners.

If you’re going to be sketching with clients then invest in some black markers and larger sheets of paper. At the risk of sounding like a stationery brand whore, Sharpies are ideal, and these comedy-sized Post-Its do the job far better than cheaper, less sticky alternatives. Although they’re thicker than most standard paper, be sure to double-layer them if you’re writing on them on a wall, unless you fancy a weekend redecorating your client’s swanky boardroom.

The best way to build confidence and improve your sketching technique is, obviously, to practise. Reading this article will be of no help unless you repeat the following examples several times each. Go grab a pen and some paper now, and notice how you improve within even a short period of time.

Sketching web UI

Most elements of any website can be drawn as a combination of geometric shapes.

photo by Nathanael Boehm

Circles

To draw a circle, get in position and start by resting your hand on the page and making the circular motion a few times without putting pen to paper. As you lower your pen whilst continuing the motion, you should notice the resulting shape is more regular than it otherwise would have been.

Squares and rectangles

Draw one pair of parallel lines first, followed by the others to complete the shapes. Slightly overlap the ends of the lines to make corners feel more solid than if you were to leave gaps. If you’re drawing a container, always draw the contents first, that way it won’t be a squash to fit them in. If you’re drawing a grid (of thumbnails, for instance), draw all parallel lines first as a series of long dashes to help keep line lengths and angles consistent.



Shadows

To lift elements from the page for emphasis, add a subtle shadow with a grey marker. For the most convincing look, assume the light source to be at the top left of the page – the shadow should simply be a thick grey line along the bottom and up the right edge of your shape. If the shape is irregular, the shadow should follow its outline. This is a good way to emphasise featured items, speech bubbles, form buttons, and so on.



Sketching ideas

Arrows

Use arrows to show steps in a process or direction of movement. Giving shadows a 3-D feel, or adding a single colour, will help separate them from the rest of the sketch.



Faces

Start by drawing the circle. The direction of the nose (merely a point) indicates the direction of the person’s gaze. The eyes and mouth show emotion: more open and curvy for happy thoughts; more closed and jagged for angry thoughts. Try out a few shapes and see what emotions they convey.



People

Remember, we’re aiming for communication rather than realism here. A stick man would be fine. Give him a solid body, as shown in this example, and it becomes easier to pose him.



I know you think hands are hard, but they’re quite important to convey some ideas, and for our purposes we don’t need to draw hands with any detail. An oval with a stick does the job of a pointing hand. Close-ups might need more fingers showing, but still don’t require any degree of realism.

Signage

Don’t be afraid to use words. We’re sketching to communicate, so if the easiest way to show an office block is a building with a big ‘office’ sign on the roof, that’s fine!



Labels

Likewise, feel free to label interactions. Use upper-case letters for legibility and slightly angle the horizontal bars upwards to create a more positive feel.

Clichés

Clichés are your friend! Someone’s having an idea? Light bulb above the head. Computer’s crashed? Cloud of smoke with “$£%*!”





It’s good to practise regularly. Try applying these principles to still life, too. Look around you now and draw the cup on the table, or the books on the shelf. Think of it as a combination of shapes and aim for symbolism rather than realism, and it’s not as hard as you’d think.

I hope this has given you the confidence to give it a shot, and the ability to at least not be mortified with the results!

Tip: If you’re involving clients in design games like Leisa Reichelt’s ‘Design Consequences’ it may be wise to tone down the quality of your drawings at that point so they don’t feel intimidated. Remember, it’s important for them to feel at ease with the idea of wireframing in front of you and their colleagues, no matter how bad their line work.

For more information see davegrayinfo.com – Dave Gray taught me everything I know :-)

STYLE VERSUS DESIGN READS like it was written this morning. In fact, I wrote the original version in 1999, when I had a monthly web design column going at Adobe.com. In 2005, Adobe asked if I’d mind updating the piece. I changed a couple of words and they agreed that the revision worked. For although the web had changed tremendously between 1999 and 2005, the issue I addressed in my article had not. This afternoon, while importing some old Ma.gnolia bookmarks into Pinboard, I came upon Adobe’s HTML version of the 2005 revision to “Style vs. Design.” I read it again, and tweeted the link. Within minutes, designers were responding. Many thought the piece was new. For what I said in that article over eleven years ago still rings true, although there are now more designers who see things as I do. It’s nice that a piece of writing about web design could remain relevant for over a decade. But it’s also a bit sad. See what you think.

First up, if you haven’t seen the new teaser for the Elektron Octatrack, it’s definitely worth a look:

http://www.youtube.com/watch?v=k8qqPjpOlZI

Obviously I’m a huge Elektron fan already (owning a Machinedrum and Monomachine, as well as moderating the Elektron-Users.com forums), so I’m interested in the Octatrack a lot.  Thinking it might let me use all hardware again to play live, leaving behind Ableton and my laptop for samples of my studio work.

Which brings me neatly to my main topic, the simplicity of the laptop, and why I’ve never been able to completely embrace it no matter how hard I try.  Like a lot of musicians, I went through a phase early on of owning a lot of studio gear to make music.  Multiple racks, keyboard stands with multiple synths, grooveboxes galore, you name it.  Then of course the digital audio revolution happened, and slowly but surely I started selling things off and moving more and more to producing entirely in the box.

Of course, in many respects this was really not at all that different from having lots of hardware initially.  Like so many others, I became obsessed with ‘collecting’ plug-ins.  Dozens of dynamics processors, too many softsynths, and more than a couple DAWs.  Slowly, I realized I was turning to a select few plug ins though, and I began to whitle down my collection.

Then I made the jump from a desktop to a laptop, and suddenly things changed.  I realized that here was a really compact means to making and performing music.  This one tool reduced clutter and cable nests, removed the need for external monitors, keyboards, and mice.  Paired with something like Logic or Live, I could basically create anything I wanted with such a simple, and yet extremely powerful toolset.  It was a sort of revelation, and in the years since prompted me to sell more and more gear, to the point where my studio looked more like a beginner just getting started, instead of someone with almost 2 decades of experience.

There was a problem though.  Despite achieving my dreams of a minimalist set up, I really wasn’t enjoying the music making process anymore.  At the time I thought it was the lack of physical controls that was throwing me off, and thus began the great MIDI controller experiment.  I think I must have tried dozens of MIDI controllers trying to find one that reminded me of using a groovebox.  Sadly, nothing ever really worked like that, at the end of the day a laptop is still a computer, and a generic MIDI controller still requires too much configuring to be useful in the heat of the moment.  I didn’t want to stop to remap every parameter I wanted to control when I thought of it.  Even things like Novation’s Automap just didn’t sit well with me, very unpredictable in use.

So for now I’ve accepted the fact that I just can’t work with only a laptop, I need at least a few pieces of hardware to use when making music too.  Someday I hope a more elegent solution is found, in the meantime I’ll have to live with the love-hate relationship when it comes to the laptop.

We’re super excited to announce the new hotness that we’ve been cooking up for the past few months: Dropbox 1.0! In addition to hundreds (yep, hundreds) of bug fixes, vastly reduced resource usage (think of it as the Prius model of Dropbox), Dropbox 1.0 (“Rainbow Shell”) also offers support for extended attributes, selective sync, and a shiny new installation wizard. Those are just the CliffsNotes though — here’s the true story behind Dropbox 1.0:

Our highest quality yet – When you’re shipping software to millions of people, a problem that affects even 1 out of 10,000 is a big deal. And the most important feature of any file syncing software is that it just works. This release represents thousands of hours fixing problems people should never have to think about: invalid file names on Windows, weird Unicode normalizations, Word and Excel file locking, abnormal symlinks hierarchies, case sensitive file systems on Mac, TrueCrypt support, …the list goes on. Whether you’re using Dropbox for work, school, or play, we’re confident that today’s Dropbox offers the best file sync experience out there.

Huge performance enhancements – Dropbox 1.0 is strong enough to sync your entire digital life yet still lightweight and fast. We completely re-architected the client-side sync engine to optimize the response time, scale, and resource consumption. Keeping track of millions of files can require lots of memory if not done properly. This version reduces memory usage by up to 50%. It’s speedier and more efficient when handling big changes to your Dropbox while ensuring that smaller changes remain quick.

Better user experience – We’ve completely redesigned our initial setup wizard on all three platforms to make it easier to get started using Dropbox. The preference menus are more organized, intuitive, and snazzy. We’ve also rewritten our Mac OS X version to only use Cocoa so Dropbox looks and feels much more native on the Mac. This also brings down the Mac download size by 20%

Selective Sync – If you have a netbook or a computer with a tiny hard drive, syncing your entire Dropbox isn’t always a great idea. You also might not want certain files on your home computer to pop up on your work computer. Selective Sync solves these problems! You now can choose which folders get downloaded to which computers. This saves you time so you don’t have to sync stuff you don’t need. To learn more, head to our help center.

Extended Attribute Sync – Syncing resource forks have historically been a pain for Mac users. In case you don’t know, resource forks are a secret area of a file that certain applications (like Quicken, Quark, and OmniGraffle) use to store important data. Most sync programs today completely ignore these forks, which results in a corrupted file on the other end. But worry not! Resource forks and other extended attributes now work great with Dropbox. Hooray!

1.0 is a milestone for us, and with it we want to communicate our confidence that Dropbox is stable, high-quality software. The service has grown from a simple sync app to something that’s changed the way lots of people work and communicate. But just because this version of Dropbox has a new number doesn’t mean that we’re anywhere close to finished. We have a long way to go before we realize our goal of making it easy for everyone to always have access to their stuff. Stay tuned for more!

Huge thanks to our fanatical forum testers for all their help making this release happen!

And now, without further ado, go grab Dropbox 1.0!

Although not a new phenomenon, media queries seem to be getting a lot attention online recently and for the right reasons too – it’s great to be able to adapt a design with just a few lines of CSS – but many people are relying only on them to create an iPhone-specific version of their website.

I was pleased to hear at FOWD NYC a few weeks ago that both myself and Aral Balkan share the same views on why media queries aren’t always going to be the best solution for mobile. Both of us specialise in iPhone design ourselves and we opt for a different approach to media queries. The trouble is, regardless of what you have carefully selected to be display:none; in your CSS, the iPhone still loads everything in the background; all that large imagery for your full scale website also takes up valuable mobile bandwidth and time.

You can greatly increase the speed of your website by creating a specific site tailored to mobile users with just a few handy pointers – media queries, in some instances, might be perfectly suitable but, in others, here’s what you can do.

Redirect your iPhone/iPod Touch users

To detect whether someone is viewing your site on an iPhone or iPod Touch, you can either use JavaScript or PHP.

The JavaScript

if((navigator.userAgent.match(/iPhone/i)) || (navigator.userAgent.match(/iPod/i))) {
if (document.cookie.indexOf("iphone_redirect=false") == -1) window.location = "http://mobile.yoursitehere.com";
}

The PHP

if(strstr($_SERVER['HTTP_USER_AGENT'],'iPhone') || strstr($_SERVER['HTTP_USER_AGENT'],'iPod'))
{
header('Location: http://mobile.yoursitehere.com');
exit();
}

Both of these methods redirect the user to a site that you have made specifically for the iPhone. At this point, be sure to provide a link to the full version of the website, in case the user wishes to view this and not be thrown into an experience they didn’t want, with no way back.

Tailoring your site

So, now you’ve got 320 × 480 pixels of screen to play with – and to create a style sheet for, just as you would for any other site you build. There are a few other bits and pieces that you can add to your code to create a site that feels more like a fully immersive iPhone app rather than a website.

Retina display

When building your website specifically tailored to the iPhone, you might like to go one step further and create a specific style sheet for iPhone 4’s Retina display. Because there are four times as many pixels on the iPhone 4 (640 × 960 pixels), you’ll find specifics such as text shadows and borders will have to be increased.

<link rel="stylesheet"
media="only screen and (-webkit-min-device-pixel-ratio: 2)"
type="text/css" href="../iphone4.css" />

(Credit to Thomas Maier)

Prevent user scaling

This declaration, added into the <head>, stops the user being able to pinch-zoom in and out of your design, which is perfect if you are designing to the exact pixel measurements of the iPhone screen.

<meta name="viewport"
content="width=device-width; initial-scale=1.0; maximum-scale=1.0;">

Designing for orientation

As iPhones aren’t static devices, you’ll also need to provide a style sheet for horizontal orientation. We can do this by inserting some JavaScript into the <head> as follows:

<script type="text/javascript">
function orient() {
switch(window.orientation) {
case 0:
document.getElementById("orient_css").href = "css/iphone_portrait.css";
break;
case -90:
document.getElementById("orient_css").href = "css/iphone_landscape.css";
break;
case 90:
document.getElementById("orient_css").href = "css/iphone_landscape.css";
break;
}
}
window.onload = orient();
</script>

You can also specify orientation styles using media queries. This is absolutely fine, as by this point you’ll already be working with mobile-specific graphics and have little need to set a lot of things to display:none;

<link rel="stylesheet"
media="only screen and (max-device-width: 480px)" href="/iphone.css">
<link rel="stylesheet"
media="only screen and (orientation: portrait)" href="/portrait.css">
<link rel="stylesheet"
media="only screen and (orientation: landscape)” href="/landscape.css">

Remove the address and status bars, top and bottom

To give you more room on-screen and to make your site feel more like an immersive web app, you can place the following declaration into the <head> of your document’s code to remove the address and status bars at the top and bottom of the screen.

<meta name="apple-mobile-web-app-capable" content="yes" />

Making the most of inbuilt functions

Similar to mailto: e-mail links, the iPhone also supports another two handy URI schemes which are great for enhancing contact details. When tapped, the following links will automatically bring up the appropriate call or text interface:

<a href="tel:01234567890">Call us</a>
<a href="sms:01234567890">Text us</a>

iPhone-specific Web Clip icon

Although I believe them to be fundamentally flawed, since they rely on the user bookmarking your site, iPhone Web Clip icons are still a nice touch. You need just two declarations, again in the <head> of your document:

<link rel="apple-touch-icon" href="icons/regular_icon.png" />
<link rel="apple-touch-icon" sizes="114x114" href="icons/retina_icon.png" />

For iPhone 4 you’ll need to create a 114 × 114 pixels icon; for a non-Retina display, a 57 × 57 pixels icon will do the trick.

Precomposed

Apple adds its standard gloss ‘moon’ over the top of any icon. If you feel this might be too much for your particular icon and would prefer a matte finish, you can add precomposed to the end of the apple-touch-icon declaration to remove the standard gloss.

<link rel="apple-touch-icon-precomposed" href="/images/touch-icon.png" />

Wrapping up

Media queries definitely have their uses. They make it easy to build a custom experience for your visitor, regardless of their browser’s size. For more complex sites, however, or where you have lots of imagery and other content that isn’t necessary on the mobile version, you can now use these other methods to help you out. Remember, they are purely for presentation and not optimisation; for busy people on the go, optimisation and faster-running mobile experiences can only be a good thing.

Have a wonderful Christmas fellow Webbies!

Other properties are being closed or “merged”, too, including Upcoming. The whole Delicious team was fired yesterday, according to a friend who works at Yahoo.

It’s almost hard to remember now, but just a few short years ago, Yahoo was the place for hot startups to find a home.

 ★ 

One of the most visited pages on this site is the Simple 2 column CSS layout tutorial, where I explain how to create a basic 2-column CSS layout with floats. Many readers have asked for a similar tutorial on how to create a three-column layout, and I’ve been meaning to write one for a few years.

Well, I finally took the time to do it. Three-column CSS layouts have been explained many times, in many different ways, by many people already, so there is nothing (or at least not much) new here. It’s also something that I’m pretty sure that most regular readers can do in their sleep. Regardless, there are many people looking for this info, and it’s convenient to be able to refer to an explanation of how I normally create 3-column CSS layouts with a method that I find robust.
Read full post
Posted in CSS.

The IAN symbol libraries contain over 1500 custom made vector symbols designed specifically for enhancing science communication skills. The libraries are designed primarily for use with Adobe Illustrator (requires version 10 or better), however we also offer eps and svg versions for non-Illustrator users. The symbols allow diagrammatic representations of complex processes to be developed easily with minimal graphical skills.

Our aim is to make them a standard resource for scientists, resource managers, community groups and environmentalists worldwide. Currently downloaded by 58747 users in 239 countries and 50 U.S. states.

The libraries are provided completely cost and royalty free.

via IAN Symbol Libraries (Free Vector Symbols for Illustrator) – Integration and Application Network.

Glenn Greenwald:

From the beginning of his detention, Manning has been held in
intensive solitary confinement.  For 23 out of 24 hours every day
— for seven straight months and counting — he sits completely
alone in his cell.  Even inside his cell, his activities are
heavily restricted; he’s barred even from exercising and is under
constant surveillance to enforce those restrictions.  For reasons
that appear completely punitive, he’s being denied many of the
most basic attributes of civilized imprisonment, including even a
pillow or sheets for his bed (he is not and never has been on
suicide watch). […]

In sum, Manning has been subjected for many months without pause
to inhumane, personality-erasing, soul-destroying,
insanity-inducing conditions of isolation similar to those
perfected at America’s Supermax prison in Florence, Colorado: 
all without so much as having been convicted of anything.  And as
is true of many prisoners subjected to warped treatment of this
sort, the brig’s medical personnel now administer regular doses of
anti-depressants to Manning to prevent his brain from snapping
from the effects of this isolation.

 ★ 

One of the major pain points in developing mobile applications for iOS devices (iPhone, iPod Touch and iPad) is testing those apps. As we've noted before, the traditional testing method is time-consuming and cumbersome - files have to be emailed or shared, then downloaded to a computer, dragged into iTunes and synced to the mobile device. When an update is required, the app in iTunes has to be deleted and the whole process must begin again.

But there's a better way, as it turns out, thanks to a change Apple made in iOS 4.0 but didn't publicize. Apps can be distributed via the "ad hoc" method for testing purposes, which means over-the-air, one-click installs for app beta testers. Here's how.

Sponsor

Although we're not a mobile application review site per se, we've done our fair share of app reviews around here. And one thing that we've always found to be problem in doing so is the tiresome, tedious method of getting pre-release apps onto our iPhones. Download, unzip, drag and drop, sync, test, etc.

That's why when mobile business card scanning solution CardMunch emailed us a link to install its latest pre-release version (now live) late last month, we were intrigued.

"If you would like to play with CardMunch 2.0 yourself, we made it easy for you to install this time since we already have your UDID. All you have to do is visit this link (no iTunes syncing required)," the email read, following by a link to a page on the CardMunch.com domain.

We clicked the link from within our iPhone's email client and the app just installed on our device - no iTunes syncing required. What? How is this possible?

Apple's Best Kept Secret
Apparently, a few developers have discovered the secret, documented in detail here. Now you may say that this isn't a secret at all, but a well-known feature most developers already know about. We say this in return: Oh yeah? Then someone please (please!) tell the developers who keep emailing us zip files about this.

OK, I guess we will.

Why Ad Hoc: More Testers, More Feedback
Thanks to this feature, developers can distribute mobile apps wirelessly for testing purposes. Developers will still need access to the device IDs (UDIDs) and will still need to create provisioning files, but the actual distribution of the apps makes it far, far easier on those receiving the applications for testing.

With easier distribution, more beta testers are likely to actually install and try your apps. That means more feedback for developers, says Alex Okafor, a mobile application developer who shared the details of the new method on his blog ParadeofRain.com. It also means that some of your testers will be out in the field when they install the apps, instead of at home using Wi-Fi, which can help you spot issues related to 3G bandwidth and its effect on the responsiveness of an app's functions.

How To Set Up Your Ad Hoc Distro
Thanks to Okafor's guide, we have the instructions for setting up an ad hoc distro. Here's how to do it:

Choose Build --> Build and Archive
If not already open, open the Organizer window (Window --> Organizer) and choose "Archived Applications"
Highlight the build you just archived and click on "Share Application"
Select "Distribute for Enterprise" and the correct provisioning profile should be automatically selected. If not, correct it.
Now, fill out the form presented to you with the app URL, title, subtitle (optional) and image URLs (optional). 
Click "OK" and specify where the file should be saved. Save the file as the same file name you gave it in the URL.
Upload both the IPA and PLIST file to the URL you specified in the form.
Drop the index.php file created by Jeffrey Sambells here in this post into the directory where you uploaded the IPA file. This index will generate the links for both the provisioning and IPA files.
You're finished! Now, just share the link with your app testers!

Is this Legit?
So is this legit? It appears so. We spoke to another well-informed source on the matter who explained that this "Wireless App Distribution" method can now be done by either posting an XML file (a manifest file), using a PHP script or any other method. The idea is that the manifest will point to a single IPA file which itself can contain a provisioning file, they explained.

Developers registered under either the Standard or Enterprise program get 100 ad hoc invites, but Enterprise developers can distribute apps without linking to UDIDs. As far as this person knew, using an Enterprise developer license for distributing anything (beta or otherwise) to employees or contractors would be fine and not in violation of the Apple Developer Agreement. (Feel free to chime in if you know more.)

As we shared in October, a startup called TestFlight has developed a tool to further refine this process. It lets developers invite testers via email, and they can then see who has tested what builds of the app. The process of gathering and managing UDIDs is handled by the TestFlight service as well.

Have you tried ad hoc distribution for testing purposes? If so, what do you think about it?

Image credits: ParadeofRain

Discuss

Now that the Shelf Theme is finally launched, I wanted to write up some of the process and challenges that The Theme Foundry and I faced in it’s creation. I’d started with the intention of dribbling everything, but constantly found that I wanted to show more than 400×300px, so I started documenting the process in a Flickr Set instead. This post will flesh those out further.

Creation

I had a very clear picture in my head of how it should look, so my first step was to create what I call a ‘HTML Sketch”:



This is where I set up basic text and positioned boxes to make sure the layout was actually possible – a series of horizontally arranged ‘cards’ on a shelf, where the card height collapsed when the viewport was too small and the cards didn’t wrap. This was achievable with the cards floated left, within an absolutely positioned wrapper div with a fixed width. Without the fixed width it was impossible to prevent the cards wrapping across all browsers. Later on we changed this to use javascript to calculate what the width should be, but left a default width in for those without javascript enabled. When the viewport height is too small, the cards become scrollable using overflow:auto.

From the basic sketch, I then started roughing out the shading:



Initially the sketch had all the cards the same height, but later I managed to get the height to change per card to make it more interesting and natural.



I normally design ‘in the browser’ but it was essential for a project like this. One caveat: you do have to know what you want to achieve first. It’s very easy to spend hours ‘tickling away’ at little bits without any idea of the bigger picture. You need focus, as I’ve discovered myself.

I’d said at the start that I wanted this to be minimal, with no wood backgrounds. However, later in the development I tried the shelf in wood, and changing the light direction a bit, and found I preferred it:



The wood added much needed warmth, and helped draw the eye downwards to the bottom where the cards are aligned. I also used nth-child pseudo class to alter the postion of every other card slightly, just so they weren’t too uniform.

article:nth-child(even) {
margin: -4px 10px 0 0;
}

The cards themselves use a mixture of border-radius, multiple box-shadows and background images to create the overall effect. It means that IE gets a much plainer looking card of course, but not enough to spoil the overall look.

I’m really pleased with the final outcome:









I now employ media queries to every project I do, and Shelf was no different. When the layout becomes too narrow, it switches to a series of vertical shelves, rather than one long horizontal one. This layout also serves as the mobile device view:



In order to provide more ways of navigating the Shelf than the scrollbar, I worked with Yan Sarazin who implemented keyboard navigation, and all the other javascript that was required. I highly recommend Yan – he was a joy to work with!

The main typeface used in Shelf is Junction, an open-source font from The League of Moveable Type, designed by Caroline Hadilaksono.



I’d been looking for something that made me think of Modern Art Galleries (or ‘Museums’ if you’re in the US) and Junction fitted the bill perfectly. It’s open-sourceness was a bonus, and meant I could @font-face as much as I thought appropriate. Not all fonts suit the low quality Windows type-rendering, but I felt Junction still worked well under those conditions.

Some of the challenges that we faced

Normally on web projects I find that IE6 can be ignored (and served a universal style sheet), IE7 needs a few hacks to make it work, while IE8 and IE9 are fairly trouble free (lack of support for CSS3 aside). Shelf was much trickier however, with Firefox and Mobile Safari giving as many problems as IE7.

I always add an IE stylesheet for each version to sort out any issues, applying zoom:1 to elements that don’t ‘have layout’ in IE by default, such as div’s. In particular, IE7 had a problem with the heights of the cards.

First, IE7 without any fixes applied:



Then with zoom:1 applied to force ‘hasLayout’:



Applying Dean Edwards IE7 script sorted that out fortunately. IE8 and 9 just needed a few nudges to position the cards correctly on the shelf. I also needed to go back and add fallbacks to rgba colours, by placing a normal hex colour on the line before. Those browsers that don’t support rgba colour will simply ignore it and use the first colour.

I’d also used opacity a lot on images, such as the social network icons to avoid repeating images. However, while -ms filters could support this in IE, it supported it very badly. Transparency worked, but the icons lost all their anti-aliasing. In the end I felt that this was important for IE to see properly, so I reverted to a series of images instead.

The next browser problem I ran into was in Firefox, as it doesn’t allow you to apply border-radius directly to images. In the original Shelf design, I had images inside the cards (which have slight rounded corners) which were clipped correctly in Opera and WebKit (even in IE9!), but Firefox (including v4 beta) would display a sharp corner every time. The effect wasn’t great:



A workaround for this was to apply the image as a background-image of a div, applying the border-radius to the div. There are even jquery scripts to automate this for you. However, they rely on having a fixed size for the image, and Shelf makes it’s cards fluid for the narrow layout. While it wasn’t an easy choice, I decided to just add some padding inside the cards, rather than have them right to the edge as I’d wanted.

The other main issue to sort out was with Mobile Safari. While horizontal scrolling isn’t for everyone, on devices like the iPad it actually feels more natural than using desktop browser with keyboard and mouse. The gesture control suits it – particularly in the landscape mode.

Here’s where the real problems started. First of all, Mobile Safari doesn’t support position:fixed, which was being used to keep the header and footer in the same place while the shelf scrolled. Aside from javascript, there is no way to support this at the moment, so I decided to just let these scroll with the shelf. That wasn’t so bad.

The bad was that in order to scroll divs with overflow:auto you have to use two fingers. There is also no indication that the content scrolls either. I felt this was too much for users to find out.

This handy script from Chris Barr solves the 2-finger problem, and allows one finger scrolling, which is more natural, and increases the chance of discovering the scroll-to content by accident. We also needed a visual indication of ‘more content, scroll to see it’. As this was the eleventh hour on the Shelf theme, I came up with some CSS to add an indicator without extra markup.

The script adds a class of ‘scrollable’ to divs where there is overflow, so I already had a head start. I then added a mask image to fade off the bottom of the div, added via the :after pseudo element. At the end of the div inside, I added the mask image again, but with a higher z-index. The result is that when you scroll to the end of the content, the scroll indicator is hidden to indicate the end of the overflow content.

Here’s the code (shortened for brevity):

.scrollable:before {
display: block;
position: absolute;
z-index: 101;
bottom: 34px;
left: -2px;
right: 40px;
height: 60px;
background: url(../images/scroll.png), url(../images/scrollgrad.png);
background-repeat: no-repeat, no-repeat;
background-position: center 40px, left top;
content: ".";
color: transparent;
}

.scrollable .content:after {
position: relative;
z-index: 102;
display: block;
content: ".";
color: transparent;
height: 60px;
margin: -30px 0 0 0;
right: 0;
left: -6px;
bottom: -14px;
background:url(../images/scrollgrad.png);
}

And here is a video of the effect in action:



It’s not perfect by any means, but I’m rather pleased with finding a solution to something that I thought wouldn’t be possible without throwing yet more javascript at it.

So there we go, I hope you got something out of all that! It only remains for me to plug one more time: go and try the Shelf Theme for yourself!

Let’s face it, testing multiple browsers on multiple systems isn’t very practical. But it's still a fact of life for the web developer. What I’m about to show you is how I manage testing in multiple browser versions.

About three years ago, I used to do all of my development on a Windows laptop. I had an old Mac G3 tower, an Ubuntu server, and a Windows 2000 server. All of these were separate—and rather ancient and noisy—machines that sat in my office. I would have IE7 and the latest version of Firefox on my machine. I would hop onto my Windows server for IE6 testing, onto my Mac for Safari testing, and ... well, okay, I didn’t test any browser in Ubuntu.

When I got my Mac, I decided to try out VMWare Fusion. There wasn’t anything in particular that drove me to try it over Parallels but it seemed to get mentioned more frequently and so I just went for it.

The Virtual Machines
I started off by installing Windows XP. After which, I installed Ubuntu and more recently, I installed Windows 7 and also the emulator for the soon-to-be-released BlackBerry PlayBook.

Admittedly, my Ubuntu VM doesn’t get much love. I used it for testing Adobe AIR applications when I was still working on them and also test in Firefox, just in case something interesting comes of it.

I tried to install Windows Vista but it took forever to install and never seemed to work quite right. Thankfully, Windows 7 installed just fine and performs quite well in VMWare.

I was surprised to discover that the emulator for the upcoming BlackBerry PlayBook actually runs in VMWare Fusion. It made it quite easy to set up, although I’m doubtful how often I’ll be loading this one unless I start getting into some development.

Snapshots

Many people I know either use something like IETester in their single VM or install multiple VMs, one for each browser that they wish to test with. In the case of using IETester, there are some known limitations which may impact accurate testing. In the case of multiple VMs, you’ll need to have the hard drive space for multiple operating systems being installed on your system.

I took another route and realized that I could take a Snapshot of a particular point in time and then launch that snapshot whenever I wanted to. By taking a snapshot while the system is running, I can load a snapshot without having to wait for a virtual machine to boot up. It’s already booted. Loading a snapshot just copies the state of the virtual machine back into memory. I’m usually back up and running from a snapshot within 15 seconds.

The amount of space that a snapshot takes on the hard drive is also much smaller than a virtual machine: it’s just the size of memory, which may be between 512MB to 2GB, depending on VM configuration.

With IE6 on my machine, I took a snapshot. Then I installed IE7 and saved that as a snapshot. Then I installed IE8 and saved that as a snapshot. I used to keep various versions of Safari, Chrome and Firefox in those different VMs but I kept forgetting which snapshot had which alternate browser. So, I’ve started saving the different versions of those browsers as separate snapshots, as well.

This approach has come in quite handy. For example, I needed to test a localized version of Chrome for China. I was able to install and test the browser without worrying about it overwriting or impacting my main configuration. Once I was done with it, I could just delete the snapshot or load another snapshot without saving my current configuration.

Wishes
My biggest wish right now is to be able to install Mac OS X as a virtual machine, too. Unfortunately, Apple’s licensing doesn’t allow it. (Although, there are some hacks on the Internet that can get around that.) I’d love to have copies of 10.4 or 10.5 that I could load up and test.

Anyways, this is how I use VMWare Fusion. How do you handle your cross-browser, cross-platform testing?

J Chris Anderson, CFO of CouchOne, has been hosting a curious CouchApp on his personal site: Twebz. Twebz is a "decentralized Twitter client." We were curious about what that meant, so I did an interview with Anderson about the project. He says it's a just a demonstration of what CouchApps are capable of. But it also hints at what CouchDB is really trying to accomplish: a radical re-architecting of the Web into a more decentralized system. Read on for the full interview.

Sponsor

Klint Finley: Let's start at the top: what exactly is Twebz? It's described as a "decentralized Twitter client." What exactly does that mean?

J Chris Anderson: The aim is to allow you to interact with Twitter when Twitter is up and you are online. But if Twitter is down for maintenance or you are in the middle of nowhere, you can still tweet. And when you can reach Twitter again, it will go through.

If lots of folks are using it, then they can see each other's tweets come in even when Twitter is down.

Mostly the goal was to show the way on how to integrate CouchDB with web services and APIs.

It seems like it could be really useful for people in situations where Internet access is spotty, though.

Definitely. It's not production software yet, lots of rough edges. But it could be cleaned up and packaged like a normal desktop twitter client easily.

Do you plan on releasing it?

Not currently - I did it when I was around the house right after my daughter was born. So it's really just to show other developers how to build these things.

So I guess the idea is that you'd run a local copy and it would connect with other instances of Twebz running on other people's machines and everyone's client would try to connect to Twitter when possible?

Yes. The hard part is ensuring that someone else can't trick your client into tweeting something as you that you didn't write. So I had to do some JSON cryptography stuff to protect against that.

I was going to ask about that - so your Twitter credentials are passing through other people's machines?

No, your credentials are private to your machine. Potentially someone could send you a tweet that looked like it's supposed to be from/by you. The crypto makes sure that the Twitter-posting code can't be fooled by that.

So if you did release this, and people started using it, and then one day Twitter decided "We're done. We're going to go raise pigs in the Ozarks," Twebz would actually still be up and running fine basically forever and everyone could keep reading each other's Tweets.

Yep. And as a side effect you have a complete personal Twitter archive of the folks you follow.

There's even a feature to pull in the complete history of a user, so you can get the back fill of your closest friends if you want.

The full history is what is used to power these types of word clouds for a user. Aside from the autocomplete, I think the word clouds are the best feature. It subtracts the global frequency of each term from the per-user frequency of a term. So for each user you see the terms that are distinctive to them.

How does the autocomplete work?

Autocomplete uses CouchDB map reduce to build a prefix index. Then CouchDB sorts the matches by popularity when each time you type a letter into the search box. So it may start out: aardvark apple alligator (as things that start with "a"). But CouchDB will sort it so you get apple first, as that's the most popular. It was inspired by Google Instant.

If people want to try it, the code and instructions are here.

It says on GitHub that it doesn't work yet.

That's the same as on the site - it certainly isn't ready for the faint of heart. But someone comfortable hacking node.js and CouchApp would be able to dig in and run it.

I wish I had time to clean it up for release, but this week will continue to be busy with all that actual business stuff I've got to do.

Could CouchDB and Node be used in conjunction to create some sort of decentralized darknet? Something along the lines of Freenet?

Node is a good fit for CouchDB because Couch encourages asynchronous background processes, but people also use Ruby / Python / Java for the same purposes. But yes, eventually the plan is that CouchDB will make web applications a lot more robust because they will no longer depend on a centralized point of failure. E.g., even if Twitter goes out of business, people can continue to share messages.

The turnover of Web 2.0 startups is so fast that I think users get discouraged from signing up for services. Why bother with a new photo share if there's a chance it won't be around in a year? But when those are CouchApps, users can continue to use them even if no one is maintaining them, which makes it more rational to invest time in using them. Imagine if Pownce or Dodgeball were still being run by fans.

Have you seen CouchAppspora?(Disclosure: CouchAppspora contributor Tyler Gilles is a ReadWriteWeb employee.)

Yeah, I like that project because the social aspects of it get to the core of the stuff that "comes for free" with the CouchApp platform.

For another example of how CouchDB is useful in low-connectivity settings, check out this case study on how Better Health Outcomes through Mentoring and Assessments is using CouchDB in rural Zambia.

Discuss

It's hard to say no to your customers, but I'm getting a lot of practice at it.

You see, almost every day I say no when a customer asks me to add a feature to FeedDemon.  It's not that I don't want them to be happy - it's just that every feature I add to FeedDemon potentially makes it more complicated for every customer, so I have to shoot down features that I don't believe will be widely used.

Quite often, the customer will reply with, "well, why not just make it an option?"  Which of course makes sense when you're thinking about one little feature.  I mean, how could adding one measly checkbox tucked away in the program's settings make it more complicated?  But multiply that by the number of feature requests I get, and it becomes clear that making everything an option is, well, not an option.

I wasn't always this way.  Many years ago when I worked on HomeSite (and, to some extent, TopStyle), I'd say "yes!" to feature requests all the time.  If the feature wasn't one that a ton of people wanted, I'd just make it an option.  I thought this was great - and at first, it was.  Customers got new stuff all the time, and loved seeing their suggestions included in the product.  But fast forward a few years, and suddenly my software was an option-laden monstrosity.

In a misguided attempt to please everyone, I had added page after page of checkboxes to the options dialog.  Customers kept asking for options that already existed, or wondered where an option was that they knew was there but couldn't find in the checkbox maze.  Even worse, they'd inadvertently enable some option that changed the program's behavior, and then report that the software no longer worked like it was supposed to.  Which meant that when I received a bug report, I'd have to figure out which options might be involved in the bug, and then figure out which of those options the customer had enabled.

The other thing is, while it's easy to add an option, it's very hard to take it away.  If you add an option to your software, you'd better be prepared to keep it around for the life of the product unless you want customers coming after you with pitchforks and torches.

For example, in the first version of FeedDemon, I added a few options that made sense at the time, but later on weren't being used much and were complicating the development of new versions.  So in the first few beta versions of FeedDemon 4.0, I did away with some options that had existed for years.  To say this wasn't received well would be an understatement.  Customers who had become used to these options were up in arms, and said they'd never upgrade if the options weren't returned.  It's pretty frustrating for a developer to hear that all the work done to improve a product is overshadowed by the loss of a few options that probably shouldn't have been added in the first place.

So if you're a developer and you're working on a new piece of software, don't make my mistake of adding options, especially if you're doing so just to please a handful of power users.  In fact, see if you can avoid the need for a settings dialog at all.  You and your customers will be happier in the long run.