Recently I had some discussions about the mobile web-browsing experience and I realized that I was not really up to date on the current state. So I collected some information and draw my conclusions...

First I have to confess that I am an iPhone/iPad user and have limited experience with other smartphones, operating systems and browsers. None the less, I tested different screensizes using a tool called screenfly and tested various browsers.

My general attitude towards mobile web-browsing is that I browse the web with a smartphone only on occasion, when I'm looking up an adress, phone number or check out an url that I encounter on the road. Most of my mobile web usage is done through smartphone apps rather than a web-browser. On longer trips, I take a tablet with me and when browsing the web with a tablet, I do read longer articles rather than just look up small bits of information. When I actually work - compose longer e-mails, write a blog post etc. - I prefer my laptop. I rather like to see the "actual, full featured" website that I am familiar with rather than something that resembles a low-bandwith version.

So the questions I wanted to answer were:

• What are the actual facts and figures about mobile web usage?
• What screensizes are common among the mobile devices out there?
• What is the quality of the common mobile web browsers?
• What are the strategies of adapting content for mobile devices?
• What is the conclusion and what are the implications of all that?

Lets get started with the facts and figures on mobile web usage.

I searched for information that included more than a special demographic and gave a good overview. Of course can find a lot of information on mobile webbrowsing but I wanted a source that was freely available and found some statistics at mobithinking. 

One of the key facts for me is that although on different levels, mobile usage seems to be similar across the US, Europe and Japan. Most interesting is that users (in the US) preferr either the browser or smartphone apps depending on the mobile activity.

Digging deeper, I found some info on app usage at appsfire. The infographic they published in their blog gives a nice overview of mobile web usage although it might tend to overestimate app usage due to the self selection of participants in the survey.

So what to take away from this: a lot of people use the web on mobile devices, they use mobile browsers and smartphone apps alike depending on the task.

The next thing we have to look at are the devices and screensizes.

Since the devices change almost on a daily basis I can not give you a complete list of screensizes but I can point you to phonescoop who seem to mantain an extensive database with specifications of mobile phones. Then, ther is of course device atlas who also have a commercial service to give you access to their database. Another, shorter list of relevant smartphone and tablet screen resoutions can be found at binvisions.

The simplest tool to check out some common screensizes I found is screenfly by quirktools. This tool allows you to enter a url and preview a website on a variety of different screensizes that you can select with two simple clicks. There are multiple device categories available (desktop, tablet, mobile, television) and you get a quick overview of common screensizes. Sadly though, the list of devices needs some work, but I am confident that the list will be updated soon. I suggest you check out the list at binvisions and preview your site at screenfly.

In essence there is a wide variety of screensizes and screen resolutions. Most modern devices will give you a screen resolution with one side at least 800 pixels wide. But as we will soon see, this is not the most important thing when thinking about mobile web-browsing.

Another component, we have to look at are mobile browsers.

This is rather complicated since you would either need a couple of different device or a bunch of emulators to check the results against each other. For starters, you can find a list of different mobile browsers at wikipedia. However I could not find a free webbased emulator/simulator to check how a given website would look like in different mobile browsers. There are commercial services available but I did not test those.

What I did find was an Opera Mini emulator at opera that comes close to the results that I get with opera on my iPhone. In addition you could check webkit based browsers on multiple devices using mobilizr. I also found a list of mobile emulators and simulators at mobilexweb.

I tested some websites on the latest version of the built in webbrowsers in Android 4.0 and iOS 5.0.1 and found only good results. The tested webpages and sites behaved as I would have expected from a desktop browser. JavaScript worked fine, pictures gave no problems, movies played as expected and html and css rendering was without a noticeable problem. I was able to zoom in and out of the content and the browsers felt fairly responsive.

I also tested various other browsers for iOS but decided to stick with the default webkit based browser as it gave the best performance and quality.

I think that the default browsers of the latest mobile OS versions are just fine at giving you access to most of your favourite websites.

Even though, there are multiple strategies for adapting content for mobile browsers.

A good start is to read an article at mobiforge to get an impression of what those different strategies are and what they involve. They have created a nice table that gives a good overview of what you could do. 

There are some basic concepts that I would like to summarize as: a) do nothing, just serve the same page to every device, b) serve a version that adapts on the client-side, c) serve a special version for each device, that is adapted on the server-side or d) use a combination of b) and c)

Indeed there is a discussion whether adaptation is at all necessary or not, given the information we reviewed above.

I believe that the need for an explicit strategy will decrease as technology evolves further.

You can sit it out, if you want, but I think it would be better to decide along another train of thought. Adaptation is not a must, but complexity of your page, intensity of use and technological circumstances should be taken as indicators of whether adaptation could add value to your website.

If you have a reliable website now, modern devices, browsers and the zoom-function will be sufficient for information retrieval from your site. If most of the traffic on your website is dedicated to finding a phone number, the adress of your shop or a short info on your products, you should be fine. In general a not to complex business website shouldn't require a special adaptation strategy.

