[android] Add possibility to select bookmark category after long click on Save button

[krozhdestvenski]

Added features
After long click on Save bookmark button we can edit bookmark before if will be added.

By default, a new bookmark is initiated with parameters (name, icon, etc.) as for quick creation in current logic.

Issues
#1060 (comment)
#6234
#5512

[biodranik]

The UX and the code do not look right...

Would it be better and easier to immediately show an existing "Edit bookmark" dialog when a bookmark was added using a long tap?

[krozhdestvenski]

The UX and the code do not look right...

Would it be better and easier to immediately show an existing "Edit bookmark" dialog when a bookmark was added using a long tap?

I think it will be a little less convenient. User will go through several screens to complete the target action.
But your solution is probably better. I'll implement it)

[krozhdestvenski]

Would it be better and easier to immediately show an existing "Edit bookmark" dialog when a bookmark was added using a long tap?

Did as you said)
One question/proposal: mabe we must cahnge page titel from "Edit Bookmark" to "Create Bookmark" in this case? I didn’t do this right, now because I don’t want to put too many translations into current PR.

[pastk]

Would it be better and easier to immediately show an existing "Edit bookmark" dialog when a bookmark was added using a long tap?

Its an improvement over the current UX indeed.
I.e. to change new bookmark's list now one has to tap 6 times (and it'll leave the place page expanded which might need another tap to collapse or close).
With that change it'll be 1 long tap + 3 taps.
But a long tap is ehh... long indeed :) its like ~2 short taps, so actually it saves ~1 tap out of 6.

However the solution described in #1060 (comment) brings it down to just 1 long tap + 1 tap. Much better!
And there is an important improvement that the map continues to stay on the screen, so a user doesn't loose focus/track of their work with the map (e.g. I find it quite disruptive for the flow when to do a minor/quick thing I have to switch to a different full-screen page).
There is a disadvantage that this solution is useful to select a list only (and perhaps a color if we implement #1805). So if a user also wants to edit name or description then there will be little or no advantage.

There are other ideas how to edit name / description quickly:

• Quick bookmarks naming / editing #1636

[krozhdestvenski]

biodranik

I have already implemented the solution that @biodranik suggested.
And it realy looks better. Here are the benefits:

1. We have full functionality on bookmark creation (we can set color, desctiption etc.).
2. Interfaces of creation and edition of a bookmark are simular (No UX complication).
3. If in future we will add some new bookmark attribute, it automatically will be added for each action(edition, creation)

[biodranik]

Did anyone else test it? @Jean-BaptisteC WDYT?

[Jean-BaptisteC]

It's better to add also listener when poi is already in bookmarks. To move poi in another bookmark list without need to open place page.

[krozhdestvenski]

It's better to add also listener when poi is already in bookmarks. To move poi in another bookmark list without need to open place page.

Sorry, can you explain in more detail, what do you mean? Perfectly - step-by-step)

[Jean-BaptisteC]

I can't doing a long press when poi is already in bookmark list.

[krozhdestvenski]

I can't doing a long press when poi is already in bookmark list.

@Jean-BaptisteC, I did it on purpose, and I think it's the correct behavior. Long-pressing initiates the bookmark creation process. When POI is already in the bookmark list, the button behavior changes to 'remove,' and we don't need to show the 'create' window.

[biodranik]

The main UX question is: should long-tap behavior be consistent and always show the create/edit bookmark dialog, or should it behave differently if a place is bookmarked or not bookmarked? In the former case, it duplicates the "Edit Bookmark" button functionality but is more consistent and easier to use. In the latter case, it may be an unexpected behavior and lead to bookmark deletion.

[krozhdestvenski]

The main UX question is: should long-tap behavior be consistent and always show the create/edit bookmark dialog, or should it behave differently if a place is bookmarked or not bookmarked? In the former case, it duplicates the "Edit Bookmark" button functionality but is more consistent and easier to use. In the latter case, it may be an unexpected behavior and lead to bookmark deletion.

The first solution seems more logical to me. We click on the “Create” button, the bookmark creation dialog is called up and the bookmark is created.
In the second case, the logic is not obvious and duality: the button is called “Delete”, and after long press the Editing dialog box opens.

In any case, if will be feedback that the behavior is not obvious (when implementing the first solution), the behavior can be modified with one line of code)

[pastk]

IMO long tapping on a delete button resulting in the edit dialog is unexpected, inconsistent and confusing. Though otherwise its safe and users who get accustomed to this strange behaviour may use it for their advantage..

Still it feels weird and I'd rather avoid such controversial UX patterns (i.e. leave the long tap on delete button do nothing).

[krozhdestvenski]

IMO long tapping on a delete button resulting in the edit dialog is unexpected, inconsistent and confusing. Though otherwise its safe and users who get accustomed to this strange behaviour may use it for their advantage..

Still it feels weird and I'd rather avoid such controversial UX patterns (i.e. leave the long tap on delete button do nothing).

In addition, I think that most users (not developers) may well perceive this button as 2 different buttons (because they have different names). And don't expect the same behavior from them.