WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 21 months ago

#15980 closed enhancement (wontfix)

Ajax listing table spinners sync'd for searching and next/prev page

Reported by: dd32 Owned by:
Milestone: Priority: normal
Severity: minor Version: 3.1
Component: Administration Keywords:
Focuses: Cc:

Description

On the listing tables, there are 2 spinners, One beside the search field, and another below the table for the page changing.

If you search for a term, both the searching, and paging spinners will start, If you change the page, both the paging and the searching spinner will start.

My expectation is that only one of these spinners would be active at a time.

Verified on Posts & Taxonomy edit pages.

Attachments (2)

15980.diff (1.9 KB) - added by nacin 3 years ago.
15980.png (138.1 KB) - added by nacin 3 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 nacin3 years ago

There are two spinners, one on top next to the search box and one on bottom near the pagination. Both should always spin for any paginating, searching, or sorting.

It's not ideal. In 3.2 we'll be sprinkling a bunch of spinners next to the specific action (pagination, the individual column th, the search box). But that was too much for 3.1.

If there are suggestions for better placement for the generic top/bottom ones, that might help. I don't think there are ones, however.

comment:2 dd323 years ago

If there are suggestions for better placement for the generic top/bottom ones, that might help. I don't think there are ones, however.

That's the thing, They're not generic locations, One is attached to the edge of the search field, The other is attached to the edge of the pagination.

Neither are tied directly to the listing table, other than that they show up when it's doing something, If they were aligned centrally to the table, or as seen during development where the entire table is dimed/spinner then would make sense to me. Just saying, That at present they ARE attached to specific functions..

This is obviously a very minor point, I just thought it was worth mentioning.

comment:3 nacin3 years ago

Generally speaking both won't be in the viewport at the same time, so that alleviates some issues.

The overlay was really bad UX and prevented the user from doing or reading anything else. Hence what we have now.

comment:4 dd323 years ago

Generally speaking both won't be in the viewport at the same time, so that alleviates some issues.

Thats what caused me to notice it, When they are both in the viewport, it feels awkward like multiple things are happening at once.

The overlay was really bad UX and prevented the user from doing or reading anything else. Hence what we have now.

Quite aware of that, However, from a visual point of view, it made it much more obvious as to what was happening, but the technical problems involved with that overrule it right now.

comment:5 garyc403 years ago

How about attaching a small spinner to the lower left corner of the mouse cursor? That sure can be done by javascript.

comment:6 nacin3 years ago

I imagine Jane would flip out at that suggestion. :)

I'm testing out a repositioning now -- above the search box and below the bottom pagination.

comment:7 dd323 years ago

IMO, If that's as it was intended and it's getting revisited in 3.2, then I'd leave it as-is for 3.1.

nacin3 years ago

nacin3 years ago

comment:8 nacin3 years ago

  • Keywords has-patch added

Ran with it anyway. Actually looks pretty good, better than what we have, less confusing. And we can revisit in 3.2 in a more thorough fashion.

Screenshot and patch attached.

comment:9 nacin3 years ago

  • Keywords 3.2-early added; has-patch removed
  • Milestone changed from 3.1 to Future Release

Per previous discussions, leave this alone as is for 3.1.0, and add spinners for each individual action in the future.

comment:10 nacin3 years ago

  • Type changed from defect (bug) to enhancement

comment:11 nacin21 months ago

  • Keywords ui-feedback 3.2-early removed
  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Closing as we don't have ajax list tables...

Note: See TracTickets for help on using tickets.