Police officers and departments are now operating in a world where every single thing they do, individually or institutionally, is sooner or later going to be scrutinized or asked about by someone. The more we can do to help agencies and officers document things that happen - especially controversial situations - the better it is going to be for everyone.

So we arrive at Use of Force, or Response to Resistance reporting. Every agency with an interest in protecting itself as well as its officers either has or is getting ready to have Use of Force report requirements. Documenting what actually happened and why is the best insurance against a future nightmare when a defendant eventually comes back with some cooked up story about injuries he sustained, the way he was treated, or whatever.

Tied to an intelligently crafted Use of Force policy, this is your best way to deal with this lousy reality. PolicePro is going to make it easier.

PolicePro’s new Use of Force reporting is, like everything else in the system, tied directly to the incident it stems from. An officer can complete a Use of Force report in just a few minutes and get on with his or her day. All the source material he or she needs for the report is right there on the PolicePro screen. When the report is completed, a supervisor can confirm it in an instant. Cases that need reporting can be isolated in a hot second by just running a Saved Find request or requests for incident types that generally require reports.

And like other critical areas of PolicePro, Use of Force reports themselves can be restricted as to who can access or read them. The only difference is that this time, we leave the arrow icon that indicates the existance of the report or reports, so supervisors can in fact confirm they exist. The actual report content can be restricted wtih our usual Need To Know logic.

Necessary evil? Probably, though this kind of reporting can keep an officer and a department out of trouble right from the start. Worth doing? Absolutely, every time.

----------------------------------------------------------------------------------------------

Sample Dispatch Ticket on a fictional Assault event:



Like everywhere else, clicking the Use of Force tab displays a decision window:



Click Yes, and a new Use of Force/Resistance Report pops up with the case reference information already created:



Printed output at the end:



Like everything else in PolicePro, resistance reporting (sounds better, yes?) is completely searchable. Output can be to paper or PDF.

Eleven years now and we never stop thinking about how to make PolicePro better, easier to use, and continually relevant. Force/Resistance reporting is a classic example of why PolicePro is Still The One.

The recent release of Filemaker 10 has had us jumping to incorporate some of the new stuff into PolicePro. One of the first visible changes is what FM calls Dynamic Reports - the ability to instantly present live, editable data in different sorted views. We’ve applied this to some of our lists in PolicePro, such as the general Dispatch incident list.

The default, longtime behavior of this list was an attractive and easy to read list of everything current, where related content (arrests, criminal complaints, etc) can be seen and accessed. Very useful, very nice, but it was static.





If you look near the top right, though, we’ve now added a row of radio buttons. Clicking any of these - or any others we may enable, depending on what kind of data is being looked at - instantly changes the view to a sorted and summarized list, shown first by Incident Type:





The great thing here is that the data is still live, searchable and editable. If a review indicated that an incident in the Zone/Post summary view below had been assigned to the wrong zone, changing the Zone field will instantly move the record to the proper spot in the list.




You can print any of these by clicking the Print button - the resulting job will be the same sorted and summarized list in a more paper friendly format.

You can see that anyone whose duties involve reviewing or reporting on multiple sets of information is going to love this! Doing a quick Find for a specific officer, for example, and clicking one of the view buttons will give you an instant and easily understood summary of that officer’s activity by date - how many calls he or she handled, for example - or zone, or any other relevant criteria.

There’s a ton more coming, but this is already going over very well with people who’ve had a chance to see it. And many more are going to be seeing it pretty quick - we’re rolling out several new and upgrade PolicePro 10 projects in the next six weeks. Busy is good!

Most of the best features in PolicePro come from the users; things I never would have thought of that turn out to be so valuable to everyone else once they’re introduced. One of the more recent - and popular - of these is Restricted Access to certain information: the Need To Know scenario.

Police agencies handle a lot of sensitive information that perhaps should not be readily available to all officers. The one that jumps out at you, and where this feature started, is sex offenses. Beyond the detectives who may write a criminal complaint or deposition containing sexual information, the bosses and the prosecutors, you may want to keep this stuff under wraps but still available in the system. The same thing is true for certain internal investigations or, for that matter, virtually anything that a supervisor or Chief wants to restrict for whatever reason.

