search

FlominatorTM / wikiblame

http://wikipedia.ramselehof.de/wikiblame.php
GNU General Public License v3.0
54 stars 13 forks source link

Feature request: reverse direction #1

Open waldyrious opened 9 years ago

waldyrious commented 9 years ago

It would be nice if we could have a checkbox to choose to go in the reverse direction (from the "start date" to the future, rather than from the start date to the past).

In fact, the term "start date" has always been quite confusing for me, since it refers to the start point of the algorithm's lookup, but also to the end of the time period covered by the range of edits being searched...

FlominatorTM commented 9 years ago

For linear search that is already available, see radio button "oldest first " at "Order".

For binary search I implemented some version as well after this bug report: http://sourceforge.net/p/wikiblame/bug-reports/1/

Try checkbox "Look for removal of text (binary only) " in that case.

Does that work for you? Which article are you looking at?

Update: https://sourceforge.net/p/wikiblame/bug-reports/57/ went into the same direction

waldyrious commented 9 years ago

For linear search that is already available, see radio button "oldest first " at "Order".

That actually parses the same set of pages, just in reverse order. I.e., it in both cases the tool gets the X revisions previous to the "start date", and goes (start date - X) --> start date (forward in time) instead of the default start date --> (start date - X) (backwards in time). What I need is start date --> (start date + X).

In fact, I'd suggest two nomenclature changes to make this clearer: first, change "order", "latest first" and "oldest first" to "time direction", "backwards" and "forward". Second, if you maintain the functionality as-is, I'd suggest changing "Start date" to "End date" (since it's the end, chronologically speaking, of the period that will be searched), or "latest revision to check", to make it more explicit; otherwise, if you add the option that I suggest above, then the date would be more accurately described as the "anchor date" (from it to the past, or from it to the future). (Second request moved to #2)

Does this make sense? I can clarify further if it's unclear.

FlominatorTM commented 9 years ago
  1. Search from X to now: I think I got it. Can you maybe describe on a concrete example what exactly you want to accomplish?
  2. order => time direction: Interesting approach, I think I will change that
  3. Start date/End date: Please create a separate issue for that.

Thanks for your contribution.

waldyrious commented 9 years ago
  1. I often come back to an article after having worked on a while ago, and want to search when a specific passage was inserted or removed. In that case, I know the oldest date of the period I want to search, not the newest.
  2. Cool :)
  3. Sure.
FlominatorTM commented 9 years ago
  1. Did you every try using binary search for that?
  2. Didn't do it yet :)
  3. Thanks
waldyrious commented 9 years ago

Sure, I use binary search all the time, it's just that having a "X to now" search matches conceptually what I want to accomplish, so it's more intuitive to me to set up the tool that way, rather than attempt to engineer its parameters to approximate what I want. Besides, the search isn't instantaneous, so narrowing down the search space with the information I do have would make it more efficient both for me (faster) and for the tool (fewer requests).

Basically, it's not that it's impossible to find what I want without this feature, but it certainly is a more complex process than it'd be if this feature were available.

FlominatorTM commented 9 years ago
  1. Renaming "order" => "time direction" is still open
  2. Did some thinking about your request. Am I right, that technically this would only be a kind of alternative way to enter the number of "Versions to check"? I'm talking about something like "I want to search the 231 versions until January, 3rd" and I want that with "time direction" option "oldest first".
  3. I think this would also fix https://sourceforge.net/p/wikiblame/bug-reports/56/
waldyrious commented 9 years ago

If I'm reading you correctly, you're talking about what already exists. Let me try again, with some diagrams:

Is this clearer than what I said before? Or am I misinterpreting what you're saying?

FlominatorTM commented 9 years ago

Nice approach, messed up my head like crazy, but will lead to more understanding anyway ;)

What I was asking: Is your version "search X revisions starting from start date Y, forward in time (not possible at the moment)" equal to "search X revisions until "start" date Y, forward in time (currently possible by picking order=oldest first)" if we set

Y = today Z = date to enter, earlier in time than Y X = count(revisions[Y-Z])

waldyrious commented 9 years ago

Intriguing. So basically you're saying the user would have the possibility to specify either an anchor date plus a number of revisions (X, Y), or a start and end date (Y, Z), right? I think the latter could indeed be more intuitive than the former.

In fact, it would work better even for the use cases currently possible in the tool: after all, it's quite unlikely that a user will know exactly how many revisions he needs to search. I, for one, always use either 50 or 500 precisely because I never know how many revisions I have to search.

So I suppose it could make sense to make X always be calculated from Y and Z. That way you don't even make the interface more complicated, since you add one control (Z) but remove another (X).

FlominatorTM commented 6 years ago

The branch https://github.com/FlominatorTM/wikiblame/tree/ui_with_more_radio is my first shot to a more intuitive UI which also contains your feature.

Feel free to play with it at http://wikipedia.ramselehof.de/wikiblame.exp.php

waldyrious commented 6 years ago

Interesting. It seems a bit complex at first, but perhaps with good UI messages and layout it can be clear. For example, the text "was not created before [date]" would be clearer as "was created after [date]", and vice versa.

Also, I seem to have found a strange behavior. Using the current settings:

I get the error message: "Wrong settings: If the first 50 versions are skipped, then none of the 50 versions to be searched will be processed."

And if I swap to the binary mode, there's no error, but the limit is not respected: It says "543 versions found" (the article is "Metal detector" on enwiki).