Projects come in two basic flavors: stuff I’m working on now and stuff I would like to work on in the undetermined future.
.::Stuff I’m working on now::.
Alas, there’s not much interesting stuff to put here at the moment. I am too tied up in grad school and at work to really have the time for this.
.::Stuff I would like to work on in the undetermined future::.
Social Ticket Tracking System – There’s already a whole range of ticket tracking systems out there, many specialized for certain areas (IT help desk, customer support, defect tracking), and many of these are not that great. If you’ve ever used a solution that your company purchased, you know what I mean. What is really missing from these systems is a set of modern functionality aimed at reducing the number of times support organizations spend solving the same problems and at improving the quality of the tacit knowledge explication that these tickets represent. Some things I see as important in such a system:
- RSS Feeds: Forget having to login to some kludgy application just to see what is waiting to be worked. Do like Craigslist and generate custom RSS feeds for any available data subset. If users can get reports and updates on very specific kinds of tickets, they can watch for the emergence of patterns, which will help to link otherwise isolated events into larger issues that may be occurring.
- APIs: Along with being able to get specific data out in whatever app will read RSS, you should also be able to roll your own interface. I don’t care how cool you think your whiz-bang web app interface is, some people will not be satisfied, and they will be quite happy to develop front-ends that work for them or mimic some workflow elements that may not be explicitly represented in your application. Try to stay out of their way.
- Statistical text analysis / pattern matching: Some elementary implementations of this concept have found their way into knowledge bases and even some open source ticket tracking systems, and they are decent. What I am looking for is a combination of statistical processing that can give me a list of previously submitted issues that look pretty similar to this one. That means the words are going to be statistically similar, but current systems assume that related tickets will have matching terminology. If different people use different terms to describe their issues, the basic text analysis will fail miserably. What’s needed are things like context analysis, synonym processing, word stems, and user tagging.
- User Tagging: AKA Folksonomy. If users can tag the requests that come in as they either submit them or work on them, instead of using staticly-defined categories, then patterns of terms evolve as people agree on what to call something. This also aids in the text processing as it’s easier to associate limited word lists than it is to try to figure out how to make associations between two paragraphs. However, tags can also be suggested based on the wording of the incoming request.
- Data and text mining: This is similar to the statistical text analysis, but instead of automatic suggestions, it can be used to identify trends and to link together issues for the discovery of things that may not be obvious. This is really just a “nice to have” feature, as you can get by without it.
- Dynamic linking (user moderation): In the same sense that user tagging can generate lists of possibly related issues, users should be able to moderate (vote up or down) the usefulness of the suggested items, and they should be able to dynamically link items together to form a web of related topics. This is predicated on the idea that the text analysis is imperfect and may miss some important features that relate tickets.
- Web of Expertise: Finally, using semantic web concepts like friend of a friend (FOAF) and others, we can establish network patterns indicating historical solution paths, so that when a ticket arrives, it can suggest not only possible solutions from past tickets, but more importantly, the most likely path the current ticket will have to follow for optimum resolution. This builds a web of experts based on the idea that certain people tend to solve certain kinds of problems. What this might allow us to do is make some predictive guesses even on tickets that represent new solutions (i.e., no history of that particular issue). Add to this the ability for users at each workflow stage to moderate the suggestion (maybe it’s well known that the person who has recently fiddled with certain issues really has no idea what he’s doing, and so the predictive selection may be overridden with user moderation). This can form a powerful tool for resolving tickets quickly, because it ensures that the issues follow the shortest path to resolution. Make the algorithm adaptive to give more weight to the most recent issues that fit the criteria, and it is no longer necessary to worry about using outdated information to determine these paths: they autocorrect over time.
Now the question is, who is going to build it? I think I can, but I will probably need help. Any takers? Let’s make it open source, create the base modules in php or ruby on rails, expose the APIs, and sell the customizations as professional services, then charge for support.