We have moved to a new Sailfish OS Forum. Please start new discussions there.

notes gestures not intuitive

asked 2013-12-30 19:27:00 +0300

Low gravatar image

updated 2013-12-31 13:12:15 +0300

dez gravatar image

The basic concept seems to be that a L>R pull cancels the current action and/or goes one level higher, while a R>L pull saves/accepts the current action.

In the stock notes application, when I make a new note, when pulling L>R after writing something I go back to all notes. The note I just wrote gets saved.

I'd prefer the notes application to follow this pattern, so a L>R pull should not create/save the new note; and to actually save what I just typed a R>L pull should be required.

edit retag flag offensive close delete



it serves a "note"app to just save anything you enter it

chemist ( 2013-12-31 00:54:13 +0300 )edit

1 Answer

Sort by » oldest newest most voted

answered 2013-12-31 13:11:52 +0300

dez gravatar image

In a perfect World it should be so that any information supplied by user should not disappear until user is asking to delete it explicitly (holy user data). So, Notes behaves correctly from this user friendly point of view, otherwise if you switch e.g. to call application on incoming call, forget about entered note and switch device off, or occasionally flick back, you will lose your entered data (and you can enter quite a lot of text there).

I agree there is some perceptive inconsistency in usage patterns for views. But there is a logical explanation because there are 2 patterns available:

  • "Cancel/Accept" or "Yes/No" dialogs: left->cancel, right->accept (also it has tips/buttons at the top). Ordinary they are used to enter/edit some information, when user can overwrite existing data, or should choose between 2 different choices.
  • Pop up dialog, used or to display something, or to perform some instantly revertible actions (like "Link" in People app), or to do some edits that do not overwrite some earlier existing information, as in the case with Notes: "New note" action does not overwrite anything, so can be safely undone later.

I'd prefer that it should be possible to have history for any editing action, so any action can be easily undone later. In this case "Cancel/Edit" can be deprecated and inconsistency goes away. But it is harder to implement proper editing with history management, so, I guess, this was the reason to have also "Cancel/Edit" pattern.

So, this is not a bug (behavior not expected by creators) but design choice. Any decision in a real World is a compromise and can't satisfy all needs :)

edit flag offensive delete publish link more


Arguably the main/categories tabbish approach in the store app counts as a third pattern, as the added view doesn't launch from an item but is just there at the top level. Perhaps it would be helpful to have some stronger visual cues for the different patterns?

sp3000 ( 2014-01-13 13:53:19 +0300 )edit

@dez And why do my sms messages disappear if I left the window to have a look to the contact details or to an other message? :) https://together.jolla.com/question/7666/sms-add-ability-to-view-received-sms-messages-while-composing-a-new-message/

Alex ( 2014-03-19 09:47:16 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2013-12-30 19:27:00 +0300

Seen: 136 times

Last updated: Dec 31 '13