Hosting Choices: Pricing and More

In the previous post, we looked at what impact a disruption in your software vendor's business can have. In this final post of this series, we'll touch on the issue of pricing and more.

Pricing

Pricing will obviously depend a lot on the particular application or applications you are looking at, regardless of how they are hosted, such as how the pricing model works, when payments are made, what rights you have for use of the application, how support is handled, and so on. But there are some particular areas that you'll want to pay particular attention to.

Many vendor-hosted applications will be priced in terms of a "subscription", for example a monthly fee paid for use of the system, sometimes with a one-time setup fee, but no other fees for things like upgrades. Often there are several different "plans" that you can choose from, offering different features of usage limits, and you can often move up or down between different plans. Make sure that you understand the limits each particular plan offers; is it based on registered users, amount of access, number of documents? Pay careful attention to any limits on disk storage and bandwidth. Because these are shared between many users, it's often in the vendor's interest to put a cap on these; ensure that any limits will accommodate your group's needs.

You'll need to understand if there are any termination charges, minimum subscription lengths, conditions under which the vendor can change their pricing or the plans they offer, etc. While most subscription terms for vendor-hosted applications are not nearly as horrific as those for your local cellphone provider, with the relative youth of "software as a service", there can be considerable volatility in terms of business models.

For a self-hosted application, again the pricing model may vary, but most commonly you will purchase the software via one large upfront license payment, with recurring annual payments for future upgrades. Again, knowing how license fees are calculated is important, but restrictions on document storage, bandwidth etc. are less likely to be a factor, since you're the one providing them, not the vendor.

Changing needs

Finally, keep in mind that with respect to all of the above areas, your needs will almost certainly change over time.

Will the application you choose handle these changing needs? Will a vendor-hosted application be able to scale to fit your increased needs, or are there either capacity limits or drastic price increases? What if you find later on that remote access is more important than you thought when you initially went for the self-hosted system?

In an ideal world, the Web 2.0 workgroup productivity application that you choose will be available in a wide variety of configurations, and has the option of being run either self-hosted or vendor-hosted, with the ability to easily migrate between the two. There are a large number of applications that do allow this, and certainly any popular self-hosted application will inspire the creation of third party hosting services. For applications designed from the start to be vendor-hosted, the transition to self-hosted can be much more difficult, and so is less common.

Summary

We've touched on the fact that there are a lot of things to consider when evaluating Web 2.0 applications for your workgroup. Obviously, we've omitted the most important, and that is will the application suit your needs and help you get whatever you need to do accomplished. An ideal hosting environment, matched closely to your security, access and pricing requirements, is useless if the application is rubbish.

Our intent of course has not been to overwhelm you with additional considerations, nor to turn every technology decision into a six month evaluation process. What we do hope is that we've made it clear that there are choices when it comes to self-hosting or vendor-hosting, there are a number of implications of those different choices, and these should be factored into your decision making processes. At the very least, we've provided a range of issues that you may want to consider with respect to your planned use of the application, and highlighted a number of common pitfalls associated with each hosting option.

As should be obvious, there's no universally "right way" to do things, despite any frenzy to the contrary about how "SaaS will render the idea of buying software obsolete" or "web applications can never be as good as desktop applications", or any of the other hyperboles that the computing world regularly pronounces. It's in your own interest to put pressure on the Web 2.0 workgroup productivity application vendors to deliver both self-hosted and vendor-hosted versions of their applications, so that you have the flexibility to choose which suits your own needs best.

Hosting Choices: Disruption of Vendor's Business

Last time we discussed how hosting can affect software upgrades. Today we'll look at what happens if there is some disruption in your software vendor's business.

You've been happily using your Web 2.0 productivity application for months, and your workgroup has come to greatly depend on it. All of a sudden, there's some major disruption in the application vendor's business. Now what?

