Movable Type For Policies & Procedures
January 22, 2004 | 
13 Comments
I’ve had quite a few requests for details and screenshots of the hospital’s new Movable Type intranet. I’m going to do my best to fulfill those requests and to start off I’ll give you an overview of one of the more useful and innovative ways in which we leveraged Movable Type’s technology for our intranet — our Policies and Procedures pages.
Policies and Procedures make up a pretty large chunk of our intranet and cover everything from clinical issues to safety concerns to Human Resources. It’s a very commonly used section of the site that had some pretty big usability issues. In addition the maintenance of this section has always been a bit of a pain as it’s a load of regular work that, for the most part, would fall upon our Web team.
Over the last few years we’ve talked about some different solutions for revamping the Policies and Procedures section. We thought about using our recently retired CMS as it had a Policies and Procedures module, but that didn’t really fit our needs and was too damn hard to customize. We talked about rebuilding it ourselves and the possibility of having an outside Web development firm take a look at it.
None of these solutions got very far. Enter Movable Type, which enabled us to not only push the maintenance off to the folks who should be (and wanted) to do it, but allowed us to improve the functionality of the section for the users as well.
Here is how it works:
- We created a blog in MT called “Policies and Procedures.” We added our modified templates so that it fit into the look and feel of the intranet and at that point had a basic MT driven site.
- Next, we created categories for each of the sections that these documents would be grouped under. There are quite a few sections, some clinical and some administrative. We can use extra templates if we ever need to group them further.
- When a new policy is added to the section the administrator simply logs into MT and creates a new entry for the policy or procedure. They would assign a title to the policy and a primary category.
- An abstract of the policy is then created using the “Entry Body”. This gives a brief overview of the document and what is contained. This helps the user get an idea of what hey are looking at before they actually open the (usually Word) document.
- We use the “Entry Excerpt” to build a link to the document. The administrator simply types or pastes the document file name into the “Excerpt” field, uploads the document via the “Upload File” feature into a folder and MT does the rest.
- Lastly we use the “Keywords” field, not only to help our search engine provide relevant results, but also, by using the MTRelatedEntriesByKeyword plugin we can provide the user with a list of related policies on each policy detail page
So that’s how an administrator would create, or edit an entry. Pretty much like creating any other Movable Type entry only with a few twists. We also provide a K-Log with detailed instructions on how to do this as well as examples and the ability to submit questions or ask for help.
On the user end we provide a fairly detailed index page (view JPG screenshot) that lets the user view the most recently updated policies or browse down into a particular section by category.
As well on the category pages we use two similar MT templates to let the user sort the related policies by either title or date updated. A simple link in the table header switches the templates out.
On the detail page (view JPG screenshot) we list the title of the policy or procedure, the date it was updates and by whom, the abstract, keywords, the link to the actual file and related policies if any.
We also use a similar system to run our “Forms” pages, thus cleaning that section up as well and moving the maintenance off the Web team’s plates. You could use the same solution to power any kind of document library. It’s actually very straightforward, not a whole lot different from what I use here to power my “Quicklinks.”
Since everything on the intranet is connected it’s very easy to list related forms, policies or procedures within an actual department’s site. This gives us a central repository for these things while at the same time offers the departments a bit of flexibility in what they link to.
So, there you have it — using Movable Type to power a very large policies and procedures section — and it does it very well. It’s functional, flexible, somewhat scaleable and all in all better than any other solution we could think of. Any questions?
Filed under: Web Development
Comments
1. ste said:
Just one question. :) What about policies or procedures that might fall under a sub-category of a major category? Was this something you had to consider or did you luck out? This (the lack of sub-categories) is perhaps the one problem I had with MovableType for any sort of major organizational site … I’m sure there are ways around it, but I haven’t been able to figure one out yet. (Apart from simply creating categories with names like Category1, Category1_Subcategory1, Category1_Subcategory2, etc. and then adding relevant documents to all of the relevant category/subcategory possibilities - but this always seemed messier than necessary.)
All in all, though, you’ve now got me considering using MT for our intranet site here … though that’ll be a while in coming.
Posted on January 22, 2004 12:57 PM | #
2. Derek said:
ste, you could use the MTSubCategories plugin to add that functionality.
Posted on January 22, 2004 01:11 PM | #
3. Keith said:
Ste - We did used to have a few sub-categories and we had entertained some various options to keep those, but in the end they’re weren’t enough to warrant it. So we don’t use them now.
Some of them got rolled up into a parent category and some got broken out into their own category. We use the “Keywords” fields to tie together related policies in different categories.
Posted on January 22, 2004 01:13 PM | #
4. Keith said:
One more thing on sub-categories. We did explore using MTSubCategories as well and it would have worked very nicely had we felt it was something we needed to do.
We may explore that in the future as well, but for now there just weren’t enough to worry about it much.
Posted on January 22, 2004 01:51 PM | #
5. ste said:
Ah, excellent! I didn’t see that option when I searched mt-plugins last time I was researching this issue. Looks like my main concern has been solved! :D
Posted on January 22, 2004 02:27 PM | #
6. Martin said:
This is interesting.
I’m thinking of setting up something similar, but I’ve never used MT before (although I know a bit about it’s basic capabilities).
A few questions:
- is there an audit trail in MT, so that when people with administrator priviledges edit a document, the changes/user etc. can be logged?
- does MT include a facility keep a copy of previous document versions for change-control?
- how secure is the system?
Posted on January 26, 2004 01:44 PM | #
7. Keith said:
Martin, I’ll give a shot at answering your questions as best I can. There are a few areas that aren’t really a big concern with our particular implementation but we have touched on them.
There is no real audit trail, you can set it up so that someone can just post in draft mode, having an editor or someone review all posts before they go live. It doesn’t log changes.
There is no version control with documents or entries. However you can set it up to work with something like VSS on the back end. There would be some manual process involved but this is something I do at the hospital. Pretty much have MT build the pages and then check them into VSS.
As far as security, I think it depends on how you set it up but it’s fairly secure and MT plays well with other systems so I imagine that if you needed to you could implement further security.
Posted on January 26, 2004 02:31 PM | #
8. Mike said:
It’s probably too late for this suggestion, but maybe on a future project you would consider putting a ‘Wiki’ site in for this type of application. I think a Wiki is a better fit.
A Wiki allows for a self-organizing site that is editable in the browser, and some of the better Wiki engines let you create sub-Wikis. Edits are usually diffferenced as well, so you can see the changes to a given document over time. Links between Wiki pages are very easy for end-users to create, and there’s no overt date-oriented organization - it’s more web-like than a blog.
The only problem I’ve seen with Wikis is that most of them are not very stylable - Wikis grew up in the software world, and software developers are notorious for not caring much about appearance (for good reason, usually). TWiki is probably the best one in all categories. It’s written in Perl.
All FWIW.
later…
Posted on January 27, 2004 09:32 AM | #
9. JC said:
Mike… I know my CEO would just love it if our low level employees could edit the corporate policy manual that the SEC reviews.
Wikis have their place… corporate policy manuals definitely are *not* it.
Keith, I’m interested in this project, but I’d be concerned about rollbacks and auditing and so forth. I gave using a blog or portal type solution some thought, but decided against it.
Right now, we’ve dumped the “Transit Solutions” product in favor of giving each user who needs it a copy of Macromedia Contribute (much less expensive than the Transit maintenance). It has rollback, and review-before-posting (which unfortunately does not prevent someone from publishing just yet), and FlashPaper.
Flashpaper is a huge selling point to me – it installs as a printer driver and lets you essentially convert anything that can be printed into a flash file with what looks like a stripped down PDF interface… you can blow it up big, make it tiny, scroll, and print it quite nicely. That’s great when we find things like forms that have to be reproduced exactly and need to be printable with good quality.
The primary drawback so far with contribute is that it requires the user to build navigation (something Transit did automatically). I’ve gotten around that in a couple of instances by using CFDirectory to build a list of files and parsing out link names based on their file names, or in one case actually parsing the files nightly (or on the editor’s request), dumping the page title and the ‘teaser’ text into a database to build the TOC from.
This is something MT would probably handle better, though, especially when you have multiple pages (it builds previous and next links automatically, right? I know WordPress does…). Is there a way to get around the date sorting though? Would you just use a page that had nothing but the category list and nix the usual latest x entries?
Posted on January 29, 2004 02:09 PM | #
10. jazer said:
Why didn’t you enter the policy itself as the entry body? Why bother with linking to another document? HTML is a perfectly useful way of presenting textual information on the web – I don’t understand why you should force people to deal with MS Word if not necessary.
Posted on February 6, 2004 11:22 AM | #
11. Keith said:
Jazer – it’s not us that is forcing the use of Word. It’s the people who own and create the policy. Don’t take offense, but I tend to doubt you’ve ever worked with this kind of thing, and if you have and were able to asert that ammount of control, you’re really lucky!
The thing is they don’t know HTML, and don’t see it as secure as a protected Word doc. They could be right. Many of these policies are very important and until they change their source we’re stuck with whatever they want to use.
Not to mention, the folks who work with this stuff are very attached to their way of doing things. Trust me, if we could go to an HTML source we would.
Posted on February 6, 2004 11:44 AM | #
12. Sian said:
My employers have just introduced a CMS system (I believe its a Microsoft product), it’s very interesting to see the thought process behind the CMS setup now at my disposal.
I’ve also setup MT to help with the running of the Dowlais Forum website and this has really made me sit up and think of the possibilities.
Thank you for sharing.
Posted on February 15, 2004 04:21 AM | #
13. Tim Duckett said:
Really useful information, thanks.
One other question, though - you’ve got great google-friendly URLs for your archive postings (and I notice that there’s PHP running somewhere). How did you do this??
Posted on April 18, 2004 08:11 AM | #
Comments are now closed