We need to setup a workflow for copying the static and dynamic (htmls) to the backend server.

• Change /osmcha-frontend/ url in package.json to / for production
• change all the links to / for production
• handle the case when .com/:id comes and convert it to .com/changeset/:id
• make osmcha backend for this.
  cc @batpad

• The link to iD is wrong, it should receive the coordinates of the current map view or of the first changeset map view, example: https://www.openstreetmap.org/edit?editor=id#map=15/-4.5650/-37.7613

• The OSM option is duplicated.

It would be great if we could poll the changeset list and see if any change sets arrived since the user last refreshed.

Following up from #11, let’s use this ticket to iterate on the Changeset list:

(Initial mockup)

Based on my discussions, here’s the list of fields in the order of importance:

1. Verified status — Not reviewed, harmful, not harmful (Helps to skip already verified changesets)
2. Changeset comment (Most descriptive: reverts/HOT tasks vs gibberish/foul language etc.)
3. Count of added/modified/deleted objects (Gives context on the scale of the changeset)
4. Flagged reason
5. Date created
6. Tags added by user (Not as important in the list view)
7. User name (Might have cues like gibberish characters, or suffix like _revert)
8. Changeset ID (Helps to lookup details on other apps, but not as relevant to see in the list)
9. Verified by username (Useful in only edge cases)

Apart from this, a state change (visual attribute) that shows:

• Changesets not opened yet
• Current changeset being viewed (selected)
• Changesets that have been opened

Here’s the mockup with the above details:

Specific details:

• Bar on the left indicates verified status (Harmful, not harmful, not reviewed)
• Background color of list item + font-weight of comment indicates opened/selected state

cc @kepta @ajithranka @batpad @geohacker @Rub21

We might need to do a cross store update for these kind of cases.

The current sidebar is peppered with so many colours that it becomes a bit overwhelming to grab necessary information.
I feel adding emojis (which people are familiar with) and icons would help reduce the information clutter.

cc @rasagy @geohacker @manoharuss

currently call url constants are scattered, it would be better to have a consolidated file for them.

Creating this ticket to track user page related things.

Fetching multiple files from the same folder requires multiple lines.
An index.js which exports such things would really help.

And whether we use pushState "real" URLs or # parameters.

cc @kepta @ajithranka

cc @kepta

We need to discuss and implement proper keyboard shortcuts for everything .

Currently to filter by action and type requires to use the cmap options.
We would like to move them to osmcha to be better aligned with the design.

To speed up design & development time, I think it might be useful to rely on a react component library instead of using assembly. AFAIK, assembly does not have an extensive library of React components.

Let's assess these

• React Bootstrap: https://react-bootstrap.github.io/components.html
• React Material UI: http://www.material-ui.com/#/components/app-bar
• React Semantic UI: http://react.semantic-ui.com/introduction
• Grommet: https://grommet.github.io/docs/components

Some considerations

• Ease of designing responsive layouts
• Extensive collection of complex form components
• Stability and popularity of the library

Ref #8.
cc: @kepta @rasagy @batpad @geohacker

Currently the mobile view is in denial, we might need to fix mobile related issues.
I will add all the minor issues related to mobile and small screens here.

Last month, we did a short user feedback session with the data team that have been actively using OSMCha for the daily validation work. Using this ticket to document what was discussed and planning next steps.

Here are the key pain points that were highlighted in the conversation:

BBox + Filter

• Favorite filters: No easy way to keep track of filter combinations that one might use regularly
• Notifications: No way to know if there are new changesets for a particular filter — especially useful with one/multiple bbox set as my area and get notifications for new results
• Logic operators: Can’t exclude certain values/filters using a NOT (!) operator
• Tag-based filters: No way to extensively filter for a particular tag, like looking for all changesets that add fire hydrant(s)

List of Changesets

• Auto refresh list: Once some changesets are checked, the list doesn’t auto-refresh, so you need to refresh everytime — which is slow if there are several changesets in the result
• Pagination controls: You can’t control how many changesets show on each page (set to 15) or jump pages quickly (without editing url) — which makes some low signal queries hard to parse through
• User details: Apart from user name and changeset comment, showing more user specific details (like user ratings from HDYC, edit count etc.) can help identify potentially harmful edits quicker

Individual changeset page

