New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: reverse direction #1

Open
waldyrious opened this Issue Jun 6, 2015 · 12 comments

Comments

Projects
None yet
2 participants
@waldyrious
Contributor

waldyrious commented Jun 6, 2015

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

This comment has been minimized.

Owner

FlominatorTM commented Jun 6, 2015

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

This comment has been minimized.

Contributor

waldyrious commented Jun 6, 2015

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

This comment has been minimized.

Owner

FlominatorTM commented Jun 8, 2015

  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

This comment has been minimized.

Contributor

waldyrious commented Jun 8, 2015

  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

This comment has been minimized.

Owner

FlominatorTM commented Jun 8, 2015

  1. Did you every try using binary search for that?
  2. Didn't do it yet :)
  3. Thanks
@waldyrious

This comment has been minimized.

Contributor

waldyrious commented Jun 8, 2015

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

This comment has been minimized.

Owner

FlominatorTM commented Jun 15, 2015

  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

This comment has been minimized.

Contributor

waldyrious commented Jun 19, 2015

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

  • search X revisions until "start" date Y, backward in time (currently possible, default behavior):

    [Y-X] <------(X revisions)------ [Y]

  • search X revisions until "start" date Y, forward in time (currently possible by picking order=oldest first):

    [Y-X] ------(X revisions)------> [Y]

  • search X revisions starting from start date Y, forward in time (not possible at the moment):

    [Y] ------(X revisions)------> [Y+X]

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

@FlominatorTM

This comment has been minimized.

Owner

FlominatorTM commented Jun 19, 2015

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

This comment has been minimized.

Contributor

waldyrious commented Jun 19, 2015

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

This comment has been minimized.

Owner

FlominatorTM commented Nov 5, 2017

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

This comment has been minimized.

Contributor

waldyrious commented Nov 16, 2017

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:

  • Latest version: is [50] revisions older than the current one
  • Oldest version: was not created before [date]
  • Search method: linear

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment