Webcrossing Quirks

We've talked about WCTL before, about how it is a fast, easy language which is great for UI, but that it's a little, well, quirky.

There are a few quirks in Webcrossing itself, just kind of goofy "what were they thinking" settings. Quirky, but a little cute, like a slightly cross-eyed Siamese kitten is quirky.  The answer, of course, to what they were thinking is that in most cases some customer way back when paid to have that setting added.  It made sense then, to them, but not to anybody since then.

I want to emphasize to anyone reading this that except for #1, these are all OPTIONS.  They are not turned on by default and an administrator has to explicitly turn them on before the server will function that way.  Just to be clear that Webcrossing is not totally whacko.

Here are some staff favorites:

1. Shut down server link.  Remember, you need shell access to a terminal to start Webcrossing.  So why would you want a "Shut down server" link in the control panel?  Once you shut it down that way, you can't start it up again that way.  Right now, it is two or three links from the bottom of the page so is more difficult to click accidentally. But I am old enough to remember it being right above the "Return to site" button, and I have clicked it accidentally more than once.
   
   
   
   
   
2. Provisional users have full access before their email addresses are validated. You can set the site to require that people respond to an email validation challenge.  Before they respond, you can give them read-only access, moderated access, or full (participant) access.  Why would you turn on provisional users and give them full access before you were sure their email address was valid?  What's the point?
   
   
   
   
   
3. Registered users can edit or delete anyone's posts, not just their own.  Excuse me?  Edit someone else's post if I'm not an administrator?  DELETE someone else's post?  I guess if you were building a wiki this might be useful, but in the ordinary course of forum management I can just imagine the havoc this could wreak :)
   
   
   
   
   
4. And, the more bizarre sibling of #3, Guest users can edit or delete anyone's posts, not just their own.  You don't believe me?  Here it is, right next to all the more reasonable settings like "guests can post messages" and "guests can add discussions."  I dare you to turn this one on on your forum. ;-)
   
   
   

Funday Monday, A Moment Of Awwww....

Kitteh versus currycomb:

Passing clientside data to the server with AJAX

Sue wrote a post about mixing clientside and serverside Javascript in Webcrossing. I want to touch briefly on a related topic, which is passing data back and forth between client- and server-side. It can get confusing, especially when you're writing in essentially the same language throughout, to remember what context you're in and what you have access to and what you don't.

Where things can get really wacky is when you're using AJAX calls to change the contents of the browser window without a page refresh. Specifically, you have to remember that any local server-side variables you may have set outside of the AJAX'd content won't be there once you make an AJAX request. Here's a simple example, where I'll use WCTL to make it a bit easier to separate client from server.

First, let's assume your page has the following AJAX call on it. (This example uses jQuery, the Javascript framework with which I'm most familiar.)

function whenYouClick() {

  $.get("/someNewContent",,function(newText) {
    $('#newContentGoesHere').html(newText);

  });

};

If you're not familiar with jQuery, just take my word for it that this code will call the WCTL macro or WCJS command "someNewContent", and whatever it returns will replace the current contents of the DOM element with ID "newContentGoesHere".

Now, let's move down into the body of the page...

%% set initValue 25 %%

<div id="newContentGoesHere">

%% use someNewContent %%

</div>

And then, separate from this page macro, you have this macro:

%% macro someNewContent %%

%% set returnVal 2*initVal %%

%% returnVal %%

%% endmacro %%

It should be obvious what will happen when you first load this entire page. someNewContent will execute and evaluate to "50" which will become the content of the div. But now, what happens if the clientside function whenYouClick() makes the AJAX call? someNewContent will execute again, but outside of the context of the entire page, that local variable initVal is not defined. returnVal will be 0.

As long as you keep it straight in your head which data is available where, this problem is not difficult to avoid. Here are two common approaches:

• You can store needed data in session variables. If you used session.initVal instead of the local variable, it would still be available inside the AJAX call (with some caveats that affect guest users who, depending on system settings, may not have a unique session).
• Alternatively, you can pass the data as arguments in your clientside function (or put it inside a DOM element where your clientside code can retrieve it) and then through to your AJAX call. Once your AJAX code is executing, any arguments you pass will be part of the form object.

This is a very brief look at a rather challenging topic, but I hope it gives you some idea of the issues involved.

To Thread or Not to Thread

Within the realm of message boards, there are a couple of different ways to organize the messages. Many people don't realize this, but it can make all the difference in the world in how people interact on your message boards. Some people have a strong preference for one or the other, but either will work. Each has its strengths and weaknesses. Even if you prefer one style, the needs of your community may dictate that you at least consider the other style.

There are two basic ways to view message board posts: threaded and conversational.

Conversational (Linear, Chronological) View

In conversational view, also known as linear or chronological view, posts are placed in chronological order, one after the other. This organizational method is good for a group of regular participants engaged in free-flowing, deep conversation. For example, this might work well with a health-related community in which there are groups for various illnesses and members are providing support to one another. It's harder to reply to individual messages, and more difficult to find "the answer" out of the bunch, however, so if you need to be able to find needles in haystacks, you might be better off with a threaded organizational structure. Conversational mode is more of a many-to-many discussion.

Threaded View

In threaded forums, the posts are arranged like an outline, with one post immediately following the one to which it is replying. Threaded organization works well in situations where people need to be able to find a particular piece of information in a hurry, such as in technical support forums. Threaded organization fosters multiple small one-to-one conversations rather than one group discussion.

A Comparison

While threaded conversations might seem more organizationally intuitive, forums generally get more participation when they use conversational mode. This is because people tend to find conversations straightforward and easy to follow.

If you have not experienced both modes, I would encourage you to do so, to get a feel for which one you prefer. Quite frankly, I have a strong bias toward conversational mode. Threading works well for newsgroups and other non-Web-based applications, but I feel that it's more difficult to use it on the Web.

