I know, I know. Job complaints are rarely the sort of thing you want to read, nor that I want to write. I really don’t! I love my job, the things I do which are varied and interesting. I’m at a bit of a crossroads though, I’ve been doing this job long enough that I worry about the documentation of how to use tools influences the way the tool is used. Quite often the most creative, interesting ways tools get used are in that first few hours of learning how to use a tool – one of the reasons I believe that blogs end up used for a short time, and people abandon them as time wears on – they’ve learned all that they need to know and with curiosity satisfied, there seems to be little value to them going forward.
So I’ve been writing lately documentation for Desire2Learn’s ePortfolio tool specifically for our instance of the platform. I’ve put together a diagram that shows the different parts of the layout with pixel dimensions, a guide to setting up the Chrome plug-in, and now a guide to using the Chrome plug-in. In my initial draft, I had examples of how one might use the plug-in, because it seems to me, you have to know why you might add a file, or take a screenshot of a webpage, before you actually do it. Maybe these examples will be held up as some sort of “best practice” or worse still “the way to do something’? I have always strived to write neutral documentation, where it just told you how to do something, with pictures illustrating the concepts. With ePortfolio though, you can do many tasks in different ways, none of the wrong or lesser than another. You can add an Artifact through the plug-in, through the Learning Environment, and there are valid reasons to add that Artifact both ways. You can tag things, you can choose to use collections if you want. You can have a big mess of things in your ePortfolio.
Who am I to tell someone that the way they’re doing it is wrong?
Apparently, I’m the one to tell people how to do it. The problem is that I instinctively want to find the most efficient way to use a tool – that’s part of my job. With ePortfolio, each path is equally complex (if you let it) or simple. There is no best path, there is no way to do it “right”, which again, will frustrate many, annoy others, and please a small few. The design of the tool pleases me ultimately, because I’m fascinated with how people deal with obstacles in learning. Unfortunately, there’s a part of me that wants the technology to not get in the way. Maybe that’s what my problem is ultimately.
When people are faced with problems they tend to either get collaborative and/or creative. Both of these conditions I love, because frankly the world can use more of both qualities at the moment. Does providing a path for those to follow stunt people’s instinctive creativeness? Is there a way with documentation to make it useful without making many decisions on what goes in, and that editing process then leaves alternative paths to grow over and be forgotten? Or is this another way to see who is really creative and thinking differently, because it allows everyone access to the tool, and then those who are energized by it, can take it places I’ve never thought about?
One Reply to “ePortfolio Implementation: Inhibiting Creativity?”
I laughed quite a bit – I know the frustration. But if you intend to use eP for program assessment, it seems likely that the unstructured approach may cause problems at some point. I’m not really sure how, but it seems that so many arbitrary decision made during implementation over the years end up having significant consequences over time.