Inventory of Physics Simulations in HTML5/JavaScript

When I discovered last winter how useful JavaScript and the HTML5 canvas element can be for physics simulations, I was astonished that there seemed to be so few examples of such simulations out there. That situation is rapidly changing. Here’s an inventory of the examples I’m aware of at this time.

My own portfolio of three simulations is unchanged, except for a few bells and whistles added to each of them:

• Ising model
• Molecular dynamics
• Fluid dynamics

Over the summer, with support from the Weber State University Beishline Fellowship, our student Nathaniel Klemm ported five of the simulations that my colleague Farhang Amiri uses in his general education physics course:

• One-dimensional projectile motion
• Two-dimensional projectile motion
• Kepler’s laws
• Distribution of speeds in a gas
• Ohm’s law

(The original versions of these simulations were written by Farhang Amiri and Brad Carroll in Adobe Director, and runnable through the Shockwave browser plugin. These were part of a much larger collection of simulations that they developed in the 1990s. Unfortunately, support for the Shockwave plugin is becoming problematic.)

Andrew Duffy of Boston University has created some simple mechanics simulations:

• Duffy HTML5 directory

These would be good examples for a beginning HTML5 developer to learn from, since their code is short and straightforward. (Andrew and I will be giving a workshop on beginning HTML5 simulation development at the 2014 AAPT summer meeting next July.)

Dan Cross of Haverford College has created two extremely elegant simulations that I especially recommend:

• Zeeman’s catastrophe machine
• Normal mode decomposition

John Denker has a simulation that draws hydrogen wavefunction scatter plots:

• Scatter plot of electron probability

Dan Styer and Noah Morris of Oberlin College have created a nice demonstration of two-slit interference:

• Interference simulator

This simulation uses the jQuery UI library for its slider controls, which unfortunately makes them unusable on devices that rely on touch events.

GlowScript is a 3D graphics library built on WebGL, created by David Scherer and Bruce Sherwood who modeled it on their earlier VPython system. GlowScript is accompanied by a web-based development environment that eliminates the need to write HTML, although it can also be used as an ordinary JavaScript library. Some collections of GlowScript examples are posted here:

• GlowScript examples
• Bruce Sherwood’s GlowScript examples

Unfortunately, the use of WebGL makes GlowScript simulations runnable only under certain browsers. As of this writing they will not run on most mobile devices, although some mobile devices offer partial support.

Francisco Esqembre of the University of Murcia has created a high-end development environment for quickly creating physics simulations, called Easy Java Simulations. Although EJS is a Java program, the new version 5 beta release can output stand-alone HTML5/JavaScript code. More than a dozen examples are now posted here:

• OSP EJSS page at comPADRE

The PhET group at Colorado has recently gone public with its first six HTML5 simulations for introductory physics and chemistry:

• PhET HTML5 simulations

As you would expect from PhET, these simulations are extremely professional and hence the code, which relies on a vast collection of libraries, is unreadable by mortals.

All of the simulations listed above were created by (or under the supervision of) academic physicists, primarily for the purpose of physics education. But of course the vast majority of graphics-intensive HTML5 development is being done by game developers. Here are a couple of these efforts that contain good physics and are fun to play with:

• xkcd Time Catapult by Manfred Hantschel
• Oliver Hunt’s simple fluid dynamics simulator

And that’s my list for now. If any readers out there would like to add to this list, feel free to leave links (noncommercial, please) in the comments.

Java vs. JavaScript vs. Python

At last week’s AAPT meeting I presented a poster showing how fun and easy it is to do fluid dynamics simulations using current personal computers and software. These simulations are computationally intensive, so every bit of performance counts. On the other hand, students and hobbyists and other nonexperts like myself rarely have time to write code that will squeeze every last drop of performance out of our machines. Also, it’s hard to share code written in C or Fortran—the languages of professionals—with other nonprofessionals.

So in recent years I’ve been writing all my physics simulations in Java or Python or JavaScript. And for my poster presentation I decided to clock these languages against each other. I had already written two-dimensional lattice-Boltzmann fluid simulations in all three languages (code posted here), so all I had to do was run them with the same lattice dimensions and measure the number of calculation steps per second. Here are the benchmark results:

