Category Archives: Programming

Managing Authors and Participants

Throughout the whole history of scientific conferences, the focus has been on the presentations; what people are going to say. We thought differently.

Whereas journals focus on scientific advancements, we think that conferences should focus on people; the authors, the audience, the critics, the competitors, the collaborators, the mentors, the students and the supporters. The unique fun and excitement of conferences is the result of these people meeting face to face and having headed discussions. If this is what conferences are all about, then the program should focus on the people. By doing this, we should be able to open up a huge number of possibilities on how conferences could enhance human interaction.

Extracting people from the program

Traditionally, authors have been a simple text attribute of each presentation. Our first task was to assign and ID to each author, and to find out which authors were actually the same person. We did this with Nayose.

Future directions

In the future, we might require all co-authors to be entered together with their work email address.

What this has enabled

Recommended presentations

We used author information to provide a list of related presentations. To our knowledge, this is the first time that anyone has done this for a conference.

“Likes”

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).

The need for speed (how Javascript slows things down)

Speed is a very important but often overlooked feature.

Regarding speed on mobile websites, there are several things to consider.

  • Web sites can be very fast to load.
  • Overuse of JavaScript can make mobile websites very slow, even if the resources are cached.
  • jQuery significantly slows down websites, just by being loaded and compiled.
  • Responsive web design is not the same as optimizing for mobile.

Discussion on the web

A detailed discussion about how jQuery can slow down websites was written by Martin Sutherland. I have confirmed this to be true, and this was the first reason I abandoned jQuery Mobile for use in Ponzu (there were many more important reasons, but this was the first show-stopper).

Arguments against responsive web design were put forward by Jason Zimdars of 37 Signals (Behind the speed: Basecamp mobile).

In Ponzu

In Ponzu, we ended up taking a similar route as Basecamp mobile by 37 Signals. Our setup is basically the same except that our Kamishibai Javascript library is much more complicated (but still much, much smaller than jQuery).

With Basecamp mobile, the resource sizes are as follows;

PC HTML:42.92KB, CSS: 515.79KB, JS: 273.80KB
Mobile HTML:16.90KB, CSS: 38.91KB, JS: 14.73KB

You can see that they cut down on the size of JS and CSS immensely. Since the browser has much less CSS and JS to parse and compile, the browser responds much faster after a reload (even when CSS and JS are cached).

With the MBSJ2012 Ponzu system, the sizes are the following;

PC HTML:12.20 + 13.61 + 3.09 = 28.90KB, CSS: 29.30KB, JS: 41.13KB
Mobile HTML:13.62 + 12.69 = 26.31KB, CSS: 18.19KB, JS: 40.96KB

Both Basecamp mobile and Ponzu keep the CSS and JS sizes very small.

Compare this to jQuery Mobile;

Mobile HTML: 2.73KB, CSS: 107.31KB, JS: 91.67 + 286.65 = 372.32 KB

The difference in JavaScript size is staggering.

Where you can see the difference

As mentioned in the articles that I linked to above, the difference in speed becomes apparent when the browser reads in the Javascript and parses it. Caching the response does not help.

When clicking on external links

Whenever browsers move to a new URL, they clear their memory. Therefore even common CSS and JS assets have to be reloaded and re-parsed. This can be prevented if the pages are loaded via Ajax. With Ajax, we keep using the same old CSS and Javascript.

jQuery Mobile mainly uses Ajax when links are clicked. Therefore, once you have loaded a jQuery Mobile page, you won’t notice slowness as long as you stay inside the same site. You will however notice slowness if you click a link to an external site (non-Ajax), and then come back. Coming back will require all the Javascript to be reloaded and re-parsed.

In other words, jQuery Mobile is OK if you stay if you never leave the site. It get’s terribly slow if you move in and out.

When you want to quickly look up something

When you are at the conference venue and you want to check up on you schedule, you want the page to show up fast. You don’t want to wait for seconds until your schedule shows up.

You want to first load to be fast. jQuery Mobile won’t provide that.

When you click on a link on twitter

The great thing about using the Web for the conference system as opposed to a native application, is that you can link to individual pages. For example, you could put a link on Twitter, telling the world how cool your presentation is and why they must come and see it. Anybody seeing that tweet could simply click on the link, and they will immediately see your abstract.

However with jQuery Mobile, it’s going to take a few seconds until the page shows up. Some people might decide that they don’t have enough time to wait and abort.

Conclusion

In Ponzu, we take speed very seriously. Without speed, many of the benefits of the system will be diminished. One of our strategies to achieve this goal, was to keep the size of our Javascript small. Other strategies including caching will be discussed later.

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.

Integration of Exhibitor information

