Final UI: site-level zoom

[Siequnu]

Will inevitably have to have some kind of map, to display routing and other overlayable information.

But might also display an interesting and visually appealing selection of graphs, showing other disparate data. @Robinlovelace has done a great job of coming up with different graphical representations, in this issue I'd like to compile a list of these that we feel are appropriate to adequately describe a site.

actdev/#91 is attempting to compile metrics used for a ranking, here I'd like to confirm those which should be visible at the site-level zoom.

I'd start with:

1. Map with control for overlays
2. Idas for specific (bar charts)/ etc?

[mvl22]

I think the three key data components seem to be:

1) The overall site summary parameters, which are those metrics (https://github.com/cyipt/actdev/issues/91) and as visualised in the quick bar charts currently (https://github.com/cyipt/actdev/issues/85#issuecomment-779332042) 2) The cycle-friendliness of the surrounding areas, as expressed I think quite clearly in Robin's dartboard concept (https://github.com/cyipt/actdev/issues/85#issuecomment-779213866) 3) The busyness level of the routes (currently shown rather crudely as the route network data (https://actdev.cyipt.bike/routenetwork,studyarea/#12.05/52.17051/0.13983)

It feels to me like these collectively should form an indication of the accessibility of the development.

I remain a bit concerned that we're not really judging the site layout quality itself but concerned more with the access to/from the site.

[joeytalbot]

The overall site summary parameters, which are those metrics (cyipt/actdev#91) and as visualised in the quick bar charts currently (cyipt/actdev#85 (comment))

Absolutely. All of the metrics listed in https://github.com/cyipt/actdev/issues/91#issue-809320072 are relevant at the site level. As long as we can avoid over-cluttering, all of them can be visible in the site-level UI, either in the form of bar charts or other infographics, or as simple headline figures.

The cycle-friendliness of the surrounding areas, as expressed I think quite clearly in Robin's dartboard concept (cyipt/actdev#85 (comment))

So far we have two methods of showing these dartboards. They can either be shown independently as infographics, or they can be shown as overlays on a map. If they are shown as overlays on a map, I think they work best when the routes (from which the dartboard zone values are derived) are also visible on the same map.

The busyness level of the routes (currently shown rather crudely as the route network data (https://actdev.cyipt.bike/routenetwork,studyarea/#12.05/52.17051/0.13983)

For the route networks, we want the line thickness to correspond to the number of journeys (in a way that is consistent across sites), and the line colour to correspond to road busyness.

[joeytalbot]

The summary metrics aim to capture the gist of the information which is shown in more detail in the dartboards and route networks.

[joeytalbot]

I remain a bit concerned that we're not really judging the site layout quality itself but concerned more with the access to/from the site.

This is a tricky one. We have been looking at routes to and from the sites, so naturally the major part of those routes lies outside the site itself.

But I think access to/from the site is in many ways more important than the site layout. For a start, in sites that haven't been built yet it's impossible for us to judge the site layout. Elsewhere (such as Chapelford), developers often spend lots of time creating pretty cycle lanes within the site, but these end up entirely unused because there's nowhere worth cycling to. Problems with crossing the 'red line' of the site boundary are well known to be common. This is where we can be of more help.

If there are any more metrics we could usefully add, the best one I can think of is the number of locations in which our mapped routes cross the site boundary. A site with just one crossing point is probably very cut off from its surrounds. In fact, I'll add that right now.

[joeytalbot]

I remain a bit concerned that we're not really judging the site layout quality itself but concerned more with the access to/from the site.

For sites where we have the internal road layout, our assessments of route circuity (both the headline metrics and the inner dartboard zones) will include contributions from the portions of the routes that lie inside the site.

We could also calculate some kind of circuity or network connectivity measures that are derived solely from roads within the site boundary.

[mvl22]

developers often spend lots of time creating pretty cycle lanes within the site

I think the issue though is that these are under the control of the developer, whereas links to places 2km are often not. And, moreover, the developer should provide an internal layout to the best possible quality, so that if the Local Authority later gets the surrounding area improved (perhaps as a result of S106 money partly from the developer), then that infrastructure will come into use.

but these end up entirely unused because there's nowhere worth cycling to

Yes, there is a lot of truth in that. Example just now from Cambridge - note the 'missing link' location. There seem few concerns about the internal site layout, but it's this interface just at the edge of the site that, like so many sites, is poorly conceived.

https://www.camcycle.org.uk/blog/2021/01/netherhall-farm-proposals-will-lock-in-car-dependent-future/

[joeytalbot]

Yes, there is a lot of truth in that. Example just now from Cambridge - note the 'missing link' location. There seem few concerns about the internal site layout, but it's this interface just at the edge of the site that, like so many sites, is poorly conceived.

This example would be nicely captured by both our overall route circuity metrics and a metric of 'number of points where routes cross the site boundary.'

But what do you think about also including a metric focused on the circuity or connectivity of the roads within the site?

[joeytalbot]

One thing we haven't mentioned yet - I have photos of some (but not all) of the sites. These clearly show some of their key aspects and problems. Where possible, we should include these photos.

[joeytalbot]

Also, do we want any links to StreetFocus / PlanIt / information about planning applications?

[Siequnu]

One thing we haven't mentioned yet - I have photos of some (but not all) of the sites. These clearly show some of their key aspects and problems. Where possible, we should include these photos.

How many of these do you think we'd put in? One photo could be embedded in each page, alongside the headline figures for example, with a placeholder (and call to action) for a site that doesn't have a photo. Alternatively, a carousel would provide a scrollable list of visuals.

[Siequnu]

Also, do we want any links to StreetFocus / PlanIt / information about planning applications?

This is a great idea, and we have to make sure we insert those links in a sensible way. Would these be three separate actions?

In this issue I'd like to get an idea of the total amount of elements/modules (map(s), graphs, photos) so that I can start to arrange and order these in a sensible way.

[Siequnu]

These are the site-level zoom page elements suggested so far:

1. Site summary in headline figures and one or more graphs, using metrics still be formalised.
2. Cycle friendliness dartboard
3. Route network lines
4. Photo(s) of site
5. Links to external pages (StreetFocus, PlanIt, etc).

Regarding the first element, issue 91 currently has 11 metrics with potential for more in the future, which I think is too many to display in our summary headline figures. Could we get a subset of these, 5 or so? The adjunct set can be displayed in other ways, rather than burying them, in for example a more informationally-dense part of the page. But it would be good to separate the corn from the chaff at this stage.

For example:

1. Overall composite rating - is this the headline stat/grade?
2. 2011 Walking & Cycle mode share
3. Route circuity
4. Site boundary interpolations
5. Suggestions?

[joeytalbot]

How many of these do you think we'd put in? One photo could be embedded in each page, alongside the headline figures for example, with a placeholder (and call to action) for a site that doesn't have a photo. Alternatively, a carousel would provide a scrollable list of visuals.

For some sites like Chapelford, it'd be worthwhile including several photos to show different aspects of the site. A carousel could work for this. But there are also many sites with no photos that would need a placeholder.

[Siequnu]

Here are 3 site-level zoom concept proposals.

In a separate posting at https://github.com/cyipt/actdev-ui/issues/15#issuecomment-782863993, the A/B street integration is discussed, which would apply to all three of these concepts.

1. Modern infographic style

➕ Modern infographic/dashboard style with a focus on typography ➕ Brings the key metrics to the fore ➕ The three smaller graphs are toggles that affect the map, combining both infographics and buttons ➕ Contextual layers can be more easily enabled ➖Smaller map size

2. Card concept design

➕ Larger map ➕ Cards can overlap, and have a hierarchy, giving more space to interact with the details ➖Not as well established on desktop as mobile — may feel slightly jarring

3. Side-bar overlay

➕ Larger map ➕Traditional concept may feel more familiar to practitioners ➕Immediately visible gallery, to give a flavour of the site ➕Use of expandable elements increases the size available for manipulation, but at the expense of discoverability ➖Traditional concept and map size makes infographic less prominent

We would prefer numbers 1 or 3. What are people's thoughts?

[Robinlovelace]

1 and 3 both look good, and not too disimilar: a map on one side and a UI + infographics panel on the side. Great work on the design, I think this will look amazing. 2 questions that should help in the process of taking this from conceptual design into deployment:

1. Is it possible to have a side panel that expands/contracts? In the PCT there is a small 'Hide' button that can hide away the UI options, useful for small screens and when people want to focus on the map (another alternative could be to add an 'expand' button to the map to make it go full screen, there are probably other solutions enabling people more focussed on the map to reduce the size of the 'infographics panel'). If it's possible to reduce the panel I would err towards 1 otherwise 3.
2. Is it worth creating embeddable JS/html versions of the infographics, e.g. like this (note you can interact with the stacked barchart making it more lively than a static .png image and these can be created with one extra command ggplotly(ggplot_object) in the code that generates the infographics)? I guess so.

Here's the Hide button of the PCT in action in any case (source https://www.pct.bike/m/?r=west-yorkshire )

Overall really happy with the design. Look forward to seeing it implemented!

[mvl22]

I think this will look amazing

Thanks 🎉 :)

We've worked hard to take the clarity that the workshop last week gave on needs/requirements, and turn those into concepts that try to get a clear set of messages across through a curated layout. They try to tell as story and highlight the important things, in a way that the alpha (a load of layers bunged on a map with equal importance, and no orientation for the user) doesn't really do. There's definitely more work to be done to try to help guide people through that story, but I hope you agree this is going in the right direction.

1 and 3 both look good, and not too disimilar: a map on one side and a UI + infographics panel on the side.

These layout concepts were interestingly approached from very different starting points: 1 started with a blank canvas on which we added summary data and then added a map panel, whereas 3 started with a map onto which we added controls, i.e. the other way round.

1 is conceptually intended to be more like as a flat dashboard which puts the infographics and data first, and the map as one panel within this, taking up just under half the page.

3 is more like a full-screen map with a Google Maps style panel floating over it on the left, so the map is more important, at the slight expense of the summary data.

Is it possible to have a side panel that expands/contracts?

I think in the first instance we'd want to ensure that the eventual design works well on all screens as the starting point. We've deliberately started the design concepts as desktop-first rather than mobile-first, as this is a site primarily for practioners who are likely to be using real computers, but the mobile view adjustments will naturally be developed once the overall concept is decided on by the team.

In terms of map size, I would suggest that we aim to make sure the core design fundamentally has a large enough map to feel easily-usable without needing to have expand/contract type controls, which might indicate that the layout itself isn't working well. Also bear in mind there is linkage between the panel and the map - in the case of layout concept 1, the smaller infographics also act as buttons to add layers (like the dartboard) to the map; in the case of layout concept 3, the expandable panels would include curated sets of tickboxes / other controls that enable those layers (e.g. see the 'Routes' bit opened up).

Is it worth creating embeddable JS/html versions of the infographics

Yes, that's definitely the intention. It's much more useful for infographics to be manipulatable, as per the example you gave, than just a static picture.

You're outputting the data itself nicely, so either we would aim to pump that data into JS from the data files, or you could write them out as embeddable HTML/JS extracts as you suggest.

In terms of keeping development risks low, it makes sense to use the existing pngs as a quick starting point to get the UI running, and then to replace those progressively with the more interactive versions as they become available - that way we could launch any time.

[Robinlovelace]

What are your thoughts on this @joeytalbot ? Keen to get your input as @Siequnu and @mvl22 are keen to crack on with the coding. I think conceptually the feel of the app will benefit greatly from this design work.

[joeytalbot]

Either 1 or 3 look great. One thing to note with the dartboards is that there are potentially several different versions of them, relating to the busyness of cycle routes, circuity of cycle routes, circuity of walking routes, etc.

[Robinlovelace]

Either 1 or 3 look great. One thing to note with the dartboards is that there are potentially several different versions of them, relating to the busyness of cycle routes, circuity of cycle routes, circuity of walking routes, etc.

Great, so I think we're ready to go! Do you want any further input from us at this stage @mvl22 ? Broadly I see this issue as done. Great work on the design.

[Siequnu]

One thing to note with the dartboards is that there are potentially several different versions of them, relating to the busyness of cycle routes, circuity of cycle routes, circuity of walking routes, etc.

Great point — am I right to presume that each would only be displayed individually (or else we'd have colour leaking through), as they represent distinct variables?

[Siequnu]

Great, so I think we're ready to go! Do you want any further input from us at this stage @mvl22 ? Broadly I see this issue as done. Great work on the design.

This is enough to start the ball moving, but we still need to keep working on defining a list of the elements to be displayed, i.e. the links to external sites, headline statistics, etc. I suggest these be packaged in a site-specific JSON file.

I propose these be finished by the start of next week, so that I can have a definitive list of "ingredients". Could @Robinlovelace take lead on this? I.e. the stats, headline figures, external links.

These are the site-level zoom page elements suggested so far:

1. Site summary in headline figures and one or more graphs, using metrics still be formalised.
2. Cycle friendliness dartboard
3. Route network lines
4. Photo(s) of site
5. Links to external pages (StreetFocus, PlanIt, etc).

Regarding the first element, issue 91 currently has 11 metrics with potential for more in the future, which I think is too many to display in our summary headline figures. Could we get a subset of these, 5 or so? The adjunct set can be displayed in other ways, rather than burying them, in for example a more informationally-dense part of the page. But it would be good to separate the corn from the chaff at this stage.

For example:

1. Overall composite rating - is this the headline stat/grade?
2. 2011 Walking & Cycle mode share
3. Route circuity
4. Site boundary interpolations
5. Suggestions?

@Robinlovelace We'll need to liaise regarding your exporting of R infographics into plotly elements — I'll build the initial template with static images, but I hope we can move swiftly to incorporating interactive live data elements instead.

[Robinlovelace]

I propose these be finished by the start of next week, so that I can have a definitive list of "ingredients". Could @Robinlovelace take lead on this?

Sure, will liaise with @joeytalbot and aim to get a reply by the end of the day on this.

[mvl22]

I propose these be finished by the start of next week, so that I can have a definitive list of "ingredients". Could @Robinlovelace take lead on this? I.e. the stats, headline figures, external links.

To clarify, this is just saying we need to get the key metrics agreed. (All the other page components are known about now obviously.)

[Robinlovelace]

@Robinlovelace We'll need to liaise regarding your exporting of R infographics into plotly elements — I'll build the initial template with static images, but I hope we can move swiftly to incorporating interactive live data elements instead.

Can do, lower priority than https://github.com/cyipt/actdev-ui/issues/13#issuecomment-783333859 but should have this by end of week and happy for pngs in the data folder to be used as a placeholder for now.

[Siequnu]

Can do, lower priority than #13 (comment) but should have this by end of week and happy for pngs in the data folder to be used as a placeholder for now.

Thanks, that fits well into the timeline.

[Siequnu]

Here is the latest iteration of the site-level zoom concept. We have merged some of the stronger aspects of number 3 into number 1, including more site-level data, options for the dartboards, a discoverable photo carousel which provides instant contextualisation, and improved the legibility and usability of the page controls.

Your thoughts?

At this point we'd like to gain agreement of the team on the iterated concept in order to proceed to implementation.

[Robinlovelace]

At this point we'd like to gain agreement of the team on the iterated concept in order to proceed to implementation.

:+1: from me it looks great. Caveat/consideration highlighted today by @MeganStreb: there is a lot of info on the screen so advocate exploration of opportunities to reduce the amount to take in, perhaps via interactive UI elements that are hidden by default and pop-out when clicked on.

[joeytalbot]

One thing to note with the dartboards is that there are potentially several different versions of them, relating to the busyness of cycle routes, circuity of cycle routes, circuity of walking routes, etc.

Great point — am I right to presume that each would only be displayed individually (or else we'd have colour leaking through), as they represent distinct variables?

Yes, they should be displayed separately from one another (perhaps with some kind of toggle). It may not be necessarily to include every single version.

[joeytalbot]

The proposed design looks good to me.

[Siequnu]

I have created a new branch of this repo — 'final-ui' — in which you can find a working version (with placeholders) of this site level zoom concept. Good progress is being made: feel free to git pull and check it out

If you change the git branch on your local install you'll probably need to bust the cache to refresh the CSS.

[Siequnu]

The final-ui branch is now merged into master, so you can now view that live.

[Robinlovelace]

Great work, will check it later today. Thanks for great work @Siequnu!

[Siequnu]

This is now live on the main site.

[Siequnu]

One of the next steps here is deciding which stats should populate the 4-5 headline numbers.

These change when switching scenarios so it'd be good to have stats that vary between these two.

[Robinlovelace]

I see this:

Source: https://actdev.cyipt.bike/#13.01/52.17254/0.11733

[Siequnu]

https://actdev.cyipt.bike/#13.01/52.17254/0.11733

Your browser is caching the old .css. You need to force-refresh the page, which will bust the cache and pull in the new .css. This is usually some combination of F5 with shift, alt, or another mutation key.

[Robinlovelace]

Ctl+F5 sorts it on Firefox, you learn something every day eh: https://support.mozilla.org/en-US/questions/1241721

Here's the result, the animated numbers are a nice feature, first impression in terms of priorities: allow the big panel on the left to be hidden away, I guess that's what the left-pointing arrow in the top left is for, right?

[mvl22]

allow the big panel on the left to be hidden away, I guess that's what the left-pointing arrow in the top left is for, right?

No, it's for going back to the list of sites.

I don't really agree with the idea of hiding the panel. I'm not sure why it's necessary, and the ability to hide/show layers isn't then possible either. The map in my view is sufficiently large.

[Robinlovelace]

The map in my view is sufficiently large.

Worth asking users I think. Looking at the map on a small screen:

It doesn't look sufficiently large to me. Another question that may help: what are the downsides of being able to hide the 1/2 screen giant UI element, or is it a technical issue? Alternative could be to allow the user to make the map full screen. Either way I think it's an issue, worth asking others. Good to be open minded and flexible about design choices such as this, dividing the UI into 2 equal sized halves at all times in the 2nd zoom level seems like a pretty major design decision that could reduce the utility of the tool in some circumstances (when looking at an east-west route for example).

[Siequnu]

The premise of the approved design number 1 is

conceptually intended to be more like as a flat dashboard which puts the infographics and data first, and the map as one panel within this, taking up just under half the page.

As opposed to design 3, which is basically a massive map with a vestigial floating panel.

I realise that for the users of the alpha, who have grown used to basically a full screen map, it might be disconcerting for a while with this new concept as it's only been up for a few hours.

This design concept however, was discussed and laid out in the above comments, (proposal, follow-up and second iteration).

I suggest trying it for a while and seeing how it feels.

Going back to the 3rd concept now (fundamentally different) seems like dilution of the design rather than an evolution of the design choices.

To reiterate, the advantage of this infographic style design is that it presents a fresh and appealing way to put the data front and centre. A large amount of the data we are showing, and certainly the main mode split and site headlines, is in no way related to the map element — I think this really shines in this concept.

Small-screen optimisations are further down the line - and I agree that with smaller screens there will need to be layout adjustments.

[Robinlovelace]

To reiterate, the advantage of this infographic style design is that it presents a fresh and appealing way to put the data front and centre. A large amount of the data we are showing, and certainly the main mode split and site headlines, is in no way related to the map element — I think this really shines in this concept.

There is no issue with the infographic UI element, it is cool and more importantly useful for assessing sites,as we all I think agree. The question I'm asking is whether it should be dockable or enforced as 50% of the screen regardless of screen size and user preferences as they interact with the data, and go beyond high level ratings to the detail of particular routes and exploring the higher resolution data? Dockable sidebar elements seem pretty standard in modern web UI, including in this demo https://svelte.dev/repl/03f0be0c4dc54eb4af5a168f644f5c31?version=3.19.1 - see good write-up here: https://dev.to/joshnuss/creating-a-sidebar-menu-in-svelte-ih2

And in the prototype JTS explorer: https://apps.saferactive.org/actdev-shiny-demo/

I imagine making the UI reactive could be technically challenging, where does all the stuff go. But I see big benefits associated with being able to hide the all the infographics (or conversely going full screen on the map) and very few negatives (main negative that comes to mind is additional compexity but a single extra UI element seems a small price to pay for the extra flexibility and map real estate that could be offered to people who want to dive deeper into the map data). Concepts and everything can stay the same, it's just making the app more flexible, useful for people who want to focus on the map (perhaps after having absorbed all the great headline info from the infographic UI), and usable for people landing on the web app from devices that have small screens. I suggest we discuss this Monday next week to scope out potential pros, cons (perhaps there are negatives I've not thought of, open minded and happy to hear of them) and potential work-arounds.

[Siequnu]

Dockable sidebar elements seem pretty standard in modern web UI, including in this demo https://svelte.dev/repl/03f0be0c4dc54eb4af5a168f644f5c31?version=3.19.1 - see good write-up here: https://dev.to/joshnuss/creating-a-sidebar-menu-in-svelte-ih2

The examples you link aren't the same thing — they are navbars (aka hamburger menus or sidebar menus), a navigation element used for top-level navigation. Hamburger menus have grown in popularity over the last 5 years, although they started as a mobile concept and have been back-ported to desktop. This is a fundamentally different concept to our infographic, which is a main page element in itself. It's not a sidebar.

enforced as 50% of the screen regardless of screen size
Small-screen optimisations are further down the line - and I agree that with smaller screens there will need to be layout adjustments.

Hiding the infographic is not a technical challenge in the least - but it is a fundamental pivot in the language of the design, coming after several weeks of mockups and discussion.

I'm not aware of the UI meeting on Monday (so please share details), but I suggest this question be closely scrutinised, and I agree this is best suited to a live chat.

[Robinlovelace]

Adding a button that allows the user to hide/show the infographic doesn't sound like a huge change to me. Yes one to chat about and in the meantime any other +s/-s of adding such a UI element welcome.

[Robinlovelace]

A bit more feedback after testing it this morning with my partner @katygregg: she said the left panel looks disproportionately large. This is a separate point but is of course related so posting here. Note all the empty real estate in the left of the image. I could of course be filled with other things but I suggest that, in addition to being dockable, the size of this left hand panel is reduced slightly, e.g. to something like 30% or 40% of screen width.

[Siequnu]

Note all the empty real estate in the left of the image. I could of course be filled with other things but I suggest that,

What's in the screenshot is another CSS cacheing issue, I've changed this specific layout yesterday so this space should not appear (see below for current version).

Make sure to refresh your CSS, your browser is obviously aggressively cacheing this and it might be worth getting into the habit of force refreshing as this is a developmental build and a lot of things changing, and this has happened to you a few times already.

[Robinlovelace]

Still a fair amount of empty space on my widescreen monitor.

[Robinlovelace]

Also I think the site name and "Current/Go Active" button are disproportionately large.

[Robinlovelace]

(That was after refreshing the cache in Firefox, will try on Chrome.)

[Robinlovelace]

OK git it going on Chrome - on a small screen there is an issue the the left panel needs to be scrolled to find the important new layer elements, they are hidden from the user when they first land on the site:

[Robinlovelace]

On a bigger screen there is still quite a lot of empty grey space in the left panel and, to my surprise, you still have to scroll down to see everything in the UI element. Quick way to improve that: reduce the "Great Kneighton" title and the scenario button (which otherwise looks and works great):