C’mon in and look around. We’re still making some minor tweaks and enhancements but I’m so excited about how it looks that I just couldn’t wait to announce it. Thanks to the folks at pMachine Services for helping me to make this happen. (more…)
Author: Michael Feldstein
-
JotSpot Initial Impressions: This is Your Source Code on Wiki
After spending a few hours playing around with the JotSpot beta, I can say that I like what I see very much so far. As a non-programmer who wants to learn a little HTML and doesn’t read manuals very often, I love the “View Source” feature in my browser. I can find a page I like and see how they put it together, learning by example. JotSpot takes this idea and runs with it.
To begin with, you can not only view the source for a JotSpot page; you can edit it too. OK, that wouldn’t be different from any other wiki if all the software allowed you to do was create free-form HTML pages. But it does a lot more than that. In fact, it does (at least) three new things beyond normal wikis that are pretty huge changes.
First, it lets you structure data. You can create form fields on a wiki page and make those fields searchable. You can even make form fields on an existing page so that you can cut free-form text and paste it into the form. This makes your data much more usable.
Second, it lets you access outside data sources. RSS is the easiest, but from what I can tell even with my severely limited markup skills, it looks fairly straightforward to pull in other types of sources too. For example, they give you a page where they use the Google API to pull in search results. Because it’s all in wiki, it’s easy for me to learn by viewing their source code, making a minor change (e.g., the search term), and testing it right there. The code in the example pages is superbly well commented to make learning by doing easy.
The third impressive thing that JotSpot does is that the accessing of external data sources can be bi-directional. Let’s say I have some data in three different systems that I want to look at. I can pull them all into the same JotSpot wiki page. But now I want to make a change in, say, the data in my CRM app. As long as the app itself allows it, I can change the data in the JotSpot field and have it automatically update in the CRM application. Very slick.
But the slickest thing of all is how easy it is. As an HTML poser, I regularly get stuck on tables and divs. If actually had to write significant SQL or PHP (or whatever) code to access data…well…forget it. But JotSpot appears to reduce all of this stuff to a simple declarative markup. You can apply CSS, etc., to it, but you don’t have to. I can build a simple but functional application in a few simple lines of code. (And by the way, unlike many wikis I’ve seen, the default result isn’t butt ugly.)
I’m just scratching the surface of this thing, really, and in some ways I’m not the best person to be testing it. But so far I’m really impressed.
By the way, Jon Udell has an interesting twenty-odd-minute Flash demo of the product. The demo itself is rough (no VCR controls, kinda blurry, etc.) but the content is highly informative. Some of the stuff I mention in this post I figured out from watching the demo and then going back to JotSpot to play.
-
Jon Stewart Demolishes Tweedle-Dumb and Tweedle-Dumber on Crossfire
This is somewhat outside the purview of what I normally post about but it’s just too important to ignore. Jon Stewart went on Crossfire this week and did a wonderful, passionate, incisive job of ripping the show to shreds.
Here’s a sample from the transcript:
STEWART: Here’s just what I wanted to tell you guys.
CARLSON: Yes.
STEWART: Stop.
(LAUGHTER)
STEWART: Stop, stop, stop, stop hurting America.
BEGALA: OK. Now
(CROSSTALK)
STEWART: And come work for us, because we, as the people…
CARLSON: How do you pay?
STEWART: The people — not well.
(LAUGHTER)
BEGALA: Better than CNN, I’m sure.
STEWART: But you can sleep at night.
(LAUGHTER)
STEWART: See, the thing is, we need your help. Right now, you’re helping the politicians and the corporations. And we’re left out there to mow our lawns.
BEGALA: By beating up on them? You just said we’re too rough on them when they make mistakes.
STEWART: No, no, no, you’re not too rough on them. You’re part of their strategies. You are partisan, what do you call it, hacks.
There’s also a Windows Media stream here (which I found via Lawrence Lessig’s blog).
Stewart is right. We despately need good journalistic coverage of our politics and we’re not getting it. This is one of the reasons why blogs are taking off as a political information source; the mainstream media outlets have created a huge opening for them by doing such a bad job. People are desparate for a news source that is not utterly controlled and manipulated by the political parties, even if that news source is flawed, inaccurate, etc.
-
Site Update
The site re-design is coming along and should hopefully be up in the first half of this coming week. Posting has been slow this week, partly because I’ve been distracted with other matters (like the site re-design) and partly because I just haven’t seen a whole lot of stimulating material this week. (Hey, it happens.) I’ll be spending some time with a demo account for Jotspot and will hopefully have some things to say about it tomorrow or Monday.
-
Blog Your Undergraduate Major
The suggestion on blogsperiment that students should be encouraged to create blogs that transcend individual courses fits well with the idea in my last post about approaching the web-enhancing of a university on the departmental level rather than on a course-by-course basis. However, unlike the other idea, this one can be done without a large commitment from the department (although that certainly would help). Give the students blogs, encourage individual instructors to give blogging assignments, assign a category or shibboleth tag for each course, and add a per-course aggregator. Here’s what you get from it:
- Students can use their own blogs for per-course blogging assignments.
- The per-course blog posts can be sucked into the course enviroment without a lot of manual fiddling or filtering.
- Each student’s blog becomes essentially a portfolio of course contributions over the lifetime of his/her undergraduate career.
- Because the the posts are permanently archived, students can more easily reflect back on previous courses and their relationships to new ones. They can even rejigger their categories as they gain broader and deeper perspectives on what they are learning.
These are just a few of the benefits; the original blogsperiment post offers more and is well worth reading.
-
Web-Enhancing the University in Departmental Blocks
The new online journal Innovate has a thought-provoking piece (registration required) on what what can be accomplished when universities roll out web-enhanced programs on a departmental rather than course-by-course basis. What I take away from it is that departments that have committed to cultivating a cohesive approach to instructional philosophy and policies will find that adopting a web-enhanced approach facilitates the change. I’m not sure that this works so well without that prior commitment which, unfortunately, is pretty unusual.
-
Why RoboDemo 5 Sucks
This post isn’t a litany of the things that I don’t like about RoboDemo, although there will necessarily will be some of that. Rather, it’s my own speculation as to why a smart company with a reputation for good software produced a lemon of a release. Make no mistake about it, though; Robodemo 5 sucks. It mostly sucks in fixable ways and it’s possible that some of the problems have already been fixed in Captivate, it’s newly released successor. (I won’t know for certain until I find time to kick the tires.) But the question remains; why did Macromedia release a product that is badly broken?
Before continuing, let me put in a caveat. I am far from a RoboDemo expert. My observations are from working with it on one project with teammates who, like me, had lots of simulation design and production experience using other products but had no RoboDemo-specific experience. I wouldn’t be surprised if there were some things that we missed. Nevertheless, most of the problems that I intend to write about here should have been much harder to hit and easier to solve than they were. Even if we missed some functionality in the product, that does not absolve Macromedia from not making that functionality the default behavior or, at least, more obvious.
The first and least interesting possible reason why Macromedia released an inferior product is that they rushed a release out with known bugs in response to external pressures. Given that this is the first release of the product since they bought the product line, I wouldn’t be surprised if they felt they needed to push a first release out the door quickly. And there is evidence of this. For example, when you put an interactive element on a screen (e.g., a click box) and set the option to “wait for user response” (or something like that; I don’t have a copy of the software with me at the moment), RoboDemo ignores this setting and moves onto the next frame regardless of whether the user has clicked. In order to make the proper behavior happen, you have to change the setting for the frame from the default “continue” and hard-wire it to go to the next numbered frame. That adds two clicks of authoring for every single interaction screen, not to mention the fact that you have to do extra editing clicks if you happen to add, delete, or change the order of the screens. Plus, it creates many more points (one per interaction screen, to be exact) where you need to QA for possible authoring errors. In a project of any substantial size, this ends up being a significant time drag. (Also, RoboDemo apparently doesn’t handle right-clicks for interactivity options. How could that be?)
At first, we thought that we had to be missing some setting; how could Macromedia release a product with such an obvious glitch? Incredibly, their customer support operator told us that, yes, the only way to get Robodemo to actually wait for the user’s interaction is to hard-wire each frame as we were doing. They refused to acknowledge that this was a bug despite the fact that they also said the behavior would change in the next release. I saw a handful glaring and careless bugs like this one, and we weren’t even pushing the product that hard.
The second possible cause of RoboDemo’s suckiness is that e-learning functionality appears to be tacked on as an afterthought. It is, after all, called RoboDemo. While there are features that allow you to build in interactivity, add scoring, etc., these all have to be added manually. It should be possible to set the product in either demo or e-learning simulation mode. When set for the latter, the product should add click boxes and the like by default. There is some indication in the marketing copy for Captivate (a.k.a. RoboDemo 6) that the new version has something like this. If it exists in version 5.0, though, we certainly couldn’t find it.
The third possible cause is in some ways the most interesting. It’s possible that some of the problems with RoboDemo are because it is built on top of Flash and relies heavily on the Flash authoring paradigm. Remember, as an animation product, Flash was fundamentally designed to make it easy to move objects around on a screen following a timeline. Some of the features that make it suitable for e-learning development were added as afterthoughts and were not necessarily added in a way that makes sense from an e-learning-centric perspective.
Take sound, for example. In Flash, sound is built on a timeline. According to one of the Flash developers on my team, there’s no real easy way to tell animations in a flash movie to pause and wait for sound file to finish playing. You basically have to fiddle with the timeline until they line up.
Maybe this is why there is no way in RoboDemo to automatically synch up audio narration so that the learner isn’t moved along to the next screen before the narration is finished. You basically have to go to the settings for one of the visual elements on the page (like a call-out bubble) and set it to display for the same number of seconds as the length of your sound file.
For each and every page.
In order to fix this behavior, two things would have had to happen. First, the RoboDemo developers would have had to break their habitual mindset as Flash developers and see that the Flash audio model is not the right one for simulation development. My impression of RoboDemo is that it was designed by Flash developers to create a bunch of short-cuts for some of the things they would do when developing a simulation by hand in the Flash authoring environment. This isn’t a bad start, but they need to stop thinking like Flash developers and start thinking like e-Learning designers to gain more significant authoring time savings for their customers. Second, once they realize that the Flash model isn’t right, they would have to develop a work-around, essentially fighting against the way that Flash naturally wants to do things. This just isn’t easy even for the best development teams.
So those are the three reasons why I think RoboDemo 5 ended up being a deeply flawed release. Again, I’m not a RoboDemo expert; these are my impressions after a little more than a week of getting up-close and personal with it. Still, I’m pretty confident that the margin of error on my suckiness assessment is relatively modest.
We’ll see if Macromedia does any better with the new version.