We simply agree that a 100+ items menu is odd - I even would dislike this amount of reports in a (searchable, sortable) grid. But then I use an approach with reports grouped to a form and called from this form. (in the background all is run by a table driven factory, but this is a different problem)

Anyway a MRU would pull the report last called to top. Normally it's an other related report to run next. So if you work on a problem with a group of reports, you got a permanently changing menu. You never know where to click, no keyboard shortcut to remember.

>For me the MRU angle would be recurrent tasks -
>Which might be hard to encode into report / file names,
>as another employee might need to run the report more or less often.
>
>MRU is somewhat self-organizing,
>abolishing the need to create a way
>for every employee to tweak their own menus -
>and with that the need to document and teach.
>Perhaps add a paragraph on how to set # of MRU entries.
>
>It cuts the "offered" reports from 100+ to amount every user needs for *his* tasks
>and the time dimension is IMO also a usable order criterion for tasks last done/to do.
>
>the smart ass answer of course would be:
>picking a report *is* picking a file (couple),
>so you should have no reason to vomit -
>imagine it to be an Excel file with a dynamic query
>giving new / current results for the period.
>
> ;-))
>
>>Me, from a user POV, would vomit if a non-file menu behaves like that.
>> I have a visual orientation and expect an entry on a certain
>
>>A MRU for files like in an editor is fine so far, since the file is the data.
>>>I think you should combine Dragan & Al:
>>>first make it EASY for each user to identify / find specific report
>>>- description table based in a grid,
>>>- perhaps 2nd window or description field form
>>>add Search option in Reports Menu
>>>Build MRU Menu via tables
>>>allow deletion in MRU Menu
>>>
>>>my 0.002 €
>>>thomas