Sakaidelic Musings

It was announced yesterday to both the Resources WG and Pedagogy lists that the Resources Viewer aka Content Viewer is ready for QA.

After trying to get it working in 2.4 at the Conference, it's nice to finally see it in action. I think this tool shows that the whole approach to course resources is being rethought. I already know the main complaint users will have though: It's a little non-intuitive to add the descriptions and accompanying info to the items in Resources to see them displayed in the Viewer. Same goes for reordering the items.

Jim Eng mentioned that he believes the Viewer will one day become a tool for editing, as well as viewing, but I think limiting to read-only for scope reasons is not a horrible way to go.

Obviously, the Viewer still has some bugs, which are listed over on the project in JIRA. (You must have an account to see the issues.) Particularly, I'm interested in RSV-6, RSV-7 and RSV-14. I think those are the main deal breakers when it comes to including it our implementation of 2.4.

In the process of updating our skin for 2.4, I've (so far) come across two major skin changes.

The first is the removal of the 'a' tag from the selected tool in the toolMenu list. Pre-2.4, all the links on the left hand side were li > a > text, and the selected tab was li.selectedTool > a > text. However, the selected tab shouldn't actually go anywhere - it's specifically there to indicate where you already are. (I also think that's an accessibility requirement too.) So, it seems perfectly natural to remove the a tag and make the selected tab li.selectedTool > text, while leaving the other list elements the way they are. However...

Extreme (Sakai) Programming! by nicola

I've finally uploaded my pictures from the Sakai 2007 Summer Conference in Amsterdam. You can see all my photos tagged with SakaiAmsterdam07 or browse all 110 photos from the whole Amsterdam trip (including a special appearance by dancing fish flakes!)

Alternatively, you can see all the photos on Flickr tagged with SakaiAmsterdam07, or relive the magic with slides and podcasts from the actual sessions.

From the progress reports and votes on the sakai-dev list, it looks like we'll soon be moving to Maven 2 as our build tool. Up until now, Sakai was only compatible with older versions of Maven, so this is a good thing (it's never a good idea to be dependent on deprecated/unsupported versions of software). However, I don't know if there's any specific benefit that the community will reap here, other than that. The consensus seems to be be that while the work won't be fun, now is the right time to do it. So, get ready to update your documentation!

In more exciting news, there has been a movement afoot to change the way course overflow works in Sakai. Currently, extra courses get bumped into a html forms-style drop down list, which I was never happy with. A new patch that has been developed (SAK-10448) replaces this with a hidden div that reappears when the user clicks "more" (similar to the functionality on Chowhound.com). This div organizes the courses and projects, which is more intuitive for the user, but the question of user preference (perhaps the user wants to rearrange these lists) hasn't really been addressed yet. I definitely think we should go with this format.

There's a community website for Sakai that aggregates the blog posts of different community members, but I was wracking my brain trying to remember what it was called. Now I found it! Planet Sakai.org

Firstly, just wanted to post a link to this entry about Blackboard: Blackboard Is Losing Customers, but What Does It Mean? Basically, its too early to tell anything yet, but its interesting nonetheless.

Now, I wanted to recap the current state of Resources in Sakai. I've actually been able to make it to two conference calls, so I feel pretty plugged in right now.

It is a truth universally acknowledged, that the core "Resources" tool in Sakai is a key area for improvement in user experience, and it's definitely an important issue for us at NYU. We have articulated it as something like "course material organization and presentation," and many new tools or approaches are currently in various stages of work. Here is a summary (especially useful as we approach the Newport Conference):

• regular Resources tool
• Resources Viewer aka Content Viewer
• Citations Helper
• POCS (new!)
• rWiki
• Melete
• some kind of possible JSR-170-based front end?
• a possible re-write of the Resources tool (possibly based on RSF), codename: ResourcesWOW!

So far, the things that seem the most interesting to me are Resources Viewer and Citations Helper. I was happy to hear that two of my three dealbreaker issues for Resources Viewer have been fixed, and that soon Resources Viewer will be able to handle content not strictly in Resources (like Assignments, etc.)

Also, it was interesting to hear a tiny bit about Mark Norton's POCS. It's interesting that some of these tools are defined by purely functional requirements (Resources Viewer, Citations Helper, rWiki) and others are more to satisfy a certain pedagogical approach (Melete, POCS). It's interesting (but not surprising) that I find the former more interesting.

In other news, the Resources WG will probably have a meeting in Newport on Friday, possibly sharing a half day with Fluid, but nothing is confirmed yet.

Just saw an email from Clay today about SiteStats and User Presence. I'll quote:

We want SiteStats, but with a minimal performance hit. We are currently running with presence turned off, for performance reasons among others, but SiteStats requires having presence turned on if it is to track site visits.

