A new use for margins

While I still read books on my way to work, I recently started reading online articles and blog posts using my phone as well.

This morning, while I was reading a column on Alertbox on iPhone, I noticed with pleasure a small detail: the left and right margins of the page have more than a merely aesthetic purpose.

As anyone who ever used an iPhone will certainly know, you usually slide your thumb along one side of the screen to scroll the page you’re reading.

Now, look at the screenshot below (red margins were highlighted later): because of the empty space at the sides of the page users are able to scroll without hiding text under their fingers. That’s relevant if you have the habit of scrolling and reading at the same time.

I don’t know if Alertbox is styled like that by chance or by design, but I appreciate the result nonetheless.

As a side note: Alertbox is one of the most mobile-friendly websites I read. As such, it’s perfectly readable even on the small screen of my Nokia E71.

Pagination directions

Although pagination is a widely diffused pattern, some times it can still be a bit confusing, when it comes to blogs.

Most blogs (and many news sites) have a couple of links at the bottom of the page, newer and older posts or articles. Of course, there are two opposite ways to arrange those links: put the newer link on the left and the older one on the right, or just the opposite. What I consider to be annoying (and confusing), is to find both alternatives used inconsistently across blogs and websites.

For example, the Google Blog puts the Newer Posts link on the left,

while the Worpress Blog places Newer Entries » on the right

Confusing, isn’t it? What is the right way to show those links?

Pagination by itself is quite clear: most web users have long become accustomed to Google search results pagination,

and Yahoo’s Design Patter Library states it clearly:

• Present links in the following order: ‘Prev’, page links, ‘Next’.
• Display a left arrow after the label ‘Prev’.
• Display a right arrow before the label ‘Next’.

In other words, previous goes to the left, while next goes to the right.

The problem with blogs and articles is that it’s not clear what should we consider the “previous page”.

Is it the one with the older (previous) posts? Or, since articles are listed starting from the more recent ones, the page with the more recent posts?

I think any answer would be debatable, and that’s the source of all the confusion. What would you say?

Outsource your features!

A new trend is rising: applications which are not designed to fulfill some user’s needs but, rather, to provide some service to other web apps.

Until some time ago, if you were to design your own web app, you had to write the same code, with little to none variations, to deal with pretty common issues (i.e. login, user profiles, messaging and so on) every time. You had no choice but to reinvent the wheel each time. Over and over.

Now you have one more possibility: delegate your recurring, non-core (albeit relevant) functionalities to third party web applications, which are built to integrate easily with your own one.

This leaves you with a lot more time to focus on your core features, maximizing your effort. Think of it as code reuse, for web apps.

I’m writing this post a few hours after adding support for user avatar images on Novlet, and I’m still surprised about how painless the process turned out to be.

Although I consider avatars a great addition to most account-enabled applications, we chose not to support them at the beginning because we considered them not to be that relevant for a web app centered upon creative writing. At least, not relevant enough with respect to the effort they required.

So, what made me change my mind?

The answer is, in just one word, Gravatar.

In short, Gravatar allows users to associate email addresses with avatar images, and allows application developers to access that images using the email address users registered with. Users have to set up their images just once, and any gravatar-enabled application will transparently use them.

Stop. Gravatar does just this. But it does it well: it took me a ridiculously small number of lines of code to set everything up, and it works like charm. (You should see the new avatars on Novlet.com when we finish polishing the details. )

Another example: BitLet’s feedback forum.

Originally, we used to gather feedback and suggestions from our users through email or via the blog. But the forum we created with UserVoice allows us to collect suggestions and manage them in an orderly and efficent way, and it took us just a few clicks to set it up.

Now you should understand why Bitlet’s blog is created with Blogger. And that’s why we plan to leverage Google Account Authentication and, eventually, all OpenID providers for our upcoming Secret Project™.

It’s a trade which benefits both users and developers: why not to take advantage from that?

In one of my previous posts I wrote about the potential of Facebook as an application platform. But with a family of interoperable and pluggable application services (or service applications ) which can be used as building blocks for our web apps, the Internet itself can become an even more powerful, open, platform, pushing the concept of mashup to a new frontier.

Connecting people

Conferences are great. Not just because you can (hopefully) learn a lot by attending, but also because they give you the chance to meet great people who share your interests and work on the same issues you’re facing.

Obviously, most of those desirable effects happen during, or maybe after the conferences themselves. (But it applies to conventions, meetings and the like.) Is that really the only option?

Some context: this month I’m flying to Amsterdam to attend User Experience 2008. I was thinking that I might end up sitting on the plane next to someone who’s going at the same conference. And we might not discover it until the first day of the conference, since the organizers did not provide attendees with any means to interact with each other.

Building an event on Facebook, a network on Ning, a group on LinkedIn are just some examples of what the organizers of an event can do to promote communications between participants. (For the less web 2.0 oriented, probably a plain forum or a mailing list would work more or less the same. )

Think about the benefits of allowing participants to interact before getting to the event. One among all: making a community out of an audience.

Perhaps Seth Godin is right, after all, when he gives so much emphasis to Tribes, and to the importance of building a community of connected people.

Web application platforms?

The everyday life of the average Internet citizen is filled with dozens of impressive web applications, which help to perform any sort of task.
Ranging from planning your next trip to Holland to sharing the photos of the last party you had, a lot of activities can be effectively made easier or more efficient by using some brilliant web site.

Although it’s becoming increasingly hard to find something you can’t do from within your browser, there are still some activities which won’t probably deserve their own shiny web app, being relevant just to a tiny niche of users.

But, think a few seconds about that: the concept of the “long tail“, often cited as one of the key points of Web 2.0 (whatever it means), is all about niches. In particular, even if the big players are fighting to satisfy the most popular needs for the vast majority of users, there may still be enough room for anyone else to deliver solutions to the needs of the niches (i.e. the “tail”).
And the good news is that it might be a sound strategy, too.

Get to the niches

Quoting Wikipedia, from their page about the long tail,

Where inventory storage and distribution costs are insignificant, it becomes economically viable to sell relatively unpopular products; however, when storage and distribution costs are high, only the most popular products can be sold.

The same principle can be generalized to web application development, as well.

Suppose we are about do create a web application which addresses a simple, non-essential, need: probably we are not aiming to the mass market, and maybe we are focusing on something that is relevant to a small amount of users, or for a limited duration (just the timeframe in which they need your app).

If we are able to focus on the core of your application, without having to deal with the burden of non-essential aspects, then it becomes viable to develop new services that will be useful for relatively smaller sets of users.

Now, there are several ways to handle this point. Most of them are technical, such as choosing a specific platform/technology/framework, while some others are merely economical (unless you’re creating something just for the fun of it). All of them are well documented and widely discussed.

But I’m afraid we might still be missing one, fundamental, point.

It’s not all about costs

Even if we manage to complete our project successfully, we still have a major barrier to cross: a new web site to use can be a significant complication to some users. It means, at least, a new web address to keep in mind (or in the bookmarks), and a new set of credentials to remember.

There is, always, a small resistance we have to win in order to make users adopt a new application. A resistance that is more relevant if we are addressing a non-essential need for a niche target.

In order to win that resistance, the first option we have is to build an outstanding web app, so that users will be so willing to use it that they will easily overcome that barrier. There is another possibility, though.

Consider this. Facebook offers us the possibility to leverage their entire user database (over 100 million users, November 2008), and, most of all, a window which stays open all day long on the browsers of a lot of people, to which we can post notifications.

In addition, as you will certainly have noted, the resistance of users towards adding new Facebook applications is significantly lower than the resistance towards new web applications. Outrageously lower.

After all, they already have registered.

Many web applications that would never make it as stand-alone web sites, might earn their place as Facebook applications. (Or, maybe, LinkedIn applications, or Google App Engine applications, or something else).

Then, that said, why do we continuously get bugged with dozens of invitations from pointless quizzes and useless tests on Facebook? Why there are so few useful applications on Facebook? It may just be the sign of some huge potential that lies unfulfilled.