Posts by Lee Carre

1) Message boards : Documentation : Runtime environment (Message 11727)
Posted 20 Jul 2007 by Lee Carre
Eric Myers wrote:
From the boinc_projects mailing list:

David Anderson wrote:

We need a document describing the runtime environment
for BOINC apps (slot/project directories, shared mem, etc.)
and the rationale for its design.
If someone wants to add this to the Wiki, feel free.

-- David
Surely this is something Rom would be a suitable author for?
2) Message boards : Documentation : UBW domain names (Message 11726)
Posted 20 Jul 2007 by Lee Carre
Thanks to Chris Malton all of the various names registered for the UBW are now all providing a permenant redirect to
Great work.

Only problem is that (without the www host-name) the domain doesn't have a root host (A) or redirect (CNAME) DNS record, so doesn't point anywhere!.

after the DNS record is added, one "site" should HTTP redirect to the other. Probably best to keep things consistent by having a redirect from to
3) Message boards : Documentation : UBW domain names (Message 11679)
Posted 18 Jul 2007 by Lee Carre
Hi Lee

I can see your point.

I imagine the word wiki was originally included in the UBW name to show that the compendium was user-led and editable by users. And now 'wiki' is also included in the name of the separate Trac collection, presumably because it's also editable by users.

I suggested keeping it to distinguish the UBW from the main boinc website info pages.

But for the majority of users who would never dare edit even a spelling mistake if they noticed one, the fact that it uses wiki software is irrelevant. As you say, what matters is the purpose.

That's the general impression I'm getting (using the same name out of habit).
Forgetting the issues of confusion or discomfort created by technical terms for a moment, let me ask another, more specific, question; if "wiki" is included in the name (or worse the URL), what happens when a "wiki" is no longer used? Oh, and without breaking any links.
4) Message boards : Documentation : Inventory (Message 11675)
Posted 17 Jul 2007 by Lee Carre
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).
5) Message boards : Documentation : Inventory (Message 11674)
Posted 17 Jul 2007 by Lee Carre
Actually, Leiden seems to have their own page in the Dutch version of the Wikipedia.
Most BOINC projects have their own page in wikipedia
6) Message boards : Documentation : Inventory (Message 11673)
Posted 17 Jul 2007 by Lee Carre
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.
7) Message boards : Documentation : Inventory (Message 11672)
Posted 17 Jul 2007 by Lee Carre
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.

I agree there is potential for confusion, but Wikipedia != MediaWiki != wiki. As Kathryn pointed out, a wiki is a general concept - a piece of software which lets a group of people edit documents collaboratively. And to do so easily and quickly. The name comes from the Hawaiian word "wiki wiki", which means "quickly".

The best way to avoid confusion is make this point clear.
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.
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.
Perhaps there are other ways to distinguish it as well? But what we can't do is refer to "THE" wiki, because there are two.
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.
8) Message boards : Documentation : Inventory (Message 11671)
Posted 17 Jul 2007 by Lee Carre
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.
9) Message boards : Documentation : Inventory (Message 11670)
Posted 17 Jul 2007 by Lee Carre
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.

All of the old .php pages have been migrated to the Trac wiki and they are no longer being maintained. All the documentation along with the source code and ticketing system are all in Trac. To me, it makes more sense than what they had before (php pages for documentation, CVS for the code repository and BOINCzilla for bugs).
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.
10) Message boards : Documentation : Inventory (Message 11669)
Posted 17 Jul 2007 by Lee Carre
A current confusion for members is that as well as the Unofficial Boinc Wiki

that is published in the usual wiki format, there's now also the TracWiki/BoincWiki which appears to be funded and published by BOINC in Berkeley. The latter is not in the usual wiki format, though it can be edited by any member (perhaps now with restrictions). My own view is that it was a mistake ever to include the word 'wiki' in the name of the Trac compendium.

If I've completely misunderstood something here, I would guess that the majority of boinc crunchers who've ever looked at boinc/unofficial/official/wiki/info/trac pages are equally confused about what is what.

To use wiki teminology, this needs to be disambiguated. Preferably by renaming ( both?), and NOT by interminable forum posts explaining which is which.

It's a pity we haven't got Paul Buck here to add an opinion.

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.
11) Message boards : Documentation : Inventory (Message 11668)
Posted 17 Jul 2007 by Lee Carre
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.
12) Message boards : Documentation : UBW domain names (Message 11667)
Posted 17 Jul 2007 by Lee Carre
Post: seems a good name to use. I don't think we should ever refer to it as even if that ever eventually becomes the wiki's web address. The name '' could easily give the impression that it means the main boinc page here:

If there's a strong objection to hyphens, would surely be just as good.

I'm genuinely asking, and don't mean to sound critical, but why are people so fond of including "wiki" in the name? (or any technology reference) instead of a tech neutral name, and one which describes the site's purpose?
13) Message boards : Documentation : Search (Message 11619)
Posted 14 Jul 2007 by Lee Carre
Don't the list archives require having signed up for the appropriate list? Or am I thinking of something else?
Another excellent point to keep in mind as the project progresses. Don't (unless really, really needed, force users to sign in, or create an account just to access information.
14) Message boards : Documentation : Search (Message 11618)
Posted 14 Jul 2007 by Lee Carre
I've added a few more options. You can now search Subversion, and the boinc_dev and boinc_projects list archives.

I'm now thinking this is getting complex enough to deserve a separate page.
The "Search BOINC with Google" page.
I'd suggest pointing everything to a /search/ page (eg or whatever) and then having whatever search feature presented there, so that it can be updated (and replaced with a proper internal search) later without having to create new search pages with different URLs, and update all the links to them.

in short, just point all visitors to a single search URL (eg /search/). If needs be, have links to different types of seaches from that; eg /search/google/ for the google site:xxx search etc.

it just makes site maintainence much easier
15) Message boards : Documentation : Search (Message 11617)
Posted 14 Jul 2007 by Lee Carre
But I do like the more fine-grained search functions. Lately I've been using searchterm on Google when I know I've seen something in one place or another. Especially on the forums. The build in forum search leaves a lot to be desired. The way results are presented are confusing for me. But then again... what can we say about me?
No K, you're absolutely right.
It's a dreadful search, both in the query form, and the display of results.
Needs vast improvement!

People shouldn't struggle to understand stuff on the web, it should be obvious or self-explanitory. You're not the only one though lol, I hate the boinc forum search too, it uses exceedingly bad search algorythms (sp?) too, so doesn't actually find any relevent info anyway! lol
Better off replacing it with a google (site specific) seach for now until a much better internal search feature can be implemented.
16) Message boards : Documentation : Search (Message 11616)
Posted 14 Jul 2007 by Lee Carre
An important part of good documentation is to be able to easily search and get exactly what you want.
i'd say critical part of good navigation, it's the single most used feature on a site, even one which has good navigation panels to start with.

So I've played with Google's search interface...
Google is good to start with (to provide something) but should eventually be replaced with an internal search to include updates immediately, and categorise stuff better than a general search engine like google would.

How to divide up the search might still be improved. Not everybody knows what "wiki" means, so maybe we need better labels
not only labels, but URLs should also not include technical terms, and if possible not include uncommon terms too, unless the subject of the article/section is technical matter, as is the case with BOINC, but an average user frankly doesn't care what a site is hosted on, they care about the content. so something descriptive of "collection of information" is required instead of whatever technology is being used to host it (eg "wiki")

or an entirely separate search for beginners. But this shows the main idea.
"simple" (default) and "advanced" (full set of options) search as is normal for most sites should solve the problem if implemented well.
17) Message boards : Documentation : UBW domain names (Message 11615)
Posted 14 Jul 2007 by Lee Carre
The domain name now points to the Unofficial BOINC wiki, and changes even when the IP address of that server changes (which is often).

Is this the name we want it to have now, unless becomes available to us?
Sensible enough for now, however although the DNS redirect works (eg DNS CNAME is in place) HTTP redirects are lacking which is bad on many conuts

  • caching is defeated, same page with different URL is re-downloaded
  • search engine rankings; google punishes the "multi domain" approach and sees it as an attempt to increase rankings.
  • confuses users;

    • are they actually the same?
    • are they the same site, or is one a copy of the other?
    • which is the true/proper/correct name?

adding HTTP redirects solves/prevents all of these problems

18) Message boards : Documentation : Content Planning & Information Architecture (Message 11614)
Posted 14 Jul 2007 by Lee Carre
Appologies for my rather long absense, other projects demanding my attention/time and all...

It's JavaScript dependant isn't it? That'll have to be changed to use a better - at least; more accessible - method. You Can't Rely on JavaScript Being Available. Period.

Yes, it uses JavaScript, and I agree that you cannot rely on JavaScript. Thanks for a link backing this up. What you can do is have optional features which use JavaScript to make the experience nicer. But the site must work with JavaScript turned off, and that should always be tested.
Absolutely right. There is infact a whole methodology to producing accessible, un-obtrusive JS which (should) work cross-browser etc. (like all good coding should).
It uses DOM methods which is the standardised way of applying JS to different browsers, eg having a standard language and "API" as it were.
the JS should be in an external .js file, referenced in by a <script type="text/javascript" src="absolute or relative URI">.

