Have redundant 'action triggers' / controls on long pages

[michael@…]

For projects with a long list of milestones, it would be helpful if there was an 'add' link at the bottom of the page as well as at the top. This allows someone who has scrolled down to check what the last milestone is to click and add the next one without scrolling back up'

[cmlenz]

The current trunk (and 0.9b1) doesn't actually have a link at the top, it provides a button at the bottom of the milestone list. As you say, this placement probably makes more sense.

However, I have the feeling that what you're really requesting is redundancy in controls, i.e. to have the action triggers both at the bottom and the top of any listing-style page. If we do this, it should be done consistently throughout Trac, and I think it'd be a good idea.

Those redundant controls should however only be rendered after the list has passed a certain threshhold, I think. For a list with one or two items (or even an empty list), putting the same buttons both above and below the list will look pretty ugly, and might be confusing. So I don't think this should really be on the plate for 0.9.

[sid]

Replying to cmlenz:

However, I have the feeling that what you're really requesting is redundancy in controls, i.e. to have the action triggers both at the bottom and the top of any listing-style page. If we do this, it should be done consistently throughout Trac, and I think it'd be a good idea. Those redundant controls should however only be rendered after the list has passed a certain threshhold, I think. For a list with one or two items (or even an empty list), putting the same buttons both above and below the list will look pretty ugly, and might be confusing.

This would be great to have.

[sid]

#2758 has been marked as duplicate of this ticket. It requests controls at top and bottom of ticket pages for "next" and "previous" links when using custom queries.

[cboos]

#2626 and #4395 were marked as duplicate.

[cboos]

Well, it might not be always easy to detect what's a "long" page and what is not.

For listing like pages (e.g. TracBrowser, the history views), the count of rows can be a good indicator. For wiki pages, it can't be decided easily (e.g. think about a single line [[Image(big_image.jpg)]]).

A different approach might be the solution: do everything in Javascript, where it should be possible on the client side to detect if the page has a scrollbar to start with (i.e. that would be a "big" page) and then duplicate the "action triggers" at the top or bottom of the page. For that, we'd need to define appropriate ids or classes where we can find the original triggers and where we have to copy them.