The trouble is that in the interface the site visits chart is front and center on the overview page, and it of course will stubbornly show zero site visits (and use a pretty graph to further illustrate this nullity), which will doubtless be confusing for our instructors, or make them think it's broken.

We had the same issue, and since we didn't have resources to modify SiteStats and we had a small pilot group, we decided to turn presence on, at least for the short term, at just hide it from users, in case we decided to remove it later. (We also received anecdotal reports that presence wasn't as big a performance hit as one might think). However, Nuno says he will be working on a fix for this:

SAK-25091

The Full Schedule for the conference has been posted.

Jason and I will be taking part in a Sakai Community Panel called "Sakai in your Backyard: Panel on Organizing Regional Sakai Events" on Wednesday, Dec 5th, in the Newport Coast room from 1:30 PM to 2:10 PM.

Other presentations that I am excited/curious to see:

Web Services in Sakai
Large Scale Sakai
Tips and Tricks with Spring and Sakai
Optimize Sakai Server - Java Memory, Performance and the Garbage Collector
Intro to the Sakai EntityBroker
Strategic Pragmatism for Running Sakai - A Technical Perspective
Sakai and Reporting - Exploring Approaches to Extracting Useful Information
Sakaibrary Project Update - Subject Research Guides

It has crossed my mind before: why are site ids so ugly? I mean, I know they need to be unique, but can't they be a little nicer to look at?

Mike asks the same thing in this thread:
Custom SiteID - OK or dangerous?

It turns out a lot of schools are already circumventing the traditional SiteID creation process with their own. Who knew?

Although I'm sure there were a few people that wanted to show up that couldn't, the BOF for developers (and other technical folks) of the female persuasion went off fairly well. I met some really great people, and we had a great discussion about our experiences both in the Sakai community as well as in the technology community in general. I'm glad we put the topic out there in the Sakai community, and I've had some interesting discussions with many people (male and female) about the diversity of the Sakai developer community. Below I've included a list of our participants, and if wanted to come, but couldn't, just let me know, and I'll add your name to the list (for future discussion and possible events, etc).

Finally back from my month-long "sabbatical" and attempting to catch up with the dev list chatter.

Recently, I've noticed more than a few references to a Sakai "framework" - not a phrase I really understand in the Sakai context. Did I miss something? Every time I feel like I'm able to peel back a few more conceptual layers of the onion that is Sakai, I find seven new things that I've never heard of before. A lot of that is just due to the incredibly brilliant people we have working on Sakai (who don't always have time to write things down right away) and the collaborative nature of the work that leads to concepts being developed in ad-hoc ways (like during conference calls, or in hallway discussions during conferences).

However, in my RTFM research, I found that there is actually a confluence space for framework, which contains this nugget: "(Note that some documentation may refer to Kernel, rather than Framework, as the latter moniker was picked after we began exploring the concept.)" So Framework == kernel?

Except, looking a little deeper, I see from this confluence page that that's not quite the case, and that the "framework" concept seems to pre-date the whole "kernel" discussion. In fact, this all came to my attention in the first place because of Ian Boston's instructions for installing the ContentHostingService which say to deploy sakai "with framework."

At least I'm in good company:
"The current framework services are not very well defined (in my opinion)" -Aaron Zeckoski
"The current organization makes little or no sense to me." -Mark Norton

But the number of unread messages is at least amusing:

Due to flight delays, I wasn't able to check out "Fearless Javascript" yesterday like I had planned. However, now that I'm at the UPMC, I see that it's plastered with Sakai signs and it's pretty easy to find your way around. I love the architecture of UPMC - I'm not an expert on architecture by any means, but it has a classic late 20th century european/socialist university feel that seems straight out of a movie. As I suspected, temperature controls in the lecture rooms is also very "european."

Got a chance to meet a lot of new people last night and this morning. One side benefit of saying at the "not cool" Marriott is that I meet and socialize with people I would not normally seek out. It's forcing me to meet new people and that's always good. However, we're starting to see the results of having the sessions at UPMC as opposed to doing everything at the conference hotel - you're less likely to run into people and have those serendipitous meetings during off hours. There also seems to be some mixed feelings about the conference bar as well.

I thought today's keynote was interesting, very clear and offered some compelling arguments for teaching with technology that I will definitely be taking back home and using. However, I felt our (meaning NYU's) position in the teaching and learning with technology field is not quite a perfect match with the environment that Diana Laurillard articulated.

Like many US institutions, we are largely a Research university - our instructors (and many of our students) are also researchers. So I felt that the claim that Instructors are wholly unfamiliar with research approaches to teaching and learning slightly jarring. True, they aren't applying ALL those techniques to their teaching, but they are doing some of them. (Post continues below...)