Another one that sounds easy at first but turns out to be tougher to implement than it looks. We went with a model that can restrict access to any Criminal Complaint, Supporting Deposition, Narrative Report or Evidence record. Restriction is at the discretion of the person who generated that record or anyone up the supervisory chain from that person. For instance, a detective can restrict a Deposition, as can any detective supervisor who reviews it. Once restricted, only the person who initiated the restriction or a member of a higher privilege set (the bosses) can release the restriction.

But isn’t this going to piss off the line officers at some point? Everyone hates the “You Do Not Belong Here” message! We dealt with this potential issue using an old magic trick: it seems to disappear!

Once a record is Restricted, the flag that indicates the very existance of that record just goes away for anyone who is not authorized to see it. Therefore, a detective sergeant looking at the Dispatch record for a Rape case sees the flags that indicate depositions and reports, but a patrol cop out in car 7 looking at the same record isn’t aware those records even exist.

Here’s a shot of a Dispatch report on an apparent domestic assault. You can see right away that a Complaint exists on this case by virtue of the Complaint flag.



Clicking that flag of course takes you to the relevant Complaint:



To restrict the Complaint record, an authorized person can simply click the check box next to the Record Lock icon:



When you return to the Dispatch record for this incident and log on as a “regular” user, the checkmark as well as the navigation ability to that Complaint are gone:



If there were mutliple Complaints (or narratives, etc.) on this case, the check mark would remain and navigation to those open records would still be enabled; but access to the restricted records still would apply. Even if a user decides to get tricky and try to scroll through records, they cannot get to, export, print or in any other way access a record once it’s been restricted.

Restrict and Open events, like locking events, are all tracked internally by PolicePro and those events become part of a Restriction log that is itself restricted all the way up to a System Administrator privilege set.

The result of all this? Real Need To Know access on sensitive records while maintaining the usual ease of search and ready access to information that is the trademark of PolicePro.

Thanks to the Hastings Police Department in New York and detective sergeant Bon Palumbo and lieutenant Dave Bloomer for bringing this up. This feature is emerging as one of the most popular, apparently second only to the universally loved File Cabinet.

This kind of detail is found throughout PolicePro. Everything has been thought out and discussed with end users to make sure that the function works in the real world as well as in my head. I’ll show some more stuff like this in future posts.

Mantoloking PD in New Jersey has really perked up their police car graphics. With the new flat light racks, these things look pretty good (unless they’re behind you with those lights turned on, of course).

The PolicePro Main Menu has been around forever, in various iterations. We’re getting ready to leave it behind, in favor of a more useful, user-intelligent Dashboard.

What the Menu lacked was that user awareness to make it actually useful. The Dashboard “knows” who is signed on and loads different content based on not only who that person is, but also what their role is within the agency. Where a patrol officer might see a generic list of currently open calls along with recent Alert flagged calls (among other things), a detective will get his or her own open cases along with that basic list... and a regional or station supervisor in a larger outfit will dispense with both, in favor perhaps of a chart of activity by station, region, zone or whatever.

The current menu, as it has appeared for the past two years - attractive but limited in function:




The new Dashboard, obviously unfinished, but heading in the right direction:



I particularly like the idea of an Officer Awareness list, being anything that has been flagged as safety related over a range of days. Should an officer receive a call to a ‘hot” address, we’ll add a special alert that will display right in the patrol car as a Heads Up before he or she ever pulls up outside the location.

On Wednesday, May 14, I was notified by several of our PDs of a bulletin from New York Division of Criminal Justice Services (DCJS) that they had just received. Dated May 8, it announced that effective immediately, DCJS is requesting (not requiring, to be fair) addition of a heavy level of Domestic Violence data to Uniform Crime and Incident Based reporting. This kind of stuff demands a lot of new logic, new data fields, and significant impact on processes and user viewed layouts... something that can literally take months to implement in a SQL based system. Therefore, it imposes quite a burden on the software vendor, who has to decide if, when, and how to implement it - since this is not just some new layer that can get added on top - and to the police department and its users and/or officers in that all this new stuff has to be captured and totaled manually until the software vendor comes up with the fix (and the likely very large bill attached to it).

I get the "why Filemaker" question a lot, though not as much these days as we used to, since Filemaker embarked on its Platform direction. Here's the best answer yet.

