Published by cce on 2011-09-06
This is a brainstorm discussion blog entry on usability items needed for HTSQL adoption. It includes discussion of editor, installer, configuration and development.
The purpose of the UI Shell is to provide a visual environment giving data analysts or programmers an interface to the HTSQL system and underlying database. Specifically, such a shell would help the user with the following items:
With the exception of sharing, this is mostly a client-side and stateless component. The access like features are explicitly not included in HTSQL’s distribution.
Nice to Have:
Critical Path:
Nice to Have:
Critial Path:
Nice to Have:
Visual Editor for Configuring: Database Connection, Schema Overrides, and other Plugin Parameters.
Integrates HTSQL Editor
Uses Internal Web-Server or Server Configuration
Works as localhost:port or as local app using something like XULRunner.
Review how a new user would discover how to use htsql-ctl to connect and ensure that the documentation, --help and error messages are informative.
Documentation for how to make a configuration file and a good hooks for the PyYAML parser to report on any problems that they may have (such as using tabs, or missing keys.)
Documentation for how to make table/schema configuration file plus hooks for good error messages.
Ensure that htsql-ctl shell and htsql-ctl serve work and are well documented. Document shell & serve features.
Some way to have N page slideshow for reStructuredText website content, so that donors choose examples can be turned into single-point-at-a-time.
The problem the HTSQL editor solves is that a URL is a horrible place to make a query. So this sort of editor
The core idea with this particular deliverable is a formatter that is divided in two parts. The top half is the query, and the bottom half is the output. What’s important is that the formatter loads immediately and sends an async request to run the query itself, and this works with errors as well.
This only works when the user agent support text/html, so other user agents will get other formatters. Ideally this would be the default formatter for web browsers, however, it’d require javascript and support for changing the URL location when you press ENTER to load a new page. For IE, it could redirect to new page for other browsers it could directly modify the location bar without re-loading to preserver the user’s cursor.
The first pass can be very simple, it could be an editor.html which is a static file, using hash-tags to pass the query and an iframe to show the results. This could go into the demo directory for the 1st pass and integrated with CodeMirror.
Later passes could use a scrollable grid, clever magic to change the URL, and become the default formatter. In this case, we’d probably have a server-side execute function which took the unadultrated query with a page number and either returned the JSON to be rendered... or a 302 if the query doesn’t support a producer interface.
This could go into the demo server. I’d like this integrated with tutorial.