nwebb

Flex components scroll when needed so we can just stick them in our application, give them a size (relative or absolute) and then forget about them – hey, if there’s too much data to display they’ll handle themselves right.

That’s all fine and good, but the temptation is to leave them with this default behaviour, and not give much thought to whether it’s the optimal behaviour for our application or not … and quite often it’s probably not.

Consider a view which displays paged search results in a DataGrid:

By default the amount of available space for the results depends on the user’s screen resolution and the size of their browser window – factors which are largely out of our hands; however a good application could easily tailor the number of results returned each time to suit the individual’s set up. After all should paged results really scroll in the first place? Shouldn’t they just fill the ‘page’?

Don’t get me wrong, scrolling is great and sometimes it’s the preferred choice, but we can only be sure we’ve made the most appropriate choice if we are aware of the alternatives. What is best, forcing the user to scroll, or forcing them to press a button each time they want a new page of results (or, as is often the case, a mixture of both)? That depends entirely on the objective of your app.

There are other reasons to at least stop and think about scrolling as a default. One such reason being that every time the user scrolls it give focus to the scroll bar (and therefore takes focus away from something else) – perhaps not desired if your item renderers are interactive in some way, and of course most of us have at some point seen the dreaded double-scroll, where a container and its nested item both have scrollbars showing simultaneously.

If you were building a paged results window you may think to return a low fixed number of results each time, but this is not a solution as you still can’t guarantee that your user will see all results without needing to scroll, and more importantly it would limit the user experience for those who do have more screen estate available. If I am a user with lots of screen space I’d expect to see as many results returned as possible, not be limited.

Eliminating scrolling altogether from a paged search is not hard. The DataGrid dispatches an event each time it is resized and it’s easy to work out the number of visible rows available then adjust your search indexes for the results you wish to return (note: numRows can’t be set if you’ve also set a height for your DataGrid, but you still have access to all the properties needed to work this out for yourself – e.g. _numRowsToDisplay = Math.floor((dg.height - dg.headerHeight) / dg.rowHeight); )

The application shown above doesn’t scroll*. This means it performs consistently regardless of the user’s screen resolution and browser size. It means the user can keep their mouse over the “more” button at all times and still see all results, which is appropriate for this particular app. If the user resizes the window at any time and presses “more results” the application will only return as many results as it can fit on the page, and double-scrolling is not ever going to be an issue. For the majority of our users this design-choice decreases the number of clicks necessary to perform the task at hand and makes for a more enjoyable application.

* unless you resize it with a set of results already on-screen, in which case you want it to scroll