Category Archives: Design

Responsive web design and the problem with desktop websites

In the current iteration of Ponzu, almost all the views (except for feature phones) share the same code. That is to say that the desktop version, the tablet version and the smartphone version are the same HTML, Javascript and CSS with a little bit of CSS media queries to shrink down the interface for smartphones.

This is responsive web design.

Responsive design is a web design trend but is not without criticism. The most prominent criticism came from Jakob Nielsen, an expert in user interface design, in the blog post “Repurposing vs. Optimized Design”.

Nielsen point boils down to the following sentence;

It defies all common sense to expect the same user interface to be optimal for 3.5-inch screens and 30 inch screens, with no modifications beyond moving a few things around. Diversity in our interactive platforms requires diverse interaction design.

He lists the following as things that ought to be different for mobile vs. desktop design;

1. Most important, the content should be different: shorter and simpler writing is required for the smaller screen because the lack of context reduces text comprehension. 2. The IA changes to defer secondary content to secondary pages on mobile devices. 3. Interaction techniques change due to the differences between finger and mouse-driven input. 4. The feature set is reduced in mobile to lower complexity and to fit on the smaller screen.

Nielsen’s post met a lot of criticism from web designers, and he elaborated his points in a subsequent interview.

Similar points have been discussed in various blogs, and I find this article by Brad Frost, comparing the presidential campaign websites to be very informative, mainly because it compares the extremes.

Brad Frost summarizes the potential pros and cons of optimized-design vs. responsive site in the following.

Access

And while responsive designers can (and do) hide content from small-screen users, responsive design affords less opportunity to fork the content and create disparate experiences, which would deprive certain users of valuable information and features.

The main problem with Mitt Romney’s (optimized-design) mobile website is that only a fraction of the full website’s features are included.

Another common problem with separate mobile websites is URL management. Because desktop and mobile content live at separate URLs, device detection is required to route users to the appropriate site. Unfortunately, many websites don’t go deep enough in their URL redirection, so desktop users will get sent to mobile content and vice versa. This becomes apparent when mobile content gets shared by mobile users on social networks and then gets accessed by desktop users: Issues arise when a mobile URL is accessed from a desktop.
As we can see, having Web content all under the same roof and URL definitely makes it easier to give visitors access to the content they’re looking for, regardless of the device they happen to be using.

Interact

Obama’s (responsive design) navigation fails on a whole load of mobile devices: “And the menu failed. Never even opened. Suddenly, the site was without navigation… at all.”

Scrolling

Romney’s (optimized-design) mobile website has an acceptable page length.

Obama’s (responsive-design) pages contain a massive amount of content, often introducing entirely new sections far down in the flow. The result is extremely long pages that have serious problems.

Peformance

A typical page on Romney’s (optimized-design) mobile website is about 687 KB and, as a result, takes about 8.75 seconds to load. While that’s over the 5-second mark, the pages still weigh less than the average size.

A typical page on Obama’s responsive website is a massive 4.2 MB, resulting in a 25-second loading time.

The picture painted in Brad Frost’s article is that neither candidate got their mobile website right, even though Romney’s site appeared to follow Nielsen’s advice.

The question is how should we design the Ponzu conference system.

The problem is not about mobile. It’s about desktop design.

As I have discussed previously on this blog and others, my take is that desktop web design is too complicated. Rather than making mobile much simpler than current desktop design, my idea is to drastically simplify desktop design. By simplifying desktop design, it will become more adaptable to 3.5 inch mobile screens with minimal layout changes.

Tablets will be the motivation to simplify desktop design. In fact, I think that desktop websites should be designed primarily for tablet audiences.

iMode mobile sites and smartphone mobiles sites are different

When it becomes difficult to support a certain platform, one option is to provide a separate website that is written in simple HTML, and redirect that platform to this website.

This is how we support IE7 and below in Ponzu. Since our CSS and Javascript require at least IE8, we redirect IE7 and below to our website designed from iMode browsers. Since iMode only supports the simplest HTML and CSS, this website is extremely simple. Any browser, probably even old Netscape browsers are able to render to render this correctly.

