#1434 (ok 4.1) Improvements to the table browsing navigation bar
A query generally results in a number of rows which don't fit in a single page (30 rows by default). Often the user will browse through the result set.
phpMyAdmin allows this with a menu at the top of the page. It allows to select the results page desired, or to request a custom range ("Show:). Sometimes, another element offering a preset range appears ("Show all").
The display of these elements is suboptimal. The current range is shown separate from this menu. The "Show all" button does not always display (see Debian ticket #658402) and shows in the page browsing area when it does. "Headers every [x] rows" has too much prominence for such a secondary feature (it should display smaller or even in the Options zone below).
Beyond clarity, there's an efficiency issue. The custom range area is very flexible, but makes very common operations slow. If I simply want to display more rows, I need to type the number of rows wanted then select "Show". In comparison, MediaWiki's page history browsing offers page size preset (25, 50, 100, 250, 500). A single click can change the number of rows. For what it's worth, I browsed page histories thousands of times, and I never had the idea that MediaWiki's page revisions browsing should be designed differently, even though it's far from phpMyAdmin's flexibility (but page history browsing and result set browsing may not be really comparable use cases).
Simply offering presets other than "Show all" (either as links or in a dropdown) would make browsing much more efficient.
An entirely different approach would be dynamic fetching of records a la Sybase Central.
There is no single way of doing things and I don't want to request too specific improvements, but failing an overhaul of browsing, there's one trivial change which would already help a lot. The use case of showing more rows is in fact longer than what I described above. Before selecting "Show", one needs to reset "Start row" to 0, since it defaults to the page size. The current behavior allows to go the next page by simply selecting "Show", but there is (since a long time) a simpler way to do that - selecting the right arrow. It would seem much more logical that if one selects "Show" without having changed anything, the result set wouldn't vary.
Thanks for your suggestions, I'll start a discussion on the devel mailing list about these (one by one).
Here is what has been implemented in master branch for 4.1. I would appreciate your testing of these changes and your feedback, either by fetching the master branch, or on http://demo.phpmyadmin.net/master (when it has refreshed).
Remove the "Headers every __ rows" dialog; it's too prominent, is not
often changed and is configurable via normal config and user prefs
Change the default number of rows from 30 to 25 (related to the next
suggestion)
Replace the input field in "Number of rows" with a dropdown
containing preset values 25/50/100/250/500. Selecting a value would
immediately have an effect. I never felt the need to display, say, 37
rows in a page. This flexibility harms usability.
Remove the "Show" button and the Start row dialog. I rarely have to
change the starting row value. Arrows and page selectors are sufficient
to navigate (not mentionning Search).
Thank you very much Marc, these changes go beyond my expectations. The flexibility removed will certainly simplify the interface. I think it's a good idea to be bold and just listen to feedback in case some consequences were omitted.
The demo is really nice and I of course checked the result. The elements look good, but I didn't expect the behavior of the size presets dropdown. When one changes the size, the currently displayed rows are no longer shown. In other words, changing the size implies a change of page, a bit like the stable version does. By default, I'll get the rows 0-24. If I change the size to 50, I'll get rows 25-74 (rather than 0-49). With the removed fields, it is no longer possible to just change the size in a single step (request). If one wants 0-49, one will have to change size to 50, then click the left arrow.
There's certainly a use case for the current behavior. Suppose one wants to read each row from a table. One would get rows 0-24, read them, then want to go further, but it would be more efficient to increase the page size. One would increase the page size and, with the current behavior, avoid getting the already read rows.
But there are also cases where one would prefer keeping the already displayed rows. If one wants to see if any of the 250 latest/highest/fooest rows contain something, one would change the page size to 250. But the user would have to go back to get the desired 0-249 range before performing his search.
So this is a choice between 2 options, none of which is strictly superior. I didn't do any research on the needs of phpMyAdmin users, but my feeling is that staying on the first page would be best. I can say for sure that is the behavior I would prefer. I recommend adopting this behavior unless others believe the current behavior is a better default. FWIW, staying at the beginning is MediaWiki's behavior browsing page histories.
If the current behavior is kept, I'd hope we can at least improve one case: a user wants to display all rows from a 156 rows table. He changes the page size to 500 thinking all rows will show, but he instead gets only 25-155. For that use case, the user would then have to click a left arrow to get all rows.
Philippe,
you're right and the expected behavior is that the position should not change when changing the number of rows. Should be fixed in https://github.com/phpmyadmin/phpmyadmin/commit/fbedeb97084dba9ab970e3e3c9a4301156e051f7.patch
I verified the fix and can confirm that the new navigation works well. The most likely source of concern I can see would be the 500 limit on the number of rows per page. I would recommend to allow a custom limit, say by adding a "Custom" option at the bottom of the dropdown. Selecting this option could reveal the old text field (or change the dropdown into the old text field). That being said, I do not remember having intentionally requested a display of more than 500 rows with phpMyAdmin.
Thank you very much for your work Marc.
Thanks Philippe for your encouragements. About the custom limit, I don't feel it's needed.