fundamental design issues with trips and dives

[Dirk Hohndel]

I hope that this subject line gets the right people to read this email - getting traction on the developer list has been very hard lately.

I'm on a flight from Amsterdam to Portland and am contemplating yet another rewrite of the divelist models for mobile. The rewrite I did this week showed that we can address the performance issue of the old idiotic (designed and initially written by me) code that we used to have for folding dive trips. But in the end it's just another hack introducing another layer of weird trickery and because of that makes it near impossible to do nice transition animations in QML. Fundamentally using magic dives that aren't actually shown to create section headers that we use for the trips is breaking way too many assumptions in QML - and there are explicit comments in the Qt documentation NOT to have zero height entries in a view (which is exactly what we do. Oops).

So I decided to use my time in the air to work on cleaning this up and creating a new underlying DiveTripListModel that has entries for the trips and the dives and that makes the UI much simpler. And of course the backend more complicated. While working on that I realized that we have a very fundamental issue how we deal with the date of a dive being changed. This isn't the first time we noticed the issue - in the past we just decided to punt ("hey, the user gets what they deserve").

Simple way to illustrate this in the mobile UI (just run this with test data, not with your real dive data, either on a device or on mobile-on-desktop... I find the latter much easier most of the time):

Let's say you have seven dives

Trip Nov
- Nov 6
- Nov 5
- Nov 3
One dive outside a trip to make things worse, let's say Oct 3
Trip Sep
- Sep 5
- Sep 4
- Sep 3

Now we allow the user to edit the date and time of a dive. That is a frequently requested feature and while I have serious misgivings with the following examples from a "what the heck does this mean in real life" perspective, we allow the user to do this:

Change the date of the Sep 4 dive from Sep 4 to Nov 4

Do it in Subsurface-mobile, I'll wait here. And after you edited the dive and tried to make sense of the dive list, tap/click on the dive trip headers you see to expand and collapse each of the trips, and again try to make sense of what you see. Are you done laughing, yet?

Looking through the code it's obvious why this happens. The question becomes, what should we do about it.

(1) we could prohibit date changes that change the order of dives in the dive list. that would prevent any of this from happening; people who downloaded dives from a dive computer with messed up clock might be unhappy, but there are ways to work around this. It's just really painful and not very user friendly. And almost impossible - no, actually impossible to do on mobile only. You need the desktop version in order to export the dives you want to move, delete them from the dive list, change their timestamp in the exported file, and then import them again. Yes, this is a weird corner case. But it does happen in real life.

(2) we could take the approach that moving the dive into the middle of a different trip removes it from Trip Sep and adds it to Trip Nov. That makes sense. But what if it we change the date to Nov 2 - is it now part of Trip Nov? Or a dive without a trip? There are a couple more odd scenarios I can create with this. What happens if I move a dive that is marked as no_trip into the middle of a trip. Does it become part of the trip?

(3) we could say that any dive that is moved across trip boundaries (and that dive outside the trip on Oct 3 is of course a boundary) become dives outside of trips, period. And that adding a dive outside of trips in the middle of a trip simply splits that trip into two, with the same data except for different start times. That would be easy to do, super logical and consistent - but since we don't offer any UI to modify trips on mobile it creates more questions later

(4) ??? other ideas?


Frankly, I dislike (2). That feels inconsistent and fragile and unintuitive. But maybe I'm wrong?
(1) is really easy to implement and the vast majority of users will be happy with it. Dealing with the small number who really need to reorder dives in the dive list might be less work overall
(3) seems to me like the most logical, most consistent thing. It's a lot more work to get this right and it really makes adding UI for trip modifications to the mobile app seem almost required, which is even more work

Before I spend much more time on my new dive list model idea I really need to understand what we should do here, because this will impact the design of my data structures...

Thanks to everyone who read all the way to here. Now please respond and give your feedback - even if it is "Dirk, you're on drugs, get of the internet while on an airplane".

/D