Forums and Discussion Groups


What are forums and discussion groups in this context? A forum is an online community where visitors may read and post topics of common interest. A discussion group is a group of people who like to discuss mutually interesting topics online. For the purposes of the intranet they amount to the same thing.

In an Internet environment you would certainly commit the records of a forum to a retrievable database, but in a discussion group you may not necessarily. In the intranet, you're much more concerned with retaining that body of knowledge generated for future use by members of the company. Indeed it becomes so valuable as a resource that it should rapidly transform itself into a knowledge base. If you don't do that, what is its eventual use? Do you throw the information away? For the sake of the company it would normally be retained - because a number of questions and responses will invariably come up again.

So let's define our requirement as a virtual place where a series of discussions can occur and that are recorded so that they become a reference for others as well as the people who took part in the discussion. To do this we need a datastore. The forum software will normally define the datastore that is required, be it a database, a file, or XML. Each has its benefits and costs; relational databases are very flexible but need an administrator and management, flat files are much simpler but can grow very large and become unmanageable, and XML has the advantage of becoming a standard data interchange format but will need web-based administration to keep it in place and readable. We'll deal with software more specifically at the end of this chapter.

Note

Whatever datastore you choose, someone in the company should have an insight into what's being stored and in what format, so that it can be extracted if necessary and form a different type of record. Let's say that you need to rewrite a procedure manual, and you decide to see what users are finding troublesome, you can search the database and find a lot of information in the form of ongoing questions, which you can refine for your procedural documentation. This, of course, is always assuming that you've set up the forums to be an information point for in-company processes, and not just message rooms where people organize Friday lunch times. There's room for that type of message on the forum, but it shouldn't be its primary purpose.

Defining the Forum

So let's define what a forum looks like. With forum software you divide your forum into subject areas and users generate threads, and replies are posted under these threads. Moderators look after the forums in their charge, maybe answering queries but making sure that the forums stay on topic and are used and not abused. They may also delete irrelevant or offensive postings. We'll deal with policing the forum in this way later in this chapter.

We will outline the setup for a typical forum. The specific details will be determined by the forum software you use or alternatively, you may want to code the forum yourself. Forums are typically designed top-down, although arriving at precisely what is included in those forums will involve an iterative design process where you may want to list all the topics that should occur. They are then grouped, and reviewed and altered as necessary. Simplicity and directness should be the key here - too complex a forum may well discourage users from knowing where to start. All design decisions, and this includes whether you will be writing your own software from scratch or not, need to take the audience into account. As with all software you should be putting yourself in the position of the user and looking at the problem from their angle. Put yourself in the place of the average user and you may be surprised at the level of simplicity they demand. We're not denigrating the user here as their prime aim in life is not to make forums but to get on with their jobs, which is what we're trying to assist them in doing. And the lower barriers we put in their paths the better for them and for the organization.

click to expand

You will, of course, have to declare a purpose for your forums. It may be that it is more convenient for you to construct several forums dealing with specific aims - for instance you may wish to separate queries relating to hardware, software, procedures, training, or anything that your company requires. How this decision is reached is up to the company involved but should have leeway for change should things not work out as planned. From experience, micro-detail planning at this stage is unwise - you will have to change things as the forums develop so allow yourself the necessary freedom. As we mentioned in Chapter 6, asking users what they need is often the best way to start when deciding on site organization.

Note

You may find it best to start out with a few very general topics (if you're in a computing environment you may choose software, hardware, and so on) and let more specific forums grow naturally. If 75% of the traffic is about Outlook, then you may want to make a separate forum for Outlook, but if you start out with a separate forum for Outlook and no one uses it, then you have to deal with removing it and any old references to it. It's like booking a room for a lecture; if you have a choice between a room for 100 people or a room for 150 people and you aren't sure how many people will come, take the smaller room. If you get 105 people they'll be impressed with how popular it was, if you book the larger room and get 75 people, it looks like a bigger gap. Similarly, if you set up ten forums and four are popular, it looks like a failure, but set up three and find that you have to add a fourth and it's growth. It also saves you from asking ten people to be moderators of forums when you only need four.

Having declared the purpose of the forum and set up its structure you have to tell your users what you expect of them. At the top of each forum it would be helpful if you declare its purpose and some broad limits about what would normally be expected. Along with this it would normally be necessary to put some sort of caveat about responsibility for the accuracy and acceptability of postings.

You need also to be aware of the costs of the forum - if you have chosen to moderate all postings prior to publication then this will be a cost in time to those performing the moderation service. Your ROI will have to be modified as a result. However in most public and private forums moderation of every post is seen as an expensive overhead as well as downgrading the forum as users are not then considered adult and responsible enough to make their own statements. If there are registered forum users who abuse the system then it may be necessary to moderate their posts, or you may care to moderate posts of new users. Frustration can occur and your forum may not be used if you are too heavy-handed. Be aware, however, that corporate management may not see your users as responsible and ask questions - be prepared with your answers however you see them. The way I and a colleague have had to deal with this when a user posted an question critical of company policy (born out of frustration) was to stand up for the user. We asked whether the storm in a teacup that was being brewed was really for the good of the company and whether the poster may have had a point. The objection disappeared.

One of the great things about a forum on the company intranet is that it can be international and is not time zone-dependent. Thus employees from any part of the globe can access and be party to ongoing discussions and contribute. People doing similar jobs can communicate and feed off each other's ideas. However this brings us to the realm of language - if several different languages are spoken in your organization then you will have to handle it in whatever way is practicable. Whether this means having translation engines or by declaring a 'forum language' is up to you and the way your company is structured.

Chatrooms

An intranet relay chatroom is an ideal place for informal typed-message discussion over distances. Here people can, as the description says, chat with much lower cost than a telephone conference call. Whether the chatroom is hosted by a server on your intranet or on one of the many free web services available is up to you. There's an advantage in hosting one internally as then security is less likely to be compromised. There are various chat programs around for which you have to provide a host and are usually either Java-based with applets or HTML/script-based that are generated periodically by the server. However if your chats are not going to carry sensitive information you may consider using someone like Bravenet - who provide a Java chat that's very fast but is advertising-supported. For this you will need to have Java enabled in each browser and be able to resolve any firewall issues involved.

There are advantages to chatrooms, the major one being cost. There are also several disadvantages that may, or may not, be important for you.

The first disadvantage is one of non-permanence - in the first section of this chapter we discussed the desirability of recording information for eventual possible transformation into the company knowledge base. With many chatrooms no record is kept, so if substantive discussions take place then someone should be responsible for making a note of the discussion and transcribe the conclusions onto one of your permanent forums. Whether this responsibility is imposed on one of the chatters, takes the form of a minutes secretary, or whether (and in my mind best) someone volunteers is up to you.

The second disadvantage is in the undoubted fact that this planet is an oblate spheroid spinning round a small star located in a galaxy - we have time differences between countries. To chat, people have to be online at the same time, and this may mean working odd hours in some countries. From experience in doing this there is no 'right' time to chat - someone has to get up early or stay up late. You have to schedule these things and adapt to fit. It seems to work that if you have regular chats, then the timing for them should be varied so that different people are working at 11pm their time.

If you are going to set up an international chat then you need to agree (or publish) a time for this to occur. One scheme is to try and find out the individual times that exist in each country from somewhere like http://greenwichmeantime.com/ and express the meeting time as that time and the local times of likely participants, such as "Chat tomorrow, 16:00 BST (15:00 GMT, 10:00 EDT). Another suitable method is to use the UT (Universal Time - essentially the same as GMT) convention and let the users work it out as you may make a mistake. This is really good if your users have correctly set their time zone and daylight saving preferences so they know, but some users are known to leave their time zones set at Seattle time.

If you're going to allow people to do access out of local hours would they be more inclined to use it if they could access it from outside the office, especially at home? And if so, how are you going to arrange security and privacy? I'm talking here about home workers and people on customer sites - this is not advocating participation in forums in 'unpaid overtime' mode. If participation in your forums starts out voluntary and ends up mandatory and part of the appraisal or review processes for each employee then that seems like a backwards step. However participation in and moderation of forums should really not be a prime activity for anyone - you don't want projects getting behind schedule because staff are involved in question and answer sessions.

Messaging

The final mode of non-e-mail communication is instant messaging. Your company could run an Instant Messaging Server themselves as part of the intranet, or use an external service. It is useful for subgroups of workers who need to communicate. It is the least managed of the three groups of communications resource and is only really suitable for quick instant answers that would (or should) probably never make it into the knowledge base. There are also well-publicized security issues on externally hosted instant messaging services, so it's your choice if there is a need in your company.

As it's the least-controlled medium messaging lends itself to potentially being the most off-topic and time-wasting. A large general messaging service involving every employee would probably mean no work done for the entire company for long periods of time. Gossip about the latest soap opera episode could easily spill over into large numbers of people. I have only found it of real use in small groups such as an IT team who need to maintain awareness of what the other is doing. However for some companies larger rollouts will be useful.




Practical Intranet Development
Practical Intranet Development
ISBN: 190415123X
EAN: 2147483647
Year: 2006
Pages: 124

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net