This algorithm performs about a hundred basic arithmetic calculations per lattice site per time step, so the Java version, at over 1000 steps per second for 16,000 lattice sites, is performing well over a billion calculations per second on my 2.3 GHz i7 MacBook Pro. I suspect that C or Fortran would run about twice as fast.

All three versions of this simulation include animated graphics, but I was careful to do the graphics in ways that didn’t significantly slow down the computation. In Java, the graphics automatically runs in a separate thread, presumably on a separate processor core.

Since my laptop has four processor cores, I could have sped up the Java version about threefold by parallelizing most of the computation. But that would violate the spirit of this test, which is to see what can be done without getting too fancy with the code. Perhaps Python can also be configured to make better use of my hardware, but I have no clue how to do so (I’m simply using the EPD Free Python installation). I did use NumPy to vectorize everything in Python, since Python loops are glacially slow.

The JavaScript results are shown for only the two fastest browsers, Chrome (version 27) and Firefox (version 22). It seems that Chrome has gotten slightly faster since my earlier tests in March, while Firefox has sped up significantly since then but still hasn’t caught up to Chrome. Both, in any case, offer remarkably good performance at more than half the speed of Java. Safari (6.0.5) is no faster than the previous version, coincidentally about the same speed as Python/NumPy. Opera (12.16) is still far too slow to bother with for this kind of simulation.

Of course, these three languages serve rather different purposes. JavaScript is for web deployment, while Python is for tinkering around on one’s own workstation. Java is fading away as a web platform, but I still like it for personal use when speed and/or interactivity is important.

Update, December 2017: In the four years since I wrote this article, JavaScript execution speed under all browsers has continued to improve. Some typical values that I obtained recently (on the same 2012-vintage MacBook Pro) were 787 steps per second in Chrome, 875 in Firefox, 770 in Opera, and 399 in Safari. The performance isn’t very consistent from one run to the next, and I’m not sure why. I’m also perplexed by Safari’s poor performance, because it does about as well as the other browsers on other computationally intensive physics simulations. The other three browsers are fast enough that it makes sense to increase the number of calculation steps per animation frame from the default 20 up to 30 or even 40. Then Opera typically runs at about 900 steps per second and Chrome and Firefox are a little faster still, rivaling the performance of Java.

JavaScript and HTML5 for Physics

Like a number of other physics educators, I’ve invested a fair amount of time and energy over the last decade creating educational software in the form of Java applets.

I love Java for several reasons. It’s a reasonably easy language to learn and use, with logical rules and few exceptions. It gives very good performance, typically within a factor of 2 of native code. And, crucially, for a long time it was installed on nearly everyone’s computers, so most students and others could run my applets immediately, without any huge downloads or configuration hassles.

Unfortunately, that last advantage is now disappearing. For one thing, more and more people are replacing their computers with mobile devices that can’t run Java. Compounding the problem, security concerns have recently prompted many people (and companies) to disable Java on their computers. Some tech pundits have gone so far as to pronounce client-side Java dead.

While it’s likely that Java can be kept on life-support for several more years, its long-term prospects appear grim. So it’s time for us Java applet programmers to abandon this obsolescent technology and find an alternative. But is there one?

Until very recently, I thought the answer was no. Sure, I was aware of the new HTML5 canvas element, which allows drawing directly to the screen via JavaScript, right inside any web page, with no plugins. But this technology has mostly been described as a replacement for Flash, not Java, and I assumed that, like Flash, it would mean sacrificing a lot of performance. I couldn’t imagine that a scripting language could ever approach Java’s speed. Indeed, in an early test of a canvas animation a few years ago, I found the performance to be so poor that computationally intensive physics simulations were unthinkable.

I then avoided thinking about the issue until this winter, when the repeated Java security alerts provided an abrupt wake-up call. Apparently knowledgable geeks all over the internet were telling the public to disable Java, insisting that nobody should ever need to use it again.

