This is another fancy web version of a feelie I’m working on, an InvisiClues-like hintbook for my WIP.
I’m separately planning on providing a plain text-based, more accessible form of the same content. The thing I’m presenting here is purely intended as an additional way to interact with the content, specifically one that tries to replicate some of the experience of interacting with the old physical hintbooks.
All of the content in the demo is placeholder stuff, and essentially none of it will be used in the “real” feelie. What I’m looking for is feedback on whether the underlying mechanism/scripting works for various browser and OS combinations: are there any hard errors, any weirdness in the page layout or element alignment, control difficulty, and so on.
General feedback on the overall look and feel is welcome as well.
When providing feedback including the browser and OS versions you’re using is super helpful.
I won’t provide details about how to interact with the feelie because it’s intended to explain itself. If it needs more explaining, let me know.
Any testing at all would be helpful, but there’s a loose “plot” in the hintbook as currently written…if you start with the first hint and proceed from there the “hints” will outline what needs to be tested/checked.
You probably know that it doesn’t work very well on mobile, but I’ll add it anyway; tapping and dragging doesn’t work, so I have to tap at the hint repeatedly. This is in Chrome on Android.
That said, this is such a cool idea and execution!
Ah, crap. I disabled touch support during testing and forgot to re-enable it.
Thanks for the problem report. Please check again, it should be working now.
It’s a little finicky on mobile because allowing the drawing gesture disables pinch and swipe gestures on those elements for navigation. So if you pinch-zoom a hint to fill the viewport, you can end up having to jiggle around looking for a non-hint element for navigation. I also haven’t mapped any touch gesture to [shift]-click to allow auto-filling hints on mobile.
Hm. The section links weren’t aligned with the “Table of Contents” label because the highlight on hover is wider than the element. Just pushed an update to do it the other way. Might tweak it again so the hover update overflows the element just for the effect.
I also widened the table of contents and spaced out the…whatever you call the line of periods between the section name and the page number (I assume there’s a name for this technique in typography, but I have no idea what it is).
It’s a little bit of slight of hand with canvas elements. The basic gimmick is that there are three l’il canvas elements for each hint:
The first one is generated by writing the hint text in brown to a yellow canvas. This is what the hint looks like fully revealed. This canvas is hidden off-screen.
The second canvas is white with a black border and starts out otherwise blank. It has the same dimensions as the first canvas. It’s the visible element on the page.
The first time the second canvas is interacted with, it creates a third canvas. It starts out blank, but each drawing gesture on the second canvas is copied onto it in black.
After each drawing event there’s a compositing action where the third canvas is used as a mask on the first canvas to update the second canvas.
In other words, it looks like the action of the marker on an old physical InvisiClues book, but it’s actually working more or less like a scratch-off ticket. There’s a fully revealed hint hidden by the white-with-black-border canvas on top, and when you’re scribbling on it you’re scratching away the white parts to reveal the yellow and brown hint below, with the third canvas keeping track of your progress.
Maybe I’m showing my age here (the other way haha) but how did they work? Was it one of those magic coloring book type things where you run the marker over it and it reveals the text?
Yeah. The InvisiClues booklets were the size of a narrow trade paperback book and were all thin enough that they were bound by stapling. They came in a plastic blister pack with a cardboard back along with a slightly chonky marker that looked kinda like a yellow highlighter. Since then highlighter pens have gotten slimmer, back then they tended to be bigger, about the size of most dry erase markers today.
The hints were printed in “invisible ink” and you “developed” them by running the marker over a printed rectangle on the page that indicated the location of the hint. You usually had to go back and forth a couple times to get the text to develop fully. The developed text was usually slightly blurry, and was always a distinctive brownish grey color. After a couple days the developed text would start to slowly fade. Nowdays if you see a vintage InvisiClues book you can see the yellow scribbling but the developed text has almost always faded more or less completely back to invisibility.
There were a couple of other things that used the exact same system. In that you could use the marker from one to develop the invisible ink from another. I remember one in particular was a line of puzzle books. I might be misremembering, but I think they were always fairly narrow, so I assume there was some limitation on the width of what could be printed with the process. But that’s just speculation on my part. I don’t think I’ve ever seen a technical discussion about the way the books were produced.
There were also a couple of competing processes. Another gimmick that was sometimes used was to print the text in blue ink, with a very busy swirling pattern printed over it in red. The text could be read when viewed through a filter of red plastic material (which I believe was the same red plastic filter material used in 3D anaglyph glasses). Infocom used this general technique in the Seastalker feelies (although in that case using repetitions of the word “SEASTALKER” as the interfering red pattern). Sierra On-Line started making InvisiClue-like booklets for their adventure games but later shifted to using the red filter technique.
The web hintbook is visually patterned on the old InvisiClues books and the introductory text and general style is a fairly straightfoward parody of the Infocom house style and particularly the InvisiClues for Zork I (and a couple others).
I’m somewhat more liberal in the use of whitespace, in the belief that it aids readability and because I don’t have to worry about keeping printing costs down. I’m also using the free font Baskervville for the section headings, questions, and so on. The InvisiClues booklets used a variety of fonts but the one I most associate with them is an '80s-era redraw of the venerable Belwe font family. Unfortunately there appears to be no free font that replicates Belwe’s idiosyncratic swashes (little decorative additions that look like pennants flying from some of the vertical elements, like the last arm of the W). I considered building a bespoke font from public domain specimens—the original letter shapes themselves are from 1907 and so are now public domain, but specific digital versions have whatever license their publisher decided to use. But I decided that’s beyond the scope of the project.
I think this looks really neat, but would it be possible to have it work if you start the dragging motion from outside the outline? As it is now, you have to start from inside the outline.
I’m using a Firefox-derived browser on Windows, specifically r3dfox 139.0.4.
Yes & Know books with decoder pens. My grandmother gave them to me to keep me occupied on long car rides between New York and Virginia in the 1970s. But apparently they’ve been around since at least the 1950s (judging by the eBay search return) and are still around today (judging by the Amazon search return).
From the patent, it looks like the printed ink is potassium ferricyanide, while the marker is ferric chloride. Which is interesting because, as far as I can tell from some quick searching, in “traditional” invisible ink it’s usually the other way around: the paper is marked with ferric chloride or the like, and potassium ferricyanide is used to reveal it. But for offset printing, it seems, it just works better this way.
Hm. I’ll have to chew on the problem a bit. Right now click and hold confines drawing to the element that was active at the time of the initial click. The reason why I set it up that way is because when it wasn’t confining the drawing action to a single element I’d invariably end up scribbling over adjacent hints.
Maybe listen for click and hold outside of the canvas elements and then only draw on the first canvas encountered after the start of the gesture? I’d have to do some testing on what that does to the document responsiveness. And that would probably interfere with the default cut and paste behavior. But I’ll take a look at it.
Anyway, thanks for the feedback.
Yeah, those were the specific ones that I was thinking about, although I think there were a couple of competing brands as well.
There were also a couple official D&D modules that were designed to be played solo using the invisible ink gimmick.
I just pushed an update that implements this. Let me know if it helps. It’s a little wonky if you start the gesture over a text portion of the page (like introductory text in some sections), because the click and hold gesture is also used by the browser for selecting text for cut and paste. But the booklet intentionally has generous amounts of whitespace in the hope that it minimizes click-on-the-wrong-element problems.