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: Jason Flatt <jflatt AT sourcemage.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Questions About Drupal Functionality and Acceptance
  • Date: Tue, 27 Sep 2005 21:32:01 -0700

I'll try to answer what I know. Adam or anyone else who has more current or
relevant information can correct me.

On Tuesday 27 September 2005 06:44 pm, Jeremy Blosser (emrys) wrote:
> 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.

It wasn't /just/ that the wiki was susceptible to spam (defacement or
vandalism are more appropriate words, IMO), it was also that the whole Web
site was a mish-mash of various programs that didn't really flow together and
required separate accounts on each piece to do anything. The initial edict
was to simply secure the wiki [0] which was not really possible with anything
available. Wikis were designed to be open and editable by anyone. The
available software either they gave no permissions, or they gave simplistic
access that was more or less on or off, or they were full blown CMSs. (Or
they required root access to install and configure some special software,
which we didn't have with Ibiblio.) So the choice was made to go full bore
and get something CMS-ish in place and replace all pieces of the, then
current, Web site, simultaneously securing the wiki and creating a coherent
look and feel and not requiring multiple user accounts to do interact with
the site. Easier said than done.

[0] http://bugs.sourcemage.org/show_bug.cgi?id=2877

> 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?

I don't know the answer to this question. As I understand it, the Drupal
wiki
module is a simply style format filter, so that people can use standard wiki
markup for their entries. Unless it's changed since I last looked into it
(4.4.x), it didn't offer the hierarchical and "hypertext" page creation
features of a regular wiki. (I could be wrong on that last part, since I
didn't do extensive feature comparison testing of the wiki module once I had
it installed.)

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

That would be the way the permissions were set up. It is possible to let
just
about anyone do just about anything.

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

Last I checked, it was possible to create a custom filter that one could
configure to allow what ever tags one wanted available to the people editing
content. I never really got into that feature, so I don't know the details.

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

Me, too. (Aaah! I feel dirty.)

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

It's possible that the current wiki module offers this, but it would need
some
reading and testing. I do agree that the process of creating a new page
while editing another page can be a bit of a pain, and really kills the
creative juices. Maybe the Drupal developers would be open to a feature
request.

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

There is a revisions feature to Drupal, but I don't know anything about it or
how to access it. There is also a Diff module:
http://drupal.org/project/diff

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

Personally, I usually look for a search feature on most sites. It's
infrequent that I am just browsing a Web site. I'm usually there looking for
something specific, and I don't want to waste time trying to figure out how
they decided to organize it. I do, however, agree that a Web site should be
clearly laid out and a common sense naming scheme should be used.

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

Yeah, that is mostly a style issue. The default fonts in Drupal are a little
wider than I think they need to be. I also don't care for a three column
layout, myself. And as far as the two team pages are concerned, I personally
like the new page better, though I'm sure it could be modified to look more
like the old one.

> Last questions, to get some resolution to these:
>
> 8) Are any of these resolvable in Drupal now, using additional modules or
> configuration, etc.? Which?

I'm sure some of them are solvable. Actually, in re-reading the above list,
I'd say that most of it is solvable. Items 2, 6 and 7 are definitely
solvable. Items 3 and 5 probably are solvable. I'm not sure about item 4.
Items 0 and 1 aren't really problems to be solved, are they, just questions?

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

I'm not sure about item 4. It might be possible to do some behind the scenes
PHP programming to implement that feature.

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

I can't answer that for them (him?).

--
Jason Flatt
Source Mage GNU/Linux: Linux so advanced, it may as well be magic.
http://www.sourcemage.org/
jflatt AT sourcemage.org

Attachment: pgpsin5QypPtp.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page