One problem however is touch-based interfaces. When we render the iMode site on a touch device like an Android smartphone, the links are too small to tap with a finger. Although even the most incapable Android smartphones are able to correctly render the iMode website, the links are un-tappable because they are too small. One solution is of course to have the user zoom-in and out of the window. This is however a pain on old Android devices, because zooming is not smooth and in some cases, you do not have pinch-to-zoom.

We are currently investigating if we need to redirect some old Android devices to the iMode website, and if necessary, whether we can customize the font-size, etc. so that this site is usable with a touch interface.

Time to rethink website navigation systems

On January 6th, 2013, I outlined my thoughts on how I wanted to design websites that worked for both tablets and PCs.

I made the following observations;

  1. We need to start designing websites with tablets in mind. Displaying PC websites on the 10-inch iPad worked quite well. However, with the smaller iPad mini, we need to make more optimized websites.
  2. Desktop websites tend to be loaded with insane amounts of junk and redundant material. 90% of the content on the Asahi.com website, for example, is either a) advertisements, b) navigation, c) recommended links. The real content of the top page, which we would expect to be the headline news, is only 10% of the page.
  3. Because desktop websites come with so much junk, you would actually lose very little by removing it and making the page fit comfortably on the iPad mini.
  4. Looking at newspaper applications designed for the iPad, it becomes apparent that even the top-navigation bar is not really necessary. If you provide a button that summons up a page dedicated to navigation, you can dispense with even the most basic web navigation elements.

Today, working on an updated version of Ponzu, I am now absolutely sure that top-navigation can and often should be removed. With even the most basic web navigation scheme being cast under doubt, I am now of the impression that website navigation as a whole needs to be completely re-imagined, with inspiration for the new generation most likely to come from native mobile applications.

We’ll update this blog with our progress as it happens.

In the meantime, here’s an excellent write-up of traditional navigation designs and patterns that are common on current websites. Unfortunately, as you can easily see, the vast majority of these designs require the precision of a mouse cursor and are very, very unsuitable for an iPad mini.

Participation Inequality in Social Networks and Ponzu

It’s an old post but still as relevant as ever. A great post by Jakob Nielsen on encouraging more users to contribute to a social network.

Some excerpts with my comments;

User participation often more or less follows a 90-9-1 rule:

  • 90% of users are lurkers (i.e., read or observe, but don’t contribute).
  • 9% of users contribute from time to time, but other priorities dominate their time.
  • 1% of users participate a lot and account for most contributions: it can seem as if they don’t have lives because they often post just minutes after whatever event they’re commenting on occurs.

At the MBSJ2012, we had better results. In the analysis of “likes”, we found that 45% of the participants used the “like” button more than once. That is many times more than the 1% + 9% = 10% you would except from the 90-9-1 rule.

Jakob Nielsen also gives some recommendations to increase participation.

Although participation will always be somewhat unequal, there are ways to better equalize it, including:

  • Make it easier to contribute. The lower the overhead, the more people will jump through the hoop. For example, Netflix lets users rate movies by clicking a star rating, which is much easier than writing a natural-language review.
  • Make participation a side effect. Even better, let users participate with zero effort by making their contributions a side effect of something else they’re doing. For example, Amazon’s “people who bought this book, bought these other books” recommendations are a side effect of people buying books. You don’t have to do anything special to have your book preferences entered into the system. Will Hill coined the term read wear for this type of effect: the simple activity of reading (or using) something will “wear” it down and thus leave its marks — just like a cookbook will automatically fall open to the recipe you prepare the most.

Our “like” system falls within the category of “make it easier to contribute”. It also incorporates “make participation a side effect”, because you need to “like” a presentation to put it into “my schedule”. These likely contributed strongly to the better participation ratios at MBSJ2012.

Thoughts

In scientific conferences, participation inequality is a very important issue. This is because the online community is not the end-product, but it only serves as a means to enhance the scientific community, the vast majority of which is not very active on social networks. More importantly, the more important members of the scientific community, i.e. the professors, are less inclined to participate in these activities compared to young researchers.

