Clock app missing remorse timer when deleting

Bug Reports
1

REPRODUCIBILITY: 100%
OS VERSION: Since SFOS 1.x
HARDWARE: Xperia 10 II
UI LANGUAGE: DE
REGRESSION: UNKNOWN

DESCRIPTION:

This one is a long standing issue but I never found the time to report it until now.
In the clock app with timers/alarm configured I sometimes change the configured hour:min. To do this its necessary to long tap the alarm and choosing “Edit” to make this change. By accident sometimes “Delete” is choose and the configured alarm is immediately deleted without the change to abort this action (missing remorse timer)!

PRECONDITIONS:

Native Clock app with an alarm configured

STEPS TO REPRODUCE:

  1. Open Clock app
  2. configured alarm
  3. delete alarm

EXPECTED RESULT:

When delete is choose a remorse timer should provide the possibility to abort the action

ACTUAL RESULT:

configured alarm is immediately deleted

MODIFICATIONS:

NONE

ADDITIONAL INFORMATION:

This issue exists since my Jolla 1 phone / 2015

4 Likes
2

I second that! Remorse timer is badly needed there.

3

It’s all discussed and and explained by Jolla here Remorse timer for alarms removed - together.jolla.com

But I agree it still feels inconsistent.

4

A patch could be easily set up, no?

5

Well, explanation that “We do not show the remorse timer in case the user can create the content/info again after deletion” isn’t too convincing as actually everything can be created again after deletion, it’s only a question of how much work / time it’ll take to get it back.

Remorse timers have a configurable timeout (4000 ms by default), so why not use some longer timeout (e.g. the default 4 seconds or more) for more important things (that would require more work to re-create in case of accidental deletion) and some shorter timeout (e.g. 2 seconds) for less important items, easier to re-create, instead of completely removing the timer?

Like for nearly anything else, but what does it change?

6

@adekker thanks for that pointer! There is the communicated reason and explanation; that i want to comment at.

The explanation is representative for a lot of decisions made by technical folks. Therefore I invite you all (who ever all is) to take a step forward. This issue is not about a technical requirement or semantic definition (e.g. loose data) its about the usability and resulting user experience. Personally, this issue leaves me angry when it happens. So, what can be done by the UI Design and System Engineer team?

Some rules exists and I present only the relevant ones for this issue:

The design decision should be reviewed with the help of following principles:

  • Prevent Errors: Design an UI that prevent such issues and react fault tolerant.
  • Permit Undo: The user is human and humans do things (by accident) that they regret
  • Support Feeling of control: Give the user control of the interaction instead forcing technocratic decisions

Only this three ones would lead to a better user interface of the clock app compared to the current implementation. I hope that its inspired enough to re-evaluate the application state. Thank you!

7

From a cursory glance it looks like a one-liner, yes.

8 
$ cat AlarmItemBase.patch 
--- a/usr/share/jolla-clock/pages/main/AlarmItemBase.qml
+++ b/usr/share/jolla-clock/pages/main/AlarmItemBase.qml
@@ -12,12 +12,14 @@
     highlighted: alarm.enabled || down || menuOpen
 
     function remove() {
+      remorseDelete(function() { 
         if (alarm.enabled) {
             Clock.cancelNotifications(alarm.id)
         }
 
         showContents = false
         alarm.deleteAlarm()
+      })
     }
 
     width: Theme.itemSizeHuge

Apply as root:

cd / ; patch -p1 < /root/AlarmItemBase.patch

Testing feedback welcome…

1 Like
9

Works fine :wink:

Now the only thing I need related to clock alarms is that they are listed on the Events screen. Is there a patch for this?