Just noticed OSM website also incorporates a changeset sidebar, similar to what we need.
I feel on top of having a changeset list similar to this, we can also have a load more button to load the next pages, instead of having the user click on an array of page number.

cc @planemad

from osmcha-frontend.

In the case of the concept C, what information would be in the sidebar when a user access the changeset detail url directly?

@willemarcel That’s the slightly hard part: we can’t show all the info we show in the tabular form, so we’ll have to pick a few of the fields. For making a quick prototype, I’m using changeset id, time, user id, created/modified/deleted and reason.

He/she would not need to switch context again and again when switching between 2 totally different views.

Just noticed OSM website also incorporates a changeset sidebar, similar to what we need.

@kepta My concern here is that there are two views of the list of changesets in this approach: A full screen table (like right now) and a collapsed panel on the left. We’ll not only end up hiding a few fields, but also show two different layouts for the same information which isn’t ideal.

Concept D however keeps the user in the same context, expanding a table row. Somewhat like this:

This will allow us to use the table row data (so we don’t need to show fields like username, time etc. again in the details page), and make it easy to view the next changeset in the list.

I’ll work on two quick layouts tomorrow to show the difference.

from osmcha-frontend.

Tagging @willemarcel for visibility

from osmcha-frontend.

Great work, @rasagy!

Might get very complex for low zoom levels or high number of changesets

We have a default pagination in the API that returns 50 changesets each time, but the user can change the page size.

My impression is that the biggest error of the first version of OSMCHA was to show the results in a list and not in a map. I don't know how was the feedback you had from the users about this, but since we are dealing with geospatial data, I feel it's very important to show the results over a map. If we could use the second screen of D in the C concept, it would sound good for me.

About the filters, some people argued that we have too many options, so it would be good to select the main options and hide the others in an advanced filters button. With the API we have the possibility of defining the area of the filter as a BBOX or to draw/use a MultiPolygon and to filter using any field of the changeset/feature database model.

from osmcha-frontend.

@rasagy You should join our roadmap meeting on Monday!
I think how we approach OSM validation will also influence the UI design of OSMCha.

IMO less focus on exploration of what is bad and more focus on working through incidents that we know are bad.

from osmcha-frontend.

Talked with a few more folks in the Data team, and did two rounds of discussions with @ajithranka and @kepta around the interface as well. I feel I have much more clarity on what can work now, adding these wireframes that we used to discuss in the ticket for reference + more feedback:

Filters

A dedicated (nearly full-screen) filters section, that has:

• Saved filters (Pick from drop down that shows name + fields modified in it)
• Frequently used filters (Preferably grouped together visually — for example the three set of controls for suspicious/flagged changesets shown together)
• Other filters (that can go on with a scroll)
• Action buttons (Reset, Save for future use, Search)

Once you search, this panel collapses to one line (shown in bottom of the sketch), that shows count of fields modified, as well as list of fields (I’m omitting actual values since they could be very long, like reasons or list of users).

Possible questions to get feedback on:

• How should saved filters be shown? (Name+fields? Sorted by last saved or name?)
• Should filters that aren’t frequently used be hidden by default (like an advanced filter that @willemarcel suggested)?
• How should a saved filter be shown when collapses? What if some fields are changed?

Changeset List (Search Results)

Fairly similar to the current view — I’m keen to not change much here since this works well.

Possible questions to get feedback on:

• Does absolute time work better or relative time? Or relative till a point (say 1 week), and then absolute?
• Do truncated comments with full text on hover work? Should #tags be highlighted first?
• How often would one click on anything apart from the changeset id to view details? Right now you can click on id, username and validator’s username
• How would a map view be more useful in your workflow compared to a list view (To gauge if it even makes sense, since the map view will have challenges like how do we paginate, visual encoding etc.)

Changeset Detail

This is the hardest section to crack — based on my discussions there are different ideas on what is needed at this stage. My hypothesis is to show only the current changeset selected, and next changeset (as a way to know what comes next) — everything else in the list accessible through some interaction (hover/scroll/click etc.)

My initial idea was to do A, but the hover-to-show-more-items approach wasn’t working out well. @kepta has been building on top of C which is interesting as well, but would take too much space to show a list that isn’t valuable to persistently see. When seeing details you want to focus only on the details (unlike say a shopping scenario where you would want to peek and compare at other list items).

Based on some feedback from @ajithranka, I’m going to pursue D — each row in the list will expand to have more details show up, while maintaining the context in the list.

Possible questions to get feedback on:

• What changeset information is valuable that isn’t being shown in the search result + changeset map? (We show source, editor, imagery in the detail page, and a section each for features & discussions)
• Is there value in seeing feature list + discussions at one time, or would an accordion/tabs work better?

