Dr. Chuck's Web Log

First Annual Etudes User Summit - April 23, 24 2009 - Los Angeles

Etudes (www.etudes.org) held its first annual User Summit this week in Los Angeles. The summit sold out and attendance had to be capped at 90 people. The attendees were a mix of teachers, academic administrators responsible for teaching, and the Etudes team. It was a high energy meeting from start to end. Sessions ranged from pedagogy and approaches to teaching online to requirements gathering sessions to strategy discussions about future directions for Etudes. The sessions I attended were characterized by nearly continuous interactivity between and among the presenters and the audience. During lunches and breaks there was so much interaction that the room was almost roaring. Teachers were doing what they do best - teaching each other - all day long for both days.

Here are a few of my pictures from the Etudes 2008 User Summit.

Disclosure: I am proud to be on the board of directors of the Etudes 501(c)(3) public charity corporation.

I had the opportunity to give a keynote speech on Thursday morning titled "Celebrating the Magic of Teachers" (slides).

This was a fun romp (for me at least) of how I have been working in Educational Technology for the past 15 years and working toward a goal of putting technology in the hands of teachers and learners. The talk has a thread of standards and interoperability and IMS running throughout.

The tag line(s) were as follows:

"After over a decade of effort, 2 million airplane miles, and four job changes, my goal is still to find ways to put educational teachnology directly in the hands of teachers - so they can use it to teach.

My technical objective is to make it so that teachers can easily trade software and content between each other (like virtual baseball cards). Regardless of what learning management system (or systems) their institution has adopted."

I had no idea if the talk would even be mildly interesting to the attendees - I figured I might put them to sleep with my self-absorbed tale about my favourite topic (me). But they were very interested throughout and I got many nice comments from the attendees indicating that it was not boring at all. Whew!

After the summit ended at 3PM on Friday, Glenn and I took a four-hour tour of Los Angeles Sights including the Playboy mansion, Bel Air, Beverly Hills, Rodeo Drive, The La Brea Tar Pits, the Hollywood sign, and Grumman Chinese Theater - and we made it back in time for a nice dinner with Vivie at the Encounter restaurant at LAX before we all went to our flights back home.

All in all, it was a wonderful two days and an apt celebration of how far Etudes has come since it became a non-profit last year. Vivie and her team are to be congratulated on a year of hard-work and success.

Organizing files on a Memory Stick/SD for a Photo Frame

I have a cheap photo frame with very little built in memory but it had a SD slot in it so I waited until 8GB SD cards went on sale and bought one.

I exported all my photos from iPhoto in one big drag and drop into a folder. This ended up with about 7000 JPG files in a single directory. When I put this SD card in my photo display simply hung for a long time on the Loading... screen and then gave up and only showed files from the internal memory - not the SD card.

So I wrote a little Python script to spread the files across 10 folders with 10 sub-folders in each folder. Just pushed things around randomly basically hoping the microcode in the photo frame could handle 80 photos per directory. I dropped the Python script in the main folder of the SD card and fired away. I even got rid of some of those Mac metadata files which started with a dot to give my poor photo frame a fighting chance.

import os

for i in range(10):
  try: os.mkdir("dir"+str(i))
  except: pass
  for j in range(10):
    try: os.mkdir("dir"+str(i)+"/dir"+str(j))
    except: pass

i = 0 
j = 0 
for root, dirs, files in os.walk('.'):
   for file in files:
      if file.startswith(".") : 
         try: os.unlink(file)
         except: pass
         continue
      if not ( file.endswith('.jpg') or file.endswith('.JPG') )  : continue
      place = "dir"+str(i)+"/dir"+str(j)+"/"+file
      j = j + 1
      if j > 9 : 
        i = i + 1
        j = 0
      if i > 9 : i = 0
      print file, place
      os.rename(file,place)

