Archive for the ‘etherpad’ Category

  • Collaborative Markdown editing and export in Etherpad

    Date: 2013.04.11 | Category: etherpad | Response: 0

    Features:
    * Use rich editing buttons and see rich edits and markdown together or toggle between markdown/up visibility.
    * Export Markdown

    Great for newcomers and Jedi’s alike.

    Gsl8fuT Collaborative Markdown editing and export in Etherpad

    Grab the ep_markdown Etherpad plugin

  • Introducing Text alignment in Etherpad

    Date: 2013.04.09 | Category: etherpad | Response: 0

    JzGMZfR Introducing Text alignment in Etherpad

    Grab ep_align from the plugin repository icon smile Introducing Text alignment in Etherpad

  • Comments in Etherpad

    Date: 2013.04.07 | Category: etherpad | Response: 0

    I have been playing with a proof of concept for Comments in Etherpad.

    This wont be available as a free plugin but if you are interested in sponsoring development or using it please get in touch!

    RAp4XHR Comments in Etherpad

  • Getting author ownership right in a collaborative editor

    Date: 2013.04.06 | Category: etherpad | Response: 2

    In this blog post I’m going to explain the complexities of getting content ownership in a document right. All popular collaborative editors get this wrong, some more drastically than others.

    Knowing who owns a certain piece of text in a document is an extremely important part of a collaborative editor, I will explain why later in the post.

    Let’s start with a basic example.

    John writes.

    My dog ate the tree
    

    Now Dave swaps the words tree and dog around. We get

    My tree ate the dog
    

    The actual sentiment of the sentence has changed a lot but that wasn’t John’s intention yet if we look at the sentence in all collaborative Editors there is no representation that Dave modified the text.

    As you can imagine this is a huge problem as far as sentiment analysis, Etherpad suffers from this too. Sentiment is distorted without the viewer being aware, imagine now we are working on a legal document and we replace the word tree and dog with friend and zombie…

    As text is modified in Etherpad new attributes IE underline/bold/strikethrough aren’t made clear to the viewer. IE if John writes

    Hello world
    

    Then Dave applies a strikethrough on this text we have no recollection that Dave made this modification. The viewer is under the impression that John struck this this piece of text, this is misleading.

    Undo also falls into the trap of modifying someone elses text without it being clear, the same applies as the basic example, sentiment can be modified without the original Authors consent.

    So what’s the solution?

    Boldly going..

    At current each piece of text in Etherpad has an author owner, I propose that on attribute modification (IE bold/strikethrough) additionally each additional author exists in an “editors” array. The original author would still be listed as the “creator/author”.

    To the replicator..

    In the “tree ate the dog” example the original author(John) should still be maintained but additionally(this is the new bit) the editor(Dave) should be added to the “editors” array. Part of Etherpad’s design is that as text is Copy/Pasted the original Author is maintained, this is healthy and by adding the editors array we should be able to identify that Dave has modified John’s content.

    Undoing the deed

    John might delete Dave’s text then hit Undo but then we have to decide if the undone text is owned by Dave, John or if it’s owned by Dave with a modification from John. Again adding Dave as an editor of the content would make it clear that a second author has modified the content.

  • Using git bisect to debug Etherpad issues

    Date: 2013.04.02 | Category: etherpad, git | Response: 0

    Sometimes stuff gets broken due to new commits, we need to know which commit broke functionality.

    To do this

    git pull
    git checkout develop
    

    Ensure the bug exists then

    git checkout master
    

    Ensure the bug doesn’t exist. If it does checkout older versions IE git checkout release/1.2.8
    Next begin the bisect process..

    git bisect start
    

    Tell bisect that master is fine

    git bisect good
    

    Tell bisect that develop is bad

    git checkout develop
    git bisect bad
    

    Bisect will then deliver you a commit state, test this new version..

    bin/run.sh
    

    Test, Control C.. Did it work? If so…

    git bisect good
    

    Did it not work? If so..

    git bisect bad
    

    Rinse repeat ‘git bisect good’ and/or ‘git bisect bad’ until it delivers you with a commit SHA then create an issue including the details from the SHA.

    Basically bisect will tell you which commit introduced the bug.