So I decided it was time to give JavaScript the HTML5 canvas another try—and I was simply stunned. At least under Chrome, I found that graphics-intensive physics simulations run about half as fast in JavaScript as they do in Java. I can absolutely live with that factor of one-half.

My specific tests were with three simulations that I’ve spent a lot of time with over the years. First I coded a basic Ising model simulation to go with the corresponding section in my Thermal Physics textbook. Then I tried a molecular dynamics simulation, similar to the computational physics project I’ve assigned many times and the applet I wrote a few years ago. Finally, encouraged by these successes, I coded a fluid dynamics simulation using the lattice-Boltzmann algorithm, which I learned with the prodding and help of a student, Cooper Remkes, as he worked on a class project in late 2011.

As the following graphs show, the choice of browser can make a big difference. Each graph shows the relative number of calculation steps per unit time, so higher is better in all cases. I ran the simulations on my new MacBook Pro with a 2.3 GHz i7 processor, and also on one of the Windows 7 desktop PCs in the student computer lab down the hall from my office, with a 2.93 GHz i3 chip. Comparing these two machines to each other wouldn’t be fair at all, and comparisons of the three different simulations wouldn’t be meaningful either, so I’ve normalized each group of results to the highest (fastest) value in the group. The browser versions were Chrome 25, Firefox 19, Safari 6, Opera 12, and Internet Explorer 9; all but the last of these are current, as far as I can tell.  (I tried I.E. 10 on a different Windows machine and found it to be only a little faster than I.E. 9, in comparison to Chrome. I couldn’t easily find a Windows PC with Safari or Opera installed.)

The Ising model benchmark tests a mix of tasks including basic arithmetic, if-else logic, accessing a large two-dimensional array, random number generation, evaluating an exponential function, and drawing to the canvas via context.fillRect. By contrast, the molecular dynamics (MD) and fluid dynamics (FD) simulations heavily emphasize plain old arithmetic. The fluid simulation, however, does more calculation between animation frames, uses much larger arrays, and uses direct pixel manipulation (context.putImageData) to ensure that graphics isn’t a bottleneck. The MD simulation seems to be limited, at least on the fastest platforms, by the targeted animation frame rate.

As you can see, the performance of Opera and I.E. on the MD and FD simulations is a major disappointment. Let’s hope the JavaScript engines in these browsers get some big speed boosts in the near future. Safari and Firefox seem to give acceptable performance in all cases, though neither measures up to Chrome on the demanding FD benchmark. Chrome is the clear all-around winner, although it’s a bit disappointing on the Ising simulation under Windows.

And how does this performance compare to Java? It’s hard to make a comparison that’s completely fair, because of differences in the languages and, especially, the available graphics APIs. But in general, I’ve found that similar simulations in Java run about twice as fast as the best of these JavaScript benchmarks.

The bottom line is that if you choose your browser carefully, JavaScript on a new computer is significantly faster than Java was on the computers we were using during its heyday (a decade ago). And of course, for simulations that don’t require quite as much computational horsepower, JavaScript and canvas can also reach the proliferating swarms of smartphones and tablets. I’m therefore a bit puzzled by the apparent shortage, at least so far, of physics educators who are creating JavaScript/canvas simulations. I’m sure this shortage won’t last much longer.

[Update: See the comments below for further details on the benchmarks, especially for the Ising model simulation.]

Inside Macintosh

The web is currently flooded with eloquent tributes to Steve Jobs. I’ll chime in with a personal footnote.

In 1985, when I was a graduate student at Stanford, I bought my first Macintosh computer. Like so many others, I was stunned by its elegant graphics-based interface. Like fewer others (though quite a few at Stanford), I had to learn to program it.

The programmer’s manual, Inside Macintosh, was still a work in progress and hadn’t been officially published. But in response to the tremendous demand, Apple put out a “promotional edition” printed on cheap paper in a typewriter font, bound in a thick volume resembling a phone book. For a short time you could get a copy for only $25, and my check was in the mail as soon as I learned about the offer.

My original Mac is now long gone, but I still have that promotional edition of Inside Macintosh. Paging through it brings back a flood of memories.

