New look and feel to launch the first Opencast Project Community Workshop

Thanks to Seamus and Julian at Graphic Mint we are able to launch our first Opencast Community Workshop with a new logo and look and feel. Check it out.

MoodleMoot Usability Panel

In April, I presented at the Western Regional Educause on the Fluid project. An SFSU staff member was there, Wen Hau Chuang, and was interested in the project, its goals, and its methods. He has invited me to sit on a Moodle Usability Panel at the upcoming MoodleMoot on June 10-11 in SF. Never having been to a MoodleMoot before, I am really looking forward to getting a sense of the larger Moodle community. The Fluid community is also working on identifying Moodle usability issues, out of our York University Partnership, so I will be bringing some of their learnings to share at the Moot (is that how you say it?).

OpenCast Project Full Steam Ahead

The OpenCast Project team has been busy planning our upcoming workshop, June 5 &6, in Berkeley and our open house event on June 13, right after the WWDC.

There will be ten universities attending the workshop to dig into the requirements and best practices for open casting of university content. As you know from my previous posts this is not new to Berkeley, but what is new is our upcoming release of our newly architected application (I say with my knuckles turning white as I grasp the arms of my chair) this Fall along with the engagement of a much larger community of folks from around higher ed to work with us on developing the roadmap for soup-to-nuts open system. Open Source to Open Content.

The OpenCast Project has a new Blog (very new) which over the next few weeks will be gaining a new look and feel (thanks to our great friends over at Graphic Mint) and much more content. Much of the content from the early wiki will be moved over and new information added as we start to release the (oh so secret) plans for our workshops. The community best practices will start going up after our June workshop. If you are interested in contributing to this effort in any way (best practices, ideas, requirements, etc…) please don’t hesitate to contact me or someone else on the team.

Perfect UX Storm in Sakai?

Is there a perfect storm brewing for the Sakai Project’s goals of improving the user experience? I am very impressed with the confluence of ideas and action in the Sakai UX improvement initiative, the Fluid project, and CARET’s Sakai Web 2.0 project. These initiatives show the community prioritizing the user experience need and coming at a shared problem from many angles, each contributing pieces of the design activities, technology, and community building. After spending the morning perusing the sites and catching up on the happenings that I am more optimistic regarding Sakai’s ability to reach user delight than ever before.

In addition to bringing good ideas and changes to the Sakai product, I am liking where it is heading in the communication department. Nathan Pearson, the UX lead for the UX improvement initiative has used Flash demos with voice over to share his design ideas with the community. Working rapidly and iteratively, he has taken the approach of share earlier rather than later, iterate and improve. He has had a lot of good research and documentation to launch from, but he also uses his design expertise and general design best practices to move forward with some best guesses which can then be tested. This can feel risky to many designers, but if the promise of being able to iteratively improve is real, then it is well worth it in terms of getting buy in and concrete visuals. In the open source and community source projects, this may be the best way to be successful with design and usability.

If you haven’t seen his presentations, check them out:

Week 1, Week 2, Week 3, Week 4, Week 5, Week 6

Nathan’s approach and Cambridge’s approach with the Sakai Web 2.0 project represent a value that is hard to come by in higher education, partly because of tight budgets which means all work must be efficient and produce a product for our end users, partly because of the reluctance of our universities to invest in R&D within its administrative units (even when supporting the academic endeavors of the campus), and partly because of our tendency to invest in a narrow range of skills (the ones that we think will shorten the time to delivery — such as programmers — and limit overhead costs — such as project managers). That said, even a range of skills doesn’t guarantee good product. I think perhaps a value of risk taking, exploration, and getting stuff in front of users for feedback will be terribly important.

Jutta Treviranus and I will be leading a discussion on some of these ideas and challenges regarding building the right organization and culture at the 9th Sakai Conference:

Mara Hancock and Jutta Treviranus will lead a discussion that explores the culture, values, and structures within our departments and institutions that enable a User Experience (UX) approach to flourish and bring transformational change to our services and open source systems.

Using the Fluid/Sakai partnership as an example they will look at the range of roles, skills, and methods that precipitate and enhance the inclusion and embracing of UX in the development process. They will lead the group in the investigation of ways in which the Sakai foundation and contributing institutions can enhance and extend their staffing models and capabilities to create a creative, flourishing, and inclusive development environment.