I cursed, swore and complained all day Wednesday and half of Thursday about this. Thursday afternoon I actually read through the whole publication three times. Even though it stems from a single identifiable incident - a dispute in a parking lot, a straight-up domestic dispute at a residence - the reporting itself is actually person (or more accurately in a database context, contact) based, and can involve several persons per incident, though each person can only be assigned one reported value. Got it?

Turns out each reportable entry involves thirty five possible combinations of data in a matrix of five reportable crime generic types and seven types of personal relationships involving the victim (Wife by Husband, Husband by WIfe, Child by Parent, etc). Therefore, what is really required are two base entry fields: one for the crime type and one for the relationship type - and thirty five calculation fields, one for each of the possible thirty five outcomes. Add thirty five summary fields to total the results of those calculations, twelve more summaries to total the sums of all the originals, and one final grand summary to total all values in the lower right corner of the matrix, and you're done, right?

Wrong, of course. You gotta have a way to trigger all this in the first place, to tag an incident as a Domestic, possibly to be reported on. And then, not every Domestic incident is going to rise to the threshold outlined by the five reportable classes, so we need to be able to ignore those. And since we can't just ignore anything without giving rise to the question of was it ignored on purpose or forgotten about, we need some kind of flag to announce that this incident was in fact excluded deliberately. And for data integrity, you should not be able to tag that flag if any reportable information is already attached to the person involved.

And of course there's more... all the process to drive and cause this stuff to happen has to be added, new layouts to display it all need to be written, print routines created, error checking, and don't forget to touch the existing audit trail stuff as well!



Welcome to Filemaker (and twelve years of experience in Filemaker and PolicePro as well, of course - no small thing). Thursday evening it was the whiteboard in the office and a a good part of a legal pad. Friday morning I turned off the phones and hit the office at 7AM. Even with a quick trip to the airport at noon, by 3:30PM I was able to lean back and realize that the entire job was done on the Master file. Now it will be the not insignificant matter of getting it in to the existing client base, since this is not something you just throw on the pile, but the bottom line is that from the initial outrage at this latest bureaucratic insult to a completed and working solution, invisibly integrated within PolicePro like every other part, the whole thing ran two days.

Try that in any other database system and see how you do, even with the logic road map I just presented.

And believe it or not, I actually enjoy doing this stuff! The problem solving is the best part of this whole enterprise... maybe why I enjoyed being a detective so much in the old days.

We're releasing CaseBook - a rewritten, more focused version of Investigator - this week, in time for the New England Conference on Child Sexual Abuse. This is going to be primarily a single user desktop or laptop application - aimed at sitting on a unit secretary's or supervisor's computer, or an individual investigator's laptop - to keep track of the status of active cases. When I was still running the detectives in Poughkeepsie, we ran an earlier version with great success on several complicated fraud and missing persons cases, one of which is still under investigation almost five years later.

But I digress! What I'm thinking about now, taking a few minutes off from doing just this, is arriving at the point where you say "This version is done, ready, finished" and hit the button that produces the end result. The point at which the product is frozen and deemed Good To Go.

PolicePro, if the last ten years actually happened, has never reached that point. We never stop adding to it, removing from it, or tweaking it. Since we provide ongoing technical support for it, this is the way it goes. While we do have loose versioning, it's hard to point at any one install and find that it exactly matches any other from that or any time period.

CaseBook, being particularly focused and not aimed at network deployment, and very inexpensive, has to be done differently. While PolicePro is arguably a product in a loose sense of the word, CaseBook is specifically just that. Therefore, once I hit the Create Runtime button, the result is intentionally frozen so that no one, programmer or otherwise, can make any functional changes to it.

That last mile of arriving at this point is the toughest. Something that may be "finished" is not necessarily "done" in this game. Every detail has to be right - there will be no more jumping under the hood and just fixing some minor (or not so minor) bug or gremlin. The last week has been nothing but compiling, testing, finding one more damn thing, fixing that, compiling and testing again... Loop Until Done.

And now that it's been beaten hard and found to be durable, and the all important first time install/setup experience - a whole different thing - has been arrived at, we can of course start keeping track of what will be added or changed in the Master file here between now and whenever the next release occurs. There's the discipline part! With PolicePro, I've always just gone ahead and made the changes to client versions as they arose, and anyone with a brain will tell you that is NOT the way to go. We're trying to take that lesson to heart, but with CaseBook we're living it.