What do we mean by major disruption? The company may have simply run out of money, and can't afford to keep the lights (or their website) on anymore. They may have been forced for some other reason, such as legal action, to cease operations. The company's investors or management, seeing it not meeting their expectations, may simply decide to cut their losses. If you're using an application from a larger company, where that application is just one part of their entire business, they may for various reasons decide to abandon it and focus their energies elsewhere.

The company may get acquired; remember, for most startups, which are the main vendors of Web 2.0 applications, this is in fact their primary goal and focus, as opposed to old-fashioned notions such as profitability or building a sustainable business. This may be a good news scenario, where the new owner really helps to push things forward. Or, despite the glowing press release, the acquirer may have purchased the vendor to take its product in a different direction, to kill off the application but leverage the underlying technology for another product, to acquire the vendor's staff, or to shut down a competitor.

For self-hosted Web 2.0 productivity applications, this is pretty much the same risk that you have to weigh with any software purchase. In the short-term, your concern is whether or not you can continue using the application. Generally this will be the case, but there may be some applications that "phone home", either for some critical piece of frequently-updated data, or to check licenses. What happens to them if the vendor's server that they're trying to reach isn't there? Over the medium term, is there a specific deadline you'll need to be aware of, after which the application will cease to function? An application sold via subscription may be programmed to automatically "drop dead" if not updated at the end of the subscription term. And longer term, if you need to transition to another solution, will this be possible? If you can get by not taking your data with you (it may be important, but is out of date and replaced quickly) this may be less difficult. Otherwise, you'll need to consider the same issues raised by backups, of getting access to all your data. As well, you'll need to know if you can do anything with the data after you have it, for example whether it is stored in a closed proprietary format, or one that is more open or can at least be converted for use by other tools.

All of these issues equally apply to vendor-hosted applications. The main difference is that you may have significantly less control of the timetable. If the vendor's web site completely shuts down on the spot, you're obviously out of luck then and there. What would the consequences of that be on your group's work? If notice is given that the site will be shut down in for example one month, there's increased pressure to accelerate a transition, that may greatly impact existing projects.

Next time: Pricing and more

Hosting Choices: Software Updates

In the previous post, we considered availability and access of the web 2.0 workgroup productivity application. Today we'll look at software upgrades.

Like all software, Web 2.0 applications designed to support workgroup productivity will usually be regularly upgraded by the software vendor. How those upgrades affect you will likely be quite different depending on whether you are self-hosted or vendor-hosted.

In a self-hosted environment, you will be responsible for keeping track of software updates from the vendor, deciding when to upgrade the system, installing the upgrade, and so on. Is this a difficult process? As we saw with the installation, upgrades can vary greatly between applications, with some involving just the push of a button, and others a potentially complex and arcane process. Make sure you know which you're dealing with.

In a vendor-hosted environment on the other hand, it's almost universally the case that upgrades are automatically take care of, without any intervention on your part. Bugs will be fixed, features will be added, and the software will be improved, sometimes without you noticing. That the vendor manages this process is a big advantage of vendor-hosted applications.

But is there a downside to these automatic updates? Again, it depends on your usage of the system and how critical it can be. The last thing you need before a big customer demo is to find out the application has jumped to version 2.0 (codename "Lemon Penguin") with the entirely "new and improved" interface, rendering your carefully planned demo script worthless. If not having control of the timing of updates is a serious concern, you'll have to be careful with vendor-hosted applications. On the plus side, though vendor-hosted applications tend to have more updates, they tend to be much more incremental. Still, you may want to find out if the vendor's practice is to give advanced notice of any significant upgrades and when they will occur.

Next time: Disruption of Vendor's Business

Hosting Choices: Availability and Access.

In the previous post we talked about security. Today we'll consider availability and access.

Availability

As with any web application, if the server hosting the application isn't available, you can't use the application. This can be as a result of server downtime (planned, unplanned, hacker attack, corruption, etc.) or any of a number of issues between your web browser and the server.

