So often I have lengthy discussions on Twitter and keep telling myself "I need to be blogging this! 140 characters isn't enough for my rage!" but to grab the bits and pieces of what was said on Twitter and codify it here on my blog can be difficult at times. So I'm going to give Storify a try here and see how well this works.
The digital storytelling "course" ds106 has relatively quickly evolved into a community in the past year. With entities like #ds106radio appearing and developing new ways to broadcast to internet radio and the website being a mismash of latest posts and course-specific content I wondered out loud if there was a better way of organizing the information for people who are new to the community. Radio has a document that is quickly becoming overwhelming in and of itself. Is a wiki the best tool for this?
|“ ||Does #ds106 need it's own wiki now? Typewithme seems to be overloaded with info and that's just radio. Do people use wikis anymore?|
|“ ||@timmmmyboy Whaaa?!?! #ds106 DOES have it's own wiki, and heck yeah, wikis are taking over the net! http://t.co/Az0Bp1b|
|“ ||@techsavvyed Yeah, ds106 has a tab to a wiki that no one uses outside of the "course" content. What about all this? http://t.co/hr5GyQX|
|“ ||@techsavvyed Or maybe that answers my question. The wiki on ds106.us isn't used because people don't like to use wikis. Typewithme wins.|
I don't want to discount the uses of a wiki here. I understand when it comes to rapid development of documentation collaboratively they're a great tool. But it seems that more often than not wikis require you to learn an alternative programming language involving brackets and asterisks to format your content. Media Uploads can be a pain. The user experience is not inviting and often invites work training users and ultimately frustration. Sites like PBworks
have alleviated this to some extent, but they're hosted solutions with a business model to unlock certain features. Whether they would work in this case better than MediaWiki is perhaps unknown.
|“ ||@timmmmyboy This is a larger symptom of #ds106, you guys teeter so much on the edge of free-wheeling and the need to codify resources|
|“ ||@timmmmyboy It must be a challenge to have to make decisions based on those two very conflicting styles of communication|
This is a very interesting topic and it's definitely a balancing act that is different for each support person. I'm the type of person that immediately shoots for "Make it elegant and simple for users, because they're the ones I'm relying on to make great things." I can't speak for others but there is certainly a backlash from folks who don't want to "coddle the user" and rather throw them into the fire so they become better learners. Teaching someone to fish rather than feeding them. Tom Woodward clarifies this balance perfectly in a tweet:
|“ ||@timmmmyboy @techsavvyed people are willing to learn things when perceived value > pain - so that's why people need to toughen up.|
So we have a few options here. We can increase the value of a product or we can reduce pain. Using #ds106radio as an example I feel like it has enough value that people have accepted the difficulty of getting online. However that hasn't stopped someone like Grant Potter from working with more advanced methods of running a PBX server so users can use any phone line to get on the radio, rather than purchasing software and getting a long list of settings correct to get online. The problem I see is that in terms of wiki software, MediaWiki has an extremely poor user interface and it takes a lot of honest hard work to mold it into a product that removes that pain for the user. Apparently some folks disagree with me.
|“ ||@techsavvyed @timmmmyboy @brlamb @sleslie MediaWiki is User Friendly! *(mostly)|
|“ ||@giuliaforsythe @timmmmyboy There's the crux...when do we draw the line in asking people to learn "one more tool"? #ds106|
|“ ||@timmmmyboy @techsavvyed we just need one tutorial first about how to edit MediaWikis. Geez, it's easier than GIMP!?|
|“ ||@brlamb @techsavvyed @giuliaforsythe @cogdog @sleslie I've seen people do amazing things with Linux too. Still won't see me recommending it.|
Clearly UBC has done two-fold with its system. They've spent a lot of time working with MediaWiki to turn it into something that is easy to create pages and edit them. As someone who as installed MW before I can confirm their implementation is nothing like what MW is out of the box. And thats fine! But that's not for everyone. It's also very likely that UBC sees a lot of value in that wiki (or at least a subset of that group who may be very actively involved in it). But see those statistics don't defend the product.
|“ ||@timmmmyboy @techsavvyed @giuliaforsythe @brlamb give me a pressing problem & mediawiki over most wikis any day. "User Friendly" is a canard|
|“ ||@lottruminates "canard" likely not right word; of course it matters, but it gets brought out as FUD and dis-abling "helpfulness" too often|
And here I completely disagree. There is not enough emphasis put on design in products. I was often told how much better Android would be as a phone platform because it was more "open" and users had more options. The opposite is true after 1.5 years of using and Android phone (with 2.5 years prior experience on an iPhone). Design Matters. Especially so when the product you are working with is one that will require the input and involvement of a large set of users. Users who are likely not the geek that you and I are.
|“ ||@sleslie @lottruminates If a major project is implemented and no one uses it because the interface is a mess, did it really exist?|
|“ ||@lottruminates @sleslie Point simply being user-friendliness matters A LOT when you're relying on users (and not you) to drive a system.|
|“ ||@timmmmyboy I shied away from MW for projects- hand coding markup not for non geeks. Potential via extensions, includes untapped|
|“ ||@timmmmyboy as I said, a "pressing problem" - in my experience, most failures less to do w/ tool/interface more with ill-defined problems|
|“ ||@brlamb @giuliaforsythe @sleslie To be fair, we're talking about different audiences, and IMO many K-12 audiences would BALK at MediaWiki|
Is it fair for us to say "K12 can't handle this, but The University totally can." If a product is designed well enough it can be adopted by anyone. Google Docs does this well. Facebook does this well. Why can't wikis do this well?