"bealer, opensource based doesn't mean you can't take design decisions
or choices, we could try to fix every applications and blame random
softwares installed from the internet for making ubuntu bug or we can
enforce some design choices we believe benefit our users and
communication to software writers on our design choice and how to well
integrate with our system, it's what other very people device makers do
for their system as well and users don't complain so much about the
limitations since in the end it leads to things working nicely together
in a consistent way"

Of course decisions have to be made, that's what this whole argument is
about. People arguing the wrong decision has been made.

Being open source and community based just means people can contribute
fixes/patches (as per above), and also give feedback and be involved
around these decisions. That seems to be lacking in this case.

Decisions should be based on feedback. In this case from developers and
users in terms of experience. At the moment developers are crying out
for this feature. We don't know how users will be affected, because I
would guess it's not been tried. There's nothing stopping you opening it
up fully, and if it becomes abused, updating notify-osd so that timeouts
can no longer be specified, or as I mentioned implement a few different
levels of duration.

"The vast majority of people out there don't care about notifications"

Then let us set it to whatever we want!

"They don't want to understand why some of the messages coming are
different or to configure every softwares to behave different, that
should just be working on be out of their way"

They're not inclined to understand in many of the examples given. People
have given examples of when overriding would be beneficial and improve
user experience.

In the case of the screenshot example, I think the user would be more
inclined to think/ "understand" why the notification pops up for so
long, or is included in the screenshot (not understanding that the dev
that wrote it had no control over it), as opposed to if it came up
quickly.

With a notification app, you need to think how it's going to be used.
We've defined plenty of use cases above. And from example use cases
define an appropriate public interface. Not define how it should work,
then try to fit the use cases around it. That's awful design and will
either lead to poor user experience in the examples given, or people
developing the same thing twice, so that they can open it up more.

-- 
notify-send ignores the expire timeout parameter
https://bugs.launchpad.net/bugs/390508
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to