Skip to Content.
Sympa Menu

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

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] Questions About Drupal Functionality and Acceptance
  • Date: Tue, 27 Sep 2005 20:44:54 -0500

One of the 1.0 targets was to "Install a CMS-type software to integrate the
pieces to the Web site". This is done as far as installation goes;
however, to be really considered complete I think we need to have the
content from the Wiki moved over and available as well. Unfortunately the
Drupal site appears to be having some issues with acceptance from the
developers; the docs are being moved only slowly, and quite often people
who are working on converting things are heard to complain that there are
things about Drupal that they have issues with. I would like to start a
thread here to ask some questions and hopefully get this all resolved.
Note, I'm not asking these as someone with a particular technology agenda
or because I want to denigrate anyone's work so far, I'm just interested in
getting our developers into a site they find really useful. My hope is
that the Tome team will have ready answers to all of these and time to
implement them, and won't hate me for organizing the questions and asking
them. Don't shoot the messenger. ;-P

First questions, for my benefit since I wasn't necessarily around for all
of this:

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.

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?

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.

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.

(On the flip side, as someone who knows HTML, I'm glad to have the full
formatting option available; there were some things that weren't
possible on the wiki for me.)

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.)

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.

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.

Last questions, to get some resolution to these:

8) Are any of these resolvable in Drupal now, using additional modules or
configuration, etc.? Which?

9) For those that aren't, what do we do?

10) Does the Tome team currently have time to work on these?

Attachment: pgpebBlbCAE1g.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page