Red Queen Review Engine User Manual

UNDERSTANDING THINGS & CONTAINERS
Adjust Text:  a a a a
« Table of Contents   |   Obtain Red Queen »

UNDERSTANDING THINGS & CONTAINERS

Red Queen's purpose is to provide up to 3 browseable directory structures of Items, Members, and Suppliers--or, if we can generalize, Things. Each of these Things can belong to zero or more Containers, as follows:

 Thing Type 

 Container Type 

 Containers per Thing 

Item

Category

1+

Member

Team

0+

Supplier

Yellow Page

0+ or 1+

As you might have begun to suspect by this stage, some thinking will clearly be required in order to set up your hierarchy. Thus, before you plow ahead with record creations at the control panels, it will likely save you time later if you take the time now to familiarize yourself somewhat with the concept of Things and Containers as they apply to Red Queen. The purpose of this page is to introduce you to the concept of a thing and its container. Discussion of the actual implementation of each specific thing and container is presented on separate pages.

THINGS

  • Items

    So. What is the interpretation of this trio of browseable Thing/Container trees? Well, if we were to set things up so that each Item represented a homepage, or Link, for some web site, then the browseable Link/Category tree is just your standard Link Directory. Each Link, in order to appear somewhere in the directory needs to belong to one or more Categories, hence the 1+ in the above table. Of course, Items need not correspond to Links. They might each represent an MP3 audio file, or they could correspond to pieces of work produced by an artist, or they could be toys, hotels, car models, books, theme parks... In short, an Item can represent pretty much anything you want it to represent. Later we will see how each Item record will represent one row in your Item table. See ITEM RECORDS for details.

  • Members

    What about a Member? Well, a Member is probably exactly what you think it is. A Member is someone who has registered as a user of your site and has been allocated a username and a password so that you can recognize them each time they return to your site and interact with it. In much the same way that you create Categories to hold Items, Red Queen allows you to create Teams to hold Members. You might prefer to think in terms of Groups, rather than Teams, but Team is the nonmenclature we'll use to describe a grouping of Members throughout the Red Queen documentation, and within the program itself. The main difference between Categories and Teams is that a Category contains passive Items which forever reside in the Categories into which they are placed (well, at least until you as the Administrator decide to move them out of a Category) while Teams contain intelligent entities that can put themselves on a Team or remove themselves from one. If you opt to let them do that, that is (you can in fact arrange things so that Team membership is by invitation only). So the idea behind Teams is that you as the Administrator create them and the Members join them of their own accord. Thus, any Team will have 0+ Members. Later we will see how each Member record will represent one row in your Member table. Jump ahead to MEMBER RECORDS if you want to know the details now. It is also worth pointing out that your Member database can be coupled with any other Member database that might already exist on your site, such as one established by a forum application like vBulletin, PHPBB, or any of several other popular programs. There are already Red Queen modules to handle coupling to a dozen other community applications.

  • Suppliers

    And what about Suppliers? How do they fit in? Suppliers are simply entities whose purpose is to be known as the supplier of one or more Items. Unless you decide to supply all the Item records yourself as the Administrator, you'll probably want to seek Item submissions from your Members. If you are familiar with Link Managers, you will know that the standard way to associate an Item with a Member is to add the Member ID value to the Item table as a foreign key. Red Queen also does this. But it also does something a little different. It forces the Member who wishes to submit an Item to create one or more Supplier accounts first. They may only submit a new Item by associating it with one of their Supplier accounts. There are some advantages to this:

    • Multiple Suppliers for a single Member
      If desired, the Member can choose the Supplier identity according to the type of Item they are submitting. As an example, the Member might specialize in supplying Items that go into 3 distinct Categories and the Member might wish to present one Supplier face or another, depending on the type of Item. To be more concrete, say you run a sports site that caters to collectors of sports-related Items. You might have one Category for Baseball Cards, another for Baseball Sportswear, and a third for Baseball Books

      • . One of your Members, "Babe Ruth", happens to specialize in all three, but prefers to create one Supplier account "East Coast Baseball Treasures" for managing the Cards and Books, and a second Supplier account "The Baseball Warehouse" to handle the Sportswear end.

    • Multiple Suppliers for a single Item
      As the Administrator, using this scheme, you could set up Supplier accounts for companies that don't actually visit your site, but who produce or distribute the Items that appear on your pages. You could then add multiple Suppliers for a single Item if that seems like a sensible thing to do--such as when an Item is not brand-specific, or when it is brand specific but you want to reference the brand distributors. In the case of distributors you might set up a Supplier account for each distributor and associate the Item with each of these.

    Now, just as Members can place themselves into Teams of their choice (that is, Member Containers) Members can attach their Supplier accounts to Yellow Pages of their choice (Supplier Containers). Yellow Pages thus are intended to group Suppliers with common attributes. What these attributes are we'll get to later when we examine the internal structure of Containers. As an example, you as the Administrator set up the Yellow Pages and one of these might be the Baseball Card Suppliers page--the perfect spot to advertise Babe Ruth's "East Coast Baseball Treasures" store. If Yellow Page placement is entirely optional there can be as few as zero Suppliers on a given Yellow Page (i.e. 0+). However, it is also possible to configure Red Queen so that no Supplier account can be created by a Member unless they specify a Yellow Page to go with it (1+). Later we will see how each Yellow Page record will represent one row in your YellowPage table. Jump ahead to SUPPLIER RECORDS if you want to know the details now.

