An example - a user wants to find a record for Acme Widget Co. created some time ago but only has a vague idea of the date. They first do a Find for Company = Acme Widgets and see there are several pages of records in list view. From here the options are
- Reduce the search for a specific date. If that's not the right date, they will have to repeat the search for Company, for each date.
- Reduce the search for a date range, entering "01-06-2008...01-07-2008|dd-MM-yyyy". IMHO This really isn't intuitive to your average user who doesn't work in Java. Sure it's possible for users to learn, but that's adapting the user to the software.
- Provide a way to jump to a selected date then look at records around that date.
The iPhone analogy was just there to make the point that a lot of people in the world love to flick through records to find things, even if they've never owned a rolodex. Observe how many people use things like Cover Flow, or flick through records in their Contacts. Agreed that it's not efficient for 20000 records, but it's great for 50-200. Apple put those things there for a reason - they spent vast amounts on focus groups, audience research and other qualitative studies and found that this is how most brains work. It's the difference between good and GREAT!
Hans suggested this - what's the most efficient to do this? (and given these discussions, could "Goto without reducing foundset" ever be considered as a parameter on the Search command.?)
Hans Nieuwenhuis wrote:Maybe you could create a second foundset, do the find / search in that foundset and then use the
primary keys from that foundset to do a selectRecord in the original foundset.