Entries Tagged 'Thoughts' ↓

Sakai Futures, part 2

It seems that at least a couple of people read my last editorial. I didn’t expect to write a part 2, at least not here or now. But it’s worth a bit of clarification…

[See the very end for the “bit” part…]

The Sakai Product Manager, Clay Fenlason, has posted some notes on this ongoing discussion. He rightly points out that it is evolving and happening in large part on the “management list”, and that you should join up or watch the archives if interested.

The purpose of this post is to clarify what looks to be a basic disconnect on my opinion, since I was cited and don’t mean what it looks like Clay heard. He says:

But again our first practical example risks a misunderstanding - that the full process is only really about Sakai 3. There are even some knowledgeable community leaders that are coming to this conclusion and holding it forth as an insight.

It seems that Clay has drawn an interpretation from my communications where I would attribute the process primarily, or even exclusively, to 3.x, thereby grandfathering 2.x into some who-knows-what process. If he read it this way, it is fair to say that others might, too.

I feel quite the opposite, in fact.

Continue reading →

Sakai Futures

Something has been gnawing at me. Here is my initial assessment:

There are some gradual but quite significant changes coming to how the Sakai community works and releases software, and these changes are quite unclear.

I don’t think this is controversial or surprising. I do think that there are lots of ideas, fears, and desires for how this might work out. We are definitely having organizational growing pains.

Here is what I see as already present:

  • Two new groups: the Product Council and Maintenance Team
  • Release Management emerging as possibly distinct from QA
  • A relatively new and evolving Product Manager role
  • Two streams of software (2.x and 3.x)
  • Tension about how each of these roles shapes either stream

Where I’m going with this is that three of us on the PC share a homework item of looking at what would be helpful support of our Incubation and Product Development phases. However, I have been confounded about the very essence of this assignment given the above list. See the email below for specifics — it also frames this post as a written reflection.

So, let me reflect.

Continue reading →

Dirt & Grass

Dirt and grass are beautiful. Rocks, twigs, and bugs, too. Sometimes this world recognizes only majestic cathedrals, all too happy to look past the essence of life.

This is a corollary to something I’ve been struggling to articulate lately. Open source has made it; and because it has made it, people want to make it big. This is fine. I don’t have a problem with big companies, big projects, big money, and the rest.

Where I get uneasy is when people cultivate the sense that the fundamental distinction of free software is just access to source code, or the even simpler view of having no licensing cost.

No, this isn’t what really gets me. Continue reading →

Graceful AJAX degradation / progressive enhancement

In one of those beautifully lucky moments, I found an article I was wishing I had kept track of last night. I was chatting with Chuck and Matt a week ago about the pervasion of script in web pages these days and how hardly anything degrades reasonably. For years, I refused script entirely but, now, I have fallen victim to the trend. “Everybody has script enabled anyway. Mashups are inevitable. They want AJAX. Just script it.” That doesn’t mean that I don’t still want to use ELinks deep down.

So, I read one of those articles a while back where you feel a little bump and realize someone has lighted the path — with the best kind of light, showing the unnoticed obviousness. It’s like observing that HTTP actually works pretty well when you use it as carefully built, ten years after working around it furiously. It’s like noticing that really ugly (well structured, unstyled) web pages take the most beautiful CSS easily.

But I lost the article. And my recollection didn’t do it justice or support the point that you can script the snot out of a page without breaking Lynx. Then I read the Thread on Safari support in Sakai, mentioning Yahoo! Graded Browser Support. And something snapped; I thought this may have been where I found the article…

The article was on Hijax.

This is a cute name Jeremy Keith came up with for an approach to adding AJAX magic without breaking the basic function of web pages. It’s more or less a philosophical first principle of modern web development. You should read this article daily and soak it in like the Tao. -NB

37signals, entropy, and Sakai

Nathan Pearson, Sakai’s lead for the UX Initiative just forwarded a post from the 37signals blog. It’s referencing a video interview with Ira Glass, where he talks about being a fierce editor and moderator, cutting more tape than you roll. The post extends the interview’s mention of entropy as the disorganizing, enemy force to software.

In principle, I agree: entropy tends to bloat, delay, and complicate software. But the read-only experience of listener/viewer in storytelling is a bit different from daily use software. The post reveals some of the company’s “less is more all” philosophy.

Continue reading →

Personal artifacts vs. official purposes

How long should personal artifacts submitted in some official capacity be viewable (by learner or official) in their original state? How we can let learners really own their materials?

We’ve approached this problem to date by ignoring it. We make an explicit step: at some point, we force to student to say “I’m done with this thing and it’s yours forever”, and lock it. Or we just let it be malleable forever.

This is directly analogous to how, in logic, math, and computer science, we sometimes restrict input to maintain a lower conceptual threshold. Persistence and security of artifacts is a really hard problem, so we make sure it can’t destabilize the easier ones we’re solving, by distilling a complex grey gradient into blacks and whites.

It’s a perfectly valid way to get a foundation, but it’s time to move into our version of second-order logic — versioned, purpose-stamped, multi-threaded artifacts — to address our complex realities. We can’t lie to ourselves and believe that hard-locking a student’s file forever is practical in a personal learning experience.

The specific thought that triggered this post was that the notion of estimated secure lifetime in cryptography is relevant to visible/storage lifetime in ePortfolios. However, this post also includes thoughts on the concepts of fluid artifacts being copied and made concrete at submission time, and how this relates to our existing web/email usage patterns.

Lots more below the break.

Continue reading →

Sakai and OSP — development, accountability, personalization

Sakai/OSP development is expensive, so it’s hard to find funding prioritized for the “soft” benefits of personal ownership and development that might not jive with the “hard” outcomes understood as necessary for accountability.

I believe these “soft” outcomes can communicate accountability just as well, and even better, but it’s a much more intensive project that needs smart, creative, dedicated people over time. The consumable accountability data needs to be assembled as a secondary product, as opposed to the primary, “automatic” data products of rigid accountability measures. (…which feel a bit like TPS reports to student, faculty, and implementors, in my experience.)

This is one area where the “lower bar” open source systems have an apparent upper hand in development. Good portions of the development happens by motivated folks who have some time to give to personalization. It’s easy enough to “get in” that essentially unfunded effort bolsters those aspects.

I believe that, in today’s higher education climate, any system that doesn’t address accountability in a systematic fashion will fall out of favor very quickly at any institution where the words “ePortfolio” and “assessment” have been uttered in the same sentence. It’s really hard to build a realistic accountability system in your spare time, out of the context of a real accountability project.

This is where Sakai/OSP is uniquely positioned. We’re admittedly a bit behind on personalization, but that is changing quickly. At the same time, we have a depth of reach into the “regular” learning system activities and assessment capacities that’s unparalleled. It’s also a primary goal for a number of us to make raw development much easier. I really believe the 2.6 release has the potential to change the game. -NB