[RFC ]Dive site tags: my try

[Dirk Hohndel]

On Thu, Jun 11, 2015 at 06:15:13PM +0200, Davide DB wrote:
> On Thu, Jun 11, 2015 at 4:45 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> > On Thu, Jun 11, 2015 at 10:51:47AM +0200, Davide DB wrote:
> >>
> >> 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 :-(
> 
> Ok
> Resuming this step:
> Once a V2 xml file is opened, a welcome dialog informs the user with
> great care of what will going on in a minute (doomsday device) once he
> press START.
> Then an import process will start and the user will see just a spinner
> or something like that.

Yep - and this is now basically as fast as a normal file open, so it
doesn't even need more of a spinner. I think we talked about a progress
bar for this at some point in the past...

> >> 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.
> 
> Ok
> Resuming: the import process will only convert everything from V2
> format and V3 format. Basically creating dive sites where it can.
> No other action are taken on xml file.
> Geocoding mojo will *eventually* be performed later.

Yes.

> >> >> >> 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
> >> >> >>
> >> 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?
> 
> Ok I will try.
> First of all I will start playing ONLY with dives with GPS fix.
> It's easier because we should not rely on some obscure user structure naming.
> 
> Let's start from user preference dialog:
> 
> http://i.imgur.com/RS5fjKJ.png
> 
> Just keep in account the upper part
> 
> - "enable reverse geocoding...."
> 
> User enable the reverse geocoding option for all the dives with GPS data.

For all dives?

I thought we talked about having this as a setting and then the user can
trigger this for "current dive site" or "all selected dive sites".

> 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 complete 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 think there is an it's insanely elaborate. But we can pick a few items.
Sadly the quality of data for reverse lookup is rather inconsistent.
But at least the country is usually available :->

> > 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.
> 
> Yes but:
> I'm trying to reduce code to implement and keeping things simpler as
> possible for the first implementation.
> Moreover a gps fix it's something you can rely on but a structured
> name could be very difficult.
> We can try to see in a different discussion what kind of location
> names could be easily parsed but for the first release I would be
> happy to get just geocoded dives with GPS fix.

So let's do nothing :-)

> > The question is (once again), as the user does this most likely exactly
> > once, how much effort do we want to spend on this?
> 
> Once?
> Every time you add a dive site and you get GPS data, you query a
> reverse geocoding system and nice geo tags are added on your dive.
> If user has GPS data in his logbook then probably he is someone who
> cares about dive sites and geocoding bells and whistles.

You misunderstood. I was referencing the parsing of the location text and
trying to figure out what it means - the thing we just agreed not to do.
That part one would only have done once during the upgrade.
The GPS reverse lookup you'd do all the time.

> >> >> >> 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.
> 
> Looking at the notes panel we need just a small space above the
> location tex field to insert a row of max of three bubbles.
> We are plenty of space. They are like current tags or similar.

:-)
You convinced me. We'll try it and see how it looks.

/D