I agree. This will be addressed in the new notification system design. Those use cases such as volume control and brightness, battery charging, progress feedback, etc., will have a different layout and usage than the 'normal' notification bubbles. They should be more subtle as their true nature is to provide feedback and remove uncertainty about background or implicit operations the system is performing.
They should not be persistent or stack, as they are above other elements on screen, user should be able to tap through them as the current activity remains visible and interactive. The idea is to make them as unobtrusive as possible, while still showing the user useful information.
The standard duration/timeout is yet to be discussed. In the NotifyOSD wiki, the standard duration for a confirmation bubble is 2000ms, can anyone confirm this is correct for the current built?
I'll add further information on this subject from next week.
I agree. This will be addressed in the new notification system design. Those use cases such as volume control and brightness, battery charging, progress feedback, etc., will have a different layout and usage than the 'normal' notification bubbles. They should be more subtle as their true nature is to provide feedback and remove uncertainty about background or implicit operations the system is performing.
They should not be persistent or stack, as they are above other elements on screen, user should be able to tap through them as the current activity remains visible and interactive. The idea is to make them as unobtrusive as possible, while still showing the user useful information.
The standard duration/timeout is yet to be discussed. In the NotifyOSD wiki, the standard duration for a confirmation bubble is 2000ms, can anyone confirm this is correct for the current built?
I'll add further information on this subject from next week.