It’s the age old UX question. I’m pretty sure there is some UI guidance on this someplace, but I’ve not had support for one way of making sure that users (and of course test automators) can handle things like a list slowly populating while calls to the back-end return.
Search engines somehow manage for example by making sure that there is not requirement to “sort” the results list, which means it’s never going to happen that a user clicks on an item and then finds that it “moved”. It’s rather frustrating when Windows Explorer (other OS filesystem search tools with GUI’s on them do exist) , and a lot of people find other file search tools create less friction by somehow magic. The built in search tool is not great for many other reasons, but this “scrolling” while results return thing is complexified when the results need to be in a sorted order. I guess I’m looking for two things here.
Infinite lists that scroll forever
Paged or chunked lists (which are much easier)
Had anyone seen a good published and reviewed explainer on this kind of UX problem? I’m mainly trying to work out if a uniform approach in a web based test framework which might help enforce consistent list user experiences is good or not achievable.
When lists are shown in pages not as one huge list, we should expect each “page” of results to be almost instantaneous for that page.
When the list is “infinite”, sorting the list becomes evil and I’d like to avoid reshuffling annoyance
Are spinners or hourglass and disable user from interacting while it loads a standard way to deal with both infinite lists or paged lists?
I cannot provide much help to your problem, but two things that might be of interest to you.
First is when I used to work with a search function the main take away is that you do the sorting on server side so you can support your infinite scrolling on server side and not in the client. (we used elastic search and for this). This has the problem that you need to fetch the list every time you want to change your sorting.
Which leads to the second part where React is working on concurrent actions that will help this. https://reactjs.org/blog/2021/06/08/the-plan-for-react-18.html
A small tl;dr is that you both allow the user to act in the current view and update the next view at the same time. In the case of the list you would select “sort by…” and it will start to do that for you without you leaving the current sorting and the ability to interact with the list items. Then when you have the results you will swap to that view instead, minimizing the need for a loader while still allowing a server to do the work instead of a client.
Oh, I’m all for detail here. So the concept of server side sorting is pretty much meaning you have to wait for the entire query to complete before piping it down the wire, because the client is going to ask for one page at a time , and maybe call
get_results(page=0, length=20)
Which is why many frameworks never have “random scrolling”, but having a performant system is still needed, since I want to be able to test that the underlying client-side magic of swapping the views and keeping things responsive. And that client and server caches of the list may exist. Which all gives me some clues. Thank you so much @ola.sundin for helping me frame that activity that goes on under the covers. I mean we want to test the user interaction, but that always requires knowledge of timings in the app.
For the situation where the user looks at a page, for example of registered domain users, should the page refresh on it’s own every few minutes? To show new users who get added? We used to have tickboxes at the bottom of all of out live screens in pass to prevent or allow live refresh. Is the current thinking that people prefer to mash the F5 button or that they prefer to see changes appear after a few seconds? I keep wondering if that is the core issue, to refresh manually, or not.
There are some cool material on the topic of pull vs. push where for instance you have the different RX libraries that introduce the push collections which might allow for a better design with data that is being updated. Which might allow to you reason better around sorting a collection that is being updated over time. It still requires some clever UX design to help the user understand that the list that you are looking at have been updated. Or if you want to explore streaming of data more chat services typically also uses a push based system more.
I also read an article that I cannot find anymore on Facebooks reasoning together with the concurrency in react that they try to predict what the user is doing and preemptively fetch the next things before the user have actually completed the action. In the case of infinite scrolling this is easy to understand like if you can show 10 items on screen then you fetch 12 or something, and when the user starts to scroll you start to fetch the next 12 while showing the 2 you already have. But if you have good tracking of the user actions maybe you can find patterns where a user typically normally follow up a list item interaction with a change in sort order, then you can start to fetch that when they interact with the item instead of when they change the sort option. Something that RX solves very nicely. There is a good talk from Netflix regarding that Netflix JavaScript Talks - RxJS + Redux + React = Amazing! - YouTube
what is a good design for an infinite list in a web page?
what things should be tested in such a list?
I just focus on the UX design in this reply, because this looks like the most important thing.
According to me a UX designer tries to design an application or a web site in a way that the user use it in a fast and intuitive way. An infinite list is a tool to accomplish this.
If a UX designer uses an infinite list, then I expect that a prototype has already been validated with the users. As a tester I can focus on other aspects like function and performance.
Some blog posts about infinite lists:
More general information about UI design:
A lot of my test ideas can be found in these articles. If you need more test ideas, than I can share them with you.
Most apps start out without a “subscription” or push model in the API, so when it gets implemented later on each dialog, I want to be ready.
So, the RX push vs pull focus will help me keep the UI sane when it grows in complexity. And this video is really good backgrounder even for non-coders. Being able to predict or know in the workflow which bits of the screen you are allowed to refresh is pretty vital to get decided up front, letting the framework decide for you feels like something that will make test-automation painful as well. And may break the UX feel for users. When a dialog finally does implement “push” it’s likely to break at least one automated test, and I’m thinking that’s maybe a good thing. This has been helpful info @ola.sundin .