Keywiki is another HTML5 experiment, this time a client-side wiki using IndexedDB for storage. It’s designed for quick and easy note taking, especially on a phone with attached external keyboard.
While I was away in India I used MarkupNotes to keep a diary. It worked fine, but there were a few things about it that don’t really work in this environment:
Keywiki addresses these problems in the simplest way I could think of.
Keywiki isn’t portable like presentable, but I intend to wrap it up into an app for offline use.
Try it here. All data you enter is kept in your browser’s IndexedDB storage, nothing is sent to the network. You can export your work as a JSON file for backup or migration.
Wikis with distinct ‘edit’ and ‘view’ modes baked in either have to rely on an agreed markup syntax or provide an editor capable of some degree of richness (links, at minimum.) There are significant issues with both of these, see the flame wars in various places over whether a wiki should have a plain or rich text editor (Confluence switched from one to mostly-the-other and endured a drubbing)
Keywiki doesn’t have a ‘view’ mode, so it doesn’t need to care about whether you are using a markup language or not. It’s up to you. A separate app could draw on the Keywiki page data and interpret it, as markdown or whatever.
The drawback of not having a ‘view’ mode is that you need an interaction for following a link which won’t collide with editing. Since you’re using the keyboard anyway, a hot key is the obvious way to do this.
NoteWiki has a similar approach, also using a hot key, though double-clicking the links will also follow them. Which brings me to
I have never seen a Javascript rich text editor that works reliably. Even Confluence’s could screw up the HTML on occasion, and they had a lot riding on making the transition as smooth as possible. The trouble is that there is a lot of structure in the rich text which doesn’t correspond to a visual cue. Markup, of whatever kind, having everything right there in-band, can always be fixed when it goes wrong.
The other reason to use a plain textarea is to get the environment to shoulder the burden of providing the editor: I don’t need to worry about internationalization (bidirectional scripts, eek) or cross-browser keycode hell, and I get the benefit of any improvements on the client (pop-up emoji keyboards, cursive input, speech-to-text)
The drawback of the browser’s textarea is of course that you can’t have links in it.
To address this weakness, we just dispense with explicit links and make the hot key work wherever you are in the page. In wikis like Ward’s which have automatic link generation, you don’t even strictly need the blue text to tell you there’s a link, because the CamelCaseWords are all links (single words have to be given extra capitals to trigger the linking.
In Keywiki, you can use a convention like this to help you navigate—or you can make up your own convention, or you can just freewheel.
All wikis that have explicit links face the issue: when you make a new page, how do you ensure it’s reachable from all the other pages that would want to reference it? In Ward’s wiki, you need to decide SomeThing is likely to be a page ahead of time. Keywiki tries to improve on this. When you navigate to a page, it automatically searches the full text of all other pages for the title of that page. Because every word is a link, the results of this search will always include the back links for the page. (At the moment the search will match pages containing any of the words in the page title. I may tighten this up if it becomes an issue.)
This gives you a choice, when you decide how to use Keywiki:
Lazy linking works because underscores are treated as ‘hard spaces’ for link purposes: when you follow the link ‘first_page’, you navigate to ‘first page’. The search will still match the originating page, but it will also match any pages which contain ‘first page’ in non-underscored form.
Of course you can’t see on those pages that ‘first page’ could be used as a link—and you’d have to select the phrase ‘first page’ explicitly to follow it, as it’s more than one word—but it gives you a heads up to go make links explicit on those pages which warrant it.