Are End Users to Blame for OS Flaws?

tomsHH writes to mention OSWeekly author Brandon Watts claims that really it is end users who should be blamed for many OS flaws. "Believe it or not, as users, we also have a large role to play in the evolution of an operating system. We use what's been created, and this means that we're the best people to turn to for judging what works and what doesn't. Passionate communities that are supportive aid development, and when users join their efforts to make their voices heard, this benefits everyone. Have you ever thought that if you wanted something to be improved, then maybe you should just speak up and offer a solution instead of quietly or publicly venting without offering any input? Nothing changes by staying the same. Companies are listening, and as taboo as it may seem, most of them want to make their users happy, so if you shout loud enough, you're bound to be heard. If you need proof of this, then just look at how Linux has progressed in its development."

Comments

Once you call it an OS flaw

[roman_mir]

Doesn't an OS flaw mean OS problem by definition, rather than user problem?
Are /. users responsible for seeing this message I just saw: Nothing for you to see here. Please move along?

We've been complaining about that message for quite some time now, it didn't go away.

NO

[packeteer]

Short Answer: No

Why would the end user be responsible? That's just silly. With that outlook Linux is going nowhere, thankfully most people will agree that this is crazy.

They don't constructively gripe?

[Mr Pippin]

I can't speak for others, but EVERY time I call support, I let them know if I think this was a crappy design, or oversight.

If it's a common issue, there will be plenty of people that do the same. The REAL issue, I think, is that the organizations I see DON'T use customer support calls as places to look for ways to improve the product.

I think most companies just see support as a neccesary evil, and not an easy way to see what your customers are wanting.

Re:They don't constructively gripe?

[drinkypoo]

I can't speak for others, but EVERY time I call support, I let them know if I think this was a crappy design, or oversight.

I do, but most of the time they're just a phone monkey and not only do they not care, but they have no process for forwarding my comments along to anyone who would care. This is of course so that the corporate masters get all the input into telling them what to do, and they do listen to some people - people with lots of money who are more important to their bottom line than I am because they are purchasing thousands of seats (or what have you.)

There is nothing to gain by telling some dude in Hindustan what I think of the rubber caps on HP's laptop... I realize that's a hardware product, but the point stands.

Re:They don't constructively gripe?

[ArsonSmith]

10 years ago I was a Phone Monkey for HP's Pavilion line of PCs, and everything you say was very true back then. Except for the fact that I did care. I would typically agree with people on design flaws of Windows 95. Help with work arounds that I had learned as well as take feedback from workarounds that they have used. The only people that benefit from this was me and the people that called me. HP didn't care. I was graded only on how quickly I could get them off the phone without having a strong probability of them calling back. I didn't stay long and moved on to a Linux sysadmin job shortly afterwards. Never really looked back on windows.

Too many voices

[Eccles]

I work on a program with somewhere between 100,000-400,000 users. That's a relatively small market compared to OSes. Even with relatively few users, there's far too many voices for suggestions to listen to. Users ask how to submit wishes, but it's really not worth it for us to make it easy. There's already far too many wishes just from our beta testers, not to mention that many requests are either contradictory, would break the database model we've developed, or are in fact already in the program and they just haven't realized it. And that's not counting the fact that my fellow developers, marketers, and I have our own "brilliant" ideas on how to best improve the program.

So I can't see blaming the users; I couldn't listen to all of them even if they were trying to tell us about their problems.

Re:Too many voices

[forkazoo]

I work on a program with somewhere between 100,000-400,000 users. That's a relatively small market compared to OSes. Even with relatively few users, there's far too many voices for suggestions to listen to. Users ask how to submit wishes, but it's really not worth it for us to make it easy. There's already far too many wishes just from our beta testers, not to mention that many requests are either contradictory, would break the database model we've developed, or are in fact already in the program and they just haven't realized it. And that's not counting the fact that my fellow developers, marketers, and I have our own "brilliant" ideas on how to best improve the program.

So I can't see blaming the users; I couldn't listen to all of them even if they were trying to tell us about their problems.

This is certainly a fair point -- too many cooks spoil the borth and all that. But, it still may be a valuable idea if you can set up a filtering process. If you have some sort of community forum, you might be able to set up a "mockup screenshot contest" where users can imagine a new feature with a screenshot walkthrough of how it should work. Then, let other users vote on which ideas they find most interesting. Every month, during a development meeting, everybody looks at the highest rated idea, or five ideas or whatever, and see if it is worth implimenting or adding to a roadmap, or whatever.

This way, you don't have to deal with 400,000 piddly complaints, but you can still notice if half your customer base is demanding a particular feature.

Informed Consumers

[Saxerman]

I went kicking and screaming from an Atari ST and Commodore Amiga user to a PC user. As such I was in the unique position to know the many things I was leaving behind in the transition. To those users moving from Windows 3.1 to Windows 95 everything seemed to be a massive improvement. For me... not so much.

Now Microsoft might not be to blame for the mismanagement of Atari and Commodore, but they are certainly to blame for the massive efforts they have expended on controlling the expectations of their key markets. For more than a decade computer users thought it was perfectly acceptably to use buggy software that crashed often because they didn't know any better. To accuse the end users of not being better educated is a sad excuse that seems short sighted in the extreme. What are they suppose to expect when software that crashes frequently is all they have ever known? Are they suppose to all run off and study the history of computers so they can more critically examine the market and cast better informed economic votes?

I'm certainly not against the idea of having better educated consumers. I can't help but see education doing anything but helping most situations. Yet in most cases people view a computer as an appliance like a toaster or a refrigerator. They don't want to know how it works, they don't want to hear about regular maintenance plans or upkeep schedules. They just want it to work. And I really don't see that as being a horribly unreasonable expectation.

Yeah, stupid end users. NOT.

[postbigbang]

No, instead it's irresponsible coders.

NO ONE SHOULD HAVE TO BE AN OPERATING SYSTEM EXPERT.

Users should use computers as tools. There are responsibilities. But users are hapless. My aunt doesn't have to know about overhead cams to drive to work, and people shouldn't have to know about 64-bit Vista WiFi drivers to logon.

Plainly, some people are irresponsible and you can't catch idiocy no matter how you try-- nothing is foolproof because fools are so ingenious. But OS makers have a hallowed responsibility to make their targeted users both produtive and protected. To say otherwise, is hubris.

Re:Yeah, stupid end users. NOT.

[postbigbang]

Your reply betrays the crux of the problem: arrogance. We expect people to be trained on tool use, not of foundational issues. We make cars safe for them. We should make computers safe for them, too. Easy to understand, easy to navigate. We need to help them, not make them experts in arcane historical misfit problems with operating systems.

Microsoft Shell: Revealed forums

[Foolhardy]

Microsoft tried that late in Vista development at the Shell: Revealed forums. We voiced many concerns, only a few of which got any attention, much of it hand-waving. No one from MS has posted there in a while now, so users have stopped too. A post about the new backup program, sdclt.exe and how much functionality it lacks compared to the old one, ntbackup.exe, was even deleted.

Someone at Microsoft thought it would be a good idea to get some public feedback on Vista development. Late, but good. But then, they didn't listen to our feedback. Some of the stuff we brought up should have been pretty easy to fix, but was blown off instead.

Re:answers:

[r3m0t]

"The people who can't figure out or don't understand what's being asked of them in that dialogue are the same users who likely won't notice or mind the application eating up a little more disk space to save them a headache later."

What if somebody sent them a csv file and needs to recieve a csv file back? What if the csv file will be input to some other application? The user and Excel aren't just in a vacuum where Excel can use whatever format it likes.

"a dummy mode that's toggled on by default isn't necessarily a bad thing when dealing largely with dummies."

Except when a dummy asks me for help and the whole UI is different because I'm not a dummy. Or they need to do something and the option simply isn't there. Or they need to do something in non-dummy mode and never turn it off and then get confused. Or they just think they're not a dummy, although they actually are.

Microsoft isn't listening

[slackmaster2000]

I found a bug recently in an administrative template that shipped with the initial release of Office 2007. I spent a lot of my own time determining that there was a bug, and exactly what it was. I *fixed* the bug.