Most of the manual, of course, is nuts-and-bolts technical details—what programmers would now call “API reference” material. But as you study it, a bigger picture comes into view: the exquisite care that went into the design of the Mac operating system, built from the inside out with the user in mind. The enthusiasm of the Mac development team occasionally bursts out in a word like “remarkable” or “amazing” amidst the manual’s otherwise dry prose. Even though this edition of the manual was hastily assembled and printed, someone made sure it had a full-color cover with that classic minimalist line drawing of a Mac.

The most important chapter of the manual, up at the front, is titled User Interface Guidelines. Rather than describing the operating system from a programmer’s point of view, this chapter instructs the reader on the underlying principles of Mac software, and firmly invites the reader to conform to these principles:

“The Macintosh is designed to appeal to an audience of nonprogrammers, including people who have previously feared and distrusted computers. To achieve this goal, Macintosh applications should be easy to learn and to use. To help people feel more comfortable with the applications, the applications should build on skills that people already have, not force them to learn new ones. The user should feel in control of the computer, not the other way around. This is achieved in applications that embody three qualities: responsiveness, permissiveness, and consistency.”

These words were revolutionary in 1985, and they made a lasting impression on me. Even today, most programmers need to pay more attention to them.

More generally, Apple has set an example for creative people everywhere: Don’t settle for mediocrity and mere functionality. Always strive for excellence, and be sure to incorporate the joy of the creative process into your work. Patiently refine every detail of your creation, while staying focused on its ultimate purpose.

That was the ethos that Steve Jobs brought to Apple, and to so much of the world.

Molecule Sandbox

Are your children already tired of their Christmas toys and games? Or would you like to see them play with something less violent and more educational?

Vi Hart’s math doodle games can provide countless hours of fun. But another option that you may want to try is the Molecular Dynamics Applet that I created three years ago. It was originally intended for college students, but I soon discovered that small children love it.

The MD Applet is a sandbox for playing with atoms and molecules. Make up to a thousand atoms, large or small, in your favorite color. Watch them jiggle around endlessly, attracting and repelling their neighbors. Add energy to make liquid droplets boil; remove energy to make a gas condense and then freeze into a solid crystal. Start with an orderly arrangement and watch entropy increase. Connect atoms together with bonds, and even build simulated nano-scale machinery.

I don’t spend much time around small children, but Christmas is often an exception. This year I found myself entertaining (and being entertained by) a delightful seven-year-old who kept coming back, asking to play some more with the MD Applet. She asked her deepest question almost immediately: Why don’t they all just fall down and stop?

And in between molecular dynamics sessions, she learned how to draw stars with seven, eight, and even ten points!

Mobile Computing Growing Pains

The experts have been saying for years that the future of computing is in mobile devices. I ignored them until recently, but now the iPhone, iPad, Kindle, and similar gadgets have gotten my attention. I own an iPhone myself, and I’m beginning to see the potential of mobile platforms for some of my own creative projects. These projects might include textbooks, educational software, and perhaps a trail guide to the local area.

I’ve already written about some of the challenges in delivering a textbook or trail guide on a mobile device. But perhaps the biggest challenge facing any of these projects would be the diversity of competing mobile platforms, and the fact that only a minority of the potential audience owns any one of them.

The obvious solution is to create content in a cross-platform format. This is trivial for a book whose formatting doesn’t matter. But a versatile and attractive electronic format for physics textbooks doesn’t seem to exist, so some custom, platform-dependent coding would probably be required. A good, practical trail guide would require much more coding. And a decent interactive simulation of molecular dynamics or the night sky requires a thousand or more lines of user-interface code.

For several years I’ve been writing these kinds of simulations in Java, which makes them portable to virtually all of today’s desktop and laptop computers--and deliverable over the web. I can’t overstate what a huge advance this is compared to the bad old days when you had to write native code that would run on only one platform. (The native Mac simulations that I wrote between 1985 and 1992 were never widely used, and now they don’t even run on the new Macs.)

