Cgeo: Distinction between "store" and "manage" buttons

[mirabilos]

Detailed steps causing the problem:

• save a cache to a list
• try to save another cache

Actual behavior after performing these steps:

• the checkbox in which the previously saved cache was stored is ticked

Expected behavior after performing these steps:

• in the dialogue, none of the checkboxen is ticked
  (unless the cache was already in any lists, in which case those should be ticked)

Version of c:geo used:

nightly build 2016-12-12

note it didn't occur in some previous (november?) nightly build

Is the problem reproducible for you?

Yes

System information:

Android 4.4 Liquidsmooth; I could give the full info if necessary, but this is a UI issue, and therefore unlikely to be needed.

Other comments and remarks:

[pstorch]

That was actually a feature request #5975
Currently being changed to only remember last list selection for 10 minutes.

[mirabilos]

Then, can you please add a setting to disable this……… “feature”………… totally?

It goes against the flow of using a normal application (principle of least surprise). I do recognise the value for some, but I’m quicker in explicitly checking what I want, also it collides with caches that are already stored (chance of data loss “oh it’s already stored so cancel that”).

[alan666notb]

Yes, It's misleading.
I've failed to store a cache because I thought this dialogue indicated that it was already stored.
I got out in the field with no mobile signal and found I didn't have the details I needed.

[SammysHP]

This is a confusion between two different actions: saving a cache and managing its lists.

[mirabilos]

But in the UI introduced when caches could be in multiple lists, that’s the same action.

[SammysHP]

1. Open popup of a not stored cache. There is refresh and a store button.
2. Press store, select lists and ok.
3. Open a popup of a stored cache. There is a refresh, a edit and a delete button.
4. Press edit, the menu will show the actual list and not the remembered list.

So far this looks absolutely fine.

[mirabilos]

Not the popup… in the cache itself. I rarely do anything but go to the details from the popup, but in this case, I was searching (via the hardware looking glass button) for the GC code, then (once I had the listing) download it.

Anyway, while it may look fine to some part of the userbase, it impedes other parts of the userbase, and as such, I request to consider this a UI bug and make it configurable via a setting.

Thanks in advance!

[mirabilos]

(besides, those buttons have changed to not-so-much-saying icons recently, which lets the user… well, guess, the meaning)

[alan666notb]

This is what goes wrong ...
-- load details of a new cache
-- Press 'store' button and store it in a list.
-- load details of another new cache
-- Press 'store' button - dialogue shows a 'tick' in the previous list you used
-- Think 'Oh, must have already stored that one before', press cancel.
-- You just screwed up, it wasn't stored and you didn't store it.

[mirabilos]

This also happens if you import two subsequent “New cache published” notifications (click in K9 Mail on the link, which opens in an embedded c:geo, then save them), just as @alan666notb said.

[SammysHP]

The detail page has exactly the same behavior as the popup: it has a store and a manage button. So I think it's just the distinction between these two buttons is not clear enough.

[mirabilos]

I would still like to request a configuration setting to make the “store” dialogue behave as before, as that’s the more consistent (in my, and others’, eyes) one.

[pstorch]

Hmm,

It goes against the flow of using a normal application (principle of least surprise)

This is a really good argument against this feature I must say. Even with the timeout we would have some surprises.

[mirabilos]

The timeout is likely to surprise even more users, in my opinion, but, as I said, as long as it’s got an option to disable, I’d just use that instead.

[SammysHP]

We should find a solution that does not require another option but retains the possibility to keep the list selection for further storing operations.

[SammysHP]

Idea:

Short press on store button → show dialog with no list selected
Long press on store button → store immediately with lists selected in last store operation

[pstorch]

@SammysHP: like the long press on "Manage Lists" button, which moves the cache?
Maybe this can be a solution. Then the obvious way (one click) is the normal behavior without preselection and the long press is the special behavior with preselection.

Other ideas / opinions?

[mirabilos]

I could live with that… though that sounds less user-friendly to me than a setting (less obvious, especially in this age where user documentation is hard to come by).

[okainov]

