pre beta test subsurface-mobile 689

Jan Mulder jlmulder at xs4all.nl
Thu Jan 21 08:25:46 PST 2016


On 21-01-16 16:48, Dirk Hohndel wrote:
> On Thu, Jan 21, 2016 at 11:11:52AM +0100, Jan Mulder wrote:
>> After the mysterious crash of yesterday (version 683) first a little focus
>> on the most recent changes with that respect. First, running on the desktop,
>> I can easily crash the app by pulling the divedetails slider. Difficult to
> Can you explain in a bit more detail what exactly you mean by "pulling the
> divedetails slider"? Do you mean the horizontal bar at the bottom of the
> screen?

Yes, the horizontal bar at the bottom. I mean with "pulling the slider". 
Focus with the mouse and hold it while sliding to the right. Basically, 
this overfloods the call of setDiveId, as in very quick selecting 
different dives.


> Which OS are you running? Which version of Qt are you running with (btw,
> that's in the log display that you can get to from the left drawer under
> Developer)?
Arch Linux, latest pacman -Syu, and the Qt stuff from the Arch 
repository. Version 5.5.1.
>
>> Back to other functionality:
>>
>> Editing of dive details. Ok, it works, and I can press save. When the save
>> button is hit there is no feedback that the save button is actually pressed
>> (in hindsight I think that that is true for all button hits throughout the
>> app).
> I thought that was implemented in Rick's change to abstract out the
> SubsurfaceButton.qml but didn't pay much attention to that detail. Yes,
> the button should change when pressed - different color or something. Jan,
> would you like to try to play with this? This is a really nice and simple
> way to get your feet wet with QML (and you clearly are already building
> your own on the desktop).
Ok, I will give this a go. I already did Henriks simple "back to 
divelist" (but I see something I still do not like and I do not want to 
spoil the fun :-)

>> This is confusing because saving takes multiple seconds to complete.
>> In addition. what is the dive-edit save actually doing? It doesn't save to
>> the actual cloud, but (I assume, did not check the source) but only to the
>> local cache.
> Yes - I discussed this on the mailing list a while back. On the desktop
> app save just marks the dive list as changed and then prompts you to save
> on exit; that doesn't make sense on mobile. So instead we save to the
> local cache when we save. But we only save to the cloud if you do so
> explicitly from the left drawer menu.
Yes, that is what I thought as well, so was surprised by the "save at 
start" as discussed below.

>> So, exited the app, checked the cloud data from my desktop. The
>> latest save (from the divedetails edit page) is not in the cloud. Opened on
>> the device again, and the last edit shows. Now, reopen the cloud on the
>> desktop. And yes, the last save is now also in the true cloud. So: on start
>> of the app, the local cloud is synced to the true cloud. I am not sure that
>> that is what a mobile user expects. This all said, it edited and saved
>> correctly.
> Yes. that is kinda strange, now that you mention it. Maybe we should save
> to the local cache and return to the execution thread and in separate
> thread try to sync with the cloud. I just want to make sure that the UI
> doesn't get stalled by this.
Yes, that sounds like a solid approach.

>> The editing itself. The notes box is bigger than the screen. So when
>> starting to enter text, you run out of screen and do not see what you type.
> Really? What device? What screen resolution?
5" screen portrait orientation. 720x1280 pixels.

>> Re-positioning of the edit screen does not work (it slides back when
>> swiped). Basically, re-styling the edit screen would solve this (labels on
>> top instead of in front).
> But that uses a lot more vertical space overall. I'll play around with the
> options there to optimize. Maybe do this just for the notes..
I agree that the main "problem" here is the notes.

>> Then the situation that the cloud is newer than the local cache. The app is
>> opened, splash screen follows, and after that the divelist is shown. Hit any
>> dive, but nothing happens. Ok, the app is busy refreshing the divelist and
>> local cache data. It is visual feedback that is missing here.
> Yes and I have no idea what to do in that case. I want to show the dive
> list from cache right away. That's just a much better user experience. But
> then after the sync from the cloud is completed, what do we do if there's
> a change?
I agree that this is a dilemma. Is is just the lack of visual feedback 
here that causes me to click some more times before realizing that it is 
just busy. I am not really into UI design, but "greyed out" or "wait 
cursor" spring to mind.

>
>> Some functionality that I really would like to be it a useful tool:
>> - the auto complete edit things from the desktop app (for example buddy
>> names, and divesite names).
> Oh no. No no no no no. Maybe in version 2. But we will not add that
> nightmare of complexity to the first version of the mobile app.
>
>> - some way to filter dives. For example, when on a trip, I like to check for
>> previous dives on that site. The cloud web interface is currently perfect
>> for that.
> Again, great for version 2. Not for the initial version.
>
> Please file these as "enhancement" requests on the bug tracker so they
> don't get lost.
Agreed and I file these as enhancements. However, i think the especially 
the first one (autocomplete) will result in not using the app for real. 
Entering at the divesite correctly (proper spelling of names) will not 
happen for me, and just trying results in lot of work later to correct 
it. But again, version 2 stuff.

best,

--jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160121/e819a7ed/attachment.html>


More information about the subsurface mailing list