Directories

Directories are a structure for organizing people and contacts on the website. For example, all staff members are listed in the staff directory. Directories also provide a convenient way of establishing who has a right to perform a given activity.

On the website right now, we have lists of contacts in the staff, on the board, and for various committees and events. These directories can be organized or unorganized.

Unorganized directories have no theme or central point organization. These directories are used quite a bit for tasks like determining who is a staff member, who is in a committee, or defining a general interest group like “surf kayakers”.

An organized directory typically rallies around some resource on the website like a club or river. One of the ideas in the Patagonia grant that funded this project was to organize groups of volunteers around rivers, organize people that are interested in rivers, and provide the details for important people relating to rivers. This is the motivation for organized groups.

It as a possible to create a group that organizes people that are interested in a given reach. It is fairly trivial to show these directories alongside the rivers in order share information about the people in the directories or solicit interest in the topic that the directory pertains to. This is approximately how the Stream team functionality is organized.

Directories have several useful properties. The most obvious is that they organize contacts information for people in a directory. Additionally, there's a function associated with the directory's page on that allows for a message to be sent to the entire group. Directories also control security on the website. This has implications on tools available through the website such as forums and wiki. Directories also may be used as a tool of recruiting volunteers or organizing interest groups.

One of the main ways that directories are used in the website is to provide a list of users or contacts for a given subject area. When used in this way, a site administrator can define a group of people, given a name, and provide a link to show the names, addresses, phone numbers, and other contact information for that group. This is the way that the site implements the staff graphical page, the regional coordinators page, and the Board of Directors page.

The advantage of listing contacts and directories like this is that the individuals can maintain their own contact information through the “my account” menu. Another function provided by the directory is that logged in users can contact the directory by clicking a link that says “send a message to group”. Finally, these directories can be easily maintained by the contacts inside of the directories that are marked as “group managers”. As such, these directories can be self maintaining.

Every directory can have permissions associated with it and can be associated with some function on the website. We have a directory on the website called “forum administrators” that is given superuser access to the forums by virtue of a permission called “forum administrator”. Another example of this is that the safety committee is given privileged access to the accidents database so that they can maintain it. This is by virtue of protecting the administrative functions on the accident database and restricting them to the safety committee.

The application of controlling permission to directories is quite powerful. A couple of the samples of how permissions can be used control directories are giving directories the ability to:

· create collaborative document through wiki

· buy products with a discount in the store

· ability to blog about a given activity

· ability to maintain and administer a private discussion group

· contact each other

· access information that the general public can not access

· administer parts of the website on a volunteer basis

The way to assign permission to do something on the website falls into three categories: normal, extended, and third-party.

Normal permission is controlled through the security button at the bottom of the webpage. Each page is composed of a number of gadgets in each gadget is given a set of verbs that it can perform. For example if you examine the user gadget and has verbs like “change password”, “view status”, “search”. You can associate with each of these verbs a specific group that can perform the action. In the case of the user, I give permission to search and change passwords to staff members and board members. I'll users of the website with membership in “website users” to view their own statuses and change their own passwords. In this way access to all Web functions can be protected or restricted to various directories. There always exists a directory called “website users” and “members” so that access to parts of the website can mandate registration or AW membership.

Extended permission functions similarly to normal permission except that an additional aspect of a page may be taken into account. An example of extended permission happens on the river pages and allows for Stream team members to be able to edit one river but not the other. Another example of extended permission is that the author of an article may always edit the article even though he or she may not be in a group that has article edit privileges. Extended permission is edited the same way that normal permission is. If particular gadget uses extended permission it will explain how it differs from normal permissions on the edit page.

Third-party permission editing happens when the site uses third-party software to provide a function such as forums, wiki, or the online store. Third-party permission editing will vary based on the software and is generally accessed through the administrator menu. For permissions on unorganized groups, the third-party software will recognize this groups by name.

For organized groups, the third third-party software will recognize all members of the organized directory in the same way. For example, the Stream team has broken up over river reach; however, the wiki will only recognize the Stream team in general not the individual reaches associated with the thousands of Stream team groups. There is a concept called formal groups that addresses this problem.

We use formal groups to organize club members who wish to have a private form on the website. Currently, the BWA has a private forum. There is a directory called club members and a formal group called BWA. The forum software recognizes the formal group called BWA and permission is set for the formal group so that they have exclusive access to the BWA forum.

Directories have built-in management tools that let them self organize. Each directory is given a group manager that can assign membership to the group. If the group has an unspecified group manager, every member of the group has this ability. Directories can also have open enrollment that allows any logged in user to join the directory by clicking a link. This option can also be configured to instantaneously allow automatic membership or send the group managers a message requesting membership. There is also an option to list the directory on the volunteer page so that AW can maintain a clearinghouse of volunteer opportunities in a centralized spot.

Organized directories on the volunteer page are managed by using formal groups similar to the way that third-party security uses them. The problem is that for a given organizational point, events for example, there can be hundreds of directories. In order to put the directory that corresponds with a single than on the volunteer page, a formal group must be created that specifies the specific event.

Directories have many shortcomings and are evolving. Improvements are planned to make display of the directory more aesthetically pleasing. There will also be some work on the role of titles and title assignment within the directory. Finally, security is not ideal with directories. In the future, gadgets will be given a list of permissions to be associated with a given directory. The problem with the current system is that a single logical action, like changing a password, may involve two steps (displaying the password changing form, and posting the update to the password). In the current system, the end-user assigning the permission has to know the names of both steps. This can be confusing.