TicketDesk - Design Philosophies Explained

It has been just over a year since I introduced TicketDesk over at CodePlex. While it hasn't taken the world by storm or anything, it did generate a lot more interest than I would have expected. There are several companies using TicketDesk in production environments, and there have been a few thousand downloads from other people that may be using it too.

While TicketDesk isn't generating the kind of download numbers that I'd want to base a software startup on, for an open source project it is what you might call "wildly successful".

If there was a major failure on my part with bringing TicketDesk to the public, it would be that I didn't do a good job explaining the ideas behind the overall design. So let me take a stab at explaining the philosophy behind TicketDesk.

The general idea behind TicketDesk was to take my 15 years or so of experience, much of it spent being frustrated by help desk issue trackers, and use that experience to design a different kind of help desk system; one that avoids those problems.

And believe me, I have a very long list of complaints with help desk systems!

I suppose the best way to explain it is to discuss the fundamental design idea then illustrate how TicketDesk implements them.

TicketDesk is an issue tracker for help desks... and that is all:

The help desk at most organizations will have many considerations aside from issue tracking. There are internal rank structures, chains of command, political issues, business practices, and financial considerations of all kinds. Unfortunately, the help desk is deeply involved in all of these things.

The mission of TicketDesk is to allow the help desk keep track of issues, and that is all it does.

• TicketDesk does not attempt to understand your org chart.


• It doesn't recognize user rank, status, or departmental affiliations.


• It doesn't act as a time tracker.


• It doesn't do billing.


• It doesn't do project management.


• It doesn't manage your inventory.


• It doesn't handle your business process.


• It doesn't do inner-departmental accounting.


• And it absolutely does NOT care about your internal politics.

TicketDesk is made for internal help desks:

TicketDesk was designed exclusively for use by help desks supporting users within the same organization. It assumes there is a decent level of trust between all participants.

TicketDesk can be used in other environments, and there are plans for future versions to better enable external user scenarios.

You should carefully evaluate TicketDesk's features before attempting to use it in a customer-facing capacity. Also, you may find the features insufficient for organizations performing contracted support for users external to your organization.

Have as few data fields as possible for any given ticket:

This the most basic design ideas behind TicketDesk.

In most help desk systems there are just too many fields, and few of them turn out to be useful. During planning management is hyped-up about the advantages all those fields will bring, but it doesn't take long for the staff to learn that the free-text description field is the only reliable source of information (and even that is a dubious assumption).

So I've spent a lot of time thinking about the various fields common to similar systems.

There are many reasons why different fields fail, but it boils down to just three overall trends:

1. The fields may not relate to the user's specific problem. For example, Questions like what OS are you using aren't useful when the user is reporting a problem with their phone.


2. The end user is incapable of answering some questions. It isn't their fault, they aren't IT professionals so they just don't know the answers, especially to the more technical and detailed questions like "what is your OS version?" or "what is the printer model number?".


3. The end user is not qualified to answer some questions. This isn't a lack of skill, but just a lack of enough information. The classic example here is the priority field, which users cannot provide a meaningful answer. They don't know how their problem stacks up in relation to other issues; only IT can provide a useful answer here.

After exploring the problems I came to the conclusion that these just cannot be solved by software and it is unlikely that training, threat, or corporate policy would help either. The only solution is for the system to expect these problems, embrace them, and concentrate on helping the humans work around them on a case by case basis.

TicketDesk follows important philosophies:

1. Avoid asking any question where the user cannot be reasonably expected to answer with 100% accuracy no matter what kind of problem they are reporting.


2. Avoid asking questions that don't apply to nearly every possible situation being reported.

Thus TicketDesk asks as little from the user as possible. The system expects that the only useful field will be the free-text details field. Other fields do exist, but they are designed to be general in nature, optional, or are answered by the staff rather than the end-user.

Tickets should evolve as a natural conversation between the help desk and the end-user:

As discussed above, TicketDesk does not attempt gather a lot of detailed and quantifiable information up front. Instead it expects that help desk may have to ask for additional information.

Tickets are designed to be an ongoing two-way conversation with the user by borrowing heavily from web 2.0 and social networking concepts.

The activity area of tickets acts as a forum-style discussion board combined with an activity and history log. Every action that can be performed with a ticket solicits additional comments that also become part of the ongoing conversation.

The notifications system (and RSS feeds) ensures that both staff and users remain informed as the ticket progresses to completion. And TicketDesk makes it very simple to perform actions or add comments which encourages the staff to actually make frequent updates as they work through an issue.

The result should be a constant stream of information flowing between the user who submitted the ticket and the help desk staffer assigned to deal with it. Either party, as well as interested 3rd parties, can jump in at any time to add to the conversation.

Avoid Workflow & Routing Hell:

