Tag Archives: Technical Decisions

Multi-device support and integration for conferences

To fully support the workflow of a conference participant, it is insufficient to simply provide applications for multiple devices. These devices also have to share information and to work together as one.

For example, a conference participant might want to do the following prior to and at the meeting;

1. Search and browse the sessions and presentations on the PC on his desk at the office, adding some to his “My Schedule”.
2. Do the same on his smartphone or tablet as he commutes home.
3. Do the same on his laptop on the train to the conference venue.
4. At the conference, look up his “My Schedule” on his smartphone or tablet.

To enable this, the supported devices must be capable of sharing information. Ideally, this should be seamless, without the user having to explicitly “sync” his/her device (they will always forget to do that).

Although conferences commonly provide both a website for PCs and smartphone applications, the “My Schedule” feature is often completely independent and is not shared. This is ridiculous.

Ponzu is a single web service that supports multiple devices. It is not a combination of different solutions for each separate device. Therefore, information sharing is built-in.

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.

Supporting participants’ workflows

To understand how to create a great conference system, we have to clearly understand what a participant will want to do prior to the conference, at the conference and after the conference.

Conference IT systems should adjust to the needs and devices that scientists possess. Scientist should not be forced to own certain devices simply to access conference information. The IT systems should be there to help, not rule over the scientists.

We realize that while 100% of scientists have a laptop computer, much fewer own smartphones and even less own tablet PC devices. We recognize that scientists are not necessarily tech-geeks and many will not purchase new fads. There will be “laggards” in the high-tech device sense, but these “laggards” are often the scientists who have a large presence and saying in the scientific community.

We also acknowledge that even though tech-savvy scientists will want to use smartphones or iPads at the conference floor, they will still use traditional PCs in their planning phase at their office. Hence the IT system should seamlessly sync whatever they did on their laptops to their smartphones.

Therefore, an IT system for scientific conferences must work well with laptop computers, and also accomodate new gadgets. Focusing on new gadgets at the expense of laptops is not an option.

Unfortunately, this is contrary to what a lot of conferences are providing.

Looking at competitor activity, it seems that their priorities are;

  1. Provide a native smartphone application.
  2. Provide a rudimentary web site for PCs.
  3. Congre uniquely provides syncing between the PC site and smartphone apps.
  4. Provide a iMode site (only Congre).

Our priorities are;

  1. Provide a cutting-edge experience on PCs so that they can do their preparations effectively.
  2. Attendees can chose whether they want to bring smartphones, tablets PCs, iMode phones or printouts to the conference.
  3. We support smartphones, tablets, PCs, iMode phones on-site.
  4. After the event, they can go back to their PCs and create a report.

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.