Bob,
> > Based on my proposal, here is the scenario:
> >
> > 1. Toner goes low, printer goes offline. User sees this display from
> > the management app:
> >
> > RED: Printer has stopped due to low toner
> >
> > 2. User goes to printer, presses "Continue" (or whatever). User now
> > sees this display from the mgmt app:
> >
> > YELLOW: Printer is low on toner
> >
> > That is, once "Continue" is invoked, the RED (critical) alert is removed
> > from the table, and is replaced with a YELLOW (non-critical, warning)
> alert.
>> How does the user (or your software) know that in this case printing can be
> resumed by pressing 'Continue' (or whatever)? What makes this critical
> alert different from others?
Sorry if you misunderstood my scenario steps above.
The scenarios assumes that the printer has a way to continue operations
upon some sort of human intervention (eg, pressing a "Continue" button
on the front panel, as some models are currently implemented). Of course,
if the printer can NOT continue in any way, then the scenario stops at
the first step above.
What makes this critical alert different than others? As a critial alert,
absolutely nothing. The key point here is that we now have a particular
alert condition ("toner low") that can be either a critical or non-critical
alert, depending on the precise state of the printer at any given time.
That's new for us, right? Until now, a vendor would pretty much fix the
severity level for any given alert code, at least from what we've seen in
our testing.
...jay