Next, I’ll be fleshing these out in more detail and work with @ajithranka & @kepta in identifying components that we need to design for this. I also have enough material to do another round of feedback, and I’m hoping to also talk a bit to the community about this. Will share updates on this as it happens.

cc @batpad @willemarcel @geohacker

from osmcha-frontend.

but would take too much space to show a list that isn’t valuable to persistently see.

@rasagy could you give more details on why you think it would take too much space.

TLDR; I talk in favour of having sidebar (design C), for L and XL screen sizes.

In my opinion after a certain optimum width, say 790px, we can switch to design C. This way we would have a persistent thing always there for the user. He/she would not need to switch context again and again when switching between 2 totally different views.
Another reason why I think having a sidebar is important, is that the changeset page doesnot really demand a full width. Even if we don't take the sidebar approach, we mind end up having a max-width with centred content. (Similar to the current osmcha).

Also, I like how apple mail does it. I guess the problem with having a sidebar is that we can't show enough. Which I think can be mitigated by incorporating a 2 row layout like the mail app does below.

Again it is a preference (it might be biased as I like to have a persistent UI element around to give context). What do you think?
@rasagy

from osmcha-frontend.

Adding @Rub21 and @manoharuss for visibility.

from osmcha-frontend.

Good work, guys!!

In the case of the concept C, what information would be in the sidebar when a user access the changeset detail url directly?

The saved filters will have an URL as well for sharing between users.

from osmcha-frontend.

Awesome ticket! @rasagy so cool.

As a user of osmcha, here is how I am seeing the frontend faster than existing workflow.

The 3 views can be integrated into 2 views. First view being the personalized information for the user, saved filters and filters themselves. Second a being an efficient screen division between changeset list sidebar and details with changeset map.

• Filters : Dedicated view
• Result changeset list on sidebar + changeset details on the side

Sidebar approach seems to feels appropriate to the need for me.

After the search finishes, from the result page this information would be sufficient

• Existing filter: new mapper+all+25-04-1027 to 26-04-2017. Click to change.

• Count of: changeset list retrieved + reviewed + harmful

• From the sidebar similar to OSM, this information would be great to have

  • changesetID by username (47563827 - manoharuss)
  • time since changeset (5hours ago, 3months ago)
  • A bar or a pie chart showing experience of the user (we need to figure this out)
  • count of deletions+creations+modifications
  • thumbs up/down
  • changeset comment

• The otherside of the page can be completely dedicated to detail

  • All the metadata information regarding the changeset
  • suspicious features + reason+description of error+JOSM buttons
  • A larger screen grab for changesetmap

A bigger lift would be the way the frontend can switch between changesets.

• Keyboard shortcuts up and down to sift down changesets in the sidebar (detail page will change for each shift)
• pressing G or Bfor changeset review should just automatically goto next changeset
• prefetching changeset-map linear down, so by the time we open it, it is already loaded

Concept D however keeps the user in the same context, expanding a table row. Somewhat like this:

On this approah ^^ : I feel like we can do a lot more with the screen real estate. This method needs more clicks and how would it look when changing from changeset to changeset with keyboard shortcuts on the screen?

The whole changeset detail, changeset map under the expanding box approach will need a bigger box which means there are fewer in the list of changesets below and above the box.

from osmcha-frontend.

@rasagy I now understand your reasons behind design D.
I like this approach, it gives a cleaner and aesthetic feel and also totally removes the need for doing UI magic for small devices. However, the following doubts still make me feel C is a better approach.

1. The current osmcha container is 1108px tall. By most screen standards it would require scrolling to view the entire thing. Design D would hence require at the very least 1108 x changesetOpenpx to scroll. I feel this makes it very scroll intensive.
2. Having a scroll intensive layout would have one more blocker, which is the changeset-map. Changeset map is a real scroll grabber. The user has to consciously make sure while scrolling she doesn't land her mouse pointer on the changeset map, if that happens the scroll stops immediately and you start zooming in out of the map.

The points below assume the design allows two or more changesets open.

3. From an implementation point of view, this assumption allows multiple gl instances running simultaneously. Which could be a big problem.
4. How does this design support hyperlinking, ie. if a user wants to share the current changeset view, how does she share the url? Considering multiple changesets could be open in the scroll view.

The points below assume the design allows automatic collapsing of any existing changeset to make space for the new changeset clicked.

5. How will this impact the productivity of swapping between two changesets.
6. Extending @manoharuss and @batpad doubt regarding how do we effectively add keyboard shortcuts to this project keeping in mind Peru team is shortcuts intensive. We can possibly switch them instantly. Though, I worry about the animation and the sudden change of context (i.e scroll up and down).