Unfortunately, mobile devices don’t run Java applets. Apple’s mobile devices don’t support Java at all. I’m not absolutely wedded to Java, but I’ve been hoping that some kind of usable cross-platform development environment for mobile devices would soon come along. Last week my hopes got a major setback.

Apple has now added the following sentence to its iPhone developer license agreement:

Applications must be originally written in Objective-C, C, C++ or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++ and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

The geek blogs are all abuzz over this new rule, and rightly so. It seems to prohibit virtually any sort of cross-platform development tools, and even restricts what programming languages you can use to develop iPhone apps. Bloggers are inferring that Apple isn’t merely trying to maintain the quality of apps; it’s literally trying to make life difficult for any developer who wishes to deploy an app on multiple mobile platforms.

For a part-time, half-assed developer like me, this move by Apple is devastating. I write software not to make money but to reach a target audience. I have no intention of writing software that can reach only the fraction of that audience that owns a particular device. And I don’t have the time or the resources to port software from one device to another.

Eventually, I suppose, the situation will improve--just like it improved for personal computers when Java came along. Until then, I’ll keep deploying physics simulations as Java applets for personal computers. And I’ll keep publishing books in the tried-and-true format that’s universally readable by all.

iPad Textbooks

I have no immediate plans to buy an iPad, since it can’t replace either my iPhone or my laptop computer. But as a textbook author, I’m intrigued by the iPad’s possibilities as a book platform.

Following a link from the New York Times, I just read a thoughtful blog essay by Craig Mod on the future of printed and digital books. Mod wisely divides book content into two categories: “formless” (which is trivial to port from one delivery platform to another) and “definite” (which is created with a particular platform in mind, using that platform’s physical features in an essential way). Last year’s digital book platforms--Kindles and iPhones--were fine for formless content, and allow us to foresee a day when these kinds of platforms will be common enough to make most mass-market paperback books obsolete. The iPad, according to Mod, changes the picture by opening up new opportunities for digital definite content.

Mod doesn’t specifically mention textbooks, but they’re discussed in the comments below his essay. Electronic textbooks have some obvious advantages: they’re less bulky; their text can be cross-linked and searchable; they can incorporate multimedia content; and they can link to related content on the web. Also, textbooks are so expensive already that the additional cost of an electronic reading device shouldn’t be much of a barrier.

As an author, I’m attracted not only by these advantages but also by the prospect of no longer having to worry about page breaks. Both of my textbooks were created using TeX, a mathematical typesetting system that mostly frees the author from thinking about form. But inevitably, when a book is full of equations and illustrations, one of the last steps before going to press is to manually tweak the layout to minimize awkward page breaks. Even then, there will be many places where students end up flipping a page back and forth to see what’s on both sides. Electronic books on portable devices won’t show as much information at once, but at least they can (if done correctly) present an entire chapter on a single scrollable page, with no artificial discontinuities.

Unfortunately, the technology for good electronic physics textbooks isn’t yet where it needs to be. For one thing, there still doesn’t seem to be a good way to incorporate complex mathematical equations into electronic documents. In html pages, equations are usually rendered as ugly, low-resolution bitmap images. A pdf document can incorporate equations made of scalable fonts, but you can’t (as far as I know) create a pdf without breaking the document into pages.

Another limitation of electronic textbooks is that it’s hard to scribble notes in the margins. Reading a textbook should be an active experience, during which the student frequently jots down thoughts and questions. (When my thermal physics textbook was published, I made sure the publisher gave it wide margins for students to write in.) Perhaps, though, the iPad can help here. With the right software, a reader should be able to add text annotations to a document using the on-screen keyboard. And with the large touch-screen, it should even be possible to add graphical annotations that include math symbols and sketches.

So even though I don’t yet plan to buy an iPad, I’ll be eager to borrow one and check out the iPad book reading experience.

Yet Another Planetarium Simulation

Last November, as another semester of teaching Elementary Astronomy drew to a close, I finally broke down and started writing my own planetarium simulation.

