Explanations of buttons in "Place filter"

[tutebatti]

Again, I'm having issues with some sentences in the explanations to the Place filter in the Location list:

The revert button will revert the changes to the place set; that is, the place set will match the current filters. Because of the functionalities detailed below, the place set will not update from the database when other filters change, only with the initial load and visualization state loads. Instead, resetting is left to the user, which allows to build up a place set incrementally.

[mfranke93]

Okay. This might be another case where I am mixing up stuff that is relevant to casual users with stuff for more advanced users. Keep in mind that I wrote these texts for you (DhiMu) originally, and you have some more knowledge about the inner workings.

Break-down to sentences

The revert button will revert the changes to the place set; that is, the place set will match the current filters.

Clicking the revert button will reset the checkboxes of the place filter to that which is part of the currently active filters. So either "no filter", or the place filter that was set the last time you pressed the Apply button in the place filter.

Because of the functionalities detailed below, the place set will not update from the database when other filters change, only with the initial load and visualization state loads.

With all other filters, the apply button behaves a bit differently: If I have un-applied changes in a view, and the view receives new data from the visualization backend, the un-applied changes are gone. For example:

1. I have modified the confidence filter (all boxes checked) and the source filter (only OCN and DHGE), but not applied either one of them:
2. I now click "Apply" in the confidence view. And the un-applied changes to the sources view are gone as well (after some time):

What happens: All data filtering and calculation operations are processed in separate WebWorker processes to keep the UI snappy. When a filter is applied (or any other UI operations that handle data; brushing and linking uses this as well) the view sends the appropriate data to the worker process. That process applies all filters to the data, the new data for each view are calculated, and then sent back to all views. So in this case, the source view also gets data sent back, and the modifications we did to it before are overwritten.

Now, that were all the other views. The place filter works differently, and there are design decisions (166@TIK) behind that as well. Mainly this one, which we discussed in a meeting (referenced here): To create a place set, it would be nice to be able to take the currently shown cities from the location list, and to add them to the set. The functionality now also allows to remove them, or to do a set intersection. But to do that, we need to be able to apply filters in other views without applying the place set itself (because the place set will then affect its own creation). And that is why applying other views does not affect it (i.e., does not push down the state from the worker, like with other views).

Instead, resetting is left to the user,

This concludes what is described above: Because changing filters from other views does not reset the place set (as happens with all other views, such as with the source filter in my example), it is up to the user to explicitly reset when they want to do that.

which allows to build up a place set incrementally.

I hope this is clear. If not, there is an extensive example for that at the end of the info text.

[tutebatti]

Thank you. I believe it is clear now, although I read the example mainly to understand the other quite complex set buttons.

To sum up, there are two important things (correct me, if necessary):

1) The place set does not react to other filters; this is a general thing and true regardless of the revert button.

2) The revert button will not revert to the last last filters applied generally but only to the last filter applied using the place filter.

[mfranke93]

1. The place set does not react to other filters; this is a general thing and true regardless of the revert button.

Yes.

2. The revert button will not revert to the last last filters applied generally but only to the last filter applied using the place filter.

Yeeeees (kind of). Yes in the sense that: will revert to the place filter that is used in the visualization everywhere. Which could be the last filter applied using the place filter. Or something that was applied by opening a specific visualization state. No in the sense that the revert button here works exactly the same way as it does in any other view.

[tutebatti]

Now I'm confused again. :smile: Maybe you could provide another example (no screenshots needed) where not the Apply buttons but the Revert buttons are involved to show the difference. I think "ich stehe auf dem Schlauch".

[mfranke93]

Sorry! :sweat_smile:

Regarding other apply buttons not affecting the place set, I think the example / use case at the end of the info text should make that clear.

Regarding other revert buttons (the one on the confidence does something different, requested by @rpbarczok: #27): Only the religion view and the tags view have one as well. Remember here how I explained that, when we apply a filter, that gets sent to a different process, where the data handling is done? The revert button works only in the front end. To use an analogy from a word processor etc.: The revert button removes the unsaved changes, so that after clicking it, the document is in the same state as on the filesystem (the filters shown are the same as are applied to the data). Clicking on the revert button does not re-trigger any filtering or redrawing, because nothing changes data-wise: the data and filters shown are still the same.

An example with the place set revert button:

1. In the place filter, deselect all places, then only add 3: Abtu, Abu Asir, Abu Tij. Now click apply.
2. The location list (we are in only active mode) now only shows these three places, and all other views (map, ...) shown only data from these places.
3. Click the plus (+) button next to Adana in the place filter.
4. The apply button is now enabled (clickable). The visualization does not change in any other way.
   1. Variant 1: Click apply again. The views get new data (some delays and loading occur). The views now show data from all 4 places.
   2. Variant 2: Click revert. Adana is again deselected (the plus button is enabled (clickable), the minus button is disabled (not clickable), the apply button is disabled (because the currently shown place set matches the applied place filter). The green check mark left to Adana disappears. The only changes happening when clicking revert happen in the place filter. The rest of the visualization stays as it is.

[tutebatti]

Tried to rephrase based on the original text without much substantial changes; @mfranke93, please check:

https://github.com/UniStuttgart-VISUS/damast/commit/cded575960e2efb4f2cae7fd49a1bb81e7195669

If this is ok, I would leave it at that and close this issue.

[mfranke93]

Looks good to me, I supplemented an actual link to the referenced settings text in bab5af2 . I would close this now.

Side note: I also replaced a "what is more" in that commit. I feel like you are overusing that phrase a bit. It is also usually used when what is following is more important than what is before it (see here for an example), which in these info texts often is not the case. Here (in bab5af2), the loading into the visualization is the important feature, and the sharing and recreating of reports is an addendum that is interesting as well, but not more so.