I'm not good at describing the UX parts, but every time I deal with it seems painful. I can't easily get to what I need, update notifications don't work the way I expect (you need to manually mark stuff as viewed), creating custom tables can be blocked by project owners (I understand not editing the shared ones, but if I want to create my own report, I don't see a reason to disable that). I can't point out many big issues, it's just papercuts whichever direction I turn to.
Things that I can point out as missing:
- no support for other locales (it's dd/mm/yyyy and 2300, not 11pm where I live, US is not the only place in the world)
- no rich-text on long-content fields
- no actual changes visible in revisions, history contains only "changed by xxx on yyy"
From the developer's perspective, the API is really silly. It seems to be completely different from normal access path. Tokens need to be authorized by project owners, not all authentication schemes work with APIs. I don't get at all why is API access treated as something additional, rather than a normal usage pattern. If I've got a user account, I should be able to do via the API every action I'm allowed to do via web - without anyone's blessing.
API design also leaves a lot room for improvements. Custom XML only with things like this definition of a query:
Keep in mind that '-s only separate the arguments to the operators, not the actual items, so for multiple values you have to quote with " inside of a '. Now try to protect that against injections. As a developer I want to cry at that point. Also the HAS operator is special cased to work only on lists of users via their screen name, id, or email... Did I mention that separators for lists of elements are periods (unless explicitly defined as semi-colons in some places).
Trying to figure out the exact meaning of "field_type", "base_type", "role" and "mode" in the results (all are attributes on every value of the results) along with how to resolve them when they reference values in other tables (which can be done in 3 different slightly underdocumented ways from what I've seen so far) is pretty difficult. This may be a good start for a TDWTF article...
I like QuickBase for prototyping and departmental applications but it does have it's idiosyncrasies. Unfortunately, I don't get to use it much anymore because I am bootstrapping a startup and it is too expensive (not free enough) for us. If we start scaling I will use QuickBase to automate as much as possible.
I have a working DBAPI compliant Python module that is about 40% complete. It really needs a method to translate SQL to QuickBase's clunky xml query format. The Ruby API has one and it would be trivial to port it to Python.
Would you (or anyone else?) be interested in contributing if I put it up on GitHub?