What is the yard stick by which you decide the trade offs while designing features? This post is an attempt to look at two radically different point of views regarding the trade offs in designs vis via an ongoing feature implementation and another example taken from Vista’s user interface changes.

The feature

Our network management tool, Cisco NetManager, can perform fault monitoring and notification for network devices. One such fault it can sense, are the link down states for the individual ports, which is basically when the particular network ports appear to be off-line or non operational.


Quite understandably Link Down is an important event to be sensed and this is done in three different ways by NetManager.

  1. By listening to ad-hoc Link-Down SNMP  traps sent from the device.
  2. By periodic SNMP based polling of all devices, which senses that a particular port is down
  3. By CDP based discovery process that runs every once in a while to discover the physical connectivity of the devices being monitored.

Issue – Flood of Correct but Un-Required Messages

As a result of these fast multiple port status detection methods, network port status changes are sensed almost in real time by NetManager. However real networks have switches and routers with plenty of un-used ports which appear to be down, simply because they are not in use. Users get inundated with notifications about the down ports of such devices, whenever notification sends down the initial list of failures it has detected initially after install. For big networks, this runs into many thousands of useless but correct alerts and needs to be controlled.

The New Requirement

We are planning to correct the above issue of un-necessary alerts in the upcoming version, which aims to cut down on this un-used ports traffic, by sensing un-used interfaces and not have any alerts reported on them. What follows is the list of facts we have considered in designing this feature and how we plan to accommodate them in the final design.

  1. Other Network Port Related Features –The next release of NetManager will also include a voice utilization feature for voice gateways, which can be used to properly size the available bandwidth using Erlang based calculations. For this reason, some of the ports discarded by the current code would be required to be processed.
  2. Only Specific Ports are Currently Alerted – Not all ports are considered for alerting. This is because many port types really do not have a strict up down status or they might translate to other status types frequently, depending on the nature of operations. For this reason, the current set of valid ports are hard coded into the source code, which is really a bad programming practice. One goal of the current set of modifications is to make this list of types looked up from some external source in an easily configurable manner.
  3. Future Requirements – There is a definite possibility that some customers might not want the same type of ports to be alerted upon by default, for reasons specific to their deployment.The challenge is to consider (not implement) this requirement along with the current feature so as to make the design flexible enough when the time comes for implementing it.
  4. Familiarity with Code – An additional advantage of expanding the design at this stage, rather than later is because this promotes familiarity with the relevant module and affords easier modifications than if the code base where to be freshly looked at during the next code cycle, after a gap of 6-7 months.

Designing for Configurable Network Port Types

The complete design, which makes the default list of network ports look up based would ideally

  1. Make the default list of port types configurable AND
  2. Make the alerting for the individual ports customizable, and based on user preference for the specific port.

Design Side Effects

Lets inspect what happens if the user changes the global alert-able setting on any port type.

  • What happens to devices with ports of the same type, that the user has already configured?
    • Leave the customized ports alone – in this case ports of some devices would show a different behaviour compared to other devices.
    • Change the alert settings irrespective of individual device settings – here the user would lose all the customizations he has made and the expectation of how a devices configured previously behaves would be violated.
  • What happens if the system does not make any changes for devices that are already present and instead affect only the new devices that will be added in the future – in this case some devices would behave totally differently from other devices and lead to confusions overall.

No matter which option we chose, we will be left with in-consistencies in the way system behaves wrt to the alert-able ports. Even though it is the user who changes these settings, in the end they would be left in need of explanations as to why the system behaves the way it does.

Rules Rules Rules

Features that exhibit this sort of behavior, forces users to learn how the system reacts, if they have to be able to use it effectively. When you have multiple pieces of system designed in this manner, with possible inter-relationships to moot, the overall complexity shoots up quite fast.

These sort of designs used to be the norm till recent times. But thoughts about quality in designs, that create simpler and more usable products have been around in the background for some time too, of the type famously pioneered by Apple perhaps, in their design of extremely user friendly and hence popular but at times restrictive products. Here is a sample

XP sound control

xp-sound-controlNotice how the sound control talks about SW Synth and Wave?

What are they and how is it different from the volume? This is the sort of design that’s typically promoted by feature rich craziness.

Designing for Usability – Vista

basic-vista-sound-control Contrast the above with new Vista Sound Control. This, is all that turns up whether you double / single click the sound icon on the Vista task bar. Notice how the other “features” have been cleaned up and the icon made more realistic so as to leave no more doubt regarding what is the intention.

Folks who are more detailed, would notice another click-able option below, termed the mixer, used to bring up the more advanced user interface. Basically Microsoft seems to be relying on the ubiquitous http style user interfacing which everyone already knows and favours, as a  basic program-user interfacing guideline.

Look below for what comes up, if you click on the mixer label.

The Real Feature – Mixer


That dialog allows you to control the volumes emitted by the various applications you might have running inside your computer. Now, this is definitely what can be termed as a feature. Another rule, or complexity or menu interface is really not what makes a new feature, but something totally new, that makes life easier for the user, without adding more rules.

Apple’s, famous designs became favored in the same manner, with more simplification rather than complexity / features compared to other players. This unmistakably popular appeal of usability as opposed to pointless features is what i will use to guide our design on the network port configurability issue.

Design for Usability – Network Ports Decision

How do we factor this into the network port customization issue we discussed above.

  • When devices are added, each port will inherit a setting as to whether they are alert-able or not based on  the global defaults. BUT THE DEFAULTS WILL NOT BE CUSTOMIZABLE BY THE USER.
  • The user can override the alert-able setting for individual ports on a device

This solution i believe would be simple enough and give the user a feature that is required, without complicating usability anymore than is required.  It does give a feeling of lost features compared to the full design, as might be the case with the Vista sound control, which lost SW SYNTH, WAVE etc.

But ti feel that the usability improvements and reduction in complexity more than offsets the loss of these minor details more than anything else, for the simple reason that the product is more easily used and less complex and hence is more value for money.

ps : Customer types that require more control can very well tweak these settings themselves by using external scripts that can be provided to achieve this.

ps : Netmanager 1.1 has a notification filtering feature that can decide the type of alerts and the exact group of devices you want to be alerted for.