...
| Page Properties | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
...
Deck visibility, specifically of sub-decks, comes in another an issue as well: search results. Currently if a term is matched in a particular slide, the search service points to the deck that is the immediate parent of that deck. Users can still navigate to any parents of the deck using the Usage tab, but if that parent is only one (because the deck was created strictly as a sub-deck of the parent), it would be better for the visitor to access the slide in its proper context. If the deck author wishes for a subdeck to be available out-of-context of the parent deck, they should be able to decide to mark it as such explicitly.
An initial proposal could include the following:
- design a new URL pattern that would not include revisions or specific paths; it should point to a deck or a slide included in a deck
- use this URL pattern when navigating the deck pages, always referencing the currently active slide revision
- support URLs that reference revisions, but also:
- if the revision is the active one, redirect to the canonical form of the URL (without the revision)
- if not, the UI should clearly mark this on the page and also provide a quick way for the user to view the currently active revison
- Specify the URL handling in outliers such as a /deck/3/slide/5 URL that was bookmarked and the slide has since been removed from the deck (the URL pattern is an example for this case, and this could be solved perhaps with a different URL scheme, but any URL scheme is sure to have outliers)
- Change the deck data model so that it includes an explicit flag whether we wish for this deck to be associated with a URL:
- for subdecks, we could still support a /deck/43 URL that would redirect to /deck/12/deck/43 (assuming the parent deck is #12)
- for deleted or reported decks we could redirect to a generic page that would include information about the deletion/reporting
Action items