Am I the only person in the world who has trouble getting Dropbox docs to sync? I mean, I have them here, I don’t have them there. I look up the problem online, and while there’s answers to obvious usage issues, e.g., wrong user info, there’s not even a hint that, if you have everything set up correctly, you won’t be able to see the file you were working on this morning at the DJ in the folder where you left it when you’re looking for it at the Chez.
Aaaaarrgh!
This one drove me crazy for days. And it was multiple files from different apps. And they were definitely being saved in Dropbox.
The solution? Threaten its life with a railway share. I started syncing files to my Amazon cloud drive instead of using Dropbox, and suddenly Dropbox got that message that, if it didn’t behave, it was going to suffer. It was going to be abandoned and left for dead. In response, it started showing all the files again.
This is not the first time this approach has solved a computer problem. It is, as far as I’m concerned, step two when step one (turn it off and turn it back on again) doesn’t work. Computer stuff doesn’t mind getting a little shirty every once in a while, but those are the times when you’ve got to show it who’s the boss. That is, you’ve occasionally got to put your applications in their place. When you do, they quiet down and go back about their business. I’m not quite sure what the technical processes behind all of this are, but I assure you, this is exactly how it works.
Go figure.
I’ve been thinking about systems and computers in general lately, for reasons unrelated to forensics, but that’s not going to stop me. The business of systems and computers has changed dramatically over the years. It used to be assumed that the users knew nothing and that you had to train them in everything, including where to sit. Over the years, as computers more and more became a part of the average person’s life, the assumption was that people marginally knew what they were doing, and you didn’t have to train them quite so much anymore. Hence the elimination of manuals, for instance, and the assumption that everyone in the office knows every button to press in Office. At the same time, the IT person’s belief that, at bottom, users are pretty much dumber than a box of rocks and really don’t know what they are doing, has endured, remaining the sort of thing the IT folks would all laugh about when they hung out at bars together getting drunk and telling stupid-user stories. In the end, the IT best practices nowadays are, in a word, not so best. The arrogance that the user is, at heart, ignorant, means that, for instance, all corporate software upgrades except the ones that can’t be hidden are, indeed, hidden. The users won’t even notice it, is the assumption. Systems that used to be beaten up in beta, tested to within an inch of their lives, in a universe when you had to tear it out of the programmer’s hands when it was 99% perfect because they wanted to spend the next year ironing out the 1%, have been replaced with launches that are maybe 50% there, and we’ll handle the problems via the help desk half a globe away. One of the standard launch issues, because users are not factored into usage analysis anymore, is that the system only works for the IT folks who happen to have special rights over the system. The average user can’t get the thing to even turn on, and the IT folks laugh at the stupid users, but the problem is that to turn the thing on, you need to be an admin and the admins were too stupid to set turn off their admin rights when they were testing it, if they even bothered to test it. This is what users complain about when they hang out in bars together telling stupid-IT stories.
Of course, this is only relevant in DJ-type situations, but don’t forget, I live in a DJ-type universe. The bottom line is, software (and hardware) is for users, not programmers, not systems analysts (both of which I’ve been, to some extent or another). Really good designers give users what they need, not necessarily what they want, and then they make sure that those users see the benefits of having their needs satisfied and can, in fact, satisfy those needs. Any program that is not clear to the intended user is simply not clear by definition, even if it’s perfectly clear to the designer. If I make you a car that you can’t drive, I might want to blame you for your thick-headedness but, at the same time, I’m not bloodly likely to sell you that car. Who loses in the end?
We return you now to our regularly scheduled program.
No comments:
Post a Comment