I am archiving older pieces I have written on other sites, making this the definitive home for all my work. This is one of several I am porting over from my GameDev.Net user journal. Enjoy!
I was going to try out my GDNet+ web space, but uploading the following screenshots has proven abortive. Consequently, I'm hosting them on my own domain, oluseyi.info, for now.
[By the way, if anyone is interested in doing some web development for me - LAMP solution, though I could be tempted to spring for ASP.NET since my hosting contract expires in November - gimme a holler.]
Okay, here's a shot of the TickerWatch client interface rough draft:
[image lost to the sands of time]
And here's the TickerWatch Admin interface rough draft:
[image lost to the sands of time]
Not much at all. Some background on TickerWatch. I'm currently working for a company that edits the transcripts of financial earnings conference calls. When companies release their quarterly earnings, they follow it up the following day with a telephone conference call with analysts and occassionally high-profile investors. We also sometimes cover technology conferences, Annual General Meetings and other events that may be of interest to investors.
We receive fairly rough transcripts of the calls done by contractors, which we then edit for language - grammar, punctuation, structure (paragraphs), etc - as well as numeric veracity and correct speaker identification. The transcript files are uploaded to what I believe is an FTP folder (it appears as a Networked Folder on Win2k) and their names follow a certain pattern.
We have a list of what calls are expected each day - ticker symbols for the companies - placed into each of the colums seen in screenshot 1. We then have to check the "outside folder" every so often to see if new files have arrived. Now laziness is the foundation of efficiency and productivity, so I whipped up a script (and installed Python on my workstation) to check the folder for me. Here's the source:
target = sys.argv
pendingTickers = 
tStart = os.stat(target)
for f in os.listdir(target):
pFile = os.path.join(target, f)
tFile = os.stat(pFile)
if tFile >= tStart:
# add pattern match to condition
pendingTickers.append((pFile, f, tFile))
fout = file("TickerWatch.html", "w")
fout.write("\n \n \n \n\n \n")
for ticker in pendingTickers:
fout.write(" %s\">%s available at %s\n" % (ticker, ticker, time.ctime(ticker)))
fout.write(" \n\n ")
win32api.ShellExecute(0, "open", "TickerWatch.html", None, None, 0)
Pretty straightforward, and it generally gets the job done. It has some issues, though, so I'm going to rewrite it. I'm also going to reexamine the core algorithm, because the current dependency on os.stat, I think, leads to instabilities such as reporting the same file several times. The highest I've seen is five.
The new algorithm looks something like this:
expectedCalls = 
// pre-populate expected calls list
l = list_files_in_dir()
if f in l is in expectedCalls:
if status(f) is COMPLETED_STATUS:
This eliminates the reliance on modification date, allows the algorithm to locate files uploaded before the application is started, and also allows the algorithm to be used for a general purpose search.
A curious caveat of our data is that it is obtained from the audio in 4-minute segments. Transcribers (the contractors mentioned earlier) sometimes split the call among multiple individuals on their end, meaning we can receive a call in portions which we then stitch back together. This is a purely mechanical process that I'd like TickerWatch to handle.
Once operational, TickerWatch will present either the categorized display of the screenshots or an alternate, prioritized listing. This allows a user to see the status of the top-priority call at a glance, and handle that as soon as it becomes available.
To indicate call status, the text of each call (list item) will vary from red to amber to green - much like a traffic light. By relying on the familiar color codes of traffic signals, I ensure universal comprehensibility with less text. Calls with no portion of the transcript available will be red; calls with some portions but not all in will be colored amber. Calls with all portions in and ready to go will be colored green.
I'm thinking that calls that have been handled should be colored black.
Double-clicking on the item will launch Microsoft Word (our editor of choice - more on that in a second) and place a lock on the file. Traditional anti-deadlocking schemes will be in place here, since this is obviously a networked application. Files are non-local, and other instances of the client need to be advised of handling, etc.
When we start editing a transcript, we make a copy and append our initials, placing this copy in one of several designated folders based on the call type. This will be automated by TickerWatch as well, seamlessly with the double-click.
We're required to set Word to track changes/revisions to the files. I sometimes forget, meaning that some of the changes I made are not available to a later reviewer/auditor, which reduces the quality of data available for contractor QA. This will also be automated by TickerWatch via COM/ActiveX, again via the double-click.
In summary, TickerWatch is supposed to take all the tedium out of the process and allow us as editors to focus on the essence of our job: editing.
Re: Microsoft Word
At work we also use AOL Instant Messenger to coordinate workflow. My supervisor has to create an AIM screenname for each employee - inlcuding temporary ones like myself - because a) people often have work-inappropriate screennames like "sexygurl86"; and b) people often don't want to add a bunch of co-workers to their buddy lists.
Once my supervisor heard about early versions of TickerWatch, we began discussing additional utilities. She'd like some kind of simple messaging tool that allows her to create and delete accounts at work without the hassle of passwords and other requirements for AIM. Jabber came to mind, but I went over to talk to the "MIS guy" and he told me there were no server-type machines available, and no machines with static IPs on the local network.
So I'm planning to extend TickerWatch at some point with rudimentary IM functionality (RTF TextBox and a UDP socket).
Another little thing that can be automated is replacing text like "45 cents" with "$0.45" and "2 million dollars", or even "two million dollars", with "$2 million" using regular expressions. Word has a pattern find/replace functionality, but it's inconsistent and nowhere as powerful as what can be done via the COM/ActiveX interface and a more robust language.
Obviously, TickerWatch is growing, and I began to ask myself whether it wouldn't make sense to host the MSWord editing component within TickerWatch, creating a single, simple, cohesive environment for our entire workflow. I'm still undecided, so I'll share whatever experiments I perform with that as time goes on.