Monthly Archives: January 2013

What should Ponzu include?

One huge oversight in the MBSJ2012 system was that we focused too much on the social aspects of the scientific program, and we didn’t provide enough support for other things (i.e. exhibition, maps, forums, etc.). Due to time and organizational constraints, it’s not clear if we could have done it even if we gave enough though about it. However, it is obvious that future iterations of Ponzu need to be better at this.

The scientific program is usually completely separate

In all the conference websites that I am aware of, the website or smartphone application that provides presentations abstracts is separate from the main conference website. For example, on the MBSJ2012 website, the separation was as follows;

Main conference website

  1. Greetings from the organizing comittee.
  2. Satellite forums.
  3. Registration info.
  4. Submission of abstracts.
  5. Child care information.
  6. Access.
  7. Lodging (external website).
  8. Exhibition (external website).
  9. Other events (job seminars).

Scientific program website

  1. Oral presentations.
  2. Poster presentations.
  3. Other events (yoruzemi).
  4. Social features.

This separation is quite typical.

Information should be more integrated

The problem is that this separation is completely due to technical reasons, and that it doesn’t take into consideration how participants want to use the system.

For example, if a participant was interested in next-generation sequencing techniques, they would not only want to view scientific presentations but they would also want to search through the exhibitions. In this case, the search function should be able to search through both the scientific program and the exhibitions.

More importantly, as conferences become bigger and try to be more than just science, the importance of fringe events become larger. For example, MBSJ2012 had job seminars, high-school student presentations and quick snack stands. MBSJ2013 is also contemplating a wide array of non-scientific events. Increasing awareness of these events is very important, and the website should play an large role in this. More integration is needed to maximize promotion.

Increasing the scope of information on a website presents significant new challenges on the navigation structure. However, when done right, it should increase participation on fringe events and it should also raise interest in the exhibitions. We will discuss some of these following posts.

Framing the scope

The separation prevalent on current conference websites stems from technical reasons. The software and systems that power a) the main conference page, b) the scientific program, and c) the exhibition are all different and are often even run by separate vendors.

To create a better experience for the participants, we have to break down these walls and think about what would be best for the users. We propose the following reasoning.

  1. Participants can juggle multiple websites from the comfort of their office and a high-speed Internet connection.
  2. Participants have limited access to the Internet at the conference venue. Hence they have much less tolerance for juggling multiple sites at the event. Ideally, all information required once the conference has started, should be on a single website.
  3. This means that the following information should be provided on a single website.
    1. Satellite forums.
    2. Registration info (on site).
    3. Access.
    4. Exhibition.
    5. Other events.
    6. Scientific program.
    7. Other events (yoruzemi)
    8. Social features.

     

Left navigation can get annoying

When the breadth of a single website gets very broad, a common way to present all of the information is by using a left navigation widget. MBSJ2012 has quite a long left navigation. The JBS2012 also uses left navigation.

Left navigation is good, but it takes up a lot of space. It’s OK if the content that we need to show on each page is actually quite small. However for pages where content is large, left-navigation breaks down.

In the MBSJ2012, the addition of social features alone required quite a few additional menus. Therefore we broke down the menu structure into the following;

Top-navigation only for most pages

A lot of the pages for the scientific program were very content heavy. The screenshot below shows the poster map, and you can see that there is absolutely no space for a left-navigation menu. Instead we used top-menu navigation. However, it is difficult to put a large number of items on a top-menu (it get’s downright impossible on smartphones). We therefore demoted those items to a sub-menu on the “HOME” page.

Poster map

Left-navigation on “HOME” page

To accommodate extra menu items without overloading the top-menu, we put these on a sub-menu on the “HOME” page.

HOME page MBSJ2012

The following is an alternate design that we might use in the future. By using icons, we can make each section more attractive. This might be what we need to get participants’ attention.

Prototype HOME

Conclusions and Future directions

Future conference systems will have to integrate more information into a single website. The challenge is to provide a navigation system that is not only easy to use, but also raises awareness of fringe events and features.

