View Single Post
  #7  
Old Sep 8, 2013, 05:49 AM
Cedille Cedille is offline
Senior Member
 
Join Date: Sep 2007
Location: Tokyo
Posts: 2,026
Default

Actually, I've not actually paid much attention to our diff function while knowing it was far from perfect, but nowadays I feel it really hurts not to have a proper edit history viewer for a user submission-based website like us. There is another comparison viewer for admins/staffs, and although it shows both the original and edited texts, it doesn't give any highlight to tell where the difference is and thus it's still lacking. In the longer term, we'll hugely benefit from a little coding work to have a better diff.

I think our diff isn't that bad. It's very quick and comprehensive, in comparison to Wikipedia's crappy one. It claimed "Nobuo Uematsu" and "Uematsu Nobuo" are the same (and for that matter "Nobuo Uematsu Uematsu Uematsu Nobuo" is the same as well), but perhaps it just takes a heuristic approach for the presentation. So, on the condition that the current algorithm gets the shortest edit script, we only have a problem with the presentation that can be vastly improved by two or three steps.
  1. Separate added and deleted characters into different sections, since mixing them in one section is just a mess. In other words, do it like SVN or Github.
    Spoiler:
    Bad:

    Good:

  2. Replace " " (aka "\x20") by   or something else that styles can apply to , so that trimmed space is always highlighted.
  3. Extract only 3 lines before and after the difference exists (only for notes). If a change is only a few characters in the wall of texts, it doesn't make sense to show the whole text.
    Spoiler:
    Very Bad:

    Good:

  4. A tab-menu for selecting Album/Tracklist/Scan/Links. Forcing users seeking for tracklist diff to scroll down the album edit history isn't good.

I created a mock viewer from scratch including an O(NP) algorithm to see if I was asking too much at all, and I find that 1) and 2) are pretty easy and requires only a little work (but of course, depended on the current implementation). 3) may require some efforts. 4), while I don't try yet, doesn't look hard. If VGMdb provides. a GET API for edit histories, somebody can host an external service, but nothing beats an official implementation, so I'd just hope it would be pushed onto a task list by any chance.
Reply With Quote