If you see that your customers have problems navigating your full website or are only looking for certain services or information from their mobile devices, you probably should adapt your website to offer a special version. 

If you realize that your customers encounter bandwidth trouble, you shold opt for a scaled down and optimized version of your website to provide quick access for mobile users.

If you operate a business that is releying heavily on the mobile web as a channel for sales or distribution and you operate a rather complicated webapplication, maybe you should think about a dedicated smartphone app that can take advantage of hardware or OS specific features.

Of course, you can always combine web and app or do both. 

The conclusions for our own development:

I think we will keep an eye on how screensizes, resolutions and browsers on mobile devices will develop. But at the current state of technology and for providing business websites, we are set up at a good position.

Pages built with GRADETY will be viewable and able to function on most tablets and smartphones depending on their OS and browser. We will strive to keep it that way, so that there is no inherent need to adapt. Full size and full features for all websites and all devices is our goal.

In the future we might present users with a way to produce a special version of their website, that they can adapt for mobile use if we see additional demand in that direction.

As always, I hope you like this collection of thoughts and I am looking forward to your feedback.

Addendum

While doing the research for this post, I came across a number of interesting links that didn't make it into the main body of the text because the text would have to get fairly technical and even longer than it already is. So I chose to include them here with just a short description.

A discussion of what a "pixel" means on mobile devices: "A pixel is not a pixel"

Several pieces of information on how to handle the zoom: a) "Zoom mobile browsers", b) "Viewport" and c) "Device adaptation"

An interesting argument on the "web vs. app" discussion: "Why the web versus application debate is irrelevant"

We've said before that we like node.js for the concept of being non-blocking. In oder to demonstrate what that means, we've put together some stuff.

First, here is a short video that tries to explain the advantage of non-blocking javascript. It's oversimplifying but it should illustrate the basic concept.

Second, we've come up with small app that will give you the chance to try this on your own: DNS.js. You will need to have nodes installed and some basic understanding of javascript development and web technology. Please be also aware that you might want to be careful on what domains and IPs you are trying this.

DNS.js is a minimal software-snippet which shows the asynchronously non-blocking processes of node.js.

The idea was to find a simple task that can illustrate some performance gains of node.js. Resolving a number of IP adresses seems to be easy enough and should nicely demonstrate some advantages of node.js.

• The first part of the program simply looks for the IP of a domain and resolves it to aaa.bbb.ccc.xxx.
• The second part is an IP-scanner, which does a reverse-resolving. It scans from IP aaa.bbb.ccc.1 to aaa.bbb.ccc.100. By the way, in addition to being non-blocking, it is an example for the asynchronous processes inside 
node-applications.

Using a counter we can start 100 queries resolving the IP’s simultaneously.

for(i=1;i<=100;i++){ (function(a){.. .. .. })('aaa.bbb.ccc.' + i)};

In the console.log we can see, that the callbacks answers 
in the order of the finished processes, not by the order of 
the iteration variable i.

var e='';
for (i=1;i<=100;i++){   
(function(a){
    dns.reverse(a  , function (err, domains) {
      if (err) {
        console.log('reverse for ' + a + ' failed: ' +
          err.message);
      } else {
        console.log('reverse for ' + a + ': ' +
          JSON.stringify(domains));
      }
    });   
})('aaa.bbb.ccc.' + i);
}// for

If you have node running and are familiar with the command-line, you can start the whole program with: $> node dns.js.

You can find a download of the code: here.

Some days ago Anja posted some reasons for starting a business. I just wanted to chime in with a short post myself because it reminded me of some of the stuff that we teach at university.

Besides a bundle of individual reasons that mostly are personal motives like a wish for self-fulfillment or the idea that being an entrepreneur will bring additional freedom. One driving factor is simply the joy of creating something new and to prove oneself in the marketplace. It can be challenging, but it can also be a lot of fun.

There's a nice quote that is attributed to Bill Rancic:

"The cover-your-butt mentality of the workplace will get you only so far. The follow-your-gut mentality of the entrepreneur has the potential to take you anywhere you want to go or run you right out of business—but it’s a whole lot more fun, don’t you think?"

Of course there's a wide variety of reasons and of course sometimes, some of those reasons are purely economic. But it is always great if you come across a business were it is obvious that it is not just founded to make a lot of money. I think that I can speak for all of us at the littleweblab, when I say that the main reason for starting development was the wish to built great tools.

I do believe our reason for getting started is more in line with Guy Kawasakis statements in "The Art of The Start":

You can check out more from his talk at the Stanford University's Entrepreneurship Corner.

On the other hand, you can not run a business on noble motives alone. In order to survive in the marketplace and provide sustainable services to your clients, your business will need to be profitable. But still, as Cyert and March (1963) noticed, among the motives for entrepreneurs:

“Profit is one, perhaps, but they are also interested in sex, food, and saving souls”.

I hope we can provide both, meaning and profit. 

What about you? Why did you start your business?