We've made Windows as well as Mac versions of this one, since we may step outside the strict police world into some more social work or security type environments, where Macs may be found. I can happily say for once that there is such a thing as a program or function that is far easier and more pleasant to run on Windows - creating the install packages.

I've been using successive versions of Indigo Rose's outstanding Setup Factory install creation tool for nearly ten years now, and the thing is always a pleasure to fire up. If it were only cross-platform! I have not yet found a cross-platform or Mac specific installer that can touch it, and even if I did, I wouldn't walk away from it out of sheer loyalty for the suffering it's saved me over those years. I think it's one of the great friends a small ISV can find.

One of the new features of Filemaker 9 - released a couple of weeks ago in mid-July, 2007 - is something called Conditional Formatting for fields. In earlier versions, display tricks such as red or green buttons, different kinds of text formatting and similar things required some trickery with calculations, custom functions and container fields that would hold color blocks. All this was central to the Lightbar in PolicePro - the row of red and green buttons that displays whether a given police car or officer is in or out of service. WIth Conditional Formatting, I had an opportunity to remove several layers from the existing process.

Of course, that means that to properly take advantage of the new function, we need to rewrite the whole thing. Since we're doing that, we might as well throw in some enhancements that would make sense to the dispatchers running the system.

What a pain in the ass it is to get this stuff exactly right! I rewrote the entire function on a single computer to where it ran flawlessly. When it came time to test it across a LAN with some other desktops, we realized that the red/green stuff I had changed wasn't working over the network the way I had rewritten it. Had to go at it all over again to remove all globals and use calculation fields instead with a new discrete relationship from PolicePro to to a single record in Preferences.

I decided the default state for any new car added to the roster should be a green button and an "In Service" tooltip. Any button that did not have a car assignment needed to open as red with no tooltip notations.

Then it occurred to me that if no location was entered when a green button was clicked, the button should stay green - an additional If statement.

After a day of tweaking and testing, it's this script (times 10, for the 10 possible Lightbar buttons) to control the actions of the lightbar stuff ends up nicely organized, easily readable and very straightforward.

The final step was to go back through the thing and comment the hell out of it for the future, the single most important thing I've learned over the last 11 years of doing this work.

The old truth in software is that the easier a program or function is to use, the more work some poor guy had to do to make it that way. Here is one tiny detail that emerged during the v9 rewrite for PolicePro as an example.

We do a ton of monthly reporting in PolicePro: incidents by Type, Incidents by Zone/Post, UCR, (soon) IBR, Clery reports for college security, Officer activity, you name it. To capture the date ranges to be reported on, we use Global fields on dialog boxes where the user enters a simple string: 6/2007 for June 2007, for example. The input field is a Text field, as opposed to a Date based field, since to get that same month result in a global Date field would require the user to enter 6/1/2007...6/30/2007 - who wants to do that if they don't have to?

But to display an English month and date on the resulting printed report, we had to have the users put that in as well under the existing system, or be stuck with a report that said "All Incidents Report 6/2007". I never much liked either alternative.



So I decided to write some calculations against that entry field, the gDateForSearch field, which would pull out the results I wanted with one simple entry field.



The Report Title is based on two more globals, gMonth and gYear. The gYear was easy: a Right function, pulling the last four characters from the gDateForSearch, since there will always be a four digit year in the string.

Whenever a Print report script runs then, the gMonth and gYear get populated by a calculation that runs in a two-step subscript:




The gMonth though? Yikes! Since it can be one or two characters, you have to look for the first incidence of the slash character... so that means adding a Position function inside a Left function, but the Left calc looking at that always INCLUDES the damn thing. Okay, then we'll run a Filter on the result to get rid of the slash... then we've still gotta turn the result into text.

And the Filter function? If you filter for 0123456789, the calc engine will drop the 0 every time, and 10/2007 will evaluate as January, 2007! Turns out the 0 has to be at the END of the string. It took ten minutes just to figure that part out! I could not initially get why the 0 kept dropping. (Of course, all I had to do was wrap the filter values in quotes, but hey, it was a long day!)

Two hours of trial and error, fighting with every semicolon, every parenthesis, on and on till it was right:



I originally thought this would be a nice, easy Month calc, but it doesn't work on a text field, and we already talked about why the entry field couldn't be a Date field.

This is now going to get a Length calc wrapped around the whole thing so it won't attempt to evaluate a string with the day in it, indicating a part of a month: 6/21/2007, or 6/1/2007...6/10/2007. In that case it will default to the actual date range entered straight out of the gDateForSearch field.

PolicePro 9 will be the first version to support IBR - Incident Based Reporting. The Feds and various states have been pushing this since the early 80s as an "improvement" over UCR - Uniform Crime Reporting - which dates back to the 60s.

There are actually two parts to this story. The first, which applied almost instantly to UCR, was the perversion of the original intent of the whole thing in the first place. Uniform Crime Reporting - note the word "Uniform" - was supposed to be a nationally scoped levelling of the playing field, so to speak. Standardized reporting across the country would allow intelligent analysis of crimes, incidents and trends, right?

Wrong! The first thing that happened is that almost every state - with my own home state, New York, in the lead - immediately began perverting and diluting the value of the whole thing by adding what are known as "enhancements" to UCR reporting. "Enhancement" in this case means taking something that is logical, orderly and valuable and turning it into a meaningless morass of asinine statistics that no longer mean anything.

So Robbery in the UCR world - depending on what state you're in - became lists miles long, in some places boiling down to Robbery/Force, others Robbery/Force/Hands/Fists/Teeth, and elsewhere Robbery/Force/Intentional. All through the UCR Part One crimes - the important ones, Murder, Rape, Robbery, Arson, Assault and Kidnapping - various state Divisions of Criminal Justice couldn't wait to put their own wrinkle on it.

The result? Supporting UCR in several states is a nightmare, since every damn state is different. So much for Uniform.


So let's go ahead and modernize! Let's dive in to the Next Big Thing, Incident Based Reporting! After all, people have been asking for it for years, and on the surface at least it seems to make more sense than UCR.

Guess what? Does New York State report IBR? Why the hell would they want to do that when you can have NYBIR: the Enhanced version for, you guessed it, New York!

MORE work for less value and there's Your Tax Dollars At Work.


So just when you thought it couldn't get any worse, I'm going through the Victim tables this afternoon, dutifully writing new data tables to comply and support this wonderful standard, and I come to a table called Victim Residence Status.

Can you feel this one coming? Can anyone say "Illegal Alien"? Of course not, that would be rude.

OK, how about "Undocumented Alien?" Why no, that's not here either.

Take a look. In the year 2007, when we are under threat of assault from potential intruders who don't belong here, THERE IS NO REPORTING CATEGORY FOR ANYONE WHO IS NOT HERE LEGALLY. The best you can hope for is "Other Status".

This would be funny if it wasn't so pathetic. It really raises your confidence that we might ever prevail against any of our enemies if we can't even risk naming those who AREN'T our enemies, but just might not belong here legally. I have no problem with people trying to improve their families' lives by coming here for America's opportunities - if I'd been born in the wrong part of South America I hope I'd have the guts to come here too, but if something is blue, there's nothing to be gained by calling it gray. This is supposed to be policing, right? Close enough doesn't count.

Heaven forbid we ever stop developing stuff! This is still some months away, but it is very much on the front burner at Steamboat. Some really tight new design and logic is going to be the keynote of this revision.

As usual, we've been collecting ideas and requests as they come up for inclusion in the next release. And as usual, most of the best ideas come from the cops and not from us.

Look for more interaction with outside data sources - scanning license information in for Name records, for instance. We're also continuing to push the new Name/Incident logic we introduced in the v8 rewrite. Under the hood, v9 features a ground-up rewrite of the program's relationship/ER logic to the new Anchor-Buoy standard, making the whole thing tougher than ever.

Interestingly, development this time is coinciding with a complete remodel/renovation of the Steamboat office - starting over from bare concrete walls - that has me particularly spending a good deal of time at the new Clifton Park library and the Borders store to get away from the noise of construction. In four weeks though, it's going to look pretty good around here!

A New York police department ran into a problem with their Uniform Crime Reporting this month when they had no arrests of anyone under 18 for the month. The error trap I had for that situation was in the wrong place in a very long and obtuse script, written eight years ago and just brought along as is into the subsequent updates and rewrites of PolicePro.

