Webinar 24: WICHway: A Traffic Management Website

Webinar 24
WICHway: A Traffic Management Website

February 4, 2015

Summary of the Federal Highway Administration’s Quarterly Webinar: Applications of Geospatial Technologies in Transportation

These notes provide a summary of the PowerPoint presentation discussed during the webinar and detail the question and answer session that followed the presentation.

The presentation is available upon request from the webinar speaker Tom Hein (hein@ksdot.org).

The webinar recording is available at: https://connectdot.connectsolutions.com/p35todne1c3/.

Presenters

Tom Hein
WICHway Manager
Kansas Department of Transportation
hein@ksdot.org

Mary Beth Pfrang
GIS Project Manager
Kansas Department of Transportation
marybeth@ksdot.org

Brian R. Sovik
Vice President GIS - Transportation Solutions
Data Transfer Solutions, LLC
bsovik@dtsgis.com

Participants

Approximately 46 participants attended the webinar.

Introduction to Presentations

Mark Sarmiento of FHWA thanked participants for joining the webinar. This webinar was the 24^th in a quarterly series of FHWA-sponsored webinars. The series deals with the application of geographic information systems (GIS) and other geospatial technologies to transportation. This webinar focused on the development and application of the WICHway traffic management website, developed by the Kansas Department of Transportation (KDOT).

Presentation

Background
The WICHWay website (now KanDrive) https://kandrive.org) is an external-facing traffic management website for Wichita, Kansas. Pulling data from 21 dynamic traffic signs, reports on road conditions, construction activities, and traffic (all reported through Kansas' 511 data), the site allows Wichita residents and visitors to quickly access traffic and road condition information.

The current WICHWay website, launched in October 2013, is the result of a fast-paced request for proposal (RFP) and an Agile Development process that began in late 2012. The site was a redesign of KDOT's internally-developed website, which launched in 2011 but lacked the mobile functionality and ease of use of the current site.

Project Goals
KDOT recognized that the old WICHWay website lacked functionality that was vital to time-pressed users who increasingly relied on accessing information through mobile devices. The agency therefore identified WICHWay as a pilot for a statewide system of traffic websites, with the ultimate goal of opening up 511 data for the whole state.

More specifically, KDOT wanted to improve the following issues with the existing WICHway website:

Slow loading times
Single-screen layout
Incompatibility with mobile devices
Complicated interface to add/remove layers
Camera tours and road conditions on separate page

By contrast, KDOT wanted the site to:

Be accessible from a mobile device
Load faster and provide access to data
Be valuable for multiple user types

Contractor Selection
KDOT prepared an open-ended request for proposal (RFP) with multiple options for web-design and GIS contractors to consider. KDOT didn't require a specific design, but wanted the following options considered: cloud based applications, smartphone applications, website redesigns, streaming video, and text messaging. The contract was awarded to Data Transfer Services, LLC (DTS) in February 2013, with the agreement to deliver the final code in August 2013.

Development Guidelines
Both in order to accelerate the development process and to ensure the end product met user needs, DTS worked with KDOT to run an agile development process for the website. DTS identified the following features for a web-enabled application (hosted via a website, not as a standalone mobile application):

ESRI browser, SQL Server
HTML5 environment (with JavaScript built-in)
3 layouts for computer, mobile phone and tablet
No GIS as a lot of users don't know how to use layers
Multiple maps, instead of large one with multiple layers
Static maps that update frequently (every 2 minutes)
Scalable to 3,000 simultaneous users

The agile process focused on 4 user types and the project team made sure the website was designed around their needs and that access to the information most important to each was simple. Through focus groups, KDOT and DTS identified the key users as:

Commuters (day-to-day)
Travelers (vacation)
Truckers (long-haul)
Weather watchers (might only look one day/year)

Agile Project Management
The core of the agile project management process was a weekly standup meeting involving KDOT IT architecture, IT security, and GIS teams, the intelligent transportation system team, content designers from DTS, the project managers (DTS and KDOT), and various other users depending on the meeting focus. These meetings were complemented by iterative design sprints, each of which lasted two weeks and focused on specific aspects of the design or specific outcomes. At the end of each sprint, the project team released a version for review.

