Reworking SavedSearches

RT Developers
1

I’m interested in the community’s interest in a reworking of
SavedSearches that we are considering implementing.

Situation:
The way we look at saved searches they can be broken down into 3-5 elements:

Query: the query run to get a list of relevant tickets
Display Format: The columns displayed and any formatting (links, size)
Ordering: Which column(s) to sort by and how.
Rows/page: (part of display format?) #rows to display per page
Refresh Rate: (part of display format?) who often to refresh page

Problem:
Currently all of these elements (we’ve added refresh rate) are saved as
part of a saved search. This means that if you need two saved searches
that have the same query but need a different display format, the query
needs to be duplicated and if a change is needed it must be changed in
two locations. I’d like to eliminate this duplication of work.

Proposal:
I’d like to split some of the elements into separately saved attributes.
This would mean that those parts of the saved search would be
separately composed and saved, and then the saved search would just
indicate which saved attribute it should use. This would also help
simplify (and speed up) the Query Builder, because the separate parts
could be separate pages.

Saved searches would be composed of:

QueryAttribute – separate attribute saved as Attr.
DisplayFormatAttribute – The columns and formatting saved as Attr.
OrderAttribute – ordering of columns saved as Attr.
RowsPerPage – # of rows to display (same as current)
RefreshRate – Add this to standard (UW already have this).

For the web interface this would mean splitting the Current Query
Builder into:

Query Builder – ‘Add Criteria’ + ‘Query’ + Save/Load
Display Builder – Left part of current ‘Display Columns’ + Save/Load
Order Builder – Order by elements + Save/Load
SavedSearch Builder – Select Query + Select Display + Select Order +
Rows + Refresh Rate + Save/Load.

Any feedback, interest, etc?

Joby Walker
ITI SSG, C&C, University of Washington

2

I’m interested in the community’s interest in a reworking of
SavedSearches that we are considering implementing.

So, this is very much something we looked at when doing the original
design for the RT 3.2 query builder and saved searches. The reason we
didn’t split out Search Results and Display Format into their own
separate subcomponents was out of a concern that it would take an
already complicated UI and make it even harder to use.

Putting results format and search terms on separate pages seems pretty
reasonable to me. Making it so that if you want to display a saved
search, you need to load two or three different items to get the same
consistent behaviour. What we’ve done for RT 3.6 is let users set up
preferences for display defaults…It only goes part of the way there,
but it’s our hope that it helps make it a bit better without making
things hurt more.

I’d encourage you to mock up a potential new UI before going all the way
through with it, but if we (or you) can come up with something that’s
useful without making the toolset harder to use for a casual user,
I’d be really psyched.

Je

3

Jesse Vincent wrote:

So, this is very much something we looked at when doing the original
design for the RT 3.2 query builder and saved searches. The reason we
didn’t split out Search Results and Display Format into their own
separate subcomponents was out of a concern that it would take an
already complicated UI and make it even harder to use.

Didn’t know the history. Good to know.

Putting results format and search terms on separate pages seems pretty
reasonable to me. Making it so that if you want to display a saved
search, you need to load two or three different items to get the same
consistent behaviour. What we’ve done for RT 3.6 is let users set up
preferences for display defaults…It only goes part of the way there,
but it’s our hope that it helps make it a bit better without making
things hurt more.

After lots of feed back we were pressured to add the ability to define a
default format for a group and then a user could select one of their
groups to provide their default search format – but the end result has
been that no one used the separate mechanism and just used saved
searches (we’re using the Homepage Saved Searches).

I’d encourage you to mock up a potential new UI before going all the way
through with it, but if we (or you) can come up with something that’s
useful without making the toolset harder to use for a casual user,
I’d be really psyched.

We’ll look at the mockup. One of the attractions for me is that our
casual users have a real hard time with the query creation part, but can
manage the formatting and ordering just fine. If they could use some
already defined queries, they wouldn’t have to deal with generating a query.

There is also no reason we couldn’t create a new “Jumbo Saved Search”
page that allows you to edit all of the elements on one page…

One thing that we’ve done – that is sort of related to this is that all
the Search/Results.* pages (and more) can be accessed with just a saved
search id# (https://path.to.rt/Search/Results.html?Id=55). This is nice
because if you bookmark …?Id=55 then even if the saved search changes,
you will get the new search – not the old one.

So with the changes I’ve proposed, Search/Results.* could take:

If Saved Search 55 consisted of:
a) query 5
b) format 18
c) order 30

  1. /Search/Results.html?Id=55

change the query to #6

  1. /Search/Results.html?queryid=6&formatid=18&orderid=30

change the ordering (without saving)

  1. /Search/Results.html?queryid=6&formatid=18&Order=Creator|Owner|

etc…

We’ll work on a mockup soon, and post some images – though we’ve change
the generic interface some so they’ll be a bit off of standard.

Joby Walker
ITI SSG, C&C, University of Washington