Skip to main content
Hi,



I received some feedback from a customer regarding the scrolling in WebUI pages.



Unintuitive from page perspective

To scroll up/down on a page, the user has to move the mouse to:


  • An empty spot (without widget)
  • A spot that contains table row headers (the rowheader-viewport)
Users expect to also be able to page-scroll when the mouse is positioned on the grid-viewport of a table, especially when the table doesn’t require scrollbars.



Unintuitive from table widget perspective

To scroll up/down in a table, this is only possible with the cursor in the grid-viewport. Users expect that it’s also possible to table-scroll when the mouse is in the rowheader-viewport.



Proposal (what I think would be intuitive)


  • When the cursor is in a table, scrolling takes place in the table. It doesn’t matter whether the cursor is located in the rowheader or the grid viewport.
  • When it is not possible to scroll further in the table (because the top or bottom is reached), continue with scrolling on page level.

Looking forward to hearing your thoughts on this.



Best regards,

Sander
I'm a strong disbeliever of scrolling in webui apps. If you have that much information to show on a single page that scrolling is required, then I would consider using the workflow widget we will be releasing shortly (or side panels) to divide that information over multiple pages which are then much more easily to switch to using the workflow widget than you would be able to using scrolling.



As an added bonus, there will be much less widgets on each of the pages, less need to dynamically hide/unhide widgets, all of which will lead to drastically reduced page load times.



If you still think that unnecessary mouse movements are required to use the workflow widget, then maybe we should consider introducing keyboard shortcuts for moving to the next or previous item.



BTW. my own ideas for the new page layouting and resizability which we will be addressing in Q4 revolve around creating pages without scrolling (like in WinUI) with areas to place widgets in that behave differently with respect to resizing the window size (e.g. stay same width/height, extend in horizontal/vertical direction, etc).



Imo scrolling is nice for pages with text and pictures, but for pages with tables, graphs and other graphical objects, I mostly want to be able to see all the information on that page, and not have to scroll down and up to see other related information. Side panels and workflow widgets may help there tremendously.
Hi Marcel, thanks for your feedback. I'm also not a fan of scrolling in WebUI pages, but given the coarse way of choosing widget sizes (rows & columns), I'm currently not able to create a properly looking page that fits all widgets that I need on that page: a small part falls of the screen.



Scrolling towards that part (and scrolling within larger tables) isn't intuitive, as mentioned above. How to approach this?

I suggest we await the new Page Layout that we are developing where we have better scaling and page filling (taking away the column/row sizing of widgets).

@sandervlot , curious to learn how you experience the new Grid Layout of pages. Has it indeed removed this concern?

 

PS: In next release (4.80) we expect Dialog Pages and Side Panel to have Grid Layout as well. 

Hi Gertjan, yes the Grid Layout has solved my problem, thanks for asking. 

Terms & Conditions

Didn't find what you were looking for? Try searching on our documentation pages:

AIMMS Developer & PRO | AIMMS How-To | AIMMS SC Navigator