Making the "event" filter more usable (esp. for large numbers of events)

[TwoMice]

Stoob recently came to me with a problem in reports, which a simple customization fixed up:

Problem: When using the "event" filter in a report, Stoob's client was having a hard time finding the right event.  This client has almost 300 events, many of them having identical or very similar names, thus distinguishable only by start date and/or event_id.  But the event filter shows only the event titles, sorted by end_date.

Solution: A) We appended the start date and the ID to the filter option labels, and sorted them alphabetically by title.  B) We later decided to improve on this by prepending the start_date year, and sorting by year (DESC) and title (ASC).

For example, the filter as currently designed has options like this:
* Wilderness Explorers
* Hands on Science Live
* Wilderness Explorers
* Hands on Science Live
* etc.

Solution A looks like this:
* Wilderness Explorers :: 2011/05/01 (#121)
* Wilderness Explorers :: 2012/02/17 (#130)
* Hands on Science Live :: 2011/04/10 (#117)
* Hands on Science Live :: 2011/05/07 (#122)

Solution B looks like this:
* 2012 - Wilderness Explorers :: 2012/02/17 (#130)
* 2011 - Hands on Science Live :: 2011/04/10 (#117)
* 2011 - Hands on Science Live :: 2011/05/07 (#122)
* 2011 - Wilderness Explorers :: 2011/05/01 (#121)

Stoob suggested this (or some form of it) might be a good contribution to make.  I agree.  Anybody else?

Thanks,
Allen

[CiviTeacher.com]

Thanks so much.

Please for those devs reviewing this, notice the subtle differences in the way the dates and titles are arranged.   I would hope we could commit an improvement patch to core that pleases the most organizations.

IMHO, almost all organizations could benefit by the addition of the start_date and id# at the end of the event title, even those who don't have many events.   Sort order is, I'm guessing, more debatable, as some organizations would prefer the list to be grouped by year, and others might not like this as much.

Feedback and suggestions, as well as examples of use-cases of your clients are welcome and appreciated so we can please the most people with our improvement.

[TwoMice]

For clients who do a lot of events, I find it helps to make key operators aware of the event_id.  It leads to more clear conversation when you say "event 221" instead of "the Community Leaders forum we had in May 2010 in Pheonix".

For this reason, I've had good experience prepending the event_id to the list of events (in filters, and in participant registration forms), so users can just type in "221" to jump to the right item (in most browsers).

- A.

[lcdweb]

+1

[Dave Greenberg]

This looks good to me - but not sure which option is better since we don't have that many events. One advantage to having the event title first is that you can type in first letter of event title and possibly jump (closer) to what you're looking for in the list. If year is first, I don't think that works.

I tweeted this post in hopes that others who have lots of events will chime in.

[SarahG (FountainTribe)]

It seems very limiting to use a single "select" list to filter on events.    How about replacing the single event name list with a set of filters: such as start and end date widgets (same style as filtering on dates in the "Find Participants" search screen) , plus event types, plus a list of events.

I was thinking this would work similar to choosing state/province after choosing a country.   So after the user chooses an event type , and/or a date range then the list of event titles would shrink to only include events of that type/date range.

[Michael McAndrew]

I like these improvements.

One advantage to having the event title first is that you can type in first letter of event title and possibly jump (closer) to what you're looking for in the list.

can we make the search wildcarded to avoid this issue? %string% i wouldn't have thought that affects performance until you start getting 100,000 events or so

that would mean you could also search via event ID, though maybe a 'search by ID' box would work better there (oops, feature creep - sorry).

Also i like the ID search but I haven't noticed the use of the # character anywhere else in the interface.  'ID' might be a safer and more obvious identifier'

[TwoMice]

I haven't noticed the use of the # character anywhere else in the interface.  'ID' might be a safer and more obvious identifier'

Yes, good point.

Also, I'm not sure I understand which search you're referring to when you ask "can we make the search wildcarded".  Are we just talking about modifying one <select> list in report filters, or something more?

 -A.

[CiviTeacher.com]

Solution A (top post) probably has the most universal appeal for the majority of orgs.

Sarah G, I agree it is limiting to search for event solely by title.   It would be nice to have an improved fully robust set of search filters as you suggest, but Allen and I don't have budget to make more happen at this point.   Shall we collect contributions, efforts, or do an MIH?

IMHO we need to focus on the task at hand, which is deciding how the title, id and date should be displayed in the most pleasing way for the majority of users. 

I vote "A".

[Michael McAndrew]

Also, I'm not sure I understand which search you're referring to when you ask "can we make the search wildcarded".  Are we just talking about modifying one <select> list in report filters, or something more?

sorry i was getting confused between event reports and event search and many other things. probably best to ignore but the general idea was where do you put the like, as is event_name LIKE '%string%' or CONCAT(event_name, event_date, event_id) LIKE '%string%' (feature creep)

[TwoMice]

Issue with patch is here: http://issues.civicrm.org/jira/browse/CRM-11141