Hence we should restrain ourselves from going overboard with social features which will tend to make the whole system unfriendly towards less social active participants. The social features should be there, but not necessarily prominent. They should help participants subtly and not be intrusive. We should also measure the success by the ratio of participants and the median activity, rather than the total number of activities. Most importantly, I believe that we should refrain from using social network features as a “voting” system for awards, unless we augment that with more traditional methods.

I believe social networks are important for scientific networks, but it is only a tool that has to be used very carefully. Ponzu (A Japanese sauce) is great for some food, but not so for others. Even when it goes well with your dish, too much will spoil it.

Jakob Nielsen, Intranet Social Features report

Jakob Nielsen, the renown user experience consultant, has posted a report on Intranet Social Features.

Below are a few excerpts that I found especially relevant to Ponzu, together with my comments;

Similarly, there’s now no doubt that social features are even more useful inside the enterprise for supporting employee collaboration and knowledge management. We used the slightly hokey term “Enterprise 2.0” to summarize our early research, and the new research confirms that the real effect of social features on intranets is to change how organizations function by making communication more open.

We also believe that social networking features in a conference program system (Ponzu) has a real positive effect on scientific research.

Little training is required. Users take to social tools easily when they’re given them for the right reasons and in the right work context. It takes little training, transition time, or urging to get people on board. In general, you should design social tools that employees can easily use without special training. In addition to following usability guidelines, you can achieve this goal by emulating popular Internet designs, such as the 5-star rating system known from Amazon and Netflix.

Avoid advertising the new tools as “new tools.” Instead, simply integrate them into the existing intranet, so that users encounter them naturally. For example, you could turn an existing bookmarking (or “quick links”) feature into a socially shared bookmarking feature without great fanfare.

It is essential that Ponzu’s features are modeled after popular Internet designs. That is why our “like” system is modeled after Facebook. We should resist making features complex. In fact, the example that Jakob Nielsen mentions, “turning an existing bookmark into a shared bookmarking feature” is essentially what we did. In Ponzu, we turned an existing bookmark (my schedule) into a “like” feature.

Despite companies’ concerns about employees using social tools with impropriety, infractions remain rare.

As long as attribution is built in and required, communities police themselves.

As with Intranets, the users of Ponzu will also be professionally accountable for the comments that they make. There should be no concern about impropriety.

In user testing of intranet search, we’ve found that it’s essential to provide a single, unified search across all intranet resources. This finding was replicated for social intranet features: they should be searched as part of the overall intranet search, rather than having individual siloed search engines for each social tool. Depending on the implementation, the need for integrated search can be a strong argument against outsourced or hosted social software, because many SaaS services don’t support federated search.

This is a strong argument for integrating all the social features inside Ponzu, instead of relying on third-party SNS or commenting solutions. Using Facebook or Twitter badges to provide social features is not a good idea. Neither is using DISQUS for the commenting system. Everything should be within the same system so that we can provide integrated search.

The most important conclusion from both research rounds is that social intranet projects must be driven by business needs — that is, the problem or pain point you’re trying to solve.

The reverse process is common, but deadly. Don’t start by saying, “Twitter and microblogging are cool, and I’ve heard good things about Yammer.” Our report says good things about Yammer, too, but that’s no reason to throw it onto your intranet. Maybe your business needs something completely different.

The difficulty here is to understand what the “business needs” of scientific conferences actually are. If you think that the needs are only to learn about research, then you don’t need social features in the first place. Only by perceiving scientific conferences as a social event can we understand which social features we need, and how we should implement them.

Today, many companies see intranet information sharing and other social features as offering true competitive advantages. It’s not something to build because it’s fun — it’s a workday utility. Social tools are an expected part of a knowledge worker’s standard toolkit, and many executives recognize this.

Widespread use of internal social media breaks down communication barriers. Although that sounds good, it can threaten people accustomed to having a monopoly on information and communication.

So, before implementing intranet collaboration tools, you must consider your company culture. If people are strongly committed to the “knowledge is power” tenet and don’t want to share, then sharing technologies will obviously fail.

Also, there’s still concern that, given social tools in the workplace, workers will fritter away their days and not get any work done. What we actually find — in companies with vibrant social platforms — is that employees are no more inclined to fritter away their work hours on non work-related communication with social tools than they were likely to do before these tools existed.

