Tags are a cornerstone of Alaveteli, keying off a variety of behaviour and presentation logic.
Currently they sit in a weird place where they’re mostly hidden, but kind of also publicly visible.
Public body tags aren’t visible on the body page, but they are indexed by search and exposed in the JSON output. You can view authorities by tag if you know the tag name or the tag has an associated category. Only admins can add body tags.
Requests have similar behaviour to authorities, but you can create tags on requests via the pre-filled request API (the only way non-admins can add tags).
Correspondence messages can be tagged, but these aren’t used anywhere other than the admin interface.
Users can’t be tagged at the moment.
It’s time to move tags towards the same visibility options as other site content and make them prominenceable.
Prominence Levels
For now we’ll focus on the two critical visibility levels – normal and hidden.
normal will mean the tags will be safe for public display anywhere in the application.
hidden will mean the tags should only ever be seen by admin users.
New tags will have a prominence of normal by default.
Applying Prominence
We’ll add the usual prominence/prominence_reason fields to the admin page for a tag.
Prominence should apply to all tags of the same name and, for now, irrespective of tag value.
Given tags “foo”, “foo:123” and “foo:xyz”, changing the prominence of “foo” from normal to hidden will also make “foo:123” and “foo:xyz” hidden. Similarly changing the tag “foo:xyz” to hidden would also change “foo:123” and “foo” to hidden.
Indexing
Only normal prominence tags should be indexed by search.
Displaying Tags (Admin)
Where we display tags in the admin interface they should be accompanied by the appropriate “prominence eye”.
Displaying Tags (Public UI)
We won’t make tags too prominent initially.
In an appropriate place for the Taggable record (sidebar for Public Bodies and Requests; bottom of message for Correspondence) we should just render the list of tags. Some records can have loads of tags, so we’ll want to fold them up if there are 3+ to keep the interface tidy. Here’s an idea for how we might display them, but open to options:
Keep this relatively small in terms of font size, colours, etc. Tags should feel a bit “technical” / like metadata.
Each tag should link to an advanced search for that tag (/search/tag:foo)
Prominence of Existing Tags
We have a choice to make about what to do for existing tags. Given the current behaviour it ought to be safe to make all existing tags “normal” prominence, but this is something to think through.
We can be confident that any tag used for a Category or Note should be normal prominence. For others we’ll have to make a decision – either en masse or on a case by case basis. We know some request tags (e.g. contracts-advance) have been added via the API and so should probably be “normal”. Other tags may have been added with the intention of being relatively private (like our “case” tags that relate to internal case reference numbers).
The safer option for reusers would be to default existing tags to hidden, and provide an upgrade note for how to make them all normal prominence in a one-liner.
Tags are a cornerstone of Alaveteli, keying off a variety of behaviour and presentation logic.
Currently they sit in a weird place where they’re mostly hidden, but kind of also publicly visible.
It’s time to move tags towards the same visibility options as other site content and make them prominenceable.
Prominence Levels
For now we’ll focus on the two critical visibility levels – normal and hidden.
New tags will have a prominence of normal by default.
Applying Prominence
We’ll add the usual prominence/prominence_reason fields to the admin page for a tag.
Prominence should apply to all tags of the same name and, for now, irrespective of tag value.
Given tags “foo”, “foo:123” and “foo:xyz”, changing the prominence of “foo” from normal to hidden will also make “foo:123” and “foo:xyz” hidden. Similarly changing the tag “foo:xyz” to hidden would also change “foo:123” and “foo” to hidden.
Indexing
Only normal prominence tags should be indexed by search.
Displaying Tags (Admin)
Where we display tags in the admin interface they should be accompanied by the appropriate “prominence eye”.
Displaying Tags (Public UI)
We won’t make tags too prominent initially.
In an appropriate place for the Taggable record (sidebar for Public Bodies and Requests; bottom of message for Correspondence) we should just render the list of tags. Some records can have loads of tags, so we’ll want to fold them up if there are 3+ to keep the interface tidy. Here’s an idea for how we might display them, but open to options:
Keep this relatively small in terms of font size, colours, etc. Tags should feel a bit “technical” / like metadata.
Each tag should link to an advanced search for that tag (/search/tag:foo)
Prominence of Existing Tags
We have a choice to make about what to do for existing tags. Given the current behaviour it ought to be safe to make all existing tags “normal” prominence, but this is something to think through.
We can be confident that any tag used for a Category or Note should be normal prominence. For others we’ll have to make a decision – either en masse or on a case by case basis. We know some request tags (e.g. contracts-advance) have been added via the API and so should probably be “normal”. Other tags may have been added with the intention of being relatively private (like our “case” tags that relate to internal case reference numbers).
The safer option for reusers would be to default existing tags to hidden, and provide an upgrade note for how to make them all normal prominence in a one-liner.