Webcrossing Settings

Whatever you decide is best for your community, Webcrossing's got you covered.  In the Control Panel > Discussions page, you can choose from:

• Default to threaded, but user can choose conversational in their preferences
• Default to conversational, but user can choose threaded in their preferences
• Mandate threaded
• Mandate conversational

And whatever you choose can be overridden for an individual discussion on the Edit Discussion page, even in mid-discussion.

My favorite combination of settings is to set the actual discussions for conversational view (mandate it), and then in the "Tabular Message View" settings, turn on the option to show replies.  This puts links between the message and the message being replied to.  At the bottom of the message being replied to is a list of all the replies.  At the top of each reply is a link back to the one it was a reply to.  In that way, you can still enjoy the advantages of conversational view while still being able to follow threads if necessary.

Feel free to experiment!

Code snippet: What's up, DOCTYPE?

In a previous post I mentioned using AJAX to call server-side functions and write dynamic content to the page. Here I introduce an easy workaround for one of the places where Webcrossing trips over its own flexibility.

There's a system setting to include a DOCTYPE in every page response for compliance with W3C standards. But once defined, this happens automatically for every request, including those which are not intended to be a full page of HTML, such as the response to an AJAX call. In order to avoid breaking your page, use this simple clientside Javascript function to remove the DOCTYPE:


function removeDoctype( txt ) {
return txt.replace(/<!DOCTYPE[^>]+>/g, "");
}

Implemented with a jQuery AJAX call, it looks like this:

$.get("/someNewContent",,function(newText) {
    $('#newContentGoesHere').html(removeDoctype(newText));
  });

A colleague of mine likes to say, "Every so often a programmer will determine that the best solution for a problem is a regular expression. Now she has two problems."

WebCrossing Theme Development

The challenge of Webcrossing at this point in time from an educational implementation perspective is the theme development possibilities. Our organization lacks the skill set to truly customize the appearance of Webcrossing to meet the aesthetic expectations of our users. We have tested Joomla, Moodle and Drupla and I still keep coming back to Webcrossing for a number of features that are either poorly designed in the other platforms or do not exist. There could be a whole new market for Webcrossing if it had third party development sites that users could easily access like:

http://www.rockettheme.com/

http://www.shape5.com/

Any feedback would be appreciated.

5 Tips to Prevent Flames

Some amount of disagreement among community members is probably inevitable. Just as in face-to-face communities, sometimes people get on each other's nerves. Rather than hoping against hope that it won't happen in your community, it's better to plan for problems from the outset and have a strategy in place for dealing with them.

What You Can Do

You can minimize the unpleasantness -- and help douse the flames when it happens -- with a judicious application of software tools and common-sense people skills. Here are five strategies you can use:

1. Choose software that allows you to deal with -- and prevent -- problems. One approach is to use moderation, which is when some or all posts are read and approved by a moderator before they go live. Reading every single post is obviously time-consuming for your community staff, but some software allows you to specify a list of objectionable words, and then it queues for moderation only posts that contain those words. Webcrossing allows you to set a different objectionable word list for each folder, if you wish.

Another tactic is to deny problem users access to some or all of your site, or to withdraw certain privileges. These users can either be denied access completely (you delete their existing user name, and they can't register again), or they can be denied access to a given area within the site (since they're logged in, the software knows who they are and can be programmed to not let them into certain areas). Or you can set it so they can read posts but not post anything themselves. You may not need these tools often, but when you do, they can be lifesavers. You can do this with Access Lists with Webcrossing.

A third approach puts the responsibility in the hands of the users by giving them filtering tools that allow them to block postings from people whom they find difficult. Webcrossing provides a "bozo filter" if you use the default Tabular Message View.

2. Write a watertight "terms of service" document. Require your participants to agree to the document when they register. It doesn't have to be legalistic and scary, nor should it discourage the discussion of issues. But it should specify that attacks on individuals are not permitted. The advantage of having something in writing is that if someone gets unruly and you need to take action, you have an existing document that you can direct them to, and your enforcement actions won't seem arbitrary.  Webcrossing's Register Plus plugin allows you to require agreement to your Terms of Service in order to register.

3. Plan a "seeding" period. It's amazing how many new sites skip this step.  But it can be crucial for setting the stage and settings expectations for behavior.  Before you open your community, invite a couple dozen people to come in behind the scenes. These should be experienced message board participants and people whom you can count on to help you get some interesting conversation going. Besides simply making it seem like "somebody's home" when the public arrives, these folks will set the stage for what will come when the doors open, including being role models for your users-to-come about what kind of behavior is usual and expected.

4. Use facilitators to shape the discussion. Faciliators can model civil disagreement and discussion and deal with problems when they arise. They can deal with your participants via private e-mail and encourage them to work out their issues with each other without making your community an unpleasant place to be. When all else fails, they can use the software tools available to them, as outlined in strategy #1, above. A good facilitator is worth his or her weight in gold!

5. Resign yourself to the fact that you're never going to please everyone. Taking action when things get out of hand is sometimes the only way to prevent your community from self-destructing; your "good" users will usually appreciate your taking action against people who are causing trouble. Otherwise, the positive contributors will get disgusted and may start to spend their time elsewhere. But at the same time, when a facilitator acts with a "cop hat" on, he or she is going to raise the ire of those in your community who have problems with authority, no matter who is wearing the hat. You may get complaints about First Amendment rights and censorship. The trick is to not take it personally and remember that for both you and your participants, everything online feels more intense than it would offline. Thus, if you can encourage people to take a "time out" of a few days to get perspective, it's likely to help a great deal.

Using a combination of Webcrossing tools and good facilitation, you can minimize the flames in your community.