This is one of the more controversial of TicketDesk's design philosophies.

Most help desk systems have customizable and dynamic workflows with rule-based routing. This allows for a lot of control over how a ticket moves through the system.

There is no inherent "problem" with this kind of system in my experience. I have had the misfortune of working with system where the workflow customizations were insanely over-engineered to create horridly inefficient routes with many unnecessary steps, but when used wisely these features don't exactly present a "problem" directly.

Avoiding advanced workflow and routing is a design philosophy based mostly on technical considerations.

Workflow and routing is a nightmare to code, especially for a small development team with limited resources. The advantage of this kind of feature set though is rather limited. Other than making managers happy by having the system act as a policy-cop, there isn't much added value to the feature set.

Additionally, TicketDesk is designed to collect a very minimal set of fields, and doesn't expect end users to necessarily fill them in meaningfully so in TicketDesk there aren't many fields that can participate usefully with advanced workflows.

Instead I designed TicketDesk to use a static state-based workflow that should be valid in just about any organization. While simple, it is also unobtrusive and frictionless for the most part.

There have been some requests for workflow options that require only simple workflow customization options or a limited set of pre-defined optional rules. I plan to explore those ideas for inclusion in future versions of TicketDesk, but I have no plans to introduce a full-featured workflow customization or rule-based routing engine.

Allow organic categorization:

Most issue tracker systems provide the end user several with cascading category lists with context sensitive sub-categories. The options in sub-cats adjust according to previous selections to produce granular categorizations. As described before though, this just doesn't work that well because users don't get these selections right very often or the selections themselves are incomplete or outdated.

By omitting detailed categorization in TicketDesk, the searchability of tickets does become a little degraded and it can be more difficult to locate related tickets.

To give TicketDesk decent searchability without re-producing all the problems of traditional over-categorization; TicketDesk includes a web 2.0 style tagging mechanism. This allows users and staff both to organically add keywords to tickets as they desire.

Anyone can tag, but it is only really successful as a substitute for categorization if the help desk takes it on themselves to ensure that tickets are tagged well before being resolved. This takes some discipline and effort, but the up-side is that it produces a degree of searchability that can far exceed traditional categorization mechanisms. And best of all, there isn't a lot of administrative overhead to tagging since the system evolves and adapts all by itself over time.

Tagging is optional though, and many shops (mine included) choose not to make much good use of it. That's OK as TicketDesk doesn't rely on tagging, and a lack of it doesn't degrade the system's ability to perform the primary mission.

Email Notifications should not spam users:

This is a major problem in a lot of different software systems. There is a need to keep users informed of changes in a timely manner, but if you send notifications too frequently the system will overwhelm users.

When this happens people tend to ignore notifications and the important ones get lost in the noise.

To combat this problem, TicketDesk puts an enormous amount of effort into reducing the number of notifications sent to ensure that notification always conveys useful new information.

Here are the basic rules behind the email system:

• Do not notify users about changes that they have made themselves. You know what you just did right?


• Wait a few minutes before sending a notification to see if additional events involving the same ticket happen. If so, wait until changes slow down a bit, then consolidate the events into a single message.


• Convey all of the information about the ticket in the message so users do not have to log in to see what is going on.


• Attempt to guarantee delivery by supporting an intelligent re-try mechanism.

Depsite the fact that this system took a while to get implemented, it has proven good at keeping down the number of messages sent as well as eliminating unnecessary notifications.

The actual format of the notification message is still a little rough around the edges, but that will be worked out in future releases.

TicketDesk will not provide performance reporting:

This is also a controversial philosophy, but one that is absolutely essential to the success of the system.

TicketDesk will not implement any reports or data collection features assist management in measuring employee performance, or that could be used this way.

Anytime the issue tracker becomes a tool by which management measures employee performance the system ceases to have value. Instead it becomes an enemy of the users. Users will manipulating the data in the system to protect themselves and inflate their performance numbers. Anything that would make them "look bad" will be deliberately obscured or omitted from the system.

Researchers call this "management dysfunction", and it is a well established and thoroughly vetted reality. Despite that though, managers around the world still insist on attempting to automate the measurement of employee performance... which is ironic. If they were successful what would be the point in having managers on staff?

Your help desk is probably staffed by very smart people. People that love figuring things out and whose job is to be very good at figuring things out. How long will take them to learn how to game the system?

Even if you have some honest staffers that don't manipulate the system... it will punish those honest users while rewarding users that do manipulate the data to their advantage.

The purpose of TicketDesk is to facilitate honest and open communication between users and help desk. If the system is used to gather performance metrics then it cannot provide honesty nor openness and fails the primary mission.

To complete the failure, any performance metrics you "thought" the system was gathering turn out to be inaccurate and distorted, resulting in a system that can't measuring actual performance nor perform the other tasks it is designed for.

