[RFC ]Dive site tags: my try

[Davide DB]

This was my old proposal of dive site management.

I understand that following a complex workflow on a quoted text email
it's not the best way to understand it.

On Wed, Feb 18, 2015 at 1:14 AM, Davide DB <dbdavide at gmail.com> 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.
>
> 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.
>
> 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
>
>
> 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)
>
> 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).
>
> 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.
>
> 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.
>
> 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].
>
> When you add GPS data to an existing dive, reverse geocoding format
> would take precedence over previous data (aka overwrite).
>
>
>
> NOTES TAB
> --------------------------------------
>
> IMHO the new Location field into the Notes panel should be just a NOT
> editable texbox.
> 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
>
> There's no "manage button" but there is a new tab named "Dive site"
> that is an extended view on the dive location.
>
> 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.
> 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.
> 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...
>
> Any operation on this panel will trigger an edit!
>
> 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'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)
>
> --
> Davide
> https://vimeo.com/bocio/videos