Drupal Features by Lois Delcambre with much assistance from Payal Agrawal and from Yinlin and Potluri and 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 hierarchy Subgroup block contains only children & only for one a time Note: both suffer in that they are NOT offering a faceted search. When you are in one tag/group and click within this list you DON’T drill down; you just go to the 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 specific content-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 n Collection 1 OAI Metadata Harvest Ensemble Fedora Repository Drupal UI w/search Drupal collection

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