If you're running the application self-hosted inside your own network, there are probably less points of failure than if you're running it outside, or running it vendor-hosted. As you control more of the pieces, you'll certainly have more control of getting things back up and running rather than waiting for the vendor to get things straightened out. On the other hand, its more likely that only you or a small number of people may be able to get things running in your group. If a vendor-hosted application goes down, it's highly likely that they will both be aware of it very quickly, and have the expertise (and hopefully redundant hardware if needed) on hand to address any problems quickly.

As always, you have to determine what the costs of not having the application available for a period of time would be, how likely downtimes are, and how possible downtimes can be managed. For vendor-hosted applications, look for service-level agreements, check out their past history, and see what their policy is for scheduled maintenance (is this something you will know about it ahead of time?). You probably can't influence their scheduled maintenance times (avoiding a particular hotspot where you need the service), but at least you want to know if it will be an issue.

For self-hosted applications, understand the limitations of your own resources and expertise, and know that for times where availability is critical, you can plan to ensure that staff are available who can correct any problems that arise. Unless there is a drastic change in how you're using the application, past experiences can be a fairly strong predictor. A possible area of concern for vendor-hosted applications, particularly those developed and maintained by startup companies, is the growth pains that can come from unpredictable use of their application. Because you're sharing their infrastructure with many others, this can very much affect how available (and responsive) their system is for you.

Access

An obvious consideration when it comes to where you should host is who will need access to the application server, and where they will need access from. Other things being equal, there's little advantage to a vendor-hosted application when access will strictly be from people within your own local network, hidden behind a firewall.

If access from "outside" is desireable, you again have to consider your own needs, resources and expertise. If remote access is needed, but will be used sparingly, and you already have solutions in place for similar circumstances (e.g. VPN to access mail and files), then you may want to use the same mechanisms for the application. If the predominant use of the application will be from people who are widely distributed, you'll need to consider if you already have the expertise and facilities to provide that in a self-hosted environment. A vendor-hosted application will by necessity be designed to operate with people using it from all over the world.

Access is obviously very strongly related to the security issued raised above. If there are particular security needs (e.g. logging all accesses) that a vendor-hosted application does not provide, this may trump the fact that a vendor-hosted solution could provide more robust access for your users.

Next time: Software Upgrades

Hosting Choices: Security

In the previous post we covered the issue of backups. Today we'll look at security.

Security is without a doubt a huge area, but here we're mainly concerned with what would happen if your company or workgroup's information was inadvertently made available to people who shouldn't have it, whether a result of a security bug in the application, a hacker attack, network sniffing, deliberate theft, or whatever. How will where your application is located (vendor-hosted or self-hosted) affect this?

This obviously depends on how important your data is to you and the consequences of it getting out. Some things you'd never want under any circumstances to escape your own network (or this may be mandated for whatever reason), in which case a vendor-hosted application is completely out of the question from the start. Normally though, its a balancing act. How well do you trust the vendor? If using a vendor-hosted application, would mandatory SSL use be required, and if so, is it an option? While you can expect a vendor-hosted setup would take certain precautions, its wise to check into their procedures, and if possible do some research into how they've done in the past. A large vendor-hosted site known to contain proprietary information may be a more compelling hacker target than a private site. Is the only access you plan to have from people inside a corporate firewall (or via a secure VPN), or will people need to access the application from a variety of locations? At the same time, for a self-hosted application, you need to consider your own security needs, knowledge, and ability to provide for them.

Managing security can be an extremely complex and difficult task. The more important your data, and the more important it stays private, the more attention you'll need to pay to this area. Where your application (and data) resides is a key piece of your overall security solution.

Next time: Availability and Access

Hosting Choices: Backups

In the previous post we looked at the issue of installation and startup. Today, we'll talk about backups.

