Cristian Driga wrote:
As I said, I would rely on the OOo servers for storing final versions of
everything. Wiki should be for the texts, lists, etc that evolve untill
they reach final versions. Of course everything that goes in the wiki
should be carrefully planned.
The concept of "final versions" is a falacy. The website should be
dynamic and evolving. Using a wiki to work on text "until they reach the
final version" is missing the point of a wiki, and missing out most of
the benefit. Wikis are supposed to be about low barriers, but if you
hide the wiki and only use it as a drafting place and all the "real"
pages still have to go through the old process, you haven't accomplished
much. The wiki should be *the* site, not a hidden page in the basement
of the site.
http://wiki.services.openoffice.org/wiki/Main_Page could only be found
from a link if I knew where to look for it. I'm no web developer but I
am an experienced user and if I find this a problem I'm sure 90% of
potential volunteers will.
As I said above, this can be easily fixed once we have a clear picture
of how the wiki can be used better for accomplishing the mission of the
project. I see no problem here.
No, usability should never be an afterthought. This is the first reason
why so many sites (like OOo) have very poor usability. You can't just
fix it later. Usability must be part of the plan as early as possible.
Alternatively all the links that lead to things
like logos etc should go to the relevant wiki pages where people can
simply up load contributions and edit things.
Better use the existing upload facilities on the website, including
publishing the graphical files in CVS
This misses 90% of the benefit that a wiki is supposed to bring. CVS is
unnecessarily complicated and troublesome for something as simple as
writing a press release or maintaining a web page. CVS was meant for
source code and that's what it should be used for. The main site should
be a wiki. A wiki if access control if you like, but a wiki still.
rather than on the wiki's hard
drive if we do not want it rendered offline due to lack of HDD space or
bandwidth consumption if everything, including google.com link there.
How is CVS less vulnerable to using up HDD space than a wiki? I am sure
that MediaWiki can handle more hits and bandwidth than CVS. After all,
it was designed with exactly that purpose in mind, and it is currently
used in one of the biggest sites in the world (Wikipedia). If MediaWiki
is good enough for Wikipedia, why isn't it good enough for OOo?
Especially for graphics the amount of Mbytes is huge. If you look at the
Art wiki tables, the preferred method is uploading in IZ or documents
section on the main site and putting the link in wiki. After they are
placed in CVS, the links are edited accordingly. This should not be too
hard to accomplish with proper instructions by any user.
I couldn't disagree more. Requiring IZ and CVS is a *huge* barrier. Jean
is a very technical computer user and it took her close to a month to
get it working. I had used CVS already in other open source projects and
I had a lot of problems. Ian runs a computer company, and he hasn't yet
managed to get it working.
No, you can't just fix it with instructions. Documentation can help, but
it doesn't do magic. It is a usability flaw to think that you can fix a
bad design through documentation. You can't. A complex or error-prone
process is not made less complex or less error prone by documenting it.
You need to use a process which actually *is* less complex. This is
precisely why Wikis are a big hit, and why using wikis the way you
described misses the whole point of having a wiki.
Daniel.
--
/\/`) http://oooauthors.org
/\/_/ http://opendocumentfellowship.org
/\/_/
\/_/ I am not over-weight, I am under-tall.
/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