Social sharing is not for all scientific conferences. The medical community tends to be more rigid then the scientific community, with a stronger hierarchy and more formality. Hence it might be less suited than the relaxed molecular biology scientific society.

“Jobs-to-be-done” in scientific conferences

Clayton Christensen often refers to “Jobs-to-be-done” as a way of thinking about innovation. “Jobs-to-be-done” is a concept that was brought forth by Bob Moesta and the example that is most often referred to is milkshake marketing.

In essence, “Jobs-to-be-done” means to focus on a product’s function and its job; to understand what job the customer wants to accomplish, and why they hired the product to help them do it. In contrast, traditional marketing is usually obsessed with product categories, customer categories, and competitors, etc. These are what 4P and 3C tells us to focus on, but they often steer us away from the job-to-be-done.

In this post, I want to look at the jobs-to-be-done for scientific conferences, what participants want to accomplish.

The way I see it, the job that conferences are hired to do are the following;

  1. Face-to-face discussions with your peers, especially with those whom you do not regularly communicate.
  2. Learn about other remotely related research (fields that you wouldn’t usually check up).
  3. Meet with old acquaintances.
  4. Training and encouragement for young researchers.

Conference systems other than Ponzu only address the second issue. They provide a way to search the abstracts and to schedule your time. Unfortunately, they tend to only have a primitive search interface which is useful only when you have a very good idea about which search keywords you should use. As such, their support for the jobs-to-be-done is very poor.

Ponzu was designed for the jobs above. Each of Ponzu’s features was envisioned as a way to assist either of the tasks.

We designed the “like” system to provide an initial connection which could bring together scientists who share a common interest, but have never met face-to-face. We have heard stories where researcher doing unrelated research have met and discussed after discovering each other through “likes”. The “like” system addresses the first job. In addition, getting “likes” is encouraging. We have heard stories of young researchers being delighted at receiving likes from renown scientists, and then sending emails to them.

Our search system uses Apache Solr as the backend, and as a result, our searches are ranked by relevancy. Furthermore, we provide excerpts of the text to assist discovery. More importantly, we list up all presentations by the same research group so that users can easily learn more about each author, and meet with them at the conference to discuss further. As a result of collaboration with DBCLS, we also display related presentations based on keyword data-mining. This empowers participants to complete the second job.

Ponzu provides private messaging. Additionally, at the MBSJ2012, we provided Yoruzemi (a BBS for nightly meet ups). These help with job number 3, meeting old acquaintances.

Other conference systems view conferences only from the perspective of a lone spectator. They consider conferences to be a vehicle for information transmission from the presenters to the the audience, similar to how books convey knowledge to readers. They borrow features from spectator-oriented media and websites, but do not understand the unique jobs that conferences help get done.

The difference between Ponzu and preceding conference systems is hence very conceptual and deep. The difference is not in the number of features. It is in how we view the role of scientific conferences in general and in our approach to the jobs-to-be-done.

Our future goals are to deepen our understanding of how conferences contribute to the advancement of science, and to design Ponzu to assist in these roles. We need to understand the jobs-to-get-done, and to get them done.

Designing for Teenagers

Jakob Nielsen just published a study on designing for teenagers (“Teenage Usability: Designing Teen-Targeted Websites”).

The great thing about doing a real survey is that it often refutes a lot of the stereotypes that we tend to throw around. In the context of Ponzu, the misleading stereotypes are;

  1. are supremely tech savvy,
  2. use smartphones for everything, and
  3. want everything to be social.

In fact, it turns out that task success rate is worse for teens mainly due to lack of patience, but also due to insufficient reading skills and less sophisticated research strategies.

Lack of patience also means that a slow website is a disaster for teens. Websites have to be fast.

Teens also want more control of social aspects and sharing information. Ponzu integrates social network features into the conference system, but we should be aware that even young people do not necessarily want to share information.

Another interesting finding is that teenagers dislike tiny font sizes as much as adults do.

My takeaways are;

  1. Don’t use small fonts except where small print is expected.
  2. Pay attention to navigation.
  3. Make the website fast, even when the network connection is bad (using local caching strategies).
  4. Don’t force sharing unless we really need to.

