[RFC ]Dive site tags: my try

[Dirk Hohndel]

On Thu, Jun 11, 2015 at 10:51:47AM +0200, Davide DB wrote:
> After an endless debate on taxonomy between Dirk, me and Henrik. In
> the end we badgered Dirk to implement something :)

Yes. That's how it's supposed to work. :-)
Except that of course it is Tomaz that implemented most of this. I'm just
the one who messed everything up with my work on the changes to core...

> The whole process was sketched four months ago when nothing was
> developed and discussed in detail so it's normal that not everything
> will apply now.

Yes.

> >> >> 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?
> >>
> >> I don't know exactly :)
> >> There will be no geo-tags.
> >> See my comment on the dive site tab:
> >
> > This is an interesting / challenging dialog; definitely not easy to
> > implement and get right - I need to spend more time understanding how much
> > of this is reasonable to do and how much is overkill.
> 
> I agree, we can skip entirely this.
> The important thing is that a welcome dialog explain everything
> clearly and that V2 xm user file is saved/backup in some way.

The nice thing about the configuration / preview is that the user sees
what will happen. But my concern is that this is a lot of UI work for
something that most users will use exactly once :-(

> > Yes, we definitely need an option on a dive site to look up data. This way
> > after I download a dive from my dive computer and get the GPS coordinates
> > I can simply fill in the taxonomy data via geo lookup
> 
> If we skip entirely the above import dialog, geo lookup and reverse
> geocoding could be performed later in the dive sites management view.
> individually or the entire database.
> Hence the user who migrate his beloved dives can checks that
> everything was ok and eventually doing geo lookups when he is
> comfortable that everything works as expected.
> Basically we avoid to have two processes at the same time during import.

Funnily enough I thought about this last night as well. We do the
{name,GPS} --> dive_site conversion on import, but we don't do any reverse
geo coding / taxonomy lookup at all.

Instead we have a dive site management system that allows us to run
reverse geo lookup on the current dive or on all selected dives.

That would simplify things, I believe.

> >> >> 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.
> >>
> >> Me too. (I'm joking)
> >> Regarding dives without gps data: while in the migration process you
> >> choose which field will be assigned during location parsing, here you
> >> decide how your new dive names will be formatted. Actually the same
> >> thing.
> >> It's the manual procedure who scares me a bit. There will be a lot of
> >> user errors, duplicates, nonsense...
> >
> > Yes, this part still worries me.
> 
> But  this is really the core of the reason we badgered you :)
> I mean that reverse geocoding would be applied only for dives with GPS data.
> I agree that trying to format dives without gps data is sci-fi and dangerous.

So let's try and describe this process again to make sure we are talking
about the same thing.

We take {name,GPS} and turn this into dive sites with name,
coordinates,... (and try to be somewhat smart about avoiding obvious
duplicates).

Now the user is in dive site management mode and wants to use the
taxonomy.

a) if there is a GPS fix, we offer to call the reverse geocoding API and
fill the taxonomy for the user (and they can edit that if they want to)

b) there is no GPS fix, we do... what?

We can do nothing. Easy to implement, works for me (as I don't care about
the taxonomy), but I thought the discussion had been that you and Henrik
wanted "something" there. For example if you were super consistent and
ALWAYS labeled all your dives as Site / Location / Country (or if it's
important from other software that has a taxonomy and where we combined
the taxonomy data into location strings like this), then it would be
reasonably easy to parse this back out.

The question is (once again), as the user does this most likely exactly
once, how much effort do we want to spend on this?

> >> >> 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".
> >
> > Funny, so that's the same argument we had a few hours ago. At least we
> > both stayed consistent :-)
> 
> Really funny indeed. I agree on you solution on the other thread.

 \O/  \o_  _O/  \O/

 (ok, not a good visualization of my happy dance...)

> >> >> 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.
> >>
> >> Our current tag labels are smaller than those I found in this library.
> >
> > I don't like this. I don't want these taxonomy tags in the dive notes.
> 
> Why? They are very nice to see and add value to the Location name.
> If you decided to not use geocoding or even dive site you will not see
> anything there.

It's about screen real estate. I'm willing to play with this but my
initial response is not positive. Hmm. Maybe we can add the "tags" as tag
bubbles after the location name? That might be visually confusing, though.

> > OK, this brings us back up to speed on the earlier proposal. I think a lot
> > of what you have here is really good. Implementing all this means
> > Subsurfae 4.5 will be released around Christmas, though...
> 
> Really?

OK - that may be an exaggeration. We might get this done by early December
:-)

> The welcome/ guide screen for the import is a must for laymen. The
> background import process is already there and needs to be tweaked
> according to the last decision.

I think we are dropping the automatic / background reverse geo coding
which will make all this simpler.

> The dive site edit/add for the single dive is nearly there. We need to
> add tags and a button to load them from a remote service and a
> preference panel for them.

Yes, that's quite a bit of work. I want to make sure we get this right so
we don't mess with people's data files, don't lose data, make this
reasonably intuitive to use.

> The dive sites database management view is nearly there :)

Umm, not quite :-/

I think we are getting closer to understanding what we really want which
is the first requirement.

/D