3 ms·
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
by lilgreenland 4y ago
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.
https://landgreen.github.io/physics/index.html https://landgreen.github.io/physics/index.html
https://news.ycombinator.com/item?id=17178031 https://news.ycombinator.com/item?id=17178031
- stevejpurves 4y agogreat 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/ 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 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 :) some example of building with it: - my blog https://www.stevejpurves.com/la-palma-earthquakes https://www.stevejpurves.com/la-palma-earthquakes - a book like report https://climasoma.curve.space/ https://climasoma.curve.space/
- cxr 4y agoDitch the build-with-CLI requirement. If you're working on notebooks, show your commitment and make the static site generator a notebook itself.
- nonrandomstring 4y agoNice 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.
- kragen 4y agoThat'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.
- teddyh 4y agoMore like that: https://ciechanow.ski/archives/ https://ciechanow.ski/archives/
- jimhefferon 4y agoI 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.
- kragen 4y agoI'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: https://dercuano.github.io/notes/uvc-archiving.html https://dercuano.github.io/notes/uvc-archiving.html https://dercuano.github.io/notes/archival-vm.html https://dercuano.github.io/notes/archival-vm.html https://derctuo.github.io/notes/veskeno-outline.html https://derctuo.github.io/notes/veskeno-outline.html https://news.ycombinator.com/item?id=32218329 https://news.ycombinator.com/item?id=32218329 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.
- teddyh 4y agoI 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.