Thoughts about the future of viewing PC websites on mobile phones

While studying how iPhone and Android display PC websites on mobile phones (here and here) , I came to the conclusion that physical screen size doesn’t really matter that much; auto-resizing text based on complex software algorithms makes all the difference.

Since there is a large difference in how browsers auto-resize text, it would be unwise to rely on it for a conference system where mobile access is very important. Ideally, you should create mobile versions of all the relevant websites for the conference. If you do not have the resources for this, at least make sure that the websites look good on Android devices, because PC websites are more difficult to use on the default Android browsers. Checking with mobile Safari is insufficient because its software algorithms make up for your mistakes.

Looking into the future, FireFox and especially FireFox OS may change the situation. The current versions of FireFox on Android use auto-resizing very aggressively, and we can expect the low-end phones using FireFox OS (which will use small screens to cut costs) to do the same. These phones may make browsing PC websites on small screens quite bearable. 

If auto-resizing becomes commonplace and web designers can begin to rely on it, then the extra efforts to optimize websites for mobile will become less important. A single design will cover both PCs and smartphones.

Comparing PC website browsing on iPhone 5 and Galaxy Note 2: The iPhone 5 is actually better

In my previous post, I concluded that the Galaxy Nexus with a 4.65-inch screen did not provide a superior web browsing experience compared to the 4.0-inch iPhone 5. On the contrary, the iPhone 5 displayed larger fonts on the same pages, hence reading the content was more comfortable on despite a significantly smaller screen. This was largely due to automatic font-resizing on the iPhone’s Safari browser.

I also briefly mentioned the Galaxy Note 2, and suggested that even with its 5.5-inch display which is 38% larger in length, fonts on PC websites would not be displayed as large as the iPhone 5. Hence, the browsing experience might still be worse despite a much larger display.

I have now obtained some screenshots from the web (I myself do not own a Note 2) so we can compare with actual images.

Below I used Galaxy Note 2 screenshots from TechRadar. I took screenshots on my iPhone 5 from the same website, and adjusted the sizes so that they represent actual physical measurements (meaning that you can directly compare font sizes).

Showing the whole page

The screenshots below were from The Daily Mail website. When displaying the whole page, second level headers were barely legible on the iPhone 5’s retina display. Second level headers on the Galaxy Note 2 were also very small, so we expect them to be very difficult to read as well. Since in both devices, the only text that could comfortably be read was the top level headers, we think there is little difference here.

Galaxy Note 2 full 2013 01 25 19 48

Zooming up on text

The next screenshot is where we move to an article page and zoom in to the text. The navigation column on the right is moved out of the screen. This is the “reading” mode where readers will actually read the text of the article.

As we saw in the previous post, here again we see that the iPhone 5’s font size is actually larger than the Galaxy Note 2, despite the latter having a 38% larger screen. This is due to mobile Safari automatically resizing the text.

Adding the fact that the iPhone 5 has a 326ppi retina display compared to the 285ppi Galaxy Note 2, the readability of the larger text on the iPhone 5 is clearly superior to the Galaxy Note 2.

Galaxy Note 2 zoom in 2013 01 25 19 50

Conclusion

With actual screenshots from the Galaxy Note 2, we can again see that the iPhone 5 provides a superior web browsing experience.

This is pretty damning. As the TechRadar article stresses, browsing the web is THE strength of the Galaxy Note 2. It is where the huge screen makes its mark. We also know that browsing the Internet is the most popular smartphone/tablet activity. Unfortunately, the much smaller iPhone 5 beats the Note 2 in website readability with the advanced software in mobile Safari.

The Galaxy Note 2 is great for browsing if your benchmark is other Android phones. If you have a choice though, I recommend the iPhone.

Software, not the hardware, is what makes the difference.

Is a larger screen on smartphones beneficial for viewing PC websites?

In a previous post, I discussed design considerations to make “pinch to zoom” work well. This is very important when you want to show your PC website to smartphone users. I concluded that it is vitally important to keep the length of each row short, and that 50 letters per row is optimal.