The MBSJ2012 introduced social features as a fringe capability, and used a sub-menu on the “HOME” page for navigation. Although we think that this was sufficient from a usability standpoint, further measures are needed if we want to aggressively promote new features.

Server infrastructure for MBSJ2012

For the MBSJ2012, we used the following server hardware;

Vendor: SAKURA Internet
Type: 8G VPS
Memory: 8GB
Disk space: 800GB
CPU: Virtual 6 core

During peak times, CPU usage reached 80%. Even at non-peak, usage hovered around 60%. This indicates that performance was not good enough.

In the future, the complexity of Ponzu and the number of participants actively using the system is sure to increase. Hence further performance optimizations and / or more powerful server hardware will be necessary.

We will do more detailed performance analyses at a later date.

Due to security reasons, we will not disclose server software configurations.

“Like” statistics for MBSJ2012

 

We analyzed the number of “likes” during the MBSJ2012.

Total number of likes

The total number of likes reached over 70,000 likes. The number of likes per day increased two weeks prior to the conference.

likes report total 20121216

Number of likes per participant

The number of participants who “liked” at least once was 2,678 people. Using 6,000 for the total number of participants, 2,678 / 6,000 = 45% of participants used the “like” button more than once.

The total number of participants who logged in at least once was 5,059 people. Using 6,000 for the total number of participants again, 5,059 / 6,000 = 84% of participants logged in. This means that 16% of participants never logged in to the online program system (however, since you can view the  program without logging in, the actual percentage of participants who used the system is likely to be higher).

A significant number of people “liked” more than 100 times.

likes report per user 20121216

Number of “likes” per presentation

The median number of “likes” for posters was 11 likes. For oral presentations, the median was 31 likes. Most importantly, only 21 presentations were without any likes. The vast majority of presentations had more than a few likes.

likes report per presentation 20121216

 

Interpretation of the results

According to the theory of Diffusion of Innovations, innovation is communicated over time in a stepwise fashion among members of a social system, via a process that is similar to diffusion. Technology laggards constitute about 16% of a given population and these people tend to have strong negative feeling towards change.

Diffusion_of_ideas.svg from wikipedia

Similarly the Chasm theory describes a chasm between early adopters and the early majority. The Chasm theory dictates that if a product can cross the Chasm and be successfully adopted by the early majority, then the probability of it becoming the de facto standard is high.

These two theories lead us to interpret the above results as following.

Participants not using the online conference system are the laggards

The percentage of participants who did not use the online conference system are likely to be the “laggards”. These people are adverse to change and tend to be advanced in age. Since it is difficult to influence these people, making them change will be difficult.

The “Like” feature has crossed the Chasm and is in the early majority

With 45% of participants “liking” at least one presentation, we can conclude that the “like” feature has crossed the Chasm (2.5 + 13.5 = 16% adoption) and is now in the middle of the early majority phase. It is highly probable that the adoption of the “like” feature will continue into the late majority, becoming the de facto standard, assuming that it is provided at future conferences.

How the MBSJ2012 system was received on Twitter

We have created a Twitter report for the MBSJ2012. We searched Twitter for various keywords related to MBSJ2012 and filtered out irrelevant tweets. To reduce duplicates, we did not include retweets. We included both positive and negative feedback.

To compare, we also searched tweets for JBS2012. We added what we found, but there weren’t too many.

Twitter Feedback (PDF 4.8MB)

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.

Rethinking REST from a Kamishibai perspective

REST is the way the web was designed to work. Thinking of URLs as resources is a guiding principle that aids design of web applications and brings order to URLs.

Browsers traditionally considered URLs to represent pages that would be shown on a single browser window, with the exception of frames. The Kamishibai approach considers URLs to represent fragments of pages. This is similar to frames.

The problem with a one-to-one correspondence between REST URLs and pages is that pages have a lot of redundancy. A single web page shares a lot of common elements with other pages. It is much more efficient to manage web resources at a fragment level.

