Shiny Tool Prototype Outline

[gotom22]

For April it would be helpful to have a "mock" framework for the tool in shiny, ideally with parts functional. See Wiki for possible tool structure and review various inputs (e.g. @nmaizlish 's work on UI).

I assign @usr110 , but obviously a group effort to hash out.

[gotom22]

align with flowchart development

[JDWoodcock]

@nmaizlish

[gotom22]

I have transferred @nmaizlish wireframes to master flowchart

[gotom22]

Could we rebuild @markotainio mock "trip distance slider graph" presented in call on 3/15 as a shiny input feature? As a scenario pilot gadget?

• first conceptually identify all the data and variables needed
• id which ones user would manipulate
• [x] build a nice little shiny gadget
• then think about how this could be generalized for the other scenario variables (mode split, propensity to walk/bike)

[usr110]

I've just created a simple app which allows users to select a range of the plot (using mouse by pressing the right click button), and then the selected area is displayed in another plot. Please see attached a screenshot

You may run the app locally as: shiny::runGitHub("ITHIM/ithim-r-interface")

This mimics the idea shared by @markotainio to select which trips may be converted into cycling trips.

This is of course proof of concept of the gadget that users may be able to select part of plots to specify a new scenario.

[gotom22]

...speaking like a true non-programmer, I would prioritize along the following order:

1. which features will we need? (ie. what info will the user provide, what info will the tool get from this?)
2. how should these look like? (visually, functionallity, "slider or button"?)
3. (only thereafter) figure out feasibility within shiny (in my experience, most things can be done in shiny)

...I believe above may address 1, but probably needs tweaking on 2. (but you may have had a specific use in mind already)

[gotom22]

@usr110 Nice work!

Some feedback on mock version for Thiago. If you invest time for quick fixes, I think in bold are the priorities. User case study:

• [ ] - city input widget: typo: it say Air Population. (I suggest to just call "City")
• [ ] - sort order of countries? (by acronym?)...see Switzerland under C
• [ ] - city list not populated: warn Thiago (or take from HEAT?)
• [ ] - in file selection widgets, browse button works, but so slowly that basically freezes tool
• [ ] - in tab again "Air population"

Predefined case studies Accra

• [ ] - (why is scenario a radio button?...)
• [ ] - Tab: maybe call it "Travel pattern" instead of "Mode"
• [ ] - chart size different for baseline and scenario. (consider putting both in same chart? like male/female...)
• [ ] - chart currently does not reflect results? (same bars top and bottom)

England

• [ ] - Select % of Population who are Regular Cyclists: prob. better as a slider
• [ ] - Flip histogram is cool. But what is difference between top and bottom chart?

[nmaizlish]

Hi, sorry I missed the call on this, but I am a bit confused. What the bar charts seem to show is the distribution of trips by trip length. This is useful but in the context of scenario generation/comparison, it would be also helpful to see how the distribution changes between the baseline and scenario. For this two series can be plotted together perhaps a smoothed lines. I also think that creating user-selected gradations of complexity may be useful. For example, via radio buttons, perhaps travel distance means or medians might be a choice along with increasingly complex graphs such as these (with the ability to stratify the graphs by mode (walk, bike, total).