I first learned about this issue from Joel Spolsky, creator of the popular FogBugz bug tracking system, but have witnessed this same phenomenon in nearly every help desk environment I've ever worked with. .

You can read Joel's take on the issue yourself if you wish, he explains it better than I can.

Now... there are ways to do useful reporting in a way that doesn't lead to management dysfunction. But it takes very careful design where you deliberately create reports that cannot be used to show individual or group performance metrics. That is a slippery slope, and I have not yet had time to do the design for such reports yet.

I do have plans to add some reporting in the future, but the reporting will be carefully designed to prevent such abuses.

ASP.NET MVC - After RedirectToAction call, the target action fails to render a partial view correctly

Another undocumented "feature" I ran into when playing with the MVC.

I have an ajax action link that sorts a list on the page. To accomplish this, the link performs an ajax request to the controller's Sort action and in the end redraws the part of the page contianing the list's data with the new sort settings.

No biggie... except that when using Mozilla Firefox, it never worked right. The list would be redrawn, but would always contain the entire page's content including the menus, headers, and all the other stuff.

This was another one of those things I had hoped would magically go away with the RTM of the MVC framework... but when it didn't I had to go figure it out.

The process here was a little more complex than what you'd see in the examples and tutorial apps, but not by much. Here is how it worked.

The controller has two actions: List and Sort

The List action reads the user's profile and gets data based on the user's sort and filter preferences. It will render a partial view containing just the list's data if the request is an ajax request, otherwise it renders the entire page view.

The Sort action simply updates the user's profile with their new sort preferences. Then it uses RedirectToAction to tell the browser to call the controller's List action again.... and the list action would do the actual list building using the updated settings.

Simple enough... 

After some debugging though, I found that some browsers don't resend the necessary headers on a subsequent ajax request when redirected this way. So the list action would think the request was a non-ajax request and it would thus render the whole page view.

There was a lot of discussion about some late beta changes to the MVC framework's IsAjaxRequest() method, so I had hoped it was just a beta bug... but apparently not.

In order to get this to work reliably, I had to have the sort method add a setting to TempData if it was called from ajax, then have the list method check both the TempData setting AND the IsAjaxRequest() method.

Annoying, but at least there is a workaround.

ASP.NET MVC - Ajax partial update fails in IE when updating a table's contents

I chased my tail for a while last week after the final release of the ASP.NET MVC framework went RTM. I'd been having a few "issues" getting my app working right, especially in IE 8.

I'd been hopeful that the RTM releases of either IE 8 or the MVC framework would magically fix these problems for me, but after both went to RTM last week I discovered that I was going to have to tackle the problem myself.

The main problem was that, in IE 8, I was unable to update a table when I was using Ajax  to fetch a partial view containing the table's contents. I had been planning to use this technique to handle paging and sorting of the table's data and for an auto-refresh of the data periodically.

This worked fine on other browsers, but with IE 8 this always threw an unusually crytpic and unformative Javascript error (an "unknown exception") and the update would not complete.

I did finally get to the bottom of the problem...

As it turns out it has nothing to do with MVC or the beta of IE 8. As it turns out, I was getting bitten by a very old limitation that all versions of IE back to IE 4 share in common.

The Ajax mechanism that performs the partial update operates by simply replacing the innerHTML value of the target elment with whatever it fetches back from the server... in my case it would replace the table's contents with new rows it got from the server.

But IE doesn't support using the innerHTML method on tables directly. After some digging I actually came across an explaination for this limitation from the guy who actually wrote the innerHTML method. If you aren't interested in why, just know that he had really good reasons.

Once I knew that it was the innerHTML property of the table that was the problem, it wasn't too much trouble to fix. I just wrapped the table in a div tag, and set the MVC application's ajax call up so it would  targeted the div instead of the table.

Not a new problem, but the fact that I was working with both a new browser and the new MVC framework made it hard to know I was dealing with a more general problem in the first place.

So long Sci Fi Channel, but I doubt you will be missed...

The Sci Fi Channel has always been one of the most confusing failures in American Television. Now, they have decided that the reason for the suckitude must just be the name of the channel.

So they are changing the name to "Syfy". Somehow they think that this move will make their crappy shows appeal to a broader range of people.

Reading an article at TV Week about I have to say, the reason this network sucks has never been clearer...

Thinking back on the successes of the Sci Fi channel, and there are some, you end up with a list that goes a little like this (in no apparent order):

• Stargate (and variants)


• Battlestar Galactica


• Dune (mini-series)


• Eureka

They also had a lot of successes with second-run shows like Doctor Who. But there is one thing that all of these have in common.... they are actually Science Fiction shows.

In the article one of the founders, Mr Brooks, says this:

"We spent a lot of time in the ’90s trying to distance the network from science fiction, which is largely why it’s called Sci Fi"

Oh!

I noticed!

While the Sci Fi channel was making cash from a couple of decent first run Sci Fi shows,They were dumping all their time and money into funding the absolute most amazingly bad screenplays I've ever even heard of.

I mean... "Mansquito"!

WTF?

And that bastardization of Earthsea?

My 9th grade creative writing class wrote better screenplays than that... and I went to public school in a backwoods part South Carolina!

So yeah, we noticed the distance between your network and Sci Fi... really... we did.

Mr Brooks also had this to say:

"The name Sci Fi has been associated with geeks and dysfunctional, antisocial boys in their basements with video games and stuff like that, as opposed to the general public and the female audience in particular"

You know... I get the distinct impression that the problem with the Sci Fi channel isn't that the market doesn't like Sci Fi shows, the problem is that the management at the Sci Fi channel themselves don't like Sci Fi shows.

I think one of the commenters from the TVWeek article (posted by "tijir") said it best:

Kind of funny, some of the biggest shows on television would be a perfect fit on Sci Fi. I'm talking about Heroes, Terminator Sara Conner Chronicals, Chuck, Fringe, and Smallville. Showing that "general" audiences like fantasy/sci fi programming and the one channel that could give it to them big time is "re-branding" itself as siffy.

So Sci Fi managment... go ahead and change the name. It isn't as if the Sci Fi channel has actually been helping put decent content on the air anyway. The few successful shows you've had would have been just as well off, if not better off, on other networks anyway.

I do not expect your network to survive the name change, but after over a decade of watching you guys shit all over the genre you were named after I don't think I care if you make it or not anyway.

I'm just annoyed that someone actually got paid real money to mismanage an entire network for so long.

Windows Vista - Stop changing my folder view based on file types

One of the most annoying things about Vista for me is the way it constantly tries to "guess" what kinds of files are in a folder and then change how windows explorer displays the contents of the folder.

This is especially annoying since I tend to use the "Details" view in windows explorer.

There is a really simple application that can fix this problem right up for you though...

You can control this setting on a folder by folder basis, and there is also a simple little registry hack that can make vista stop guessing what kinds of files are in your folder and attempting to "help" by screwing up your view settings. This and more is described in some detail over at HowToGeek.

But if you, like me, would rather have a simple tool to do the trick, go get ExplorerView. It is a simple little app that can toggle about 4 different settings for you.

As for this "feature"... I sure hope it gets axed in Windows 7. It is about the dumbest-ass idea I've seen to date for the WIndows Explorer UI (and there have been a LOT of dumb-ass ideas in that area before). Why would anyone assume that I'd want the format of an entire "list" of files to change just because "some" of those files are videos or music files?

How that makes any sense at all is beyond me!

What is most annoying is the lack of any obvious way to change that behavior or control it directly in the Windows Exporer UI. Sure... there is a sort of option to fix it for a specific folder, but the option is buried in the options in such a counter-intuative way that they may as well have just not bothered to put in the configuration option for it at all.

TicketDesk 1.2 Stable Release

I've just published the stable release for TicketDesk 1.2 over on CodePlex!

This release took much longer than I'd hoped, but it does significantly improve on the previous release in nearly every functioinal area.

TicketDesk is an open source help desk issue tracking system. Unlike many similar products, TicketDesk strives for simplicity for both end users and help desk staff.   

New in this release:

• New Ticket Viewer/Editor
  • Rich Text Editor for comments and ticket details
  • Improved Work-Flow for resolved, closed, and more-info tickets
  • Smoother UI
• Improved TicketCenter
  
  • Multi-Column sorting
  • Better Filtering
  • Remembers view settings between sessions
  • Improved performance
• Improved Attachment Handling
  • Upload multiple attachments
  • Upload attachments for new tickets
  • Attachment Description field
  • Ability to add comments with uploading attachments
• New Email Notification System
  
  • History and Activity stored in DB
  • Intelligently cuts spam when multiple updates occur rapidly
  • Automatic retry for failed deliveries
• Customizable RSS feeds
• Advanced error logging with ELMAH

TicketDesk 1.2 Alpha Release

I'm please to announce that the next major release of the TicketDesk Help Desk Issue Tracking and Support System is on track for a Mid-February release.

I've already put an alpha version of the new release on CodePlex while I wrap up a few loose ends and finish up some cross-browser testing..

TicketDesk is an open source help desk issue tracking system. Unlike many similar products, TicketDesk strives for simplicity for both end users and help desk staff.  

TicketDesk 1.2 is a significant upgrade over the 1.1 release from last spring with numerous improvements in nearly every part of the system. For a list of the major new features please visit the What's New section over at CodePlex.