Engage Sandpoint: A missed opportunity

By David Phillips
Reader Contributor

Projects fail for all sorts of reasons. Sometimes the expectations are set too high; sometimes the allocated time or resources are insufficient; sometimes the tools suffer from fundamental shortcomings. In the case of Engage Sandpoint, I believe that all of the above factors are contributing to a downward trend in utility that will ultimately cause public participation to tail off. 

As someone who’s been deeply involved in software development, architecture, usability and interaction design for a long time, I’ve been regularly involved in assessing designs, functionality and standards from small businesses to enterprise-level efforts. 

Some specifics:

“We must write all our own software”: A lot of development teams fall into this trap, believing that they are the ones to reinvent the wheel better than anyone who has come before rather than leveraging existing tools. The problem: The tool you end up with is as simplistic and immature as a “version 1.0” of anything would be.

SeeClickFix appears to be written mostly from scratch, which explains a lot: The code is heavily focused on Microsoft products using methodology that’s outdated, and browser compatibility is sorely lacking. The application has states only for “Open,” “Acknowledged,” “Closed” and “Archived,” and its search capability is barely usable. 

Our current situation speaks as well to Sandpoint’s technology procurement process, as deploying this application indicates to me that either the people making the contracting decision weren’t qualified to evaluate tools like this, or due diligence was ignored.

Interaction design: While SeeClickFix has good intentions, the product suffers from a lack of coherent user experience (UX). Again, this is essentially beta or alpha software. Navigation is inconsistent symbolically and functionally — some controls like search filtering are virtually hidden due to size or placement (look for a tiny funnel symbol for filtering). It is possible to have two search fields active on the page that do radically different things (e.g. address search and text search). It’s relatively easy to end up on a page for without any path to return to where you started. The navigation paradigm varies from page to page. 

All of this indicates a lack of architectural oversight.

Search: This is probably the weakest function of SeeClickFix, and for an app like this, a critical miss. Google learned a long time ago that search results absolutely must be consistent, comprehensive and relevant if they are to be trusted. When SeeClickFix added the “Archival” search setting, I had some hope they were getting their act together in this area. But “Archival” suggests a comprehensive search of all available data. The first release of this feature had no pagination and limited results to the first 20 issues it found. Pagination addressed that problem, but search is hardly comprehensive. Check the “archival” box and search for “truck” or “speeding” or “garage” or “snow” you’ll likely get two or three results, when there are far more in the database. This is a pervasive behavior across all searches.

Success factors: Any issue tracking system has some fundamental requirements: 

Clarity: A user can access an issue and understand what the issue was, what the response has been, what action has been taken, and what the current status is (the “workflow”). This means that issues must have sufficient states to clearly represent their status, and also means the people administering the system (i.e. the responders) must be consistent in their use of those statuses. Too limited a status set and the responders have to get creative. The four-state set of SeeClickFix is likely a result of a development team building the application in isolation, without any real-world user feedback. Any commercial issue tracking system will have a “resolved” state. And there are usually rules for using an issue, something like “you cannot close an issue without fully explaining why the issue is resolved”. As I’ve stated in other articles, “closed” and “resolved” are not synonymous. This has led, unsurprisingly, to Sandpoint staff’s predilection to close issues before they are resolved just to get them off the books: more and more issues are closed with statements along the lines of “I’m going to close this issue but we’re still working on it”, an unacceptable situation in pretty much every industry that makes use of tracking systems.

Comprehensiveness: A user can search all issues using any keywords to see issues that satisfy those criteria. Without this capability the application is effectively lobotomized. 

In addition, you need an involved and transparent responder group. With rare exception, I would characterize the city’s responses to issues as pretty much the opposite of transparent, from uninspired to downright defensive or obstructionist. 

Recently, the city has started closing issues and preventing them from being reopened, in my experience a really bad sign.

I believe the SeeClickFix team has an honest goal of providing a really capable tool for cities to use to stimulate dialog with their citizenry. But it’s also my impression that team lacks enterprise experience and has made some fundamental mistakes early on, then launched their product before it was anywhere near what I’d call production ready.

Having spent more than a year using Engage Sandpoint, I find I’m losing interest. The buggy UX, the lack of any ability to track issues because search is unreliable and the behavior of the city — closing issues before any resolution is addressed — are disappointing in the extreme. There are bright spots, like the conversations around south Sandpoint, but these are by far the exceptions. Even those partially successful issues suffer from a certain amount of stonewalling from the city. See the Boyer and Cedar garage sale sign issues for more evidence of that. If they haven’t been hidden.

Engage Sandpoint seems about to follow the guitar I bought when I was 16 so I could become a rock star, destined for the basement closet to gather dust.

David Phillips is a technology consultant/photographer/filmmaker who arrived in Sandpoint from Colorado by way of Seattle and points further west.