About a decade ago I discovered that I have a soy intolerance, and
recently my sister discovered that she has a milder version of the same
problem. (Our symptoms are similar to
lactose
intolerance.
) As I began to deal with the problem, I found that hunting down
prepackaged foods that were free from soy proved to be a difficult and
tedious pursuit. After watching how much time and effort my sister and
I spend reading labels, my niece described us as “more label
conscious than vegans.”
Along the way, I came across a discussion group for those who are
Soy and MSG
allergic.
On the forum we shared foods we found or restaurants we discovered
that were willing and able to accommodate our needs. Unfortunately,
searching the previous posts was not an easy process if you were trying
to find foods that fell into a specific category, like
“soups.” The
only way that things were going to get any easier was if we had some
kind of database system to provide easy
access to the information. I decided to take some action. I found an
available domain name,
AllergyFreeFood.org,
found a
host for the
website,
designed
a database layout, put
information
about my plans up for people to comment on, and then ...
procrastinated.
At first, I didn’t get many comments on what I had designed.
Then
other
projects started to fill my time. Finally, the real issue
became apparent to me.
Getting the project started was going to be hard.
Regardless of whether I used MySQL/PHP, Smalltalk/Seside, or some other
toolset, putting together the infrastructure and the necessary web
interfaces was likely to be tedious.
Meanwhile, as I procrastinated, interactivity on the web changed as the
use of
wikis
became
widespread.
This changed my thinking about what my users might want
to do with their allergy and food data. I began to vacillate
between whether a structured database would be best, or some kind of
moderated wiki would be best. No doubt, many other projects have
remained unfinished and on the shelf because of problems such
as
mine.
When I began reading about
Dabble, I realized
that I may have reached a point where my procrastination had
transformed into patience.
I sent them an email, explained some of the above, and they
invited me to be one of the beta testers. (The email had the
same
title as this posting. Never underestimate the power of a well-titled
email.)
[Full disclosure: I allowed the people at
Smallthought Systems
to read this essay before I posted it. I wanted to give them the chance
to tell me if anything I had written would be violating the beta
testing
agreement between us.]
From my beta test experiences, I can say that Dabble may just
be a safe passage “between a Wiki and a hard base.”
While testing Dabble, I’ve found that it allows you to work
as if you were
molding
your databases
out
of
clay.
You can start with a general idea of what you want to do with some data
and work your way toward optimal presentations for it.
Like a standard database system, Dabble provides various field types
and ways to set up links between your different data groupings.
The basic field choices include variations of Text, Number,
Money,
Date/Time, Pick from a list, User id, and a planned image field type.
One advanced field choice is
a field that links a record to another record in the same or a
different Category (That’s Dabble’s name for a
table.). A second
advanced field choice provides a way to have a list of those record
links.
Like a wiki, Dabble provides ways for users of varying skill levels to
add to the available data and to make some modifications to how the
data is arranged and presented. Users of a Dabble application can add
or delete records and can make changes to the data in existing records.
They are also allowed the same capabilities when it comes to the
structure and layout of Categories. They can change a field’s
type, add
new fields to a Category, or delete existing fields.
Perhaps one of the best places where Dabble stands out is in the
malleability of its data views. Users can add, rearrange, and remove
columns from views, and data listed in those views can be grouped and
sorted. Views can also be modified to exclude data or only
include data that pass various conditions. (This is referred to in
Dabble as “filtering.”) Finally, after any of these
changes have been
made, the user can give the resulting view its own name.
Are the databases created with Dabble
Relational,
Network,
or
Hierarchical?
I don’t think it matters because I don’t think the
users need to care.
The standard models of databases were designed to solve large problems
for large organizations. Dabble isn’t trying to solve those
types of
problems. It’s trying to help solve the smaller problems that
were left
to languish because they couldn’t gain enough momentum to be
solved
with existing tools.
Since the average user isn’t trained in database design,
won’t their creations be horribly sub-optimal?
The results of experiments done by the
Center
for Bits and Atoms
at MIT suggest otherwise. The researchers there have created personal
fabrication systems that ordinary people can use. In a recent edition
of the radio program
Science
Friday,
the director of the MIT program, Neil Gershenfel, discusses what
happened when they put these fabs into the hands of ordinary people.
(Audio:
mp3,
RealAudio,
Windows
Media)
About 20 minutes into the call-in program, Adam, a product designer in
San Francisco, worried that untrained, ordinary people in a remote
village wouldn’t have the skills to correctly use these fab
systems.
Mr. Gershenfel said that they found out that official training programs
weren’t needed because people would find ways to learn what
was needed
for the tasks at hand. He referred to it as, “‘Just
in time learning’
rather than ‘just in case’.” I believe
that these personal fabrication
systems provide the same kind of malleability in the arena of personal
physical design as Dabble provides for database application design.
Despite this high praise, Dabble does have its limitations.
Wiki-like mark-up and textural formatting support is still in
the
design stage. As an example, while the text field subtype that holds
URLs produces a clickable weblink
in the list views, there is no direct way to associate a title or
alt tag with the URL. If you want to have something like a title
associated with the link, you will need to place another text field
near it in the list views.
Since Dabble uses a passive security model, changes will be trackable
by user, but there is no way to set up differing levels of permission
other than to provide full access or read-only access. This is a
reason that Dabble isn’t really suitable for an application
with a large user base. (Please read
Clay Shirky’s
presentation “
A
Group Is Its Own Worst Enemy” for an explanation of
why large user bases need tiered permission structures.)
Applications for large user bases are further hindered by what seems to
be Dabble’s data-centric approach. On the beta
testers’ email list, I
proposed an imagined collectable book database. The idea was that there
would be a table (category) with entries for each of the books and all
of the pertinent info. In addition, each user would track which books
they owned, wanted, or were willing to sell. For
tax purposes, I thought each user would also need to track what
they had paid for their copy of the book and/or how much they had sold
it for. Profit was to be tracked in a derived and calculated
field. In response, I was told that the idea wouldn’t work
very well because the
initial security model wouldn’t provide a way for users to
restrict
access to their own data.
However, there may be a way around these types of limitations by using
the planned programmer APIs. A more sophisticated application could be
developed using standard web development tools and by using
the APIs, Dabble could be the system’s back
end. (This prompts me to wonder if it would be possible for
two Dabble applications to share data between them with the same APIs.)
In regards to customizing the page layout, the options are few. The way
the data is displayed might be
best described as
a table or spreadsheet layout. As I mentioned above, what
columns
are displayed and what order they are displayed in, are in the
control of the users. Beyond that, there are only plans for allowing
company logos to be placed on the pages and for limited tweaking of the
presentation color schemes.
Another limitation comes when linking a record to other records. The
dialog box for establishing a connection only
allows one connection to be added at a time.
Making multiple connections can be tedious after a while. (To be fair,
the Dabble people are aware of the flaw and are attempting to come up
with a UI design to allow multiple connections to be added at once.)
Also, there is no way to specify an item order in a list.
Unfortunately, this limitation means I can’t use Dabble for
my Allergy
Food database. Since some people
can only tolerate small amounts of an allergen, the order of
ingredients on a food label can be vitally important. (Luckily,
the
new food labeling laws may provide some relief for those of
us who read labels as if they were mystery novels.)
Although I can’t yet use Dabble for my original application
idea, it
may be better suited than this blog for spreading the word about open
Smalltalk positions.
One advantage of note is that Address fields are automatically linked
to Google maps. This is
very
handy
with job postings if you want to see where you might be working. (In
the future, this
active link idea may be carried over to other text field sub-types and
other external data sources.)
One disadvantage came when I tried to figure out how to link to the
actual job postings on places like Dice and Monster. It is possible for
multiple companies to be recruiting for the same open position. On my
blog, if I came across one of those situations, I would do something
like this:
- Application
Developer - Experience in Object Studio Smalltalk is
required and experience with Order Management systems a plus. Oracle
SQL, Word
In my details about open positions, I have provided multiple pieces of
information with my use of weblinks. I have been able provide an active
link to the job posting and I’ve used the link title to
convey the name
of the posted position or provide the name of the company that was
recruiting for the position. As I mentioned above, there
isn’t an easy
way to associate a title with a URL field type. Dabble
doesn’t really
provide an easy way to establish or maintain “one ->
many -> one”
associations like these.
In order to provide something like the information I had already been
providing, I had to create a “Companies” category
and a “Job Link”
category.
An entry in the Companies category includes information such
as
the company’s name, a text blurb about the company and a
weblink to
their homepage. An entry in the “Job Link” category
contains two things:
a link to an entry in the Companies category and a weblink field
pointing to a posting on a job board. In the main Open positions table,
I have a “List of entries” field that points to any
number of Job links.
This may seem to be a bit convoluted, but it will make it easier for me
to get the word out about new Smalltalk jobs. Publishing job lists
through my blog requires a lot of time spent organizing the listings,
structuring their layout, and validating the various weblinks. Dabble
can take care of much of that for me, and it can provide various export
options.
Dabble is still in beta, but I’ve been given permission to
export data
from my Smalltalk Jobs application in RSS and HTML formats.
Every
filtered view in Dabble can have its own set of actively updated
exports. Since there isn’t public access to my application at
the
moment, I’ve derived some views that I think would be the
most useful
to my current readers. Feel free to bookmark or subscribe to the
exports of these location and date filtered views:
- This past week: RSS - HTML
- This past week in Canada: RSS - HTML
- This past week in European Union: RSS - HTML
- This past week in United States: RSS - HTML
- This past month: RSS - HTML
- This past month in Canada: RSS - HTML
- This past month in European Union: RSS - HTML
- This past month in United States: RSS - HTML
- All open positions: RSS - HTML
- All open positions in Canada: RSS - HTML
- All open positions in European Union: RSS - HTML
- All open positions in United States: RSS - HTML
As usual, feedback is always welcome.
