As a VersionOne User, I want all grids, but especially in release planning and sprint tracking, to stop going back to the top whenever I modify an item in the middle or bottom (particularly from the Edit button or other menus) so that I don’t keep losing my place and have to scroll down to where I was before I can enter more data.
by: Khris C. | over a year ago | User Interface
Comments
I agree that this is a poor user experience.
Sometimes the list can refresh without scrolling to the top, sometimes it does not, suggesting that there is not technological reason for this to happen. Just find all of the actions that are triggering a page reload, and modify them to do a grid refresh.
More complete user story:
As a VersionOne User, I want all grids, but especially in release planning and sprint tracking, to stop going back to the top whenever I modify an item in the middle or bottom (particularly from the Edit button or other menus) so that I don’t keep losing my place and have to scroll down to where I was before I can enter more data.
For example, if a product owner is planning his backlog in a list that shows 50 items, and he edits #40, then selecting OK on the screen jumps up to the top to show item 1, so he loses context of what he just edited, which is a pain if editing a number of items one after another.
This problem occurs impacts all product owners and scrum masters in our organization, which is between 60 and 70 people. To a lesser extent, this problem may also impact teams, depending on what view they use for sprint tracking during daily standups.
I would agree that the program should do some sort of in-line reloading of the grid. I would expand to say that this should be done for all of the grids in V1. Many of my users find this very annoying and are very vocal about it, especially when I'm in a planning session.
I agree. It makes the tool look unpredictable, wastes our valuable time in planning sessions, and also causes the team's confidence in the SM/PO to drop. I wonder if many of us make the same customization to increase the default number of rows per page to try and get the whole backlog onto one page and this exacerbates the issue. I may try going back to smaller rows per page, but that means trading off having to page back and forth (with wait times) to find BLIs, which is also not desired.
I agree. Scrolling back down takes too long, but it's still a bit faster than having a small number (e.g. default/10) rows per page.
I agree that it needs fixing when you use menu commands to perform actions. However, you can avoid the scrolling by making the fields in the grid editable. Then, after updating a field, move the cursor to a different field and press the Enter key on the keyboard. The values refresh without scrolling.
We've been working on this one over time. I think we're at a good point now. Release Scheduling and the Sprint Tracking grids behave and it seems the behavior is pretty consistent but want to hear from you before closing this out. Are there any other grids where this is a problem? Please tell reply w/ page and release you are using if you are still having issues. Thanks!
I was more concerned about the backlog list, which tends to be the biggest. It now keeps you where you are after editing a line. I very much appreciate the improvement!
Maybe this is a different request, but whenever I add a blocking issue to an item (I consider that a form of an edit), the grid also goes back to the top of the screen. We see this in the Product Backlog and the Team Rooms.
This is a problem in the Teamrooms as well. Specifically the Storyboard view moves anytime I do something like remove an issue from a card, or make another change to the story details. The scrolling should be frozen on refresh -- very frustrating to have to re-center my view in standup.
Thank you all for your feedback. The issue has now been resolved.
Please check it out and keep the good ideas coming.