Documentation is nice and appreciated, but the work that needs doing in
order to a) make Spiel work well with 4.3 and b) dodge a bunch of
questions/criticisms I'll get if I released what I have is all
code-related. Spiel needs a better swipe model, because the current a)
classifies each view as a separate destination, making swiping slower
and b) misses some items. Getting this right is challenging because
there is no documented means for marking a view as being significant for
accessibility, and many views contain duplicate information which it is
difficult to filter. It's all trial and error.
Spiel needs keyboard support. Android 4.3 introduced a mechanism for
intercepting keyboard commands, so it is now theoretically possible to
add a bunch of screen reader specific commands for navigating devices
with keyboards.
Spiel needs support for the new live regions added in 4.4. This should
allow for certain areas of the display to be automatically read on
change, opening up a wide variety of application interfaces.
Tying this all together, Spiel needs a brand new, reconceptualized
scripting system. We need a flexible means of tying scripts to keyboard
commands, tying scripts to widgets and view IDs on screen, etc. Current
thoughts I have involve something a bit like a combination of JQuery
selectors and builders, but there's so much more groundwork to lay that
isn't more than a few pseudocode ideas in my brain. Additionally, we
need a better script distribution mechanism. The old Bazaar was a nice
idea, but was a central point of failure that has since stopped being
maintained. Nice would be the ability to navigate to any Spiel script
from your browser, then to "share" the script with Spiel to install it.
Spiel could then theoretically check the last-modified time of the
originating URL and prompt the user to upgrade scripts on change. This'd
let you host scripts in Dropbox, on your own website, in Github, wherever.
Spiel needs robust plugin support. At the moment there's a complicated,
hacky mechanism by which Spiel can introspect itself, find plugin
classes and add them. This makes it possible to add lots of new
functionality without touching core code. At one point, I had an
experimental single-tap plugin that eliminated the need to double tap,
all in about 30 lines of code. This should be integrated with scripting
such that it is possible to write plugins in JavaScript. It should also
be integrated into the UI so plugins can be disabled, can add additional
UI tabs, etc. Additional R&D should determine if it is possible for
plugins to be shipped in separate APKs, perhaps using metadata tags in
manifests to provide discoverability, with a permission such that
plugins must be granted it to enhance core functionality.
Unfortunately, while documentation would be a nice thing to have, I
really need smart folks to step up and help me brainstorm a lot of these
features. Also, while much of it sounds like nice-to-have, non-essential
things, having solid scripting and plugin systems would potentially make
Spiel easier to maintain for a smaller team. If implementing a core
feature was just a matter of writing a plugin in JavaScript, then it
becomes substantially easier for folks to iteratively improve Spiel
without my explicit blessing. I can throw together quick docs for
gestures and key features in an hour, and better ones can be written
over time. The code, though, has to exist for Spiel to be useful and
less buggy.
Unfortunately, coding on my own is hard to pull off when I'm quite
literally worried about running out of money in a month or two and
perpetually putting out fires.
There's also the fact that building better systems and software
sometimes requires more than one brain working on the problem. I'm
trying to tackle some pretty major architectural issues, but sometimes I
can't figure out a solution alone. It took months of brainstorming
before I came up with a scripting syntax I was somewhat happy with, for
instance. If Spiel was being driven by a team rather than just me, we
may have solved that problem much quicker, and perhaps my time could
have been spent implementing our solution rather than simply trying to
come up with it.
I don't know what to do. I'll keep thinking.
Short term, I'll focus on rebuilding the infrastructure. As a heads-up,
I'm considering switching VCSs again, from HG to Git. Before everything
went down, I was trying to come up with a good architecture that'd let
me open the repository to more contributors without worrying about
someone committing to tip. Unfortunately, Bitbucket and Github are less
accessible than I'd like. While I like Mercurial more than Git, the
reality is that tooling for Git is much more advanced and thorough. I
currently have a Git setup that'd let me offer each user the ability to
create branches while limiting who can merge to master, all without
inaccessible web interfaces. This is something that has been difficult
to achieve with previous infrastructures. Perhaps if I'd had the
capability to open up the repository more previously, I'd have had more
code contributions. Anyhow, we'll see shortly I suppose...