Monthly Archives: February 2009

Well, I’ve been sitting on this adaptation of my Broadway Plogger theme for too long. It hasn’t been fully tested, but it seems to work. It’s a dark theme that uses the popular Lightbox 2 JavaScript script to open medium-sized images over the thumbnails page. This means that there is no getting to the full-sized image.

Plogger 3 theme: Broadway screenshot

Anyway, if you’ve been looking for a Lightbox 2 supporting Plogger theme, please give this one a try.

Download the “Broadway 2 + Lightbox” Plogger theme

Update 12/19/09: I’ve updated the theme to be compatible with the recently-released Plogger v.1.0. If you’re running an earlier version, I would recommend that you update to the current stable release.

Update 7.2.10: Since this post, CARM has developed a new, more usable interface that improves the user’s ability to construct an adequately narrow search. Improvements to the database mean that searches of non-indexed fields are much more likely to successfully complete, rather than time-out.
CARM still has a long way to go before finding an email in the repository is as slick a process as finding one in any web app or client, but it’s much better.

Filesurf, which was rebranded CA Records Manager and goes by CARM, is an electronic records management system by CA, originally developed by MDY. According to the official product write-up:

It is a product that manages, controls and discovers physical, electronic and email records via a single policy engine to become the policy authority for enterprise information. It reduces end-user burden and administrative overhead while providing comprehensive life cycle management of your corporate knowledge assets across your enterprise content silos.

The laughable part of that description is that it reduces end-user burden. In my experience, it creates a huge amount of confusion, frustration and resentment in the end-users. I’ll get to that in a bit.

My firm uses Filesurf (we don’t call it CA Records Manager or CARM, yet) in large part to archive email messages which can then be deleted from the mail system. It creates copies of email messages, stores them in an archive, and provides a web-based method of locating these messages.

That sounds like a very useful thing to have, and your company may be tempted to use Filesurf to archive and later access its email. But Filesurf is a shockingly miserable, ugly and brutish piece of software to work with.

As someone who appreciates the difficulty of developing usable, intuitive web-based application interfaces, I feel totally justified in saying this thing’s front-end is a jaw-droppingly awful bit of programming. The laziness of the interface engineers permeates every page and error message.

The search functions are primitive, frustrating, and time-consuming. Locating specific emails is very much like finding a needle in a haystack. Glaring limitations of the web-based interface prevent effective narrowing of search results.

For example, it’s possible to narrow a search by sender, and it’s possible to run a full-text search on the body of the email, but you can’t do both at the same time. They’re actually on two different web pages. You can’t even do one and then apply the other to the results as a filter. Why on earth can’t CA combine these two search functions? Any web programmer who has ever worked with a database could do this in a matter of minutes. I’ve personally written much more complicated database search queries in PHP.

The results appear as a list ordered by date sent and are not sortable.

Searching Filesurf: A case study

Today I was tasked with helping a user locate an email attachment. The user knew who sent the email, what the attachment was named, and where the email had been located in the mail system before being archived. The user also had some idea about when the email was sent. That’s a lot to go on. Unfortunately, Filesurf is so poorly designed that much of that information can’t be used as search criteria.

To begin with, it isn’t obvious that Filesurf can handle date ranges – there is only a single input field for date. You can’t search for attachment file names, or limit results by attachment type, or even just by whether an email has an attachment. If users typically forward emails ‘as attachment’, they can’t be differentiated from Word, PDF, or image file attachments.

So what usable criteria are we left with? Just the sender and the folder from which the email was archived, or the “source path”. In this case, sender doesn’t further limit the results from the source path search. So while the user has four different bits of information about the archived item, only two of them are usable, but from the interface, it appears only one of them is usable.

After performing the search, I was left looking at a list of hundreds of emails, maybe a third to half of which have attachments. I can view the details of each email, but attachments do not show up in the details screen. To view the attachment names, I have to open each email and look at the attachments.

If you are considering CA MDY FileSurf, I strongly recommend having someone on your staff who can devote many long hours to nothing but wrestling with the horrendous search function – sifting through hundreds of irrelevant results that should never have been returned in the first place.

I was installing PHP 5 on an IIS 6 server when I ran into what turns out to be a pretty common problem. PHP appeared to be installed correctly, but browsing to any page with a .php extension returned a 404 Page Not Found error. While the steps below fixed this for me, I had to piece them together from a few different sources, and a number of other suggestions (like copying the php.ini file to C:/WINDOWS/) didn’t work and were not necessary.

Open your IIS management console at C:\WINDOWS\system32\inetsrv\iis.msc.
Drill down to your web site, right-click and select Properties.
Select the Home Directory tab, then click on the Configuration button.
Select the Mappings tab. If you don’t see a .php extension listed, click the Add button. Browse to the PHP 5 DLL (which may be at C:\Program Files\PHP\php5isapi.dll). Type .php into the Extension field and leave everything else at the default values. Click OK. The extension and executable path will be filled out and under Verbs you should see “All”.

I should point out that I didn’t have anything listed under the ISAPI Filters tab.

Stop and restart your IIS server and browse to a .php file. (To restart your IIS server, open the IIS management console, right-click the local computer in the left pane, hover on All Tasks and choose Restart IIS.) Chances are, you’re no longer getting the 404 error, but are now seeing a 403.1 message, like:

The page cannot be displayed
You have attempted to execute a CGI, ISAPI, or other executable program from a directory that does not allow programs to be executed.

Please try the following:

* Contact the Web site administrator if you believe this directory should allow execute access.

HTTP Error 403.1 – Forbidden: Execute access is denied.
Internet Information Services (IIS)

Open iis.msc again, go back to the Home Directory tab, and select the “Scripts only” option from the Execute Permissions menu. Restart the server.

The server should now be correctly processing .php files.