Hi there, I'm Mathias, one of the co-founders of the littleweblab and our core developer. As a first post to our blog, I wanted to briefly talk about our switch from ruby on rails to node.js. 

Let's be clear about one thing, I think that you should not directly compare rails and node because in contrast to rails, node is not a framework. That's why I will give you my impression and some reasons, why we decided to switch our development. So, this article is neither a comparison, or how-to, nore does it claim to give any general advice on whether to choose one above the other. It's simply a blog about what happened and why we took the decision.

We are putting a lot of emphasis on the interface an user experience of our application. After all we wanted to build a really cool webapplication and not the hundredth iteration of the same old cms concept. That goal made us push more an more of the application logic to the client. We rely heavily on the jQuery UI widget factory and have built a controller that manages the widgets depending on the url and the selected dom element.

If most of the application logic is on the client-side, how sophisticated should the server-side really be?

The server-side is reduced to what its does best, routing, and serving scripts, css, binary files as well as the basic html of the application and operating the database. Of course we could have done that with rails, but it seemed oversized. There was alot of background "magic" that we wouldn't need.

When we went looking for alternatives, we realised the following

1. We like the concept of stored procedures and think that adding an additional database abstraction layer can get in the way of realizing the full potential of MySQL. So, most of GRADETY's database logic is done by stored procedures within the database itself.
2. We love JavaScript! Why should we bother to use 2 or more languages? Since we started as a small team it seemed to be a good idea to keep the number of languages down. Since the browser is just fine with JavaScript, the decision could have been made earlier to go for Javascript on the server as well, but in the first phase of our development, node was simply not ready yet. When we revisited this topic some months later however, it was!
3. In rails there doesn't seem to be an elgant concept for ajax at least in our perspective.
4. Manageable. Node and its frameworks are more puristic (although that is also due to their smaller size)
5. Node is non blocking and that's nice. We will have a separate post about that soon!
6. If you've really mastered you JavaScript skills client-side, you "only" have to learn about server-side topics without learning a whole new language.
7. We didn't want to rely on to much "magic" that might make it difficult to support and manage our source code with a small team down the road. We wanted to keep a small codebase with readable code while still being able to keep the requirements and groundwork as simple as possible. Rails is built for a lot of usage scenarios and brings many higher level functions that we wouldn't use.
8. We wanted to be able to blur the boundaries between client and server as well as break free from a strict mvc paradigm.
9. Watching a young community grow is really cool.
10. We did like the logo! The old one! ;-)

I am sure that everything I write here can be contradicted and is of course up for debate and in addition subject to change as both technologies develop. Node is by far free of any problems, and of course you can - one way or another - built solutions to most problems using most web-technologies.

What I think is really important is that a developer should be comfortable with the technology he uses.

Whatever the chosen technology is not that good at, one has to make up for in time and creativity. For us, node is the technology of choice. For us, switching over to node took about 1/3 of the time of the rails development. Performance increased and we are really happy.

I'm looking forward to show you our application and the performance that we get out of the technology. I think Webdesigners will love it.

As for node.js, if you have questions, want to discuss or want to join development of GRADETY, use the comment section below or send us a mail.

Hi, I‘m Anja. I‘m part of the littleweblab Team (although I‘m not into web development). Anyhow, I‘d like to write a bit about what it is like to start our new business. Or better to say, what the reasons are to start a business of our own (aside from the fact that we have a product of which we think would perfectly fit the market).

It‘s definitely not about the money. Or about of the many weeks of vacations. Whom would I be kidding! Starting a new business is actually taking us a lot of time - and money. Wouldn‘t it be more rational to stick to an 8 to 5 job with quite a nice income and five weeks of vacation? No? So what is it, that makes us want to become entrepreneurs against all odds?

It‘s about the way we want our lives to be.

Our way to work, our way to create new things, to change the world (just a little bit) and in the end knowing why and for whom we‘re doing it.

Starting a new business somehow is a kind of freedom we always wanted but seldom had. And I‘m not talking about sleeping ‘till noon. It‘s the freedom of deciding whether to or not to take a certain step (by the way, it doesn‘t matter what kind of business you might be starting, it should always have your personal handwriting).

One of the things we most appreciate about being entrepreneurs is that we actually are given the opportunity to combine work and personal life exactly the way we wish. Starting with the place we live. City? Countryside? Considering that all we need to keep our business going is a reliable internet connection, well, we have the privilege to choose.

For instance, I would love to grow my own vegetables. In fact I‘m already doing it on my tiny city balcony (leaving no space to place a chair – or, funny thought, a table!). So it‘s beans, tomatoes, squash and chillies this season. But imagine what precious garden I would have if I would live not in the city but in a house on the countryside. It would make my life complete. I would be (more) happy – simple as that. Which would definitely have a big influence on my work. Not mentioning the dog I would have, that I can‘t keep in my apartment. So moving is definitely on the agenda!

Certainly there are a lot more reasons – no question. Btw, we would love to hear from you and your reasons to start a (future) business of your own.