This post is password protected. To view it please enter your password below:

Password:

One of COSL’s contributions to the Open Education and educational technology fields was that we demonstrated working code. We prototyped and disseminated a number of tools and services to promote OER projects to work together.

At MIT, the group I work in at OEIT has a focus area on Content and Curriculum that can be viewed as an extension of this COSL philosophy.

I think it’s time to sprint again.

Lessons Learned

OEIT

OEIT takes on projects dealing with educational innovation and technology. We’re supposed to work to either scale up interesting projects that have been prototyped by faculty/researchers or explore innovative technologies with the potential for broad adoption at MIT and beyond. And what I believe really makes us different is a view to connecting the dots and scaling up. We may choose to work on some fairly narrowly defined projects for individual faculty, but we do so with an eye to what we can leverage more broadly.

So, OEIT is a bit different from the target audience of WebWorkerDaily, which focuses on freelancers and consultants. But we’re also similar. We have the choice as to which projects to take on, how to integrate those projects with a greater whole, and how to accomplish the goals of the project.

Nevertheless, I think we can learn a lot from the two posts, and some of these items I’ve already tried to nudge us toward.

Warning Signs

I’m going to build upon the WebWorkerDaily summary of the two posts, and for completeness I’ll list the two summary bullet lists and then say how it might apply to OEIT.

From Red Flags: When to Say “No” to a Potential Client:

• The never-ending contract revisionist. Beware the prospect that keeps making revisions to the contract — it’s likely they will show similar goal post-moving tendencies during the project.

  [For OEIT: We don't usually ask for a contract, we typically work internally with other individuals and organizations within the university. Nevertheless, it's probably worthwhile for us to agree to an internal contract for why we're working on a project and what we intend to get out of it. And we should probably do the same thing with the client. If we can't clearly state our goals and the scope, we shouldn't enter into the agreement. (I hope to expand upon this more later.)]

• The giant project team. Large project teams can lead to extended timelines and compromised results.

  [For OEIT: This one can be a challenge in a large organization that works by consensus. Nevertheless if we want to get something done, it's critical to have a small, focused project team. Design by committee seems to rarely result in a good nor even satisfying project/product.]

• Mr. or Mrs. Vague. If the prospect can’t provide a detailed description of what it is they’re after, they’re likely not engaged enough to produce a good result.

  [For OEIT: Amen, this has been a root cause of many of our problems. We've let clients meander about and take us away from why we got involved in the first place. We've become general purpose developers, and have gotten away from our "internal contract"--working on the part of the project that meets our mission and goals. Thus having that "internal contract" and a client contract are important, and regularly checking progress against those is even more important.]

• The prospect with ants in their pants. If the client is proposing unreasonable project deadlines, you need to understand why that is.

  [For OEIT: Absolutely! This goes to our lesson learned: Speak with the Actual Client.]

• The vanishing boss. You don’t want to have the boss disappear while you’re working on the project, then suddenly appear later on to tell you that what you’re doing is wrong.

  [For OEIT: 'nuff said, this is probably always the case.]

WebWorkerDaily. (2009, October 21). “Red Flags: When to Say “No” to a Potential Client. Retrieved on October 24, 2009 from WebWorkerDaily Website: http://webworkerdaily.com/2009/10/21/red-flags-when-to-say-no-to-a-potential-client/

From 4 Signs That Your Potential Clients Aren’t Interested (and What to Do About It):

• It’s been a week since their last email.

  [For OEIT: This is something that is often misinterpreted as a blessing. But, one of the things that is within our control is good communication.]

• They keep asking for more of your previous work.

  [For OEIT: This is something we don't usually face.]

• They ask you to make “samples.”

  [For OEIT: This can either mean it's a fishing expedition, or their looking for pro-bono work. In the first case, ask questions as to why, in the second remind the client we do the majority of our work through our base funding to support educational innovation in undergraduate education at MIT.]

• The project is all talk and no action.

  [For OEIT: I sometimes feel we get stuck in this situation too often, and also cause it too often. Nothing concrete, just a gut feel. Something we need to be aware of and take steps to address and mitigate.]

WebWorkerDaily. (2009, June 23). “Red Flags: When to Say “No” to a Potential Client. Retrieved on October 24, 2009 from WebWorkerDaily Website: http://webworkerdaily.com/2009/06/23/4-signs-that-your-potential-clients-arent-interested-and-what-to-do-about-it/

Conclusions

Too early to tell. I can only work hard to try and prevent what Santayana cautioned against…

Those who cannot remember the past are condemned to repeat it.

Santayana, G. (1905-1906). Life of Reason, ‘Reason in Common Sense,’ ch. 12

(Often misquoted and used out of context. I just learned a little bit about the actual context, and I think I’ve been using it if not in context, at least closer to the original context. I’ve know the actual quote since AP U.S. History in high school–aka over twenty years now.)

The general thinking being, that the primary distinctions between education-only and the general web is a perception of quality and a “shared space”. Neither of which, I believe, really holds to be true. It’s all about perception and I have yet to hear a compelling reason for why “education” has to be different and separate. And certainly these perceptions don’t provide enough inertia to overcome neither the scale and support and nor usefulness of general web tools.

Here’s the punch line: education-only tools are likely to be challenged to generate enough users and use and are not likely to have sufficient support to grow and evolve.

The big, often unrealized consequences of this is that the potential maximum audience for the tool or service starts off as restricted. This limitation, combined with the perception from educators at all levels that they are “too busy” to adopt a new technology or technique, and a tool/service has to be a “home run” or even a “grand slam” to get the attention of enough of them. This is especially true when developing a service that requires a large number of users to be successful, as in a community of participants.

The end result? Education-only tools and services often ultimately fade into obscurity.

[I should probably expand on this, but I don't have the motivation to write more right now --Brandon]

Folksemantic Tools

Folksemantic built alpha and beta versions of the tools we thought were necessary to link folksonomies, social media/social networking, and the semantic web to be harnessed to support open education.

At the time we started, many of the tools were unique–but as we progressed, and we fully expected this to happen, a number of startup companies emerged providing the very tools and services we were working on. This is an outcome we expected. Really, we wanted to use/implement these tools and services for a greater purpose. If the tools and services existed, seemed relatively stable, had reasonable funding/support and had reasonable uptake we’d gladly use the service. But until that occurred, we wanted to demonstrate the value and one method of providing the tool or service. And if necessary, we’d continue running the tool/service over time.

Twine a Better Incarnation of Ozmozr

For example, we built Ozmozr to absorb the web. As a better social media aggregator Ozmozr was a fully functional proof of concept that had many of the underlying features and intents of the recently launched web 2.0 site Twine.

Twine Understands Your Interests

• Discover information that matters to you
• Collect and share bookmarks and other content
• Receive recommendations based on your interests

–Twine

Acawiki an Modern Incarnation of Gistr

On October 7, Acawiki, a modern incarnation of Gistr, launched.

AcaWiki is like “Wikipedia for academic research” designed to increase the impact of scholars, students, and bloggers by enabling them to share summaries and discuss academic papers online.

–AcaWiki

Justin Ball of COSL “wrote [Gistr] during a meeting. Gistr is a small utility application that helps us gather up our research in social network in one place.” The source code is still available, but the site was decommissioned earlier this year.

To be fair, we never really did anything with Gistr, but we did promote the idea and if you do a search you’ll see a few blogs picked up and reported on and described Gistr’s intent. And I haven’t checked, but it’s likely that the decision to develop Acawiki might have had some of it’s beginning in discussions between Acawiki founder Neeru Paharia and COSL’s David Wiley. And certainly it’s a small world because my current boss provided a great summary in Acawiki’s press release.

AcaWiki can provide an important ’sense-making’ function for enabling easier sharing of knowledge that can help to build bridges across disciplines—and even between academia and those outside.

–Vijay Kumar
senior associate dean anddirector of the Office of
Educational Innovation and Technology at MIT

Trip Reports

So, I’ve known about the idea of trip reports for some time now. I even thought about suggesting them as a requirement for conference attendance while at COSL. (I did realize that by making them mandatory, you sort of lose the value in doing them. I know organizations that require them, and for the friends and colleagues that have to do them they’ve become a chore. Sort of like being required to read a book for English class in school. That’s the best way to ruin the experience of the book.)

I’ve been writing trip reports for the travel to meetings and conferences I’ve done at OEIT and have been enjoying doing it. It does take awhile. For my recent around the world jaunt, I sent out the report in four segments and worked on the content off and on over five days.

What are the elements of my trip reports:

• Recap of the formal reason I attended the event. Did I give a presentation, participate in a meeting, etc. If it was a presentation, I’ll also include a link to the presentation(s) that I’m sharing on Slideshare.net.
• A brief, introspective analysis of the formal reason for attending the event.
• A recap of the discussions I had, listed by topic area, including an analysis and relation to the projects I’m working on, or areas I think we should be working on.

Here are the pluses:

• Allows you to share with your team/group/supervisor/boss what you saw and heard. There’s an accountability mechanism here, but if it’s voluntary, I think it’s more about open sharing of what you learned.
• Helps you to remember the important discussions you had and more importantly their implications (because you have to write them down and explain them to others).
• They help demonstrate the value of the meeting or event. If you didn’t get anything out of the event, why did you go? And why should you go in the future? (This is a different thing I’ve been tracking over the last couple years. Why am I going to certain conferences? What am I learning from them? And, was the trip worthwhile?)

Here are the minuses:

• They can be time-consuming to write, and can get forgotten when you get back to the office.
• They can be perceived of as just something else for your team/manager to read. (But keep in mind they should be useful, and written to communicate versus just document. If folks still have the opinion that they’re not useful, then you’ve got other problems!)

This post was inspired by reading these blog posts: How To Justify Attending A Conference and How to Strategize Your Trade Show Trip for Success.

Lessons Learned from Previous Employment (Adam Shand) — great summary of what he learned in the different jobs he’s had over the years…

Source: Torkington, N. (2009). Four short links: 14 May 2009. Retrieved May 14, 2009 from O’Reilly’s Radar Web site: http://radar.oreilly.com/2009/05/four-short-links-14-may-2009.html

Some of these struck a chord with me.