And it worked - a cheap closeout photo frame ($20.00 from Aldi's) with a $14 8GB SD card and I have 9 years of photos showing randomly! Yay!

Google is Amazingly Quick

I put up my previous blog post about the iPhone keyboard patent this morning - then I went to a meeting and then drove home. Just now (5 hours later) I decided to type the title of my blog post:

"Apple Touch Screen Keyboard Overlay"

Into Google to see how long it took for Google to find my blog post. OOPS - I waited too long. Google already found it and indexed it.

In less than five hours - I am the #2 search result for that set of keywords. Next time I try to see how long it takes for Google to find something, I will not wait so long. :)

Amazingly cool. Maybe they have software that knows what I am going to blog about before I blog about it!

Patent/Invention: Apple Touch Screen Keyboard Overlay

One of the biggest remaining problems with the Apple iPhone (and presumably any Apple touch screen device) is the fact that one cannot touch type on the system. You must watch the keyboard as you type.

My idea is to make a plastic overlay (similar to a plastic screen protector) – which has a subtle raised pattern which outlines the key board or perhaps makes little nubs where certain keys are. The pattern on the plastic can be quite subtle because we will learn where the keys are relative to the bits of tactile feedback. By making this cling to the glass –it can be removed – it also serves as a screen protector.

Specialized cling plastic overlays can be made for special purposes (i.e. not just the QUERTY) keyboard and they can be interchanged.

This allows Apple (and others) to manufacture touch-screen devices with perfectly smooth glass and allows us to customize the “feel” of these devices to our own tastes.

Note: I originally came up with this idea September 2008. You see the dated picture. I revealed the idea to the University of Michigan Tech transfer folks September 22, 2008 - and they were not interested. I asked Apple if there were interested in any ideas without revealing the idea and their policy is not to accept anything like this from customers. I left the text(above) on my desktop for a while wondering if I could patent it myself - but just got bored and decided to clean up my desktop and post it here. Really I just want such a product to exist so I stop hating my iPhone's keyboard.

Basement 414 - Unstructured Art/Music Space in Lansing, MI

I am sitting at the Basement 414 space in Lansing, MI. B414 has been going on for about a year and a half. For those of you who know me - I like places that have soul - bars, restaurants, etc that feel like they are organically grown - a place where when you walk in you get a sense, a feeling, and that feeling is defined by the current and past occupants of the space.

http://b414.org/

http://twitter.com/B414/

First off, some factual bits. B414 is alcohol-free, there is no admittance fee (donations accepted), there is no food, you can buy coffee and Faygo pop and sometimes they have popcorn, the bands are very local and they have free WiFi. There are four rooms which make up 4000 square feet of floor space. One room is the quieter room and tends to focus on art, the second room is the concert room - it can hold about 40-50 people and it is a very fun and intimate space including a dance floor, the third room is still storage, and the fourth room is the band staging area. Bands can unload their stuff and stage it in a room connected to the concert room. This allows 4-5 bands per night with a just a little down time - which leads to a lot of fun.

B414 is operated by a passionate group of local arts and IT folks who are committed to creating a friendly, comfortable accepting, tolerant space with as few rules as possible. There are few rules and everyone seems to get along and every one just cooperates with each other. The focus is being together and having a good time.

Fridays and Saturdays are the high energy days with more intense rock. Weeknights are slower - weekend day time s might be more artsy of just a place to hang out and have some coffee.

While this is a misleading description, B414 is kind of like a real-world myspace - an our-space as it were. There is fun, over the top artsy background - some music from time to time - a bunch of friends that support and point to one another - in a sense a real-world social network.

The age group is pretty much all over the map - there is not one pattern - you see kids with their parents (one band had an 8 year old drummer) high school students, college students, and old people like me as well. In a sense the very diverse nature of the crowd is a very stabilizing and calming influence. This space is not about one thing - it is about the occupants at the current moment.

They don't promote it too much - folks usually find out about it via word-of-mouth - in a sense like MySpace itself.

If at this point, you have absolutely *no* idea what I am talking about - don't worry - it is pretty much impossible to describe until you get to Basement 414 and experience it for yourself. In a sense, B414 is different for everyone.

For me, it is a place to take Brent's High School friends so they can do something other than play video games all summer - they meet people, make friends, experience talent, relax, find a place where they belong, and all the while I am sitting here with my Macintosh getting some work done - at least I will get to work after I get this blog post finished.

The B414 team are really cool and relaxed - they just blend into the background - they do a good job of keeping their http://b414.org/ page up-to-date with upcoming events. To find it, go south on Cedar Street and turn into the alley on the right just south of the NutHouse and go to the end of the alley - B414 is the last door in the last building on the right side of the alley - if the door is open - it is open.

Designing Collaborative CyberInfrastructure Scientific Analysis Software

I am writing some draft text for a grant having to do with Cyber Infrasturcture. This text will be massively edited before it goes into the final proposal - I am just putting it up here as draft and thoughts - comments welcome.

Design User-Centered Computational Tools

The goal of the technical team associated with this project will be to build simple tools that allow our users to collaboratively explore our data, annotate that data, form models and hypothesis, and exchange information with others working on the data. Our approach to this is to create a very agile technical team that can gather user requirements and develop software and get it into production and in the hands of the end-users in a matter of weeks, to keep the user's deeply engaged in the design processes. The team will always take user input and evolve the software to meet the emerging user needs as the software is being used. In order to achieve this level of flexibility, the project will not use any particular "framework" or existing software package. While starting with a well-developed software as the core can bring a lot of capabilities to bear on the problem quickly - standardizing on foundational software early in the process also brings a "pre-baked" perspective or point of view which limits flexibility.

The initial software will be kept simple and focus on the most important use cases as seen by the users. By working together and co-evolving the software both the users and technical team develop a deep understanding appreciation of the real user requirements. Because the process focuses on the act of co-creation (rather than trying to bend existing software into usable shape) - users and developers are energized to look very deeply into the problem space and unearth fine detail about the use cases.

The project will make use of readily available compute and data resources including commercially available offerings for hosting as appropriate. We do not want to invest any project time or energy in building technical infrastructure. We will make sure that the technical approach requires very little training effort by doing our work in widely used languages such as PHP and Java and using MySql as the database. This way we can easily bring a variety of new developers onto the project with little or no training time.

Advancing an agile and user-centered approach to designing Cyber Infrastructure

The approach to design and development is a classic user-centered approach with technical staff participating in all of the brainstorming and idea generation phases of the projects. The design sessions need a diverse set of participants ranging from domain experts, to design experts, to management stakeholders, and technical developers. One of the ground rules is that technical developers are generally not allowed to "veto" design ideas based on how difficult the ideas appear on first glance. The goal is to capture the user's needs in terms of the kind of functionality needed in the collaborative data analysis tools.

Often in a project like this, the technical team worries about performance, scalability, or maintainability far too early in the design processes. Because our project will scale slowly over time, we will be able to address issues such as performance and scalability in later versions of the software. And often once domain expert users have a chance to work with a feature they will come up with a new and often simpler (and more technically feasible) design. The key is to avoid saying "no" to an idea in the design phase - but instead to try to make it work as the users conceive of it and explore and adjust the design as experience is gained.

The technical team needs to be very careful not to "fall in love" with any single technical approach. It is entirely possible that we will end up starting over or switching directions several times through the life of the project. As such, each of the software components should be developed and deployed quickly with a minimum of effort and energy so that the technical staff will be willing participants in any new directions.

We expect to produce two general categories of software in this project: (1) domain specific tools to search and work with learning science data and (2) a set of collaborative research widgets (rating, annotation, messaging, etc.) that are not particularly about learning data. We will use a simple JavaScript based approach (see www.cloudsocial.org and www.shiftspace.org for ideas) to make all the capabilities available to our users. By "mashing up" functionality, we allow each bit of functionality to be written by a different technical team, in a different programming language, and hosted independently. The approach will initially focus on building of the domain specific-tools and as we see general patterns emerge, we will re-factor functionality into general-purpose tools. The following mockup and whiteboard photo are taken from a project in the University of Michigan Medical School that is using the same development methodology to develop software to support introducing first-year medical students to clinical experiences:

You can see the "background" is a collaborative document developed specifically for one of seven course activities, dealing with all of the workflow and stakeholders in this particular activity. At the bottom of the screen is a Facebook-like toolbar that contains the common/reusable elements that is layered on top of the background document using embedded JavaScript. You will note that during the design session we don't even represent the reusable widgets in the design because we assume that they will always "be there if needed" – the focus is on the design of the background tool.

The key to the approach is that the reusable widgets can come from different servers and even be written in different programming languages than the background document. This ability to "mash-up" functionality [REF:CSEV] from multiple sources avoids technical lock-in and allows the developer of the core data analysis tools the flexibility of building simple applications in a comfortable development environment rather than working in a highly constrained framework just to make a set of collaborative widgets available to the users.

Awareness of potential pitfalls and plan to mitigate

Probably the single greatest failing in CI projects that develop software is constraining technical choices far too early in the project. Once these technical constraints are in place, all further design is done within the context of those technical choices. Far too often, the design teams will be told, "that is a really good idea but it is pretty much impossible to do in our current framework without a 6-month rewrite". Another problem is creating a classic "waterfall" schedule with front-loaded software-development project plans which feature a short user-requirements phase, followed by a software development phase with little user involvement, followed by a release milestone where users begin to use the software. The waterfall approach often results in software that does not meet the needs of the users but since so much time and resources in the project have been used up - there is no chance to "start over" and the domain-experts on the team is forced to make the best of a bad situation.

Domain experts can also fall into a trap when expressing requirements. There is a temptation to express a desire for capabilities where the software has almost "mythical" capabilities that border on Artificial Intelligence. It is quite natural to hope for software that does "automatic unattended research" and presents the researcher with a set of possible insights for the researcher to cut and paste to produce a journal article. The problem is that most technical teams are willing to "give these kinds of ideas a try" because they too would like to produce the "magic bullet". Once these impossible requirements are agreed to, the universal outcome is a lot of lost project time and software that does not satisfy the requirements.

The solution to all these (and other) problems is to avoid constraining ideas with technical decisions too early in the process and to insist that new versions of production-ready software are placed in the hands of the users every 2-4 months. By engaging in a continuous design process and a continuous development process - requirements are naturally more feasible. Also having short delivery cycles avoids the temptation to attack "impossible" problems and focuses attention on what is useful and achievable.

This also keeps the focus of the effort on producing the science and developing the community of users from the first months of the project.

Classic pitfalls

As described in the previous section, the classic pitfalls in CI projects that go awry are as follows

- Selection of a software framework far too early in the process and then resisting any user requirement that does not fit nicely into the selected framework. This also leads to spending all the developer time in the project learning the framework instead of meeting user requirements.

- Unwillingness of the technical team to drop an idea and go a new way because too much technical effort and energy has been invested in an old idea. Most successful CI efforts go through several major rewrites of their software.

- A behavior pattern where the technical team becomes "locked in" to a particular approach and is continuously vetoing any requirements that do not fit into their approach.

- A waterfall-style schedule with a short requirements phase followed by a long software development period, typically delivering the first version of software at the 1/2 or 2/3 point in the project time line with no opportunity to "start over" if the software is unsuitable.

- Attempting to work towards a "magic bullet" solution that solves difficult (usually intractable in the context of the project resources and timeline) problems such as "Artificial Intelligence" or "Software that automatically does research". We mistakenly think that "seeming intelligent" software like Google are easy to build and while we all might dream about a "Google for research insights" - any attempt to develop such software is likely to fail with the only outcome to be using up valuable time and resources and ultimately doom the overall project to failure.

The way to avoid these pitfalls is to focus both the technical members of the team and the domain experts on what is achievable and to produce a development methodology that is simple and easy to achieve. In a sense, any project is faced with the "iron triangle": "Good, Fast, or Inexpensive - Pick any two" (http://en.wikipedia.org/wiki/Project_triangle). In this project we are picking "Fast and Inexpensive". We want our project to "look good" and meet user requirements but we fully understand and give our developers the flexibility to "harden" the resulting code later.

By giving our technical team these guiding principles, we focus on the user needs over the technical needs and avoid premature lock in which comes from trying to produce the most elegant or most scalable solution. For the right software developers, this kind of freedom makes programming much more enjoyable and keeps the developers focused on looking for clever ways to meet the user's requirements instead of defending their "turf". It allows programmers to explore new technical approaches in a low risk environment.

Once we have a solid understanding of real user requirements and user interfaces which work well for users, it is often a relatively simple and straightforward (and time bounded) task to do a full ground-up rewrite of the software with an eye to performance and scalability, and generalizability.

In our experience, this type of approach leads to a fun, high-energy team where everyone is enjoying making their contributions. By avoiding the known sources of conflict and friction, everyone brings their best talent to bear on

Technical Generalizability

We see two generalizable outcomes of this project: (1) a generalizable model for collaborative design and development activity between technical teams, designers, and domain experts to build focused domain specific cyberinfrastructure, and (2) a technical approach to "mashing up" functionality from multiple sources to produce an overall user interface for domain experts.

A third possible outcome is a set of reusable widgets which can be easily integrated into any CyberInfrastructure project. While we do not have the resources in this proposal to truly harden and deploy our easily reusable collaborative widgets, we hope to have made some progress in this area and laid the groundwork for making such a set of widgets available.

The mash-up nature of our approach lends itself to easy and low-cost collaboration with other CyberInfrastructure projects if such opportunities arise during this project.

References

[REF:CSEV] Charles Severance, Joseph Hardin, Anthony Whyte, The Coming Functionality Mashup in Personal Learning Environments, Interactive Learning Environments (Journal), Volume 16, Number 1, April 2008.

http://www.informaworld.com/smpp/content~db=all~content=a788482223~tab=linking

Some Abstracts

Abstract: Building Sakai tools in the Cloud Using Google App Engine (WorkShop)

This workshop will introduce attendees to the Google App Engine and show how to write simple learning tools in Python and host them in Google App Engine. Then students will integrate their tools into Sakai using IMS Learning Tools Interoperability. The workshop will introduce Google App Engine and introduce IMS Learning Tools Interoperability and have a hands-on activity. Students should pre-install the Google App Engine environment on their laptop following instructions at www.appenginelearn.com.

Note To Reviewers: Please do not schedule this at the same time as a Sakai3 developer workshop because I want to go to the Sakai3 workshop myself.

Abstract: Outcome-Based Learning Tools at the U. Michigan Medical School
The University of Michigan is developing outcome-based approaches to Medical Education ranging from clinical experiences in first-year students to lifelong learning portfolios. The underlying principle of the program is outcome-based self-directed learning where the student manages their own plan-learn-assess-adjust cycles with help and guidance from faculty and mentors. The students are tracked against competencies and learning objectives throughout their education. We are developing new learning tools to support this educational model and approach. Instead of looking for a general one-size-fits-all solution, the team has chosen to take a very agile approach to building tools that meet the needs of the faculty, student, and institution. The focus is on quickly making useful and usable tools and getting the tools in the hands of the students and getting feedback. Tools are conceived, designed, developed, deployed, and used in learning activities in a 10-15 week cycle idea to production. Sakai is used to manage the course and launch these new tools using IMS Learning Tools Interoperability. The model is to create a fluid ecosystem of dynamic and innovative tools integrated into and coordinated by Sakai.

The App Engine Birds of a Feather at Pycon 2009

This is my first O'Reilly blog post. Feel free to point out embarrassing typos. Here is the real post:

http://broadcast.oreilly.com/2009/04/the-app-engine-birds-of-a-feat.html

Here is an excerpt:

This was my second Pycon - since the last two have been in Chicago and on a weekend it has been an easy drive for me to attend coming from Michigan. Since last year was my first time at Pycon - I was just finding my way around. This year I was invited to all the "Python educators" parties and running around promoting my upcoming "Using Google App Engine" book - handing out postcards with discount codes and hanging out at the O'Reilly booth.

I was really excited when Guido posted a BOF about Google App Engine. Even though I wrote an introductory book, there were a few nagging questions that the documentation seemed not to answer.

....

Annoying iPhone Keyboard

I must really like everything else about the iPhone given how frustrating I find the keyboard. For example, last night I sent the following message to George Kroner (a PSU alum):

Go Penn State - NIT Champs

I was walking as I typed it in - and Apple made the following spelling correction:

Go Penn State - NOT Champs

Check it out - I and O are near each other on the keyboard. And given the nature of the NIT - the message as ruined by Apple's spelling correction / keyboard could be the message I meant to sent - particularly if I was a mean person.

And George might have assumed I *meant* the mean variant of the message - given the Big-Ten school where I work and the Big-Ten school where I got my degrees from. He might have never mentioned it to me so I could apologize for the message I never meant to send. He might have though I was a mean person forever!

I was great to be at State College last night watching PSU win the NIT - go Big-Ten!

I turned off spelling correction this morning. At least Apple gives me that option so the mistakes are all mine and/or the keyboard.