Optional meta data field

Gabe's Avatar

Gabe

12 Feb, 2013 10:06 PM

In an early version of CM, we supported meta data for all comments with the format:

 {++some added text++[GSW 2013-02-12 16:58:53]}

We were converting that meta data to several different kinds of HTML, including <span class"criticmeta">.

We dropped it because it felt awkward and overly complicated. We also weren't thrilled with the HTML preview options.

The team over at Fountain.io are very interested in bringing that back and I see no harm in making it optional.

Obvious problems would be reduced readability of the plain text and inconsistent conversion to HTML.

A possible alternative is to use a comment immediately following the CM to denote meta data:

  {++some added text++}{>>GSW 2013-02-12 16:58:53<<}
  1. 1 Posted by fletcher on 13 Feb, 2013 02:57 AM

    fletcher's Avatar

    It seems to make sense to pick one or the other.

    {++foo++}{>>bar<<}
    

    or

    {++foo++[bar]}
    

    I'm not sure I see the benefit of having both, other than adding confusion, and requiring developers to support even more complex regular expressions to get everything to work.

  2. Support Staff 2 Posted by Gabe on 13 Feb, 2013 03:04 AM

    Gabe's Avatar

    I think the primary use case is not for a comment. They are looking for edit specific meta data like author initials and timestamp. The specific instance is to allow multiple editors on a single manuscript.

    I'm less worried about confusion and more worried about handling edits within edits or partially overlapping edits.

    I suppose in a large manuscript like they use Fountain for, that would be less likely, but still a concern.

    Another proposal may be more simple. Prepend an author name with an "@". That seems easy enough and doesn't require any change to CM syntax. Can be searched or (if desired) separately matched by another toolkit.

     {++some added text++}{>>@GSW my comment<<}
    
  3. 3 Posted by Brett on 16 Feb, 2013 03:57 PM

    Brett's Avatar

    I think the question of multiple editors on a single manuscript is significant, and worthy of its own thread and, perhaps, even worthy of mention in the website itself. I love the idea of CriticMarkup and would find it even more useful if it were clear how I could share my documents with more than one editor at a time.

  4. 4 Posted by fletcher on 16 Feb, 2013 04:08 PM

    fletcher's Avatar

    > I think the question of multiple editors on a single manuscript is significant, and worthy of its own thread and, perhaps, even worthy of mention in the website itself. I love the idea of CriticMarkup and would find it even more useful if it were clear how I could share my documents with more than one editor at a time.

    I think best practices for this will probably evolve over time, and will be different between groups. A separate thread allowing feedback from many people over time would be a good idea.

    Composer 2.1's ability to compare files would make it easy to bring back changes from multiple editors, but I'll need to work on how it reimports CM syntax - you would end up with something like {++{++ksjdksjd++}{>>sdsds<<}++}, which would be confusing, but technically would work.

    F-

  5. Support Staff 5 Posted by Gabe on 16 Feb, 2013 06:34 PM

    Gabe's Avatar

    Fletcher highlights the exact problem with multiple editors that needs to be solved. How do we handle conflicting or overlapping edits? I've tried to mimic the best parts of MSWord Track Changes in some prototypes. Even there multiple editors can easily confuse a reader.

    I'd like to see what evolves over time rather than force a narrow decision now. I rarely work in a multi-editor environment so my decisions would not be completely informed. However, by using a blame string in a comment tag, we don't break any other syntax and authors are required to be a bit more considerate of overlapping edits.

    Here's an example of how I see it working right now:

     {++some added text++}{>>@GSW 2013-02-12_16:58:53<<}{>>@EH 2013-02-16_13:32:59 I disagree. I think this text is superfluous<<}
    

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

Recent Discussions

12 Jul, 2019 08:01 PM
10 May, 2019 05:30 PM
15 Dec, 2018 02:29 PM
17 Oct, 2018 07:57 PM
18 Aug, 2018 03:32 AM