On its face, this was a ridiculous waste of time. There are already dozens, if not hundreds, of planetarium simulation programs that will show you where the stars and planets appear in the sky, as viewed from your chosen location at your chosen time. They run on every microcomputer platform and many handheld devices. Some are extremely sophisticated, with databases of millions of stars, beautiful images, and even the ability to interface with a telescope.

But I wanted something a little different. To be useful to most of my students, a simulation program has to be (a) free; (b) delivered through a web browser, with nothing to download or install; (c) easy for beginners to understand; and (d) convenient for showing the motions of the stars and other objects with respect to earth's horizon.

Sky View Cafe is a great Java applet that almost fits the bill, and I’ve been recommending it to my students for several years. It’s loaded with features and was obviously written by a pro. But its time/date control is a bit awkward to use, so it isn’t ideal for showing celestial motions. Worse, its default full-sky view can be disorienting for beginners, who often have trouble relating the circle on the screen to the domed sky overhead.

Fifty-six years ago, H. A. Rey showed the best way to draw the sky for beginning observers. The illustrations in his delightful book Find the Constellations show half the visible sky at a time, as if viewed through a huge domed window stretching 180 degrees from side to side, from the horizon at the bottom to zenith at the top. I vividly remember reading that book as a child, and I wanted a web applet that gives a similar view of the sky.

I also wanted intuitive, analog controls for changing the time and date, so the sky’s motions would be easy to explore. Inspired by the GoSkyWatch iPhone app, I settled on a circular dial for changing the time of day, with a concentric inner dial for changing the date of the year. I added similar analog controls for setting the latitude and longitude.

To make the motions even more apparent, I included a feature that WSU’s digital planetarium projector has: the ability to show “trails” that simulate long-exposure or multiple-exposure photographs. Besides the familiar star trails, you can use this feature to trace out analemmas and retrograde loops.

This project has soaked up much of my free time for the last three months, but I think it’s essentially finished for the time being. I hope my students--and others who discover it--will find it useful.

iPhone Astronomy

When I gave up my Palm Z-22 for an iPhone in March of last year, one of the few things I sacrificed was a free little astronomy app that would draw a chart of the planets and constellations for any date and time.

Third-party apps for the iPhone became available a few months later, and among the initial offerings were four good astronomy apps. They cost $9 to $12 each, but they were far more powerful than what I’d had before. Over the year since then, two of these apps have been greatly improved and three others have been introduced. The most powerful of them now costs $19, but there are good choices for $5 to $6 and one of the apps also comes in a pretty good free version.

I have no idea whether these apps are stimulating more interest in astronomy among the general public, but I sure hope so. They’re affordable, fun to use, and instantly available whenever you find yourself out under the stars wondering what you’re looking at. Although astronomy software for full-sized computers is more powerful still, it’s often more expensive and harder to use--besides being tied to a large, power-hungry device that you can’t slip into your pocket.

The iPhone (and iPod Touch) user interface is ideally suited for this kind of software. On the screen you see a map of the sky, automatically adjusted for your current location. The amount you see at any one time is limited by the screen’s small size, but you can move the map around and zoom in and out instantly, using intuitive finger gestures. The better apps are so easy to use that even if I’m sitting at my computer, I prefer to pull out my iPhone to look up the time of sunset or the phase of the moon or the best time to view the Andromeda Galaxy.

In a modest effort to promote these apps, I decided last winter to write a review of them. Not a quick off-the-cuff review, but a thorough review of all seven apps, with a detailed comparison table and lots of screen shots. Otherwise, how are users supposed to choose among the seven apps--or even know that they have so many choices? (There’s no easy way to even find them all on the iTunes Store, which outgrew its primitive organizational scheme long ago. Astronomy apps are variously categorized under Education, Navigation, and Reference.)

The review project ended up being a little too ambitious, and I’ve had trouble keeping the review up to date. Still, there are hundreds of people out there who have read the review, and I’m getting a steady trickle of email thanking me for it. If a few more people fall in love with astronomy as a result, it will have been time well spent.

Astronomy is just one of many subjects where computing makes more sense on a mobile device than on a bulky computer. Another is trail maps and nature guides, as I mentioned recently. I get the sense that most of us, including the software developers, are still adjusting to this paradigm shift, and I look forward to the next generation of useful mobile apps.

