VE User Experience

Overview of deliverables, initial plan, and requirements discussion

• Scope/schedule
  • Received NTP last week to begin work on AASHTO amendment focused on user experience improvements
  • AASHTO team is discussing a peer exchange for September/October, so can we have something to share by then?
• Deliverables:
  • Documentation in the wiki of this workshop’s findings and recommendations for implementation
  • Iterative updates to the user interface for configuring, running, and visualizing multiple scenarios at once
    • How do we specify which inputs can be systematically varied in the VE framework and exposed in the UI?
    • How do we communicate within VE model runs in a more programmatic manner than a log file so we can inform the user of progress?
    • How do we understand and query multiple runs from within the UI?
  • Integrated documentation and tutorials
    • Integrated and hidable getting started materials (such as in the RPAT UI) or separate resources (such as an Rmarkdown document or the wiki)?
• Requirements:
  • Some of these are already in the backlog under the Improve End User Experience Milestone and in the UI Design page.
  • For two audiences:
    • beginning VisionEval users with little R experience, 86, 99
    • advanced / power users
  • For setting up and running models: an RShiny-based solution that works with any VE model and can be maintained by modelers with strong R programming skills
  • For visualizing results: maybe RShiny or instead just html/javascript so it is more lightweight and can be hosted by GitHub pages
  • Provides multiple scenario visualization capabilities, 98, 97, 96
  • Integrated documentation and tutorials, 159
  • Tested and versioned like all VE resources
  • In addition to running locally, also have a demo model in the cloud – for example, visioneval.org/demo, 184
  • Implements a clean interface between the R models and the GUI runner + visualizer, 91, 154
    • HTTP messages, start+stop text files, etc?
  • Needs to output a CSV file of visualizer input data in addition to visualizing the data so user's can load the data into their own tools (Excel, Tableau, R, etc.)
  • Seed later module inputs with results from earlier modules so we don't have to re-run everything (i.e. use the same hh module results for a set of travel module runs)
  • What’s the relative importance of aesthetics versus features? Aesthetics are important, but functionality must be correct, and the current pilot GUI and Scenario Viewer are not quite what is needed
  • Maybe we need a "scenario generator" that builds and checks scenarios? Maybe the user specifies a low/med/high range for input files and then the UI builds X intermediate states?
  • We need a simpler set of outputs for the beginner user - just a couple key plots of VMT, GHG overtime etc.
  • We need to think about the groups of inputs and outputs and how they map to input files. These meta groups are key to the user experience from start to finish, including documentation.
  • Different experiences for different users is a key requirement

Review of inspirational examples

• Select sites from showmeshiny – Ben
  • UI, aesthetics
    • pemDemo - clean interface, controls on the left, results on the right, workflow on the top, static graphs so it is not too interactive (and nonlinear), too much interaction can be laggy
      • maybe we have a basic view (default) and advanced (that you click to show)?
    • BMOP - similar to the pemDemo but includes maps
  • Maps
    • NZIPR - not a lot of good RShiny map examples, PlaceTypes USA has maps
      • could do maps for VERSPM since it has bzones, is nice to show spatial data if possible, use leaflet probably
  • Cloud-based demo
    • shiny io - we would need to pay month for Shiny server online hosting, or host ourselves, so long term that may be an issue, but we all really want an online (atleast demo) version
• Documentation and Scenario Analysis - Tara
  • Input documentation management - groups inputs by meta categories, allows for switching between VE modules, show/hide details
  • ODOT SARSPM - cover basics for how ODOT’s scenario planning process works for local planners (not appliers)
    • includes very handy Checklist in the appendix
  • TFL model variables - Liming's table of model variables is helpful for understanding what variables influence what parts of the model
    • should be able to build something based on the VE input, output lists
    • documentation should be in a separate window from the UI so the user can see both at once (like in the wiki or a new browser tab, etc.)
  • Query language for outputs and summary_state_measures.csv - run R commands against outputs to create CSV file of metrics for use in Excel, etc.
  • Statewide scenario analysis I1, I2, I3, I4, I5 - again, meta groupings of inputs and outputs, calculates metrics relative to a base case, allows for filtering scenarios by inputs/outputs
    • sort of like using the model as a solver - set a target and allow inputs to vary within constraints
• Wizards, wire-frames, aesthetics - Kevin
  • TF Guide (Method Selection for Travel Forecasting) / NCHRP Report 852
• FSDM RShiny user interface – Brian

Finalizing the plan – 12 to 1 – Ben

• What’s our recommendation for implementation?
  • UI design
  • UI model interface
  • Documentation integration
• What are the most important next steps?
• How do we parse our plan into agile iterations of improvements to a working user interface?
• Who will test the user interface and provide feedback?