Between a Wiki and a Hard Base
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:
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:
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
- Montgomeryville, PA
- 4 Months
- through Devon Consulting, Inc.
- This position also appears to be offered by Precision System Design, (a Corporate Member of the Smalltalk Industry Council).
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:
- Today: RSS - HTML
- Today in Canada: RSS - HTML
- Today in European Union: RSS - HTML
- Today in United States: RSS - HTML
- 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