CONTAINERS

  • Categories

    Items are assigned to one or more Categories of "similar" Items, so that people searching for Items of that kind will be able to find them more easily when the time arises. Red Queen requires that when an Item record is created, it is assigned to at least one Category (Members must nominate a Category, but the Administrator, or a Category Editor, has the final word and may reassign the Item to another Category altogether, or assign additional Categories).

    Categories in Red Queen have a hierarchical structure: each Category has a parent Category. This allows a tree structure to be created and a user can traverse the tree, narrowing the scope of their search as they proceed from top to bottom. To present users with the browse tree structure associated with Item Categories you direct them to the Item branch of your public pages, with a URL that looks something like this:

    http://www.mydomain.com/cgi-bin/path/to/.../redqueen/do/redqueen.cgi?module=find_item

    In fact, this refers to the dynamic branch of your Red Queen pages, or pages produced on the fly by the program. If you have elected to build static, or pure HTML pages that are updated, say, weekly, then the corresponding URL might be something like:

    http://www.mydomain.com/reviews/item/

    By clicking on Category links one proceeds from, say, Baseball to Baseball/Stuff For Sale to Baseball/Stuff For Sale/Baseball Cards. Each Category contains zero or more Items, and zero or more Subcategories. Eventually you either come across an Item of interest or you run out of Categories. When you do find a suitable Item, clicking on the link for it brings up the Detail Page for the Item. The Detail Page presents to the user everything about the Item that you want them to know about, including who the Suppliers are for the Item, plus member reviews of the Item if any are available.

    Categories can be assigned Editors, unless you feel the need as the Administrator to do all the work yourself (which experience suggests, is usually the case). If you assign an Editor to a Category, that Member will usually be responsible for approving (or rejecting) other Member submissions associated with Items in the Category. Item submissions and Review submissions will go into a queue and be evaluated by the Editor at a time of their choosing. Exactly what actions an Editor is free to perform will depend upon the permissions that have been assigned to them. Some of these permissions are global while other apply specifically to the individual Categories to which the Editor has been assigned. These permissions are covered in detail elsewhere.

  • Teams

    The presentation of Teams is exactly analogous to that of Categories. One is presented with a page of top-level Teams, and by clicking on successive Team links you arrive at Subteam pages that contain zero or more Members, and zero or more Subteams. Teams too have their dynamic representation:

    http://www.mydomain.com/cgi-bin/path/to/.../redqueen/do/redqueen.cgi?module=find_member

    and a static one:

    http://www.mydomain.com/reviews/member/

    Team Members have a detail page just as Category Items do. However, Members also have a Member Profile page which is the primary source of Member information. For that reason the amount of information about the Member presented on the detail page is far less comprehensive than that for an Item (a link to the Member Profile page is presented along with a very brief Member bio). The main purpose of the Member detail page, for a given Team, is to provide access to any reviews that may have been submitted about the Member in the context of their membership in that Team. After all, the reason a Member joins a Team is most probably in order to receive reviews.

    You might wonder about what is to stop a Member from joining as many Teams as they like. In short, you do. As the Administrator you can specify the maximum number of Teams any single member can join.

    What sort of Teams should you create? Well, that will depend very much on the type of community you cater to. A good idea is to create Teams whose members claim some kind of expertise in the areas to which your web site caters. For instance, if you were running a sports site you might create one set of Teams in which the Members supposedly are good at forecasting the results of sports events. You might create another set in which the Members are judged for their ability to offer critical post game analysis. Another set might represent the fans of particular sports teams. These Members might be rated on their level of enthusiasm and whatever else they bring to the table as a sports team fan on your site (sports history knowledge?). Basically, if you can think of a grouping of Members with common attributes, one or more of which can be be rated, and it makes sense to offer the ability to review the Member, then you can offer a Team for these Members to enroll in if they wish. If you find yourself stuck for ideas, ask your Members for Team suggestions. In fact, your Members will probably offer the best ideas precisely because they will know better than you what the benefits are to being a member of a particular Team. Their vested interest in Team participation should elicit plenty of ideas for Teams and the associated Team attributes. So poll them before you start populating your Team records, and you'll likely save yourself the trouble of having to "retool" your Teams later on.

  • Yellow Pages

    Supplier Yellow Pages are analogous to Member Teams in that Suppliers (or rather Members acting as Suppliers) can put themselves onto a given Yellow Page, or take themselves off one. As expected by this stage, Yellow Pages have their dynamic representation:

    http://www.mydomain.com/cgi-bin/path/to/.../redqueen/do/redqueen.cgi?module=find_supplier

    and their static one:

    http://www.mydomain.com/reviews/supplier/

    Once again, you decide how many Yellow Pages a given Supplier can appear on, and you create the Yellow Pages, each with its own set of ratable attributes. Suppliers who put themselves on a Yellow Page generally expect to be reviewed and rated by the community for doing so. Because we are dealing with the Suppliers of Items, your Yellow Pages will normally be oriented to the supply of goods and services, so your Yellow Page attributes will typically be things like Reasonable Pricing, Level Of Customer Service, Speed Of Order Fulfillment, Contactability, and all the other things that concern someone who might want to use the services of the Supplier. Yellow Page attributes, like those of Categories and Teams, are assigned on a per container basis, so you can offer both very general rating attributes, which may be used for the majority of Yellow Pages, and those that might only be used for a single Yellow Page.

    As it was for Members, Suppliers too have a detail page which offers just a modicum of information about the Supplier (along with all the reviews collected) as well as a far more comprehensive Supplier Profile page where information about the Supplier, including any business address and logo will appear.

« Table of Contents   |   Obtain Red Queen »

Copyright © 2004 Random Mouse Software. All Rights Reserved.