So I'm looking at this thing and trying to figure out where the break is, and of course when you do this, you inevitably just get stuck and miss the obvious: this so-called script was a disaster, and while it had been sort of modularized (calling two external scripts to handle the actual Print events of the two reports it produces, Over 17 and Under 18 arrests), the modules were broken out in the wrong places and missed the whole point of doing it in the first place.

The only way out of stuff like this is to step back, hit the Delete button, and start all over again writing the routines. And Part Two of that, the important part, is that when you're doing stuff in (hopefully) logical modules or sequences, you need to work from the bottom up instead of from the top down! The Top Down approach has you trying to get the whole grand sequence in some kind of order, creating pieces to handle the If branches as they arise. That's how I originally wrote this, and that's what was wrong with the damn thing.

Bottom up means you start at the basic steps: write routines for extracting the Over and Under 18 stuff, THEN tie it all together into something that runs at the mouseclick or is called from an even further up script.

And in the end, clarity! What was once this (calling two poorly thought out subscripts for the Print events and one to end up at the proper Admin menu):

#Called by UCR Reporting script
Set Error Capture (On)
Enter Browse Mode [ ]
Go to Layout ["Arrest List" (Arrests)]
Enter Find Mode
#Set criteria for arrests over 18 this date range.
Set Field [Arrests::Arrest_Date; Prefs::gLastDate]
Set Field [Arrests::Age; ">17"]
Set Field [Arrests::UCR_Crime_Type_Flag_Calc; 0]
Perform Find
#
If [Get (LastError) = 0]
#No errors occurred, and the report for Over 18 is run.
Perform Script ["Print UCR Arrests Over 18 - 2"]
#Now set Find Criteria for arrests under 18 this date range.
Enter Find Mode
Set Field [Arrests::Arrest_Date; Prefs::gLastDate]
Set Field [Arrests::Age; "<18"]
Set Field [Arrests::UCR_Crime_Type_Flag_Calc; 0]
Perform Find
#
If [Get(LastError) = 0]
Perform Script ["Print UCR Arrests Under 18 - 3"]
Perform Script ["Switch To Administrative Menu"]
#
Else
#No arrest records over 18 found for this date range.
#Run through the Under 18 FInd criteria and Find again.
Show Custom Dialog ["No arrests over 18 were found. The script will run the Under 18 report only."]
Enter Find Mode
Set Field [Arrests::Arrest_Date; Prefs::gLastDate]
Set Field [Arrests::Age; "<18"]
Set Field [Arrests::UCR_Crime_Type_Flag_Calc; 0]
Perform Find
#
If [Get(LastError) = 0]
Perform Script ["Print UCR Arrests Under 18 - 3"]
Perform Script ["Switch To Administrative Menu"]
#
Else
Show Custom Dialog ["No records were found for arrests under 18."]
End If
End If
End If
#
Perform Script ["Switch To Adminstrative Menu"]



Became this:

#8/23/2006 dwl
#Called by UCR Reporting script.
#----------------------------------------------------
Set Error Capture [On]
Enter Browse Mode
Perform Script ["Print UCR Arrests Over 18 - 2"]
Perform Script ["Print UCR Arrests Under 18 - 3"]
Perform Script ["Switch To Administrative Menu"]


Well, THAT'S a little easier to understand! By way of making excuses for myself, I'll restate that I wrote this mess back in 1997 or 1998, and that when I did the big rewrite, I just shoved the existing UCR stuff in As Is because it worked, and I had just finished defining 845 UCR related fields from scratch and by hand. So there it lay, quiet and messy, until a slow arrest month brought it onto my desktop again.

The new script calls the same two subscripts as before, but this time the Set Field and Find steps - and the Error Captures - are in THOSE scripts where they should have been all along. They're exacty the same except for the Find criteria on the Age field and the layout they go to for the Print step.

This thing was the Filemaker developer's version of getting hit by a bus while sporting old underwear. When you get to the emergency room, everyone has a good laugh at your expense. So now on the rare occasions I don't have much to do, I guess I'll be revisiting what's left of the old pre 2004 code and seeing what other horrors lurk there. Just because it works don't mean it's pretty!

