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