Tag Archives: Native vs Web

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.

Are native apps a replacement for a mobile web site?

Jason Zimdars on Basecamp Mobile back on Sep 13, 2012.

But even if/when we offer native apps, we will still want this mobile web version. Apps aren’t a replacement for the mobile web.

Mark Zuckerberg, Disrupt SF, September 2012

One of the things that’s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us.

So having a native application for the conference program does not mean that we can do without a mobile website.

Unfortunately, some conferences have apps while very few have mobile websites.

What killed the native smartphone app for MBSJ2012?

As of April, 2012, the plan was to create a native application (with “Like” capability) to support smartphones, and to support PCs and feature phones through the website. The website would also provide an API so that the smartphone application could sync “like” information. This decision was changed in July, 2012. Native applications were ditched and the decision was to support all devices through the website.

Below, I describe our perspective as to why a native application was not (and still probably isn’t) suitable.

Smartphone native applications don’t require “native” functionality

Conference program applications are quite simple. They are basically a hierarchical listing of the presentations with a simple search function and a bookmark function. They hardly require any graphics capabilities. Since they are basically viewing-only, complicated editing and gestures are not necessary.

As such, there is very little need for these applications to be written as native applications. A basic web page can easily provide the same set of functions.

The only benefit of a smartphone native application is working offline

Although both Apple and Android smartphones use WebKit for their browsers and are HTML5 capable, storing data offline is still a sore point. The most widely supported API for offline storage is webStorage, but it is limited to 5MB on most browsers. This limits us to a few hundred presentations. By using webSQL and indexed DB, we should be able to use more than 50MB, which will enable us to include thousands of presentations. As such, storing the whole conference program on the browser for offline viewing is still confusing and difficult to program. Furthermore, developing offline web applications is an area technique which is not yet common, and mature libraries have yet to emerge.

Native applications are much easier. Native applications can directly use sqlite3 or keep all the data in the filesystem. The App Stores do not limit the size of applications, so the number of presentations that can be stored is virtually limitless.

The native app developer considered using UIWebView for the poster map

When we were discussing native application development with the software house in May 2012, they brought up the idea of using a UIWebView for displaying the poster map. This is basically the equivalent of providing a link. All the programing for the poster map will be done on the website, and the native application will simply act as a browser to view the page.

I was stunned. The poster map is the only feature where nice graphics would really make a difference, and the only place where I would consider native applications to have a fundamental advantage. Despite that, the developer was saying that they wanted to use web technologies to do that. They were throwing out the opportunity to show that native apps are awesome. It also meant that the only real advantage of a smartphone application, offline viewing, would not be possible for the poster map. This was unacceptable since the room where WiFi would be most fragile was expected to be the poster hall.

I pressed hard on the developer, basically interrogating them on what they really meant, whether they really thought that the UIWebView solution would be appropriate, and whether they would be able to make it work offline. This discussion was rather confusing, and I began to worry about whether they were really going to create something that met up to our expectations.

This is when I started work on a smartphone version of Ponzu to see if a smartphone version might be a better solution than a native application.

Conclusions from the smartphone version

  1. If the smartphone application used Ajax technologies to keep network access to a minimum, 3G networks were sufficient for smartphone clients. We tested in congested areas in Tokyo such as Shibuya station, and found no performance issues.
  2. iPads with only WiFi connections would still be an issue unless we supported offline viewing.

Current thoughts

  1. If we can fully support offline viewing on the mobile website using HTML5 storage, then we can almost completely neutralize the advantages of a native application.
  2. Having two different parties developing for different devices is dangerous. Communication is difficult and the result is almost sure to be inconsistent features and user interfaces.
  3. An outside developer that isn’t committed to excellence will slow down innovation. An outside developer is OK only when innovation is stalled, and you can show them what they need to copy.

Conference programs in a social world

Here we discuss how conference programs should interplay with external social networking systems like Twitter and Facebook. We will also discuss how currents systems fail.

Links from social network sites

Nowadays, the most common way to share information on the internet is by sharing links on social network sites like Twitter and Facebook. One common use case would be where one of the authors shares his/her presentation with co-authors or colleagues.

Although link sharing is very common and most Internet users take it for granted, the rising popularity of mobile devices and the use of native applications has made it a challenge. There are increasingly more cases where simple link sharing doesn’t work.

Currently Ponzu has some complications when sharing links across devices. More specifically, a link from the mobile website viewed on a smartphone, when viewed on a PC, will display the same mobile version. This is OK on Safari, Chrome or Firefox, but has issues on Internet Explorer. Similar situations occur when a PC link is viewed on a smartphone, etc.

If the conference has a native application for smartphones, the situation is often worse. These application usually have not assigned URLs to each presentation so sharing is simply impossible.

The current situation means that we are wasting golden opportunities to use social networks for marketing our conferences. Ponzu has limited support as of now, and will be improved to provide top-class social sharing.

Participants should be able to enter their own SNS accounts

In Ponzu, participants could enter their own SNS accounts such as Facebook, Twitter, LinkedIn and Read & ResearchMap. We hope that this will help researchers to become more connected and more collaborative.

We believe that this was yet another first for a conference program.

Conclusion

We believe strongly that the scientific community should embrace social networks to enhance collaboration. Conferences, being social in nature, are an ideal place to trigger that trend. However, there are some roadblocks that are preventing this.

One particularly large roadblock is the focus on native applications for smartphones. Unless accompanied by a mobile website, these applications can actually prevent participants from spreading information to their network. We have to take this into consideration when choosing our mobile platforms.

Native apps vs Web: Comparison of search

Search is a very complicated technology that can consume a large amount of computing resources. Here we will compare search inside a native application and search on the web.

Search speed

Search speed on the web, if done correctly, is generally very fast. This is because a) there are a number of very good open-source search engines, b) servers have a lot of RAM, fast I/O and CPU speed. On the other hand, native applications don’t have many open-source search engines, nor do they have the power to search really fast.

The difference probably is even larger when searching through Japanese text. This is because when indexing Japanese, we would generally use Ngram. However, Ngram inflates RAM usage, and is not very realistic to use it on mobile devices.

Server side search is very feature rich

If you use a search engine like Solr, then you can use faceted search. Faceted search tells you the distribution of the results, and you can make it easier for the user to drill down further to specifically find what they are interested in. It would be interesting to see how we can employ faceted search in conferences.

It is not possible to provide the same functionality on a native application, unless that application connects to a server.

Conclusion

Search is vastly better on a client-server architecture with the search engine residing on the server. A native application that searches locally will never have the same level of sophistication and speed will be slower. A better solution would be for the native application to connect to the server whenever the user wants to perform a search.