• Multiple tabs: Due to the slow speed of changeset map (or loading errors), folks in data team tend to open multiple changesets in tabs (~3) in one go so the others load while they examine one.
• Discussions: Not seeing changeset comments in this view means they might spend a lot of time on a changeset that might already have been flagged by the community

Changeset details & actions

• User details: Generally head to OSM to see join date, description, edit count, diary post count, active blocks + history
• View changeset in OSM: This helps see any major visual breakage on a map quickly — the OSM map style shows more detail than Mapbox Streets/Dark style
• View feature list in OSM: In some cases, it helps to see all the features, not just the suspicious ones
• Opening in JOSM: For complex changesets, opening directly in JOSM doesn’t work (slow/too large bbox) — instead folks in data team tend to zoom into particular part of changeset in OSM or select a feature from the list and then load that bbox or feature in JOSM
• Actual reason vs possible reason: No way to specify what was actually wrong in the changeset (for analytics or machine learning)
• Tracking status: No way to track if something that was marked harmful was fixed (reverted), or still not reverted, or get notifications if there’s an activity on the changeset (this would be a workflow overhead though)
• Tracking action: No way to specify what was done: was a harmful changeset reverted completely, fixed (partially), comment was left on changeset or something else
• Leaving a comment: No way to quickly leave a comment, so tend to go to OSM comments for this

Mark as harmful/valid

• Actions: They generally don’t mark all valid changesets, only the harmful ones

cc @batpad @geohacker @ajithranka @kepta @willemarcel

cc @ajithranka @kepta

We need to handle some forbidden operations, like when the user tries to check or tag his own changeset or is not logged in to check/tag another user's changeset. We could show an error message or just hide those buttons.

I got started with some quick thumbnail sketches to highlight key information+states for each step of the flow, and explore UI patterns that we can use.

Details of each concept

A) Tabs or wizard like breadcrumbs:

Split the three major steps — Filter, List, Details — into individual tabs, with either some tabs disabled (no details till you select something in the list) or visual cue of which step of the flow you are, and what you can jump to (filled/stroked circles).

What works:

• Clear mental model
• Highlights the major steps: Filter, Select, Explore

What doesn’t work:

• Tabs are usually mutually-exclusive, and the relation between the tabs isn’t as evident
• The actual workflow is non-linear, so can’t use a wizard/step-by-step interface — you might jump into the second step (link to results of a filter) or last step (link to a changeset detail)
• Leaves no context to quickly jump across changesets — you need to switch tabs to go next

B) Vertical Accordions

Each section expands to the full screen, with one vertical bar each for the other sections. Allows you to hover on the bar to get a glance of that section, which might be helpful in switching from details view to list of changesets and jumping to another changeset.

What works:

• Allows you to get a glance of the previous section
• Can glance at the whole list of changesets and jump around easily

What doesn’t work:

• Narrow column width for glancing would limit what can be shown for each section while keeping a consistent layout
• Collapsed states can’t be used to show any detail (except icons or vertical text)

C) Horizontal Accordions

Similar to above, but with the sections stacked horizontally. The bar for filters could show the specific filters that are being used, and the bar for changeset list could show the selected row (and more rows on hover/glance)

What works:

• Easy to use a consistent expanded and collapsed layout
• Better context for both filters and list
• Scope for better transitions

What doesn’t work:

• There’s lesser real estate on the Y axis (on a typical wide-screen monitor), so this will take significant screen space to show detailed collapsed sections
• The changeset list won’t be easy to view completely in a glance (only a few rows on hover)

E) Map based

Shows bounding box of each changeset in the search result on a map, and allows you to hover to see basic info and click to see details

What works:

• Orients you geospatially — could be useful for users that are focusing on one area regularly
• Bigger changesets (that could correlate to more impact) will be easier to spot
• More details could be shown by adding visual properties to the bbox: thicker bbox for high number of features, colors for more additions/modifications/deletions etc.

What doesn’t work:

• Might get very complex for low zoom levels or high number of changesets
• Would be difficult to interact with overlapping bbox

Hoverable Edge Panels

Both Filters and Changeset list collapse into small panels on the top and left edge, and hovering on each part shows more details (change existing filter or view detail of other changesets in the list)

What works:

• Allows quicker modification of filters
• Persistent view of changeset list

What doesn’t work:

• Not too valuable to have such interactivity for each part of filter & list
• More value in parsing through the whole list at once instead of hovering on each item

Conclusion:

We’ll go ahead with (C), and I’ll work on more detailed designs that I can use to get feedback from users.

cc @ajithranka @kepta @batpad @geohacker

for a version 1 we can squeeze this in.

what do you think @batpad

The default list of changesets reflects all changesets, which means the most recent ones will have data that is still being processed. We should hide these so it doesn’t get confusing for people — in any case these won’t be usable till we fetch all the details.

cc @batpad @geohacker @kepta

We are almost there with the existing osmcha.
Couple of things that need to move before we start beta testing the app, next week.

Login

Changeset Details View

Changesetmap

Sidebar View

Filters View

Add tags

Suspicious Feature

Miscellaneous

• Fresh data: Get fresh data from backend
• Fix map style: changeset-map map style doesn't work atm.
• Page ref in urls.: show the page in url ?

cc @batpad @ajithranka @rasagy @manoharuss

• Reasons drop down v stops working (nothing happens on clicking) after adding 2 reasons
• If you add and remove reasons, then clicking on drop down gives no list

cc @kepta

Listing things that we should try to include (must have + good to have) when we release the new beta.

1. Good About page: More detail about what the tool is, what validation is about, what flags mean, and a bit about repo, licensing + Mapbox etc.
2. Welcome to NEW OSMCha modal: Highlight the major changes in the new UI
3. Walkthrough: (Optional) Step-by-step list of UI highlights

cc @kepta @batpad @geohacker

cc @batpad @willemarcel

Right now it always shows a list of page numbers even when those pages don't exist, and clicking on an invalid page number seems to break things a bit.

Also would be nice to display the count of results returned somewhere.

Fields like Filter dates needs basic checks so that invalid input should give an error. For ex: From is after to, to/from is in the future etc.

cc @kepta

For ex, searching for #hotosm in comments doesn’t work.

cc @kepta

Hi
I'm finding this project very useful.

Could changeset descriptions be added to the dialog so it can been read in fullscreen mode? It's useful as a guide as to what was edited.
Could the dialog be collapsible to an icon & slightly transparent when open?

The filters page is broken need to be fixed.

For most cases count of tags + reasons < 3.
I feel we should also show tags along with reasons with a different color in the changeset list. I guess this would help the end user make a better decision.

Could there be any problems with such a design?
cc
@manoharuss @rasagy @geohacker

We might need a bunch of icons for this project. Assembly accepts svg paths.
cc @rasagy

Following up from #11, let’s use this ticket to iterate on the Changeset details view:

Key information:

1. Main header with CTA

• Open in (JOSM, iD etc.)
• Verify (Harmful, not harmful)
• Add tag (Longer list of tags that could explain actual cause, action taken, escalation etc.)

2. Changeset metadata

• Apart from what’s visible in the changeset list, more details like Imagery, Source, Editor etc.

3. Flagged features

• Table with links to open the individual feature page, highlight it in changeset map, open in JOSM

4. Changeset discussion
5. Changeset map

For the layout, I’m envisioning the top half with dedicated section for 2, 3, 4 and the bottom half for changeset map. This ensures that the changeset detail is always visible (for context), and you can view the flagged feature list along with the changeset map (so you can quickly inspect individual features on the map without any scrolling).

cc @kepta @ajithranka @batpad @geohacker

If you do a clearFeature on every change of changes map.
It fails randomly.
Further investigation is needed.

Feel free to share any feedback on this ticket (bugs, feature request, workflow feedback)

cc @manoharuss @krishnanammala @chtnha @kepta @ajithranka @geohacker @batpad

cc @kepta @ajithranka @rasagy

Seeing this right now:

cc @kepta

If there is no comment in the changeset, the changeset details navbar do not show up. Clicking on subsequent changeset do not fix the issue.

For reference:
changeset id: 49184825

cc: @kepta @ajithranka @rasagy

Steps to reproduce:

Click on changeset in list.
Select a feature on changeset map.
Click on different changeset on list.

What happens:
The details for the feature selected from the previous changeset still shows on changeset map.

What I expect to happen:
Feature selection from previous changeset is cleared.

We can scope similar constants in an object and achieve namespaced constants.
This should reduce the visual clutter they created.

Sometime ago we talked about to define a default date range filter in the frontend, because the database count operation to return the total number of changesets takes too much time. So defining a smaller default date range will make the API response be faster and save our servers. As I remember, we thought to define the default date range to one week.

cc @batpad