I love my iPad. At first, I was wary. I was “testing” it out. I wanted to see whether she would be viable. Believe me, I have used my share of devices like palm pilots and treos, all with little keyboards I carried around in my backpack to meetings. But I always slipped in my process at some point. Tired of the tool, and pulled out my little lined notebook. I have also owned a Kindle. That didn’t last long either, as the hardware seemed old school and the device so one-track minded.

Not so with my iPad. In fact, my love and respect for it has grown (probably along with the apps). I am beginning to believe that this little thin device may be well on the road to being a game changer for computing and for educational technology. Here are a few things that really work for me:

  1. So thin and light — I even got a special small timbuk2 bag (the Freestyle) to go with it. I spent all last week in L.A. at the Sakai Conference. I did both my presentations from the iPad and I left my laptop at home in Berkeley.
  2. Small apps that provide very focused functionality keep me focused. I am learning to jump quickly between them, and the good ones are starting to build more integration points.
  3. The cloud rocks. I use Evernote everyday for all my meeting notes. I can access them on my phone, my iPad, my laptop. I am never without my information and paper is printed rarely. iAnnotate also helps with this process.
  4. It is my friend. It helps me find my way, find good restaurants when and where I need them, access email on my way to the snowshoe trail in Tahoe… It is my personal assistant, connecting me to the information I need when I need it and my colleagues and more.

Also, Some apps are developing collaboration tools using bluetooth or the network to share screens and co-edit. This has many applications in the classroom. I am thinking we should buy a fleet for our new Active Learning Classroom Test Kitchen. What do you think? Can any of you share use cases for within the classroom? Love to hear from you.

Advertisements

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?).

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.

Fluid Project Summit

October 9, 2007

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.

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!

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

July 12, 2007

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.