Filemaker Inc, the makers of the Filemaker software that we use to write PolicePro, announced the new version 8.5 this morning (Monday, July 10). Lo and behold, one of the prime examples they use to show the power of their outstanding new Web Viewer capability is PolicePro. The Web Viewer allows us to embed a Google or Mapquest map of an incident location directly into the Dispatch Report in 8.5, something extremely helpful to cops responding to a call with PolicePro in their patrol cars.

It's great to be recognized by Filemaker, with whom we've had a long relationship... in the late 90's they ran an ad campaign featuring the early PolicePro with a tag line "This collar belongs to Filemaker Pro". I was on a plane reading Fortune Magazine and turned the page to the ad without knowing it was running there, and how good did THAT feel?

The reference to PolicePro and the screenshots are here.

And it's nice to now be able to announce this great feature, which has had to be a secret until FMI made the new version release.

The jet will be taking off to Alaska in a week, so the new Inventory and Personnel systems are moving along pretty well now. Nice to be on schedule!

Skagway's new Inventory system will track anything and everything the PD desires to follow, from when they buy it, to when it is assigned to an officer, and when it comes back for its next assignment. Barcode features will minimize typing and make it easy to keep track of where things are. All this is designed as a response to Alaska's state accreditation requirements, and will put the Skagway PD right where they want to be.

Inventory and Personnel records will be tightly integrated as well, allowing supervisors to see at a glance what is assigned to any particular officer. In the event that things require periodic qualification or calibration actions, that information will be available at either the item or the assigned officer's record.

While we're at it, we're enhancing the training records for personnel and moving the personnel files themselves more fully into various PolicePro operations.

PolicePro and Steamboat Data Systems operate out of New York. What's with the Alaska stuff?

Hey, why not? It's not that big a deal, in a state where going to the dentist often means a plane ride. From Albany you hop on a jet, turn right at Seattle, land in Juneau and go from there. And in the new wireless world of the much improved Internet, we find we can service our distant clients from pretty much anywhere, until it comes time for a major new project or upgrade.

So the story is that Dave Lundgren will be in Southeast Alaska during the first part of April this year, and if you are part of a PD in that state that is tired of the system you have, tired of having no system at all, or just curious about PolicePro, you won't get a better opportunity than this to do something about it.

We love Alaska. PolicePro, even though a Lower 48 flatlander program, could not be a better fit for Alaskan law enforcement if we had written it in a tent atop the Denver Glacier. PolicePro will shortly meet every standard of the ALEAAC Accreditation program as well. It certainly couldn't hurt to contact us, especially now since we will be in the (so to speak) neighborhood.

So here we go again with the weblog idea. I had one of these going last year, the Steamblog, attached loosely to the Steamboat Data website. It was done in Six Apart's Typepad product, which was excellent to work with; but I let it lapse as pressures to get other things done slowly pushed it further off my radar.

This new site is a move back to our original PolicePro roots. For several years PolicePro.com was its own entity, and quite successfully. When we incorporated in 2003 as Steamboat Data Systems, I had the bright idea of consolidating everything under one site umbrella. I can't say it was the best idea I ever had, and so this site is the result of recognizing that fact and putting PP (as we call it) back in its own house. The Steamboat Data site persists as well, and will start heading in its own independent direction shortly.

PolicePro.com for the cops and our (favorite) police business, SteamboatData.com for other programming endeavors.

The new site is being done completely in RapidWeaver, just an outstanding web creation product. It ain't the most sophisticated product in the world, but we're not the most sophisticated people either, so it's alright. It is some solid, practical stuff for people who want to get a site up and out there. It is also a Macintosh only product, so Windows users either need to find something else, or buy a Mac mini to use for web creation along with your other computers. Try it, you'll like it!

What Rapidweaver does better than anyone is let me create, manage and update this site by myself without requiring all sorts of technical assistance from anyone else. Since our message is pretty straightforward and our corporate culture is about Relaxed Excellence, it's a great match for what I want to do.

Rapidweaver also lets me run this weblog as an integral part of the site, again a great timesaver and ease of use tool.

So the weblog will (slowly) evolve into the usual self-absorbed ramblings that they all do, but hey - there are people out there who are interested in this stuff! I intend to pontificate occasionally on what is going on with PolicePro, what we see for its future, and how we're going about it all.

With maybe just a little tech talk sort of content in there as well as things appear that impress me - like Rapidweaver.