Permanent Deck URLs

Background

The URL of a deck page is formed in such a way that it includes the deck revision, the slide id and revision if a slide is selected, as well as the path to the slide in question. There is the notion of a Deck URL that only includes the deck id (and not the revision), but once a visitor navigates through the deck slides, the URL changes to this "canonical" form. Moreover, when a user edits a slide and saves it, the URL for the slide will include the new revision. We currently support links to slides that only include the deck id and slide id and no revisions, but it's not clear where they are generated by the system (I've seen them in recent decks section of the home page), and once a visitor starts navigating the page they are replaced with the non-permanent, revision- and path-including URLs.

The way most people share links of pages is via the URL on the address bar. Constantly changing URLs that include implementation details like revision IDs create issues for people sharing those links.

There is of course a use case for URLs pointing to specific revisions, but those should result in pages where it is more clear in the UI that they don't relate to the currently active revision. I would expect when I edit a slide and save it for the URL to be the canonical form without the revision. If I bookmark the slide page and revisit at a later time, I expect to see the active revision. If I want to explicitly bookmark the revision-specific version, I should be able to use a dedicated revision permalink control or something like that.

Moreover, friendly and stable URLs are a major component of any serious SEO effort. People will include slidewiki links with URLs copied from their address bar in their pages, no matter how good a UX for permalink generation we may devise. In the old slidewiki the URLs also included the Deck title (slug form) which is also a good SEO practice we should apply in this version as well.

Another related issue is Deck visibility and URL availability. Currently, if a user creates creates and adds a new subdeck to a deck, that subdeck also has its own URL as if it was a root deck. Because the use cases for using subdecks are not restricted in any way, that user may not wish for this subdeck to be available on its own, because it would be out of context. Another use case where a user might wish for a deck they own not to be accessible in the web site is when they would like to delete a deck or when they would like to report a deck for license violation etc. This of course relates to the discussion here: Delete/Remove option for decks.

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:

1. 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
2. use this URL pattern when navigating the deck pages, always referencing the currently active slide revision
3. support URLs that reference revisions, but also:
   1. if the revision is the active one, redirect to the canonical form of the URL (without the revision)
   2. 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
4. 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)
5. Change the deck data model so that it includes an explicit flag whether we wish for this deck to be associated with a URL:
   1. for subdecks, we could still support a /deck/43 URL that would redirect to /deck/12/deck/43 (assuming the parent deck is #12)
   2. for deleted or reported decks we could redirect to a generic page that would include information about the deletion/reporting 

Action items