Quasicard is a hypothetical reimagining of HyperCard and TiddlyWiki, born out of my combined frustration and contentment with reading textbooks and taking lab notes on an iPhone and doing exploratory data analysis and algorithm design in IPython/Jupyter.
I’m currently reading Horowitz & Hill’s “Art of Electronics” on this iPhone. Using whatever downtime I have on public transport to read a page or two is a fantastic way to gradually come to understand things that have mystified me for years, sometimes decades. And, unlike most things on the iPhone, the PDF reader app doesn’t break all the time when internet access is disabled. But it is frustrating.
The column width of the PDF is such that about a column and a half of text fits on the screen in landscape mode at a comfortable reading size; in portrait mode the text is slightly too small if a whole column width is on the screen, but about 36 lines of about 10 words fit (360 words). At the larger but more comfortable size where a column width fills the landscape screen width, 11 lines fit (110 words). This leads to a lot of uncontrollable fits of interaction, sliding the words on the screen around every five or ten seconds, and the sense of reading the whole book through a peephole.
While the text is still not unreadable when shrunk so that both columns are visible side-by-side on the landscape-mode screen, it is uncomfortably small, and the other column is usually not useful — the two chunks of text are not linearly sequential, unless most of the top or bottom of the page is taken up by a figure. Indeed, the text is still readable with a magnifying glass when the entire page text is shrunk onto the screen in portrait mode, but this is not comfortable.
The iPhone’s Notes app fits 15 comfortably readable landscape-mode lines on the screen at once with about 12 words per line, for a total of about 180 words, with space spent on screen furniture on all four sides.
So the optimal reading experience is having somewhere around 200 words visible. However, this is still kind of shitty in the textbook case, because the book is full of schematics and graphs, and the text refers frequently to them; following these references is so much trouble that I merely accept that I will have to read through the text again more than once to understand it.
For example, p.669 contains the end of §9.8.3C, all of §9.8.3D, the beginning of §9.8.3E, two footnotes, and Figure 9.86. The §C text at the top of the page continues from a sentence that began on the previous page, refers to a footnote at the bottom of the page and the TOP201 controller chip simplified block diagram in Figure 9.83 on p.666, neither of which is visible at the same time as the §C text. The footnote refers to the second edition of the book for material that was omitted from this edition. §D also refers to several details of Figure 9.83. The §E text continues to describe Figure 9.83, and also refers to Chapter 1x, which is published in a separate book forthcoming later this year, another footnote (which for a change is simultaneously visible), Figure 9.85 on p. 667, and Figure 9.86, which is adjacent but which requires zooming out to fit on the screen; then it continues to the next page in the middle of the sentence.
This page 669, which contains about 80 or 90 lines of text (about 800 or 900 words) and one figure, thus contains eight references to things that the reader cannot see in the PDF viewer but must remember, refer to, or hope to buy later; one of these is on the same page, and another one (the rest of §C) is on the facing page 668. This level of hypertextuality or allusivity is, I think, typical of this book, although the book is probably several levels more hypertextual than an average textbook, which doesn’t have “Chapter 1x” or refer you to previous editions or put the student exercises in a separate book by a different author.
Reading this book, I was struck by the realization that printed books require such compromises due to their imposition of a fixed linear order on the underlying mangle of interconnected ideas. Such a linearization will unavoidably sometimes put significant distances between a drawing like Figure 9.83, which calls for many pages of explanation, and most of that explanation.
But the benefit of computerized hypertext systems is ostensibly precisely that they liberate us from such enforced linearity. Yet, looking at Wikipedia’s page on the same subject, I find that such references to invisible things are present within the first few lines — it begins with an anatomy of an ATX power supply, and by the time I have scrolled down enough to see “D: output filter coil;”, I can no longer see D, the output filter coil, in the photograph. Most of the many links in the first paragraph similarly refer to things I must remember or refer to to understand it, and unlike in the Horowitz & Hill PDF, I can tap my finger on them to see the definition; but this takes me away from the paragraph I am reading. Scrolling down to the first citation, I can tap on it to display the citation at the same time as the article; the citation window then remains unless I dismiss it, although it can change to display a different citation.
This kind of multiwindow mode could potentially be a useful mode for, for example, viewing the relevant parts of a figure as you scroll through the relevant parts of its explanation. It was attempted on the WWW with “framesets” and later iframes, but these did not work very well except for niche uses like advertising; most of the problems were not fundamental to the concept.
Beyond the issues of mere concurrent visibility of referents, there are missed opportunities. Textbooks like this one are full of formalized models of real-world phenomena in the form of equations, tables, and graphs. To learn how these models behave, it would be useful to be able to experiment with them (for example, to simulate the behavior of a switching power supply, perhaps to design one to fulfill an exercise) and use them to calculate solutions to real-world problems, without having to convert them into machine-readable form by hand, with the possible errors that entails.
I’m using the same iPhone to take notes on the things I try in the pottery studio, with words, interspersed photos, and time-lapse videos. Typically I take photos and videos during my studio time, then crop them and compose the text afterwards on the way home. As Bush predicted in 1945, “A scientist of the future records experiments with a tiny camera fitted with universal-focus lens.” Or, anyway, that’s what I’m aspiring to be doing; I can’t really call myself a “scientist”.
The photos and videos are extremely valuable for watching the progress of a piece through the traditionally slow process of shaping clay, and for recording the setup for many parallel experiments that can take weeks.
Unfortunately, there are a lot of things that lab notebooks really need that are clumsy or impossible on the iPhone. The iPhone can’t be backed up (except to Apple’s proprietary system), can’t export to HTML, can’t produce an audit log so that particular material can be confidently dated, can’t interface with data acquisition equipment to record measurements, and can’t do automatic calculations in the way that VisiCalc did on an Apple ][ in 1979 in 32K of RAM. It can, at least, switch back and forth between taking notes and doing calculations with its pictures-under-glass facsimile of an infix scientific calculator.
The calculation facilities needed for a lab notebook are similar to those needed for a textbook, except that you need some kind of assurance that the results of the calculations haven’t changed since you took the notes.
On top of these problems, this app silently reduces the resolution of the photos you store in it, which is a potentially fatal problem if you’re, for example, photographing something with text on it.
In IPython with Numpy and Scipy, I can load up measured data consisting of tens of thousands of data points, plot them, and immediately apply a whole panoply of signal-processing, statistical, and linear-algebra algorithms to them, plotting the results. It’s far better than anything else I’ve seen for this, except sometimes Matlab. And it also lets me include notes in pidgin Markdown with pseudo-LaTeX for equations, and Sympy can output formulas and equations in pseudo-LaTeX or LaTeX as well.
Powers like these would be extremely valuable for a lab-notebook application.
Unfortunately, code in an IPython notebook isn’t reusable for other IPython notebooks, because the atomic unit is the notebook. They can be sort of source-controlled in Git, but the file format mixes source code and output, the diffs are not readable, the diffs include ubiquitous spurious changes, and there was a backward-incompatible notebook file format change within the last few years, so the promise of auditability or even file compatibility across machines is false. Also, the results are not reproducible, because they depend on the entire Python installation, as well as the sequence of evaluations of “cells” within the notebook.
Also, of course, IPython/Jupyter is not equipped for photography, audio recording, or other data acquisition.
HyperCard was, in Nielsen’s 1995 nomenclature, a “frame-based” hypermedia system, unlike the WWW, which is a “window-based” system. The unit of hypertext was a fixed-size “card”, which did not scroll (it was the size of your screen) rather than a scrollable arbitrary-size document that your screen was a window onto. To write things that were longer than a screenful, you would normally organize them into multiple different cards with links between them, although, in versions of HyperCard 2.1 and later, you had the option of putting your text (if it was just plain text) into a scrollable text field.
TiddlyWiki is a “personal nonlinear web notebook” based on WikiWikiWeb. Unlike other Wikis, the unit of editing in TiddlyWiki is smaller than an entire web page; it’s a “tiddler”, and you can have many “tiddlers” visible at a time, just as Twitter displays many “tweets”, Facebook displays many “narcissists”, or Slack displays many “messages”. Rohit Khare’s understanding of the 2008 web as fragmenting its “atomic” pages into “subatomic” units gave him the name “Ångströ” for his startup, acquired in 2010 by Google, which I worked on briefly.
It is not a coincidence that Twitter refers to the link previews it displays with some “tweets” as “cards”.
In Nielsen’s terminology, TiddlyWiki is a “frame-based” system that simply displays multiple frames simultaneously:
Nodes are the fundamental unit of hypertext, but there is no agreement as to what really constitutes a “node.” The main distinction is between frame-based systems and window-based systems.
Frames take up a specific amount of space on the computer screen no matter how much information they contain. Typical examples are the KMS frames and the HyperCard cards. Often the size of the frame is defined as the size of the computer screen, but that determination may not hold in all systems. Since the frame has a fixed size, the user may have to split a given amount of information over several frames if it cannot fit into one. The advantage of frames is that all user navigation takes place using whatever hypertext mechanisms are provided by the system.
In contrast, window-based systems require the user to use a scrolling mechanism in addition to the hypertext mechanisms to get the desired part of the node to show in the window. Because the system can display only a (potentially small) part of the node through the window at any given time, the node may be as large as needed, and the need for potential unnatural distribution of text over several nodes is eliminated. Guide and Intermedia are typical window-based systems.
A great disadvantage of window-based hypertexts is that the hypertext designer has no control over how the node will appear when the user reads it since it can be scrolled in many ways. The advantage is that windows may be of different size depending on the importance and nature of information they hold. One can imagine a window-based system that did away with scrolling and thus kept most of the advantages of both display formats.
The real world is not quite as simple as the clear distinction between frames and windows. HyperCard is mostly frame-based but includes the possibility for having scrolling text fields as part of a card. Hyperties uses a full-screen display without scrolling but instead requires the user to page back and forth through a sequence of screens in case the node is too big to fit on a single screen.
Bush’s original Memex proposal was a frame-based hypertext system that could display two frames simultaneously on two separate screens (or more: “he has several projection positions”) in order to enable the user to add links between them.
Quasicard is a card-based hypertext system — currently in initial design stages — similar to TiddlyWiki, but with some important differences.
First, Quasicard card titles are optional. This sounds dumb, but it turns out to have a profound effect on the way the system can be used. (Imagine trying to use a version of Twitter that asked you to invent a globally unique title for every Tweet!) Although there isn’t a hard character limit like Twatter, Quasicard cards are intended to be small enough that several of them can fit comfortably on a cellphone screen at once — about a sentence or two in length, like a line of chat, rather than a paragraph or a document. Something like 128 to 256 characters, or half that in CJKV languages. To accommodate this, Quasicard makes it easy to split an existing card into new cards with Previous and Next links, automatically generating new IDs for those cards.
Second, Quasicard normally doesn’t scroll text. Instead, it displays up to however many cards will fit on your screen at once, closing whichever ones were least recently used. The last several closed cards are displayed in a list; you can look further back. Quasicard tries to find a reasonable layout on the display to accommodate the most recently used cards.
Third, Quasicard cards can include special non-interactive links which open other cards automatically as soon as they are opened, or maintain those cards open.
Fourth, Quasicard cards, like WWW URLs, can take parameters. In the case of image cards, this just allows them to be cropped to a particular area and zoomed to a particular minimum size when they open; but there are also calculation cards, which can take input data and perform some calculation on it, presenting the result in some format.
Fifth, there are calculation cards in Quasicard. You can tap on arbitrary numbers on the screen to add them to a calculation stack, enter new numbers, then apply arithmetic operations to them to create a calculation. Moreover, you can tap on other kinds of datasets to calculate on them, too.
Sixth, you can create cards in Quasicard by taking photos, recording videos, taking screenshots, recording sounds, recording your geographic location, and adding files, as well as typing text.
In the Quasicard user interface, commands (invoked by keyboard commands or mouse clicks or finger taps) take no arguments; the equivalent is to create a new ephemeral card with input fields in it, which can be filled by typing, drawing, or drag-and-drop; and it can have buttons. The card can then react, but it acts only with the authority it brought with it and the authority you granted it by dragging things onto it. Similarly, command output is generally provided by creating a new card. This makes Quasicard dramatically less modal than other interfaces.
The internal data of a card can easily be orders of magnitude larger than the 128–256 bytes displayed, which means that in some sense they can contain many other cards within themselves.