Search

Problem

Search, as it is currently implemented, is a failure. This stems from two primary problems. The first is the untrustworthiness of search results. Query results are unreliable, incomplete, and unnavigable. This is exacerbated by an obsolete technical foundation and information architecture. The second is the fracturing of information across the website. Data in contained in model-specific silos, without any united navigation or relationship between datasets. This is exacerbated by an obsolete information architecture and an ever-expanding scope.

Solution

The solution to this two-fold problem is itself multifaceted. The primary solution is to stop displaying entire database dumps as a user interface. The responsibility we have in implementing this solution is to reliably surface relevant information in an informed way. A unified search interface should provide a trustworthy and comprehensive way of asking questions against all of MuckRock's datasets. That is to say, if no results exist for a query, it should be absolutely true that no objects for that search exist anywhere in our system. Tertiary solutions include clarifying the information architecture, cataloging data types, and providing better starting points for queries.

The principle object in this interface is the array of results. The state of results is transformed by two functions, search and sort. Search filters the results, while sort reorders the results. The state of search and sort are their inputs. Search and sort should maintain their state independent from one another.

A result array should not be produced without a search. Therefore, sorts may only be performed following the initial search. This should provide a clearer interaction model for the user. They will be presented with a single question: "what are you looking for?"

Search

Search should be an array of filters. Model, keyword, date, user, status, and agency are some possible filters. We should expect to increase the variety of the filters moving forward. Search should be performed on the server, providing the client with the result array.

Each search filter should have an attribute (type, user, agency) and an array of values ([Request], [Michael Morisy], [FBI, CIA, NSA]). Values of filters should be combined using OR operations. Filters should be combined using AND operations. For simplicity of implementation and communication, that means each successive filter makes the search increasingly specific.

e.g. ((User is a OR b OR c) AND (Agency is d OR e) AND (Tag is f OR g OR h OR i))

The exception to this is the keyword filter, which should always be visible and behave like a typical keyword search input.

Question Should filters also have a positivity attribute, e.g. AND x or y and AND NOT x OR y?

Question Should search be applied to a single model at a time, or across all models? Single model at a time is way simpler, and even search UI like Facebook's splinters it search by model.

filters = Array

filter = {
    key: String,
    values: Array
}

Sort

Only one sort may be applied at a time. Each sort has a comparative value and a direction. Name and date are two possible sorts. Sort should be performed on the client side, after a list of search results has been delivered from the server.

Question How do we sort different models with different attributes? Should we?

sort = {
    comparison: String,
    direction: (ascending|descending)
}