Printer is busy.
Printer is not available for printing
This is what Preform was telling me earlier today. It’d be a non-event if it wasn’t because both things are false.
My computer was at the moment connected to the Internet through a different network than the one where my Form 2 is attached. Therefore, Preform wasn’t able to see the printer. So, you’d think that Preform would say “Unable to connect to the printer”, right? Well, no, it throws the coin and states that it’s busy.
Therefore my request is: Don’t lie to the user. Can’t connect is can’t connect. You don’t know if it’s busy or not. Guessing (or using a generic message that is too specific) is guaranteed to confuse, upset or confuse and upset the user.
Thanks.
At a fundamental level, can’t connect is a timeout, whereas printer busy means, or should mean, that the software has connected to the printer, queried its state, and the printer reported to be busy. Very different animals.
Your hypothesis would work if, for example, internally the software used a comms library that either works, or just returns a generic error. But that is bad design anyway. Well let’s not say bad, rather “desperately needing improvement” design
While “Printer is busy” is a bit misleading, technically the statement “Printer not available for printing” is accurate and adequately descriptive of the condition. The printer was not available.
The driver should know the difference between the printer actually being busy (meaning it does not respond over the network) vs. not being present. I agree it is a simple matter of the application of a timeout limit. No response from the printer in, say, 15 seconds, assume it’s offline and say “Printer appears to be offline”.
The printer should always respond over the network. If it’s busy it should respond with a busy message. If it has extended times where it is too busy to respond, it’s communications are not very robust (bad for a commercial product, especially at this price.)
You’d like to think that, I know. I would too. But the reality of these types of communications systems is that there are many reasons why an “initiator” may not be able to get a response to a “target”. Drivers implement “Command Timeouts” to prevent themselves from permanently hanging in these situations. Because if they didn’t, they would hang, because these situations are inevitable even when the systems are working normally.
By way of a parallel example, take the HDD or SSD inside your computer. The driver for that device implements a timeout that (depending on the OS) ranges from 5 to as much as 30 seconds. Even though you’d be right to think it shouldn’t be necessary, that the HDD or SSD should always respond to the computer. But they don’t, always.
You are correct that “can’t connect” is a timeout. PreForm will continuously try to connect to the Form 2, which is why you’re not immediately notified. I have to agree that the semantics of “Printer is busy” might be a bit confusing and an ineffective “catch all” message. We do our best to prioritize the user experience as we continuously make improvements. We’ll certainly reconsider improving the PreForm error messages. Thanks for the tip!
