What (web) application should I use to create and maintain a multilingual operations manual for a restaurant chain?

January 10, 2008 5:58 AM

What (web) application should I use to create and maintain a multilingual operations manual for a restaurant chain?

I run a chain of fast-food restaurants, and we'd like to consolidate all the info we have about running the place into an operations manual.

- It needs to be online, and also easy to print
- Various people need to be able to update it (and attach photos, etc to it)
- It needs to be secure, since only qualified people are supposed to see it. Preferably we could decide the levels each user is able to see.
- We need to be able to adjust the look of the web and print version
- The exact same manual needs to be updated in a number of languages
- We'd also like to be able to store things like images, forms, etc within the same system so it's easy to retrieve (for example, a page about specific equipment should also contain a link to the users manual for that equipment, stored on our servers).

I've looked into Drupal, but I'm a little unsure whether that's the right system and I'd like to be sure about everything before I put more information into one system. Maybe I can buy help with setting up the Drupal structure and look somewhere?

Any ideas?

posted by einarorn to computers & internet (11 comments total)

I have worked as a content management system consultant. I would recommend that you get up and going in a simple, free wiki system like MediaWiki, the software that runs Wikipedia. If you find that it doesn't fit your purposes you'll have more exact understanding of precisely what functionality you need. The existing wiki content should be fairly easy to transfer to a new system.

MediaWiki actually does multi-lingual content better than many content management systems do. Also, I hate to tell you but precise control of print layout and web content basically don't mix. I don't know exactly what you need to adjust in the print version but you won't really be able to affect much more than what you already get control of when you print something from your web browser.

If you were going to spend money I think you'd do better to spend it on web design help that can get the appearance of the web content looking more like what you want in a way that would be compatible with any web-based solution. But again I'd recommend that you get something like the wiki up and going and get your content in shape and usable before you spend money or effort trying to tune it to be exactly the way you want.
posted by XMLicious at 6:43 AM on January 10, 2008

You might consider TWiki. TWiki is open source, but you can get a certified version that includes support. It's intended for use as a corporate wiki and can replace an intranet, so it might be more flexible than MediaWiki.

I've been using the open-source version with no support for a few months now. It took an advanced geek about two hours to install on my site's Linux server and customize it a bit; it took me several more hours to continue the customization. But now that it's up and running, I can say it's easy to use and will probably do what you need.

You have very detailed control over who can see or change what in the system. For example, you can have an area that everyone can see but only a few people can change, a different area that only a few people can see, and so forth. You can also set access permissions for individual pages, so there could be "hidden" pages that only admins can see in among the pages that everyone else can see.

I'm not familiar with TWiki's multi-language support. It does have a way to automatically translate text into several languages, so someone who speaks Spanish could look at a wiki page that was written in English but see it in Spanish. However, automatic translation is pretty weak in any system. It would, however, mean that you needed to maintain only one version of the materials.

Uploading images, forms, etc. is easy--you "attach" them to a page in the wiki, no FTPing required. You could also FTP content to the server and just include a link to it in the wiki.

You can separately customize how a page looks online vs. how it looks printed. You use CSS for both, so your print layout options are limited to what you can do with CSS that's printed through a web browser.

You can also have different "looks" to the interface depending on who is looking. For example, I have an "advanced user" view and a "simple" view that shows fewer options.
posted by PatoPata at 6:56 AM on January 10, 2008

Drupal could certainly work. There are several modules for maintaining multilingual content. And it has very fine-grained permissions for as many user roles as you want. On-screen appearance would be controlled through a theme; print appearance through a print stylesheet.

