It's important that digital textbooks are more than a pdf of the pages found in a traditional textbook. You can do so much more with an explorable interactive experience.
I shared my attempt at this on Hacker News a few years ago.
Nice work, a great gift to us all. I originally started "Designing
Sound" as a website full of easily clickable and runnable Pd
patches. In some ways publication with MIT forced me to shoehorn a
much richer experience into a standard textbook format. To that extent
I remain disappointed with how "web" technologies turned out for
education. In the end I had to take down the site in the face of
leaching parasites that linked to the material in such a way as to
saddle me with the bandwidth burden while freeloading as "meta
educational" sites. 15 years later I am resolved to make my next text,
after "Ethics for Hackers", be a more permanent free resource taking
account of lessons learned.
That's a real shame. Ideally we'd bundle together a bunch of things like this into a torrent so that the people using them paid the bandwidth costs, but 70% of people are using hand computers that have been deliberately crippled to make this impossible.
I admire your work. Can I ask how you deal with upkeep? I can't possibly keep updating software to deal with new JavaScript versions, and fielding reports like, "It fails on xx browser running on yy platform" are a real impediment to progress.
I've been thinking about how to solve this problem, which Konrad Hinsen calls "software collapse". I think we can define an "archival virtual machine" specification that is efficient enough to be usable but simple enough that it never needs to be updated and is easy to implement on any platform; then we can compile our explorable explanations into binaries for that machine. Thenceforth we only need to write new implementations of the archival virtual machine platform as new platforms come along: JavaScript, WebAssembly, PostmarketOS, or whatever.
Here are some of the things I've written about this in the recent past, though I seem to be suffering from profoundly pathological levels of analysis paralysis:
I think there will always be a hard core of explorables that really need the performance of a modern computer to express what you want to express, but I think there are a huge number that aren't, and for which the penalty of running 10x or 100x slower than they would in JavaScript with WebGL is worth the benefit of lasting forever without any maintenance.
For things that have some direct real-world applicability, like solving a sparse linear system (that isn't too large) or estimating the transmittance spectrum of a slice of the atmosphere, this kind of reproducibility seems even more important to me than for tutorial material.
I think that it was this kind of thinking which led to the Java Virtual Machine. Not for the specifical problem of archiving, of course, but for portability, which is almost the same problem. Archiving is just porting to a future platform.
Archiving is porting to platforms that are created after you die, which makes it harder to test on them, which in turn can make the porting task harder in some ways.
I did mention the JVM in two out of four of the notes I linked there, and it was certainly an influential step in the direction I'm going, but I'm aiming for deeper levels of reproducibility than the JVM tries to offer.
I haven't much upkeep or compatibility issues. There are a few people that have started working on translations. I imagine they might need some help. In general though, it's a simple site with no server communication, running on github pages, with almost no libraries.
I use the site for my own students when I teach physics, and they catch a few typos and bugs each semester.
great work! it' such a pity that so much gets put into PDFs still as a medium for textbooks when interactive content is so much better.
I've been working on some integrations along the lines of explorable texts that are backend by compute in jupyter - like this mini one on fourier series https://curvenote.github.io/demo-fourier/ (pres the power button to connect to a binder instance).
There ia notebook behind the scenes, and the idea is to try and move from custom web/js development towards something that a content creator say who is familar with python can use. Also open up the possibility of computing with libraries in the python ecosystem, and with compute needs beyond what we can achieve in the browser.
Still this example is a one off react site, built with JS knowledge.
Working from the other direction I'm also working with folks on a static site generator that can use Markdown(MyST) and Juptyer Notebooks to build book like content, this is a little like JupyterBook but with a JS stack that can integrate the explorable JS based interactivity on the link above.
The idea is again to let people focus on content and have a site generator let them build the deployable book. The cli that does that is open source and in beta at the moment in terms of readiness https://curvenote.com/docs/web but we're excited about what it can do already and busy working on the explorable integrations - looking for feedback and direction too :)