KDE Developer
|
In Calligra 2.4 we disabled change tracking because it didn't have the quality we felt comfortable releasing.
Now I ask you dear users to share your requirements for the ultimate change tracking systemt. But also describe how you have been using change tracking in the past (in any application) and what was good and bad, what you felt missing, etc. I'd like personal accounts and anything you share should be free from interlectual property claims. Just go ahead.. |
Registered Member
|
Timeline:
Personally I find that often you want to be able to read how something was at a point in time, but the way other apps (ie LibreOffice etc) display every piece of data added or removed, included deleted bits crossed out, makes it essentially unreadable. For me what works far better is Etherpad's time slider where you can easily skip to any point in time and see the document exactly as it was then. In-document comments: Another improvement would be comments that are clearly visibly linked to the place they were inserted. Often, with the insistence that comments be shown in the sides bars, it can get hard to tell which comment comes from where, when there are multiple comments on a single line. My preference would be to show some small marker indicating that there was a comment inserted at exactly point X in the text, and have it show when moused over. This could be default, with the option to drag the comment pop up over to either side to show permanently. If someone moused over it, the marker on the text could be hilighted to show their connection. Mouse free commenting: It would be nice if changes done by a user recognized by Akonadi could have an avatar from Akonadi. A small thing that would help when doing a lot of comments... If I select "Add comment" and immediately start typing, the text should start appearing in the comment without having to mouse over to it on the side of the screen. It would be nice if Ctrl+Enter or similar then saved the comment and returned the cursor to where it was in the document. Relative dates / times: An option to show dates / times in relative terms (ie 15 minutes ago) rather than absolute (12:31 April 28, 2012) would often help scanning comments for the most relevant ones. Previous / Next: Buttons to skip to the next / last comment. 'Nuff said. That about wraps it up for me. That's what I'd love to see. |
Registered Member
|
First, I would like to express my support with everything the previous poster said. Second, I would like to request another feature: a "diff"-like view in two columns that shows only what has been changed with a bit of context to every change (i.e. ca. two lines of text before and after the actual change, with the changed words highlighted in colors).
|
Registered Member
|
I do use change tracking (or review mode) a lot. I am a scientist and often work with other colleagues and polishing a report takes a lot of effort. Since we have to be careful that we are not imposing ourselves on others, change track is a very useful feature as it allows the other party to accept or reject our inputs.
For small articles, in document addition deletion with different colors is what I use in LO which my collesagues can access from MSO. For bigger documents, a separate view where big changes are shown in the margin are better suited. I do run Kubuntu and use LO for daily work, adoption or calligra is tricky for me as I have to care about interoperability. I found font rendering in calligra is far superior than LO and hence fount it much more joyful to use. Rajendra |
KDE Developer
|
Thank guys
Keep the input coming. I'd like to get to know more about the work flow you want supported in regards to the actual changes. For example if several people want to change the same part of text. How whould you like to keep track of who does what, and should each persons changes be remembered even if someone else make other changes. And how about changes to changes? And are such concerns even relevant, or would something simple regarding this be enough? |
Registered Member
|
Ok here's my mockup of how I would ideally have it, with an explanation of how it works underneath:
1. The blue triangle would show all the time, indicating the beginning of a change. The blue underlines indicating which area hads been changed, is something that probably needs the ability to be turned on / off as desired. 2. When hovering over (clicking?) the blue triangle, the popup is shown with the different revisions. Each revision shows the avatar for the user who made it, from Akonadi. I'll cover what happens if revisions are too big to display in the pop up further down. 3. The double blue underline indicates a part that is different in various revisions. 4. Where revisions are long, the popup could show the selection of text different to the other revisions with elipses (...) to indicate that the text continues before and/or afterwards, much like google's search results show selections of text in the website that include the words you searched for. In this example it could show "...is awesome!" "...is fantastic!" without showing the whole sentence. 5. Hovering over the avatar shows the name of the person and when they made the revision. 6. Clicking the left / right arrows jumps to the previous / next place in the document where changes exist. 7. Clicking the trash icon (which would look clearer if I used the proper 16x16 Oxygen icon in this mockup) deletes the revision. 8. Clicking the up / down arrows (or clicking on a revision in the popup) shows that revision in the document, but does not take the revision pop up away (so you can easily click through and see multiple revisions). This also allows people to scroll in the rare cases where the number of revisions on one change becomes long enough that it doesn't fit the screen. 9. Clicking outside of the popup makes the popup dissapear, leaving whichever revision was selected. 10. When a revision is selected and the text in the revision in the text is edited, it becomes a new revision. New revisions could either appear at the bottom of the list (for top down reading languages) or it could appear underneath the revision that was edited to create it. (Analagous to web browsers either opening new tabs to the far right, or after the currently open tab). Now, with *any* system for dealing with changes, if you have changes with many revisions involving very large chunks of text, you're *always* going to run into problems with not being able to display the change text for all revisions all of the time (due to screensize being finite). For that reason, the best solution seems to be to display one revision, in the document itself (which also makes it easy to read in context), and make it as easy as possible for people to switch between revisions. This is what I've tried to do with this design. Note: Ideally, in my mind this would be *in addition to* an Etherpad style timeline, not instead of it. Hey, we are talking our ideal world here! ;P |
Registered Member
|
On a similar theme, people often make minor formatting changes; and those changes often are not even part of real edit. So, Id like to suggest that it should be possible to not show formatting changes, or not show formatting changes that are not associated with a text change. Or something like that...
|
KDE Developer
|
Thanks a lot again. More, more of this
@shaheed not show or even not record?, and how much granuality in format changes |
Registered Member
|
Well, I wasn't the one suggesting it, but it is a great idea. Regarding your question, I would say definitely only an option to not show. |
Registered Member
|
@boemann...
On the subject of whether format changes should be recorded,I suspect it would be a mistake not to record them. As for the display side,my own use cases tend to be for technical specifications where the formatting is often of less concern that the content. However, there will be cases where the semantic value is influenced. A specific case of the latter might be the promotion of a piece of body text into a list item, and I guess this is the sort of thing you have in mind when you asked about granularity of display. I guess it will be tricky to come up with something that is both intuitive and workable. How about a spectrum based on likely semantic value like this: (most important) - Conversion between list style, heading style and other style. - Font size, underline, colour - whitespace only changes (indentation, linespacing, justification) (least important) or something along those lines. |
KDE Developer
|
Yes that is what I meant by granularity
And thanks, I think you division makes a lot of sense |
Registered users: Bing [Bot], claydoh, Evergrowing, Google [Bot], rblackwell