[RFC ]Dive site tags: my try

[Dirk Hohndel]

Davide,

thank you so much for all the effort you are putting into this.

While you were working on this, Tomaz and I were in a video call with a
Luisa, a designer in Brazil who has helped us in the past and who wants to
contribute more as well.

It is very exciting to me to be going from "no one with any decent design
sense" to having "a diver with design ideas" plus "a designer who can help
turn this into beautiful software"...

I believe Tomaz was planning to walk Luisa through some of your ideas
today and tomorrow.

On Wed, Feb 18, 2015 at 01:14:20AM +0100, Davide DB wrote:
> This is my try to define a workflow for this new amazing feature.
> Bear with me!
> 
> I'll try to follow some use case and some excerpt from previous discussion.
> 
> Precondition
> * V3 xml format removes location, latitude and longitude from the
> struct dive and replaces them with a dive_site_uuid.
> - V3 xml format uses the struct dive_site to hold that information .
> * V3 xml format is not compatible with previous version hence users
> have to migrate to V3 format to use Subsurface.
> * Once migrated you are not forced to explicitly use location structure.

Yes.

> Use cases
> 
> MIGRATION PROCESS
> ------------------------------------
> Existing users must migrate to the new V2 xml format.
> 
> "Data migration" and "new dive creation" behaviors are controlled via
> a "Dive site management" user preferences panel. Let's see how the
> migration process could be:
> 
> Migration is triggered:
> 
> - Opening a V2 logbook via File > Open.
> - Importing a V2 logbook via Import > Import log file.

So basically the feature that I thought most people use (you have a
default file that automatically opens when you start Subsurface) is
something that you didn't consider?

Or is it that if your default file is a V2 file it ISN'T just opened but
instead the user gets presented with a dialog that asks them how they want
to migrate their data?

> WELCOME
> ----------------
> A welcome dialog informs the user of what will going on in a minute
> (doomsday device).
> All instruction are given:
> 
> http://i.imgur.com/sQ6NMdP.png

I don't like the "will delete your logbook" language. It should say "will
save a backup of your unmodified logbook in _this_location_ and then
migrate your data in place" (or something along those lines).

And you should get this dialog whenever a V2 file is opened. So open,
import, and default file.

> CONFIGURATION
> ----------------------------
> Next step give the user the choice to configure the process:
> 
> http://i.imgur.com/2myW9jj.png
> 
> Here I imagined two options: dives with GPS data and dives without GPS
> data. User must opt-in both.
> 
> User enable the reverse geocoding option for all the dives with GPS data.
> 
> Once enabled he can choose which attributes (we could call them
> geo-tags) fit for him.
> For the UI I copied the nice idea from Miika for CSV file import but
> simpler approach could be used.
> Basically he can choose up to three geo-tags dragging them on the
> three boxes/area.
> The geo-tag list is what we can get from the reverse geocoding service
> we will use (I do not know if there is a standard)

I like this.

> If user used some sort of structure in his dive locations he could
> eventually choose to parse dives without GPS data too. He could
> indicate which kind of structure he used. More or less as above (we
> should choose its separator).

Yes, separators would have to be a user option. This might work for the
"very consistent" crowd :-)

> I know, it's not perfect. In the above description dive location names
> with gps data are not touched so some redundancy could easily happen.
> We could use a mix of the two procedure described above.
> 
> PREVIEW
> --------------------
> 
> Next step is the import/migration process by itself.
> We need a progress bar nad we need a preview of what we are going to
> save (and eventually accept, reject, edit)
> 
> http://i.imgur.com/2eJXqgo.png
> 
> The procedure will show a table for "GPS dives" and "manual dives"
> showing names before/after.
> We could accept all with a global check-box or one by one and
> eventually edit the new name before saving.
> I did not show file open/save dialogs.

I understand what "accept" means. But what happens if a user doesn't
accept a dive? Is there a manual process to set geo tags? Or is just the
site name used with no geo tags?

> In my opinion once we use the reverse geocoding service we should
> graba nd save into the xml ALL the attributes/geo-tags regardless of
> user choice. In other words: the user choose only what he will display
> later.
> This could be useful later for maximum compatibility when
> interfacing/exporting to other logbooks.

Why would we? If we can get those data once, we can get them again... I
see no reason to fill up the XML files with all that information if the
user doesn't care about it...

> USER PREFERENCES
> -----------------------------------
> 
> User could decide to change dive site structure later.
> Configuration is made via a new option in the user preference dialog.
> In my wireframe I slightly rearranged the current dialog (more idea to
> come...).
> 
> http://i.imgur.com/RS5fjKJ.png
> 
> Basically here there are more or less same options of the migration process.
> Dive site structure format for dives without gps data should be of
> help while creating a new dive manually or without companion app. [I'm
> not fully convinced here].

I'm not sure I understand what you are saying here.

> When you add GPS data to an existing dive, reverse geocoding format
> would take precedence over previous data (aka overwrite).

Really? Shouldn't there be a "do you want to replace "THIS" with "THAT"
dialog?

> NOTES TAB
> --------------------------------------
> 
> IMHO the new Location field into the Notes panel should be just a NOT
> editable texbox.

That makes things easier. But if there is no site name, yet, that is a bit
awkward. Unless you turn that field itself into the button and then if
there is no site dat you turn the text into "click here to add a dive
site".

> Eventually near dive site name you have the geo-tags chosen (via
> reverse geocoding or manually added). In my wireframe I imagined a
> group box with geo-tags. In a hurry I did not draw all Notes controls.
> 
> http://i.imgur.com/OphJsjy.png

OK - that takes a lot of space - but we just dropped the coordinates.

> There's no "manage button" but there is a new tab named "Dive site"
> that is an extended view on the dive location.

I want fewer tabs, not more :-/

> Dirk wrote about a dedicated view to manage all dive sites...
> I avoided it in my wireframes. It would be nice we could avoid another view.

I'll push back on that. The current dive site view sucks. But imagine one
where instead of the profile you have a "site photo" plus all photos
associated with dives at this site? And instead of a dive list below you
have a list of dive sites that you can manage? I think that adds
substantial value.

> A prerequisite would be that a "dive site" does not exist by itself
> inside a logbook.
> You cannot create a new dive site. You simply create a new dive as
> usual and eventually a new dive site for it.

That was my vision as well. In my scenario that's just a convention - in
yours that =;s a requirement.

> In this way (I hope) everything it's simpler and we could have a
> design like mine.
> 
> DIVE SITE TAB
> ------------------------
> 
> http://i.imgur.com/rxqX8Hv.png
> 
> This is more or less the same as in the experimental build.
> There is a new group-box with the current geo-tags chosen (again: via
> reverse geocoding or manually added). In my wireframe they came from
> reverse geocoding because there are GPS data.
> There is an Update button near geo-tags: it queries again the reverse
> geocoding service.
> Geo-tags can be deleted with the X icon.
> Maybe when I tried to use the service it was not available (network..)
> so I could imagine to have a special icon indicating that this dive
> site has not been correctly updated...

OK

> Any operation on this panel will trigger an edit!

Yes.

> DIVE SITE EDIT
> -------------------------
> 
> One weak side of this design is that the dive site tab could refer to
> many dives (I've just deleted the stat tab for this :) ) but I think
> we can live with it. Dive site is strictly related to the current dive
> so the info is not misleading.
> Of course, when we edit it we must alert user that we are going to
> affet one or several dives:
> 
> http://i.imgur.com/RD7FdQs.png

I disagree with the text. The user is not "editing 49 dives". The user is
"editing a dive site used in 49 dives". Very different.

> I'm sure that I forgot a lot of things and that there are a lot of
> flaws in my workflow or maybe it's too complicated or completely
> different from what expected. I myself have some doubt :)
> 
> Henrik, Dirk and me exposed a lot of different ideas. I hope this is
> at least an helper to define the correct workflow.
> 
> Good night (1:11 am here in Italy)

Again, thanks for the amazing effory. This is really appreciated.
I think you bring a lot of relevant and good ideas... let's see what
others think

/D