in reply to Suggestion for a new tag: <update>

Hi. Thanks to all above for your feedback. I guess, I have to clarify the motivation a little bit...

The main intention was to make significant updates visible by authors and customisable by readers.
It was not my intention

Admittedly, using <del> and <ins> inside the examples for <update> markup might have lead to that conclusion. Here, the intention was to demonstrate that there is no interference when using them intermixed.

My main observation was, that there are typically two kind of updates. First, editorial changes (grammar, spelling, formatting) and second, content changes (corrections of errors, background information added, etc.). It seems to be common understanding that an updated node is marked (usually at the end of the contribution) with the Update: keyword and some additional text. After this visual marker, some authors describe editorial changes, but most authors add significant information to the node, both activities reveal that the authors care about what they have written (quality). So it might be worth for a reader to re-visit such a node.

Thus, updating a node is also a kind of asynchronous communication between the author and the reader. I thought, it would be useful that an author can <update> a node and thus say I consider this update a significant content-change. The reader at the other end of the communication channel might say I don't care. Don't bother me. (no special markup of <update>'d sections / site-default). But another reader might say Please make <update>'s prominent, so I can immediately see them while skimming through the nodes. (e.g. by specifying a private CSS style for such content). Using markup to identify such a section can serve authors as well as readers while making the new content accessible for tools.
Multiple updates could be enumerated manually by using <ol> / <li> inside the <update> block... so there will be usually only a single instance of <update> present .oO(...consecutive update blocks might be merged and enumerated automatically...).

Example: A possible use of a tool might be to add a marker (again: the reader can decide - as with Monk levels - if (s)he wants to see them) to the entries of Recently Active Threads. The (first N characters) of <update> could be inlined or made visible by tool-tips. A page with significantly changed (SoPW only?) nodes could be created - like we already have for Recently Updated Home Nodes.
The PM engine knows that there was an update because the <update> tag was found but maybe the same thing can be achieved by adding a checkbutton significant update close to the Update! button?
Maybe a tag could be added to indicate an insignificant editorial change (though appreciated) like so <update type="edit"> or with an alias <edit> hiding the change from being detected by the tools - but that might be more complicated than intended first? ...arrgh - creativity overflow...

As said in the OP, it's just a suggestion. If it is considered useless, that's fine with me - but it was hard to tell in advance.

Thanks again for you feedback.

Replies are listed 'Best First'.
Re^2: Suggestion for a new tag: <update>
by ELISHEVA (Prior) on Mar 02, 2009 at 20:22 UTC

    While your proposal would give authors a way to mark major updates, I don't think they would solve the communication problem, for two reasons:

    • The user may not want to use special tags: some people have enough trouble just mastering paragraph and code tags. The net result is that many significant updates, especially by beginners, will not get marked.
    • I don't generally go back and read threads until a new node is posted on the thread, so I may never be on the thread to see the specially highlighted update.

    What would help me would be a node equivalent to what we have now for major and minor updates to user pages:

    • an easy way for the author to self-nominate their change as a 'significant change', for example, by having an update and major update buttons (instead of the one button that now exists).
    • an option to see major updates flagged on either (or both) "Newest nodes" or "Recent Threads".

    Best, beth

[reply]
      I don't generally go back and read threads until a new node is posted on the thread

      Neither do I. That's why I never bother to put the word 'update' in my node, or make my node harder to read by inserting strike throughs. If I update my node it's either to fix spelling, grammar or markup mistakes, or to add or clarify a missing or unclear issue - but the latter I only do immediately after posting.

      In all other cases, I just followup to myself. It's easier for me, and people following the thread see an update was made. And the original is still there.

[reply]

        Yeah, that is the best practice for exactly those reasons.

        Certainly, there are cases where updates are just fine (essentially, where the update is helpful to people seeing the node for the first time but won't be missed by those who have already read the node).

        As for augmenting Newest nodes with Newestly minorly updated nodes and Newestly majorly updated nodes and User settings for what constitutes 'major' vs 'minor', no, as you can probably tell from my ficticious title choices, I don't see that as a great direction to go. (And the "this is a major update" checkbox has been a good example of a site feature that doesn't work very well in practice.)

        So I don't see much value in complex features for assigning timestamps to updates, etc. The best way to put a timestamp on a clarification is to put that clarification in a new node.

        - tye        

[reply]

In Section Perl Monks Discussion