Table view jumps to the top after the deletion of the row. Any fixes?

I have a complex table with two level of grouping (on the left).

Each row has a “Delete” button with the function DeleteRows(thisRow)

Every time I click this button, the row gets deleted, but the view scrolls to the top of the table.

Is it possible not to jump to the top of the table after deletion of the row?
Or should I change the button function?

1 Like

When you delete a row, the “focus” of where a cursor is on the page disappears. It looks like we’re falling back to the overall table for this. I’ll post this in our talks and see if this is an issue.

When you delete a row by selecting it and pressing Delete key focus doesn’t jump, Coda just selects next row in a table. If user deletes a row with a button, it’s logical for Coda to behave in the same way.

I’m not sure if it’s easy for Coda team to implement, but it will be an improvement.

It’s irritating when you work with a huge table and the view jumps to the top and you lose your viewing position.

View also jumps to the top of the table when you select a value (or a few values) from a list/lookup type column with option “Allow Multiple selection” on and click on the side of the table (empty space) to finish the selection. Maybe it’s how you think Coda should behave, but I think user experience will be better if you leave the focus on the cell where user made a selection.

The workaround is to press Return/Enter key to finish the selection or click anywhere inside the table next to this cell.

Maybe you can discuss focus jumping in this scenario too.

2 Likes

This is a significant UX issue, and has been for as long as I’ve been using Coda. Auto-scroll gets triggered by many more scenarios than those @Andrei_Kharlanov has identified here. They are difficult to document and reproduce.

The user will be totally focused (eyes and brain) on the content where they are working, take some trivial user action like a mouse click some place, and the window will jump to some random location. The UX on this particular issue is like walking through a mine field. It would be difficult to think of a more “irritating” UX scenario than that!:grinning:

There is never a time in any app that I use when I want it to automatically scroll away from where I, the user, have consciously positioned the app/window/screen to display exactly what I want it to display. (There will always be edge cases, but what is being discussed in this thread is beyond that.)

Imho, the code should be audited for all instances of window.scroll() or whichever method is causing this, and each instance should be vigorously tested for UX. My suspicion is that it could just be removed in most cases.

1 Like