Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Questions About Drupal Functionality and Acceptance

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: David Kowis <dkowis AT shlrm.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Questions About Drupal Functionality and Acceptance
  • Date: Tue, 27 Sep 2005 22:58:06 -0500

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Blosser (emrys) wrote:
> 0) What about the old wiki was so fundamentally broken that we decided to
> switch to an entirely different technology? The main thing the people
> I've asked have told me is that the wiki had a spam problem, but it
> seems this could have been fixed inside the technology we had instead of
> implementing something so different it requires porting everything over.
Truly, I dunno :)
>
> 1) I'm vaguely aware from parts of past conversations I saw that Drupal has
> some kind of wiki module available as an alternative to the book format.
> Depending on what this offers it could address several of the concerns
> I've heard raised, so can I ask why we decided against imeplementing it
> so far?
http://drupal.org/project/wiki
models phpwiki.sf.net's syntax

> Second set of "questions", these are some of the specific gripes I've heard
> raised about the Drupal site:
>
> There are several under the general idea it's too hard to add content.
> Specifically:
>
> 2) You have to have permissions as an editor. The wiki of course allowed
> anyone to edit, and this led to a spam problem. A common opinion
> however seems to be that the Drupal site goes too far the other way, and
> that anyone with a registered account should be able to edit pages.
Yeah this is quite annoying, if you can register, you should be able to
edit. Even if this requires approval of accounts or something.

>
> 3) The available page formatting options are either too slim or "full
> HTML". The filtered modes allow a very few HTML tags or BBCode. This
> mostly amounts to bold/em, lists, and font colors, as well as a couple
> other pre-formatted block modes. There is no provision for things like
> headers or other block elements. You can do full HTML to get
> everything, but consensus among many is that they don't know HTML and
> don't want to, and that the Wiki tagging was good for this.
>
It'd be nice to have the option, wiki for quick stuff, and full HTML for
things that you want to make look nice yourself.

>
> 4) There is no real "hypertext" method for adding subpages. In a wiki you
> can basically just reference a page that doesn't exist yet and then go
> create it; subpages are created organically and the site grows
> naturally. With Drupal's books, to create a subpage you have to do
> 'create content' again and then find the page you just made in a drop
> down and make your page off of that. It's much more organized and also
> a good bit slower.
>
> (As someone with an information architecture background, organic site
> growth ala a wiki is horrid to me for actual user browsing, but I know
> it's the best way to get people actually contributing. Ideal would be a
> system where contributors could add content organically and then the IA
> could be cleaned up easily later.)
I don't think organic growing is horrid. It'd be nice if there was a
daemon of sorts that would build indexes for us :)

>
> 5) You can't get diffs between revisions of a book page. This is a big
> deal, since often we want to use the site to work out policy and
> technical design stuff. If we can't easily see how a document has
> changed through revisions then this format is quite simply useless for
> collaborative document editing, there's really no two ways about that.
>
> Then there are a couple things that are probably just how this site is
> implemented:
>
> 6) It's a good bit harder to find things on the new site. The old wiki
> index page had everything and was organized very well, especially for
> something that had content added organically. With the new site you
> basically need to ignore the navigation options and use the search to
> find things. I think this can be fixed with just some more time spent
> on the IA and navigation, but it needs to be addressed.
I agree, not that I'm volunteering or anything ;)
>
> 7) The style of the new site is more difficult to read. The content column
> and font sizes are significantly smaller, there's a lot of excessive
> whitespace, stuff scrolls horizontally a lot more and less evenly, etc.
> As someone noted before, compare
> http://wiki.sourcemage.org/index.php?page=The+Source+Mage+Developers
> to
> http://www.sourcemage.org/developers
> for plain readability, there's really no contest. Several people have
> said they've tried to use the code blocks on the new site and just given
> up on them because they are overformatted. Fortunately all of this can
> probably be resolved by just simplifying the style sheet(s) we're using,
> perhaps using the old wiki default style as a guide.
I also agree. <pre> tags are formated very strange. IMO, the default
tags should behave in the default way. I don't know how difficult it'd
be to add a drupal class to everything so that the internal stuff that
drupal uses is distinct from the regular tags.
>
> Last questions, to get some resolution to these:
>
> 8) Are any of these resolvable in Drupal now, using additional modules or
> configuration, etc.? Which?
Yep, already answered :)
>
> 9) For those that aren't, what do we do?
uhm, out-source it!

- --
David Kowis

ISO Team Lead - www.sourcemage.org
SourceMage GNU/Linux

Progress isn't made by early risers. It's made by lazy men trying to
find easier ways to do something.
- Robert Heinlein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDOhTOtgErhgxHMHsRAm8+AKCXN1W+oHZoZqzNbF6nJKfXKctbYQCfeUNf
KL3DsmvWrtROdbc4fURmkX0=
=hfxo
-----END PGP SIGNATURE-----




Archive powered by MHonArc 2.6.24.

Top of Page