Side Note: I agree with @manoharuss to discard the full screen changeset list view and stick to these two views

• sidebar and changeset details View
• filter View
• (features View if we plan to add in future)

from osmcha-frontend.

Here’s a stab at the concept C & D:

List of changesets

On searching with filters, you’ll get a list of changesets — like the current interface. The only main change here is sorting buttons on the top right, and a toggle for list | map that is optional for now (we can decide this based on the amount of effort it’ll take for us to get this right).

Concept C: Collapsed panel on left

On clicking any table row, the table collapses to the left as shown, with the current row highlighted.

Pros:

• Long list of changesets available persistently — works better for workflows where you skip changesets often
• Can show more details on demand (hover)
• This works great if we show a map view of all the changesets
• Separates scroll for list and details

Cons:

• There’s a stark difference between the list layout and the collapsed layout — users will have to learn to skim through the two views differently
• The collapsed layout will only show a subset of fields, which will lead to frequent interaction with the list for more details of each item
• Less width for the detail view means that the changeset map will get harder to use (especially with the info and tables being shown)
• Since the left panel shows a subset of information, we’ll have to show the details (shown on hover) in the Details panel

Concept D: Expanded table rows

On clicking any table row, the table scrolls to show that row on the top. Details show up below the row so that the next changeset row is shown in the bottom of the screen (the darkened area is below the fold)

Pros:

• Consistent view for the changeset details (as a table row)
• Full-width area for the changeset details (and changeset map)
• Would scale well across screen sizes (especially for expert use case with multiple windows open, like many folks in the Data team)
• Reuses the table row to show the important details, so they don’t need to be shown again in the details view
• Works well for the workflow where user wants to go through the changesets linearly

Cons:

• Only the next changeset details are visible without scroll
• Table row might truncate some fields — we’ll need multi-line rows or wrap content + show full content for that field on hover as a popup
• Multiple scrolls — each section in details (like changeset discussion) might have a scroll if we want to ensure that the whole details section fits in the screen, and changeset map has a scroll as well. This means to scroll down, the user will have to scroll from the next item in the list

cc @ajithranka @kepta @batpad @geohacker @willemarcel @Rub21

from osmcha-frontend.

@manoharuss Thanks for the detailed feedback! I’m going to expand on your thoughts about what to show in the filter bar on the top.

• Keyboard shortcuts up and down to sift down changesets in the sidebar (detail page will change for each shift)
• pressing G or Bfor changeset review should just automatically goto next changeset

This makes sense, and is something we can think about in both the concepts — it’ll be definitely useful.

• prefetching changeset-map linear down, so by the time we open it, it is already loaded

We discussed this during our initial sync in the pros vs cons for a single page react app vs the current way where we create a new DOM altogether. Once we have our first cut out, we’ll focus more on the optimization using ideas like the one you mentioned.

Feedback from @kepta:

Design D would hence require at the very least 1108 x changesetOpenpx to scroll.

True. If we build a more fluid layout that uses the full-width, we can reduce some of this — the details that take up considerable size will be shown in the table row itself, therefore the details section will need to show action buttons, suspicious/flagged features, and changeset discussions (if any). I think this should be doable in the space.

I feel this makes it very scroll intensive.
Having a scroll intensive layout would have one more blocker

Yes, that’s definitely a con, and once we get to the details I would like to see what is the best way to tackle this. With Changeset map being much more useful now (links to other tools + better properties table), we’ll not let it scroll below the screen even if we use Concept C, so will have to tackle this regardless.

From an implementation point of view, this assumption allows multiple gl instances running simultaneously.

As you mentioned, we’ll stick with a collapsable view (like an accordion) so you can only view one changeset at a time.

How will this impact the productivity of swapping between two changesets.

This is a good point to test out. I’m thinking that we’ll need shortcuts to collapse the detailed view + jump back and forth between changesets.

from osmcha-frontend.

I got a chance to make a rough prototype of design C and D.

Here is design C.
Here is design D.

@rasagy thoughts?

from osmcha-frontend.

@kepta Looks good. Based on our quick chat, design D will struggle with scroll context when trying to expand/collapse different accordions.

Let’s go ahead with concept C and find ways to make it responsive (to work well with a split screen layout alongside JOSM), and find ways to make the list of changesets on the left less space-consuming.
cc @ajithranka

from osmcha-frontend.

We have adopted a full screen layout of changeset-map, refer this refactor for the updated changeset-map.

Closing this ticket,

from osmcha-frontend.