Статья: Ten Most Wanted Design Bug
>Хотя лично меня впечатлили только и тебя раздражают серые менюшки? 
IMHO бред сивой кобылы 
достали
Прекраснейший список. Очищает мозги от мыслей типа "Ну типа везде такой хуйовый УИ, нах мне делать по другому". Особенно про серенькие менюшки. Да. Ну и вообще.
Прекрасный текст!
Прекрасный текст!
По поводу первого полностью согласен.
Про "persistancy" я, кажется, уже здесь заводил разговор.
Равно как и про версионную файловую систему.
А вот в третьем злостно обманывают:
в моём EvilWM/X нет недоступных "серых пунктов."
---
...Я работаю антинаучным аферистом...
Про "persistancy" я, кажется, уже здесь заводил разговор.
Равно как и про версионную файловую систему.
А вот в третьем злостно обманывают:
в моём EvilWM/X нет недоступных "серых пунктов."
---
...Я работаю антинаучным аферистом...
> в моём EvilWM/X нет недоступных "серых пунктов."
это ещё не значит, что тебя не наебали
это ещё не значит, что тебя не наебали
А на русском можжно?
Оставить комментарий
Marinavo_0507
Источник: http://www.asktog.com/Bughouse/10MostPersistentBugs.htmlПрикольный список проблем, которые воспринимаются как законы природы.
Хотя лично меня впечатлили только и Last update: Sat, Nov 27, 2004
Welcome to the Over the Hill Gang, design bugs that have been around so long that we've begun to think of them as folk heros. However, the usual requirement for turning a public enemy into a folk hero is death, not longevity, and so it should be for these worthies: Their executions are long overdue.
These bugs aren't necessarily fatal. The are all at minimum highly irritating, and they have all survived for a minimum of five years or five product release cycles, whichever came first.
In some cases, the bugs have outlasted the original developers, persisting so long that their successors may not even realize they are bugs—they seem the result of "natural laws." In other cases, the developers know these bugs full well, but refuse to address them. These all need to be addressed, and that address should be far out of town.
ONE.
Bug Name: Power Failure Crash
Duration: >30 years
Supplier: Desktop computer manufacturers
Alias: "Oh, Sh--!"
Product: Desktop computers worldwide
Bug: If the computer loses power for more than a few thousanths of a second, it throws everything away.
Class of error: "That's the way Grandpa did it..."
Principle: Protect the User's Work
Discussion: Somehow, the most destructive act a computer can carry out, other than destroying the contents of a hard disk, got "grandfathered in." Somehow it became OK for computers to just die if the power fails.
If cars modelled this behavior, you might drive your car from New York to Miami, run out of gas in Fort Lauderdale, 10 miles from your destination, and suddenly find yourself back in New York.
Immediate Fix: Web Developers
Store (encrypted) information in cookies even before transfer to the server, so information is preserved from all but the most serious "melt-downs."
Proposed Fix: Application Developers
Convert your existing software and write new software to perform Continuous Save, so users cannot lose more than the last few characters typed or gestures entered. Do not fail to provide sufficient Undo and Revert facilities enabling users to get back to where they were before they started doing the wrong thing.
For all the drawbacks of the crude system most applications have had until now, one advantage was that new drafts did not take the place of old until we said so.
Oh, and by the way, a dialog saying, "This action cannot be undone. OK Cancel," is not a suitable substitute for a Revert facility for anything at any time.
Proposed Fix: OS's
Build support for Continous Save and Revert into the toolbox.
Proposed Fix: Computer Hardware
Add very short term batteries or tantalum capacitors to systems with volatile memory with enough power to dump the memory to disk and go into hibernation, perhaps 30 to 45 second worth.
Bug first observed: 1976
Observer: Tog
Bug reported to Apple: 5 Mar 1985. Quote from that memo:
The age of computers that die when the power goes off will fade to an interesting footnote in history, just as radio gave way to TV. The question is not whether Apple will [address the problem], but when. I believe the time is now....We
have the opportunity to add another dimension to computers; let us take it.
Should happen any day now...
Bug on list since: List inception: 1 Dec 2004
TWO
Bug Name: The Macintosh Dock
Duration: Four and counting
Supplier: Apple Computer, Inc.
Alias: "The Cool Demo"
Product: Mac OS X
Bug: There are actually nine separate and distinct design bugs in the Dock, probably a record for a single object. You can read about them all in my Article, "The Top 9 Reasons the Dock Still Sucks."
Class of error: Confusing a demo with a product
Principle: Demos and products are two separate entities. The Demo's purpose in life is to help sell the product. The product's purpose is to serve the user.
Proposed Fix: Leave the Dock just as is. It looks great on stage during presentations; it looks great in the store. However, allow the user a graceful way to turn it off once it's shortcomings become apparent, substituting instead less flashy looking tools with real power behind them.
Discussion: It's not that the Dock sucks so much as a productivity tool as it is that Apple threw away so many more powerful, useful objects in its favor. These, in an updated, extended form, should be returned.
For an article on how Mac users can "repair" these design flaws by themselves, using third party shareware, see my "Make your Mac a Monster Machine."
Bug first observed: January, 2000
Observer: Tog
Bug reported to supplier: January, 2000
Bug on list since: List inception: 1 Dec 2004
THREE
Bug Name: Mysteriously dimmed menu items
Duration: 25 years
Nickname: "Dimmed & Dimmer" or "Gray Doubt" [try saying it out loud]
Supplier: Apple, Microsoft, Sun, Linux, et. al.
Favorite Saying: "Ha, ha!" [in the manner of Nelson on the Simpsons]
Product: All GUIs
Bug: Designers offer no way for users to discover why a given menu or option has been dimmed (grayed out nor how to turn it back on.
Class of error: Users are teased with options that they cannot access without guessing what was in the designer's mind
Principle: Interfaces should be fully explorable. Users should never have to guess at what unusual confluence of factors will enable them to take advantage of a given capability of a website, application, or system.
Proposed Fix: Make grayed-out objects clickable, revealing what has caused the object to be dimmed and what the user can do about it.
Discussion: This design bug has hung around since the work at Xerox Parc that laid the foundation for the Mac and the machines that followed.
In the earliest days, systems did very little, offering, therefore, few options. It did not take users long to understand that the reason Print was dimmed was because there was no document open to print. Then things got complicated.
Today, it can take users upwards of an hour to even a few days to figure out why an option is dimmed, often involving calls to the vendor. Too often, the vendor doesn't know either.
This bug has been ignored for too long and it has reached a critical point. Too often, an item on the File menu, for example, is dimmed because of some interaction on the fourth menu over, one that has no apparent logical connection with the File menu or item being dimmed, at least not in the user's world.
The software "knows" why it has dimmed the item. Some decision or decisions led to the flag being set. At the same time as the flag is set, the reason why should be made available. If the user clicks on a grayed-out option, the reason or reasons should be made known. And none of those, "Gosh, Oh, Gee, it could be any one of these 14 reasons or maybe something else" messages. The message needs to be intelligen