Drupal Featuresby

Lois Delcambrewith much assistance from

Payal Agrawaland from

Yinlin and Potluriand the ensemble team

Drupal Strengths

• Open source

• Free

• Various modules available; each module is easy to install, easy to use

• Website is very easy to configure; easy to change the “view” of various things – all without programming

But …

• Some features are incompatible:

• Acquia marina theme does not support breadcrumb display – for the full path of group names

• Some features have disappeared:

• Taxonomy “force all” – where documents for a child/grandchild tag are also “known” as documents for the grandparent

• Og_calendar

are not available from Drupal 6.x onwards

• Lots of options; not a lot of guidance

blog entry is a single post to an online journal, or blog.

book page is a page of content that automatically displays links to adjacent pages, providing a simple navigation system for structured content.

case assigned to a particular project. (Part of bug-tracking module)

event creates a Calendar Event

forum topic is the initial post to a new discussion thread within a forum.

image (with thumbnail). This is ideal for publishing photographs or screenshots.

page, similar in form to a story, is a simple method for creating and displaying information that rarely changes, such as an "About us" section of a website.

poll is a question with a set of possible responses. A poll, once created, automatically provides a simple running count of the number of votes received for each response.

project for use with Case Tracker (bug-tracking module)

story, similar in form to a page, is ideal for creating and displaying content that informs or engages website visitors. By default, a story entry is automatically featured on the site's initial home page, and provides the ability to post

Content types (1)

Content types (2) for internal workings of the portal

Introduce and used by the portal:Collection Page The Featured Collection parses these pages.

Community Page The Featured Community block will parse these pages.

Extra content types (that we are not using and probably don’t need):

Articulation Group Articulation Group Post here

Ensemble Group Ensemble Group Post

Consider … this:

Drupal Forum: typical capabilities – topics with replies & comments

vs. this:

Drupal group (to discuss drupal features): Some “pages”, “blog entries”, “stories”, & an image

Structuring Options in Drupal

• Organic groups:

• Can have their own members

• Can have subgroups (and sub-subgroups, …)

• Tags

• Can be grouped into categories/can have subtags, sub-sub tags, etc.

• Content types

Structure Experiments (for CS1)

• We wanted to describe postings in the following dimensions (at least):

• Target audience

• Curricular approach

• Programming language used

• We wanted to figure out which structuring option to use

• So we considered “all tags” vs. “all groups”

• Note: a posting CAN be in multiple groups

Tags vs. Subgroup (1)Group categories block has

expanded hierarchySubgroup block contains

only children & only for one group @ a time

Note: both suffer in that they are NOToffering a faceted search. When you are in one tag/group and click within this list you DON’T drill down; you just go tothe other tag/group.

Tags vs. Subgroup (2)

• Only leaf-level tags are shown.

If parent group has content of subgroup

all groups are listed for the posted

Tags vs. Subgroup (3)

Using all tags:

The group list page has no tags/terms

Using all groups …

The group list page has all subgroups mentioned by default.

See “CS Non Major”,

“Python”, …

Our Choices (for CS1)

• Introduce (small number) of useful content types (e.g., textbook post)

• Use just one group (CS1)

• Use multiple tag hierarchies – one for each dimension of interest (Target-audience, Curricular-Approach, Programming-Language, …)

• Roughly … group ≅ folder in a directory; it’s a place to put content

Suggestions: Organic Group in computingportal.org

• Put only parent groups on group list page

• Use breadcrumb to indicate group and subgroups hierarchy (instead of long naming convention)

• Limit the content types to be used in each group (blog vs. forum vs. story)

• Use a different group home page for each group

Breadcrumb to get group hierarchy

Easy to navigate

Tabs for content types

Show documents that use

content from this one

Syllabus and Textbook Post are tabs for specific content types for CS1

Here’s an example of putting tabs for specificcontent-types. Tabs showed up on FOCES groups!

Bugs in Drupal

• Group categories block length limited to 20 entries

• Some modules support not available from Drupal 6.x onwards. e.g Taxonomy force all, Og_calendar.

• Acquia marina theme does not support breadcrumb display – Need change in theme's settings files

New features needed(New modules can be written)

• Faceted/Drill down/Compound search for tags and content types

• Ability to comment on existing tags – to get user's feedback including CO

• Ability to display the Content type with each posting

• Ability to browse by content types

What about forums?

• In Drupal, any posting … can have comments. And comments can have further replies … in a hierarchy.

• So … any posting is (basically) like a new “topic” in a “forum”

• So … should we use forums as well?(For CS1, we are suggesting that we have a forum for questions/suggestions – but use content types for main postings.)

Discussion

• Which structures should we use in Drupal?

• Philosophy:

• Our Fedora repository is our primary content

• We use Drupal to implement one of our user interfaces for Ensemble

• Some collections are hosted in Drupal

Discussion (cont.)

• Collections hosted in Drupal should be crawled (using OAI) and appear in Fedora

• Content (from Drupal) may have comments, replies, various content types, …

• Thus, our Fedora site could/should have richer content types and richer structures.

• And … an enhanced search capabilities in Fedora for this additional structure should be present in the Drupal UI

• (We crawl Drupal content -> Fedora -> accessible from Drupal UI)

Simple Diagram

Collection nCollection 1

OAI Metadata Harvest

Ensemble Fedora Repository

Drupal UIw/search

Drupalcollection

So … how much structure should be “mirrored” from Drupal?

• Seems like a bad idea to take “everything” from Drupal

• Seems like a better idea to define “classic” structures that could be harvested from Drupal and elsewhere:

• “classic” forum

• “classic” repository with content type & relationships

• and with comments, with tags, with ratings, …

• with subdocuments/mashups

• Virginia Tech is already doing this: mirroring the hierarchical structure of CSTA