Aigle wrote:But, the upside is our ordering system, is it's not compatible with anything other than Internet Explore. So, in a way I do have Windows (via Parallel's) but I have to use the Mac for everything else. Mostly what I don't like is I like to explore and figure out new things, with a Mac if you change something it's changed automatically.
I think that's hilarious. Given all the effort they put into switching over to a Mac shop, they still have to use Windows for something so critical! Irony like that is bittersweet.
That latter bit is part of the reason why I don't like Ubuntu. There's a lot of stuff in newer versions of Ubuntu that get changed without you really knowing... While I realize it's nice to keep some things hidden from users who don't care or don't want to know, outright changing something that MIGHT impact other systems without alerting the user seems to go against the entire grain of user interface design.
There was a little discussion along these lines that I wish I could find (it's in my bookmarks, but if you saw them, you'd know why I'm never going to find it again!), and it boiled down to essentially these concepts: If you're doing a background task, don't alert the user. If you have to connect to a remote server (like anti-virus software might), don't whine when you can't connect. Try later. Only alert the user to critical errors and even then, try to resolve the problem.
However, it's also important to follow another concept that I learned as a programmer: Follow the "Principle of Least Surprise." You can imagine what that implies. If the user performs and activity
it should not surprise them! From what you've described of their office productivity stuff, it sure seems like they're violating this principle in almost every package! Jeez...
Turus wrote:Techs that love to talk about what they are doing would be better served by not using their jargon to describe what it is they are fixing/breaking.
There's three schools of thought in regards to this, and I'm not sure which is best. I suppose it depends on context.
1) Explain changes to the users in terms they can understand. I'd imagine this is important if you're upgrading software or changing the user-facing side of it.
2) Explain very little. Be vague and say "We'll be taking the system down for a couple of hours to perform routine maintenance."
3) Explain nothing. Useful if the users aren't likely to notice anything.
Here is some commentary related to how this might apply in an enterprise.
#1 is obviously most useful in cases where user-facing things are going to change noticeably. Of course, the problem with approach #1 is that the users will likely blame every problem they could possibly ever encounter, including the death of their beloved $housepet due to $stupidity, on these changes. The dialog might go something like this:
User: "I can't get my e-mail."
BOFH: "It shows it in your box."
User: "It just won't work ever since you guys upgraded the mail server."
BOFH: "The logs say you're getting it."
*IT guy takes a trip to the user's office only to discover that the user had forgotten to scroll down to read new mail*
#2 is a nice balance between #1 and #3. It provides ample warning to users but explains nothing about the systems that are about to be changed. I imagine that this approach is best to use when 1) the downtime to make necessary changes is going to be lengthy and noticeable to end users and 2) is vague enough about what activities are being performed so the users can't immediately assume that something won't work. Of course, that isn't going to stop them. Imagine a dialog like this:
User: "I can't get my e-mail ever since you guys did maintenance yesterday. What did you break?"
BOFH: "We were upgrading the security system for the server room. We didn't touch the mail server."
User: "So why did you take it down?"
BOFH: "We didn't. We just sent out that notice in case we did. Nothing changed."
User: "So why can't I get my e-mail?"
BOFH: "Do you have capslock on?"
User: "...oops."
#3 is handy when performing short tasks that are unlikely to present any kind of interruption. Obviously, this would be incredibly bad practice if you just upgraded everyone from Office 97 to Office 2007 without explaining anything about the UI changes. But, for most minor alterations to the system, what the user doesn't know won't pester you. In this case, support requests simply become part of the routine! Well, unless a system you changed happened to be generating these requests (that's something to consider, too):
User: "I can't get my e-mail."
BOFH: "All right, what's happening?"
User: "It says limited or no connectivity."
BOFH: "Did you unplug the ethernet cable again?"
User: "I didn't touch it."
BOFH: "I can't see your system on the network."
User: "Okay, maybe I touched it a little."
BOFH: "A little?"
User: "Is the little plastic tab supposed to come off?"
BOFH: "I'll send someone to swap cables. Please don't touch it again."