https://bugs.kde.org/show_bug.cgi?id=452264
--- Comment #16 from Volker Krause <vkra...@kde.org> ---
Some more technical background:
The notification popup UI is entirely outside of our control, it's provided by
the platform shell (Plasma, Gnome, Android, Windows, etc). What we can use are
two text elements (title and body) with some basic rich text formatting, the
default "activate" and "close"/"discard" actions and up to 3 named action
buttons. Additionally, there are a few special-purpose controls for indicating
progress, for things related to files/URLs (that's the mentioned hamburger
menu), inline replies to text messages or media playback controls, neither of
which is really applicable to event reminders.
So essentially the thing we can work with are the three action buttons. They
however also close the notification when activated on most platforms, so
clicking 3x 5min for a 15min suspension is also not possible for example.
Right now we use those buttons for "Dismiss" (which duplicates the
default/built-in dismiss action and thus isn't strictly needed, it's just
easier to hit than the small 'X' button, considering how often it's needed),
"Suspend" and a context-specific action when available ("Open URL", "Show
Map"). As mentioned before, that allocation doesn't need to be fixed, we can
adjust that depending on the context.
What we can do in theory is launch a separate UI from there, with whatever UI
we want. Not doing this has the advantage that we don't have to bother with
desktop vs mobile usability, notifications popups are appropriately adjusted
for us for free in that regard. The other thing to consider is to not make
things too convoluted for users for whom the current setup works very
efficiently.
That aside, the important part here IMHO is to properly understand what people
actually use this for, and derive from that how we can best support that. My
impression from the feedback here and elsewhere is that this is basically split
into two groups:
(1) reminders for things like meetings or calls, typically set shortly before
the event. That's the use-case the current implementation seems to support
rather well. The need for fine-grained suspension times is further reduced
there by the popup being able to remain open without interfering with continued
use of other applications while showing a countdown to the event.
(2) reminders being used as part of some form of task management workflow (on
either events or todos). That's where the reminder distance to the event is
typically bigger, or might not really matter at all as there is no hard
deadline (ie. reminders might be deferred past the event). That's where the
current approach isn't helping.
Is there a way we can distinguish those use-cases reliably? Then we could at
least give the second case three different suspend options quite easily.
--
You are receiving this mail because:
You are the assignee for the bug.