In this post, I would like to investigate whether or not a larger screen like that on recent Android devices would help. Specifically, I would like to discuss whether the Galaxy Nexus with a 4.7 inch screen (W 2.28 x H 4.05 inches) provides a better viewing experience compared to the iPhone 5 with a 4.0 inch screen (W 1.96 x H 3.49 inches).

As described in more detail below, my conclusion is that due to software optimizations in mobile Safari, iPhone 5 (and to a lesser extent iPhone 4/4s) provide a better experience than the Galaxy Nexus. This is despite the Galaxy Nexus having a significantly larger display.

A similar conclusion was reached by Ben Bajarin of Tech.pinions in his blog post.

Safari auto-resizes text to make important stuff legible

In a “pinch to zoom” interface, it is vitally important that the user can recognize what part of the screen they should zoom into. This means that important headers and links should be large enough to be legible, even without zooming-in. We want to see if this is the case

In the following image, I have compared the nikkei.com front page on the iPhone 5 and Galaxy Nexus. The images are drawn to the same scale so that you can directly compare sizes.

As you can see, both smartphones display the headers of each article quite well (red arrows). These headers are both equally legible. The text is smaller on the iPhone and larger on the Galaxy Nexus, representative of the difference in screen width.

However when we look at the smaller headers/links which I highlighted with yellow arrows, the situation is reversed. On the iPhone 5, mobile Safari automatically enlarged the text to make them legible. However, Chrome on the Galaxy Nexus rendered them in propotion to the rest of the page and they are barely readable.

When you look at the text body, you realize that the lines are shorter on the iPhone 5. This is because mobile Safari again is automatically enlarging the font-size so that it would be legible. As a result, the body text is larger on mobile Safari compared to the Galaxy Nexus.

iPhone 5 does not increase text size universally. For articles that are not accompanied by large header text, iPhone 5 tends to treat them as unimportant and does not increase text size.

The end result is that despite the iPhone 5 having a significantly narrower screen, the text is actually larger and easier to read than on the Galaxy Nexus.

Nikkei com 2013 01 25 10 49

We can also see this in action on www.asahi.com. The iPhone 5 is significantly easier to read.

Www asahi com 2013 01 25 10 50

Font size in pinch-to-zoom view is larger on Safari

As a side-effect of font-resizing, the text is much larger and easier to read after the user has “pinch-to-zoom”ed. The following screen shots are on www.asahi.com after zooming in to the top news section. As a side note, zooming was easier on the iPhone 5 because mobile Safari has better auto-zoom level detection. Hence a double-tap takes you to the zoom level on the screenshot, whereas a double-tap on Chrome does not. With Chrome we had to do an actual “pinch-to-zoom” gesture, which is more cumbersome, to get to the zoom level on the screenshot.

As you can see, font sizes are significantly larger on the iPhone 5. This is due to the rows having less characters per line as a side-effect of the auto-text resizing I described in the previous section. The font-size on Chrome, although legible, is not ideal. Any website that has been optimized for mobile would use a much larger font.

Asahi com pinch to zoom 2013 01 25 10 50

This situation is very serious for text-heavy pages. As you can see in the following screenshots, the iPhone 5 screen is much much easier to read.

Asahi com 2013 01 25 11 33

On mobile optimized websites neither has an advantage

Mobile optimized websites are designed for narrow screens and assume that the user will scroll down to read more. Font sizes will be more-or-less the same regardless of screen size, hence the difference is only in how much a user has to scroll. Given the easiness of scrolling on smartphones, this is generally not much of an issue.

In the next screenshot from IT Media mobile, you can see that the Galaxy Nexus shows a bit more information at the bottom of the screen. Still, not enough is visible so even Nexus users will scroll down.

The font sizes are almost identical and easily legible.

ITMedia mobile 2013 01 25 10 50

Firefox

Although Firefox is not the default browser on Android and we won’t use it to compare with the iPhone, Firefox has very interesting text-autoresizing and is worth mentioning here.

Simply put, Firefox is extremely aggressive with text-autoresizing. The resized text is very large and easily readable. I expect many people to find this very nice. 

