Brainstorming page for how to improve efficiency of team communications
If you're not 100% familiar with currently used methods, read
WikiVsEmail and ListsAndForums first. If you want new methods, see ForumVsWiki.
Wishlist
- The new turing-test has some hard to distinguish characters (v-u, m-h, e-b, d-o, etc...). Sometimes it does not accept very clear codes (maybe errors in the configuration?
- suggest previewing changes in case of problems: "This code is not required if you are previewing changes." => "... Press preview if you are unsure. If the wiki engine does not accept the code, press Back in your browser. Note that Back might not work properly in broken browsers, which might resulst in losing your text (MSIE). Copy text from the big textarea to clipboard before trying to save to be safe."
- automatically apply "preview" if the turing-test fails to give the user another chance, without pressing "Back" (and the danger of losing text). This shouldn't be too hard.
- make it possible to commit without a turing test, with a cookie. Username/password input-fields can be on the form (at least if there was no valid cookie) and set a cookie in the browser if they are of a registered user.
- RSS feed for the Wiki, instead of reloading RecentChanges all the time
- Hardcopy download of the Wiki. So I can browse on the train, at my mother-in-law, the garage, or wherever I don't have internet access. This can be done with wget -r -l2 http://www.vems.hu/wiki/index.php?page=SiteIndex. Should we do it "officially" on a remote machine daily so zip can be fetched from there ?
- See http://www.6speed.org/vems/web/wiki_capture.zip - from 13Feb05
- Distributed sourcecontrol. The ability to track local changes even without internet access is really useful. At work I have internet access, but the firewall forbids me to use ssh (thus making CVS impossible) and the web-proxy doesn't allow some commands (thus making SVN impossible). [Arch] is gaining momentum among developers, even if I prefer [darcs] myself. There are probably others that allows for distributed repositories. I think there even is a patch for SVN, but I haven't looked at it. Maybe I misunderstand this... but distributed sourcecontrol can be easiley done with keeping a copy before your changes (on unix cp -al allows to do this with almost 0 diskspace) and a diff -U 4 command between the original and the changed tree. That applies to SVN or CVS or anything.
- Drop-down menus for the buttons on the top of the page - I have a feeling that would capture the attention and appeal to the wiki-unfamilliar. This must be configurable in preferences so it can be turned off (because it's less efficient than direct links).
- MembersPage change get rid of the annoying MembersPage/ in front of everybody's username, maybe also alphabetically order the list of people? This will be wonderful, if we have a way to collect all member-pages on a page (easy) - the harder part is to have a siteindex2 that does _not_ link to these pages (or keeps them separate). It's not good if these links mix with the rest. I know that we shouldn't rely on SiteIndex, but that is even harder.
- This would require internal code changes to the wiki software most likely. I will sign up for it after OfBiz is up, running, and finally our new storefront. (Jason)
- Search related. See below
The big question: how to store info?
There are some information that must be stored in CVS (or SVN), some that must go to ofbiz, but for some information it is not clear where would be best (most efficient).
- CVS or SVN: nice versioning systems; for professionals these beat anything, but for novices requires some learning (3..8 hours depending on previous skills and client and firewall issues)
- Wiki is very easy to use, no firewall or client issues, but not ideal for versioning and structured info
- ofbiz.org is ideal for inventory, order-processing, development workeffort and shares.
In many case, the format (of human readable info) is a question. Information should be organized by content, not by layout. Major goal is that anyone can find the interesting info relatively fast.
Note that email is not sufficient to store information, it's just useful for a nudge.
clean up the rest sometime... - note: not just delete, that does not solve the discussed issues.
target audience of change
As our wiki traffic increases, people want to filter what they read and what they skip.
- splitting to several wikis is the wrong way
- having pages organized in major categories could be suitable, still a clumsy way for this (information must be organized thematically, not according to audience, or time of creation or source)
The good way is to have explicite information of the target audience - in some cases.
- when someone posts he can tell in attention of and adding some groups:
- obviously, the selection must happen on group level, usually (in attention of shopkeepers, firmware developers, firmware users etc...) rarely user level. Not needed, we'll use ofbiz to assign tasks (like "don't miss .... page in any case" and confirmation when it's done)
- RecentChanges should have an option to filter changes; show those changes separately that are in attention of groups that I am a member of. If one has limited time, he'll only read those. Not needed.
Which wiki has this feature?
- tikiwiki ?
- xwiki ?
a clumsy workaround would be offchannel notification: email groups (a few more than what we have now) that are manually notified for major changes - with the link included. Ofbiz workeffort will be the perfect way to keep such meta-info noise out of the wiki, but still available.
Search engine proposals
To find information in wiki easy, we need some conventions:
- matrix on GenBoard/Manual
- MembersPage stuff (grouping pages, but that need not necessarily show up in the title).
Search for Ionsense first (verified there is an ionsense page).
Broken google links, like ionsense site:www.vems.hu
were caused by a change in CGI location (a /wiki/ prefix was added). I'm sure he had a good reason because this broke all external links. The google links fixed themselves by now, but the other external links will become broken.
Also searched on wiki itself and got the following results:\nÿ1ÿ
So we obviously have a problem. the Ionsense page is about 20th down on the list. the exact match for the title and its child pages should be first. maybe we should try to glom on google? set it up so that the search is effective?
- Yes, make a link please!
- Also, use google to find references to the site and let's fix the links that we can.
- also, the Search function needs a "not found" case, for when the phrase you've searched for isn't found in the wiki.
See also