Category Archives: Native App vs Web site

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.

Optimizing total development effort with Ponzu

In Ponzu, our idea is to support all the digital communication devices that a significant number of participants are likely to own. This means that we will support 1) PCs, 2) smartphones, 3) feature phones, 4) tablets, 5) PDFs. That’s 5 different formats.

If we were to support smartphones and tablets through native applications rather than through the web, that would mean that we would have to add at least two more platforms, making the total number of formats into 7! Clearly, that is too much.

Furthermore, unlike normal IT development which is notorious for frequently missing deadlines, IT development for conferences must be on time. The time window is also very narrow since a large portion of the development cannot happen until the abstracts have been submitted by the users and the organizers have sifted through them.

Hence reducing total development effort is a very important part of Ponzu.

In the following, we will briefly describe what multi-device development is like in Ponzu, and how we manage to keep total development effort at manageable levels.

MVC architecture with Ruby-on-Rails

The MVC architecture for building web applications separates the Model (business logic) from the View (presentation). The effect is that you can use the exact same code for the Model, regardless of which device you are targeting. You will have to write View code for each device though.

This is a huge advantage for multi-device support. When we add another device, we don’t have to touch the Models. We simply modify the Controller and write a new View.

The most advanced MVC framework for web development is Ruby-on-Rails. We many of Ruby/Rails features to make multi-device support easier.

Writing new Views

Even though the overall page design is different between devices, a lot of the parts are very similar.

For example, code to generate the lists of authors and institutes in HTML is basically the same. We extract these into view helpers and use them in both for the PC website, the smartphone website and the feature phone website.

Code sharing can be done at a higher level as well. If you compare iPhone apps and iPad apps, you often notice that the iPad app is actually adding navigational elements around an iPhone app. In these cases, the iPad apps includes the iPhone app view as a fragment. Rails lets us do this easily with view partials.

Although still a work in progress, our goal is to share as much code between the views of our supported devices, while still providing a non-compromised, optimized design. Ruby-on-Rails helps us a lot here.

Modifying the Controllers

During the mid-phases of developing the MBSJ2012 system, we separated the controllers for all our devices. We had a controller for the PC website, smartphones and for feature phones.

Our concern was that the pages we wanted to provide might differ significantly between devices and we wanted to maintain flexibility. For example, PC websites typically pack a lot of information into a single page; the main content, navigational elements, related links, etc. These would be unnecessary for smartphone websites because there wouldn’t be enough space to display these.

However, rewriting both the Controller and the View for each supported device ended up being very frustrating. This is because while there are differences between devices in how we want to display the information, there was actually a significant amount of stuff that was the same. Because we had separate Controllers and therefore a different folder to contain the Views, comparing the code between devices was very time consuming and it was difficult to analyze to what extend we could DRY up the code. We often did copy & paste, simply because it was too much work to figure out the difference. We desperately needed a way to accommodate multiple devices into a single controller.

Our solution was to generate supplementary and superficial information in the View and not in the Controller. A common idea in MVC is to not let the View directly interact with the Model. That is the idea behind templating languages like Smarty (PHP). Our solution was to ignore this. In Ponzu, the View itself frequently has code that accesses the Model. This enables us to keep the Controller as device-independent as possible. As a side effect, it also makes fragment-caching much easier.

With this solution, we were able to unify the controllers for all our devices. The controllers manage interaction with the main Model for that page, authentication, selection of the appropriate View template for each device, expiration management of local cache, etc. They aren’t responsible for interacting with all the models required to draw a page because that depends on the device.

When we need to add support for another device, we simply add some code to specify which view template it will use. (i.e. Where the PC website uses the “index.html.erb” template, smartphones will typically access “index.s.html.erb” and feature phones will access “index.g.html.erb”. Sometimes though, smartphones will share “index.html.erb” with the PC site.) Other stuff is usually kept the same.

Sharing Kamishibai

Kamishibai is the Javascript framework for providing smooth Ajax-based page transitions and managing the local cache of pages. We wrote Kamishibai in raw Javascript so that we could keep the total Javascript size very small, and therefore usable on mobile devices. As a result, Ponzu shares most of the Javascript between the PC website and smartphone version.

Only when we need to use advanced editing techniques will we call in libraries like jQuery and jQuery UI.

Thoughts about Javascript MVC

Javascript MVC, although gaining in popularity, is not a good fit for Ponzu. It requires that we move Model and Controller logic to the client, meaning that we will have device dependent Models and Controllers. It will make multi-device support significantly harder. We have other reasons why we don’t use Javascript MVC, but this is the largest.

Conclusion

Ponzu is architected from very fundamental levels to optimize total development effort for multiple devices. The pillars for this are;

  1. Web-based with a central server holding all information. Clients are merely display terminals (with caching abilities).
  2. Exploit Ruby-on-Rails for it’s DRY capabilities.
  3. Don’t use overweight Javascript libraries (jQuery).

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.

Native conference applications are little more than eBooks

Since there are so many smartphone application developers now, the prices for a native conference application has gone down dramatically. You can get both an iOS and an Android version for about 1 million yen. However, the features that these applications provide are little more than eBooks. Moreover, preparing the data to be imported into these applications is left to the conference staff; the application developer will not do this.

My prediction is that the native conference applications will be replaced by eBooks in the near future. What is holding us back is the lack of pre-installed ePub readers, especially on the Android platform.

Below I will discuss this in more detail.

Search on native conference applications is very simple and comparable to ePub readers

The search capability on native conference applications is very limited. In fact, native applications (including those for PCs) often have very crude searching. Instead of indexing the text, these applications commonly do a simple scan through all the documents for each query. This makes searching slow and they usually lack effective scoring algorithms. As a result, searching inside native conference applications is not significantly better than similar capabilities on ePub readers. This partially due to the lack of good search libraries, but the largest limitation is the CPU power, memory and battery life on mobile devices. Without abundant resources, indexing simply is not realistic.

In contrast, searching on the server is very sophisticated, and there are amazingly powerful solutions that are available free of charge. You can use complex scoring algorithms so the most *relevant* results are shown on top. You can show *facets*. Speed is very fast because servers typically have enough RAM to store the whole index in memory.

ePub has powerful table-of-content features and links

ePub provides a flexible and easily accessible table-of-contents feature and also the capability to connect pages through links. Therefore dividing thousands of presentations into sessions, and grouping those sessions together by date and time is relatively straightforward. Furthermore, clicking on links provides makes it easy to navigate through an ePub.

Although the UI may be less appealing, it is possible to provide the same navigation as a native conference application.

Limitations of ePub

For MBSJ2012, we tested and created a prototype ePub and viewed it in iBooks on the iPad and iPhone. We observed the following limitations;

  1. Search was extremely slow (probably not an issue unless huge conference)
  2. Table-of-contents were generally OK

Other limitations were that there is no ePub reader installed by default on Android devices, and that the same can be said for PCs.

Recommendations

Although we think that ePubs and eBooks are very suited for relatively small conferences, the problem is support on Android. If Google starts bundling ePub readers on Android, then ePub will be a very attractive solution. If there is a good free application for Android, that might be sufficient.