Message boards : Documentation : Inventory
Message board moderation
Previous · 1 · 2
Author | Message |
---|---|
Send message Joined: 30 Oct 05 Posts: 1239 |
But what we can't do is refer to "THE" wiki, because there are two. And to add to this, a couple of projects have their own Wiki. Pirates, of course. And I noticed this evening that Leiden has its own Wiki. Kathryn :o) |
Send message Joined: 12 Feb 06 Posts: 232 |
Actually, Leiden seems to have their own _page_ in the Dutch version of the Wikipedia. And a link to the UBW. Unless I missed something. The Pirates wiki is a demonstration of a MediaWiki authentication plug-in which lets you graft a wiki onto any BOINC project, and then let anybody on the BOINC project edit the wiki (perhaps limited to only those with RAC). So any project which wants a wiki can easily add one. (Documentation for the add-on at http://www.mediawiki.org/wiki/Extension:BOINC_Authentication) -- Eric Myers "Education is not the filling of a pail, but the lighting of a fire." -- William Butler Yeats |
Send message Joined: 30 Oct 05 Posts: 1239 |
Ah. I saw the link that said "The (Dutch) Wiki of Leiden Classical" and assumed that it was a full Wiki. But my point still holds. There's nothing stopping a project from having their own Wiki. Kathryn :o) |
Send message Joined: 8 Sep 05 Posts: 74 |
Dimitris probably didn't put the document into a validation checker. You could email the link to him - his address is at the bottom of the page. There are a few minor details I may contact him about, but he's researched a lot of projects very thoroughly and it's a very worthwhile document.Well, validation is only one part of a very large whole, and at present I've got enough web-projects for now - don't get me wrong, I'd like to help, but as much as I'd like to I don't want to dilute my efforts too much. I never questioned the content of the page, it's very good and well laid out (highly scanable with lots of good links). I was just commenting on the code incase someone was planning to copy the code directly. But a better option would just be to link to his page anyway, so that any future updates are available and to avoid duplicating the work in the official documentation. Want to search the BOINC Wiki, BOINCstats or various BOINC related forums from within firefox? Try the BOINC related Firefox Search Plugins |
Send message Joined: 8 Sep 05 Posts: 74 |
A current confusion for members is that as well as the Unofficial Boinc Wiki Agree! I don't think you've misunderstood at all, you've illustrated a major point - that everything is rather fragmented and seriously lacking organisation - which will obviously be highly confusing to users; especially new ones. I myself found the Trac system hard to navigate, which (trying not to sound arrogent) I believe says a lot considering I can usually manage to decipher the most cryptic of nav systems reasonably easily. Want to search the BOINC Wiki, BOINCstats or various BOINC related forums from within firefox? Try the BOINC related Firefox Search Plugins |
Send message Joined: 8 Sep 05 Posts: 74 |
Most people are familiar with MediaWiki as that's what WikiPedia runs off of.May I ask what you're basing this on? Taking the explicit meaning that most (eg >50%) of people associate MediaWiki (the software) with Wikipedia (the primary/intended implementation). Unfortunately people think the look of Wikipedia = Wiki. And that's just not true.I'm not disputing that point, but a similar/related one. I suspect that most people associate Wikipedia with "online encyclopedia" considering that's the part of the name they're most familiar with. Trac is a whole system for the development team. And the wiki part of it really is a wiki. It's markup is a subset of Moin-Moin's markup.integration is good (when there's lots of appropriate inter-linking between sections). However the real issue (as pointed out before) is that there's virtually no indication of what's happened, or what the current plans/intentions are - it just seems to have "happened". Maybe changing the "wiki" tab to read "documentation" would work. I have no idea if that's possible within the constraints of Trac.It should be possible, otherwise the package isn't really suitable for production use. I suspect that it is, but nobody's bothered; considering the URL for "the current management system" contains "trac" (which happens to be the package currently used) - a more wisely chosen URL would be technology-independant. Want to search the BOINC Wiki, BOINCstats or various BOINC related forums from within firefox? Try the BOINC related Firefox Search Plugins |
Send message Joined: 8 Sep 05 Posts: 74 |
Yes, that all makes good sense and it's a good idea to have all this formerly dispersed stuff accessible from a single set of buttons in Trac. But including the word 'wiki' in two different boinc compendiums will inevitably lead to confusion.couldn't have put it better myself - people won't realise (until they investigate the matter) that "wiki" is a concept, not a purpose or software package. The well-known word 'Wikipedia' is an all-embracing encyclopaedia on a par with the E Britannica. And many people think that the word 'wiki' is just a short form of 'Wikipedia'. So if crunchers see more than one reference to boinc+wiki, many if not most will expect them all to refer to a single all-embracing compendium of boinc documents.good point The Unofficial Boinc Wiki has had this name for ages and should retain the word Wiki in its name on the grounds of prior use and the Wikipedia-like format of its pages. I think the documents accessible from Trac should be renamed.Only if the purpose is going to remain the same - but I gather that Eric is proposing (and I agree with him) that the whole documentation etc. side of things needs a major overhaul and rethink. So in that case, considering the purpose/function will propably change in a fundamental way and the possibility of "wiki" software not being used (due to it's poor navigation system) - is it really sensible/appropriate/justifiable to continue using the name? "wiki" may be the term for online collaboration now, but what about in years to come when it changes (trust me, it will) - what happens then? We either have to majorly change things (with additional effort needed to not break links) or continue using an incorrect name... seems non-sensible to me. Changing the name could easily give the impression of "renewal" and make people willing to try it again if their first impressions were less than encouraging. Want to search the BOINC Wiki, BOINCstats or various BOINC related forums from within firefox? Try the BOINC related Firefox Search Plugins |
Send message Joined: 8 Sep 05 Posts: 74 |
why should the point need to be explained in the first place? This is making the user/visitor think which is against virutally every usability principal.The Unofficial Boinc Wiki has had this name for ages and should retain the word Wiki in its name on the grounds of prior use and the Wikipedia-like format of its pages. I think the documents accessible from Trac should be renamed. Why not a more descriptive name instead of the current/latest buzz-word which means "collaboration"? I'm not saying the idea is bad - I like the idea of a "wiki" - but almost all users don't care about such things, nor should they have to, or be expected/required to. They don't care what a system is based on, as long as it works and they can do what they want/need. A wiki is a good way to enable such things, but the user doesn't need to be told about it, or even aware of what things are or how they work unless they wish to learn about it; in which case probably means they're a developer/technical person. Right now I deal with three different wiki's, and all are implemented with slightly different software and have slightly different markup conventions. It *is* a bit confusing to keep the three straight, especially as I was starting out. (I've been thinking of creating a wiki page with a table summarizing the differences. Where to put it?)how about starting a blog to document such things, and share your experience? The Trac component which allows the community (as we define it) to edit documentation at Berkeley is a wiki, so there's no point in removing the name from the URL. It's the wiki at Berkeley.until they use something else (other than a wiki) or the name changes - which will only result in great confusion. The Unofficial BOINC wiki is also a wiki. I belive Paul was encouraged to include the "Unofficial" to distinguish it from anything hosted by Berkeley.I don't think anyone's disagring on the technical front, the only issue seems to be should we use technical names on the front-end? If I'm honest I'm very much a "do it right" kind of person (I hate slap-dash). But people just aren't the same way, especially on the web. Users want the content easilly and quickly without fuss. Now, sure do lots of technical magic to make this happen, but don't require them to know about the technical stuff - even having to explain concepts (or new words for old ideas) isn't that usable, and most users will just ignore such information anyway. People don't carefully read manuals, they "muddle through" (experts are just people muddling at a higher level). So people won't take the time to learn what a "wiki" is (unless they're inclined to anyway - but then we're talking about "technically minded" folks). Even for important issues which are of benefit to users; like security, users hate the hassle (they just want it to magically work - which in the case of security is virutally impossible, as most security related decisions need to be made by humans and not machines). My parent's/sister's (relatively new) computer was running rather slowly and unreliably, so they asked me about it (being the tech guy around here). After some scans it was obvious that it was badly infected with malware (aka spyware and the like). I removed the offending software and did a bit of clean up, but explained that to prevent it happening again that they shouldn't use Internet Explorer, but a different browser instead. So, installed Firefox and Opera, added a bunch of security enhancement extensions to firefox (such as NoScript, adblock plus, CookieSafe etc.) and configured them all appropriately (in whitelist mode - everything blocked by default). However, even though all this was for their benifit; none of them appreciate the fact that to protect their computer, they need to tell it what's safe (eg for sites which (wrongly) depend on javascript, or require cookies). I told them that they can disable the few noticable security extras if they wish (because firefox is preferable to IE anyway) but doing so would defeat the purpose somewhat, and increase the risk of re-infection. I don't know of a better case (eg, "security" in general - not this example specifically) which illustrates user's ruthlessness when it comes to performing tasks efficiently, and even more so on the web (getting content easilly/quickly). What we can do is try to distinguish the two by purpose and focus. I mentioned earlier the idea that the Berkeley pages could be thought of as being the "Reference Manual". They would be an authoritative source (it's from Berkeley) containing all information about BOINC, arranged as appropriate for a reference document. The UBW could play the role of the "User's Manual", which would be arranged more as a description of how to do the most common or most useful things, not in the form of a reference manual.this is a far better idea, as i said before. Purpose/function is far more relevent to most users than the tech behind a site. But, as before, i think "user guide" would be more descriptive of the fact that it's planned to be tutorial based. "Manual" seems more technical and thus off-putting. Now that's one way the two could be distinguished, but it doesn't have to be the way it's done. In any case, it would be useful to have clear guiding principles which distinguish the roles of the two.not questioning the idea (I agree with it), but just to say that such info should be put on the "about" page of each site, with a very short, pithy "tag line" on each page of the respective sites to give a basic indication of the purpose of each (eg, "is it a sports site?", "is it a technical manual?", "if so what's it a manual for?" etc. are the kinds of questions that go through a user's head - usually at the subconcious level). A tag-line should be an easy way to identify what the site is about. And should there be only two? The idea has come up that it might be useful to have a completely separate wiki to document how to create a BOINC project and BOINC applications. The idea is to keep the more technical material separate from what the casual BOINC volunteer needs to know (which is what would remain in the UBW). In that case there might even be a third wiki in the collection of BOINC documentation.that's probably a good idea, rather than trying to have a single project cover all possibilities. Not only will the "how to create a project" be far more technical, and to an extent have to assume some level of knowledge (otherwise it'll have to teach people about linux and apache too) then it's usually going to be read by technically minded folk. A seperate "developers" project allows each to grow in a more focused way, rather than trying to be all things to all people. Another subtle point is that far more people are likely to visit the "user guide" site than the "developer" site. And as the target audiences are vastly different, it would be appropriate to design each based on different criteria - again, rather than trying to be all things to all people. So my main point is that we should not think of there being "THE" wiki, as there can be several. How best to make this point and dispel confusion among users is something we may still need to work out.good point to illustrate that everything in this discussion is about planning (design rather than implementation) and any major ideas are encouraged. As for reducing confusion, don't advertise a service until it's deemed "ready" (eg finished/fully implemented/created/writen). Make transitions gradually, allowing for as much transparency as possible (an example; redirects from one site (eg the old one) to another (the new one). Once a change has been decided, don't mess about on the front-end (obviously i'm not saying it should be slapped togther, it should be done properly). If users are ment to go to a new site, make sure it's up, stable, ready for them to visit etc. Also make changes clear, preferable giving the reasons after a basic summary of the changes. All sensible things like that will reduce confusion and make visitors feel more comfortable and "in the loop" about what's happening. Want to search the BOINC Wiki, BOINCstats or various BOINC related forums from within firefox? Try the BOINC related Firefox Search Plugins |
Send message Joined: 8 Sep 05 Posts: 74 |
I wonder how many people even know Trac exists. There was a news item on the main page. But how many of the 10000s of crunchers actually read it?most people don't need to know, and don't need to read it. only the developers (both berkeley and volunteer) should. so lack of awareness in the majority of the "cruncher" community isn't really a problem, unless you have a specific example I've missed? I link to it in my sig on all of the project forums. But I have no idea how many people click through.don't shoot the messenger, but it's probably not much, your sig isn't technically true forum content, it's additional/secondary. I tend to only tell people to go to Trac when they have a bug to report or I know where the documentation for something is. Like building BOINC using VS. I don't even know if there is a page on the UBW for that.Well, that's almost another discussion on it's own - bug reports by most users are rather severly lacking (if the developer reading it is actually expected to replicate the problem, diagnose it, and fix it). So generally bug reports should be made by people who know how - which in my book is anyone who's fully read and understood How to Report Bugs Effectively. How To Ask Questions The Smart Way is an excellent complement to the former, again should be fully read and understood before questions are asked of experienced users or developers. I encourage linking to these in the forum as much as possible, especially in the "before you post" stickies, and when dealing with a difficult or unhelpful user who has a technical issue they're ranting about. I find them to be most effective in changing peolpe from "needy beginners" (not all beginners, just those who run to the technical person for any slight problem without even applying their own thought to the issue first) into users capable of researching/investigating problems on their own - at least before they ask for help. Want to search the BOINC Wiki, BOINCstats or various BOINC related forums from within firefox? Try the BOINC related Firefox Search Plugins |
Send message Joined: 8 Sep 05 Posts: 74 |
Actually, Leiden seems to have their own page in the Dutch version of the Wikipedia.Most BOINC projects have their own page in wikipedia Want to search the BOINC Wiki, BOINCstats or various BOINC related forums from within firefox? Try the BOINC related Firefox Search Plugins |
Send message Joined: 8 Sep 05 Posts: 74 |
But my point still holds. There's nothing stopping a project from having their own Wiki.Of course not, it's a good/sensible idea. An easilly updated/maintained collection of the current/important information related to a project. Could be a good summary of the many in-depth discussions in forums (obviously project specific). Want to search the BOINC Wiki, BOINCstats or various BOINC related forums from within firefox? Try the BOINC related Firefox Search Plugins |
Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.