Make WordPress Core

Tagged: revisions Toggle Comment Threads | Keyboard Shortcuts

  • Erick Hitter 9:45 pm on February 19, 2013 Permalink
    Tags: , revisions   

    Revisions Update, 2/19 

    Following two consecutive days of office hours, we’ve reached a consensus on what the UI should be for comparing a single revision to the current version of a post:

    comparing-one

    Based on the above mockup from @karmatosed, @adamsilverstein is continuing development of the new revisions interface on ticket #23497.

    Once we have an acceptable, working prototype, we’ll revisit how to present the interface for comparing two different revisions. @nacin suggested, and we generally agreed, that a single slider with two grabbers would likely be a workable approach, but we’ll discuss that further once the above interface is implemented.

    No progress to report on the other tickets scoped for 3.6 as we’ve been focused on UI lately.

    [IRC log]

     

    • Ben Tremblay 9:58 pm on February 19, 2013 Permalink | Log in to Reply

      1st thought: the chunks appear w/o context. (I imagine it with a snippet of before and after.) You okay with that?
      #JustSayin’

      • Grant Palin 10:50 pm on February 19, 2013 Permalink | Log in to Reply

        Agreed, context is important. Just where in the document the shown snippet is located can make a dig difference.

      • adamsilverstein 11:27 pm on February 19, 2013 Permalink | Log in to Reply

        yes, for sure.

        although the mockup doesn’t make it clear, you will actually see your full document content, showing what has been removed, added (and what stayed the same), so the context is shown.

      • Peter Westwood 3:23 pm on February 21, 2013 Permalink | Log in to Reply

        The chunks appear without context because the mockup happens to show a full post rewrite :)

    • aldo.roman 7:11 pm on February 20, 2013 Permalink | Log in to Reply

      I follow the GIT (or others) DIFF as the mockup shows a ‘ + ‘ and a ‘ – ‘ signs, but I don’t think the end user will need them. Maybe the colours is enough and we can have a cleaner screen.

  • Erick Hitter 5:22 pm on February 18, 2013 Permalink
    Tags: , revisions   

    Revisions Update, 2/18 

    We’ve scheduled an additional office hours for Tuesday, February 19, at 2000 UTC in #wordpress-dev.

    During today’s meeting, we reviewed @adamsilverstein’s prototype on #23497, which led to a lengthy discussion about how the prototype related to our mockups, specifically http://core.trac.wordpress.org/attachment/ticket/23396/revisions9.png.

    @karmatosed will prepare a revised mockup for tomorrow that incorporates the slider introduced in #23497, and @adamsilverstein will tweak the prototype as well so that comparing a revision to the current version is the default behaviour.

    The feeling is that we’re straying from our intended goals, and I didn’t want to wait until our Thursday office hours to refocus. After tomorrow’s meeting, I’ll post a more detailed recap of where the Revisions team stands.

    [IRC log]

     

  • Erick Hitter 4:47 pm on February 13, 2013 Permalink
    Tags: , revisions   

    Revisions Update, 2/11 

    As has been the case for many sessions now, Monday’s revisions office hours focused on changes to the UI. @karmatosed provided new mockups, influenced by a thread on the Accessibility blog. @adamsilverstein also posted a series of patches on #23396 that begin to implement the general direction we’ve chosen for UI updates (aside: we’ll do our best to keep future mockups on this ticket, for easier discovery; until now, most have been posted in the comments on these update threads). We are certainly approaching a consensus on the new design, but have held off on any significant UI-specific coding until we’re confident that our efforts won’t be wasted.

    Beyond UI, there are patches on three tickets that could use testing: #16215, #22289, and #19932. @adamsilverstein and @westi are working on unit tests, which should help move the patch review along.

    We should have new mockups to review during tomorrow’s office hours at 1500 UTC in #wordpress-dev.

    [IRC log]

     

  • Erick Hitter 4:39 pm on February 7, 2013 Permalink
    Tags: , revisions   

    Revisions Update, 2/7 

    We started today’s office hours by reviewing @karmatosed’s latest mockups for the revisions screen. We’re in agreement that these reflect the direction we’ll take, so @adamsilverstein will begin coding the changes in preparation for Monday’s meeting. As some concerns have been raised about the use of red and green, @karmatosed will post to the Accessibility group’s P2 asking for feedback on the current mockups. She will also explore the use of patterns to differentiate additions and deletions, as suggested by @helen.

    @westi made a few suggestions, based on his recent experiences with Revisions, which we’ve agreed to incorporate. For clarity, the current version will be included in the revisions list to provide a stronger connection with the overall revisions workflow. Second, we decided that when first landing on the revision screen for a given post, we should show the diff of the current version and its immediate predecessor revision; since most users are probably looking for this anyway, why not save them a step?

    Lastly, we chatted about the status of code-oriented tickets scoped for 3.6. A few (#16215, #22289, and #19932) have patches, which we’ll be reviewing and providing feedback on before Monday’s meeting. With any luck, we can land at least one in Core before the next dev chat. Beyond that, development on the remaining tickets should progress over the weekend, with the aim of having more patches to review for our next office hours.

    For reference, the tickets that are in scope for 3.6 (at least at this point), can be found here.

    [IRC Log]

     

  • Erick Hitter 7:43 pm on February 5, 2013 Permalink
    Tags: , revisions   

    Revisions Update, 2/5 

    Yesterday’s meeting focused on revisions to the revisions interface :) . @lessbloat joined us to ask some great questions, and helped refocus the UI changes that have been proposed and mocked up so far. We started off by trying to identify the major uses of revisions, and settled on two primary cases: undoing mistakes by finding the last correct revisions, and reviewing changes as part of an editorial workflow.

    In light of those focuses, we’ve decided to revisit the UI mockups we’ve (namely, @karmatosed and @adamsilverstein) worked on so far. The general consensus is that they’ve become overly complicated, and led to feature creep (looking at you, line-by-line accept/reject capabilities). @karmatosed is working on some new mockups for Thursday’s office hours. One possible source of inspiration may be @benbalter’s post forking plugin.

    On the code side, @mdawaffe worked out a pretty comprehensive patch for the display of incorrect authors on revisions (#16215). We’ll be reviewing that, along with the patches added to the other tickets we’ve scoped for 3.6. As was the case when I last posted, progress is slow at this point due to travel and the ongoing UI discussions.

    [IRC log]

     

    • adamsilverstein 8:47 pm on February 5, 2013 Permalink | Log in to Reply

      i posted patches for testing that implement some of the mockup concepts we talked about during our meeting here – #23396

    • karmatosed 2:56 pm on February 7, 2013 Permalink | Log in to Reply

      I’ve got some more mockups for discussion in the meeting today here:

      I spent some time with @benbalter’s plugin and merged that with some of the ideas that seemed ‘easy wins’ from a UI view. It’s mainly a tidy up in a lot of respects. I did one with notes but understand this feature probably will not be included – I just wanted to see what it looked like.

      I felt the picking in the post forking plugin worked well for that instance but may be overly complicating for us as the ‘new’ would always be the newer version so that’s what I was keeping to by you just picking 2. I didn’t add a submit or confirm as figured if you picked 2 it could reload – we may want to reconsider this as perhaps a pause through clicking something could be useful.

  • Peter Westwood 11:16 am on February 4, 2013 Permalink
    Tags: , revisions   

    Revisions Update(s) for Last Week 

    These are combined and late (sorry).

    Last week we had two successful Office Hours discussions:

    We discussed the different mockups that both @adamsilverstein and @karmatosed have been working on with the discussions in the first meeting leading to some new mockups here: http://make.wordpress.org/core/2013/01/25/revision-update-125/#comment-7869

    And then @karmatosed created some further mockups after our second meeting bringing together our feedback and the different idea threads:

    Outside of the meetings our progress has been slow because most of us have been travelling for conferences / meetups

    Our next office hours are today at 16:00 UTC

     

    • John Saddington 2:09 pm on February 4, 2013 Permalink | Log in to Reply

      Just curious… are you guys using mockingbird mockup app for these? looks great!

    • Robert Chapin (miqrogroove) 7:42 pm on February 4, 2013 Permalink | Log in to Reply

      What’s the difference between Apply and Discard? Apply to what? Discard from where? What does it mean to discard a removal? I think this needs to be more verbose or more intuitive like Undo and Redo.

    • lessbloat 10:20 pm on February 4, 2013 Permalink | Log in to Reply

      I played around with an alternate concept this afternoon.

      My assumptions

      There are two major use cases:

      A) Undo a mistake I made

      B) Review changes & find mistakes other people have made

      With the major use cases in mind, here are the problems I see with the existing UI:

      1) With just a date/time stamp and author, there is no way to tell (at-a-glance) what revision you’re after from the post edit page, requiring you to click into revisions.

      2) Once you click a link from the post edit page, you are taken to a complete revision (without any comparison showing). This seems backwards to me. Seems like you should be taken to the comparison view by default. As you are oftentimes looking for mistakes, which are much harder to spot in the “complete revision” view.

      3) The “Revisions” table at the bottom is super confusing. :-)

      4) It’s hard once on the revisions page to quickly move through additional revision sets.

      My rough proposal

      With those use cases and existing UI problems in mind, here’s what I came up with:

      Post edit page

      On the post edit page show more details related to each revision (base them off of comparisons with previous revisions):

      Or perhaps:

      Which adds:

      • gravatar (optional)
      • words removed
      • words added
      • total words (after add/removed)

      Revisions page

      Start off in comparison view:

      • Default to comparison view
      • Assume that the user wants to diff against the previous revision. We could add the advanced diff table selection option (with the radios) back in as either a screen option, or boot it to a plugin (it really is painful to use).
      • Allow them to quickly paginate through all revisions (“View Previous” button)
      • Give them a sense of which revision this is (out of all of them) with the black/gray dots at the top.
      • Change the paradigm from “older” “newer” to “removed” always on the left, and “added” always on the right.

      If you mouse over the black/gray icons, more info would show up in a tooltip:

      Then if you clicked the “View previous” button you’d see:

      Anyhoo… It’s still super rough, but I thought I’d through the concept out there.

    • adamsilverstein 5:03 pm on February 5, 2013 Permalink | Log in to Reply

      thanks for the new mockups!

      before reading your post, i created a ticket and posed patches that implement some of the mockup concepts we had talked about during office hours – #23396

      a few responses -

      i really like the idea of entering the revision screen already comparing to the previous revision, i never understood why we have the extra option of viewing a revision by itself.

      i still don’t understand the meta box on the post page, even if you can pinpoint the revision you want, which is doubtful, you still have to click into the revisions page to restore the revision. for this reason, and because of use case A, i think a link into the revisions interface belongs near the publish button, see #23352. i would just leave the meta box as is (hidden) and focus on the actual revisions page.

      i really like the next/back idea, especially if we can get the view refreshing without page reloads. this will make it easy to go back to find the exact revision a user needs.

      the little dot idea with popups, while nifty, is not really accessible. what do you think of the idea of a left column showing the list of revisions? ideally, i’d like to see these grouped when there are more than a certain number, either by user or by hour; otherwise the list becomes unwieldy on posts with many edits.

      i’m not sure i get the paradigm of removed on one side and added on the other, how will the user know what the post will look like when the restore the revision? willing to try, but i think i prefer the direction of a combined diff view with labels down the edge.

    • Midhun Devasia 7:37 pm on February 6, 2013 Permalink | Log in to Reply

      I had an idea about the revision change updates.

      What I’m thinking is that, when a user want to find what was changed
      1. Show the last changes in Revision meta box.
      2. And it should show the “Inline Diff” between last version and its previous version. (Comparing Side by Side or left right methods are more complex for normal users, I think they prefer Stoked text, wth color changes of what they deleted and what they added from the last change or revision )
      3. The revision meta should show the abbreviation of Big changes.
      4. If he is still can’t idenftify the changes he can link to the revision management page.
      5. Show atleast 10-20 revisions on the Revision Metabox, or else pagination/link to revision management page.

      The Above points are only for Revision Meta box as considered as Quick Reference of the revisions/changes what they made. can give restore link there too, if he find that was his revision.

      I had submitted a rough working patch for the above Inline diff method.

      Check my ticket.

      http://core.trac.wordpress.org/attachment/ticket/18733/wp_revision_meta_.png
      http://core.trac.wordpress.org/attachment/ticket/18733/2Screen1.png

      http://core.trac.wordpress.org/ticket/18733

      Patch
      http://core.trac.wordpress.org/attachment/ticket/18733/Qucik%20Revision.patch

    • esmi 7:50 pm on February 6, 2013 Permalink | Log in to Reply

      Still rather concerned about the colours being used here — both in the original screenshots & @lessbloats alternative concept screenshots. Can we look at using colours other than red & green? Red/green is the most common form of colour blindness, so this could potentially impact on 10% of all make users. See http://quirm.net/temp/revisions-cb2.jpg for an example of how the original screenshot would look to a user with red/green colour blindness.

      I’ve also analysed the foreground/background contrast on both the red & green test. Both fail the recommended 4.5:1 contrasts ratio. The red is 4.3:1 whilst the green only manages a really miserable 2.8:1. Anything below the recommended 4.5:1 ratio will hit visually impaired users (not all of whom use screen reading software) and about 50% of dyslexics.

      • Peter Westwood 9:12 am on February 7, 2013 Permalink | Log in to Reply

        Your concern is noted and not forgotten, our mockups have focused on the layout of the page and I want to try different colours once we have something implemented so as to address the accessibility issues.

  • Erick Hitter 11:21 pm on January 25, 2013 Permalink
    Tags: , revisions   

    Revisions Update, 1/25 

    Yesterday, the revisions team had its second scheduled office hours chat in #wordpress-dev at 1600 UTC. @karmatosed and I were both afk, and our first chat was earlier this week, so it was a short meeting [IRC log].

    @nacin popped in to mention that he’ll be working on the API for draft changes to published content. This will overlap with, but shouldn’t take away from, the revisions efforts our team is working on. For reference, the ticket’s we’ve scoped for 3.6 are listed here.

    Overall, progress this week has been tentative, mostly focused around #16215 and #16847; thanks to @adamsilverstein for his efforts on those tickets thus far. A big area of focus in the near-term will be the UI improvements—there’s been a fair bit of discussion on this front in the comments here and here.

    Our next meeting is Monday, January 28, at 1600 UTC. At the moment, our office hours on Thursdays conflict with the Post Formats team, so one of us will have to move. We’ll keep the hours listed in the sidebar updated as we move forward.

     

  • Peter Westwood 9:42 am on January 23, 2013 Permalink
    Tags: , revisions   

    Revisions Update, Jan 22nd 

    This week the revisions team had our first in-person meeting and we started by setting out office hours for this cycle which are 4pm UTC on Mondays and Thursdays. We then went through and reviewed a large number of open trac tickets related to revisions to get a feel for the existing bugs and enhancement requests as well as to set down a line as to what we feel is and isn’t in scope.

    We ended our review with 8 “in-scope” existing tickets:

    Bugs:

    • #16215 – Post Revision history displays the incorrect author
    • #20982 – Attribution of changes via edit_last after restore
    • #16847 – Capability check fails for custom post type revision edit (& map_meta_cap no good)
    • #9843 – Duplicate autosave/revisions clutter the database

    Enhancements:

    • #/22289 – Filter to override WP_POST_REVISIONS (or define it later)
    • #19932 – More context when display revision info for plugins
    • #18733 – Show revision number for post/pages in Revision list
    • #7237 – Multiple clean_post_cache() calls when saving a post due to post revisions

    We explicitly left the following out of scope:

    • #9681 – Add hooks to allow a plugin to support the deletion of unneeded revisions
    • #20564 – Post Meta Revisions
    • #20299 – Preview changes on a published post makes all post meta “live”
    • #11049 – Page Preview does not autosave page template

    After the trac ticket discussion we then talked about UI ideas and set ourselves some goals for this week:

    • More UI mockups – to come in the comment thread here
    • Start investigating and addressing some of the bugs

    Full logs of our IRC Chat are here

     

    • John Saddington 12:19 pm on January 23, 2013 Permalink | Log in to Reply

      I wonder how many people have had mega issues with post meta revisions and wanting that. Hmm.

      • Helen Hou-Sandi 2:05 pm on January 23, 2013 Permalink | Log in to Reply

        Plenty of people. Doesn’t make it in-scope, though.

        • Travis Northcutt 2:24 pm on January 23, 2013 Permalink | Log in to Reply

          Given that Alex King volunteered (albeit 9 months ago, so I don’t know if he has the time right now) to clean up what they built for inclusion in core, would it be feasible to get it in scope if the work is done by people other than Westi et al.? (Serious question – I’m not familiar with how much work a committer has to do once a good patch is presented for inclusion).

          • Bryan Petty 8:24 pm on January 23, 2013 Permalink | Log in to Reply

            Maybe, but it wouldn’t hurt to start patch reviews, testing, discussion and revising on the ticket either way. If it’s ready in time and there’s someone with the time to commit it, great, but otherwise, there will be that much less work involved with getting it included in 3.7.

          • Helen Hou-Sandi 9:09 pm on January 23, 2013 Permalink | Log in to Reply

            Indeed, there is nothing wrong with working on it, anyway.

    • Stephanie Leary 4:07 pm on January 25, 2013 Permalink | Log in to Reply

      For the diff UI: what if we had Visual and HTML options just like we do in the editor? The HTML view would show the markup, as we do now. The Visual would show only the content changes. Here’s a very old example using del and ins tags to emulate Word’s track changes feature (this was before Word switched to the bubble style it uses now).

    • adamsilverstein 5:30 pm on January 31, 2013 Permalink | Log in to Reply

      there was some discussion today that #20564 and #20299 are going to block progress on the workflow changes, we may need to reconsider those tickets if possible.

  • Peter Westwood 10:26 pm on January 20, 2013 Permalink
    Tags: , revisions   

    Revisions Update, for 18th Jan 2013 

    As Aaron posted before the revisions team has two clear focuses:

    • Fixing the Author Attribution issue – #16215
    • Improving the usability of the differences for the average user.

    So far most of our discussion has been in the comment thread of Aarons post and I want to catch up on the in-person discussion and start in earnest on fleshing out the direction.

    To that end I’m going to spend the majority of Monday the 21st working through the current ideas and also reviewing any revisions related trac tickets to pull together our direction and I invite all interested parties to join me for a discussion session starting at 1400 UTC on #wordpress-dev.

    It would be great if @karmatosed, @ethitter, @adamsilverstein could all be there and we can also arrange when our regular office hours will be.

     

  • Aaron D. Campbell 11:21 pm on January 7, 2013 Permalink
    Tags: , revisions   

    WordPress 3.6: Revisions 

    Revisions are an extremely powerful tool for content tracking, but there are a few parts that need a little TLC. Ever since they were first introduced, there’s been a problem with proper author attribution on revisions (see #16215), and we’re going to take a crack at fixing that in 3.6. Additionally, while the current diffs are pretty cool, and make a lot of sense to those of us that look at diffs everyday, there’s a lot of room for improvement for your average user. We’d like to see some UI improvements around the diffs as well as information that makes more sense to an average content creator (words changed, a visual representation of what was added/removed, prettier output, etc).

    @markjaquith and I chose @westi to lead this. I’m excited to see the improvements on this one! There’s a little of everything in this project, so please leave a comment if you’re interested in lending a hand.

     

    • Alex Mills (Viper007Bond) 11:25 pm on January 7, 2013 Permalink | Log in to Reply

      It’d be nice to have revisions also include post meta and taxonomy data so that when restoring to a previous revision, the whole post’s state could be restored.

    • adamsilverstein 11:28 pm on January 7, 2013 Permalink | Log in to Reply

      i’d love to help with this.

    • Rafael Ehlers 11:31 pm on January 7, 2013 Permalink | Log in to Reply

      And make define(‘WP_POST_REVISIONS’, false); works!

    • karmatosed 11:32 pm on January 7, 2013 Permalink | Log in to Reply

      I’d love to help from a UI angle on this.

    • Erick Hitter 11:58 pm on January 7, 2013 Permalink | Log in to Reply

      I’m very interested in helping with this.

    • zippykid 12:32 am on January 8, 2013 Permalink | Log in to Reply

      +1

    • janw.oostendorp 1:49 am on January 8, 2013 Permalink | Log in to Reply

      A suggestion. Can revisions be stored like only save one revision a day per post? Most of the time I would want to restore a revision I already overridden the nr I’ve set on that day. So I can’t go back to yesterday.

      Maybe save all revisions of this day and 1 for every day that is defined in `WP_POST_REVISIONS`.
      Just a suggestion.

      • Peter Westwood 9:38 am on January 8, 2013 Permalink | Log in to Reply

        This sounds like an interesting idea. I think our primary drive will be around the presentation and making it much more user friendly.

        It may be that we can alter the presentation to provide a less verbose history by default with only one revision per day highlighted while keeping the full history as well – the full history is really useful in the context of one of the key theme of 3.6 – never lose your content.

        • Curtiss Grymala 4:22 pm on January 8, 2013 Permalink | Log in to Reply

          While I think this is an interesting idea, I think it might be just as helpful (more helpful in my use-cases) if revisions were actually systematically compared at some point, and identical revisions were either dumped or not highlighted.

          For instance, let’s say I go in to look at a post (for instance, to copy a shortcode I used in it, etc.) and then, out of habit, click “Update”. Although I didn’t change anything in the post, WP stores a separate revision for that update, and shows that in the list of revisions. It would be nice if WP was able to compare that version to the previous version, recognize that nothing changed, and downgrade that revision somehow.

          I think, either way, we would need to look at somehow classifying revisions (possibly with a +1 or -1) to differentiate between revisions that should be highlighted (for reversion purposes) and those that are just stored for record-keeping (basically just to know when someone accessed the edit page for that post).

          • wedi 7:17 pm on January 9, 2013 Permalink | Log in to Reply

            That is really a big point. It’s quite annoying to click through several revisions to find the last real change.

    • esmi 2:53 pm on January 8, 2013 Permalink | Log in to Reply

      Can some of the accessibility issues associated with revisions also receive some attention? Specifically, the Compare Revisions table.

      1. As this is a form, each of the radio buttons needs an associated label. By all means, position the label offscreen if you must but without those labels, the form is virtually impossible to use in some situations.

      2. Can we have unique text for each of the Restore links? Again, position the unique fragment offscreen if necessary but handful of identical-sounding links creates major problems for some users.

      3. Ideally, get rid of the table markup. Forms + tables = accessibility problems for many users.

      • Peter Westwood 10:55 am on January 9, 2013 Permalink | Log in to Reply

        Can some of the accessibility issues associated with revisions also receive some attention?

        We will definitely look at the issues you have highlighted and see how we can best address them.

    • lessbloat 9:27 pm on January 8, 2013 Permalink | Log in to Reply

      Thought I’d play with some visual indicators showing whats changed between diffs, so at a glance you can see: “Oh ya, this is the one where I just removed on line”, or “this is the one where I removed 5 paragraphs”.

      Option 1

      Option 2

      Option 3

      Option 4

      Hat tip to MarkJaquith for the concept.

      • Aaron D. Campbell 9:33 pm on January 8, 2013 Permalink | Log in to Reply

        I really like it. Personally I think the bars are more user-friendly than the raw numbers, but I don’t have much preference between those three.

      • karmatosed 9:58 pm on January 8, 2013 Permalink | Log in to Reply

        I like the bar dots the most but my worry about any graphical indicator like that is a ‘what does it mean’. 3 red dots to me or a lump of a bar isn’t as instantly recognisable maybe to all users. I guess my question would be: “Is it important to know what of what”? If that’s the case then a number is far more indication. If a vague idea is all that’s needed then exacts aren’t as required.

        Worth exploring around other ways of representing I think aside from ones that require more maybe guess work as to what % of what?

      • GrahamArmfield 10:10 am on January 9, 2013 Permalink | Log in to Reply

        As a sighted person a visual representation can sum up a concept neatly. Unfortunately not everyone is sighted or has clear sight. Using colour as the only way to convey meaning can also be problematic – especially in your choice of red/green. Some 8% of men and 2% of women are colourblind – with red/green colourblindness being the most common.

        Any solution like this needs to also include plain visible text to indicate what the bars mean. I’d especially echo karmatosed’s point – will even all sighted users understand what’s being represented here. And how would the dots/lines represent removing some characters and adding some different ones?

      • Peter Westwood 10:57 am on January 9, 2013 Permalink | Log in to Reply

        These are neat and address a piece of the UI that I hadn’t even considered improving yet :)

        If we don’t focus on trying to condense the visualisation of the whole diff down into some coloured fragments are there ways in which we can highlight if the diff is a large or small change well?

      • wedi 7:18 pm on January 9, 2013 Permalink | Log in to Reply

        That is great! An indication if the content or just meta data was edited would be very useful, too.

      • ArielK 7:48 pm on January 9, 2013 Permalink | Log in to Reply

        I like “option 1″ it’s very clear & simple.

      • Sam Parsons 11:06 pm on January 10, 2013 Permalink | Log in to Reply

        Here’s an idea of a mockup that would show both visually and give some words to explain to those not accustomed to this type of image and to those who have visual impairments (either color-blindness or others).

        mockup of the revision interface.

        • Peter Westwood 1:30 pm on January 11, 2013 Permalink | Log in to Reply

          This is quite neat, I wonder if this is too specific though :)

          What people probably want to know is things like:

          • Is this the revisions where I fixed that typo
          • Is this the revision where the editor re-wrote my whole post

          It will be interesting if we can present something more like a graduated size of change metric which has more end-user meaning that something very technical like word count – especially when word counting is so hard to get write in some situations like some asian languages.

      • karmatosed 1:07 pm on January 18, 2013 Permalink | Log in to Reply

        I had a bit of an experiment around this area. One thing that struck me was how small the content is for that wide area. It perhaps means we can use that area to give more information – people seem to be saying different information is useful to different users so perhaps just saying the time, who and an indicator isn’t enough.

        I also thought a bit about how things like commit messages and ways and along with different representations came up with the following.

        I know it’s very different from what have now it’s more just an exploration of a few things and doesn’t have to all be used.

        • karmatosed 1:09 pm on January 18, 2013 Permalink | Log in to Reply

          I just realised that squashed it down a bit in the message so here is the original linked to see it a bit more clearly:

      • karmatosed 1:25 pm on January 18, 2013 Permalink | Log in to Reply

        I also did a different exploration using bars.

    • esmi 11:33 am on January 9, 2013 Permalink | Log in to Reply

      If you’re going with the red/green combination, please consider using numbers – not bars. http://quirm.net/temp/red-green.png shows the display as it would be seen by those who suffer from 2 out of 3 of the known forms of color blindness. Using numbers would also by-pass any issues for non-sighted users and give everyone a clear indication of the changes made.

      • Siobhan 3:07 pm on January 10, 2013 Permalink | Log in to Reply

        In terms of writing, numbers are much more useful as they provide context. Also, word count is more useful than character count.

    • talgalili 10:51 am on January 12, 2013 Permalink | Log in to Reply

      Hello all,

      I would like to ask for another feature:
      When comparing two revisions, allowing a reviewer to have an “accept/reject” for each section changed (in a similar way as offered by libre-office or MS-word), which at the end of it will create a new revision.

      Background story for the request: I recently had the need for such a feature, since I have three friends working on the same post, where one is more “senior”. The senior friend wanted to be able to accept/reject changes by the other contributors. Since this was not an option in WP, we decided to do the first draft of the post in word, and exchange it by e-mails.

      Thank you all for taking on work at this front :)
      Cheers,
      Tal

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel