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