Last Printed Edition of the Outings Guide?

The Ogden Sierra Club Outings Guide is now being printed. If anyone out there is waiting to buy a copy, we should have them in a week or two.

The changes since the last (2004) edition are numerous but minor. I’ve squeezed in descriptions of three new trails, tweaked the descriptions of many others, and updated several of the maps. The length is unchanged (112 pages), as are the illustrations and most of the page layout.

Shown here is one of the delightful chapter-opening cartoons, which were drawn before my time (1980s or perhaps earlier) by someone I’ve never met (Richard Hogue). It’s an honor to work on a project that so many others have lovingly contributed to over the decades.

Since the Guide went to press, one person has already requested an electronic version of it. This leads me to ponder its future, and the future of books more generally, as the world rushes into the internet age.

Technology has already had a big impact on the production and appearance of the Outings Guide. The first three editions were produced with typewriter, scissors, and tape. Some of the maps were hand-drawn, while others were copied (with permission) from newspaper clippings. A copy shop then reproduced the pages using an analog photocopier.

When I took over as editor in 1998, the production process went digital. I typeset the text (using TeX, the same software I use to write physics books and class handouts), scanned the line drawings, and produced new shaded-relief maps based on digital elevation data. I recall delivering that edition to the copy shop on a Zip disk, from which they uploaded it to their digital copier. In the 2004 edition we switched to FTP and offset printing.

To the end user, however, the format of the Guide is still unchanged: a pocket-sized soft-cover black-and-white booklet, printed on dead trees.

An electronic final version would be environmentally preferable, and would make my life easier in several ways. No more agonizing over the locations of page breaks, or over how much information to try to squeeze onto a tiny black-and-white map. No more running around town making deliveries. No more having to wait until the inventory is depleted before making updates.

On the other hand, the initial creation of a usable electronic version would be a major challenge, in terms of both programming and design. Sure, it’s easy to brainstorm about full-color zoomable maps with links to and from a searchable database of trail descriptions and photos. But I’ve done enough programming and web design to know that producing such a software package wouldn’t be easy.

To their credit, Weber Pathways has put an electronic version of their trail map on the web. As you roll the cursor over an alphabetical list of trail names, the trails are highlighted on the map. You can click on a trail name to see a text description of the trail, and you can restrict the list to trails of a chosen difficulty level if desired. With a bit of patience I can even view this map on my iPhone, if I’m in a location that has service.

But the Weber Pathways electronic map isn’t perfect. The map is extremely small and can’t be zoomed. Nor can you identify a trail by pointing at it on the map. You can’t access the map while exploring the more remote parts of the county. And notably, the electronic version of the map is now out of date, compared to the latest printed edition. 

Are there better examples of electronic trail maps? If so, I’d love to see them. But I’m doubtful, because solving one problem would probably create others. A fancier web site could be prohibitively expensive to create and maintain. A stand-alone mobile app could have a slicker user interface, but would be unavailable to anyone who doesn’t have the right gadget.

The long-term maintenance issue is especially troubling. Already, the production process for our Outings Guide has become so technical that I would have a lot of trouble finding another volunteer to take it over. Switching to an electronic Guide would ratchet up the geek level a couple more notches, and might require hiring a professional programmer. And while it’s easy in principle to update an electronic document, in practice it can become a burden and even an expensive necessity, as hardware and software quickly evolve.

Then there’s the question of money. Selling Outings Guides has been our group’s main source of income over the years. But nobody is willing to pay to access a web site, and at least for now, the market for a mobile app of this type isn’t large enough to cover the cost of hiring someone to produce it. (Weber Pathways operates on a much different business model, raising money from charitable contributions and mostly staying out of politics. We need organizations like that, but they can’t do everything.)

The good news is that we’re printing enough paper copies of the Outings Guide to last another four or five years. By then technology will have progressed, and perhaps the right way to do an electronic Guide will be obvious.

I’ll promise one thing now, though: As long as I’m the editor, the Guide will continue to include Richard’s cartoons.