I went to Microsoft to report the bug and offer the fix. Unfortunately, I couldn't find the front door. There was one little door off to the side, but the bouncer wanted almost $200 to get through it. I found a large group of people congregating in the parking lot around a few guys with "MVP" badges. Figuring that the MVPs must be representing the company somehow, I told one of them about the problem. He repeated everything I said back to him, and then read something out of a manual. I explained to him that I wasn't having trouble understanding how the software was supposed to work, but I was there to report that the software was not working as documented. He repeated everything I had just said, then everything he had previously said, then everything I originally said, and then asked me about my network settings. I said, "no no, you don't understand. Here's the problem, and here is the fix." I handed him a copy of the exact instructions to fix the problem, and awaited his response. Perhaps a big smooch on the cheek and a check for $50!? No, he just stared off blankly for a while and then started asking some other guy for his network settings. "Click start. Click run. Enter cmd and press enter. Type ipconfig /all..."

I was a little disappointed that I didn't even get a hug or anything for solving a problem for the company who I had just given 24,000 dollars to earlier in the year, but I went away certain that the trustworthy MVP personally delivered my complaint to the proper executives once he had ascertained his daily quota of network settings. I mean, the MVPs can get past the bouncer, right? Of course, of course.

You know, sometimes bitching on the web 2.0 is all we got.

Re:answers:

[dgatwood]

My point is that with proper caching, there's no reason for undo/redo to not save a change log on the fly, then rewrite the final revision and reverse patch on close. You mentioned that Office does this. So does AppleWorks. Every app should work this way. If an OS-level service made it easy, more apps would do so. As it stands, I can count the apps tht do this on one hand. In fact, I believe between your post and this one, that's all the apps I know of. Okay, a few command-line tools like vi. With modern drives, for most applications, there's no reason not to write each change to disk. Let the OS batch the changes and write them when it has a whole block full of diffs.

As for your assertion that the VFS layer is the wrong layer, I disagree. The block layer, however, would be completely inappropriate because data changes to files do not tend to be block oriented. Diffs (in binary or text form) have to handle the notion of data sliding, which doesn't work optimally if you are looking at only a single block of data at a time. Thus, block layer versioning would only work reasonably for very limited file formats like disk images, and even then, would be suboptimal in terms of wasting space.

The best way to do it, IMHO, would be to support existing apps with "legacy I/O" (read/write system calls and variants thereof) in the most lightweight way possible, then do something completely different for apps that want control over versioning. It definitely can't be a per-write operation, as writes can have dependencies on nearby writes that can occur earlier or later. Thus, you'd probably just have to commit changes on close for apps that aren't versioning-aware.

You'd also have problems with apps that mv one file on top of another, which is why you would have to intercept those operations in the VFS layer and do a merge of the versioning data. Otherwise, viruses could completely subvert the whole system by writing a file and renaming it over top of another file and the whole history would go away. The only way to keep this out of the VFS layer would be to make it restricted to a single filesystem, which in my experience is the best way to guarantee that it never gets adopted by anyone....

For supporting new applications, most of the work would move out of the kernel and into the application level, but with significant integration with the kernel versioning bits (specifically, asking the kernel to check in a new top of tree version). The ideal design would be for the app to choose its access mode: block mode, structured mode, or text mode. Block mode would support data that will not typically change in length and shift data around, e.g. a disk image. It might either use binary diffs or a block log. Either way would work acceptably, but for performance reasons, block logs would probably be the better choice. In text mode, everything would be represented with text diffs.

The more interesting mode, though, is structured mode. In structured mode, everything would be represented with an XML schema. In effect, this would separate the data structure from the application itself, leading to more open file formats. Ideally, it should be possible through language constructs to tie member variables in C++ classes to values in the structured content so that changes to the values result in changes in the external representation.

This would essentially makes changes to the structure of the data a matter of recording the operations, doing diffs of long strings, etc. In that mode, the app would have a "commit change" call to save a new version. It would be up to the app to decide whether to commit after each change or wait until someone hits "save". For that matter, you could even have a "conditional commit" call that could be rolled back. Not sure how useful that would be, but it seems like a reasonable thing to add.

One more thing. In addition to a top-of-tree cache, it would be absolutely necessary for the initial revision to exist as a complete file. Otherwise, there are cases where an entire file could be lost due to a poorly timed power failure or an application attempting to subvert checking in the head revisioin using the private APIs used by the libc bits.