search

bocoup / blocks-capacity-planner

An airtable block for matching supply to demand in an airtable base.
MIT License
3 stars 3 forks source link

Schedule constraints UI improvements #47

Closed arebe closed 4 years ago

arebe commented 4 years ago

Closes #43

As per design v2: new Constraints UI: Move schedule and budget constraints to top of planning page, add new copy, add confirmation button.

To create the Confirm button UX - I refactored the DndProvider by moving it to wrap the top-level Chooser component to resolve rendering / HTML5 Backend error.

There's a new field in Constraints for max distance - while it appears in the UI, it's disabled until the distance calculation functionality build out.

Screen Shot 2020-05-21 at 5 17 36 PM
susanpark commented 4 years ago

Fixed positioning perpetually assigns some of the viewport to the menu, but the menu may not be relevant during most of a working session. This seems suboptimal for an application where so much information has to be displayed concurrently.

There are various issues with how it's built today in terms of viewport - we've gotten feedback on this from various chapters and we want to prioritize it, as it creates a bad experience

  1. When a hospital schedule slot shows up, that means a user has to select a restaurant to match with the hospital on the right side. Right now, the left side height of the restaurant is determined by the how many hospitals appear on the right side, which is unreasonably short. All of our chapters have a large list of restaurants they need to scroll/sort through to match the hospitals. The goal for chapters is to find a restaurant, and we need to optimize for the discoverability of a restaurant. When there is only one or two restaurants, it becomes very difficult for chapters to find restaurants. The viewport should be large enough for them to scroll through the restaurants.
  2. We should never surprise users with inconsistency. Just because there is only one or two hospitals on the right side, doesn't mean that we should change the heights of the viewports for depending on the number of hospitals. This kind of inconsistency causes a negative experience and surprises users when they try to set up a schedule.
jugglinmike commented 4 years ago

That all sounds good to me, @susanpark! You may be interested in the changes in gh-22.

My question to Jesar was specifically about the way they intended the "schedule constraints" form to interact with the scroll bar. I'm seeking clarification because the design specification doesn't describe what's intended.

Currently, the patch affixes the form to the top of the Block's viewport such that it is present while the user scrolls through the shifts. An alternate interpretation would be to include the form as scrollable content (this would mean it would no longer be visible as the user moved through the shifts).

Here's a screen recording to demonstrate the two interpretations of the design specification:

2020-05-26-ff-viewport

jesarshah commented 4 years ago

Hello! Apologies for the delay in my response - based on how people were using it during the few test rounds, I think giving them as much space on the screen to plan is valuable. So after they set the constraints, they spend time dragging restaurants to hospitals. So I think we should allow the constraints and top of the page content to scroll away with the scrollbar. Thanks!

arebe commented 4 years ago

@jugglinmike thanks for the review -- I updated the PR with the scrolling UX you & Jesar suggested. think it's good to merge? also -- it looks like you all are using merge --squash strategy, yeah?

jugglinmike commented 4 years ago

Thanks @jesarshah! Thanks @arebe!

jugglinmike commented 4 years ago

also -- it looks like you all are using merge --squash strategy, yeah?

Preferably, unless circumstances call for a merge commit