Hope you can make it and help us explore these issues. Meanwhile, thanks to Nathan Pearson, the CARET team at Cambridge and their friends working on the Sakai Web 2.0 project for adding some additional wind to the perfect storm.

Open Cast Planning Grant

Thanks to WIlliam and Flora Hewlett and Andrew W. Mellon Foundations for joining together to support the Open Cast project (new site will be coming out soon) planning grant. This funding will support the project in conducting three requirements and best practices workshops to explore the requirements and readiness for a new community source effort around the shared development and design of an open source podcast capture and delivery system for higher ed. Outcomes will be documentation of the resulting requirements and best practices, the development of a collaborative community (already well underway with over 200 individual participants), and a well defined proposal for next steps.

Why is this important?

UC Berkeley has been delivering open webcast content (audio and video) since the mid-90’s. As we have increasingly automated the process, brought down the cost to sustain the system, disseminated the content to popular platforms such as YouTube and iTunes (go to where the viewers/learners/users are), and increased our installations, we have found that this program makes a difference in both lives and professions.

First, professions.

In Spring 2006, UC Berkeley launched a free podcasting service, which leveraged Berkeley’s existing video webcast infrastructure in general assignment classrooms and our central scheduling and capture system. In doing so, humanities curriculum was exposed to an eager public. These humanities podcasts have had a tremendous impact on the public and far exceed the popularity of the sciences – becoming some of the most popular podcasts on iTunes, wedged between notable media outlets like CNN and National Geographic. Popular courses include “Man, God, and Society in Western Literature,” taught by Philosophy Professor Herbert Dreyfus and Professor Michael Nagler’s “Non-Violence Today”

Webcast video and audio helps to spotlight humanities curriculum and faculty at a time when the humanities are struggling to receive funds and recognition. The American Historical Society, for example, highlights the Berkeley History curriculum on its website . One young Berkeley history lecturer used the webcasting of her course to promote her teaching and scholarship, eventually earning an assistant professorship at the University of Virginia. Without a scalable and affordable system and set of best practices, the sharing of this content and exposure for the Berkeley History Department would not be possible.

Now, lives.

ETS and our webcasting faculty get amazing letters from learners around the world. These webcasts are engaging, entertaining, educating millions of people. There is not a continent that has gone untouched. Here are a couple of examples:

“…As far as I’ve been watching it’s been great, though I’ve only been watching Physics 10 with Professor Richard A. Muller because he’s really such an interesting teacher. I’m interested, I’m laughing and I’m learning…”

“Is there a course on art history? If so I beg on bended knee for that to be uploaded!
Thank you a million times for allowing us to watch your lectures here!
The person who had this idea should be knighted or maybe a petition for sainthood!
The free flow of information is an essential part of the evolution of any society!
Thank you again!!!”

No kidding. Comments like this come in like candy, reminding us why we come to work every day at such an incredible public institution like UC Berkeley.

Interestingly, the UC Berkeley students seem to get it too. They are absolutely in love with webcast because it helps them learn better. In recent focus groups with ETS they have talked about using it to review the lecture and to listen to other teachers from other semesters on the same subjects. They will review the lecture notes at night and then listen to the podcast on the way to school in the morning. Several students have mentioned that while they would love to have these embedded in their course sites, they also don’t want to deprive the public of them. One student mentioned how the MIT OCW helped her augment her studies as a high school student in India and credited her acceptance to Berkeley because of that.

Wouldn’t it be great if more schools could/would do this too?

We hope that Open Cast will make it easier for them to join in.

Fluid Project Summit

The week of September 24-28 was the first Fluid Summit, held at the University of Toronto. This brought together folks not only dedicated to the project, but other key members from the associated communities such as the Sakai Executive Director, Michael Korcuska, and fellow Sakai board member, Clay Fenlason. We also had volunteers from the larger community, such as Kathy Moore, a UI designer from Boston University. Of course, we also had a large contingent from the Fluid Project core team as well, making it a pretty large group of designers, developers, and managers.

One huge benefit of the Fluid Project is that it reaches across communities - uPortal, Sakai, Kuali Student, Moodle — and brings people together around real work. This real work is what keeps us all motivated and getting up in the morning. I was surprised to find in a discussion with Michael Korcuska that he wasn’t sure about just how concrete the Fluid contribution was going to be. The Summit revealed to him how committed the project is to getting real results (designs and code) into these community source products. Michael wrote a great blog entry about the Fluid and Sakai as a result of his attendance at the summit. One of his statements that was particularly heart-warming to me was this:

“Fluid is Sakai

Looking around the rooms at the Fluid Summit I saw a lot of familiar faces from places like UC Berkeley, Cambridge and Georgia Tech. These folks know Sakai inside and out and that knowledge will ensure that what gets worked on is relevant to Sakai. Of course Fluid is other things as well, including uPortal and Kuali Student and Moodle, which should benefit everyone. But I stopped thinking about Fluid as a project that is somehow separate or “in parallel to” Sakai.”

When we were working on the proposal for Fluid, we articulated that Fluid would never be successful if it was seen as being from “outside” the community/open source project it was working to improve. Being inside — and trusted — is a critical aspect of making an impact and contribution to open source projects. Thus, we talked about Fluid as being “embedded” in the core projects it was working on. Michael’s comment indicates to me that we were right on with this approach.

It is important to stress that Fluid is not a theoretical exercise or experiment. Efforts from its teams have already begun to be seen in implemented designs and code. The component and design pattern libraries will be be built and integrated “as we go,” we will not wait to achieve perfection or critical mass. Everything is open and available now. This includes access to decisions, methods, mock-ups, user research, code, html widgets, components, and more.

Look for the U-Camp to roll out for the JA-SIG Un-conference in New Brunswick on November 11-16 and the Newport Beach Sakai Conference on December 4-7. U-Camps are a place to learn, talk about, and do design. They include UX designers, training and support folks, faculty, and programmers. You can see some of the activities that took place in the Sakai Amsterdam conference U-Camp. The Newport beach U-Camp will be the third U-Camp for Sakai, and the fourth delivered over the past year. The Sakai programmer’s cafe and the U-Camp are exploring ways to bring together UX designers and developers — perhaps in some sort of sprint activity.

Before closing, I want to reiterate that projects that directly contribute to and impact production systems are the only type of project you will ever find the UC Berkeley Educational Technology Services unit involved in! While we may lust in our hearts after the pure innovation project, it is critical to our mission as a services unit that where we extend our effort has direct impact (hopefully for the good!) on our constituency. If you notice my eyes straying, just give me a nudge.

User-Centered Design and Pedagogy

In my blog post at Penn’s State Terra Incognita blog, I talked a little about how UX designers can help bridge the gap between instructional designers and developers of teaching and learning software:

Another challenge in creating applications for academia is that many of the user goals are embedded in pedagogical methods that may be discipline specific or not expressed in a generalizable way. Instructional designers and faculty are rarely part of a development team. In the higher education community source environment we have an opportunity to remedy this. It may require reaching across local organizational divides to ensure that the user and instructional goals are adequately being met: Often, instructors don’t speak the language of technology, so the instructional designer can help translate, generalize, and communicate their needs. In turn, the instructional designer often doesn’t speak the language of the application programmer, and the UI designer can help translate and represent their needs within the design and work flow of the application for the developers. Here is a diagram that attempts to illustrate this point and show how UX can be a bridging activity: UCD in Higher Education

Since that writing, there has been a string of emails across the Sakai UI and Pedagogy email lists pertaining to this issue (just lucky timing I think). Mark Notess, a usability expert from the University of Michigan pointed the list to an article he wrote for eLearn magazine back in 2001, titled Usability, User Experience, and Learner Experience. While somewhat dated (according to Mark) there are still plenty of points that hold true today as we work on Sakai. This one in particular caught my attention:

Learner-Centered Design

How do the concepts and processes of user experience apply to online learning? To the extent that an online learning system is another piece of software, the applicability is straightforward. All of our methods that have worked well with software applications should be used with online learning and should work equally well. But creating online learning is not identical to creating typical software applications because we have to concern ourselves with things like instructional strategies, content sequencing, and quality of learning.

Web usability has been a hot topic for the past few years, but web-based learning faces some different issues. Web usability has largely concerned itself with e-commerce–product catalog navigation and converting hits to purchases. Other web usability work has focused on information seeking and finding. But web-based learning is a different experience. It raises questions like these:

• How can we keep learners engaged with large amounts of content?
• How can learners get oriented and effectively navigate an online learning environment consisting of dozens of learning resources, tools, and activities?
• How do we engender effective online collaboration between learners?

He included in his email the comment,

“My contention, which is actually motivating my current dissertation research, is that the growth of the web and web-based learning environments has increased (or perhaps created) the need for IDs to be able to work with UX people and developers such that there is a need for a common language and inclusive, cross-disciplinary processes.”

I think he and I are on the same page. When I look back to my graduate training in instructional design, the principles in conducting a needs assessment in a performance or learning environment don’t vary too much from the principles of a good UX field study. Perhaps simply finding the shared vocabulary would be a good starting point. However, UX still needs to translate to developers on the other end of the continuum. They also tend not to have the depth of knowledge (I know I am generalizing here) in understanding the tools of the trade in learning theory, and where behavior in the teaching and learning activities can be generalized and the issues and assumptions imposed by discipline, etc… However, I am starting to ponder the importance of the fact that not only do instructor’s not speak developer-speak (for the most part) they also very often don’t speak pedagogy-speak! So, that leaves us with a lot of people in different fields with common goals and close enough vocabularies to confuse the heck out of each other!

I know this is actually a good thing. I know that the fact that community source efforts allow us to be embedded in an environment where we actually have these different skills sets all organized around a common goal has the potential to be incredibly powerful. It feels like the answer is on the tip of our tongues!

Dreaming in Code and Community Source

Last week the UC Berkeley Kuali Student Project Community Council had a fortunate visit and presentation from Scott Rosenberg, the author of the book Dreaming in Code. I read this insightful book last Spring and immediately wanted to recommend it to twenty other people involved in community source and/or software development, thus I was thrilled that my colleague Bill Allison was able to bring Scott in to talk with us.

Dreaming in Code is not only about the Chandler Project, Mitch Kapor’s open source effort, but also provides a valuable history lesson in the software development holy grail for the perfect release — on time, on budget, and in-scope. The book is also a page turner.

One of the many tenets reflected within the book and in Rosenberg’s presentation, “Software is hard” (heard repeatedly from the mouth of Mitch Kapor in the book, but I believe Rosenberg says it originated from Donald Knuth, a Stanford Prof. and author of the tome, The Art of Computer Programming.) deserves some reflection. It is a statement that to many people is probably a no-duh statement. But to me, I think, “Thank God someone said that out loud!” However, most of the modern world doesn’t act like they believe that statement. In fact, programmers themselves often downplay the effort, using the term, “trivial” to describe what it will take to make some programming feature or bug fix. What I have seen over the years is that what “can” be done, and what “will” be done are often very different.

Scott talked not only about some of the general software history lessons and the lessons from Chandler, but also reflected on some of the lessons we are all learning from the web 2.0 world and agile development method. Some of the principles that jump out as immediately applicable to the Kuali Student and other community source efforts:

1. Thinking about keeping projects small and simple rather than large and complex. (Yes, sometimes the way we frame it to ourselves matters!)
   It is easy to get buried in the “bigness” of a community source effort. There are many layers to manage: the external development partnership, the various requirements from all the stakeholders off and on campus, the local budget constraints, the balance of features and design with architecture, etc. The complexity of community source is matched, or perhaps even overwhelmed, by enterprise thinking. This is where SOA may come in handy.
2. Producing software in small, short iterative cycles gets you somewhere.
   This is a lesson from Agile that higher ed can learn from. It matches nicely with an SOA model, but it also comes with its challenges such as how to integrate with user-centered design. The Sakai project, while not utilizing Agile, did work well in the way that it a) built on existing code, meaning something was in front of users earlier rather than later (some will say that this was its key problem — both perspectives are right!), and b) provided a platform so that many participants could deliver independently of each other. This had and continues to have its downsides. It is a challenge to usability, and difficult to create a solid feature roadmap, but it makes it easier to develop a key contributor-base and to develop buy-in from the end-user and local constituency that has been WAITING for this widget forever (tap, tap, tap). Questions from Rosenberg’s audience made it clear that some Student Systems stakeholders are anxious about this. The UCB team will need to address it in some way (not necessarily solve it).
3. Planning, design, and testing should be at least half the project timeline…
   Deciding what to build (if you want “it” to be successful) is more difficult than building it. It has to a) meet someone’s needs and help them achieve their goals with minimal interference, b) work! This principle is often lost in the haste to achieve #2.
