Tag Archives: Programming

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 sorry state of PDFs and how we aim to change that

Up till MBSJ2011, the abstracts were also provided as a PDF file. However, the implementation was terrible. The figure below illustrates what was wrong with the PDF.

MBSJ2011 pdf

The reasons for the issues in the MBSJ2011 PDF are probably not simple and I have no reason to doubt that the programmers put a lot of effort into the system that automatically churned out these files. There is however no doubt that one should try to do better.

4 presentations per page is difficult. 2 presentations per page should be OK.

The MBSJ2011 PDF had 4 presentations per page, probably as a remnant of the days when all abstracts were actually printed onto paper. I have heard that there was even a time that 6 presentations were squashed onto a single page. However, 4 presentations per page is very close to or even exceeds the limits. In the publishing industry, 7 points is the smallest font size that is acceptable. The MBSj2011 format uses 6 points (and sometimes 4).

Considering that most people would only want a few tens of presentations at most, we thought that it is not necessary anymore to squeeze 4 presentations into a page; 2 presentations per page should be sufficient. This enabled us to use 10 points for the main font.

Make it easy to print out the presentations that the user wants

Users will only want to print out a small number of presentations. We have to make it easy for them to do this. At MBSJ2012, we provided a separate PDF file for each session so that participants could print out abstracts for the ones that they were attending.

MBSJ2011 did not have this feature, but enabled users to print only those that they had entered into “My Schedule”. This is a feature that MBSJ2012 did not have, and we are thinking about implementing it in the future.

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.