Building good web based user interfaces is hard work. It involves good programming, good design skills and an understanding of the target audience. Building good interfaces for scientific data analysis is even harder. Difficult concepts must be presented to users in a way that is simple and intuitive yet scientifically accurate. User interface designers tread a thin line between building full and complex ‘exploratory’ systems targeted at field specialists and creating more constrained ‘explanatory’ systems for non-specialists. Often, background documentation for such systems takes a back set to interface design.
This post describes how to use WordPress as a ‘wrapper’ for web based user interfaces and thus provide an easy-to-use environment for both writing and reading background documentation.
iframes for User Interfaces
Another technique that is less subtle is to load an entire web page into an
<iframe> tag. There are several different iframe plugins for WordPress. We have tried out and are happy with Easy iFrame Loader. As always, installation is WordPress easy and use of the plugin is as simple as placing
[iframe_loader src=""] in your pages or posts. We can use this iframe to embed a completely independent user interface inside of a WordPress page giving us a clean separation between our custom user interface and a general purpose documentation environment.
Before we embed our user interface, however, we should create a custom version at a unique URL. This version should remove any decorative headers and footers, navigation bars, documentation links, etc. as we will be using WordPress to provide that functionality. Once you have finished modifying the HTML and CSS styling of the ‘iframe’ version of your user interface you can create a new WordPress page who’s contents contain only this:
[iframe_loader width='100%' height='900' frameborder='0' longdesc='' marginheight=’0′ marginwidth=’0′ name='MyExplorer' click_words='' click_url='' scrolling='no' src='http://mysite.com/MyExplorer/index_iframe.html']
The options to this plugin are described here and should be sufficient to allow for a seamless integration. Depending upon the width of your user interface, you may have to make modifications to the WordPress theme in use. This should be a straightforward task for anyone involved in designing user interfaces for the web.
Structuring WordPress as a Documentation ‘wrapper’
A default installation of WordPress assumes that it will be used as a blog site rather than a documentation wrapper as we are using it here. To function as a wrapper we will need to make some minor modifications.
1) Create a custom WordPress theme
This isn’t as hard as it sounds if you are a web developer. Following the Using Themes documentation, you can take an existing theme as a starting point and then create a few additional php templates that simply omit some of the features we don’t want on every page (e.g. sidebars and commenting). In our first trial we ended up with a new theme directory containing the following templates which override the parent theme:
explorer-page.php footer.php header.php nocomment_loop-page.php nocomment_nosidebar-page.php nocomment-page.php style.css
2) Create a set of pages that reflect the structure of the documentation
Dashboard > Pages > Add New in WordPress and create several new pages that reflect the structure of the wrapper you wish to create. Top level pages will appear in the WordPress navigation bar with drop down menus for pages underneath a parent. As an example:
- Explorer (page displaying the user interface)
- About (parent page)
- Using the interface
- Interpreting output
- Data sources
- Institutional support
- References (articles, papers, etc.)
- News (blog is redirected here)
For each page you will need to assign it one of the templates above. We chose to remove commenting from every page except the Comments page. For space issues, the user interface page (“Explorer”) uses the template which also has no sidebar.
3) Reassign WordPress’ default front page
Dashboard > Settings > Reading in WordPress and click on “Front page displays (*) A static page” and choose the new front page. It could be the “Explorer” page which houses the user interface or it could be some sort of “Welcome” page. The blog posts should be reassigned to the “News” page.
4) Working examples
We have just started working with WordPress in this manner and have two working examples:
- The Futures Explorer displays historical market futures chains.
- The Riparian Management Explorer allows users to investigate the effects of forest management practices on the deposition of large woody debris into streams.
So far we are quite happy with the ease of updating documentation, adding pages and modifying the overall look and feel of these sites without having to embrace a more complex web framework and without having to write much code. WordPress is just powerful enough to address all of our needs and is far easier to work with than any other content management system we know. Following Einstein’s advice, this strategy keeps our code base “as simple as possible, but not simpler”.
Using data visualization to communicate complex ideas is a very challenging and rewarding pursuit. Many different groups are working hard, building user interfaces to make web based interactive data visualization a reality. But even the most intuitive interface that provides access to the best data visualizations is not enough — thorough documentation and background information is also required.
In an ideal world we should be able to marry interactive data analysis with high quality scientific publication in a web-based, participatory, “open source” process that allows for easy analysis, easy data visualization and easy publication of scientific documents.
Hopefully, this posts’ WordPress mashup demonstrates that our ideal world may be within reach as long as we carefully separate functionality and always use the most appropriate tool for each job.