Will’s Similiblog

I added an “about this site” page - created as a static page (from the Admin menu, Create content; Page); giving this an address “about” in the URL path settings field.

To link to this, I created a link in the primary links menu - administer > site building > menus; primary links, linking to the path “about”.  In the default Drigg theme, these primary links show up in the upper right hand corner of the page header.  I’ve also linked in this menu to our school’s course management platform (a Moodle installation).

The Category links - which show up just below the header logo in the default Drigg theme, as well as in the Categories block (upper right-hand sidecolumn by default), are pulled from a Drupal “vocabulary” (taxonomy) - configure these at administer > content management > categories, creating category terms in the “Category” vocabulary.

I think I’ve finally come to some resolution re the issue of featuritis in my social learning platform - and decided to go the route of individual linked sites for specific functions.

For user-contributed news with social rating & commenting (Digg-like), I’ve played extensively with Pligg, Drigg/Drupal, and a custom platform hacked together in Drupal.  Drigg has evolved handsomely over the past several months, and the most recent releases are behaving very nicely, with the feature-sets that I need.  My current site, launching into production this week, adds a few bells & whistles to the basic Drigg/Drupal distribution.  I’ll document those here.

Editing (submission, voting, commenting) is restricted to authenticated users from a closed community, but you can view the site, at http://drigg.ncnm.edu.

I started with the standard Drigg/Drupal installation from
http://www.drigg-code.org/pages/download_and_install
- using the “express” installation, which bundles the Drigg-specific modules with a Drupal installation, and pre-configured database.  Just today I updated to the 9/25/08 release (NICE work on this, Tony!).  Setup is well-documented & went on without a hitch.

I’ll follow with some posts re my customizations & additions to the basic installation.

for users of our NCNM Drigg installation, a short (08:18) video tutorial re basic navigation of the site:

 

 drigg tutorial 2 - navigation [00:08:18m]: Play Now | Play in Popup | Download

a brief video tutorial (10:19) re setting up an instance of the Scheduler module in Moodle (intended for my fellow faculty at NCNM)

 

 scheduler setup Moodle [00:10:09m]: Play Now | Play in Popup | Download

I’ve set up an installation of Drigg to go into trial production for my school (the National College of Natural Medicine), for social contribution/ranking/discussion of health-related news w/in our learning community.  Editing will be restricted to our community, but contributed material is world-readable.

Below, is a brief (5:36) video tutorial re use of the system:

 

 NCNM Drigg tutorial [00:05:36m]: Play Now | Play in Popup | Download

——

If you’re setting up a similar site, and wish to use the excellent javascript “Submit to Drigg” bookmarklet - the code for this, found in the Drigg forums, is:

<a href=”javascript:q=(document.location.href);t=(document.title);s=(document.getSelection());void(open(’http://YOURSITE.COM/node/add/drigg?url=’+escape(q)+’&title=’+escape(t)+’&body=’+escape(s),”,”));”>Submit to Drigg</a>

- be sure that the page this is placed on, has “full HTML” as input format (ask me how long it took me to figure out why it wasn’t working …)

A screencast illustrating the Gallery2 Map module, permitting geotagging of photos uploaded to Gallery2 albums, and integration with GoogleMaps and GoogleEarth.

 

 gallery2mapmoduledemo [00:10:55m]: Play Now | Play in Popup | Download

See my Gallery2 installation with the Map module at work, at http://gallery.similibus.org.

I’m trying out a navigation solution to my featuritis dilemma. As I’ve got 3 major features on my site - [1] a community blog, [2] aggregated news feeds, and [3] an aggregation of forums postings from selected forums in an associated Moodle course support platform (I’ll describe this, and the reasons for it, in a subsequent post) - each with multiple views - the comprehensive navigation for all 3 features together was growing cumbersome, with a rather lengthy side column of menu blocks.

So - I’ve created a front welcome page using a “Page” node, with a menu block linking to each of these 3 sections of the site; and added links as well to my 3 sections in the “primary” menu, which displays below the header on all page views.

The side-column menu blocks relating to the Community Blog should show up on the various views of the Community Blog “section” of the site, but should not show up on the views relating to Aggregated News or the Aggregated Forums, & v/v. To accomplish this, I’ve set up custom block visibility for these views.

On the Blocks Administration page, to manage block visibility, click on the selected block’s configure link. At Show block on specific pages:, select Show if the following PHP code returns TRUE (PHP-mode, experts only). Paste in the equivalent of:

<?php
$match = FALSE;
$types = array(’blog‘ => 1);
if (arg(0) == ‘node’ && is_numeric(arg(1))) {
$nid = arg(1);
$node = node_load(array(’nid’ => $nid));
$type = $node->type;
if (isset($types[$type])) {
$match = TRUE;
}
}
$url = request_uri();
if (strpos($url, “blog/“)) {
$match = TRUE;
}
if (strpos($url, “tagadelic/list/1“)) {
$match = TRUE;
}
return $match;
?>

The first criterion - $types = array(’blog‘ => 1); - will include this block on all single-node pages where the node is a blog entry.

The second criterion - if (strpos($url, “blog/“)) { - will include this block on all pages where the URL contains the string blog/. I’ve set up the various Views of the community blog, in their Views settings, to have the url blog/… (e.g., blog/communityblog_listview, &c.).

The third criterion - if (strpos($url, “tagadelic/list/1“)) { - will include this block on the tagadelic tag-cloud page that lists my blog-specific taxonomy (but will not include it on the tagadelic pages displaying taxonomy specific to news aggregation &c.)

This was repeated for each of the side blocks that I want to see displayed on the Community Blog related pages of my site; these will now show up when the user is navigating through pages related to the Community Blog, but will not show up if the user is in other “sections” of the site.

Side-column menu blocks for the other sections of the site are similarly configured, to display menu items specific to the News section only on the pages dealing with aggregated news, &c.

I like it - it works ;^)

In the continued development & refinement of my social learning platform, I find myself facing a featuritis dilemma, as elegantly described by Kathy Sierra (illustration from her most wonderful blog):

How to resolve? Navigation? Simplification? A collection of simple sites each of focal purpose, linked with one another, v/s one “swiss army” site? Do I/we need all this?

Aggregators were apparently developed to help shift the web-phenomenon east of “happy user peak” to the left; yet my aggregation site seems to be beginning to slip down the slope past “guess I better look at the manual …”.

I’m wondering about using Drupal’s multisite function, with the multisite_login module, to create parallel sites for separable functions of my currently swiss-army-ish tool - with shared user db’s and single login. Community blog with aggregation of users’ distributed content on one site, community rated aggregated news on another, aggregation of selected Moodle course forum discussions on a 3rd.

Or perhaps I’m just getting too excited about the tools, & need to simplify overall. The tools are just too cool.

Without a few tweaks, posts will be identified as authored by “xena123″ or similar usernames. To make this a truly social experience, I’ll need to have real names resolve as authors; and to add a carbon-based element to the user experience, I’ll need user pictures to accompany posts.

Online conversations can be of very high quality, and can be quite human in character - my little Rosie (the Bernese retriever / golden mountain dog puppy in so many of my postings) came to me through an online friend, as a case example. But I am convinced that there is unique character to face-to-face conversations in the hall or library or the coffee shop across the street, and I’d like to see this platform act as a nidus around which such conversations can form. For this, we need to be able to hang our conversations around names and faces.

For this, we’ll need to configure drupal’s built-in user-picture support; enable and configure the core Profile module to provide a real name field; and install, make a minor hack on, and configure the 3rd-party Authorship module to substitute users’ full names for usernames in posts.

For pictures -

In Admin > user settings, check the Picture support - Enabled radio button.
The picture image path field needs to be designated (e.g., pictures)

In Admin > Themes, click on the “configure” tab; check the Display post information checkboxes for Blog entry and Feed item

Users can upload pictures at “My account”/edit
At Admin > user settings, you can post user picture guidelines - explaining that for the purposes of this site, these need to be real, recognizable photos; and not photos of the user’s dog, “avatars” of Xena Warrior Princess, &c.
I’ve found it handy to bring a digital camera to the first week of classes, and delegate to a student the task of getting pics of their classmates; these can be distributed for users to upload, or as admin, you can spend an evening getting pics up for a more cyber-confidence-impaired user population.

At Admin > Profiles, create a single-line textfield profile_fullname in category personal information. Check the public field - shown on profile page & on member list pages radio button, and the checkboxes for visible in user registration form and user must enter a value.

The Authorship module needs a small hack; as is, it will substitute the user’s fullname for the username in teaser view and in single-node page views, but not in views with multiple full-nodes on a page. To fix this:

open authorship.module, and edit line 157, to read
if( $page || $teaser || $node) {

At Admin > Content type > Blog entry, find Enable authorship module functionality and check the enabled radio button.  In the The profile variable name used to store the real name: field, enter profile_fullname.  Do the same at Admin > Content type > Feed item.

Done.  Now posts - both Blog entries and aggregated distributed user content - will now be identified by the user’s full name, and will be accompanied by the user’s photo.

Have also been playing with drigg, a ‘Digg clone’ written as a Drupal (5.x) module suite. Works very much like Pligg, reviewed in my last post. Voting is done using the drupal votingapi, with extra_voting_forms as the interface. In addition to accepting individual submissions, like Pligg, drigg will import rss feeds, and has a very nice feed import interface. The rss import function depends on the default drupal ‘Aggregator’ module, with the addition of some custom code in the drigg module itself. A provided theme gives a Drigg/Pligg-like look & feel.

I had no trouble setting up an installation & getting feeds to import.

My sense is, after playing a bit with both drigg and Pligg, that if a dedicated Digg-like “social-ratings-of-submissions & feed items” site is desired, without the need for added functionality, I’d go with Pligg; if there is reason to integrate this with other functionality that could be provided by other drupal modules, drigg will perform the same tasks quite nearly as well within a drupal installation. The module suite is under active development, and has come into its present state quite quickly, so I’d keep an eye on it.

Currently, I have a site set up as a dedicated drigg installation; I’ll be messing around with integrating this into one portion of a more comprehensive drupal installation, to see how well it might integrate with other drupal functionality. Drigg’s feed import functionality depends on the default drupal ‘aggregator’ module, which does not play well with the very elegant ‘aggregation’ module I’m using on my social learning platform for aggregation of users’ distributed content; so this strange need I feel to aggregate two different types of content separately on my site may leave me in a pickle (perhaps I need to use Drupal’s multisite and multisite_login capability, & create 2 sites with single sign-in, each using the Aggregation module to its own ends, one to handle aggregation of news and 3rd-party submissions with social ratings, and one to handle users’ distributed content with comment-density surfacing of content? - perhaps I’m just nuts).

For drigg in action, see here:
http://www.drigg.org/
or here:
http://www.fsdaily.com/