SSP currently has the pleasure of working with an electric utility to design and build a Web-based solution to create and manage work orders associated to streetlight repairs.

It has been a valuable opportunity to learn and grow experience with the evolving technologies enveloping utility GIS these days.

Where the standard issue to the front line personnel is a tablet or smartphone, this post shares some of that experience given that utility GIS operations and workflows are exploding beyond the traditional IT / toolset boundaries.

Client Requirements

For this effort, the client requirements focused on a solution that would provide a lightweight, easy to use and easy to manage system. The organization’s internal network and protocols for user authentication, the enterprise Geodatabase and browser-based maps, user interface and input forms were the core elements to guide a final design.

The client required an efficient means to locate, enter, and manage work orders for streetlights in need of repair flagged by the public, public safety personnel and the company’s field crews. External reports of streetlight problems would be funneled through traditional customer representatives, and field crews would have the ability to initiate work orders on their own from the field.

The Web-application would need to be the same for both internal desktop users and the tablet-equipped field crew. Field personnel would require a VPN connection to the company’s network.

Never the Straight Line

It is always an interesting path to take when people get together to custom build an application that is intended for an array of end-users in an organization. From initial premise to a deployable application, it is a twisty adventure – requirements evolved, technical approaches shifted, obstacles presented themselves.

For example, the initial approach included Web tools to be built using ASP.Net coupled with some Desktop GIS customizations. Ideas then migrated to possibly using the ArcGIS Web AppBuilder and AppBuilder wijits but given the requirements we evolved our ideas in the approach.

ArcGIS Server published maps and feature services were always going to be central to the solution – two means of adding layers to the map were utilized.  Cached map services were added via a basemap array while other layers were added with custom code via an array of dynamic map layer URL strings.

Both arrays were added in such a way that they could be configured by the client without touching the code. The Web-application would be authored with Javascript and the Javascript API. A Javascript configuration file would be central to managing various aspects and parameters of the application so that on-going administration will mostly be made via the configuration file.

Adding data elements, changing presentation and application behaviors to some degree will be via configuration.

A major shift in direction involved the notion of having non-GIS personnel make direct edits to the Streetlight object in the Geodatabase. Given field observation or the results of repair work, it was desired to have that information captured at that time, “Hey – Let’s have field crews make direct edits to the Streetlight object as it resides in the Geodatabase.”

Performing edits to the Streetlight ArcFM feature class proved troublesome on a number of levels, especially given that the feature class participates in the geometric network. Also, it came to pass that having non-GIS users edit enterprise GIS data may not be a good idea.

End-User Assumptions

So, that last item is interesting in that you really need to know and understand the end-user as their frame of reference is completely different than those that work with GIS day-in, day-out. There were some pretty optimistic assumptions as to how the end-users would interact with the application and the data.

Exposing the application to the end-users and going through the test cycles had us re-think functions, workflows and edits to data. And I’m not blaming the end-users, it’s the “professionals” that had some flawed application design elements.

GIS professionals are not building applications for GIS professionals as it were not that long ago; we’re building applications for a varied work force across the organization where the GIS app needs to align with and not burden primary job functions.

Other challenges and items to note based on this effort … 

• Minimize login / authentication burden on the user: end-user authentication to access the application, application services, the database and to address other requirements proved to be a learning experience. Some user logins were to be read-only and others allowed to edit work order data. Editor tracking was desired to capture some basic meta-data regarding edits to the database. The requirement to use various browsers meant understanding the various means of passing authentication parameters.
• User Interface:  it required a few cycles to “tweak” the UI; it evolved over time to become cleaner, streamlined and as intuitive as possible – initial cracks at this missed the mark. Building functions to have them work is one thing, to deploy an application that is effective to get the job done is another level or two (or three) in effort. A representation of the target audience needs to participate early and often from the initial requirements gathering, through design/development and testing – then hopefully they are your champions going forward (not to mention, the power users, trainers, troubleshooters, etc.).
• Keep It Simple:  the endurng adage is spot-on. There is probably a tendency to add nifty controls, widgets and functions to elevate the cool factor, not to say there is zero value adding useful controls and capabilities. I suppose a lesson learned is to keep functions and controls at a minimum in the first few releases and after the organization has used the application for awhile, get *THEIR* feedback on what will enhance the user experience and business operations.

As this is an on-going endeavor we will update this post with additional findings and technical details.