Editing saves on every keypress. It hammers my connection.

[9662]

It appears that the application tries to mimic the approach on the ownCloud web front end, which has no explicit save mechanism.

As far as I can see, for every keystroke the whole file is being sent to the server. If let us say the user is editing a largish note on low bandwidth, this becomes a bit of a problem. It also totally screws up my Activity feed.

Why not:

• Have an explicit save mechanism (e.g., an icon, menu option) so the user can choose when to save.
• Save automatically on leaving the note (going back to notes list, dismissing application)
• Save automatically after a period of inactivity. Let us say, if the user has not typed anything in the last x seconds.

The options above need not be mutually exclusive. Do note however that any automatic saves should have an undo option, to allow the user to recover from accidents (the web front end provides this via file versioning).

[stefan-niedermann]

Hi @9662,

It appears that the application tries to mimic the approach on the ownCloud web front end, which has no explicit save mechanism.

This is correct, see #26.

As far as I can see, for every keystroke the whole file is being sent to the server.

Not for every keystroke, no, but:

Save automatically after a period of inactivity. Let us say, if the user has not typed anything in the last x seconds.

The period of inactivity is 1000ms.

Save automatically on leaving the note (going back to notes list, dismissing application)

This is also happening.

Do note however that any automatic saves should have an undo option, to allow the user to recover from accidents (the web front end provides this via file versioning).

Please have a look at issue 57: "Pressing the top-right X-Button allows an user to cancel his editing (I noticed this is a strange behaviour - auto-save is nice, but when i have done something i'm not able to cancel my changes) "

We already thought about this and will implement undo, as soon as the blocking sync-service-branch is ready :)

Puh. Any questions left? We could talk about increasing the period of inacitivty, but i think a whole second should be enough.

[9662]

Sounds cool. I would just say, perhaps make the inactivity delay user-configurable? That's one of those things for which one-size-fits-all just doesn't work.

[stefan-niedermann]

Yeah, i know what you mean, but think about Good Defaults Instead of Options.
Lets think about how we can do it better instead of providing an option.

Example:

1. Default: 1sec
2. User goes into edit mode
3. If user has only 2G connection -> increase delay to 3 sec

[bvolkmer]

Why not a two phase save.
Phase 1: Save on keystroke/ short intervalls internally
Phase 2: Sync on lager intervalls/exit/inactivity to the server.

This leeds to much reduced bandwidth.

The only bad points I see in this are:

• The version on the server is older on an appcrash.
  But newer version is still on the device, to be synced at the next startup
• Worse parallel editing. If there is someone editing on the webui, the changes will come in less frequent. But this is, as far as I can estimate a very rare one. Is it currently even possible?

This should balance both stability and bandwidth.

[stefan-niedermann]

Is it currently even possible?

No, sadly not. The webapp itself does currently not provide an api :-/

Nice idea, i will think about it. But as you already pointed out: When you want to work on both, app & web you have to wait longer before you refresh at the web version... hmm...

Maybe combining the two ideas? When you edit parallel on notebook at web and on mobile, you are mostly on wifi (notebook) - and so you are on your smartphone. So:

• When you are connected via WiFi, keep current behaviour
• When you are not connected via WiFi, store note only in database and sync only every 3 seconds

[9662]

Yeah, i know what you mean, but think about Good Defaults Instead of Options.

I know that principle rather well, that's why I said “one size fits all” does not always work. Also, default is not the same thing as hardwired.

Lets think about how we can do it better instead of providing an option.

One thing does not preclude the other, on the contrary. There should be a good default (for some sensible definition of “good”), while at the same time the user should always retain ultimate control.

As an aside: an example of this is Mozilla Firefox's and Thunderbird's about:config. Provided that sensible defaults are used, one never has to go there in order to use the software, but if I decide that I need to tweak things then I can do it (being behind a low bandwidth link, e.g., a satphone, is a good example).

With that said, I'm all for for trying an approach like @X4fyr describes first. If that still doesn't fulfil mine or some other user's needs, then further customisation may be considered. Make sense?

[stefan-niedermann]

@9662: Answer: sorry, but no, there won't be an option to set the period of inactivity.
Better help finding a solution which does not need a preference, like the suggestions in the three comments above you.
Thanks.

[bvolkmer]

In addition to my previous described approach, it would be easy to implement some kind of offline mode, interrupting after phase 1, resulting in no bandwidth at all.

I think a thing like a about:config would be far to overpowered for such an app. And putting such small details, that the minority of users might use, in to settings, will just make them less overseeable.
This general problem of bandwidth shouldn't be addressed by apps, but by the system, android, it self.

P.S. and not to discussed here, just as a future thought on this.
This might reference to (the now closed) #64 , as in such a offline mode, a manual sync(-button) might make sense, turning the offline mode to a "autosync switch". Otherwise, a offline mode should be handled by the system, not the app, but as android does not have a per app switch, the problem remains. But this can be surrounded by simply turning online for a short moment. I definitely will not continue #64 here.