When we think of URLs as HTML fragment resources, then we can rethink what the root path stands for. In the fragment model, the root path stands for the boot loader, the initialization of the application. It does not stand for any particular page. Therefore, it is actually more natural to use the hash as the navigation indication. The hash based approach is no longer a hack; it is representative of how the web application works.

Another way of seeing it is to rethink what the hash originally stood for. The hash was a way to tell the browser which portion of the web page to show. We can frame the Kamishibai concept in the same way; In Kamishibai, the hash indicates the ID of the HTML element that we want to display in the front. In some cases, the HTML element will already be loaded, which makes it virtually identical to how regular hashes are handled by default. If the HTML element is empty or has not been loaded, Kamishibai loads that page via AJAX. However, this is invisible from the HREF. The HREF simply tells the browser that it wants to view a certain fragment within the root URL resource. It is Kamishibai’s responsibility to prepare that page and display it with animations.

Therefore, we can think of Kamishibai as actually adhering to REST principles. Since it does not alternate the response based on whether it is an AJAX request or not, in some ways it adheres more closely that PJAX.

Looking at the Kamishibai world from a REST perspective, the root URL which holds the whole application can be thought of as a huge single page that you can navigate through with hash links.

Thoughts on PJAX

Before starting work on Kamishibai, I was working with PJAX. PJAX was a nice and clean idea for implementing the HTML5 History API. The promises of PJAX was speeding up of web loading times by virtue of AJAX partial page loading, while at the same time, maintaining standard URLs and being web crawler friendly.

There were several problems with PJAX that made it difficult to work with and suboptimal for a flaky network environment.

For situations where the AJAX container changed between pages, PJAX simply reverted to re-issuing a full page load. This happened often when going backwards. For example, if we were moving forwards towards a page that changed in only a small fragment. Then we would set the AJAX container to the small fragment and this is all that is entered into the History state object. However, when we move back, then that would mean that we have to redraw more than the just the small fragment; we have to redraw the stuff surrounding it. PJAX simply balked in these situations and reverted to a full page load.

It’s great that with PJAX, there is always a way to simply reload the page and get a regular response that will always work. The issue is that it reverts to this too easily.

Also, this means that PJAX will send out two different types of requests depending on the situation it finds itself in. This makes it complicated and wasteful if we want to store the responses in localStorage. For example, if we do a reload of a deep-linked page, we would receive the whole HTML page. The question is, do we want to store all of it in localStorage under the deep-URL? When we request the same URL via PJAX, should we actually use the HTML body in localStorage? What if the case is reversed and we have an HTML fragment in localStorage, but the browser has requested a full reload. What should we show?

I was also unhappy with the way PJAX tended to waste the History memory. PJAX stores a copy of each AJAX body in the History state object. The problem is that this information can only be retrieved when going back. We can’t use this cache to load pages going forward and we have no way to check whether a certain fragment has already been stored. Given the low speed and reliability of mobile networks and the limited RAM of mobile devices, it doesn’t make sense to be so conservative with the use of precious memory.

Another factor is the lack of support of History API in the Android 4.0 and 4.1 stock browsers. Of course there is Chrome on these platforms, but it doesn’t make sense. The lack of History API on Internet Explorer up to 9.0 doesn’t help either, since it means that half of the browsers in the conference room will be gobbling up unnecessary amounts of bandwidth.

Since PJAX takes a one-page-at-a-time approach to the idea of URL resources, it is very compatible with a pure HTML document model, but is not really efficient for cases where bandwidth is limited. The issue that I had is with the use of the application cache manifest. The application cache manifest work with a full HTML document as the smallest unit (fragment). It does not work with Ajax, and requires a full HTML page reload. Therefore it doesn’t work at all with PJAX unless we cache all entry URLs. On the other hand, if we take a hash-based navigation approach, we will only need a single resource URL in the cache manifest. This URL will return the HTML header and body responsible for the “chrome” of all pages. To put it another way, if we wish to use the cache manifest with PJAX, the only way to do it would be to have entries for every single page that could be an entry-page. This would be extremely wasteful, and even if we could do this, we wouldn’t be able to navigate between these pages with AJAX since AJAX wouldn’t access the cached pages.

