the back-end demystified

OK, let’s suppose you’ve amassed huge quantities of data and you want to get them online. Or, maybe you just started to think about doing an online catalog and you’re wondering where to begin. A database sounds good. Everybody says so. Maybe you already have one. What then? The question: What do you need to do to get that data to go from your computer to someone’s screen out there? The answer: You need a back-end.

What is a Back-End?
A back-end is comprised of two things that operate in tandem—a data entry tool (an interface on your computer where you enter data), which is connected to an online database where your data is stored. Once your content is published online, any user who queries your database via your web site will pull the appropriate data to her screen. It’s a perfectly symbiotic relationship. Here’s a simplified picture of how it works:

The arrow to the left represents the cataloger pushing data to the online database. The two-way flow at the right represents the user’s queries—i.e., mouse clicks or typed words and phrases—going out and pulling back results.

Since a back-end is coded to transmit data to a web site in specific and predetermined ways, you need to find one designed especially for your purposes. An online catalog is only as good as its back-end and a back-end is only useful if it’s structured according to the best practices of cataloging. This is why you consult with an experienced software developer before talking to a website designer.

What Do I Look For?
The best interface will prompt you to enter data correctly just by the way it’s laid out. What you want to avoid is an interface where the fields are too few in number, because in an overly simplified interface design these are probably free-text fields.

Free-text fields are used to communicate nuance, ambiguity, and uncertainty which is fine when you are writing commentaries or composing remarks; normally they should be kept to a minimum. For the most part nuance, ambiguity, and uncertainty are uncalled for in a catalog. The real problem with too many free-text fields however, is that the cataloger is forced to cram many things into each one (we cover the dangers of this situation elsewhere). A good interface should allow for parsing data into larger sets of controlled fields.

Controlled fields use controlled vocabularies—groups of preferred words or phrases of delimited scope used to index and retrieve content efficiently through navigation or searches. So, for example, there should be a separate field for newspaper dates and another for journal dates. Even better are controlled lists in the form of scrolling menus, and better yet are controlled lists that you edit. These are what you want lots of.

Another thing: what if you have data and your fields don’t conform to the new product you’re considering? Find out if the software developer can migrate existing data to the new database and—this is important—massage the data into all the right places in the process. Realistically, you may still have some tweaking to do, but you shouldn’t accept a situation where you’ll have to do everything over again.

And lastly, if the developers are any good, they should be able to work with you to customize your database a bit, since no two catalogs are exactly alike. Granted, this may cost a little more, but a good back-end should allow for a certain amount of flexibility.

In the end, the relationship between content and form and its dependence upon well-built relational database structures helps maintain data integrity. After all, the question of universal standards for recording and delivering properly formatted data goes deep to the heart of what cataloging is all about.


Roger Shepherd is the Creative Director of panOpticon.


Have other questions you want to ask or topics you want to recommend for discussion? Please go to our question page to post them. Thanks.

Roger Shepherd
Article By :