making it accessible includes using methods which aren't mouse-specific (or any pointing device for that matter). using "active" functions/triggers instead (eg like CSS "active" instead of "hover").

progressive enhancement (formerly graceful degradation) is a style of coding to make sure that JS will only be a factor if it's avalable in the first place. Removing much need for "testing/checking" etc. although basic testing should still be done, proper methods remove much of the need to test every possible situation as is the case with "dis-graceful degradation".
same idea as using valid code - removes the need for lots of testing in every version of every browser.

there's loads of info about writing good JS if you know where to look (but that article - by a standards advocate - is the best i've seen because it highlights the fact that the user doesn't always have control over javascript availability, so remarks like "you need to enable javascript in your browser" are instantly quashed :)
There are several books on the subject too actually. I can recommend some if you like.

Why aren't the patches in the CVS anyway?

I test them on Pirates, then submit them to Rytis for his consideration. I've been slack about the latter step.
Ah ok, you're busy, that's perfectly understandable :) I know the feeling ;)

Considering you seem to be the most helpful boinc dev who knows the code already; what would you recommend as the best way for someone very familiar with front-end code and usability to be able to apply changes to code which is predominantly back-end (server-side; PHP) based/oriented?

Because that's my major problem at the moment, I'm able to change simple things (like link text) but not the important stuff like page layout (migrating from tables to CSS).
Also PHP has it's own considerations for efficient ways of doing things etc.
19) Message boards : Documentation : Inventory (Message 11612)
Posted 14 Jul 2007 by Lee Carre
This was noted on the SETI@Home news feed. Add it to the inventory

* How-To: Join Distributed Computing projects that benefit humanity

Appologies for my rather long absense, other projects and all...

I came across that page the other week, the idea and layout seems good, but the underlying code is rather messy, check the validation result
20) Message boards : Documentation : Inventory (Message 10877)
Posted 12 Jun 2007 by Lee Carre
Eric Myers wrote:
Lee Carre wrote:
Eric Myers wrote:
What is the re-editing timeout on this board?
I believe it's an hour by default. Although I have issue with the idea of being able to edit for an hour, then not at all, not even to correct spelling/grammar errors, seems very counter-productive on the usability front lol

I would actually like to see it shorter. As a scientist I'm used to writing in a logbook (either paper or electronic), and the convention is that you just write your observations and move on. Errors are never deleted, just corrected (with a new log entry) or perhaps made invisible. You just go on with it, and the logbook is a part of the input data stream.

You then take this raw data and digest it and put it into a nicer, more organized form. But that is a separate, new document, not the logs.

I've made changes to the software (see Pirates@Home) to support this kind of use for the I2U2 project, though of course we don't have to be so strict here in this discussion.
I do see the point of some of the ideas behind it, to reduce abuse (eg people editing messages a long time after they were originally posted in a way to make people who replied look bad, due to changing the context of their original message etc.) and the fact that things are set in stone (again, for replies etc.).

The problem is that this isn't the rough version which is then processed and presented nicely later. For usability it's horrible, corrections & additions occouring in new messages (which may not be read), the general flow of a thread can be really fragmented at worst.
Basically it doesn't play well with one of the fundamental usability rules; scanability.

I mean, I know I'm in the minority talking about usability (ie, the "prevent abuse" thinking has won because it's on the mind of more people, and those controlling, having access to, and/or able to edit the source code), but there's no escaping the fact that good usability is really important for a sucessful resource.

Think about your own experiences, and how long it can sometimescan take to find some useful/revavent information in a thread.

I suppose you could argue that the documentation is supposed to be the pretty version. And yes i'd agree with the idea that it's supposed to be, but we all know what usually happens to documentation ;)
If the documentation is intended to be the nice version of the collective knowledge, then again, it needs to be done really well if it's going to be at all effective.
I don't mean to sound pesimistic, I'm just pointing out things which aren't obvious at first, or not until after experience of how it can go wrong.
Usability in general covers both of those things unfortunetly, and trying to show measurable benefit is hard. To start with, what exactly do you measure? lol
Again, think of your own experiences; a common example is how long it takes a site to load; user's hate slow sites (which is essentially down to attention spans, something which can't be changed), I know i've been cursing sites which take forever to let me do something. But to measure the benefit of a fast site is hard; to justify it to the doubters.
Maybe loading time is a bad example, most peolpe realise that speed is very important (user's just leave out of frustration otherwise) but there are many other more subtle examples which don't get a second thought from those concerned about other things.
Unfortunetly the usual result is that usability suffers (greatly) and a not-so-useful resource is all that remains.

Next 20

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.