Dubroy.com/blog

I’ve been taking a break from my RSS reader for the last couple of weeks, so I didn’t hear about Scribd’s iPaper until yesterday. If you also need to be filled in: Scribd is a Y Combinator startup who writes software “that makes it easy to share documents online.” They want to be the YouTube of documents. iPaper is their new Flash-based platform for document sharing:

iPaper is a document format built for the Internet. Like a YouTube video, iPaper documents are Flash widgets which you embed in your existing web pages. PDF, Word, PowerPoint, and many other document formats can all be displayed on the web using iPaper.

iPaper is designed to be fast, light, and simple. Because it’s integrated into your site, iPaper offers a fluid browsing experience, keeping visitors on your site. It has a small footprint, doesn’t require the installation of additional software, and it’s not loaded with superfluous features.

Now I would be the last guy to defend PDF. I’ve invented entirely new swear words just for Acrobat. And I’ve written before about how downloading documents is a seam in the web experience. iPaper seems like it could be an improvement — but it remains to be seen.

But what worries me a bit about iPaper is that if it becomes popular, it’s another step towards a centralized web. One of the greatest things about the internet is that it’s mostly decentralized — a single point of failure can only have a limited impact. If a single email provider like Yahoo! goes down, then only Yahoo! users are affected. The same with my web site: if CNN goes down, it doesn’t have an impact on me. But if your site relies on YouTube and Scribd to serve your content, then you are screwed if one of those sites goes down. (Or goes bankrupt, or gets shut down by the feds, or …)

As we move towards the vision of “utility computing” — where CPU cycles and software are delivered like gas and electricity — centralization is becoming more and more of a problem. The Amazon S3 outage last week brought down quite a few sites. Think about all the sites that rely on Amazon S3 and EC2, Google Maps, YouTube, and maybe soon Scribd.

The web is becoming fragile.

In a great post at Signal vs. Noise, Jason Fried answers the question, “Is it really the number of features that matter?”

What matters is the editing. Software needs an editor like a writer needs an editor or a museum needs a curator. Someone with a critical eye and the ability to say “No, that doesn’t belong” or “There’s a better way to say this.” Physical constraints create natural limits for books and museums. Books have pages and museums have wall space. Software, on the other hand, is virtual, boundless. Anything is possible. When anything is possible someone inevitably tries to make something do everything. And the more something does the harder it becomes to understand, grasp, and use. So the key is deciding what makes it and what doesn’t.

What Jason’s talking about here is really the core of design. It’s about making tradeoffs, and finding balance:

So remember: Good software is about balancing value and screen real estate and understanding and outcome. If it takes 20 good features to get there, then great. If it only takes eight, even better. It’s not the number that counts, it’s the balance.

Joshua Porter thinks it’s important that the designer be someone different than the creator:

You need someone pushing back as much as you need someone pushing forward. You need, not necessarily a critical eye, but a concerned eye that isn’t colored with the effort of creation. A creator is almost never equipped to be objective about their creation. (nor should they be)

The analogy to writing — that software needs an editor — is a good one. But there’s a key different with software: it’s about solving a specific problem. When choosing which features to include, you need to always keep in mind the problem that you’re trying to solve. As Charles Eames, one of the most famous designers of the 20th century, said: “Recognizing the need is the primary condition for design.”

Over at Signal vs. Noise, Matt talks about taming the RSS beast:

Is keeping up with RSS feeds a challenge for you? If so, what solution would you like to see? Are there blogs or software tools out there that are already doing some/all of the above well? Let’s hear about it.

I probably subscribe to fewer RSS feeds than most people — I’ve got 16 in there right now, and less than half of those publish even a post per day. And still, I find it to be an annoyance sometimes. It’s just oh so compelling to click on those Bold Headlines (56).

In the comments to the SvN article, several people suggest that you should only subscribe to feeds that you can’t miss, and the rest you should keep as bookmarks in your browser. What if I don’t keep bookmarks in my browser? I work on several different computers during the day, and one of the things I love about subscribing to RSS feeds in Bloglines is that everything I want to read is in one place, and accessible from any computer.

Jeff raises a good point:

I don’t have any answer, but this post got me wondering: is there really a fundamental difference between managing your RSS feeds versus managing your email inbox. Of course there are differences, but basically you just need a way to prioritize and quickly evaluate what you want/need to deal with now versus later. How do you manage your inbox? Why can’t you use a similar approach to feeds?

This is something I’ve been thinking about for a long time. We deal with all kinds of information on a daily basis, in many different formats: email, blog postings, rss feeds, documents, bookmarks, etc. Each one of these formats has is managed by a different application, each one with its own features and quirks. Every application you have to be familiar with adds a little bit more to your cognitive load. Why do we insist on segregating our data based on its format? Couldn’t a single application be able to deal with different data formats?

This is something I will be writing about a lot more on this blog — the problems with current information managment software, and what can be done to fix them. Stay tuned.

Joel raises a good point in his post Choices = Headaches. His complaint is that Vista has WAAAAAY too many options for saying “see ya” to your computer: sleep, hibernate, shut down, restart, log off, and switch user. I agree with him here. I was just thinking the other day how silly it is that there is even a restart option. It’s basically only there because of brain-dead software, and if you really, really need to restart, couldn’t you just turn the computer off then on again?

Joel’s solution is a single action, which he calls b’bye:

When you click b’bye, the screen is locked and any RAM that hasn’t already been copied out to flash is written. You can log back on, or anyone else can log on and get their own session, or you can unplug the whole computer.

He calls it b’bye, but it’s just another name for off. If you implement it the way he described though, you’re still missing a true reset option. Sure, it may be a cop-out for poorly-written software, but I think it’s still necessary.

The big-picture idea that Joel is touching on here is that more is less. Having too many options is a bad thing, because you actually have to invest significant mental effort to choose between them. Sometimes this can be enough to turn you away altogether. I procrastinated on buying a digital camera for years, because it was such a monumental effort to just learn about the choices I had. Too many choices can also make you feel belittled, because you don’t understand the differences. The menu at Starbucks has this effect for many people.

In software, adding a configuration option is the ultimate design cop-out. I’ve seen this happen many times with Eclipse since I was a developer in pre-1.0 days. Would you like to double-click to open files, or single-click? Would you like to use curvy tabs or square tabs? Having so many options makes it really difficult to find the important ones. (In fairness to the Eclipse developers, they have a very diverse set of stakeholders, and this is the only way to keep most of them happy)

What it really comes down to is having the courage to make those tough design design decisions. By removing those unnecessary options, you risk alienating a certain group of users — the people that actually want them. But would you rather by stuck in the zone of mediocrity?

I’ve just finished reading a paper on Cognitive Dimensions of Notations for the grad psychology class I’m taking. I found it pretty interesting, because it solidified some concepts that have been floating around in my brain for a while. The Cognitive Dimensions (CDs) framework provides a vocabulary for discussing usability aspects of information systems.

CDs give names to common issues related to representing and manipulating information. Viscosity refers to how hard it is for a user to change the system. For example, think of changing the prototype of a method in C++: in a large class hiearchy, you have to make the same change in many classes, and in both the header and the implementation. This would be high on the viscosity scale.

Another dimension is diffuseness: how verbose is the notation? A language like Java would score high on this scale (ummm, public void Runnable() anyone???), while Smalltalk would be much lower (where anonymous functions can be created by just using square braces).

I like the idea of formalizing these kinds of higher level concepts, because by giving something a name, it becomes immediately more tangible, more legitimate. And it becomes a kernel around which ideas can crystalize.

Of course, the other advantage to naming these concepts is that it becomes much easier to discuss them. Like with design patterns, you can refer to Model-View-Controller and most programmers will know what you’re talking about. If software developers were taught about Cognitive Dimensions as core concepts like patterns, then it might make it easier for them to understand and respect these issues, instead of dismissing them as touch-feely aesthetic issues.

Note: The title of this post is the name of another (proposed) CD — Useful Awkwardness is when something is deliberately difficult or awkward, but ultimately helpful as the user is forced to reflect upon the action. It’s my second-favouritely named CD, behind Grokkiness. Apparently people weren’t too fond of that one though, and it’s been renamed.