As for me, it's super useful feature to remember the lists to save, please dont remove it

[pstorch]

OK, do we want to go for the long press option?

[SammysHP]

If we implement the long press, the timeout should be raised a little bit, maybe half an hour at least.

[pstorch]

Or remove the timeout?

[SammysHP]

That would also be an option, yes.

[pstorch]

Ok, let's replace the "remember with timeout" with the "remember when long pressed" option. I'm on it.

[Lineflyer]

@pstorch
I am sorry that I missed the discussion here.

Can you describe again the present mode and the future mode (after your change)?
I tend to avoid having feature hidden behind long press (even more if the new function (remember list selection) is already out to the users. Or do I misunderstand it.

[pstorch]

@Lineflyer yes, the "remember list selection" is already released. Currently with a timeout, but causing confusion. That's why we have this issue here.
The solution discussed here is to don't do a preselection in the "standard" case (single click) but on purpose if done a long press on the store buttons (floppy disk icon).

[Lineflyer]

That brings us two downsides:

• Users might have already used (and liked) the current remembering
• Users will not intuitively find out about the long press.
• It is only a solution at a single usage flow (the manage button in cache details) the others will fall back to the old approach but no longer have the timeout solution

That makes me undecided.
Any opinions from the team, depsite @SammysHP and @pstorch regarding the "long press" or any other proposal.

[mirabilos]

The timeframe the remembering was in was a few weeks, I think less than a month even. The previous behaviour was in for much longer and is used by a lot more people.

If c:geo acts quickly, we can have @pstorch ’s suggestion shipped, which restores the previous (known by the biggest share of users) behaviour for short click and moves the remembering behaviour to long click. Mention this in the changelog (which is shown on every nightly build update anyway (without indicating what changed since the last nightly build…)) and we’re all good.

[SammysHP]

We still need a solution for the menus.

[mirabilos]

inhowfar?

[SammysHP]

Because the long press works only for buttons.

[Lineflyer]

Back to my previous posts:
If it is the case that long press immediately saves to the previously used lists I am fine with that. At first I thought it would only open the same selection dialog with just other preselections.

Regarding menus we can decide then in a next step.

[mirabilos]

I don’t think the long press was meant to store immediately, but that’s a splendid idea!

In this case, the menu would just have the Store entry.

[pstorch]

With my change a long press would open the selection dialog with a preselection. But storing immediately would also be a nice option.
BTW long press on menu items is possible. I just doubted that it is useful. But if there is a consensus about it, it can be implemented.

[SammysHP]

IMHO we should keep the dialog. Using it with menu items sounds unusual, but would be an improvement.

[pstorch]

I played around a bit. Here is a screenshot of another possible solution: a third button on the list selection dialog to preselect the lists:

A user would have to click on Last Selection to have the lists selected as on the last time he used this dialog. But it would only do the selection not confirming the dialog. A press on ok afterwards would still be necessary. It would make the "Use the last remembered list selection" explicit and visible.

What do you think?

[SammysHP]

That is a feature we can merge for sure! But I still prefer an additional fast-store method (that might be hidden in a long press action) that directly stores the cache in the last selection. (Btw: what happens if one of the lists does not exist anymore?)

[pstorch]

@SammysHP if one of the previous lists doesn't exisit anymore it won't be selected. The question is if no previous list is left or if there was no previous remembered list selection. What should the fast-store feature do? Store on default Stored list?

I think we are coming closer:

• have the long press on buttons and menu items for fast-store: use previous selection without showing any dialog
• have the third button Last Selection on the list selection dialog for all other users who don't know about the long press fast-store method
• remove the timeout

[pstorch]

Instead of using the default Stored list in case there is no preselection on fast-store available we could also fallback to show the dialog.

[pstorch]

Maybe I was wrong with long press on menu items. There are only hacky solutions, the long press is reserved for a help toast.

But the longer I play and test around with the proposed fast-store function the more I like it :wink:

Can we live without a fast-store option for the menu items?

[SammysHP]

we could also fallback to show the dialog

👍

Can we live without a fast-store option for the menu items?

If it is too difficult, sure.