As with any of your important data, backups need to be managed. If you're self-hosting your application, this is your responsibility and yours alone. If you're running other applications or otherwise holding your group's own data (e.g. on a file server you manage), you're probably already quite familiar with what's involved with doing regular backups. If you have someone else (e.g. your IT guys) doing backups of your data for you already, hopefully they can be encouraged/persuaded to add your application's data to their existing backup routine. You will also of course have to check to see if the application vendor has any specific requirements or procedures that need to be followed when performing backups.

If you're not already doing existing backups of other data, or not able to convince someone else to do it for you, its something you're going to have to figure out on your own. If this seems like a daunting task (which, given the tools available today, it normally shouldn't be) you may need to rethink running a self-hosted application, or at least that particular one.

On the other hand, if you're running a vendor-hosted application, there's a very good chance that the vendor is doing regular backups, and you'll have absolutely nothing to worry about. Right?

Not so fast. You should check the vendor's terms of service to ensure that backups are in fact done, and get the necessary answers about how often they are done, how long they are stored, the procedure you and they will follow if data is lost and needs to be restored from backup, and more. If those all work for you, great.

But even if everything they're doing meets your needs, do you really want to trust your important data to the vendor without doing your own backups as well?

Yes, even if a vendor-hosted application has a solid backup strategy in place that fits your needs, and certainly if it doesn't, you should be doing your own backups if your data is at all important to you. Remember, backups help you both in the case of data being lost because of some sort of system corruption, but also in the case where some of your data is inadvertently deleted by a user in the regular course of using the application. Your vendor may well be prepared for the first case, but are their backups going to be helpful in the second case, when you realize several weeks down the road something has gone missing that needs to be restored?

There are a number of things you need to determine from your vendor, beyond simply how often backups are done and how long they are stored for. Can you download all your data at anytime from the vendor's servers? Can this be automatically done? If data needs to be restored from your own backups (e.g. because of accidental deletion), is there a way that this can be handled? Finally, is the data that you can retrieve from the server helpful to you outside the context of the vendor-hosted application? We'll touch on this more in the next section.

Next time: Security

User Guides Updated.

From the "better late than never" department.... the user guides have been updated to cover all the latest features included in version 6.0. View the ProjectForum User's Guide or the CourseForum User's Guide (both are about 4MB PDF files).

Hosting Choices: Installation and Startup.

In the previous post we talked about why it's important to think about whether your web 2.0 workgroup productivity application should be self-hosted or vendor-hosted. Today's post looks at the first issue to consider when making this decision, installation and startup.

Installation and startup considers how long it takes from the time you decide to use a web application until its software is up and running, along with what expertise, hardware, software and other resources you need to get it running. Even though this is a one-time cost, and usually paid only by one person for support across the whole organization, it's a very important one. If you're at the stage of evaluating ten different tools, and each one takes two weeks and an army of consultants to get installed, well, you're not off to a great start.

Vendor-hosted applications generally win hands down here. The entire premise is that the vendor has done all the hard work installing everything, so that you (and all their other customers) can come along and just use it. Startup is usually no more lengthy or complex than visiting a web site and registering for an account.

When it comes to self-hosted applications, all generalizations fly out the window. Some applications are in fact very easy to install and get going, requiring no special skills, and can be up and running in minutes. Others, not so much. This is definitely an area where if you're considering self-hosted applications, you need to pay close attention. And needless to say, a vendor's claim of "easy to install" should be taken with a rather large grain of salt.

We'll use our ProjectForum wiki as an example of an application that really does make installation easy (we just told you not to trust vendors, so you may want to try it for yourself). When you download ProjectForum from our website (a fairly small 1-2 MB file) onto the machine you'd like to run it on, you get a single application, no DLL's, configuration files, or anything else. Run that application (e.g. double-click) and it starts up its own built-in webserver. Open your web browser and connect to that webserver, and you're up and running, ready to create your first wiki. It doesn't need to have anything else installed — no web server like Apache or IIS, no database like MySQL, no version control system, no particular system libraries, no editing configuration files, nothing.

On the other side of the coin are applications that have, let's just say, a few more prerequisites. While not pointing fingers, many open source applications suffer from this; some of them actually do a great job here, but in the vast majority of cases, it's almost like the programmer's behind them are demonstrating how amazingly cool their software is by how many other pieces it uses — more is better!

So what kinds of things might be needed before and during the install of an application? Code may need to be compiled. You may need to set up a particular database management system, and perhaps create some initial database tables. You may need other software, such as a version control system, or an entire virtual machine, that the application needs available. You may need to ensure you have a particular scripting language interpreter, and perhaps particular plugins, libraries or extensions that add features to the scripting language. All of which you'll need to find, download and install, if they're not already there, being careful that you get the right versions. And then of course there is the hand editing of application configuration files in your text editor before you can get it running.

The above list isn't at all contrived; you'll find many applications that will require you to do that — if you have the expertise, or are able to lean on expertise from your IT department or elsewhere. Luckily, most applications probably only require a few of the pieces noted above. And increasingly, some operating systems (e.g. Linux, recent versions of Mac OS X) come bundled with many of the prerequisites, although getting the right version may still sometimes be tricky.

Some vendors will instead ship you an "appliance", a preconfigured computer that you plug into your network, set an IP address, and that's all it takes to have their application up and running. It probably speaks to how complex their software is and how many dependencies and prerequisites it has that they need to do it this way rather than just shipping you the software, but purchasing such a dedicated box may well make sense in some situations.

Bottom line: particularly with self-hosted applications, you'll need to be very careful about installation and startup, factoring in the time, expertise and other resources needed, which may be either trivial or quite substantial. With vendor-hosted applications, you're almost guaranteed that this area will go smoothly.

Next time:Backups

Patch Version 6.0.3.

We've done some more fine-tuning of CourseForum and ProjectForum, and have updated our download site and hosting servers to version 6.0.3.

Primarily, this version trims off some HTML tags that were being added in the richtext editor by some web browsers. This usually just resulted in some excess verbiage in the underlying wiki markup for the page. We also added a couple small goodies. Full details in our changelog.

Office Closure.

Our business office will be closed February 25th to February 29th. We'd request your patience during this time, as responses to your emails etc. may be somewhat slower than usual.

Hosting Choices: Why It's Important

In the previous post, we talked about what web 2.0 workgroup productivity applications are. Today's post introduces the idea of where to host, and why this is a crucial decision to consider.

While users access these application with only their web browser, its important to remember that, despite the breathless hype and promises of sticking it to the man, at the end of the day there is a substantial chunk of software involved, and its all running on the server that everyone is pointing their browsers at. Our point here is that where that chunk of software is sitting is something you actually might want to spend some time to think about, before you dive head first into this whole Web 2.0 thing.

To greatly simplify, there are two places that software could sit. The first is on servers run by the software vendor, or some other company that buys the software from that vendor and hosts it for a pile of other people. The sexy buzzword for this is "Software as a Service" (SaaS); you're not really buying the software, you're just paying to use it for a certain period of time from their servers, most often for a monthly fee. Let's call this "vendor-hosted".

The second model is where the software is put on some server (or often, just any old computer, as long as its always on and has a network connection) that you or your workgroup have somewhere. Same deal as before for your users, they still use their web browser and point it a web site, but this time it's a web site under your control, and probably not shared with hundreds or thousands of others. Often this machine is placed inside a company firewall, but it need not be. Rather than a monthly fee, the software is often (again, not always) purchased up front for a larger amount, usually with some annual maintenance fees. We'll call this "self-hosted".

Which way do you choose? Sometimes the choice is made for you. For a couple of consultants whose entire IT infrastructure consists of a couple of hand-me-down laptops and the wireless connection at their local coffee shop, using that Web 2.0 app on the vendor's servers is the only way to go. For the corporate wage-slave with the "assertive" IT policies around his neck (if any data leaves our firewall, you will be drawn and quartered — in triplicate!) a self-hosted solution would be a prudent choice. Most people though, are somewhere in between, and if you're one of them, read on.

How this information can help you

You're thinking about a Web 2.0 productivity application for your workgroup, and could probably go with either a vendor-hosted or self-hosted one. Now what? Keep reading, and you'll get help with these four scenarios.

1. You've luckily found an application that could either be self-hosted, or vendor-hosted — which should you choose?
2. Two similar applications meet your needs, one self-hosted and one-vendor hosted — how exactly should that factor into your decision making process?
3. You're just starting to look for a solution, and want to narrow down your search — would self-hosted or vendor-hosted be the smarter place to start looking?
4. You're developing criterion to evaluate several applications — what are the important trouble-spots with respect to each hosting alternative to pay careful attention to?

Next time: Installation and startup

Hosting Choices: Web 2.0 Workgroup Productivity Applications

Over the next couple of weeks, we'll be putting together a series of posts that looks at the question of where to host so-called "web 2.0" workgroup productivity applications. These applications have opened a lot of doors for a lot of people and teams, and it's truly fantastic that you no longer need an IT department to take advantage of all the new generation of tools.

There's such a wide variety of tools these days, and there are a lot of things you should consider. Figuring out if you should be hosting things yourself or if you should go with a vendor-hosted solution is one of those things, and is not a trivial decision. This series of posts will touch on many aspects of this decision.

We're not exactly unbiased of course, because ProjectForum is exactly the sort of web 2.0 workgroup productivity application we're talking about. But because we offer both vendor-hosted and self-hosted options, we think we have a useful perspective on this issue.

Who this information is for

We've put this information together to help workgroups who think that some of this "Web 2.0" technology that everyone is talking about may possibly be helpful in getting their work done.

What is a workgroup? Any group of people working together on some common goal or project. Sure, that's a facetious answer, but think about all the different ways you can put people together that fit that description. A small business or SME as a whole might be a workgroup. So might a single department in a larger organization, or the ever-popular cross-functional business team. People from different organizations working on a joint venture certainly can constitute a workgroup. As can so-called "virtual teams" that come together for a specific project. Consultants and their clients often work closely together as a workgroup. And it doesn't just have to be commercial ventures; a group of volunteers at a non-profit or a group of teachers developing a shared learning resource are also examples of workgroups.

In most contexts this would just go without saying, but when we drift into the realm of "Web 2.0", it's worth being explicit. Here, we're talking about tools to help your group work together and share things, not the entire world. Many of the popular Web 2.0 applications are all about sharing with the entire world: think of photo sharing with Flickr, videos on YouTube, social bookmarking with del.icio.us, or a global encyclopedia like Wikipedia. These are all great tools, but not what we're talking about here. We're talking about your work being shared just within your group, not with everyone and their dog.

It's also worth saying that the work or information that your workgroup is thinking about putting into some kind of Web 2.0 tool is pretty important (at least to them), and probably also important that it stays private. Otherwise, why exactly are you worrying so much about what tool you want to use?

We're also not talking about people with a dedicated and always helpful IT team at their beck and call, that will get them anything they want, help to acquire it and keep everything going smoothly. Though if you have that (especially the "always helpful" part), congratulations. You still might not want to burden them, leaving them free for more complex work that demands their skills. These are tools that if you want to use, you and your team are going to have to figure it out on your own.

What exactly do we mean by Web 2.0 Productivity applications?

Simply, these are applications that clients run using only a web browser, just by going to a particular web site. By "productivity" we just mean we're worrying about tools to help get some kind of work done, like we described above, rather than games or pure social networking. Because these applications run in a network environment and many people use them, they often — but not always — take advantage of this by offering some aspects of collaboration or sharing.

A few examples: wikis, weblogs, group calendars, project and task management, CRM, chat rooms, database-like tools, file sharing, workflow, bug and issue tracking, and audio, video or web conferencing.

Applications running in a web browser have been around for a while, but the "2.0" part is newer. While older web apps were nice because users didn't have to install anything, they were in general more clunky to use. Now, using a bunch of technologies, collectively called "AJAX", that are available in newer web browsers, these applications can be a lot smoother and easier to use than they were before, somewhat closer to the interactivity and usability that people have been used to in desktop applications. This is what has generated the recent flood of interest and excitement.

Next time... why to consider hosting.

Q: Can the Category Template be changed to list the pages horizontally?

If you have enabled HTML formatting for the group, this can be done by inserting a small amount of CSS at the beginning of the page (or if you're using a custom theme, you could modify the stylesheet there). You can use the following:

===html===

<style  type="text/css">

.referenceslist li {display:inline;}

</style>

===html===

Making your Wiki Successful.

For those people wondering about how best to introduce your ProjectForum wiki to your workgroup, encouraging more and better use, or wondering why nobody really cares, there's a great web site you need to check out.

The site is wikipatterns.com. It contains a set of so-called "patterns" and "anti-patterns" — generally good (or generally bad) strategies and approaches that may be of help (or may hinder) your wiki's usage and adoption.

A book version of the site was also published a month or two ago.

Version Six Editing Tips

Thanks to Wayne MacPhail at w8nc, who has kindly let us share this information on the new editor he prepared for one of this clients using ProjectForum.

Originally, there was just one way to markup text for use in ProjectForum.

That was by using the simple markup language, you are all familiar with.

Later versions introduced a toolbar:

to add bold, italic, headline, underline and formatted list formats to our text.

We could even use it to add links to other wiki pages, websites or email addresses.

Now, with Version 6 of the ProjectForum software, we have a new way, called Rich Text Editing. Rich Text Editing allows you to create formatted text in ProjectForum much like you would when you use Microsoft Word or another word processor.

You also still have the option of using the older Source Code Editing you're used to.

Here's how to switch between the two.

If you look in the upper right-hand corner of any editing window, you'll now see a set of three icons beside the "Preview" text link:

In the image above, the editor is set to the Rich Text Editing mode. You can tell this because the icon has the <> symbol in it. To shift to the older Source Code Editing mode, just click on the icon circled in red above. The icon will now look like this:

And you'll be able to format text the way you have in the past. You can work in either mode, the choice is yours.

What's the advantage of the new Rich Text Editing?

Let's take a look. Here's a snapshot of text formatted and displayed using the old style, Source Code Editor:

and here's the same text as it appears when you're using the new Rich Text Editor:

As you can see, the Rich Text Editor version looks more like regular word processor text. So, it should be easier for you to enter and format text than using the old Source Code Editor.

You'll also notice that there are some additional icons in the tool bar at the top of the Rich Text Editor window.

You can now indent (and outdent) paragraphs you've formatted as ordered lists, using the new indent and outdent tools:

You must first convert a paragraph to an ordered list prior to using the indent or outdent tool. Here's an example:

• Line one
  
  • Line two
    
• Line three
  

In the example above I made a bulletted list (a form of ordered list) of Lines One, Two and Three. I then used the Indent tool to make Line Two a sub-bullet under Line One. You'll note that the line not only moved over to the right, but also gained a hollow bullet point automatically.

You'll also notice you have two more new icons, undo and redo, the curved blue arrow icons:

These allow you to easily undo, or redo the last change you made to the page.

Finally, there is the powerful table icon:

It's long been possible to make simple tables in ProjectForum, but it involved the careful use of | symbols as cell and row end dividers. Tables are much more powerful and easy using the Rich Text Editor. When you click on the table icon, now you'll see an empty, four-celled table inserted in your text. In the image below, I've filled each cell with some text.

Once your cursor is in your new table, you'll see that the table icon will have a new set of icons strung out to the right of it, as show here:

From left to right, these icons allow you to:

• Insert a column to the right of the column your cursor is in
  
• Insert a column to the left of the column your cursor is in
  
• Insert row beneath the row your cursor is in
  
• Insert a row above the row your cursor is in
  
• Delete a column
  
• Delete a row
  
• Left justify the text in a cell
  
• Centre the text in a cell
  
• Right justify the text in a cell
  
• Add a border to your table (the default state is no border)
  

Q: How can I print multiple pages?

Beyond the obvious "print the first page, then the second..." of course. There is a markup feature that lets you include other pages into the current page. So create a new page that you'll use for printouts, and include in it markup that looks like this:

[include:name of page 1]

[include:name of page 2]

Q: Will ProjectForum run on Windows Home Server?

We don't have any experience with Windows Home Server. There's nothing in ProjectForum that is specifically built to fit into the application environment it provides, but it's entirely possible that it still runs fine on the system.

Is there anyone out there who has WHS who has given ProjectForum a try?

Patch Version 6.0.2. Attention IE 6.0 Users!

We've just released a second patch release for ProjectForum/CourseForum 6.0.

We had some number of users, almost all using IE6, who were reporting a range of different problems. Most typically, the new editor failed to load, leaving raw HTML on the screen, or there was a problem with file uploads that stopped working. There were a few others as well.

It turns out these were all symptoms of the same problem, which turned out to be a bug in some versions of IE 6.0 SP1 (a bug where there's been a hotfix available for some time as it turns out, but most people wouldn't have applied it). You can read about the specific bug we were triggering in the Microsoft Knowledge Base.

Essentially, some versions of IE 6 had a problem downloading certain types of content that had been compressed. Our new editor consists of some fairly large Javascript files which the browser needs to download. Because of this, we added a feature where if the web browser asked for it (most do), we'd send these files compressed (gzipped), which is much faster. For those broken versions of IE, that meant the Javascript code that runs the editor (and other pieces) wasn't loaded, so those components didn't work.

In this patch release, we no longer serve the compressed Javascript files to any IE 6.0 browser, while still sending the compressed version to other web browsers. This seems to do the trick.

As well, we encountered one situation where these problems were happening on all browsers, not just versions of IE 6.0. We found in this case that their organization's firewall was set to block compressed Javascript files. Because some other sites may have similar issues, we've added a new option to disable sending compressed Javascript to any browser. You can find this new option on the main site administration page.

We'd recommend anyone who had users running IE6 who had these sorts of problems try out 6.0.2 to see if it helps. Downloads on the pages for ProjectForum or CourseForum. Our hosting sites have been updated to run the new version.

We could not have isolated and fixed this problem without the very generous help of a number of fantastic people in our user community who worked with us as we tried to narrow the problem down, and experimented with different potential solutions. To those people (you know who you are) - thanks so much!

Tip: Bug Reports

When you're running into problems or think you've found a bug in CourseForum or ProjectForum, we'd obviously like to hear about it.

When it comes to us tracking down and fixing the bug, the process generally involves us trying to duplicate the bug in our environment, which makes fixing it much easier. The more information we have from you, the more likely we are to be able to duplicate it. That's where your bug report is so important.

For starters, we want to know some basic things: what operating system are you running your server on, what operating system and web browser version are you running on your own machine, and so on.

Next, a description of what you're seeing, and how that is different than what you expected, is very helpful.

I was on such-and-such page at such-and-such time. Looking at the edit screen, I expected to see X, but instead I saw Y. I then tried to do operation A, and expected to see B as a result. Instead, I got C.

Screenshots that show the problem are also very helpful. On Windows, here is a web page that describes how to create and mail a screenshot. On Mac OS X, hit Command-Shift-3, which will save a picture of your entire screen to your desktop, which can then be attached to an email.

Web browser errors, particularly Javascript errors, can also be very useful to us. You'll find an item in the menus of most web browsers named "Error Console" or "Javascript Console" that will display any of these errors. For Internet Explorer, this page describes how to look for and view Javascript errors. In either case, sending us the full contents of the error message may be a big help.