Bear with me here. I’m trying to convince myself that it’s worth it to write my own blog engine.

As a clever man said:

In the past few years I’ve been trying to store my writing locally, but writing in public is powerful. It is excruciating to keep writing on the web (especially with inline images, like here) up to date with local notes. And “local” here doesn’t mean “stored in a repo”, like for a static site, because a repo is separate from where I’m writing: it has been Evernote, then Notational Velocity, then nvALT, now Bear, and soon, hopefully, my own open-source project.

I offer a new paradigm: own your writing, publish everywhere. Now it’s usually backwards, you’re writing on the internet somewhere and then maybe, if the service lets you, export what you’ve written.

What does this have to do with a blog engine? It’s a start, where the CMS, or the publishing platform, will only be a container for published writing, not its master location.

My current engine, Aegea, is woefully inadequate due to it being closed-source. And Wordpress and the like are either too cumbersome to setup the way I need (I have a small, but _opinionated_ (as they say) set of necessary features) or don’t have what I need at all.

A static site would fit the bill but it doesn’t have comments, and no, Disqus won’t cut it.

In the end, I _want_ to write one. I’ve been learning some Go and this is a great opportunity to write a medium-sized web-service, which I have never done before. And it’s very motivating because I want to keep my writing published. I’m quite sure a minimal version can be done in a week, so that I can migrate to it, and its incompleteness should motivate me to work on it further.

I have already compiled a minimal list of features to implement first and it’s manageable, so there’s hope.

Can’t wait to share what I come up with.

After just a couple of days in review (maybe beta review helped?) Not So Fast has been released on the Apple App Store.

You can find the link on the website: https://notsofastapp.com

As usual, this version is temporary, made with Carrd, to be replaced later with a simple static page.

I have already found a few bugs and got some valuable feedback from users. There’s also a huge backlog of features I’d like to implement, but everything takes time! I’m happy to have released at this very first version, it has been a lesson in what corners can be cut and what features are absolutely essential.

An attempt to design an interactive input control for a text-based game. Given a question, fill in the blanks in the correct order by selecting parts of the answer from cards.

“Hayaku” is a kana speed-reading mobile game that I’m (slowly) making. I’m studying Japanese again after a five-year break, and this time a thing I’ve noticed is that none of the apps teach you to read fast. I believe it’s a crucial skill on the path to being comfortable with a new language, especially one with a difficult writing system. Japanese is not all kanji, there is a lot of kana, and reading it faster means reading it with more precision. At least that’s the idea.

Basic gameplay is as follows: you are presented with a word in Japanese. Under the word there is a number of blanks to fill. Under the blanks, a 3x3 grid of cards with syllables which you must pick to fill in the blanks. Looks simple, but in order for the interaction to feel natural, I had to come up with this little spec, which describes the 3x3 grid control in question. It works kind of a like an Android unlock screen.

I will return to this when I make a working prototype demonstrating each point, and it will be much clearer.

Glossary

• Buffer: a set of empty cells of a specific length, used to collect selected items to match against correct answer.
• Chain: an ordered set of tiles selected by the user.
• Input: user actions (taps and slides).
• Slide: continuous motion while the finger is touching the screen.
• Tap: a short touch after which the finger is lifted. Treated as a short slide.
• Tile: a card with part of the answer.

Notes

Using mobile paradigm for input, read tap as click and slide as drag for mouse input.

Controller input not included, but possible e. g. with a selection frame used to target and “tap” tiles.

Spec

1. General
   1. Input generates a chain of tiles until the buffer is full.
   2. When at least one tile is selected, shows hints that the user can select only tiles directly adjacent to the last selected tile.
   3. Buffer can be filled by any combination of taps and slides.
   4. When on confirm input (raise finger) the buffer becomes full, the buffer is reset if the answer is wrong.
   5. When on confirm input (raise finger) the buffer becomes full, if the answer is correct succeed and prepare control for the next answer.
2. Taps
   1. Tap one tile after another to fill the buffer. This creates a chain of tiles.
   2. When tapping the last selected tile, erase it from the buffer and make the previous tile (if any) the last in the chain.
   3. When tapping any other non-adjacent tile (selected or not), reset buffer and make it the first tile.
3. Slides
   1. Slide across adjacent tiles one after another to fill the buffer. This creates a chain of tiles.
   2. Slide can be ended (finger raised from the screen) and if the start tile has been adjacent, tiles will be appended to the chain and the buffer up until it’s full.
   3. Slide will display feedback in real time for slide path and adjacent tiles, just like when tapping.
   4. When the buffer is full, adjacent tiles hint stops displaying, the finger can be moved freely until it’s raised, no new tiles will be selected, and input will only be accepted when the finger is raised.
   5. While holding the finger, it is possible to slide back across selected tiles one by one and deselect tiles, including the first tile.
   6. When a tile is selected, beginning the slide from this tile will make it the first tile (same as tapping any non-adjacent tile).