In summary, we decided against PJAX due to issues in the current implementation. It is also very likely that we will not use PJAX even if the library improves and browser support becomes more ubiquitous. This is because we feel that PJAX cannot use the cache manifest efficiently.

What is Kamishibai?

Below I describe the design goals of Kamishibai.

Kamishibai is a compositior

Kamishibai is a simple compositor, similar to the Quartz Compositor in Mac OS X. What this means can be illustrated by what Kamishibai does, and what it does not.

What Kamishibai does not.

  1. Kamishibai does not generate HTML from data through the use of templates.
  2. Kamishibai does not contain any business logic in the form of “Models”.
  3. Kamishibai is not a Javascript MVC framework.
  4. Kamishibai will never target native application development through phoneGap, etc. That’s not what Kamishibai is for.

What Kamishibai does.

  1. Kamishibai requests HTML fragments from the server and stores them in a local cache.
  2. Kamishibai replaces portions of the current DOM with HTML fragments from the server and displays them.
  3. Kamishibai intelligently places HTML fragments from the server into appropriate locations in the DOM based on attributes on the fragments.
  4. Kamishibai combines multiple fragments to generate a single DOM.
  5. Kamishibai local cache stores HTML fragments and also expires them.
  6. Kamishibai intelligently examines current network stability and uses the cached fragment or requests a new one from the server accordingly.
  7. Kamishibai interprets the URL and makes suitable Ajax requests to generate the page.
  8. Kamishibai intelligently discovers and fragments that are currently missing and requests them from the server.
  9. We think that explicit syncing sucks. Kamishibai will make syncing almost invisible to the end user.
  10. Kamishibai works offline.
  11. Kamishibai does not enforce a specific UI design and does not come with widgets. Designers are expected to be capable of coding their own widgets with HTML and CSS. This makes design extremely flexible so you can easily brand you website.

Why isn’t Kamishibai Javascript MVC?

  1. Ruby and Ruby-on-Rails are superb. There’s a huge amount of functionality that you will miss with current Javascript MVC frameworks.
  2. Javascript MVC frameworks typically require a lot of Javascript on the browser. This will make first load times for mobile devices extremely slow (seconds for Javascript MVC vs tenths of seconds for Kamishibai).
  3. Rendering HTML on mobile devices will always be slower than on powerful server hardware. Furthermore, pages rendered on the server will be cached for later use, making it even faster.
  4. If the server is slow, you can simply add more hardware. You can’t do that with client side libraries. You are always limited by whatever cheap and slow hardware the customer choses.
  5. Javascript MVC requires a steep learning curve. On the other hand, Kamishibai only requires a few extensions onto HTML, CSS. You don’t even need to learn Javascript to get started. You can easily convert preexisting websites, and even WordPress sites.

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.

A design that respects the authors work

The previous designs for conference programs showed no respect for the hard work of the authors. Abstracts were treated simply as entries in a database. We strongly object to this and propose that conference programs should be designed with the same care as printed academic journals.

Example of bad design

  • Abstracts are treated as database fields.
  • All the font sizes and styles are the same. Important information (titles, number) should have a larger font size, while affiliations should be smaller (as is typical in a printed journal).
  • As discussed in “Multi-lingual support”, displaying both English and Japanese next to each other makes it harder for readers to quickly read the content and should be avoided.

2011 presentation

Ponzu design

Below is the design for MBSJ2012.

  • The design is based on top printed journals.
  • Font sizes, styles and colors are used to make each element easily identifiable.
  • Important information (title, number) is in larger font sizes.
  • A two column layout is used so that readers do not have to move their eyeballs long distances.

MBSJ2012 design 2

Conclusion

Historically very little effort was put in the design of conference programs. It is time for this to change.