Offline access

[theRocket]

One major hurdle that has not been discussed yet (I think) is how the
promoters will use the results software offline, i.e. the situation
where there is no internet connection available at the race site
(probably 95% of cases).

Do we expect them to prepare them in a spreadsheet in a certain
format, perhaps based on an export from the live database of WSBA
members, than import it back in with results on it?

Or is there a smarter way?

When I was thinking about this problem for my own use case, I planned
on just running the Rails app on my local machine (not broadcasting
it), then exporting the new data as a SQL file, which would be
uploaded into the database directly (with a database management
program).

Not an approach I expect Joe B. Promoter to take, nor would allow
(direct access to the database, that is).

Database synchronization of offline web apps is a problem that has not
really been solved, as I know of. I talked with a guy at RailsConf
who helped design eBay Desktop (runs in Adobe Air), and he agreed
there is no easy answer for this problem.

[Scott Willson]

Good analysis. You've obviously thought this through in detail.
Offline results is the biggest design issue we've got.

Here's how it works now:
Officials/promoters download the latest member information an Excel file
Officials/promoters score results in Excel
Officials/promoters email the results Excel file to Cheryl or Martha
Cheryl (or Martha) fix any formatting problems
Cheryl uploads the results to the database

It works OK. The roundtrips via Excel produce a lot of messy data, and
that makes for a lot of manual fixing on Cheryl's part.

Expanding the application to run offline for results at the event
would help, though not eliminate, a lot of data entry work. As you
touch on below, there are a lot of design decisions involved.

I would start with a standalone application that could semi-
automatically synchronize member information, record results at the
event, and then send the results to the site when it's back online.
Essentially replace the freeform Excel with a standard machine-to-
machine format, and remove the manual emailing with automatic
synchronization.

A lot of this admin stuff is hard to visualize just by me describing
it. There's a demo site running. Anyone who's interested, email me
directly for a password so that you can check it out:
http://app.obra.butlerpress.com/admin/racers

Scott

[theRocket]

I just came across this frontier of web technology:

http://webkit.org/blog/126/webkit-does-html5-client-side-database-storage/

Webkit does come with a Windows version, which we could require the
promoters to download.

It appears not much has moved on this lately at WebKit, but I may give
it a try in it's current state.

Fortunately, each promoter is responsible for his/her own results, so
we shouldn't have simultaneous updates happening. The data should
append, not replace. If they screw up, they can delete all and start
over?

[Scott Willson]

That's cool. There are several different approaches out there. It gets
a little tricky if you want to deploy and run Rails on the computers.

I don't think storing and synching data is the biggest hurdle.
Fortunately, our painful importing and exporting of Excel files has
created a fairly simple, but complete interface. I think a standalone
client could probably communicate with the server via simple text
files or HTTP, or maybe Rails' Active Resource. SQLite (or similar)
for local data storage should be fine.

The bigger issue is how to build the UI application. It needs to work
on multiple platforms, speak POX over HTTP, and (ideally) re-use the
relevant Ruby code. I tried Fox and Gnome-Ruby, but compilation,
installation, and edge-case bugs were issues. Neither work too hot on
OS X, either, since they rely on X11.

One option would be to use each platform's native GUI toolkit and make
the GUI very "thin"—logic on the server as much as possible. So you
would use, say: .NET, Gnome, and Cocoa. This would give the nicest
GUI, but means you would need to code in three different environments.

Another option is Java Swing. It would require Java, and Swing's got a
bad rap, but I think it's a decent GUI toolkit, and the Java download
and install options (like WebStart) work well. We'd have to test on
three platforms, but not have to code to them. And theoretically, we
could run via JRuby and re-use existing logic. Even more
theoretically, you could write all the Swing code in Ruby via JRuby,
and never write any Java.

Anyhow, that's my disconnected client brain dump. I not sure it's
anything we'll tackle soon, and the longer we wait, the more our
options seem to evolve.

Scott

[theRocket]

Scott,

Most of those technologies you list make my nose hairs wrinkle, except
Cocoa, SQLite, Rails, and "native GUI toolkit". For that, I am
looking at SproutCore:
http://www.sproutcore.com/
http://www.sproutcore.com/2008/07/19/writing-sproutcore-apps-with-a-rails-backend/
(links to this, in 3 parts)
http://blog.lawrencepit.com/2008/07/19/sproutcore-rails/
http://blog.lawrencepit.com/2008/07/26/sproutcore-rails-part-ii/
http://blog.lawrencepit.com/2008/08/04/spoutcore-rails-part-iii/

When online, the client server does an Ajax request to GET or POST
data RESTfully (now implemented in Sproutcore edge by the blog
author).

When offline, it will live locally in a SQLite db file, which is how
WebKit is implementing the HTML5 spec.

Like I said, the promoter is expected to download WebKit, and know
whether they are online or not (so we don't have to detect their
network connection). I will test it on the various platforms.

[theRocket]

Just checked Windows XP. The standard Windows release of Safari
supports that Notes demonstration of the local db storage, so I think
I can pursue this.

RyanR>

[Scott Willson]

Yeah, SproutCore is pretty promising. I've considered replacing the
entire admin UI with it. If you could also run it as a client
application, that would be nice and consistent. On the other hand,
it's a pretty new framework—there's not even a table view component
yet. And it's yet another developer paradigm/framework to learn: Cocoa-
inspired Javascript talking to Rails and generating HTML.

My last concern is the install. Sure, for you and I, it's easy to
install Ruby, Rails, the required gems, and fire up a local web
server ... but that's not practical for a wide audience of promoters
and officials. It really needs to be about as simple as: I click this
link, download, run application. Java WebStart actually handles all of
that nicely. Is there SproutCore-in-a-box? That would great.

But, uh, as much fun as these discussions about disconnected clients
are, they don't seem very relevant to putting up racer registration
pages. You know what I am saying? ;)

[theRocket]

I am not thinking I could expect non-programmers to tackle the Rails
install at all. I am thinking the results engine would not run on
Rails when out on the race course - just SproutCore and SQLite. The
'sc-build' command is "used to generate a static directory of files
that you can upload and serve from any web server." These are
all .html, .css, and .js files, I believe. So they download Safari,
download the app as a zip of files, and just find "index.html". The
data is stored in a separate location then the app, so they could
install a new version of the app over the top of the old one or run
them separately. It would send results data only to the Rails app
running on the server, and only when the promoter comes back online.

SproutCore is very new, but the adoption by two highly successful and
technologically savvy parties -- the new MobileMe service from Apple,
and Barack Obama's primary campaign early on -- is a big selling point
for me.

The documentation is good (and on GitHub! http://github.com/sproutit/sproutcore/wikis),
and I'm a quick study. Let's just give it an Alpha test run, at
least. Proof-of-concept, if you will.

It does have a TableView component. Look here under Views/Collections
here: http://www.sproutcore.com/static/sc_docs/ Here's the
implementation:
http://www.sproutcore.com/static/sproutcore/-docs/data/symbols/src/_Users_charles_Sites_sproutcore_samples_frameworks_sproutcore_views_collection_table.js.html

Thanks,
RyanR>

[Scott Willson]

Cool. Thanks for digging deeper into it. I agree: a prototype would be the best way to prove it out.

Honestly, really trying to use it for some concrete is the best way to prove it out. Always seems like even the best UI frameworks have nasty snags and take a bit of learning to use effectively. My experience is has also been that frameworks that are driven by one big user (e.g., SWT and Eclipse) tend to focus on the one big user and ignore other people's needs.

But, when we build an offline app, if SproutCore does the job, then great!