Diary: Notifications
Posted: Wed May 11, 2011 9:05 am
I've been working for quite some while now on notifications and lately have begun to convert some of the overlays that display useful information to the new notification framework.
In the process of doing that I started to reconsider the viability of one design decision in particular I made along the way. When talking to Felix about it, he suggested I should post my problem here, to get a more varied response and, hopefully, some helpful suggestions or comments.
But first, let's talk about why we notifications in the first place and how they're implemented so far.
The basic goal behind the notifications module is to provide an easy to use, coherent framework to both send and display notifications, notifications being short messages informing the user about something you think he should know.
The reasons why I felt the need for such a system are manifold, mainly I didn't want to deal with overlays every time I wanted to display some informative text. I also wanted to give the UI designer more control about what is displayed how, when and where, and ultimately prevent a chaotic situation, where, in order to display some text I would have to know about any overlay that currently exists, just to be sure it doesn't interfere with what I want to do.
As for the implementation, I decided to separate the displaying of the notifications from the process of sending and storing them.
Sending a notification can be done trough a static function of the NotificationListener. The notification is then registered with every NotificationListener and the NotificationListener also takes care of all the network stuff, e.g. if the server wants to send a notification to just one client.
Then there is the pivotal entity in the whole notification framework, the NotificationManager. It is in fact the only NotificationListener (so far) and it's responsibilities are the storage of the notifications (ordered by their time of arrival) and their redistribution to the entities that display them. Later this could also be used to display some kind of notification history.
The entities that display the notifications are called NotificationQueues and they have all the notifications they currently display (or plan to display in the future but haven't gotten around to displaying them), they have parameters such as the maximum number of notifications they display at a given time or how long a notification is displayed at the most. They also talk to CEGUI to do the actual displaying. (The framework could be extended without much effort to have a special type of NotificationQueue that displays its notifications using overlays instead of CEGUI, but I think CEGUI is much more suited to do this.)
In CEGUI the notifications (or rather the NotificationQueues, that then display the notifications) are displayed in a sheet called NotificationLayer, that can be shown or hidden to show or hide all notifications.
There is some more fancy stuff, such as commands that affect the NotificationQueue in ways other than displaying notifications (e.g. clearing them), or NotificationDispatchers, that allow to display (customized) notifications as a result of something happening in a level (e.g. a Trigger triggering) and also some stuff in the works, e.g. different types of notifications (info, important, ...) that the NotificationQueue can decide to display differently.
Now to the problem: So far whenever a notification is sent, a sender (which is just an arbitrary string, that should identify the part of orxonox the notification is coming from, e.g. if a notification comes from the questsystem the sender could be set to "questsystem") has to be specified and each NotificationQueue has a list of senders it accepts notifications from (or displays notifications of).
This may be counter-intuitive at first glance, because you may think of a NotificationQueue as a kind of Blackboard that you decide to put your notification on and where it is then displayed.
But that's currently not how it works. A proper analogy would be to think of a NotificationQueue as a mask that only lets you see notifications from parts of orxonox you defined.
There are various advantages to this strategy. First and foremost if we decide to change our NotificationQueues, e.g. we started with two, one displaying all quest-related notifications and another displaying all gametype-related notifications, but now we want to just have one queue displaying notifications for both of them, we run into problems, if we have the Blackboard approach. We would need to go through each instance we send a notification and change where we send it to. This gets very tedious very quickly (and you'll need to recompile a lot of code).
With the current approach we only need to change the senders that are accepted by the NotificationQueue, which in the future might bold down to just changing some parameters in an XML file.
Additionally the NotificationQueue could actually indicate where the notification came from, helping the user to more easily determine its relevance.
The question is, whether it would be more usable, and thus justify the loss in adaptability, if we would do the Blackboard approach.
Also I'm curious what other questions, comments and suggestions you have regarding the notifications.
In the process of doing that I started to reconsider the viability of one design decision in particular I made along the way. When talking to Felix about it, he suggested I should post my problem here, to get a more varied response and, hopefully, some helpful suggestions or comments.
But first, let's talk about why we notifications in the first place and how they're implemented so far.
The basic goal behind the notifications module is to provide an easy to use, coherent framework to both send and display notifications, notifications being short messages informing the user about something you think he should know.
The reasons why I felt the need for such a system are manifold, mainly I didn't want to deal with overlays every time I wanted to display some informative text. I also wanted to give the UI designer more control about what is displayed how, when and where, and ultimately prevent a chaotic situation, where, in order to display some text I would have to know about any overlay that currently exists, just to be sure it doesn't interfere with what I want to do.
As for the implementation, I decided to separate the displaying of the notifications from the process of sending and storing them.
Sending a notification can be done trough a static function of the NotificationListener. The notification is then registered with every NotificationListener and the NotificationListener also takes care of all the network stuff, e.g. if the server wants to send a notification to just one client.
Then there is the pivotal entity in the whole notification framework, the NotificationManager. It is in fact the only NotificationListener (so far) and it's responsibilities are the storage of the notifications (ordered by their time of arrival) and their redistribution to the entities that display them. Later this could also be used to display some kind of notification history.
The entities that display the notifications are called NotificationQueues and they have all the notifications they currently display (or plan to display in the future but haven't gotten around to displaying them), they have parameters such as the maximum number of notifications they display at a given time or how long a notification is displayed at the most. They also talk to CEGUI to do the actual displaying. (The framework could be extended without much effort to have a special type of NotificationQueue that displays its notifications using overlays instead of CEGUI, but I think CEGUI is much more suited to do this.)
In CEGUI the notifications (or rather the NotificationQueues, that then display the notifications) are displayed in a sheet called NotificationLayer, that can be shown or hidden to show or hide all notifications.
There is some more fancy stuff, such as commands that affect the NotificationQueue in ways other than displaying notifications (e.g. clearing them), or NotificationDispatchers, that allow to display (customized) notifications as a result of something happening in a level (e.g. a Trigger triggering) and also some stuff in the works, e.g. different types of notifications (info, important, ...) that the NotificationQueue can decide to display differently.
Now to the problem: So far whenever a notification is sent, a sender (which is just an arbitrary string, that should identify the part of orxonox the notification is coming from, e.g. if a notification comes from the questsystem the sender could be set to "questsystem") has to be specified and each NotificationQueue has a list of senders it accepts notifications from (or displays notifications of).
This may be counter-intuitive at first glance, because you may think of a NotificationQueue as a kind of Blackboard that you decide to put your notification on and where it is then displayed.
But that's currently not how it works. A proper analogy would be to think of a NotificationQueue as a mask that only lets you see notifications from parts of orxonox you defined.
There are various advantages to this strategy. First and foremost if we decide to change our NotificationQueues, e.g. we started with two, one displaying all quest-related notifications and another displaying all gametype-related notifications, but now we want to just have one queue displaying notifications for both of them, we run into problems, if we have the Blackboard approach. We would need to go through each instance we send a notification and change where we send it to. This gets very tedious very quickly (and you'll need to recompile a lot of code).
With the current approach we only need to change the senders that are accepted by the NotificationQueue, which in the future might bold down to just changing some parameters in an XML file.
Additionally the NotificationQueue could actually indicate where the notification came from, helping the user to more easily determine its relevance.
The question is, whether it would be more usable, and thus justify the loss in adaptability, if we would do the Blackboard approach.
Also I'm curious what other questions, comments and suggestions you have regarding the notifications.