QuickBase is one of the
best software applications that I have ever used.
(Disclaimer: it is built by one of the Intuit teams where I used
to work. :)
QuickBase is a web database; it lets you organize and share
information in a structured form. I have hundreds of QuickBases. :)
The designers of QuickBase realized that most "databases" are
"small" (say, less than 10,000 records, in fact many less than 1,000
records) and decided that ease-of-use was more important than strict
rules.
This means that QuickBase makes it very easy for you to change your
mind about how your database is structured at any time, even after you
have a bunch of stuff in there!
My biggest problem with QuickBases are that most humans
over-estimate their ability to stay organized, and as such they always
create new databases with way too many fields. They try to setup
systems to track stuff because it is possible, instead of focusing on
what is most usable. Such complicated QuickBases are almost never
widely used, since others can not understand them.
My strongest suggestion to QuickBase users is to start simple--
create very simple database structures, and only after you (and
others) are successful using it for a while, only then should you
start to add a little more structure.
My QuickBase Conventions
- Simplicity. Keep schemas simple. Simpler than you think you
need. Really.
- Terseness. Keep field names and values small, ideally one
word, all lowercase, and short words are better than long words. The
reason for this is to have flexibility in having many different views
each of which should be easy to read. Longer field names cause wider
columns and thus harder to fit more info into some views.
- Prioritization. I like having a two-character multiple
choice field which I usually call "Pri" with values P0, P1, P2
(default), P3, P9. Don't make this mistake of making everything high
priority, or the same priority. :) I try to use P0 only when something
is very urgent. I use P9 to indicate something which is on the list
but which is very low priority, a task not to be worked on but to be
listed so as to show that we didn't forget it.
- Owners. Databases used for issue tracking should have
owners. I like using unix login names to keep the owner field all
lowercase and eight characters max. :) I don't like issues with
multiple owners-- always assign one main owner/driver, and they can
get the help of others as needed. You can use an owner of TBD when you
want to list an issue but you are not yet sure of who will own it.
Example QuickBases
