What do you think about Cultivate.Coop so far?
From Cultivate.Coop
What do you think Cultivate.Coop is missing? What do you really like about it? What confuses you? I've been using Cultivate.Coop since it launched now and I'm curious what other people think of it.
1. What do you think Cultivate.Coop is missing? (a planning process started from identification problems)
2. What do you really like about it? (I am a cooperative planner for public and private partnerships)
3. What confuses you? (Public Policy vs. Intellectual Property Rights)
4. .....? (the alternative will be new cooperatives)
5. I've been using Cultivate.Coop since it launched now. (controlling stadium)
6. I'm curious what other people think of it. (evaluation stadium)
Missing:
- Potentially a partial WYSIWYG editor. I'm aware of the problems with WYSIWYG and wiki grammar parsing, but enabling an editor, and then stripping down the toolbar to only use elements that dependably parse properly might allow for a lower barrier to entry, but preserve quality markup in articles. Then again, this might not be feasible.
- More use of categories to organize workflow, ala "needs expansion" reference, cleanup, etc. If not tags, some more developed sense of workflow.
- An expanded wish-list, and mechanism for adding items to a wish list. Visitors should be able to easily add/vote for articles they would find useful. My participation is rather fruitless if I'm working on pet interests while people are wanting other information that I'm not helping with because I don't know it's wanted. I realize there's a thread just under here with requests, but in my experience as a site admin, it's just plain hard to get broad-based feedback. Off the top of my head: Editing the search template to include a direct link to the request thread, or a more passive approach - using something like the KeepSearches extension to create a tag cloud of frequently searched phrases.
Really like:
- That it exists! I'm glad that someone stepped up and switched on the experiment.
Hey Lippe,
These are really great suggestions. Thanks for bringing them up.
- In terms of the WYSIWYG editor, lowering the barrier for entry is definitely critical. I'm not personally aware of any exact WYSIWYG editors for wiki-text. But do you mean something like the newer editing toolbar on wikipedia's pages (see here for example). Obviously this isn't exactly WYSIWYG, but it's toolbar is stripped down, etc. The one thing that I think still scares some people off is, when clicking on the edit button, they see what looks like code. But in general, I/we are unaware of any actual WYSIWYG text editing for wiki-pages.
- Workflow- great point as well. We were going to start using the categories function to help organize content (see the portals reference here. And we already have a few templates - such as Template:Learn edit and Template:stub. However, we could add more that are just plain text, or we could try to add something like wikipedia's "refimprove" template, as seen here. Is that what you mean?
- Wish-list suggestions' - this is an especially great suggestion, and the idea of voting on needed content is particularly ace. We'll look into what possible extensions would be needed to make that happen right away (it would have to be very easy to use). And we'll try to get cracking on this suggestion - "include a direct link to the request thread, or a more passive approach - using something like the KeepSearches extension to create a tag cloud of frequently searched phrases" - ASAP. Those could be incredibly helpful features. Probably one other thing that is needed would be to make the request thread more instantly visable on the site, i.e. linked to from the home page.
Thanks for your thoughts!
- WYSIWYG + wikis are a troubled mix, but there are some implementations. WYSIWYG on mediawiki.org, Confluence wiki has an integrated editor, FOSwiki too. The difficulties of using WYSIWYG & wiki markup are outlined in the 1st link. The lack of strong WYSIWYG is one of the the main reasons my co-op is considering moving from a wiki (which was useful to get a feel for the necessary structure of our internal site) to a CMS.
- That is exactly what I mean. This can be done by using templates, or tag extensions. The frustrating part is developing a taxonomy. It would be better if it were fully-developed before being put in place, but that may not be possible.
- Installing the MediaWiki widget which allows for embedding google docs might be quick & dirty for gathering wishes. [Qpoll] looks like a live extension for voting. Integrating suggestion + voting within MW is probably harder, [Google Moderator] might be helpful too, though I've barely used it.
Hey Lippe, sorry for the delay in responding!
- WYSIWYG: These are really great examples, thanks a lot for sharing them. As per your recommendation, we've started to investigate which would be the best route to take. I don't think any transition could be immediate from some of our initial examinations, but within a few months might be a good time frame. (We're working with a limited budget and people-power). How easy is the transfer from wiki to CMS going to be for your co-op?
- Good points. What recommendations of a taxonomy do you have? Needs references, etc...? I'm going to try to do some research to see if there are already existing templates out there. If not, Cultivate.Coop will try to replicate what's out there - or just use basic text templates/tag extensions.
- Really good examples here as well, thanks for sharing! We'll do a little research over the next couple of weeks to examine the options out there and try to get something up ASAP. In the meantime, we'll keep promoting the existing discussion thread more than we have.
- Our transition to a CMS (Drupal most likely) is still in the planning phase. It will be a lot of work, but will open up huge opportunities to create accessible, structured, semantic content. As great as the wiki has been for creating order out of chaos, the effort necessary to support best practices & conventions in such a free-form environment will be a growing burden, especially as concerns task and file management. Which is where stuff like Casetracker & Project module come in.
- Drupal.org uses No known problems, Incomplete, Needs copy/style review, Needs dividing, Needs technical review, Needs updating, or Deprecated. I like the idea of using a small but comprehensive set that can be further refined as needed. Wikipedia has a million, but Cleanup, Disputes, General, Sources of articles, and Maintenance might be good starting points. Drupal.org also uses "audience taxonomy", which is an interesting idea, so someone can look at a list of articles intended for their organizational role, or organization status, e.g. startup.
It just struck me that another aspect of tagging/categorization that is lacking is specifying content beyond "article." One way to approach this might be at some point have a brainstorming session on *all* the types of things that one would like to add, or hope others will add, and then to try and assemble a taxonomy based on that list.
For example, I would like to have a place to post actual parts lists and assembly diagrams for a secure netbook kiosk, a checkout counter, and a space-saving hanging monitor display (unless deemed out of the scope of the project). They could be classified as articles, but they would be orphaned pages unless cross-linked, which is unlikely - they'd probably be better listed in an index of DIY plans.
And as I keep banging on.. intentionally subjective case studies in relation to various topics. I don't think it's appropriate to stick a rant on Samsung registers into a page talking about point of sales equipment, but I certainly have thoughts to share that might be helpful to others looking at acquiring registers.
Lippe - this is a great idea. If we started a "brainstorm" on tagging/categorization at the outset of next week, Cultivate can put a lot of energy behind pushing this brainstorm out through our social media sites and e-mail and trying to get more people involved.
Also - the thought of putting together the diagrams/etc. for the kiosk and so forth is stellar.
I've been thinking about the intentionally subjective cases studies in relation to various topics. Do you think that'd be appropriate for a wiki space (i.e. it's something that others would be able to edit when you're discussing your personal experience). I'm not against it, per se - we've been considering it for some other possibilities - but I'm just wondering about it in practice.
Here's the thread that was started for this brainstorm: http://cultivate.coop/wiki/Cultivate.Coop_talk:Community_portal#Brainstorming_Session:_New_.22Categories.22_on_Cultivate.Coop_-_What_would_you_like_to_see.3F_111
Feel free to change or add to the content/description!
I've started a thread here to keep track of the templates/tag extensions for improving the management and workflow of the site: [1].
These are works in progress, please feel free to edit them, add your own, or suggest others!