In all current systems that I am aware of, exhibitor information is managed completely separately from the scientific program. However, from a programming perspective, they are actually quite similar.

If we could integrate exhibitor into the conference program, it would be trivial to include luncheon seminars, etc. in search results. It would also be possible to do interesting Ad placements.

Exhibitors as Presentation objects

We could make the Exhibitions and the luncheon seminars as a Session type similar to “Workshops”, “Symposiums” and “Posters”. This way, it will be straightforward to include luncheon seminars into timetables and exhibition maps. It will be simple to also add “likes” and “my schedule” support.

Exhibitors should be free to edit their stuff.

Contrary to the presentations, exhibition stuff does not need to be edited by organizers. The exhibitors should be free to add information as they wish.

Exhibitors should have a live feed.

Prior to MBSJ2012, I entertained the idea of having a live feed of exhibitor activity, much like a Twitter hashtag for the exhibition that was more integrated with Ponzu. However, after seeing the failure that was JBS2012, I’m not so sure. Maybe this isn’t the best way to do it.

How many platforms do we have to support?

The simple question in the title can be reframed as “Do we want to exclude paying participants or distinguished speakers from accessing the conference program?”. Of course the answer is NO.

Although the percentage of smartphone users exceeding 50% of total mobile phone users in the United States, the number is much less in Japan. As of 2012, only about 30% of Japanese mobile phone users use a smartphone. Furthermore, demographics suggest that while younger to middle-aged people are more likely to own a smartphone, elder people, the people who tend to be distinguished professors, are not. Moreover young students are often admitted without charge. Therefore, if we were to calculate the total attendance fees from smartphone owning participants and to compare it with non-smartphone owners, we would probably find non-owners paying more.

Despite this, there is a tendency for conferences to provide native smartphone applications, which will not run on feature phones. Even when there is a website for PCs, it tends to be a very simple and rudimentary search system.

We think that this is a ridiculous situation. Our goal with MBSJ2012 and with the current Ponzu system is to support as many devices as possible, including the millenniums-old but always reliable medium; paper.

Our support strategy is as follows;

  1. PCs: The most ubiquitous digital device among conference participants is the PC. Every researcher has a PC to write presentations and journal articles. They will use their PCs to find out which presentations interest them, and which ones they will want to see.
  2. Smartphones: Smartphones are gaining in popularity and provide a huge amount of functionally. Many researchers will want to use smartphones to check the conference program.
  3. Feature phones: Although not as powerful as smartphones, feature phones are nonetheless capable of browsing websites. If an appropriate website is provided, feature phone users too can easily check the conference program.
  4. Tablets (iPad): Tablets are the ideal device for viewing conference programs on-site. They provide a wide screen while being totally usable standing. However, their popularity is still limited. The people who own tablets are a minority.
  5. Paper (PDF): PDFs are great for downloading and printing onto paper. If you do your homework and narrow down the presentations that you want to attend, then the amount of paper you have to bring is actually quite manageable.

Our commitment is to support all of the above media with the highest quality possible. Supporting five different media is a huge challenge, but was made possible by integrating all the platforms within Ponzu and Kamishibai.

To jQuery or not (jQuery vs. raw JavaScript)

In Kamishibai, we decided to not use jQuery. Instead, Kamishibai is written in native Javascript although we might use CoffeeScript in the near future.

The reasons for not using jQuery are as follows.

  1. Modern browsers have much better JavaScript support and many utility functions are provided natively. For example, we don’t need jQuery map functions anymore since they are provided natively.
  2. jQuery is big. Although this is rarely an issue with desktop browsers, rendering and compiling the jQuery library alone can take something like 2-300ms on a mobile device. This is not acceptable.
  3. A lot of code in jQuery is actually support for legacy browsers. We don’t need that baggage.
  4. The jQuery library is bloated with lots of legacy functions. I’m always confused by the multiple ways of attaching an event to an object, for example.
  5. CoffeeScript solves a lot of the verbosity issues with plain JavaScript. There is no need to use jQuery to clean up the syntax (unless you really dig the functional style).

Regarding item 2., Martin Sutherland has written up a great post titled “jQuery Mobile doubts” which completely covers my concerns about using jQuery in a mobile environment. (I don’t agree with his “Problem 2: Ajax navigation” though, which I will probably cover in a different post). Take a look for a more detailed analysis.

On the other hand, jQuery is fine if we have a fast network connection and are using a PC. jQuery has a lot of great libraries and we want to use them, especially if we need to do complex editing on the desktop.

We also use jQuery as a compatibility layer. jQuery is good for providing support for IE and we code some of our IE-specific polyfills using jQuery.

We never intend to load jQuery on a mobile device though.