Let me give a use case where an offline-first hypermedia document model would be useful. I used to work as an instructional designer, making art and photography courses. This sort of material requires a lot of media, practically of all kinds. You either have to know how to code or use some platform to build that kind of thing. In either case, there'll be friction between reconciling the data source and the final document/volume. If you use a managed solution like a platform, you'll be locking away the content on their servers. Exporting the raw data does nothing because it'll lose all structure—that's basically what happens when you try to export from Notion, from instance. Yes, you can export, but it's lossy, because available offline formats, even markdown, cannot express the structure and ergonomics available within the authoring environment. There's a disconnect between source and presentation. You'll be left with a scattered set of files. The other option is not much better: coding it yourself. You'll need a CMS, and your data will be either JSON, MD, XML, or worse, tabular within an SQL database. Then you'll have to develop a build system or make some sort of SPA. And you'll need to setup a webserver and configure it to distribute the content. This is absurdly complex. It makes producing such materials very expensive. You just can't distribute your course offline. You can't back it up easily, either.Compare that with print media. Want to make a memo? Fire whatever word processor, write it down, export to PDF, share anywhere. Done. If hypermedia was easy like this, do you have any doubt that people would put it to good use? Do you realize how PDF might be overused simply because of the durability, simplicity and fidelity traits it has?
It's not a law of nature that hypermedia should exist only in the context of browsers. Neither that it has to use HTML, CSS and JS.
ianburrell|1 year ago
Your example could be done with directory of media files and metadata in JSON. JavaScript generates pages from the JSON file. Browsers can serve from the filesystem. It would need to be static since updating the JSON safely is hard since filesystem don't provide atomic guarantees.
If you wanted it writable or larger, you would need web server running API for accessing something like SQLite for database. Running a web server is super easy these days, single command.
Instead of thinking about how would remake hypermedia, come up with a JSON metadata schema that can be dropped in directory of multimedia. Then have JavaScript to render it. There are lots of people, me included, that would like that for our music and image libraries.
pilgrim0|1 year ago
Well, you're damn right! That's almost exactly what I did with my research! Perhaps to your displeasure, it's not JSON, it's something else, I needed something easy to write by hand. Plus I wanted to be have composability and a lot of other traits. Basically it's a novel data structure.
You can check a sample here https://jon.work/og/index.fifo.txt
P.S. Just to be clear, if a given information model has stable constructive and reproductive characters it can be considered media. And if it's multidimensional and multimedia it can be considered hypermedia (by definition), so doing what you suggested and guaranteeing the mentioned properties is precisely what "inventing hypermedia" entails. There's not only one possible hypermedia, it's an open concept, category. You can have as much renditions of it as you're capable to invent.
robertlagrant|1 year ago
It is sort of a law of hypermedia that different resources are different files, though, isn't it? I guess you could make a file format that embeds images and fonts and HTML in it, but why bother when we have PDF?
pilgrim0|1 year ago