Taking the layout of this blog as the starting point, I have looked at how to indicate that an article has been superseded. In this design the text ‘This Article has been superseded’ is appended after the date, with a reveal triangle.
The reader can click on this to get options to simply acknowledge this (OK), and the red text becomes light grey, to view the latest version or to view the version history.
Other design thoughts in this mock-up are having next and previous post buttons be on the right side of the screen so as to follow the logic of scrolling back and forth.
There are no lists of Categories here, they are for the Timeline view.
The Commenting system has been removed, in an effort to make comments be full posts with high resolution addressing in citation. Any comment with Pingbacks will be listed at the bottom of the screen. The reader can click to expand to show more (full or partial post) and have further options when expanded to jump to the article.
So this is obviously a RFC for a ViewSpec. There are two ways to spec ViewSpecs: one would be to write one RFC per ViewSpec feature, so different features can be combined into a rendering layout, or to spec a rendering layout as a whole, containing several ViewSpec features. I’m for the first option, otherwise we’ll just create a mess that’s not standardizable and reusable.
“is appended after the date” assumes that there is a date. As of now, we don’t have a RFC that specs a format for text resources or a capability that would describe where a date is supposed to come from, and just expecting that it should be WordPresses format would evoke a whole bunch of comments, so I’m reading the suggestion as “is appended somewhere”.
“The reader can click on this” assumes that a mouse capability is present, which might not be true for all systems, for example terminal environments, e-ink devices or print might not offer such functionality, so I propose that the supersede indicator is purely informational in cases where no confirmation capability can be provided. Acknowledging the indicator is something to be stored by the client.
Any formatting of the indicator text before and after confirmation should be configurable by the user as a general system setting or as part of a session/context configuration, maybe offering a suggestion by the author/source or other sources, but how those settings are managed is part of the general ViewSpec infrastructure and not subject of this RFC, so this RFC only describes that based on the confirmation status of the indicator, the indicator can be visually changed by applying settings that aren’t subject of this RFC.
“view the latest version or to view the version history” is very vague and there are no RFCs yet how the latest version or version history might be managed or rendered, so this RFC suggests that systems that are already able to provide such functionality, are allowed to add it to the supersede indicator in whatever way they’re able to, but it’s not recommended to rely on the availability of these options at the indicator.
I ignore the other suggestions as they’re not related to this ViewSpec feature RFC. To make the ViewSpec feature work, we need another RFC that describes how the supersede indication can be published. Note that this mustn’t necessarily include provisions on how the latest version or version history is related to the indicator, because that would be a whole thing of its own, not coming from the visual design of a ViewSpec feature, but the simple capability to indicate (and have the indication published and retrieved) that a text is outdated is already useful for systems to provide only the latest, not superseded material, or to learn about what resources do not need to be retrieved if the user doesn’t want to look at the historical past.
Copyright (C) 2018 Stephan Kreutzer. This text is licensed under the GNU Affero General Public License 3 + any later version and/or under the Creative Commons Attribution-ShareAlike 4.0 International.
I think your post highlights issues we need to deal with. I would so very much like to be able to comment inline, instead of separated, here. Anyway:
Yes, viewspec should be modular.
Yes, there may not be a date so this should be just one option for showing if the document has been superseded.
Clicking is assumed for the first version I think, but we must definitely look into other interactions for other devices.
Lots to discuss, but this dialogue itself is very worthwhile I think.