The group used a Microsoft SharePoint website for document storage to ensure that all documents were consistent. The development timeline followed a well-developed schedule, with daily meetings for the design and coding team. Despite the fast timeline, the daily backlog of tasks was never more than a day behind.

Throughout the process, DTS conducted workshops with target end-users to make sure they were capturing these users' needs quickly and efficiently. These workshops often involved wireframes of the website, allowing the coders to quickly make changes and to have a strong focus on the design early on in the process.

Website Launch
Thanks to the rapid development process, the website was ready for launch in August 2013. The new website features an initial, static map that refreshes every two minutes, and users can bookmark maps for quick access.

The final tool was launched as a website with multiple layouts for mobile and tablet users. Ultimately, a separate mobile application seemed difficult to maintain and heavy handed for a smaller community like Wichita. Due to the static maps and its streamlined design, the website has successfully passed load testing for 3,000 simultaneous users.

Initially, some training for public users was necessary to make sure users knew how to access and use the website quickly. KDOT developed a short, instructional video and posted it to YouTube, to share with the initial roll out.

Uses and Next Steps
The launch of WICHWay was a significant success for KDOT, which is now evaluating options to launch the system statewide. The KDOT team that worked on this project also benefited from learning about Agile Development, and the team is now considering using it as a framework to manage other projects.

Some lessons learned from this project include:

A rapid development process requires strong organization and preparation. For example, meeting notes were critical for those unable to attend each weekly meeting. Likewise, it was critical to make decisions on content before moving quickly through the development process.
Make sure stakeholders are very devoted to a project during the 2-3 months when it is being built. The time commitment may be limited but is ongoing and requires regular input.
Build contingency into the schedule, in case of uncertainty and changes in the team composition.

Question and Answer Session

How many members were there on the code development team?
There were anywhere from two to four programmers on the DTS team at any given time, depending on the weekly requirements. In general, approximately six KDOT team members worked on back end requirements at the same time (e.g. camera feeds, sign feeds, GIS data, etc.).

How many hours the KDOT team put in during the agile process compared to what it might have taken using traditional PMBOK/waterfall methodology?
The hourly commitment really varied depending on the day. During the two week sprints, aside from day-to-day talking, the process probably took about 1.5 hours per two week period. The project definitely went much faster than the waterfall method, though it likely took up more staff time.

Communication and working together was much easier because everyone communicated well: IT, sponsor, consultant, management. Problems were taken care of quickly. The fast development timeline also made it clear that people needed to participate in the standup meetings and keep up.

DTS was not on-site for most of the project, but largely stayed in touch by hosting webinars.

What data is used to show construction information?
Construction information sits on a desktop website, 511. We're also giving information to the website.

What will be done to the pilot to make it statewide?
The landing page would most likely change to provide more statewide data, e.g. we only have travel speed within Wichita. State system roads might also change by region or by district, allowing users to zoom in more to choose a route.

Scaling will be an end-user focused design opportunity. There are aspects of this design that won't scale properly across an entire state or region. The goal is first and foremost to control the website and get information to the public.

Are the desktop and mobile version separate websites or one responsive site?
It is one responsive website that switches between the mobile view and desktop view depending on the device.

When did the website go live?
The site went live in September 2013, but we publicized it starting in November 2013. We have Google Analytics that we review every month, and so far have had no downtime.

If you had to share the two most common points of feedback from the public to improve the site what would those be?
The most common complaint is: “Why can't we see live/streaming video?” We unfortunately cannot address that right now because there are too many users and cameras.

The public would also like to receive e-mails and texts a specific route, e.g. incidents on a specific highway.

What versions of Internet Explorer (IE) are compatible with the site?
We developed for IE 11 and targeted backward to IE 9. I know that IE 8 is used in some agencies, but even in compatibility view it is not supported.