Most of the above also goes for MediaWiki (though I'm not sure about the fine-grained permissions). I've spent less time fooling around with MediaWiki but it seems to me that administration requires more geekiness.

There are a lot of web developers that specialize in Drupal. I'd recommend posting a request to the Drupal paid services board. Before doing so, think through your requirements very thoroughly. A good developer bidding on this project will want as many details upfront as possible.

Again, I'm sure other CMSs would work, and have developer communities surrounding them. One benefit to Drupal is that it's fairly popular, so it's easy to find a developer.
posted by adamrice at 7:55 AM on January 10, 2008

I think a wiki is a bad choice for this, as wikis do not typically allow for theming elements, and are geared towards an 'everyone-can-edit' model. What you want sounds like more of a case where you are going to have an editor delivering content to users.

Much as I hate Drupal (because I've worked with -- well, against -- it every day for the past six months), it is a reasonable choice for this application. You WILL need development help. The rule with Drupal is whenever you want it to do anything it isn't competent at out of the box (being a multi-user blog is pretty much its only core competency) you need a developer. As adamrice mentioned, Drupal has done a lot of internationalization (i18n) work (especially in drupal 6, which is a release candidate now and almost out officially): this basically means that you'll probably only have to do translations on things that re-appear once, and menu items/etc will largely have their translations handled for you.

There are a lot of web developers 'specializing' in Drupal; and although I think their competency may be questionable (there's a lot of really poorly put together third-party modules) you're not asking for anything too difficult. Most consultants will probably run from $60-100/hour. You can't really hire a 'regular' PHP developer to develop in Drupal because it'll take them at least a month or two to come up to speed on the Drupal framework (which isn't terrible once you get used to it).

As adamrice mentions, you are going to need a much more solid spec than what has been included in this question to get good development work.

If this is a no-budget project and needs to be done by in-house folk without development experience, a wiki may still be your best bet.
posted by fishfucker at 8:42 AM on January 10, 2008

Thanks for the answers. I didn't want to put too much detail into the post.

Fishfucker is right to assume that this is mostly content generated by an editor delivered to users. I assume maybe 3-4 people are going to contribute most of the stuff. Then after the main content is up then some users will be allowed to change things around, and adapt some pages (for example some restaurants have different equipment so restaurant managers may want to change that info for their particular restaurant).

Also, I would then get a translating service to go into the original manual to make copies for other languages.
posted by einarorn at 9:16 AM on January 10, 2008

The reason why I recommend going with something off-the-shelf and hitting the ground running, get some solid content together, then fancying it up later on, is that CMS implementation projects tend to balloon into enormous white elephants. Especially ones where you go and hire an outside developer.

If you get a wiki set up, get some straight web pages going with Dreamweaver, or anything else that you can do yourself with internal resources, and get some usable web content going first, then when you approach a developer or consultant or web design firm you don't have to work through wireframes or written specifications; as part of the bidding process they can actually throw some of the existing content into an out-of-the-box Drupal shell, for example (or whatever CMS they're comfortable with) and show you how it's going to work and what it's going to be like to use once they do the migration.

If you're going to have an outside firm do lots of work on this it's better to pick a reputable and otherwise-successful firm, let them use whatever system they're comfortable with, and have them show you example sites / a portfolio of their work, than to pick one on your own and proceed on the basis of finding someone local who works with it. Some firms may do work in multiple systems. You don't have to accept their choice if you don't like the interface or don't like their quote, I'm just saying let them lead as far as choice of the software. For anything that's not a $50k+ implementation project, in my experience the familiarity and comfort of the contractor with the system they're working in is more important to a satisfying outcome than the virtues of the CMS software itself.

Also, if you do go with something that will require substantial outside work (or if later on as you dig into the project you realize it's going to require substantial outside work) back off, put together some solid requirements, and set up a bidding process among several firms. Also remember to think about ongoing maintenance; a well-managed, successful contractor (which is the kind you want working for you) is going to call you up and try to persuade you to hire them to upgrade you to Drupal 7 when it comes out, for example.

For requirements-gathering and implementation advice on content management systems there's an immense amount of material available online. Too much, probably, but that's because it's a substantial endeavor.

----

On preview, since you're having a translation service do the translation, and from the rest of your description you're going to be having the English content updated continuously, you need to think about how frequently and in what situations you're going to be having the English re-translated.

Check out all of your costs first. Depending on how things work out you may actually want to let the translation service, rather than the web contractor, choose the software. Your initial and ongoing translation costs might actually be the most expensive thing here.
posted by XMLicious at 9:25 AM on January 10, 2008

To explain a bit more on the translation front, translation companies have tools that automatically show them where the original content has changed, allow them to deal only with the straight text by removing and re-adding HTML tags, "translation memory" features that re-translate unusual phrases the same way those phrases have been translated before, and a host of other features. If a CMS can automatically export content to and import content from their translation tools they usually charge less than they would if their translators have to learn how to log in to and use an unfamiliar system where they can't use their tools, even a system with an easy-to-use interface.
posted by XMLicious at 9:34 AM on January 10, 2008

Thanks, XMLicious. My plan was originally to try to put together some basic structure by myself before I would get any outside help. I guess I was looking into whether Drupal was a system I could use for that, or if I should look at other choices.

I guess a follow-up question would then be whether it should be easy to export stuff from Drupal into other CMS systems?
posted by einarorn at 10:34 AM on January 10, 2008

Moving between a wiki and a CMS or between different CMSes usually requires lots of cutting and pasting and reworking links. That can be labor-intensive but it's the kind of thing you can usually hire intern-type people or high school students to do, which as a restauranteur you must have in abundance.

If you feel that you or your in-house staff can set up Drupal, or that you can do so cheaply with an outside resource, I'd say go for it.
posted by XMLicious at 10:55 AM on January 10, 2008

I guess a follow-up question would then be whether it should be easy to export stuff from Drupal into other CMS systems?

That's a potentially hard question to quantify. If you use a straight-forward drupal node (ie, text + body, no special fields), then scripting a dump in, say, XML, would be easy-peasy -- if you have a bunch of special functionality and node types, you're going to have trouble. If you plan on porting the data, keep everything as simple as possible. I'd also recommend avoiding the use of CCK, because it builds really terrible (imo) data structures which you'll have to deal with down the road. Importing would be yet another issue -- I'm not aware of any 'imports' for Drupal, so I doubt they exist for the other big open source players in the field. Portability is usually more in the scope of CMSes designed for blogging (wordpress, movable type) because a blog post is such a simple piece of content.

At a minimum, I'd say you should expect to need a developer's help to export content from Drupal.

Also, XMLicious's advice is very good, especially the bit about just turning over the whole mess to a developer and letting them sort out their solution. Deciding what CMS (if any) is appropriate for a particular spec is really a job that should be done by developer. Your job is to provide the clearest specification possible. Doing a small in-house project with a wiki or even static pages will help you solve some of user interaction problems and, more importantly, help you decide exactly what you want without paying $100 an hour for someone else to figure it out (and possibly get it wrong).
posted by fishfucker at 1:10 PM on January 10, 2008

Maybe you should look into AuthorIT¹. However, if you decide to go that way, do try to get your hands on version 4.5 rather than 5². Also get a certified consultant (IANACC) to set up your templates, migrate any existing content and train the people who are going to have to use the system. But once you've got it all set up, it's very likely smooth sailing for you from there on (provided you stick with 4.5).

Using this tool you can easily reuse content in different formats and outputs. Not just print, web etc. but it's also really easy to reuse the content each of your individual restaurants have in common and for them to then add (and maintain) their own as needed.

It handles text, images of any format and files created and maintained in other applications. It's built to enable you to have different image formats or text and layout styles for depending on its output, for example, a good quality image for print and a lower, less bandwidth-consuming version for your website.

The same applies to look-and-feel: each restaurant can have their own style, even if applied to content that is shared by other restaurants.

The content is stored in a database, so as long as people have access to your DB server it doesn't matter where they are located.

It provides a very easy-to-use editor. Once people have had some training, they can make all text and structure changes themselves. Style changes they might be able to do as well, but you may want to leave that to a professional designer.

You can control who is allowed to do or view what: you can allow some users to make esthetic changes and prevent others from ruining your carefully designed look-and-feel.

It also has a component specifically designed to handle localisation as efficiently as possible, so you can provide your translator with new or changed content only and easily port the translations back into the system. But I haven't worked with the localisation manager myself so I don't know how easy and efficient it really is.

Hope this helps, if anything, to put the pros and cons of off-the-shelf, custom and semi-custom made solutions for your specific requirements in perspective.

^{1 - I do not work for or get paid by Author-it Software Corporation Ltd. See also note 2.
2 - As a professional, day-to-day user of this product I am disappointed in the latest major release and will steer clear of it as long as I can. AIT 5 is one bug-riddled, bloated, inefficient and all-round crap product, so buyer beware! I love 4.5 despite its little bugs and annoyances, but I am heartbroken (yes, heartbroken!) that they fucked up so badly in 5. Being in the software industry myself I understand how this can happen; my only hope is that they'll redeem themselves with the next major release.}

posted by l'esprit d'escalier at 1:38 AM on January 11, 2008