change_instructions_navigator

<a href="https://archive.org/details/HyperCardVol1">HyperCard</a> (<a href="https://www.youtube.com/watch?v=AmeUt3_yQ8c">1</a>, <a href="https://www.youtube.com/watch?v=fFX1otbE_wU">2</a>) seems to have an <a href="https://www.youtube.com/watch?v=bdJKjBHCh18">origin</a> similar to the famous <a href="https://www.youtube.com/watch?v=Bqx6li5dbEY#t=0m29s">rowboat experience</a> (0:29). The implemented techniques remind me a lot of <a href="http://skreutzer.de/browsergames/welt/index.php?x=0&y=0">one of my own projects</a> that <a href="https://www.vidlii.com/watch?v=lxv5_pHYQI9">assembled transparent images into a scene</a> with the help of the <a href="http://php.net/manual/en/book.image.php">gdlib in PHP</a>, complemented by corresponding <a href="https://en.wikipedia.org/wiki/Image_map#Client-side">image maps</a> to make areas of the final composition clickable for navigation. Everything is driven by records from a database, which define the presence of objects based on a time range, plus some caching for optimization. To make the creation of such virtual worlds easier, I soon added an editor (<a href="https://www.vidlii.com/watch?v=XIPdiAg9i_n">1</a>, <a href="https://www.vidlii.com/watch?v=_BR7jj7EGnL">2</a>). Today, browsers come with HTML5 canvas, CSS3 and SVG. The HTML5 canvas is the generic drawing area control that finally got standardized. Similar to typical game programming, objects get drawn over each other and the result displayed on the screen, usually at a frame rate not below 30 frames per second to make animations appear smoothly to the human eye. In contrast, SVG’s primary way of graphics manipulation is a tree of objects for the SVG engine to figure out which portions are visible and therefore need to be drawn/updated as opposed to portions that are completely covered by other objects. Each object can register its own click event handler and the engine will automatically call the right one without the need to do manual bounding box calculations as with HTML5. CSS3 should be similar to SVG in that regard and with the recent extension of transformations, it might be worth a look. Unfortunately, SVG is said to be bad for text handling. Anyway, the browser would make a pretty decent player for a modern HyperCard reincarnation, but as an authoring environment – who knows if the <code>window.localStorage</code> is big enough to hold all the data including many or large images and if the sandbox can be escaped with a download or “save as” hack, because it’s probably not a good idea to require an internet connection all the time or to persist stacks on the server while they should be standalone units that can be send around. EPUB may help with that, but not to run JavaScript on e-ink devices but to package the different resources together for distribution. The receipient would simply extract the contents again and open it as local websites in the browser, or a dedicated e-reader software would take care of that. The hardware back in the day granted HyperCard some advantages we can’t make use of any more. With the fixed screen size of the Macintosh, the card dimensions never had to change. In our time, the use of vector graphics would avoid issues where the aspect ratio of the screen remains the same. If the underlaying cards constitute a navigatable, continuous space similar to the top level coordinate system of my “virtual world” project, the screen dimensions could just become a viewport. Still, what’s the solution for a landscape card rendered on a portrait screen? Scrolling? Should stacks specifically be prepared for a certain screen resolution only? I’m not convinced yet. At least <a href="https://en.wikipedia.org/wiki/Reflowable_document">text tends to be reflowable</a>, so systems for text don’t run into this problem too much. This is where HyperCard differs from an Open Hyperdocument System: the former is much more visual and less concerned about text manipulation anyway. HyperCard wasn’t that much networked either, so the collaborative creation of stacks could be introduced to start a federated application builder tool. Imagine some kind of a <a href="https://en.wikipedia.org/wiki/Rapid_application_development">RAD</a>-centric ecosystem that offers <a href="https://www.youtube.com/watch?v=8i60_REoeIY#t=14m20s">ready-made libre-licensed GUI control toolkits</a> (14:20) to be imported/referenced from checked/signed software repositories with a way to share libre-licensed stacks via an app store, enabling <a href="https://www.youtube.com/watch?v=PUv66718DII">Bret Victor’s vision</a> on a large scale, eventually getting some of <a href="https://www.youtube.com/watch?v=yzq3kCyak_I#t=0m30s">Jeff Rulifson’s bootstrapping</a> and Adam Cheyer’s Collaborama in. With the stupid artificial restrictions of the browser, the authoring tool could be a separate native application that generates the needed files for the web and could target other execution targets as well, except it turns out to be crucial for the usage paradigm that <a href="https://www.youtube.com/watch?v=x2GylLq59rI#t=6m20s">reading and authoring must happen in the same “space”</a> (6:20) for the project to not head into a wrong direction. Maybe it’s not too bad to separate the two as long as the generated stack files can still be investigated and imported back into the editor again manually, on the other hand, if the builder tool supports several execution targets and an “export” irreversible decides for a particular scripting language, then we would end up with a project source as the primary form for one to do modifications in, and users receiving something else less useful. Another major difference between an Open Hyperdocument System and HyperCard would be that I expect an OHS to implement a standardized specification of capabilities that provide an infrastructure for text applications to rely on, while HyperCard would focus on custom code that comes along with each individual self-sufficient stack package. HyperCard could follow a much more flexible code snippet sharing approach as there’s no need to stay interoperable with every other stack out there, which instead is certainly an important requirement for an OHS. So now, with no advances for text in 2018 to improve my reading, writing and publishing, I guess I should work on an OHS first despite building a modern HyperCard clone would be fun, useful and not too difficult with the technology that’s currently at our disposal. Bill Atkinson <a href="https://www.youtube.com/watch?v=ejdgTVj7ZG8#t=6m40s">claims some “Open Sourcyness”</a> (6:40) for HyperCard, but it’s a typical example of “Open Source” that doesn’t understand or care about the <a href="https://www.youtube.com/watch?v=ejdgTVj7ZG8#t=8m00s">control proprietary software developers seek to exercise</a> (8:00) in order to exploit it against the interests of the user, community and public. What does it help if the <a href="https://www.youtube.com/watch?v=ejdgTVj7ZG8#t=10m37s">authoring/reading tool is freeware</a> (10:37) and encourages creators to produce content that happens to be “open” by nature (interpreted and not compiled to a binary executable), but then denies them to actually own the tools as their means of production, therefore not really empowering them? Sure, the package seems to be gratis, but that’s only if people buy into the Apple world, which would trap them and their content in a tightly controlled vendor lock-in. Libre-freely licensed software is owned by the user/community/public and can’t be taken away from them, but HyperCard as freeware at first and then split into proprietary packages prevented it from becoming what’s the WWW today. Apple’s decision to discontinue this product killed it entirely because neither users nor community were allowed/enabled to keep it running for themselves. The fate of Bill Atkinson’s HyperCard was pretty much the same as Donn Denman’s MacBASIC with the only difference that it happened to HyperCard somewhat later when there were already plenty of naive adopters to be affected by it. Society and civilization at large can’t allow their basic infrastructure to be under control of a single company and if users build on top of proprietary dependencies, they have to be prepared to lose all of their effort again very easily, which is exactly what <a href="https://www.youtube.com/watch?v=ejdgTVj7ZG8#t=45m05s">happened to HyperCard</a> (45:05). Similarly, would you be comfortable to entrust <a href="https://www.youtube.com/watch?v=H_pMgowkLt4">your stacks</a> with <a href="http://tilestack.com">these punks</a>? Bill Atkinson probably couldn’t know better at the time, the libre software movement was still in its infancy. It could be that the only apparent limitation for adoption seemed to be a price because that would exclude those who need it the most, and if we learn from Johannes Gutenberg, Linus Torvalds or Tim Berners-Lee, there’s really no way of charging for a cultural technique or otherwise it simply won’t become one. And over “<a href="https://en.wikipedia.org/wiki/Gratis_versus_libre">free beer</a>”, it’s very easy to miss the other important distinction between real technology and mere products, one for the benefit of humanity and the other for the benefit of a few stakeholders: every participant must be empowered technically as well as legally to be in control of their own merit. One has to wonder how this should be the case for <a href="https://www.youtube.com/watch?v=ejdgTVj7ZG8#t=1h08m16s">iBooks Author</a> (1:08:16) or anything else from Apple. This text is licensed under the <a href="https://www.gnu.org/licenses/agpl-3.0.html">GNU Affero General Public License 3 + any later version</a> and/or under the <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode">Creative Commons Attribution-ShareAlike 4.0 International</a>.