4. Transparency and governance structure are your friends.
   Open source and higher ed public institutions have the concepts of sharing, transparency, and doing things for the greater good in common. Where successful open source tends to do better than higher ed (surprise) is in the governance of their development projects. Transparency is key here, but also knowing who is responsible for what and giving them the authority, based on meritocracy, to deliver. This means that not everyone is at the table all the time. Grit your teeth now, cause this means even you. And that should be OK, as long as you know why, who is at the table, and what you need to do in order to be at the table if that is so important to you.

Now back to Kuali student. The reason Scott’s book and talk are so interesting to me in this context is that the Kuali Student project screams, “BIG,” it screams “ENTERPRISE IMPACT,” and there are tons of local stakeholders tapping their fingers and clutching their scroll of requirements (in fact I am one of them!) which should deliver them a seat at the table.

There is no way the project can be successful without finding ways to manage, mitigate, and communicate its way through these factors.

Recognizing this, it is going to take a team of dedicated, focussed, disciplined, and open folks run this thing. AND it is going to take a lot of support, idea-sharing, and patience from those of us on the periphery.

Go Kuali Student! Go UC Berkeley Kuali and 2012 teams! I am rooting for ya.

Terra Incognita

I just finished a posting titled Open Source Software and the User Experience In Higher Education for the Penn State Blog, Terra Incognita, exploring new ground in higher education. Terra Incognita is managed by Ken Udas, my colleague at Penn State World Campus. I met Ken through his collaboration with Michael Feldstein at SUNY on the LMOS (Learning Management Operating System) project. LMOS had some great ideas embedded in it, but it didn’t “take” at SUNY and since then both Michael and Ken have moved on to bigger and better places (well, that’s what I think, anyway!). Perhaps some of the threads of LMOS will live on at both Penn State and Oracle.

Diversity and Inclusivity in Software Design

For those of you who are interested in inclusive software design and don’t know Jutta Treviranus, you should. As the director for the Adaptive Technology Resource Centre (ATRC), she leads a creative and inspiring set of projects. Yesterday, at the Sakai conference, Jutta spoke on Inclusive Design and, along with Colin Clark and Daphne Ogle, on the Fluid Project. Jutta’s message about inclusive design is incredibly inspiring. Working from a core set of values that focus on and embrace diversity rather than simply what we generally consider accessibility for large physical disabilities broadens the discussion and increases recognition of the wider impact (Electronic Curb Cut Effect) these solutions can have. In fact, this can and should lead to more innovation rather the make-do solutions (solely complying with accessibility guidelines) which most often result in a less than rich experience. A key take away is to beware of the risk of creating user experiences that are accessible to everyone but optimal for no one.

The Fluid project — just starting out — affords some great opportunities to make a big difference in improving the user experience for all users of open source software. One of the things to remember about the project is that it is emphasizing the embedded resources philosophy: in order to create real and sustainable change the resources and participation should come from the core of the open source community on which they are working. The first activity, the lightbox component, has started by taking a fairly discrete new (hence in an early iteration) Sakai tool, the Image Gallery that is being worked on by UC Berkeley ETS. It started with the rich accessible version, and Colin Clark demoed that. I played with an early version of it over the weekend and was thrilled to find out that I was actually delighted by the experience.

Daphne Ogle talked about some of the plans for the User Experience efforts. Starting this summer they will be launching UX Inspections to “identify current user “pain points” by performing heuristic evaluation and cognitive walk-throughs of uPortal, Sakai and Moodle.” Some of the other ambitious and exciting UX deliverables will be:

• Designer toolkit — shared design resources
• A living library of flexible UI components that can be used across applications
• Integration into core parts of Sakai
• UI Design patterns (to be applied across OS projects)
• Component library
• Component design artifacts to talk about the components themselves — give ourselves way to talk about them within our own context — truly inclusive/personalized
• Create a design patterns taxonomy / folksonomy

I am enjoying reflecting on the idea of folksonomy as an accessibility strategy. This concept immediately resonated with me, thinking about how many times I have struggled with the information architectures of various sites or wikis (likening them to having to understand someone else’s mind). I think this can also be applied through the creation of various “viewers” that could be combined with tagging and annotation environments which would allow for personal context organizations of someone else’s content.