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 <[email protected]> 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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
