Home| About| Contact| Client’s login| Services

Web-based application screenshots

This page contains screenshots from various web-based applications that we've built over the years. We've reproduced the screens here because most of these applications are password-protected and access to them is limited by the company we worked for. But at least you’ll get an idea of what we can do with a text editor, Photoshop, and a wad of chewing gum. :)

^ top

The Project Management Office

The Project Management Office (PMO) was designed to help project managers (PMs) communicate with team members, particularly when the team members were employed by the client. It included various web applications, including a calendar, a message-of-the-day scrolling marquee, an issues tracker, an "Explorer-like" left-hand navigation tree, and an "e-drive" for sharing documents (pictured above).

Best of all, the PMO was flexible enough so that if a client wanted some extra functionality, we could plug it into the application without affecting the other clients, which gave the sales people just one more way to sweeten the deal -- without sending us through the roof. You'll fnid this same sort of modularity in today's popular web applications such as PHP-Nuke.

Other PMO screenshots

(Some of the screenshots are large and will take time to download)

• Contact Center -- One of the most popular features (some PMs wanted a PMO site set up just for this function), the Contact Center allowed PMs to easily update team members' phones and emails. Most of the PMs kept the list in an Excel spreadsheet, saved it out as an web page, and then uploaded the latest version to the PMO. There was no intervention on my part for that process (except, of course, when the PMs tried to get fancy and embedded images or organization charts into the contact list).
• E-drive -- Allows people to upload and download files, all displayed in a familiar Windows-like interface
• Issue Tracker -- PMs can add issues, assign them to team members, print a status report, resolve and close an issue
• User Management Interface -- PMs can easily add users: all they need for a user is a full name and an email address. If the PM doesn't want to have to make up passwords, the system will do it for him/her. I did this after seeing the PMs add multiple users with the same password. And what you don't see here is a administrators' interface that would batch import users from an Excel spreadsheet, which took some of the burden off the PMs to deal with the interface.

^ top

The Knowledge Management System

There's a reason why the KMS looks a lot like the Project Management Office, and that's because when we started building the KMS, the only platform our client would give us was the PMO. The KMS started out as a "project" inside the PMO (remember the part about being able to plug in applications to the PMO without too much trouble?).

The KMS had some extra functionality, mainly being that users could upload documents to a repository and tag them with regional information, document types (presentation, white paper, etc), industry and service line, for example (see the Add Document screenshot for details). Users could narrow down a search to return only documents relating to a specific industry, as well as search for text in the document.

Since we didn't have access to a powerful enough database to serve up binary files, we had to go with Microsoft's Indexing Server. The upshot: the only documents we could sucessfully tag and store were Office docs (Word, Excel, PowerPoint) and Adobe PDFs. Anything else had to fit inside a Word document (like a GIF, for instance, could be placed inside a Word document).

Other KMS screenshots

(Some of the screenshots are large and will take time to download)

• Search -- The search user interface was modeled after the GroupWise advanced search, which I reasoned would be familiar to our users since GroupWise was the corporate email client.
• Search results -- The search results page had a few little features to it, including the ability to download the file as well as view it in an Internet Explorer browser simply by clicking on the icon.
• Search help -- The KMS was both blessed and cursed by its search functions. Blessed because they were so powerful; cursed because the users were mostly sales people, who -- and let's be honest about it -- weren't always hired for their intellectual prowess. So it was crucial that users could contact a person (usually the company's "knowledge manager") at any point during the searching process and ask for help. Another technique we used: if the search returned no documents or resulted in a error condition, both the company's knowledge manager was automatically notified via email, so no matter what time zone the user was in, she could respond with an offer to help out.

^ top

Web Folders application

We put together the Web Folders application several years after building the "e-drive" on the PMO, partly out of frustration for the e-drive's shortcomings. For instance, there was no way to impose an access level to a particular file or folder. And people got inconsistent results when downloading the file: I could never quite predict whether the file would open up in the browser or the user could save it out to the local disk. This problem in particular caused many problems with users who opened up the file inside the browser, because they would invariably make changes to the file, save it, and assume that it had been updated on the server.

So in the Web Folders application, as it came to be known, we fixed those problems. We sent it up so that each folder had four levels of access: No access, read-only, read-write, and administrative. In addition, the access rights were based on NTFS permissions, NT's native file-permissions, and not something homegrown, as the PMO was. We reasoned that it such a measure would greatly improve security.

But we didn't want users to have to get an MCSE just to have to use this application. So we limited the granularity of access levels to folders and groups only. You couldn't set permissions on just a single file, and you had to create groups of users for each access levels. We figured we might as well use NT groups, and that meant we had to create an interface for creating and editing a group.

Other Web Folder and Group Administration screenshots

(Some of the screenshots are large and will take time to download)

• Three views of the Web Folders -- You're looking at the application as a manager of the folder. That means not only can you add and update files, but you can create new folders and decide who gets to look at these files and folders. A couple of features to note: The navigation bar at the top, so you can always see where you are in the directory tree (in this example, it's a top-level folder called "Recruiting"). Another feature: The information in the gray box is actually the contents of the "readme.htm" file, which you can see is listed last. This was one of the biggest selling points for this application, because each department could attach some introductory material to each directory, which could be easily written in Microsoft Word and saved as an HTM file.
  • Top view -- basically, the read-only view.
  • Middle view -- Unfortunately, I couldn't get the screenshots just right. What I would have done here is show just the "read-write" view, which would have ended with the section marked "Upload files and create folders."
  • Bottom view -- Administrators could decide who had access to each folder; they could add groups of users to the read-only acess, the read-write access, or delegate adminstrative access to a group of users.
• Four view of the Groups Administration interface. From here, you could create NT groups, add and delete users, and delegate group ownership to other users.
  • List groups -- Lists groups for which you are listed as an owner.
  • Add a group -- when you create a group, you automatically become an owner.
  • Edit a group -- Add members, edit the group description.
  • Delegate ownership -- Delegate group ownership to another user.

^ top

Technology Outages application

The outages system started out as a quick way to let users know about system outages, both planned and unplanned. With a minimum of fuss, IT/IS staff could quickly enter alert users -- and quick was important, because I didn't want to make them spend 5 minutes typing in order to alert users that the Financial Project Management system was hung up (alerting users would be the last thing on their minds at the time -- can't they tell the darn thing isn't working?)

You might look at the outages system and think that it's just a not much to write home about. Oh sure, it sends email alerting certain people of outages and it's got a nifty date picker (courtesy of some freebie Javascript application I found), but in the end, it's just entering information into a database table. I'd say it's a bit more than that, because it's the cumulation of much of my programming efforts. It uses pre-written libraries and a methodolgy for validating data. Heck, it's a close to object-oriented programming using a scripting language as I'm ever going to get.

Other outages system screenshots

(Some of the screenshots are large and will take time to download)

• Home Page Notification -- A quickie insert into the home page of the intranet that displays the most imminent outages.
• List outages -- An administrator's page list outages, which then can be deleted or edited.
• Edit Outage -- Entering a date on a web page can be the bane of a developer's existence. Either it's too darn complicated, like having three list boxes for month, day and year, or it's too amorphous, like having a text entry field and hoping the user will pay heed to hints such as "MM-DD-YYYY." I prefer to mix both methods: The outages system allows users to use the pop-up date picker, which always formats the date correctly, or a text entry field that makes use of the myriad date parsing routines out there that'll take just about any nearly correctly formatted date. That's what you'll see in this screen shot.