The Mozilla organization is preparing FireFox OS for low-end smartphones. FireFox OS will probably use the same aggressive text-autoresizing. This is ideal for low-end smartphones which are likely to have smaller screens than high-end Android phones. Text will be easily legible despite small screens, and is likely to be much better than text on high-end Androids with large screens running Chrome.

The algorithm for resizing text on FireFox is described here.

Chrome Firefox headlines 2013 01 25 17 14

Chrome Firefox text 2013 01 25 17 15

Conclusion

Despite the Galaxy Nexus having a significantly larger screen than the iPhone 5 (4.6 inches vs 4.0 inches), viewing PC websites is actually much more comfortable on the iPhone. This is due to important software optimizations in mobile Safari.

If you are designing a PC website and you want it to also be usable on iPhones, you can be more relaxed about the recommendations that I gave on my previous post. You don’t have to be too picky about the maximum characters per line, because mobile Safari will do the work for you. However, if you want to make it usable on Android, then the burden is on you. The designer has to make sure that the line length is short enough to be easily legible on Android smartphones, and large screen sizes don’t help much.

On the other hand, if you are creating a mobile website, as long as you are adhering to the general guidelines for a mobile site, usability will be basically the same on both iPhones and large-screen Android phones. Large screens do not provide an advantage. Likewise, Android’s lack of optimization is no longer a disadvantage.

How this effects screen size trends

A recent trend in smartphones is the rise of the “phablet” category, namely the popularity of the Galaxy Note which is a smartphone with a 5.5 inch display. This screen provides 18% more width than the Galaxy Nexus.

As discussed above, screen size alone is not important. When we compare the Galaxy Note (simulated screenshot below) to the iPhone 5 for the body text, we actually see that the iPhone 5 still has larger text and better readability. In fact, in order to surpass the iPhone 5 in font size when reading PC websites, Android devices need to get up to 7-inches.

I suspect that the rise of “phablets” is a result of the lack of software optimization in Android browsers. The iPhone and mobile Safari can provide readability that surpasses “phablets” on much smaller screens.

Simulated galaxy note 2013 01 25 12 21

The larger view

Incremental feature improvements provide actual benefits only when the previous technology was insufficient. Large screens provide benefits to smartphone applications if and only if the current screen size is restricting usability, and the improvements are significant enough to overcome the limitation.

What this means is that applications that have been optimized for small smartphone screens will not receive significant benefits from an incrementally larger screen. This is the situation that we saw with mobile-optimized websites. A larger screen allows you to see a few more lines. However, since scrolling is so easy on smartphones, the benefits to usability are limited.

On the other hand, viewing PC websites that have not been optimized for mobile are a great opportunity to show off the benefits of a larger screen. Viewing PC websites is by far the most irritating activity on smartphones because the text is often too small to be legible, and scrolling horizontally to read as single line of text is truly annoying. It is these times when we wish we had a larger screen or a tablet.

Therefore, the benefits of a larger screen on smartphones should mainly be measured by how easy it is to browse PC websites. However, due to lack of text-resizing, large-screen Android smartphones actually provide a worse browsing experience compared to the iPhone. Without text-resizing, a screen size approaching 7-inches is required to display websites with the same font-size as the iPhone.

The situation is different with tablets. Because tablets like the iPad have fundamentally larger screens compared to smartphones, it is possible to provide a different user interface. Optimized applications have multi-paneled navigation systems, for example. Therefore with tablets, the issue is whether the screen size is large enough to house the different user interface or not.

In the eyes of most web designers, tablets at or below 7-inches do not have sufficient screen real-estate to accommodate multi-paneled navigation, whereas the iPad mini does. Many web designers give 7-inch tablets the smartphone version in their responsive designs. On the other hand, the iPad mini will get the same multi-paneled navigation as the iPad. In a nutshell, anything below 7-inches is a smartphone, and anything above 7.9-inches is a full tablet.

In conclusion;

  1. For optimized websites and applications, anything below 7-inches is basically the same. You get the smartphone experience. You only get a significantly better experience if you go to or above 7.9-inches (the iPad mini).
  2. For non-optimized websites, incremental increases in screen size can potentially benefit the user experience. However, the lack of automated resizing in Android browsers results in a worse experience than mobile Safari, despite a significant advantage in screen size.