The table shown when clicking on a(ny) federation has a few issues making interacting with it slightly frustrating:
The results table is paginated, but there is no obvious way to influence how many rows are being displayed on a page (20, atm). Keeping things simple is good but this aspect is worsened by the other issues below (meaning if the issues below are resolved it might not be necessary to make the number of rows shown configurable in the UI after all):
There is an export facility but that only exports the entities shown in the current pagination, which seems both couter-intuitive as well as useless to me: For a large federation I'd have to click though all n paginated results and export 20 rows each into n separate files and then also merge all those files somehow (which isn't total obvious for the XML and JSON formats and even for CSV you'd have to remove the first line with the column headings multiple times) in order to do anything with the exported data set. As it is I think this is a design or implementation error because I cannot imagine how exporting only the currently shown 20 rows out of a larger result set might be useful to anyone?
The column headers (EntityID, Type, DisplayName, etc.) can be clicked to sort the results by that column but again this only sorts the results for the current pagination. Again I cannot imagine how it would be useful to anyone to sort 20 rows from a paginated result set with n pages if the data in all the other (unsorted) pages unknown, and the default sorting of rows seems to be some kind of bogus-sort. Steps to frustration: Click page 1, click DISPLAYNAME: You get 20 out of many entities and the table now begins with a display name that starts with the letter "A", followed by an entity with a display name that starts with "B". To continue click page 2, click DISPLAYNAME again, and again you'll have different entities that start with "A", followed by "B", etc. I don't see how that's useful sorting if there are more "A"s in other pages but you'd have to click through all existing pages in order to find them.
So I'd suggest to change this to re-sort all rows once a different sorting has been chosen by clicking a column header and keeping that sort criterion even when clicking through more pages.
(Feel free to split those up into separate issues if you think this is warranted.)
The table shown when clicking on a(ny) federation has a few issues making interacting with it slightly frustrating:
n
paginated results and export 20 rows each inton
separate files and then also merge all those files somehow (which isn't total obvious for the XML and JSON formats and even for CSV you'd have to remove the first line with the column headings multiple times) in order to do anything with the exported data set. As it is I think this is a design or implementation error because I cannot imagine how exporting only the currently shown 20 rows out of a larger result set might be useful to anyone?n
pages if the data in all the other (unsorted) pages unknown, and the default sorting of rows seems to be some kind of bogus-sort. Steps to frustration: Click page1
, clickDISPLAYNAME
: You get 20 out of many entities and the table now begins with a display name that starts with the letter "A", followed by an entity with a display name that starts with "B". To continue click page2
, clickDISPLAYNAME
again, and again you'll have different entities that start with "A", followed by "B", etc. I don't see how that's useful sorting if there are more "A"s in other pages but you'd have to click through all existing pages in order to find them.So I'd suggest to change this to re-sort all rows once a different sorting has been chosen by clicking a column header and keeping that sort criterion even when clicking through more pages.
(Feel free to split those up into separate issues if you think this is warranted.)