[RFC ]Dive site tags: my try

Wed Jun 10 22:11:13 PDT 2015

So this appears to be the last email in the thread on tags/taxonomy...

On Wed, Feb 18, 2015 at 02:31:00AM +0100, Davide DB wrote:
> On Wed, Feb 18, 2015 at 1:58 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
> > Davide,
> > 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.
> 
> Explosive mix :)
> 
> >> 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?
> 
> I simply forgot it.
> Yes, as you open Subsurface 4.5 you will prompted for data migration.

So we need to have a "welome" dialog if the user opens (or auto-opens) a
V2 logbook in Subsurface 4.5

That shouldn't be too hard

> >> 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).
> 
> You are right.
> I just wrote random thoughts. Of course a great care should be taken
> explainng the whole process.
> We don't want to loose our users.

And that dialog needs to very carefully describe what's happening, maybe
err on the site of being verbose.

> >>
> >> 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.

> > 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...
> 
> So we could find a way to indicate missing info during the normal use.
> You suggested a proper dive site view and management. We should find a
> flag there.

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

> >> 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...
> 
> Ok, you are right.
> 
> 
> 
> >> 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.

> >> 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?
> 
> Of course, In a hurry I just described the final effect.
> I was afraid that describing and drawing wireframes for everything I
> would have completed after the real implementation.
> 
> >> 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".

Funny, so that's the same argument we had a few hours ago. At least we
both stayed consistent :-)

> >> 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.

> >> 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.
> 
> You bought me.
> I was trying to save lines of code :)
> 
> >>
> >> 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.
> 
> Right!
> But with the dive site management view this will be trown away.

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...

/D