Displaying notifications in the user interface is an essential feedback mechanism. They inform the user that something of interest has happened. A virtual machine that belongs to them, and one of the disks is no longer accessible. The user might want to know about something like this as it could pose a serious threat to their business. Imagine this type of thing happening and we get notified by the guest operating system when we try to write to the missing disk. Better to let the user know as soon as something like this happens, using appropriate messages, perhaps even guiding their next course of action. The problem with this type of notification is that the user didn't trigger it. It was triggered triggered by the autonomous background behavior of the system. And so, displaying these types of notifications indiscriminately could pose a problem. The UI needs to select which messages to display.
Showing posts with label messaging. Show all posts
Showing posts with label messaging. Show all posts
Wednesday, February 27, 2013
Saturday, October 3, 2009
Why Use Email
Coding horror has a nice entry on why email is counter-productive. It takes a different view as to why this is so. Rather than assume that it is the need to respond to emails that is the counter-productive part, the entry states that it is the constant need to see if anything new has arrived. The chances of any important information arriving via email are quite slim. You might get one or to useful emails per day. So what is the contents of the other emails that arrive daily that you don't care about? Maybe smaller pieces of information that might be of some significance in the future, but not today. And being interrupted with these irrelevant pieces of information is what is counter-productive.
So how to deal with these irrelevant pieces of information? There are always social networks. Social networks are feature reach and are certainly more than common these days. But I find that even moving these smaller pieces of seemingly irrelevant data to social networks as the delivery medium does not solve the problem entirely. Sure, this would clean up your inbox and thus eliminate the need for you to constantly be checking it. But what about that nagging feeling that you are missing something on your social networks? They do suffer from the same productivity problems as email does. Something else that might be taken into account when considering social networks as a delivery medium for sending simple messages is the fact that they support many more features. These other bells and whistles can be even more distracting than email because email does one thing and one thing only.
Using a wiki for exchanging most types of information, both big and small pieces, often makes more sense. Larger, more static pieces of information can be created as wiki pages. Smaller pieces of information can be created as tickets in project management systems, most of which have wiki support. A threaded dialog can then be created on these tickets. The conversation is than public and persistent. It is also search ready. They key point here being that tickets and wiki pages for that matter, are not limited to a software development context. They are much more general purpose and do not require polling on the recipient's behalf.
So how to deal with these irrelevant pieces of information? There are always social networks. Social networks are feature reach and are certainly more than common these days. But I find that even moving these smaller pieces of seemingly irrelevant data to social networks as the delivery medium does not solve the problem entirely. Sure, this would clean up your inbox and thus eliminate the need for you to constantly be checking it. But what about that nagging feeling that you are missing something on your social networks? They do suffer from the same productivity problems as email does. Something else that might be taken into account when considering social networks as a delivery medium for sending simple messages is the fact that they support many more features. These other bells and whistles can be even more distracting than email because email does one thing and one thing only.
Using a wiki for exchanging most types of information, both big and small pieces, often makes more sense. Larger, more static pieces of information can be created as wiki pages. Smaller pieces of information can be created as tickets in project management systems, most of which have wiki support. A threaded dialog can then be created on these tickets. The conversation is than public and persistent. It is also search ready. They key point here being that tickets and wiki pages for that matter, are not limited to a software development context. They are much more general purpose and do not require polling on the recipient's behalf.
Subscribe to:
Posts
(
Atom
)