I was very happy to attend the Content Authoring BOF and get some insight into the work and thought that has already happened with regard to this issue. I think it was remarkable how close our respective visions were and how much agreement there was. I was encouraged with how quickly people were willing to discard or admit the limitations of the current tool-focused paradigm.

I was happy that we could articulate (at least partially) the tension between content creation that is structured (and probably based on templates) and content that can be organized any which way ("wild wild west" content authoring). These approaches to content authoring are really more of a spectrum and a potential feature would have to be able to satisfy needs all along that that spectrum.

I liked the idea that we could both accommodate the ability for system-provided templates and also allow users to promote their created pages to templates.

I was also happy that while sequencing and tracking were articulated as important, everyone seemed to agree that neither were crucial for a first implementation.

I was also ecstatic to learn that the groundwork is being laid for Sakai to be aware of content/items/entities inside of tools (like discussion thread, assignments, etc.) in order to accomodate the need to place them on a page and treat them like any other piece of content in Sakai.

Yesterday Essex County College in Newark, NJ was our gracious host for another NYC Regional Meet Up. Essex, Rutgers, NYU, NYU School of Medicine, and CampusEAI were all well represented. We had a chance to talk about a variety of topics, specifically tools, adoption, and content authoring. We also looked at different Sakai sites and spoke about how different organizations have different approaches to using Sakai for teaching and learning in their respective environments.

The subject of portfolios did come up, and we discussed at length the types of use cases for portfolio functionality. Apparently both Rutgers and LaGuardia are doing some type of portfolio work, and NYU is interested. Perhaps we may have a portfolio-centric meetup at some point.

Jason and I also gave a recap of the Paris Conference and covered some of the trends that came out of it. It was great to see both new and known faces, but one of the things I was especially impressed about was variety of experience represented. There were, of course, Developers and Instructional designers, but also quite a few Faculty and Librarians!

If you're interested in particpating in the NYC Regional Sakai Group, please subscribe to the mailing list by joining our site on http://collab.sakaiproject.org (you may need to create an account first).

We had a great time at Blind Tiger last night. We had representatives from NYU, Marist, Columbia, College of Mount Saint Vincent, CampusEAI and the Sakai Foundation. We had developers, UI folks, systems people, client support and managerial types all represented. I'm including the flyer below for historial purposes.

If you ever wanted to swap out Jackrabbit for another JSR-170 compliant content repository (like Xythos) in Sakai 2-6-x, here is how you do it.

Special thanks to Ian Boston, Seth Theriault, Kevin Wiggen and Julian Reschke.

Although a session/panel/discussion on this is scheduled for later today, I wanted to capture some thoughts from the BOF yesterday on Sakai 2->3 migration.

The old idea of "hybrid" mode is still going strong - in fact, it's really the only idea going for transitioning users from one to the other. We're still operating on the idea that we can run Sakai 2.x "headless" and show Sakai 2.x tools inside of a Sakai 3 container. However, my concern is that at some point, there has to be some mapping and migration from a Sakai 2 tool to a Sakai 3 tool.

User data that relates to a particular instance of a course in a particular semester is not so important - although we have an obligation to retain that for a certain period of time. The data that really does have to be migrated to Sakai 3 tools is what Lance called the "structure" of the course. By that, we don't mean the particular layout - which would obviously be pretty different in Sakai 3 - instead we mean the content, but also the assignments, and the forum topics (although not the posts themselves), etc: anything an instructor would need to bring over to teach the course again to a new group of people.

Could we migrate this data piecemeal based on Instructor course copy? That is to say, when an Instructor is ready to teach a course in Semester B, and they want to copy old content from Semester A (we already have this metaphor in Sakai and Blackboard), the course copy process will migrate any tools to their Sakai 3 versions if those tools are available. For the other tools, Sakai 2 versions will be nested inside.

And then, when the Instructor is ready to teach Semester C, she initiates another course copy (from B->C), and now any remaining Sakai 2 tools are now migrated to their Sakai 3 equivelents (which are now available).

For those who attended the NYU presentation at the Boston conference ("Alternatives to OSP: Making Portfolios Flexible and Fun"), I'm happy to let you know that we've completed our testing with Jackrabbit, so we should be getting ready to release this code soon! I just have to write a README and tweak a few other things.

I'll send an email to the dev list when it's out there and we'll probably have something in the newsletter too.

I also know that our esteemed colleagues are doing some demos of the tool for those who didn't see it at the conference, so let me know if you're interested in that.

For those who have interest the Simonides Memory Palace code can be checked out from:

https://source.sakaiproject.org/contrib/simonides/

Please direct all feedback or questions to simonides.help@nyu.edu