Thursday, November 10, 2011

Steve Jobs didn't kill mobile flash and how to build a climate software strategy

I can't help but smile when so called "tech experts" proclaim that "Steve Jobs killed (mobile) Flash." While he did have a hand in it (so did Google by spending $100M+ on open video codecs), it is a simple fact that no one can kill a good product**. The bottom-line is: Adobe Flash was/is a poorly designed, buggy, and insecure platform that adds virtually no value to web applications. As a result, Adobe is the main reason Flash failed.

The reason I bring this up here is that an increasing number of climate applications are Flash driven. This is bad for several reasons:

  1. The applications aren't cross-platform and you must have Flash installed
  2. Using Flash has numerous security threats to your data and servers
  3. Web pages that predominantly use Flash have load times slower than evolution.

It is of critical importance that we produce climate analysis and visualization tools to the general public to increase awareness and transparency on climate challenges. Subsequently, these software products must be accessible to the widest range of users possible. The number one rule is that you should never release software that you used internally in your laboratory to the general public without a proper strategy (it is imperative, however, that you provide all source code of your research to publication reviewers and fellow scientists to objectively evaluate your results). The main reason being that, your software was originally written with only you in mind. Such software is not only unusable by non-experts, it lowers the standards of what's "customer ready" software and negatively affects out community as a whole.

As a climate scientist, if you are thinking about launching a major software product, here are a few questions that can help shape your digital strategy:

  1. Is the product I am using proprietary? Never ever use closed-source proprietary software (such as Adobe, MATLAB, Apple iOS, Microsoft C# or Silverlight, etc.) First, just like in Adobe's case, there is no guarantee that proprietary software maker won't just pull the plug on the platform/language you are using. Second, by using a comercial product you have effectively shot yourself in the foot as far as your product reaching a wide audience. Most users won't purchase/install additional products to use your code. Finally, the more closed the platform you are using the less likely you will find someone to efficiently design, maintain, and update your platform.
  2. How does it handle large amounts of data? The two major uses of climate software is to analyze/process or visualize large amounts of data. You should, therefore, optimize your software for these two purposes first before you dive into fancy features. The main problem with Adobe Flash is that it couldn't handle the basic purpose it was design to do: smoothly display multimedia content on the web. Don't let your software have the same fate.
  3. How does it run on multiple platforms? Your software should have virtually no entry barriers, except owning a computer. Windows is no longer the computing platform of choice, especially in scientific circles. Any new software should have only a handful of features but be cross-platform (windows, linux, unix, Mac, etc.) Similarly, your software should be flexible enough to read a variety of climate data (NetCDF, HDF, Grib, etc.) if you allow users to analyze their own data. This should be as seamless as possible (i.e. don't force users to reformat data in a certain format, ect.)
  4. Should I have a web/mobile component? One way to avoid cross-platform development is to have a cloud-based application. There a few issues with this route mainly that you would have to host your own servers, which is a pain. Also, if you have numerous users you will most certainly have to distribute the workload across multiple machines to not jeopardize the user experience. A good option is to have your codebase hosted on Google servers and write you programs in Python or Java through Google App Engine.
An example of a good climate software is NASA's data visualization tool Panoply. Given that it is a data viewer, it serves its primary purpose by seamlessly handling multiple data types. It is also cross-platform and does not requiere any installation. Obviously is has some flaws: First, it is buggy and sometimes crashes. Second, it is sometimes finicky on which data it displays. Third, given that all climate data are huge, it offers no way to automatically visualize and save a large number of plots (i.e. you have to manually go through each figure and save it).

What are some of your favorite climate software and what's on your wish list?

** An example of a single person not being able to kill a good product is Dropbox. Dropbox is a cross-platform, well designed, and minimally elegant data-syncing product. Last year, Apple tried to buy Dropbox but its co-founders refused. As a response to the rejection, Apple launched iCloud but that will hardly affect Dropbox because they have a great product and have conquered the majority of the market. Something Adobe didn't have.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.