Cero'@十一月 19th, 2006

进行 Web 界面原型设计常用的工具如下：

1. 白纸、铅笔、橡皮，有时候还需要剪刀。可惜大部分情况下保真度不高而且难以表述页面流程；
2. Word，可以制作 wireframe，还可以批注或者加大段文字说明。可以在一定程度上表述页面流程，但是依赖于文字功底；
3. PPT，使用起来比较麻烦，但是可以动态的表达出交互流程，可惜文字表达能力不足；
4. Flash，同 PPT，更加难以使用。适合制作小屏幕界面原型；
5. HTML，本文就是想讲如何使用 HTML 快速进行 Web 界面原型设计。

HTML 作为 Web 的基础，也是大部分项目开发过程中，设计师最终要向程序员提交的成果。使用 HTML 进行原型的设计，有相当大的优势在于可以节省一些制作的时间。但是这里面还是遇到几个问题：设计师如何管理 HTML 文件？最后提交给程序员后，如果要修改怎么办？因为大部分情况下，HTML 一旦交付，可能就四分五裂不成样子了。要修改的话可能要先改设计稿，好了之后再次提交给程序员，同时程序员要确认哪里修改了，哪几个文件修改了。如果使用 SVN 来协同开发，情况还好一些，但是设计师就要花上一段时间来理解程序结构。

我常戏称这种方法为页面驱动型开发，因为在开发前（确切说是编码前）大部分工作是处理界面、交互，并且制作出高保真的 HTML 页面原型。它基于 Web 标准设计，完全分离结构和表现，这样当程序员在原型基础上进行编码的同时，设计师可以进一步完善 UI 设计，而只用到 CSS 文件和 images 文件夹。通常情况下需要 CVS 或 SVN 的支持。

这种高保真的 HTML 页面原型，包括：

• 页面布局和内容：一致的布局和界面上的文字（与用户的对话），不包括详细的 UI；
• 页面流：页面原型上所有链接可点，并且可理解，比如 href="/posts/add" 这样的链接；
• 提示信息：利用 JS 模拟用户操作，有成功操作或失败操作的提示；
• 小元素：比如弹出小窗口的提示和帮助等。

这样的原型交付给程序员，相信他也会相当的开心的 :D，不会因为页面去向不明或者缺少提示等而询问产品经理或者设计师，因为实际操作一下就明白了。

在设计这样的原型时，主要的思想是 MVC。因为一开始程序员在编码前会有一份代码设计的文档，包括一些约定和类的设计。设计师可以借助这份文档一瞥程序结构。以 Blog 管理后台为例，如 Posts 具有 add、edit、list、del 等功能。那么在本地就可以相应的建立 Posts 目录，目录下分别新建 add.html、edit.html、list.html 和 del.html 页面。现在设计师通常也配有 IIS 或者 apache 用来调试。那么在省略扩展名的情况下，我们就可以通过 http://localhost/blogadmin/posts/add 来测试添加 post 的页面。这与后期程序约定是一致的。

接下来我们要统一页面的布局（layouts）。以 CakePHP 这个 PHP 框架为例，布局模版一般放在 \app\views\layouts 下面。一般是默认的 default.thtml。仿照这个结构，在原型设计根目录下设 Posts、Categories、Comments 和 Layouts 等目录。统一的小代码块放在 Elements 目录下。

目录理清楚后，接下来就是如何连接起来。这里用到了 SSI(Server Side Include)，可以用简单的注释实现文件包含、代码重用。只需使用例如 <!--#include virtual="/path/to/file" --> 的代码就可以包含文件。为什么不直接使用 PHP 的 include？显然让设计师学习 PHP 有些困难，而这种注释形式的“程序”更加容易理解。

为了让所有的页面使用同一个布局，我们用到了系统变量 $QUERY_STRING，即 URL 中的查询字符串，比如 http://example.com/?home，那么 $QUERY_STRING=home。有了查询字符串，布局的问题就解决了，URL 统一的问题也能够解决。

在原型设计的根目录下新建简单的 index.html 文件，加入 <!--#include virtual="/layouts/default.html" -->，也可以直接用 index.html 作为统一布局文件。然后在 /layouts/default.html 文件中加上统一的布局代码，动态变化的区域用 <!--#include virtual="$QUERY_STRING.html" --> 代替。之后你就可以通过 http://localhost/blogadmin/?posts/add 来测试添加 post 的页面（$QUERY_STRING=posts/add）。虽然与之前的 URL 不同，但是已经基本一致了。如果你是一个完美主义者，可以配一下 mod_rewrite，可以实现完全的 friendly URLs。

基本上就是如此，最后不要忘了 JS 的小提示、重用代码的整理。在原型设计的过程中可以不断地和程序员沟通，了解他的需求，这样子可以减少不少后期的沟通成本和返工的情况。

====转自http://www.junchenwu.com/2006/11/a_method_of_using_html_to_design_web_prototype.html＝＝
＝＝＝http://www.junchenwu.com/===

Chapter 4: Affordances and Metaphors

Developing a user interface where the program model matches the user model is not easy. Sometimes, your users might not have a concrete expectation of how the program works and what it's supposed to do. In these cases, you are going to have to find ways to give the user clues about how something works. With graphical interfaces, a common way to solve this problem is with metaphors. But not all metaphors are created equal, and it's important to understand why metaphors work so you know if you've got a good one.

The most famous metaphor is the "desktop metaphor" used in Windows and the Macintosh. You have these little folders with little files in them, which you can drag around. You can drag a file from one folder to another to move it. To the extent that this metaphor works, it's because the little pictures of folders actually remind people of folders, which makes them realize that they can put documents into them.

Here's a screenshot from Kai's Photo Soap. Can you guess how to zoom in? 

It's not very hard. The magnifying glass is a real world metaphor. People know what they are supposed to do. And there's no fear that the zoom operation is actually changing the size of the underlying image, since that's not what magnifying glasses do.

A metaphor, even an imperfect one, works a lot better than when you don't have one at all. Can you figure out how to zoom in with Microsoft Word?

Word has two tiny magnifying glasses in their interface, but one of them is on the "Print Preview" button (for some reason), and the other is on the "Document Map" button, whatever that is. The actual way to change the zoom level here is with the dropdown box that is currently showing "100%". There's no attempt at a metaphor, so it's harder for users to guess how to zoom. This is not necessarily a bad thing; zooming is probably not important enough in a word processing application to justify as much screen space as Kai gives it. But it's a safe bet that more Kai users will be able to zoom in than Word users.

A metaphor, badly chosen, is worse than no metaphor at all. Remember the briefcase from Windows 95? This cute little icon occupied a square inch or so on everybody's desktop for a few years until Microsoft realized that nobody wanted one. And nobody wanted one, because it was a broken metaphor. It was supposed to be a "briefcase", where you put files to take home. But when you took the files home, you still had to put them on a floppy disk. So, do you put them in the briefcase or on a floppy disk? I'm not sure. I don't understand the briefcase. I could never get it to work.

Affordances

Well-designed objects make it clear how they work just by looking at them. Some doors have big metal plates at arm-level. The only thing you can do to a metal plate is push it. In the words of Donald Norman, the plate affords pushing. Other doors have big, rounded handles that just make you want to pull them. They even imply how they want you to place your hand on the handle. The handle affords pulling. It makes you want to pull it.

Other objects aren't designed so well and you can't tell what you're supposed to do. The quintessential example is the CD jewel case, which requires you to place your thumbs just so and pull in a certain direction. Nothing about the design of the box would indicate how you're supposed to open it. If you don't know the trick, it's very frustrating, because the box just won't open.

The best way to create an affordance is to echo the shape of the human hand in "negative space". Look closely at the (excellent) Kodak DC-290 digital camera, shown here front and back:

On the front, you can see a big rubber grip which just looks like your right fingers fit there. Even smarter, on the back, in the lower left corner, you can see an indent which looks uncannily like a thumbprint. When you put your left thumb there, your left index finger curls snugly on the front of the camera, between the lens and another rubber nubbin. It provides a kind of comforting feeling you haven't felt since you sucked your thumb (and curled your index finger around your nose). 

The Kodak engineers are just trying to persuade you to hold the camera with both hands, in a position which ensures that the camera will be more stable and even keeps stray fingers from blocking the lens by mistake. All this rubber is not functional, its sole purpose is to encourage you to hold the camera correctly.

Good computer UI uses affordances, too. About ten years ago, most push buttons went "3D". Using shades of grey, they appear to pop out of the screen. This is not just to look cool: it's important because 3D buttons afford pushing. They look like they stick out and they look like the way to operate them is by clicking on them. Unfortunately, many web sites these days (unaware of the value of affordances) would rather have buttons that look cool rather than buttons which look pushable; as a result, you sometimes have to hunt around to figure out where to click. Look at this web banner:

The "Go" and "Login" buttons pop out and look like you can click on them. The Site Map and Help buttons don't look so clickable, in fact, they look exactly like the QUOTES label which isn't clickable.

About four years ago, many windows started sprouting three little ridges on the bottom right corner which look like a grip. It looks like the kind of thing somebody would put on a slide switch to increase the friction. It affords dragging. It just begs to be dragged to stretch the window.

Finally, one of the best examples of affordances is the famous "tabbed dialog". Remember the old Mac control panel?

The idea was that you choose one of the icons from the (scrolling) list on the left. As you click on the icon, the right side of the screen changes. For some reason, this type of indirection was incredibly logical to the programmers who designed it, but many users didn't understand it. Among other things, people rarely figured out how to scroll the list to get more than the first 4 control panels. But more critically, most people just didn't understand that there was a connection between the icons and the dialog. The icons actually look like they are one of the choices.

Starting in about 1992, these interfaces started to disappear, to be replaced with a new invention called tabbed dialogs:

Tabbed dialogs are a great affordance. It's really obvious from this picture that you have six tabs; it's really obvious which tab you're on, and it's really obvious how to switch to a different tab. When Microsoft first usability tested the tabbed dialog interface, usability went up from about 30% (the old Mac way) to 100%. Literally every single testee was able to figure out the tabbed dialogs. Given the remarkable success of this metaphor, and the fact that the code for tabbed dialogs is built into Windows and available practically for free, it's a wonder you still see applications which don't take advantage of them. These applications suffer from actual, measurable, real world usability problems because they refuse to get with the program.

Chapter 5: Consistency and Other Hobgoblins

The main programs in the Microsoft Office suite, Word and Excel, were developed from scratch at Microsoft, but others were bought from outside companies, notably FrontPage (bought from Vermeer) and Visio, bought from Visio. The thing these two programs have in common? They were originally designed to look and feel just like Microsoft Office applications.

The decision to emulate the Office UI wasn't merely to "suck up" to Microsoft or to position the companies for acquisition; indeed, Charles Ferguson, who developed FrontPage, does not hesitate to admit his antipathy for Microsoft; he repeatedly begged the Justice department to do something about the Redmond Beasties (until he sold his company to them, after which his position became a lot more complicated). In fact Vermeer and Visio seem to have copied the Office UI mainly because it was expedient: it was easier and quicker than reinventing the wheel.

When Mike Mathieu, a group program manager at Microsoft, downloaded FrontPage from Vermeer's web site and tried it out, it worked a whole lot like Word. Since it worked so much like he expected a program to work, it was easier to use. And this ease of use gave him a favorable impression of the program right off the bat.

Now, when Microsoft gets a favorable impression of a program right off the bat, they shell out $150 million or so. Your goal is probably more modest; you want your customers to get a favorable impression and shell out maybe $39. But it's the same idea: consistency causes ease of use which in turn causes good feelings resulting in more money for you.

It's hard to overestimate just how much consistency helps people to learn and use a wide variety of programs. Before GUIs, every program reinvented the very fundamentals of the user interface. Even a simple operation like "exit" which every program had to have was completely inconsistent. In those days people made a point of memorizing, at the very least, the exit command of common programs so they could exit and run a program they understood. Emacs fanatics memorized ":q!" (and nothing else) in case they ever found themselves stuck in vi by mistake, while vi users memorized "C-x C-c" (Emacs even has its own way to represent control characters). Over in DOS land, you couldn't even use WordPerfect unless you had one of those dorky plastic keyboard templates that reminded you what Alt+Ctrl+F3 did. I just memorized F7 which got you the heck outta there.

Not only that, but small inconsistencies in things like the default typing behavior (overwrite or insert) can drive you crazy. I've gotten so used to Ctrl+Z meaning "undo" in Windows applications that when I use Emacs I am constantly minimizing the window (Ctrl+Z) by mistake. (The funny thing is that the very reason Emacs interprets Ctrl+Z as minimize is for "consistency" with that terrific user interface, csh, the C shell from UNIX.) This is one of those minor frustrations that adds up to a general feeling of unhappiness.

To take an even smaller example, Pico and Emacs both use Ctrl+K to delete lines, but with a slightly different behavior that usually mauls my document whenever I find myself in Pico. I'm sure you have a dozen examples of your own.

In the early days of Macintosh, before Microsoft Windows, Apple's evangelists told everyone that the average Mac user used more different programs to get their work done than the average DOS user. I don't remember the exact numbers, but I believe it was something like 1 or 2 programs for the average DOS user versus twelve programs for a Mac user. The reason was that it was so easy to learn a new program on the Mac because they generally worked the same way.

Consistency is a fundamental principle of good UI design, but it's really just a corollary of the axiom "make the program model match the user model", because the user model is likely to reflect the way that users see other programs behaving. If the user has learned that double-clicking text means select word, you can show them a program they've never seen before and they will guess that the way to select a word is to double-click it. And now, that program better select words when they double click (as opposed to, say, looking the word up in the dictionary), or else you have a usability problem.

If consistency is so obviously beneficial, why am I wasting your time and mine evangelizing it? Unhappily, there is a dark force out there that fights against consistency, and that is the natural tendency of designers and programmers to be creative.

Now, I hate to be the one to tell you "don't be creative," but unfortunately, to make a user interface easy to use, you are going to have to channel your creativity into some other area. In most UI decisions, before you design anything from scratch, you absolutely have to look at what other popular programs are doing and emulate that as closely as possible. If you're creating a document editing program of some sort, it better look an awful lot like Microsoft Word, down to the accelerators on the menu items that you have in common. Some of your users will be used to Ctrl+S for save; some of them will be used to Alt+F,S for save, and still others will be used to Alt,F,S (releasing the Alt key) . Another group will look for the floppy disk in the top left area of the program and click it. All four better work, or your users are going to get something that they didn't want.

I've seen companies where management prides themselves on doing things deliberately differently from Microsoft. "Just because Microsoft does it, doesn't mean it's right," they brag, and then proceed to create a gratuitously different user interface from the one that people are used to. Before you start chanting the mantra that "just because Microsoft does it, doesn't mean it's right," please consider two things:

1. Even if it's not right, if Microsoft is doing it in a popular program like Word, Excel, Windows, or Internet Explorer, then millions of people are going to think that it's right, or at least, fairly standard, and they are going to assume that your program works the same way. Even if you think (as the Netscape 6.0 engineers clearly do) that Alt+Left is not a good shortcut key for "Back", there are literally millions of people out there who will try to use Alt+Left to go back, and if you refuse to do it on some general religious principle that Bill Gates is the evil smurf arch-nemesis Gargamel, then you are just gratuitously ruining your program so that you can feel smug and self-satisfied, and your users will not thank you for it.
2. And don't be so sure it's not right. Microsoft spends more money on usability testing than you do, they keep detailed statistics based on millions of tech support phone calls, and there's a darn good chance that they did it that way because more people can figure out how to use it that way.

To create a good program with a usable user interface, you're going to have to leave your religion at the door, thank you. Microsoft may not be the only company to copy: if you're making an online bookstore, you should probably make sure that your web site is at least semantically the same as Amazon. Amazon keeps your shopping cart around for 90 days. You might think that you are extra-smart and empty the cart after 24 hours. If you do this, there will be Amazon customers who put stuff in your shopping cart and come back two weeks later expecting it to still be there. When it's gone, you've lost a customer.

If you're making a high end photo editor for graphics professionals, I assure you that 90% of your users are going to know Adobe Photoshop, so you better behave a heck of a lot like Photoshop in the areas where your program overlaps. If you don't, people are going to say that your program is hard to use, even if you think it's easier to use than Photoshop, because it's not behaving the way they expect it to.

There is another popular tendency to reinvent the common controls that come with Windows. Don't even get me started about Netscape 6. There was a time when you could tell the programs that were compiled with Borland's C++ compiler because they used big fat OK buttons with giant green checkboxes. This wasn't nearly as bad as Kai's Photo Soap:

Fine, so, it's stunningly beautiful, but the O with a line through it (which actually means "no") reminds me of "OK," and the standard on Windows is to have OK on the left, so I wind up hitting the wrong button a lot. The only benefit to having funny symbols instead of "OK" and "Cancel" like everyone else is that you get to show off how creative you are. If people make mistakes because of Kai's creativity, well, that's just the price they have to pay for being in the presence of an artist. (Another problem with this "dialog" is that it doesn't have a standard title bar which can be used to move the dialog around on the screen. So if the dialog gets in the way of something you want to see in order to answer the question in the dialog, you are out of luck.)

Now, there's a lot to be gained by having a slick, cool-looking user interface. Good graphical design like Kai is pleasing and will attract people to your program. The trick is to do it without breaking the rules. You can change the visual look of dialogs, a bit, but don't break the functionality.

When the first version of Juno was written, it had the standard log on dialog that prompted you for a user name and a password. After you entered the user name, you were supposed to press TAB to go to the password field and type in a password.

Now, this distracted one of the programming managers at Juno, who had a lot more experience with UNIX than with Windows, so he was used to typing user name, then pressing ENTER to jump to the password field (instead of TAB). Now, when you're writing a program targeted at non-expert Windows users, a UNIX programmer is probably not the ideal example of a typical user, but this manager was very insistent that the enter key should move to the next field instead of doing the Windows-standard "OK" thing. "Just because Microsoft does it, doesn't mean it's right," he chirped.

So the programmers spent a really remarkable amount of time writing some amazingly complicated dialog box handling code to work around the default behavior of Windows. (Being inconsistent is almost always more work than just acting like your platform expects you to act). This code was a big maintenance nightmare; it didn't port so well when we moved from 16-bit to 32-bit Windows. It didn't do what people expected. And as new programmers joined the team, they didn't understand why there was this strange subclass for dialogs.

An awful lot of programmers have tried to reimplement various common Windows controls, from buttons to scrollbars to toolbars and menu bars (the Microsoft Office team's favorite thing to reimplement). Netscape 6.0 goes so far as to reimplement every single common Windows control. This usually has some unforeseen bad effects. The best example is with the edit box. If you reimplement the edit box, there are an awful lot of utilities that you don't even know about (like Chinese language editing add-ins, and bidirectional versions of Windows that support right-to-left text) that are going to stop working because they don't recognize your non-standard edit box. Some of the reviewers of the preview release of Netscape 6.0 noticed that the URL box, using a non-standard Netscape edit control, does not support common edit control features like right clicking to get a context menu.

When you find yourself arguing with a anti-Microsoft fundamentalist or a creative graphic designer about consistency, they're apt to quote Emerson incorrectly: "Consistency is the hobgoblin of little minds..." The real quote is "A foolish consistency is the hobgoblin of little minds." Good UI designers use consistency intelligently, and, though it may not show off their creativity as well, in the long run it makes users happier.

Chapter 6: Designing for People Who Have Better Things To Do With Their Lives

When you design user interfaces, it's a good idea to keep two principles in mind:

1. Users don't have the manual, and if they did, they wouldn't read it.
2. In fact, users can't read anything, and if they could, they wouldn't want to.

These are not, strictly speaking, facts, but you should act as if they are facts, for it will make your program easier and friendlier. Designing with these ideas in mind is called respecting the user, which means, not having much respect for the user. Confused? Let me explain.

What does it mean to make something easy to use? One way to measure this is to see what percentage of real-world users are able to complete tasks in a given amount of time. For example, suppose the goal of your program is to allow people to convert digital camera photos into a web photo album. If you sit down a group of average users with your program and ask them all to complete this task, then the more usable your program is, the higher the percentage of users that will be able to successfully create a web photo album. To be scientific about it, imagine 100 real world users. They are not necessarily familiar with computers. They have many diverse talents, but some of them distinctly do not have talents in the computer area. Some of them are being distracted while they try to use your program. The phone is ringing. WHAT? The baby is crying. WHAT? And the cat keeps jumping on the desk and batting around the mouse. I CAN'T HEAR YOU!

Now, even without going through with this experiment, I can state with some confidence that some of the users will simply fail to complete the task, or will take an extraordinary amount of time doing it. I don't mean to say that these users are stupid. Quite the contrary, they are probably highly intelligent, or maybe they are accomplished athletes, but vis-à-vis your program, they are just not applying all of their motor skills and brain cells to the usage of your program. You're only getting about 30% of their attention, so you have to make do with a user who, from inside the computer, does not appear to be playing with a full deck.

Users Don't Read the Manual.

First of all, they actually don't have the manual. There may not be a manual. If there is one, the user might not have it, for all kinds of logical reasons: they're on the plane; they are using a downloaded demo version from your web site; they are at home and the manual is at work; their IS department never gave them the manual. Even if they have the manual, frankly, they are simply not going to read it unless they absolutely have no other choice. With very few exceptions, users will not cuddle up with your manual and read it through before they begin to use your software. In general, your users are trying to get something done, and they see reading the manual as a waste of time, or at the very least, as a distraction that keeps them from getting their task done.

The very fact that you're reading this book puts you in an elite group of highly literate people. Yes, I know, people who use computers are by and large able to read, but I guarantee you that a good percentage of them will find reading to be a chore. The language in which the manual is written may not be their first language, and they may not be totally fluent. They may be kids! They can decipher the manual if they really must, but they sure ain't gonna read it if they don't have to. Users do just-in-time manual reading, on a strictly need-to-know basis.

The upshot of all this is that you probably have no choice but to design your software so that it does not need a manual in the first place. The only exception I can think of is if your users do not have any domain knowledge -- they don't really understand what the program is intended to do, but they know that they better learn. A great example of this is Intuit's immensely popular small-business accounting program QuickBooks. Many of the people who use this program are small business owners who simply have no idea what's involved in accounting. The manual for QuickBooks assumes this and assumes that it will have to teach people basic accounting principles. There's no other way to do it. Still, if you do know accounting, QuickBooks is easy to use without the manual.

In fact, users don't read anything. 

This may sound a little harsh, but you'll see, when you do usability tests, that there are quite a few users who simply do not read words that you put on the screen. If you pop up an error box of any sort, they simply will not read it. This may be disconcerting to you as a programmer, because you imagine yourself as conducting a dialog with the user. Hey, user! You can't open that file, we don't support that file format! Still, experience shows that the more words you put on that dialog box, the fewer people will actually read it.

The fact that users do not read the manual leads many software designers to assume that they are going to have to educate users by describing things as they go along. You see this all over the place in programs. In principle, it's OK, but in reality, people's aversion to reading means that this will almost always get you in trouble. Experienced UI designers literally try to minimize the number of words on dialogs to increase the chances that they will get read. When I worked on Juno, the UI people understood this principle and tried to write short, clear, simple text. Sadly, the CEO of the company had been an English major at an Ivy League college; he had no training in UI design or software engineering, but he sure thought he was a good editor of prose. So he vetoed the wording done by the professional UI designers and added lots of his own verbiage. A typical dialog in Juno looks like this:

Compare that to the equivalent dialog from Windows:

Intuitively, you might guess that the Juno version, with 80 words of instructions, would be "superior" (i.e., easier to use) than the Windows version, with 5 words of instructions. In reality, when you run a usability test on this kind of thing, you'll find that

• advanced users skip over the instructions. They assume they know how to use things and don't have time to read complicated instructions
• most novice users skip over the instructions. They don't like reading too much and hope that the defaults will be OK
• the remaining novice users who do, earnestly, try to read the instructions (some of whom are only reading them because it's a usability test and they feel obliged) are often confused by the sheer number of words and concepts. So even if they were pretty confident that they would be able to use the dialog when it first came up, the instructions actually confused them even more.

Now, Juno was obviously micro-managed beyond all reason. More to the point, if you're an English major from Columbia, then you are in a whole different league of literacy than the average Joe, and you should be very careful about wording dialogs that look helpful to you. Shorten it, dumb it down, simplify, get rid of the complicated clauses in parentheses, and usability test. But do not write things that look like Ivy League faculty memos. Even adding the word "please" to a dialog, which may seem helpful and polite, is going to slow people down: the increased bulk of the wording is going to reduce, by some measurable percentage, the number of people who read the text.

Another important point is that many people are intimidated by computers. You probably know this, right? But you may not realize the implications of this. I was watching a friend try to exit Juno. For some reason she was having quite a bit of trouble. I noticed that when you try to exit Juno, the following dialog pops up:

She was hitting No, and then she was kind of surprised that Juno hadn't exited. The very fact that Juno was questioning her choice made her immediately assume that she was doing something wrong. Usually, when programs ask you to confirm a command, it's because you're about to do something which you might regret. She had assumed that if the computer was questioning her judgment, then the computer must have been right, because, after all, computers are computers where as she was merely a human, so she hit "No."

Is it too much to ask people to read 11 lousy words? Well, apparently. First of all, since exiting Juno has no deleterious effects, Juno should have just exited without prompting for confirmation, like every other GUI program in existence. But even if you are convinced that it is crucial that people confirm before exiting, you could do it in two words instead of 11:

Without the completely unnecessary "thank you" and the remorse-inspiring "are you sure?", this dialog is a lot less likely to cause problems. Users will certainly read the two words, say "um, duh?" to the program, and pound the Yes key.

Sure, the Juno Exit Confirmation dialog trips up a few people, you say, but is it that big a deal? Everyone will eventually manage to get out of the program. But herein lies the difference between a program which is possible to use versus a program which is easy to use. Even smart, experienced, advanced users will appreciate things that you do to make it easy for the distracted, inexperienced, beginner users. Hotel bathtubs have big grab bars. They're just there to help disabled people, but everybody uses them anyway to get out of the bathtub. They make life easier even for the physically fit.

In the next chapter, I'll talk a bit about the mouse. Just like users don't/won't/can't read, some are not very good at using the mouse, so you have to accommodate them.

Chapter 7: Designing for People Who Have Better Things To Do With Their Lives, Part Two

When the Macintosh was new, Bruce "Tog" Tognazzini wrote a column in Apple's developer magazine on UI. In his column, people wrote in with lots of interesting UI design problems, which he discussed. These columns continue to this day on his web site. They've also been collected and embellished in a couple of great books, like Tog on Software Design, which is a lot of fun and a great introduction to UI design. (Tog on Interface was even better, but it's out of print.)

Tog invented the concept of the mile high menu bar to explain why the menu bar on the Macintosh, which is always glued to the top of the physical screen, is so much easier to use than menu bars on Windows, which appear inside each application window. When you want to point to the File menu on Windows, you have a target about half an inch wide and a quarter of an inch high to acquire. You must move and position the mouse fairly precisely in both the vertical and the horizontal dimensions.

But on a Macintosh, you can slam the mouse up to the top of the screen, without regard to how high you slam it, and it will stop at the physical edge of the screen - the correct vertical position for using the menu. So, effectively, you have a target that is still half an inch wide, but a mile high. Now you only need to worry about positioning the cursor horizontally, not vertically, so the task of clicking on a menu item is that much easier.

Based on this principle, Tog has a pop quiz: what are the five spots on the screen that are easiest to acquire (point to) with the mouse? The answer: all four corners of the screen (where you can literally slam the mouse over there in one fell swoop without any pointing at all), plus, the current position of the mouse, because it's already there.

The principle of the mile-high menu bar is fairly well known, but it must not be entirely obvious, because the Windows 95 team missed the point completely with the Start push button, sitting almost in the bottom left corner of the screen, but not exactly. In fact, it's about 2 pixels away from the bottom and 2 pixels from the left of the screen. So, for the sake of a couple of pixels, Microsoft literally "snatches defeat from the jaws of victory", Tog writes, and makes it that much harder to acquire the start button. It could have been a mile square, absolutely trivial to hit with the mouse. For the sake of something, I don't know what, it's not. God help us.

In the previous chapter, we talked about how users hate reading, and will avoid it unless they absolutely cannot accomplish their task. Similarly:

Users can't control the mouse very well.

I don't mean this literally. What I mean is, you should design your program so that it does not require a tremendous amount of mouse-agility to use it right. Top six reasons:

1. Sometimes people are using sub-optimal pointing devices, like trackballs, trackpads, and the little red thingy on a ThinkPad, which are harder to control than true mice.
2. Sometimes people are using mice under bad conditions: a crowded desk; a dirty trackball making the mouse skip; or the mouse itself is a $5 clone which just doesn't track right.
3. Some people are new to computers and have not yet developed the motor skills to use mice accurately.
4. Some people literally will never have the motor skills to use mice precisely, and never will. They may have arthritis, tremors, carpal tunnel; they may be very young or very old; or any other number of disabilities.
5. Many people find that it is extremely difficult to double-click without slightly moving the mouse. As a result they often drag things around on their screen when they mean to be launching applications. You can tell these people because their desktops are a mess because half the time they try to launch something, they wind up moving it instead.
6. Even in the best of situations, using the mouse a lot feels slow to people. If you force people to perform a multi-step operation using the mouse, they may feel like they are being stalled which in turn makes the UI feel unresponsive, which, as you should know by now, makes them unhappy.

In ye olden days when I worked on Excel, laptops didn't come with pointing devices built in, so Microsoft made a clip-on trackball that clipped to the side of the keyboard. Now, a mouse is controlled with the wrist and most of the fingers. This is much like writing, and you probably developed very accurate motor skills for writing in elementary school. But a trackball is controlled entirely with the thumb. As a result, it's much harder to control a trackball to the same degree of accuracy as a mouse. Most people find that they can control a mouse to within one or two pixels, but can only control a trackball to within 3 or 4 pixels. On the Excel team, I always urged people to try out their new UIs with the trackball, instead of only with a mouse, to see how it would feel to people who are not able to get the mouse to go exactly where they want it.

One of the UI elements which bothers me the most is the dropdown combo list box. That's the one that looks like this:

When you click on the down arrow, it expands:

Think about how many detailed mouse clicks it's going to take to choose, say, Times New Roman. First, you have to click on the down arrow. Then, using the scroll bar, you have to carefully scroll until Times New Roman is in view. Many of these dropdowns are carelessly designed to show only two or three items at a time, so this scrolling is none too easy, especially if you have a lot of fonts. It involves either carefully dragging the thumb (with such a small range of movement, it's probably unlikely that this will work), or clicking repeatedly on the second down arrow, or trying to click in the area between the thumb and the down area -- which will eventually stop working when the thumb gets low enough, annoying you even further. Finally, if you do manage to get Times New Roman into view, you have to click on it. If you miss, you get to start all over again. Now multiply by 10, if, say, you want to use a fancy font for the first letter in each of your chapters, and you're really unhappy. 

The poxy combo dropdown control is even more annoying because there's such an easy solution: just make the dropdown long enough to contain all of the options. 90% of the combo boxes out there don't even use all available space to drop down, which is a sin. If there is not enough room between the main edit box and the bottom of the screen, the dropdown should grow up until it fits all the items, even if it has to go all the way from the top of the physical screen to the bottom of the physical screen. And then, if there are still more items than fit, let the combo scroll automatically as the mouse approaches the edge, rather than requiring the poor user to mess with a teensy weensy scrollbar.

Furthermore, don't make me click on the little tiny arrow to the right of the edit box before you pop up the combo: let me click anywhere on the combo box. This expands the click target about tenfold and makes it that much easier to acquire the target with the mouse pointer.

Let's look at another problem with mousing: edit boxes. You may have noticed that almost every edit box on the Macintosh uses a fat, wide, bold font called Chicago which looks kind of ugly and distresses graphic designers to no end. Graphic designers (unlike UI designers) have been taught that thin, variable spaced fonts are more gracious, look better, and are easier to read. All this is true. But graphic designers learned their skills on paper, not on the screen. When you need to edit text, monospace has a major advantage over variable spaced fonts: it's easier to see and select narrow letters like "l" and "i". I learned this lesson after watching a sixty year old man in a usability test painfully trying to edit the name of his street, which was something like Fillmore Street. We were using 8 point Arial, so the edit box looked like this:

Notice that the I and the Ls are literally one pixel wide. The difference between a lower case I and a lower case L is literally one pixel. (Similarly, it is almost impossible to see the difference between "RN" and "M" in lower case, so this edit box might actually say Fillrnore.)

There are very few people who would notice if they mistyped Flilmore or Fiilmore or Fillrnore, and even if they did, they would have a heck of a time trying to use the mouse to select the offending letter and correct it. In fact, they would even have a hard time using the blinking cursor, which is two pixels wide, to select a single letter. Look how much easier it would have been if we had used a fat font (shown here with Courier Bold)

Fine, OK, so it takes up more space and doesn't look as cool to your graphic designers. Deal with it! It's much easier to use; it even feels better to use because as the user types, they get sharp, clear text, and it's so much easier to edit.

---

Here's a common programmer thought pattern: there are only three numbers: 0, 1, and n. If n is allowed, all n's are equally likely. This thought pattern comes from the belief (probably true) that you shouldn't have any numeric constants in your code except for 0 and 1. (Constants other than 0 and 1 are referred to as "magic numbers". I don't even want to go into the gestalt of that.)

Thus, for example, programmers tend to think that if your program allows you to open multiple documents, it must allow you to open infinitely many documents (as memory allows), or at least 2^32, the only magic number programmers concede. A programmer would tend to look with disdain on a program which limited you to 20 open documents. What's 20? Why 20? It's not even a power of 2!

Another implication of all n's are equally likely is that programmers have tended to think that if users are allowed to resize and move windows, they should have complete flexibility over where these windows go, right down to the last pixel. After all, positioning a window 2 pixels from the top of the screen is "equally likely" as positioning a window exactly at the top of the screen.

But it's not true. As it turns out, there are lots of good reasons why you might want a window exactly at the top of the screen (it maximizes screen real estate), but there aren't any reasons to leave 2 pixels between the top of the screen and the top of the window. So, in reality, 0 is much more likely than 2.

The programmers over at Nullsoft, creators of WinAmp, managed somehow to avoid the programmer-think that has imprisoned the rest of us for a decade. WinAmp has a great feature. When you start to drag the window near the edge of the screen, coming within a few pixels, it automatically snaps to the edge of the screen perfectly. Which is probably exactly what you wanted, since 0 is so much more likely than 2. (The Juno main window has a similar feature: it's the only application I've ever seen that is "locked in a box" on the screen and cannot be dragged beyond the edge.)

You lose a little bit of flexibility, but in exchange, you get a user interface that recognizes that controlling the mouse precisely is hard, so why should you have to? This innovation (which every program could use) eases the burden of window management in an intelligent way. Look closely at your user interface, and give us all a break. Pretend that we are gorillas, or maybe smart orangutans, and we really have trouble with the mouse.

Chapter 8: Designing for People Who Have Better Things To Do With Their Lives, Part Three

One of the early principles of GUI interfaces was that you shouldn't ask people to remember things that the computer could remember. The classic example is the Open File dialog box, which shows people a list of files rather than asking them to recall and type the exact file name. People remember things a lot better when they are given some clues, and they'd always rather choose something from a list than have to recall it from memory. 

Another example is the menus themselves. Historically, providing a complete menu of available commands replaced the old command-line interfaces, where you had to memorize the commands you wanted to use. And this is, fundamentally, the reason why command line interfaces are just not better than GUI interfaces, no matter what your UNIX friends tell you. Using a command line interface is like having to learn Korean to order food in a Seoul branch of McDonalds. Using a menu based interface is like being able to point to the food you want and nod your head vigorously: it conveys the same information with no learning curve.

Consider the file selection process in a typical graphics program:

 Luckily, Windows 98 introduced thumbnail support, so you can see the files like this:

This makes it significantly easier to open the file you want; it doesn't even take the mental effort to map words onto pictures.

You can see the minimum-memory principle at work in features like auto completion, too. Even if you need to type something, some programs make educated guesses about what you're about to type:

In this example, as soon as you type "M", Excel guesses that you are likely to be typing Male, because you've typed Male before in this column, and proposes that as the auto completion. But the "ale" is preselected so that if you didn't mean to type Male, you can keep typing (perhaps "ystery") and overwrite Excel's guess with no lost effort.

Microsoft Word gets a little bit carried away guessing what you are about to type, as anybody that has ever used that product during the merry month of May has discovered:

Designing For People Who Have Better Things To Do With Their Lives, Redux

In the preceding chapters, I've brought up three principles:

• Users don't read stuff (chapter 6)

• Users can't use the mouse (chapter 7)

• Users can't remember anything

You might be starting to get the impression that I think that users are dolts. It's not true. Disrespecting your users is how arrogant software like Microsoft Bob gets created (and dumped in the trash bin), and nobody is very happy.

On the other hand, there is a much worse kind of arrogance in software design: the arrogant assumption that "my software is so damn cool, people are just going to have to warp their brains around it." This kind of chutzpah is pretty common in the free software world. Hey, Linux is free! If you're not smart enough to decipher it, you don't deserve to be using it!

Human aptitude tends towards the bell curve. Maybe 98% of your customers are smart enough to use a television set. About 70% of them can use Windows. 15% can use Linux. 1% can program. But only 0.1% of them can program in a language like C++. And only 0.01% of them can figure out Microsoft ATL programming. (And all of them, without exception, have beards and glasses.)

The effect of this sharp drop-off is that whenever you "lower the bar" by even a small amount, making your program, say, 10% easier to use, you dramatically increase the number of people who can use it, say, by 50%.

So, I don't really believe that people are dolts, but I think that if you constantly try to design your program so that it's easy enough for dolts to use, you are going to make a popular, easy to use program that people like. And you will be surprised by how what seem like small usability improvements translate into lots more customers.

One good way to evaluate the usability of a program or dialog you've never seen before is to act a little stupid. Don't read the words on the dialog. Make random assumptions about what things do without verifying. Try to use the mouse with just one finger. Make lots of mistakes, and generally thrash around. See if the program does what you want, or at least, gently guides you instead of blowing up. Be impatient. If you can't do what you want right away, give up. If the UI can't withstand your acting generally immature and stupid, it could use some work.

Chapter 9: The Process of Designing a Product

We've talked about the principles of good design, but principles only give you a way to evaluate and improve an existing design. But... how do you figure out what the dang design should be in the first place? Many people write big, functional outlines of all the features they thought up. Then they design each one, and hang it off of a menu item (or web page). When they're done, the program (or web site) has all the functionality they wanted, but it doesn't flow right. People sit down and they don't know what it does, and they don't know how to accomplish what they want.

Microsoft's solution to this is something called Activity Based Planning. (As far as I can tell, this concept was invented by Mike Conte on the Excel team, who got bored with that and went on to a second career as a race car driver). The key insight is to figure out the activity that the user is doing, and focus on making it easy to accomplish that activity. This is best illustrated with an example.

You've decided to make a web site that lets people create greeting cards. Using a somewhat naïve approach, you might come up with a list of features like this:

1. Add text to card 2. Add picture to card 3. Get predesigned card from library 4. Send card:            a. Using email            b. By printing it out

For lack of any better way of thinking about the problem, this might lead itself to a typical Macintosh user interface, circa-1984: a program that starts out with a blank card, with menu items for adding text, pictures, loading cards from a library, and sending cards. And then what the user is going to have to do is sit down and browse through the menus, trying to figure out all the commands available, and then do their own synthesis of how to put these atomic commands together to create a card.

Now, activity based planning says that you need to come up with a list of activities that users might do. So, you talk to your potential users, and you come up with this "top three" list:

1. Birthday Greeting
2. Party Invitation
3. Anniversary Greeting

Now, instead of thinking about your program like a programmer (in terms of what features you need to have to make a card), you're thinking about it like the user, in terms of, what activities is the user doing, specifically:

1. Sending a birthday card
2. Planning a party, and inviting people to it
3. Sending an anniversary card

Suddenly, all kinds of ideas will rush into your head. Instead of starting with a blank card, you might start with a menu like this:

What do you want to do? Send a birthday card Send an anniversary card Send a party invitation Start with a blank card

Suddenly users will find it much easier to get started with your program, without browsing around on the menus, since the program will virtually lead them through the steps to complete the activity. (There is a risk that if you didn't pick the activities correctly, you will alienate or confuse users who might have been able to use your program, say, to send a Hanukah card, but don't see that as a choice. So be careful in picking activities that blanket the majority of the market you want to target.)

Just looking at our list of three activities suggests some great features which you might want to add. For example, if you're sending a birthday or anniversary card, you might want to be reminded next year to send a card to the same person... so you might add a checkbox that says "remind me next year". And a party invitation needs a way to RSVP, so you might add a feature that lets you collect RSVPs from people electronically. Both of these feature ideas almost fell out of looking at the activity that users were performing instead of the features in the application.

This example is trivial; for any serious application, the rewards of activity based planning are even greater. When you're designing a program from scratch, you already have a vision of what activities your users are going to be doing. Figuring out this vision is not hard at all, it takes almost no effort at all to do some brainstorming with coworkers, write down a list of potential activities, and then decide which ones you want to focus on. But forcing yourself to list these activities on paper will help your overall design enormously. 

Activity based planning is even more important when you are working on version two of a product that people are already using. Here, it may be a matter of observing a sample of customers to see what they are using your program for. 

In the days of Excel 1.0 through 4.0, most people at Microsoft thought that the most common user activity was doing financial what-if scenarios, where you do things like change the inflation rate and see how this affects your profitability. 

When we were designing Excel 5.0, the first major release to use serious activity-based planning, we only had to watch about five customers using the product before we realized that an enormous number of people just use Excel to keep lists. They are not entering any formulas or doing any calculation at all! We hadn't even considered this before. Keeping lists turned out to be far more popular than any other activity with Excel. And this led us to invent a whole slew of features that make it easier to keep lists: easier sorting, automatic data entry, the AutoFilter feature which helps you see a slice of your list, and multi-user features which let several people work on the same list at the same time while Excel automatically reconciles everything.

While Excel 5 was being designed, Lotus had shipped a "new paradigm" spreadsheet called Improv. According to the press releases, Improv was a whole new generation of spreadsheet, which was going to blow away everything that existed before it. For various strange reasons, Improv was first available on the NeXT, which certainly didn't help its sales, but a lot of smart people believed that Improv would be to NeXT as VisiCalc was to the Apple II: it would be the killer app that made people go out and buy all new hardware just to run one program.

Of course, Improv is now a footnote in history. Search for it on the web, and the only links you'll find are from very over-organized storeroom managers who have, for some reason, made a web site with an inventory of all the stuff they have collecting dust.

Why? Because in Improv, it was almost impossible to just make lists. The Improv designers thought that people were using spreadsheets to create complicated multi-dimensional financial models. Turns out, if they asked people, they would discover that making lists was so much more common than multi-dimensional financial models, and in Improv, making lists was a downright chore, if not impossible.

So activity based planning is helpful in the initial version of your application, where you have to make guesses about what people want to do, but it's even more helpful when you're planning the upgrade, because you understand what your customers are doing.

Another example, from the web, is the evolution of deja.com, which started out as an huge, searchable index of Usenet called dejanews. The original interface basically had an edit box and said "search Usenet for blah," and that was it. In 1999 a bit of activity based planning showed that one common user activity was doing research on a product or service, of the "which car should I buy" nature. Deja was completely reorganized, and today, it is more of a product opinion research service: the Usenet searching ability is almost completely hidden. This annoyed the small number of users who were using the site to search for whether their Matrox video card worked with Redhat Linux 5.1, but it delighted the much larger population of users who just wanted to buy the best digital camera.

The other great thing about activity based planning is that it lets you make a list of what features not to do. When you create any kind of software, the reality is that you will come up with three times as many features as you have time to do. And one of the best ways to decide which features get done, and which features get left out, is to evaluate which features support the most important user activities.

Imaginary Users.

The very best UI designers in the industry all agree on one thing: you have to invent and describe some imaginary users before you can design your UI. You may remember back in the introduction to this book, I introduced an imaginary user Pete:

Pete is an accountant for a technical publisher who has used Windows for six years at the office and a bit at home. He is fairly competent and technical. He installs his own software; he reads PC Magazine, and he has even programmed some simple Word macros to help the secretaries in his office send invoices. He's getting a cable modem at home. Pete has never used a Macintosh. "They're too expensive," he'll tell you. "You can get a 700 Mhz PC with 128 Meg RAM for the price of..." OK, Pete. We get it.

When you read this, you can almost imagine a user. I could also have invented quite another type of user:

Patricia is an English professor who has written several well-received books of poetry. She has been using computers for word processing since 1980, although the only two programs she ever used are Nota Bene (an ancient academic word processor) and Microsoft Word. She doesn't want to spend time learning the theory of how the computer works, and she tends to store all her documents in whatever directory they would go in if you didn't know about directories.

Obviously, designing software for Pete is quite different from designing software for Patricia, who in turn is quite different from Mike, a 16 year old who runs Linux at home, talks on IRC for hours, and uses no "Micro$oft" software.

When you invent these users, thinking about whether your design is appropriate becomes much easier. For example, a lot of programmers tend to overestimate the ability of the typical user to figure things out. Whenever I write something about command line interfaces being hard to use, I get the inevitable email barrage saying that command line interfaces are ultra-powerful because you can do things like 'gunzip foo.tar.gz | tar xvf -'. But as soon as you have to think about getting Patricia to type "gunzip..." it becomes obvious that that kind of interface just isn't going to serve her needs, ever. Thinking about a "real" person gives you the empathy you need to make a feature that serves that person's need. (Of course, if you're making Linux backup software for advanced sysadmins, you need to invent a character like "Frank" who refuses to touch Windows, which he only refers to as an "operating system" in quotation marks, uses his own personally modified version of tcsh, and runs X11 with four tiled xterms all day long. And about 11 xperfs.)

To summarize, designing good software takes about six steps:

1. Invent some users

2. Figure out the important activities

3. Figure out the user model -- how the user will expect to accomplish those activities

4. Sketch out the first draft of the design

5. Iterate over your design again and again, making it easier and easier until it's well within the capabilities of your imaginary users

6. Watch real humans trying to use your software. Note the areas where people have trouble, which probably demonstrate areas where the program model isn't matching the user model.

Good UI sells software, but it also makes people happy, because people are happy when they accomplish the task they wanted to accomplish. Which is why UI design is such a satisfying field to be in. Where else are you going to get a chance to make millions of people just a little bit happier?

About the Author: I'm your host, Joel Spolsky, a software developer in New York City. Since 2000, I've been writing about software development, management, business, and the Internet on this site. For my day job, I run Fog Creek Software, makers of FogBugz - the smart bug tracking software with the stupid name, and Fog Creek Copilot - the easiest way to provide remote tech support over the Internet, with nothing to install or configure.

Enter your email address to receive a (very occasional) email whenever I write a major new article. You can unsubscribe at any time, of course.

Chapter 1: Controlling Your Environment Makes You Happy

Most of the hard core C++ programmers I know hate user interface programming. This surprises me, because I find UI programming to be quintessentially easy, straightforward, and fun.

It's easy because you usually don't need algorithms more sophisticated than how to center one rectangle in another. It's straightforward because when you make a mistake, you immediately see it and can correct it. It's fun, because the results of your work are immediately visible. You feel like you are sculpting the program directly.

I think most programmers' fear of UI programming comes from their fear of doing UI design. They think that UI design is like graphics design: the mysterious process by which creative, latte-drinking, all-dressed-in-black people with interesting piercings produce cool looking artistic stuff. Programmers see themselves as analytic, logical thinkers: strong at reasoning, weak on artistic judgment. So they think they can't do UI design.

Actually, I’ve found UI design to be quite easy and quite rational. It’s not a mysterious matter that requires a degree from an art school and a penchant for neon-purple hair. There is a rational way to think about user interfaces with some simple, logical rules that you can apply anywhere to improve the interfaces of the programs you work on. 

I'm not going to give you "Zen and the Art of UI Design". It's not art, it's not Buddhism, it's just a set of rules. A way of thinking rationally and methodically. This book is designed for programmers. I assume you don't need instructions for how to make a menu bar; rather, you need to think about what to put in your menu bar (or whether to have one at all). There is one primary axiom I'll teach you which guides all good UI design, and it's not hard to understand at all.

My first real job was in a big, industrial bakery. The bakery was designed to have six bread production lines. For every two production lines, there was a dough mixer, which produced 180 kg lumps of dough that could be dumped to the left or the right:

Well, this was the design. In reality, Mixer C hadn't been built yet, nor had lines 3 or 5. So the arrangement was:

Alert readers will be wondering, "how did the dough get from Mixer B to production line 6?" Well, that's where Wee Joel came in. My job, if you can believe this, was to stand on the left of Mixer B, then catch the giant 180 kg lumps of dough as they flew out of the mixer in a big bathtub-with-wheels, then roll the bathtub over to production line 6, and, using a winch-like device, heave the dough onto line 6. I had to do this once every ten minutes, from about 10 PM until 4 AM.

There were other complications. Line 6 couldn't really handle 180 kg of dough all at once, so I had to slice it with a giant knife into about 10 pieces. I don't even want to go into how absurdly difficult that was.

The first few days, of course, I was terrible at this job. It seemed nearly impossible. Every bone in my body ached. My blisters had blisters. I had aches in places where I didn't know I had places.

At first I just couldn't keep line 6 supplied with dough. Every time they had an interruption in the dough, this caused a big gap on the assembly line. When the gap rolled into the oven, the oven (expending a constant amount of energy over a reduced amount of dough) started to heat up more, which burnt the bread. Sometimes, line 6 would get gummed up and stop production, but the mixer went right on ahead producing dough for me, and I would run the risk of running out of bathtubs-with-wheels to store the dough in. When this happened, I actually had to clean and oil the floor and dump the dough on the floor to be scraped up later. Not that this would work very well, because if the dough got older than about 30 minutes it would ferment and wouldn't make good bread. If this happened, you had to chop it up into 5 kg pieces and put one piece into the mixture for each future batch.

After a week or so, I got good enough at the routine that I actually had, if I remember correctly, 2 minutes free for every 10 minute dough-cycle to rest. I figured out a precise schedule and learned how to tell the mixer to skip a batch when the production line stopped.

And I started to think about why, as the beer commercial asks, some days are better than others.

One day, thinking about this problem, I noticed that one of the bathtubs-with-wheels had pretty lousy wheels that wouldn't turn well. Sometimes this bathtub did not go where I pushed it, and bumped into things. This was a small frustration. Sometimes, as I was pulling the chain to winch up the bathtub, I scraped myself -- just a little bit -- on a splinter of metal on the chain. Another small frustration. Sometimes, as I ran with an empty bathtub to catch a dough emission about to fly out of the mixer, I slipped on a little bit of oil on the floor. Not enough to fall, mind you, just a tiny, small frustration.

Other times, I would have tiny victories. I learned to time the dough production perfectly so that fresh dough would arrive just seconds before the previous batch ran out. This guaranteed the freshest dough and made the best bread. Some of the victories were even tinier: I would spot a tiny blob of dough that had flung off of the mixer and attached itself to the wall, and I would scrape it off with a paint scraper I carried in my back pocket and throw it in the trash. YES! When slicing the dough into pieces, sometimes it just sliced really nicely and easily. Tiny moments of satisfaction, when I managed to control the world around me, even in the smallest way.

So that's what days were like. A bunch of tiny frustrations, and a bunch of tiny successes. But they added up. Even something which seems like a tiny, inconsequential frustration affects your mood. Your emotions don't seem to care about the magnitude of the event, only the quality.

And I started to learn that the days when I was happiest were the days with lots of small successes and few small frustrations.

Years later, when I got to college, I learned about an important theory of psychology called Learned Helplessness, developed by Dr. Martin E. P. Seligman. This theory, backed up by years of research, is that a great deal of depression grows out of a feeling of helplessness: the feeling that you cannot control your environment.

The more you feel that you can control your environment, and that the things you do are actually working, the happier you are. When you find yourself frustrated, angry, and upset, it's probably because of something that happened that you could not control: even something small. The space bar on your keyboard is not working well. When you type, some of the words are stuck together. This gets frustrating, because you are pressing the space bar and nothing is happening. The key to your front door doesn't work very well. When you try to turn it, it sticks. Another tiny frustration. These things add up; these are the things that make us unhappy on a day-to-day basis. Even though they seem too petty to dwell on (I mean, there are people starving in Africa, for heaven's sake, I can't get upset about space bars), nonetheless they change our moods. 

Let's pause for a minute and go back to computers. 

We're going to invent a typical Windows power user named Pete. When you're thinking about user interfaces, it helps to keep imaginary users in mind. The more realistic the imaginary user is, the better you'll do thinking about how they use your product. Pete is an accountant for a technical publisher who has used Windows for six years at the office and a bit at home. He is fairly competent and technical. He installs his own software; he reads PC Magazine, and he has even programmed some simple Word macros to help the secretaries in his office send invoices. He's getting a cable modem at home. Pete has never used a Macintosh. "They're too expensive," he'll tell you. "You can get a 700 Mhz PC with 128 Meg RAM for the price of..." OK, Pete. We get it.

One day Pete's friend Gena asks him for some computer help. Now, Gena has a Macintosh iBook, because she loves the translucent boxes. When Pete sits down and tries to use the Macintosh, he quickly gets frustrated. "I hate these things," he says. He is, finally, able to help Gena, but he's grumpy and unhappy. "The Macintosh has such a clunky user interface."

Clunky? What's he talking about? Everybody knows that the Macintosh has an elegant user interface, right? The very paradigm of ease-of-use?

Here's my analysis of this mystery.

On the Macintosh, when you want to move a window, you can grab any edge with the mouse and move it. On Windows, you must grab the title bar. If you try to grab an edge, the window will be reshaped. When Pete was helping Gena, he tried to widen a window by dragging the right edge. Frustratingly, the whole window moved, rather than resizing as he expected.

On Windows, when a message box pops up, you can hit enter or the space bar to dismiss the message box.  On the Mac, space doesn't work. You usually need to click with the mouse. When Pete got alerts, he tried to dismiss them using the space bar, like he's been doing subconsciously for the last six years. The first time, nothing happened. Without even being aware of it, Pete banged the space bar harder, since he thought that the problem must be that the Mac did not register his tapping the space bar. Actually,  it did -- but it didn't care! Eventually he used the mouse. Another tiny frustration.

Pete has also learned to use Alt+F4 to close windows. On the Mac, this actually changes the volume. At one point, Pete wanted to click on the Internet Explorer icon on the desktop, which was partially covered by another window.  So he hit Alt+F4 to close the window and immediately double-clicked where the icon would have been. The Alt+F4 raised the volume on the computer and didn't close the window, so his double click actually hit the Help button in the toolbar on the window which he wanted closed anyway, which immediately started bringing up a help window, so now, he's got two windows open which he has to close.

Another small frustration. But, boy, does it add up. At the end of the day, Pete is grumpy and angry. When he tries to control things, they don't respond. The space bar and the Alt+F4 key "don't work" -- for all intents and purposes, it's as if those keys were broken. The window disobeys him when he tries to make it wider, playing a little prank where it just moves over instead of widening. Bad window. Even if the whole thing is subconscious, the subtle feeling of being out of control translates into helplessness, which translates into unhappiness. "I like my computer," Pete says. "I have it all set up so that it works exactly the way I like it. But these Macs are clunky and hard to use. It's an exercise in frustration. If Apple had been working on MacOS all these years instead of messing around with Newtons, their operating system wouldn't be such a mess."

Right, Pete. We know better. His feelings come despite the fact that the Macintosh really is quite easy to use -- for Mac users. It's totally arbitrary which key you press to close a window. The Microsoft programmers, who were, presumably, copying the Mac interface, probably thought that they were adding a cool new feature by letting you resize windows by dragging any edge. The MacOS 8.0 programmers probably thought they were adding a cool new feature when they let you move windows by dragging any edge.

Most flame wars you read about user interface issues focus on the wrong thing. Windows is better because it gives you more ways to resize the window. So what? That's missing the point. The point is, does the UI respond to the user in the way in which the user expected it to respond? If it didn't, the user is going to feel helpless and out of control, the same way I felt when the wheels of the dough bathtub didn't turn the way I pushed them, and I bumped into a wall. Bonk.

UI is important because it affects the feelings, the emotions, and the mood of your users. If the UI is wrong and the user feels like they can't control your software, they literally won't be happy and they'll blame it on your software. If the UI is smart and things work the way the user expected them to work, they will be cheerful as they manage to accomplish small goals. Hey! I ripped a CD! It just worked! Nice software! Wooooooooooo!

To make people happy, you have to let them feel like they are in control of their environment. To do this, you need to correctly interpret their actions. The interface needs to behave in the way they are expecting it to behave. 

Thus, the cardinal axiom of all user interface design:

A user interface is well-designed when the program behaves exactly how the user thought it would.

As Hillel said, everything else is commentary. All the other rules of good UI design are just corollaries.

Chapter 2: Figuring Out What They Expected

When a new user sits down to use a program, they do not come with a completely clean slate. They have some expectations of how they think the program is going to work. If they've used similar software before, they will think it's going to work like that other software. If they've used any software before, they are going to think that your software conforms to certain common conventions. They may have intelligent guesses about how the UI is going to work. This is called the user model: it is their mental understanding of what the program is doing for them.

The program, too, has a "mental model," only this one is encoded in bits and will be executed faithfully by the CPU. This is called the program model, and it is The Law. As we learned in Chapter One, if the program model corresponds to the user model, you have a successful user interface.

Let's look at one example. In Microsoft Word (and most word processors), when you put a picture in your document, the picture is actually embedded in the same file as the document itself. You can create the picture, drag it into the document, then delete the original picture file, but the picture will still remain in the document.

Now, HTML doesn't let you do this. HTML documents must store their pictures in a separate file. If you take a user who is used to word processors, and doesn't know anything about HTML, and sit them down in front of a nice WYSIWYG HTML editor like FrontPage, they will almost certainly think that the picture is going to be stored in the file. Call this user model inertia, if you will.

So we have an unhappy conflict of user model (the picture will be embedded) versus program model (the picture must be in a separate file), and the UI is bound to cause problems.

If you're designing a program like FrontPage, you've just found your first UI problem. You can't really change HTML. Something has to give to bring the program model in line with the user model.

You have two choices. You can try to change the user model. This turns out to be remarkably hard. You could explain things in the manual, but everybody knows that users don't read manuals, and they probably shouldn't have to. You can pop up a little dialog box explaining that the image file won't be embedded, but this has two problems: it's annoying to sophisticated users, and users don't read dialog boxes, either (we'll take more about this in Chapter Six). 

So, if the mountain won't come to Muhammad ... your best choice is almost always going to be to change the program model, not the user model. Perhaps when they insert the picture, you could make a copy of the picture in a subdirectory beneath the document file, so that at least you can match the user's idea that the picture is copied (and the original can be safely deleted).

How do I know what the user model is?

This turns out to be relatively easy. Just ask them! Pick five random people in your office, or friends, or family, and tell them what your program does in general terms ("it's a program for making web pages"). Then describe the situation: "You've got a web page that you're working on, and a picture file named Picture.JPG. You insert the picture in your web page." Then ask them some questions to try and guess their user model. "Where did the picture go? If you delete Picture.JPG, will the web page still be able to show the picture?"

A friend of mine is working on a photo album application. After you insert your photos, the application shows you a bunch of thumbnails: wee tiny copies of each picture. Now, generating these thumbnails takes a long time, especially if you have a lot of pictures, so he wants to store the thumbnails on the hard drive somewhere so that they only have to be generated once. There are a lot of ways he could do this. They could all be stored in one large file called Thumbnails. They could all be stored in separate files, in a subdirectory called Thumbnails. They might be marked as hidden files in the operating system so that users don't know about them. My friend chose one way of doing it which he thought was the best tradeoff: he stored the thumbnail of each picture picture.JPG in a new file named picture_t.JPG in the same directory. If you made an album with 30 pictures, when you were done, there were 60 files in the directory including the thumbnail pictures.

You could argue for weeks about the merits and demerits of various schemes of storing the pictures, but as it turns out, there's a more scientific way to do it. Just ask a bunch of users where they think the thumbnails are going to be stored. Of course, many of them won't know or won't care, or they won't have thought about this, but if you ask a lot of people, you'll start to see some kind of consensus. The popular choice is the best user model, and it's up to you to make the program model match it.

Next, you have to test your theories. Build a model or prototype of your user interface and give some people tasks to accomplish. As they work through the tasks, ask them what they think is happening. Your goal is to figure out what they expect. If the task is "insert a picture," and you see that they are trying to drag the picture into your program, you'll realize that you better support drag and drop. If they go to the Insert menu, you'll realize that you better have a Picture choice in the Insert menu. If they go to the Font toolbar and replace the word "Times New Roman" with the words "Insert Picture", you've found a relic who hasn't been introduced to GUIs yet and is expecting a command line interface.

How many users do you need to test your interface on? Your instinct may be "the more, the better," which makes sense for scientific experiments. But that instinct is wrong. Almost everybody who does usability testing for a living seems to think that five or six users is enough. After that, you start seeing the same results again and again, and any additional users are just a waste of time.

You don't need a formal usability lab, and you don't really need to bring in users "off the street" -- you can do "50 cent usability tests" where you simply grab the next person you see and ask them to try a quick usability test. Make sure you don't spill the beans and tell them how to do things. Ask them to "think out loud" and interview them using open questions to try to discover their mental model.

If your program model is nontrivial, it's probably not the user model.

When I was 6 and my dad brought home one of the world's first pocket calculators, an HP-35, he tried to convince me that it had a computer inside it. I thought that was unlikely. All the computers on Star Trek were the size of a room and had big reel-to-reel tape recorders. I thought that there was just a clever correlation between the keys on the keypad and the individual elements of the LED display that happened to produce mathematically correct results. (Hey, I was 6).

An important rule of thumb is that user models aren't very complex. When people have to guess how a program is going to work, they tend to guess simple things, rather than complicated things. 

Sit down at a Macintosh. Open two Excel spreadsheet files and Word document file. Almost any novice user would guess that the windows were independent. They look independent:

The user model says that clicking on Spreadsheet 1 would bring that window to the front. What really happens is that Spreadsheet 2 comes to the front, a frustrating surprise for almost anybody:

As it turns out, Microsoft Excel's program model says that "you have these invisible sheets, one for each application, and the windows are 'glued' to those invisible sheets. When you bring Excel to the foreground, all other windows from Excel will move forward, too."

Riiiight. Invisible sheets. What are the chances that the user model included the concept of invisible sheets? Probably about zero. So new users will be surprised by this behavior.

Another example from the world of Microsoft Windows is the Alt+Tab key combination which switches to the "next" window. Most users would probably assume that it simply rotates among all available windows. If you have window A, B, and C, with A active, Alt+Tab should take you to B. Alt+Tab again would take you to C. Actually, what happens is that the second Alt+Tab takes you back to A. The only way to get to C is to hold down Alt and press Tab twice. It's a nice way to toggle between two applications, but almost nobody figures it out, because it's a slightly more complicated model than the rotate-among-available-windows model.

It's hard enough to make the program model conform to the user model when the models are simple. When the models become complex, it's even more unlikely. So pick the simplest possible model.

Chapter 3: Choices

When you go into a restaurant and you see a sign that says "No Dogs Allowed," you might think that sign is purely proscriptive: Mr. Restaurant doesn't like dogs around, so when he built the restaurant he put up that sign.

If that was all that was going on, there would also be a "No Snakes" sign; after all, nobody likes snakes. And a "No Elephants" sign, because they break the chairs when they sit down.

The real reason that sign is there is historical: it is a historical marker that indicates that people used to try to bring their dogs into the restaurant.

Most prohibitive signs are there because the proprietors of an establishment were sick and tired of people doing X, so they made a sign asking them to please not. If you go into one of those fifty year old ma-and-pa diners, like the Yankee Doodle in New Haven, the walls are covered with signs saying things like "Please don't put your knapsack on the counter," more anthropological evidence that people used to put their knapsacks on the counter a lot. By the age of the sign you can figure out when knapsacks were popular among local students. 

Sometimes they're harder to figure out. "Please do not bring glass bottles into the park" must mean that somebody cut themselves stepping on broken glass while walking barefoot through the grass once, and it's a good bet they sued the city.

Software has a similar archaeological record, too: it's called the Options dialog. Pull up the Tools | Options dialog box and you will see a history of arguments that the software designers had about the design of the product. Should we automatically open the last file that the user was working on? Yes! No! There is a two week debate, nobody wants to hurt anyone's feelings, the programmer puts in an #ifdef in self defense while the designers fight it out. Eventually they just decide to make it an option.

It doesn't even have to be a debate between two people: it can be an internal dilemma. I just can't decide if we should optimize the database for size or speed. Either way, you wind up with things like what is unequivocally the most moronic "wizard" dialog in the history of the Windows operating system. This dialog is so stupid that it deserves some kind of award. A whole new category of award. It's the dialog that comes up when you try to find something in Help:

The first problem with this dialog is that it's distracting. You are trying to find help in the help file. You do not, at that particular moment, give a hoot whether the database is small, big, customized, or chocolate-covered. In the meanwhile, this wicked, wicked dialog is giving you little pedantic lectures that it must create a list (or database). There are about three paragraphs there, most of which are completely confusing. There's the painfully awkward phrase "your help file(s)". You see, you may have one or more files. As if you cared at this point that there could be more than one. As if it made the slightest amount of difference. But the programmer who worked on that dialog was obviously distressed beyond belief at the possibility that there might be more than one help file(s) and it would be incorrect to say help file, now, wouldn't it?

Don't even get me started about how most people who want help are not the kinds of people who understand these kinds of arcana. Or that even advanced users, programmers with PhDs in Computer Science who know all about full text indexes, would not be able to figure out what they are really being asked to choose from.  

To add insult to injury, this isn't even a dialog... it's a wizard (the second page of which just says something like "thank you for submitting yourself to this needless waste of your time," to paraphrase). And it's pretty obvious that the designers had some idea as to which choice is best; after all, they've gone to the trouble of recommending one of the choices.

Which brings us to our second major rule of user interface design:

Every time you provide an option, you're asking the user to make a decision.

Asking the user to make a decision isn't in itself a bad thing. Freedom of choice can be wonderful. People love to order espresso-based beverages at Starbucks because they get to make so many choices. Grande-half-caf-skim-mocha-Valencia-with-whip. Extra hot!

The problem comes when you ask them to make a choice that they don't care about. In the case of help files, people are looking at the help file because they are having trouble accomplishing something they really want to accomplish, like making a birthday invitation. Their birthday invitation task has been unfortunately interrupted because they can't figure out how to print upside down balloons, or whatever, so they are going to the help file. Now, some annoying help-index-engine-programmer at Microsoft with an inflated idea of his own importance to the whole scheme of things has the audacity, the chutzpah, to interrupt the user once again and start teaching the user things about making lists (or databases). This second level of interrupting is completely unrelated to birthday invitations, and it's simply guaranteed to perplex and eventually piss off the user.

And believe you me, users care about a lot less things than you might think. They are using your software to accomplish a task. They care about the task. If it's a graphics program, they probably want to be able to control every pixel to the finest level of detail. If it's a tool to build a web site, you can bet that they are obsessive about getting the web site to look exactly the way they want it to look.

They do not, however, care one whit if the program's own toolbar is on the top or the bottom of the window. They don't care how the help file is indexed. They don't care about a lot of things, and it is the designers' responsibility to make these choices for them so that they don't have to. It is the height of arrogance for a software designer to inflict a choice like this on the user simply because the designer couldn't think hard enough to decide which option is really better. (It's even worse when you try to cover up the fact that you're giving the user a difficult choice by converting it to a wizard, as the WinHelp people did. As if the user was a moron who needed to take a little two step mini-course in the choice that they are being offered so that they can make an educated decision.)

It has been said that design is the art of making choices. When you design a trash can for the corner, you have to make choices between conflicting requirements. It needs to be heavy so it won't blow away. It needs to be light so the trash collector can dump it out. It needs to be large so it can hold a lot of trash. It needs to be small so it doesn't get in peoples' way on the sidewalk. When you are designing, and you try to abdicate your responsibility by forcing the user to decide something, you're probably not doing your job. Someone else will make an easier program that accomplishes the same task with less intrusions, and most users will love it.

When Microsoft Excel 3.0 came out in 1990, it was the first application to sport a new feature called a toolbar. It was a sensible feature, people liked it, and everybody copied it -- to the point that it's unusual to see an application without one any more.

The toolbar was so successful that the Excel team did field research using a special version of Excel which they distributed to a few people; this version kept statistics on what the most frequently used commands were and reported them back to Microsoft. For the next version, they added another row of toolbar buttons, this time containing the most frequently used commands. Great.

The trouble was, they never got around to disbanding the toolbar team, who didn't seem to know when to leave good enough alone. They wanted you to be able to customize your toolbar. They wanted you to be able to drag the toolbar anywhere on the screen. Then, they started to think about how the menu bar is really just a glorified toolbar with words instead of icons, so they let you drag the menu bar anywhere you wanted on the screen, too. Customizability on steroids. Problem: nobody cares! I've never met anyone who wants their menu bar anywhere except at the top of the window. But here's the (bad) joke: if you try to pull down the File menu, and you accidentally grab the menu bar a tiny bit too far to the left, you yank off the whole menu bar, dragging it to the only place you could not possibly want it to be: blocking the document you're working on.

How many times have you seen that? And once you've done this by mistake, it's not clear what you did or how to fix it. So here we have an option (moving the menu bar) that nobody wants (ok, maybe 0.1% of all humans want it) but which gets in the way for almost everybody.

One day a friend called me up. She was having trouble sending email. Half the screen was grey, she said. 

Half the screen was grey?

It took me five minutes over the phone to figure out what had happened. She had accidentally dragged the Windows toolbar to the right side of the screen, then accidentally widened it:

This is the kind of thing that nobody does on purpose. And there are a lot of computer users out there who can't get themselves out of this kind of mess; by definition, when you accidentally reconfigure one of the options in your program, you don't know how to re-reconfigure it. It's sort of shocking how many people uninstall and then reinstall their software when things start behaving wrong, because at least they know how to do that. (They've learned to uninstall first, because otherwise all the broken customizations are likely to just come back).

"But wait!" you say. "It's important to have options for advanced users who want to tweak their environments!" In reality, it's not as important as you think. This reminds me of when I tried to switch to a Dvorak keyboard. The trouble was, I don't use one computer. I use all kinds of computers. I use other people's computers. I use three computers fairly regularly at home and three at work. I use computers in the test lab at work. The trouble with customizing your environment is that it just doesn't propagate, so it's not even worth the trouble.

Most advanced users use several computers regularly; they upgrade their computer every couple of years, they reinstall their operating system every three weeks. It's true that the first time they realized you could completely remap the keyboard in Word, they changed everything around to be more to their liking, but as soon as they upgraded to Windows 95 those settings got lost, and they weren't the same at work, and eventually they just stopped reconfiguring things. I've asked a lot of my "power user" friends about this; hardly any of them do any customization other than the bare minimum necessary to make their system behave reasonably.

Every time you provide an option, you're asking the user to make a decision. That means they will have to think about something and decide about it. It's not necessarily a bad thing, but, in general, you should always try to minimize the number of decisions that people have to make.

This doesn't mean eliminate all choice. There are enough choices that users will have to make anyway: the way their document will look, the way their web site will behave, or anything else that is integral to the work that the user is doing. In these areas, go crazy:  it's great to give people choices: by all means, the more the merrier. And there's another category of choice that people like: the ability to change the visual look of things, without really changing the behavior. Everybody loves WinAmp skins; everybody sets their desktop background to a picture. Since the choice affects the visual look without affecting the way anything functions, and since users are completely free to ignore the choice and get their work done anyway, this is a good use of options.

SQL Server 安全管理可分为3个层次，即登入账户、资料库的管理与连接特定资料库的权限和使用者对所连接资料库部分的操作权限。下面，我们将针对这3个层次做详细说明。

一、登入账户
        任何需要存取 SQL Server的使用者皆需要有一组服务器认可的账户和密码。SQL Server支持2种登入方式，一种为Windows验证，另一种为SQL Server验证。前者只要在SQL Server中建立与Windwos NT/2000对应的登入账户，让使用者登入Windows NT/2000时所用的账户能与在SQL Server中的账户相互对应，即可顺利连上SQL Server，由此，我们完成了对Windows NT/2000安全管理机制的整合。

        接下来，资料库管理者在Windows NT上登入账号，可直接将Windows NT中的群组加到SQL Server中，从而成为一个登入账户。

        通过上述操作，Windows NT登入群组中的成员皆可连接SQL Server。如果该群组中某一成员不允许其登入SQL Server，可在SQL Server中将该成员的个人账户设为拒绝存取。如果把SQL Server安装在 Windows 95、Windows 98或Windows Me中，则无法使用Windows验证方式。

        如果使用SQL Server验证，必须在SQL Server中为要连接SQL Server的使用者建立登入的账号名称和密码，这些账号和密码与Windows NT/2000的账户无关。

二、管理与连接特定资料库的权限
        在建立登入账户后，使用者便能进入SQL Server中，但并不代表使用者有连接SQL Server特定资料库的权限，必须对使用者或群组设置对SQL Server的操作权限。SQL Server中对资料库的操作权限可分为服务器自身的操作权限与资料库的存取权限。对SQL Server的操作权限可由服务器角色来设置，资料库的存取权限则可由角色与使用者对个别表格的存取权限来设置。那么，服务器角色与角色之间有什么不同呢？

        1. 服务器角色
        SQL Server系统内建8种服务器角色(可把角色想像成Windows NT账号中的群组)，它不能更改或新增。当对某一使用者或群组设置好服务器角色后，其便拥有该服务器角色所拥有的权限。服务器角色是将SQL Server的各项管理工作加以分类，如建立账号和资料库备份等，它与资料库角色不一样，后者为对个别资料库的操作权限。

        我们简单列出8种服务器角色所拥有的权限。
        system administrators 表示系统管理员可执行任何动作。
        security administrators 表示管理登入账户。
        server administrators 表示设置SQL Server的各项参数。
        setup administrators  表示有关replication(复制)的设置与管理扩充预存程序。
        process administrators 表示管理SQL Server所有执行中的程序。
        disk administrators  表示管理资料库文件。
        database administrators 表示建立和更改资料库属性。
        bulk insert administrators 表示对可执行bulk insert操作的管理。

        2. 角色
        SQL Server内建10种资料库角色，它不能更改或删除，但可对个别资料库增加角色。若给予使用者有内建角色中的资料库拥有者权限，它便拥有该资料库的完整操作权。其余各角色的详细权限说明可参考SQL Server的bol(即SQL Server books online)，通过查询关键字roles，进入标题为roles的项目，其中有包含内建服务器角色与资料库角色的完整说明，在此不多赘述。需要注意的是，在对使用者分别设置了各种角色(每一使用者或群组可具有多种角色)后，它便拥有所有角色联集的权限，但若其中有某一角色对某一操作权(如对某一表格的select权)设置了拒绝，它将失去了该项权限，换句话说，拒绝权限优于授予权限。

三、资料库中部件的存取权限
        对于SQL Server的管理与可连接特定资料库的权限，由SQL Server所提供的服务器角色与资料库角色基本上可以符合我们大部份需求。另外，可直接对使用者或群组设置对资料库中部件的个别存取权限，这些个别的存取权限有select、insert、update、delete、exec和dri，其中exec与dri分别表示对预存程序的执行权限和对表格有效性的验证权限。在做直接的权限设置时，我们也可针对特殊的使用者(如内建资料库角色不能满足时)，当然，如果使用相同权限方式的用户比较多时，可以增加一个符合需求的资料库角色，或将这些使用者在Windows NT/2000上先归于某群组，再对该群组设置权限，这样做比较方便于管理与维护。

        除上述内容之外，在实际运行时，笔者对于资料库安全的把关总结出以下几点建议。
        1. 除非必要，否则尽量以Windows验证来管理可连接SQL Server的使用者，以整合Windows NT/2000的安全机制。
        2. 善用SQL Server的服务器角色与资料库角色功能。
        3. 善用SQL Server的加密功能。

        SQL Server提供了登入账号、网络传输、虚拟表和预存程序的加密功能。其中账号的密码加密是预设的，而网络间传输资料则可用SSL方式进行加密，要启动此功能必须启动net-library的加密功能，同时要配合Windows 2000的CA功能，并在服务器端与用户端设置完成，从而双方在传输资料前，便会在SSL加密后再进行传输。由于虚拟表和预存程序的定义是以明码保存在系统资料表中，若要将虚拟表和预存程序加密，可在其建立时在eNTerprise manager中设置加密选项或以 alter 叙述来设置加密。

        4. 系统安装完毕后，务必更改预设的sa密码，免得有其他使用者"义务"管理您的SQL Server。

在进行SQL Server 2000数据库的安全配置之前，首先你必须对操作系统进行安全配置，保证你的操作系统处于安全状态。然后对你要使用的操作数据库软件（程序）进行必要的安全审核，比如对ASP、PHP等脚本，这是很多基于数据库的WEB应用常出现的安全隐患，对于脚本主要是一个过滤问题，需要过滤一些类似 , ‘ ; @ / 等字符，防止破坏者构造恶意的SQL语句。接着，安装SQL Server2000后请打上补丁sp3以及最新的sp4。


在做完上面三步基础之后，我们再来讨论SQL Server的安全配置。

1、使用安全的密码策略
我们把密码策略摆在所有安全配置的第一步，请注意，很多数据库帐号的密码过于简单，这跟系统密码过于简单是一个道理。对于sa更应该注意，同时不要让sa帐号的密码写于应用程序或者脚本中。健壮的密码是安全的第一步！
SQL Server2000安装的时候，如果是使用混合模式，那么就需要输入sa的密码，除非你确认必须使用空密码。这比以前的版本有所改进。
同时养成定期修改密码的好习惯。数据库管理员应该定期查看是否有不符合密码要求的帐号。比如使用下面的SQL语句：
Use master
Select name,Password from syslogins where password is null

2、使用安全的帐号策略。
由于SQL Server不能更改sa用户名称，也不能删除这个超级用户，所以，我们必须对这个帐号进行最强的保护，当然，包括使用一个非常强壮的密码，最好不要在数据库应用中使用sa帐号，只有当没有其它方法登录到 SQL Server 实例（例如，当其它系统管理员不可用或忘记了密码）时才使用 sa。建议数据库管理员新建立一个拥有与sa一样权限的超级用户来管理数据库。安全的帐号策略还包括不要让管理员权限的帐号泛滥。
SQL Server的认证模式有Windows身份认证和混合身份认证两种。如果数据库管理员不希望操作系统管理员来通过操作系统登陆来接触数据库的话，可以在帐号管理中把系统帐号“BUILTIN\Administrators”删除。不过这样做的结果是一旦sa帐号忘记密码的话，就没有办法来恢复了。
很多主机使用数据库应用只是用来做查询、修改等简单功能的，请根据实际需要分配帐号，并赋予仅仅能够满足应用要求和需要的权限。比如，只要查询功能的，那么就使用一个简单的public帐号能够select就可以了。

3、加强数据库日志的记录。
审核数据库登录事件的“失败和成功”，在实例属性中选择“安全性”，将其中的审核级别选定为全部，这样在数据库系统和操作系统日志里面，就详细记录了所有帐号的登录事件。

请定期查看SQL Server日志检查是否有可疑的登录事件发生，或者使用DOS命令。
findstr /C:"登录" d:\Microsoft SQL Server\MSSQL\LOG\*.*

4、管理扩展存储过程
对存储过程进行大手术，并且对帐号调用扩展存储过程的权限要慎重。其实在多数应用中根本用不到多少系统的存储过程，而SQL Server的这么多系统存储过程只是用来适应广大用户需求的，所以请删除不必要的存储过程，因为有些系统的存储过程能很容易地被人利用起来提升权限或进行破坏。
如果你不需要扩展存储过程xp_cmdshell请把它去掉。使用这个SQL语句：
use master
sp_dropextendedproc 'xp_cmdshell'
xp_cmdshell是进入操作系统的最佳捷径，是数据库留给操作系统的一个大后门。如果你需要这个存储过程，请用这个语句也可以恢复过来。
sp_addextendedproc 'xp_cmdshell', 'xpsql70.dll'

如果你不需要请丢弃OLE自动存储过程（会造成管理器中的某些特征不能使用），这些过程包括如下：
Sp_OACreate Sp_OADestroy Sp_OAGetErrorInfo Sp_OAGetProperty
Sp_OAMethod Sp_OASetProperty Sp_OAStop
去掉不需要的注册表访问的存储过程，注册表存储过程甚至能够读出操作系统管理员的密码来，如下：
Xp_regaddmultistring Xp_regdeletekey Xp_regdeletevalue Xp_regenumvalues
Xp_regread Xp_regremovemultistring Xp_regwrite
还有一些其他的扩展存储过程，你也最好检查检查。
在处理存储过程的时候，请确认一下，避免造成对数据库或应用程序的伤害。

5、使用协议加密
SQL Server 2000使用的Tabular Data Stream协议来进行网络数据交换，如果不加密的话，所有的网络传输都是明文的，包括密码、数据库内容等等，这是一个很大的安全威胁。能被人在网络中截获到他们需要的东西，包括数据库帐号和密码。所以，在条件容许情况下，最好使用SSL来加密协议，当然，你需要一个证书来支持。

6、不要让人随便探测到你的TCP/IP端口
默认情况下，SQL Server使用1433端口监听，很多人都说SQL Server配置的时候要把这个端口改变，这样别人就不能很容易地知道使用的什么端口了。可惜，通过微软未公开的1434端口的UDP探测可以很容易知道SQL Server使用的什么TCP/IP端口了（请参考《深入探索SQL Server网络连接的安全问题》）。
不过微软还是考虑到了这个问题，毕竟公开而且开放的端口会引起不必要的麻烦。在实例属性中选择TCP/IP协议的属性。选择隐藏 SQL Server 实例。如果隐藏了 SQL Server 实例，则将禁止对试图枚举网络上现有的 SQL Server 实例的客户端所发出的广播作出响应。这样，别人就不能用1434来探测你的TCP/IP端口了（除非用Port Scan）。

7、修改TCP/IP使用的端口
请在上一步配置的基础上，更改原默认的1433端口。在实例属性中选择网络配置中的TCP/IP协议的属性，将TCP/IP使用的默认端口变为其他端口。

9、拒绝来自1434端口的探测
由于1434端口探测没有限制，能够被别人探测到一些数据库信息，而且还可能遭到DOS攻击让数据库服务器的CPU负荷增大，所以对Windows 2000操作系统来说，在IPSec过滤拒绝掉1434端口的UDP通讯，可以尽可能地隐藏你的SQL Server。

10、对网络连接进行IP限制
SQL Server 2000数据库系统本身没有提供网络连接的安全解决办法，但是Windows 2000提供了这样的安全机制。使用操作系统自己的IPSec可以实现IP数据包的安全性。请对IP连接进行限制，只保证自己的IP能够访问，也拒绝其他IP进行的端口连接，把来自网络上的安全威胁进行有效的控制。
关于IPSec的使用请参看：http://www.microsoft.com/china/technet/security/ipsecloc.ASP

上面主要介绍的一些SQL Server的安全配置，经过以上的配置，可以让SQL Server本身具备足够的安全防范能力。当然，更主要的还是要加强内部的安全控制和管理员的安全培训，而且安全性问题是一个长期的解决过程，还需要以后进行更多的安全维护。

一、Windows Server2003的安装

　　1、安装系统最少两需要个分区，分区格式都采用NTFS格式

　　2、在断开网络的情况安装好2003系统

　　3、安装IIS，仅安装必要的 IIS 组件（禁用不需要的如FTP 和 SMTP 服务）。默认情况下，IIS服务没有安装，在添加/删除Win组件中选择“应用程序服务器”，然后点击“详细信息”，双击Internet信息服务(iis)，勾选以下选项：

　　Internet 信息服务管理器；

　　公用文件；

　　后台智能传输服务 (BITS) 服务器扩展；

　　万维网服务。

　　如果你使用 FrontPage 扩展的 Web 站点再勾选：FrontPage 2002 Server Extensions

　　4、安装MSSQL及其它所需要的软件然后进行Update。

　　5、使用Microsoft 提供的 MBSA（Microsoft Baseline Security Analyzer） 工具分析计算机的安全配置，并标识缺少的修补程序和更新。下载地址：见页末的链接

二、设置和管理账户

　　1、系统管理员账户最好少建，更改默认的管理员帐户名（Administrator）和描述，密码最好采用数字加大小写字母加数字的上档键组合，长度最好不少于14位。

　　2、新建一个名为Administrator的陷阱帐号，为其设置最小的权限，然后随便输入组合的最好不低于20位的密码

　　3、将Guest账户禁用并更改名称和描述，然后输入一个复杂的密码，当然现在也有一个DelGuest的工具，也许你也可以利用它来删除Guest账户，但我没有试过。

　　4、在运行中输入gpedit.msc回车，打开组策略编辑器，选择计算机配置-Windows设置-安全设置-账户策略-账户锁定策略，将账户设为“三次登陆无效”，“锁定时间为30分钟”，“复位锁定计数设为30分钟”。

　　5、在安全设置-本地策略-安全选项中将“不显示上次的用户名”设为启用

　　6、在安全设置-本地策略-用户权利分配中将“从网络访问此计算机”中只保留Internet来宾账户、启动IIS进程账户。如果你使用了Asp.net还要保留Aspnet账户。

　　7、创建一个User账户，运行系统，如果要运行特权命令使用Runas命令。

三、网络服务安全管理

　　1、禁止C$、D$、ADMIN$一类的缺省共享

　　打开注册表，HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters，在右边的窗口中新建Dword值，名称设为AutoShareServer值设为0

　　2、 解除NetBios与TCP/IP协议的绑定

　　右击网上邻居-属性-右击本地连接-属性-双击Internet协议-高级-Wins-禁用TCP/IP上的NETBIOS

　　3、关闭不需要的服务，以下为建议选项

　　Computer Browser:维护网络计算机更新，禁用

　　Distributed File System: 局域网管理共享文件，不需要禁用

　　Distributed linktracking client：用于局域网更新连接信息，不需要禁用

　　Error reporting service：禁止发送错误报告

　　Microsoft Serch：提供快速的单词搜索，不需要可禁用

　　NTLMSecuritysupportprovide：telnet服务和Microsoft Serch用的，不需要禁用

　　PrintSpooler：如果没有打印机可禁用

　　Remote Registry：禁止远程修改注册表

　　Remote Desktop Help Session Manager：禁止远程协助

四、打开相应的审核策略

　　在运行中输入gpedit.msc回车，打开组策略编辑器，选择计算机配置-Windows设置-安全设置-审核策略在创建审核项目时需要注意的是如果审核的项目太多，生成的事件也就越多，那么要想发现严重的事件也越难当然如果审核的太少也会影响你发现严重的事件，所以你需要根据情况在这二者之间做出选择。

　　推荐的要审核的项目：

　　登录事件 成功 失败

　　账户登录事件 成功 失败

　　系统事件 成功 失败

　　策略更改 成功 失败

　　对象访问 失败

　　目录服务访问 失败

　　特权使用 失败

五、其它安全相关设置

　　1、隐藏重要文件/目录

　　可以修改注册表实现完全隐藏：“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\ Current-Version\Explorer\Advanced\Folder\Hi-dden\SHOWALL”，鼠标右击 “CheckedValue”，选择修改，把数值由1改为0

　　2、启动系统自带的Internet连接防火墙，在设置服务选项中勾选Web服务器。

　　3、防止SYN洪水攻击

　　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

　　新建DWORD值，名为SynAttackProtect，值为2

　　4. 禁止响应ICMP路由通告报文

　　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\interface

　　新建DWORD值，名为PerformRouterDiscovery 值为0

　　5. 防止ICMP重定向报文的攻击

　　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

　　将EnableICMPRedirects 值设为0

　　6. 不支持IGMP协议

　　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

　　新建DWORD值，名为IGMPLevel 值为0

　　7、禁用DCOM：

　　运行中输入 Dcomcnfg.exe。 回车， 单击“控制台根节点”下的“组件服务”。 打开“计算机”子文件夹。

　　对于本地计算机，请以右键单击“我的电脑”，然后选择“属性”。选择“默认属性”选项卡。

　　清除“在这台计算机上启用分布式 COM”复选框。

　　注：3-6项内容我采用的是Server2000设置，没有测试过对2003是否起作用。但有一点可以肯定我用了一段的时间没有发现其它副面的影响。

六、配置 IIS 服务：

　　1、不使用默认的Web站点，如果使用也要将 将IIS目录与系统磁盘分开。

　　2、删除IIS默认创建的Inetpub目录（在安装系统的盘上）。

　　3、删除系统盘下的虚拟目录，如：_vti_bin、IISSamples、Scripts、IIShelp、IISAdmin、IIShelp、MSADC。

　　4、删除不必要的IIS扩展名映射。

　　右键单击“默认Web站点→属性→主目录→配置”，打开应用程序窗口，去掉不必要的应用程序映射。主要为.shtml, .shtm, .stm

　　5、更改IIS日志的路径

　　右键单击“默认Web站点→属性-网站-在启用日志记录下点击属性

　　6、如果使用的是2000可以使用iislockdown来保护IIS，在2003运行的IE6.0的版本不需要。

　　7、使用UrlScan

　　UrlScan是一个ISAPI筛选器，它对传入的HTTP数据包进行分析并可以拒绝任何可疑的通信量。目前最新的版本是2.5，如果是2000Server需要先安装1.0或2.0的版本。下载地址见页未的链接

　　如果没有特殊的要求采用UrlScan默认配置就可以了。

　　但如果你在服务器运行ASP.NET程序，并要进行调试你需打开要%WINDIR%\System32\Inetsrv\URLscan

　　文件夹中的URLScan.ini 文件，然后在UserAllowVerbs节添加debug谓词，注意此节是区分大小写的。

　　如果你的网页是.asp网页你需要在DenyExtensions删除.asp相关的内容。

　　如果你的网页使用了非ASCII代码，你需要在Option节中将AllowHighBitCharacters的值设为1

　　在对URLScan.ini 文件做了更改后，你需要重启IIS服务才能生效，快速方法运行中输入iisreset

　　如果你在配置后出现什么问题，你可以通过添加/删除程序删除UrlScan。

　　8、利用WIS (Web Injection Scanner)工具对整个网站进行SQL Injection 脆弱性扫描.

　　

七、配置Sql服务器

　　1、System Administrators 角色最好不要超过两个

　　2、如果是在本机最好将身份验证配置为Win登陆

　　3、不要使用Sa账户，为其配置一个超级复杂的密码

　　4、删除以下的扩展存储过程格式为：
　　use master
　　sp_dropextendedproc ‘扩展存储过程名’

　　xp_cmdshell：是进入操作系统的最佳捷径，删除

　　访问注册表的存储过程，删除
　　Xp_regaddmultistring　　Xp_regdeletekey　　Xp_regdeletevalue　　Xp_regenumvalues
　　Xp_regread　　　　　 Xp_regwrite　　　 Xp_regremovemultistring

　　OLE自动存储过程，不需要删除
　　Sp_OACreate　 　Sp_OADestroy　　　　Sp_OAGetErrorInfo　　Sp_OAGetProperty
　　Sp_OAMethod　　Sp_OASetProperty　　Sp_OAStop

　　5、隐藏 SQL Server、更改默认的1433端口

　　右击实例选属性-常规-网络配置中选择TCP/IP协议的属性，选择隐藏 SQL Server 实例，并改原默认的1433端口。

八、如果只做服务器，不进行其它操作，使用IPSec

　　1、管理工具—本地安全策略—右击IP安全策略—管理IP筛选器表和筛选器操作—在管理IP筛选器表选项下点击

　　添加—名称设为Web筛选器—点击添加—在描述中输入Web服务器—将源地址设为任何IP地址——将目标地址设为我的IP地址——协议类型设为Tcp——IP协议端口第一项设为从任意端口，第二项到此端口80——点击完成——点击确定。

　　2、再在管理IP筛选器表选项下点击

　　添加—名称设为所有入站筛选器—点击添加—在描述中输入所有入站筛选—将源地址设为任何IP地址——将目标地址设为我的IP地址——协议类型设为任意——点击下一步——完成——点击确定。

　　3、在管理筛选器操作选项下点击添加——下一步——名称中输入阻止——下一步——选择阻止——下一步——完成——关闭管理IP筛选器表和筛选器操作窗口

　　4、右击IP安全策略——创建IP安全策略——下一步——名称输入数据包筛选器——下一步——取消默认激活响应原则——下一步——完成

　　5、在打开的新IP安全策略属性窗口选择添加——下一步——不指定隧道——下一步——所有网络连接——下一步——在IP筛选器列表中选择新建的 Web筛选器——下一步——在筛选器操作中选择许可——下一步——完成——在IP筛选器列表中选择新建的阻止筛选器——下一步——在筛选器操作中选择阻止 ——下一步——完成——确定

　　6、在IP安全策略的右边窗口中右击新建的数据包筛选器，点击指派，不需要重启，IPSec就可生效.

九 严重注意

　　如果你按这些去操作，建议每做一项更改就测试一下服务器，如果有问题可以马上撤消更改。而如果更改的项数多，才发现出问题，那就很难判断问题是出在哪一步上了。

十、运行服务器记录当前的程序和开放的端口

　　1、将当前服务器的进程抓图或记录下来，将其保存，方便以后对照查看是否有不明的程序。

　　2、将当前开放的端口抓图或记录下来，保存，方便以后对照查看是否开放了不明的端口。当然如果你能分辨每一个进程，和端口这一步可以省略。

十一、

确设置磁盘的安全性,具体如下(虚拟机的安全设置，我们以asp程序为例子)重点：

1、系统盘权限设置

C:分区部分：

c:\

administrators 全部(该文件夹，子文件夹及文件)

CREATOR OWNER 全部(只有子文件来及文件)

system 全部(该文件夹，子文件夹及文件)

IIS_WPG 创建文件/写入数据(只有该文件夹)

IIS_WPG(该文件夹，子文件夹及文件)

遍历文件夹/运行文件

列出文件夹/读取数据

读取属性

创建文件夹/附加数据

读取权限

c:\Documents and Settings

administrators 全部(该文件夹，子文件夹及文件)

Power Users (该文件夹，子文件夹及文件)

读取和运行

列出文件夹目录

读取

SYSTEM全部(该文件夹，子文件夹及文件)

C:\Program Files

administrators 全部(该文件夹，子文件夹及文件)

CREATOR OWNER全部(只有子文件来及文件)

IIS_WPG (该文件夹，子文件夹及文件)

读取和运行

列出文件夹目录

读取

Power Users(该文件夹，子文件夹及文件)

修改权限

SYSTEM全部(该文件夹，子文件夹及文件)

TERMINAL SERVER USER (该文件夹，子文件夹及文件)

修改权限

2、网站及虚拟机权限设置(比如网站在E盘)

说明：我们假设网站全部在E盘wwwsite目录下，并且为每一个虚拟机创建了一个guest用户，用户名为vhost1...vhostn并且创建了一个webuser组，把所有的vhost用户全部加入这个webuser组里面方便管理

E:\

Administrators全部(该文件夹，子文件夹及文件)

E:\wwwsite

Administrators全部(该文件夹，子文件夹及文件)

system全部(该文件夹，子文件夹及文件)

service全部(该文件夹，子文件夹及文件)

E:\wwwsite\vhost1

Administrators全部(该文件夹，子文件夹及文件)

system全部(该文件夹，子文件夹及文件)

vhost1全部(该文件夹，子文件夹及文件)

3、数据备份盘

数据备份盘最好只指定一个特定的用户对它有完全操作的权限

比如F盘为数据备份盘，我们只指定一个管理员对它有完全操作的权限

4、其它地方的权限设置

请找到c盘的这些文件，把安全性设置只有特定的管理员有完全操作权限

下列这些文件只允许administrators访问

net.exe

net1.exet

cmd.exe

tftp.exe

netstat.exe

regedit.exe

at.exe

attrib.exe

cacls.exe

format.com

5.删除c:\inetpub目录，删除iis不必要的映射，建立陷阱帐号，更改描述

第三招：禁用不必要的服务，提高安全性和系统效率

Computer Browser 维护网络上计算机的最新列表以及提供这个列表

　　Task scheduler 允许程序在指定时间运行

　　Routing and Remote Access 在局域网以及广域网环境中为企业提供路由服务

　　Removable storage 管理可移动媒体、驱动程序和库

　　Remote Registry Service 允许远程注册表操作

　　Print Spooler 将文件加载到内存中以便以后打印。要用打印机的朋友不能禁用这项

　　IPSEC Policy Agent 管理IP安全策略以及启动ISAKMP/OakleyIKE)和IP安全驱动程序

　　Distributed Link Tracking Client 当文件在网络域的NTFS卷中移动时发送通知

　　Com+ Event System 提供事件的自动发布到订阅COM组件

Alerter 通知选定的用户和计算机管理警报

Error Reporting Service 收集、存储和向 Microsoft 报告异常应用程序

Messenger 传输客户端和服务器之间的 NET SEND 和 警报器服务消息

Telnet 允许远程用户登录到此计算机并运行程序

第四招:修改注册表，让系统更强壮

1、隐藏重要文件/目录可以修改注册表实现完全隐藏：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\ Current-Version\Explorer\Advanced\Folder\Hi-dden\SHOWALL”，鼠标右击 “Checkedvalue”，选择修改，把数值由1改为0

　　2、启动系统自带的Internet连接_blank">防火墙，在设置服务选项中勾选Web服务器。

　　3、防止SYN洪水攻击

　　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

新建DWORD值，名为SynAttackProtect，值为2

EnablePMTUDiscovery REG_DWORD 0

NoNameReleaseOnDemand REG_DWORD 1

EnableDeadGWDetect REG_DWORD 0

KeepAliveTime REG_DWORD 300,000

PerformRouterDiscovery REG_DWORD 0

EnableICMPRedirects REG_DWORD 0

　　4. 禁止响应ICMP路由通告报文

　　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\interface

　　新建DWORD值，名为PerformRouterDiscovery 值为0

　　5. 防止ICMP重定向报文的攻击

　　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

　　将EnableICMPRedirects 值设为0

　　6. 不支持IGMP协议

　　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

新建DWORD值，名为IGMPLevel 值为0

7.修改终端服务端口

运行regedit，找到[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Terminal Server \ Wds \ rdpwd \ Tds \ tcp]，看到右边的PortNumber了吗？在十进制状态下改成你想要的端口号吧，比如7126之类的，只要不与其它冲突即可。

　　2、第二处HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Terminal Server \ WinStations \ RDP-Tcp，方法同上，记得改的端口号和上面改的一样就行了。

8、禁止IPC空连接：

cracker可以利用net use命令建立空连接，进而入侵，还有net view，nbtstat这些都是基于空连接的，禁止空连接就好了。打开注册表，找到Local_Machine\System\CurrentControlSet\Control\LSA-RestrictAnonymous 把这个值改成”1”即可。

9、更改TTL值

cracker可以根据ping回的TTL值来大致判断你的操作系统，如：

TTL=107(WINNT);

TTL=108(win2000);

TTL=127或128(win9x);

TTL=240或241(linux);

TTL=252(solaris);

TTL=240(Irix);

实际上你可以自己更改的：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters：DefaultTTL REG_DWORD 0-0xff(0-255 十进制,默认值128)改成一个莫名其妙的数字如258，起码让那些小菜鸟晕上半天，就此放弃入侵你也不一定哦

10. 删除默认共享
有人问过我一开机就共享所有盘，改回来以后，重启又变成了共享是怎么回事，这是2K为管理而设置的默认共享，必须通过修改注册表的方式取消它：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters：AutoShareServer类型是REG_DWORD把值改为0即可

11. 禁止建立空连接

默认情况下，任何用户通过通过空连接连上服务器，进而枚举出帐号，猜测密码。我们可以通过修改注册表来禁止建立空连接：

Local_Machine\System\CurrentControlSet\Control\LSA-RestrictAnonymous 的值改成”1”即可。

第五招:其它安全手段

1.禁用TCP/IP上的NetBIOS
网上邻居-属性-本地连接-属性-Internet协议（TCP/IP）属性-高级-WINS面板-NetBIOS设置-禁用TCP/IP上的NetBIOS。这样cracker就无法用nbtstat命令来读取你的NetBIOS信息和网卡MAC地址了。

2. 账户安全
首先禁止一切账户，除了你自己，呵呵。然后把Administrator改名。我呢就顺手又建了个Administrator账户，不过是什么权限都没有的那种，然后打开记事本，一阵乱敲，复制，粘贴到“密码”里去，呵呵，来破密码吧~！破完了才发现是个低级账户，看你崩溃不？

创建2个管理员用帐号

虽然这点看上去和上面这点有些矛盾，但事实上是服从上面的规则的。 创建一个一般权限帐号用来收信以及处理一些正常事物，另一个拥有Administrators 权限的帐户只在需要的时候使用。可以让管理员使用 “ RunAS” 命令来执行一些需要特权才能作的一些工作，以方便管理

3.更改C:\WINDOWS\Help\iisHelp\common\404b.htm内容改为 这样，出错了自动转到首页

4. 安全日志

我遇到过这样的情况，一台主机被别人入侵了，系统管理员请我去追查凶手，我登录进去一看：安全日志是空的，倒，请记住：Win2000的默认安装是不开任何安全审核的！那么请你到本地安全策略->审核策略中打开相应的审核，推荐的审核是：

账户管理 成功 失败

登录事件 成功 失败

对象访问 失败

策略更改 成功 失败

特权使用 失败

系统事件 成功 失败

目录服务访问 失败

账户登录事件 成功 失败

审核项目少的缺点是万一你想看发现没有记录那就一点都没辙；审核项目太多不仅会占用系统资源而且会导致你根本没空去看，这样就失去了审核的意义

5. 运行防毒软件

我见过的Win2000/Nt服务器从来没有见到有安装了防毒软件的，其实这一点非常重要。一些好的杀毒软件不仅能杀掉一些著名的病毒，还能查杀大量木马和后门程序。这样的话，“黑客”们使用的那些有名的木马就毫无用武之地了。不要忘了经常升级病毒库,我们推荐mcafree杀毒软件+blackice_blank">防火墙

6.sqlserver数据库服务器安全和serv-u ftp服务器安全配置，更改默认端口，和管理密码

7.设置ip筛选、用blackice禁止木马常用端口

一般禁用以下端口

135 138 139 443 445 4000 4899 7626

8.本地安全策略和组策略的设置,如果你在设置本地安全策略时设置错了，可以这样恢复成它的默认值.

打开 %SystemRoot%\Security文件夹,创建一个 "OldSecurity"子目录,将%SystemRoot%\Security下所有的.log文件移到这个新建的子文件夹中.

在%SystemRoot%\Security\database\下找到"Secedit.sdb"安全数据库并将其改名,如改为"Secedit.old".

启动"安全配置和分析"MMC管理单元:"开始"->"运行"->"MMC",启动管理控制台,"添加/删除管理单元",将"安全配置和分析"管理单元添加上.

右击"安全配置和分析"->"打开数据库",浏览"C:\WINNT\security\Database"文件夹,输入文件名"secedit.sdb",单击"打开".

当系统提示输入一个模板时,选择"Setup Security.inf",单击"打开".

如果系统提示"拒绝访问数据库",不管他.

你会发现在"C:\WINNT\security\Database"子文件夹中重新生成了新的安全数据库,

在"C:\WINNT\security"子文件夹下重新生成了log文件.安全数据库重建成功 

[来源于网络，还给网络，大家随便使用]

<HTML>
<HEAD>
<TITLE>演示图片等比例缩小</TITLE>
<script>
function Wa_SetImgAutoSize(img)
{
//var img=document.all.img1;//获取图片
var MaxWidth=200;//设置图片宽度界限
var MaxHeight=100;//设置图片高度界限
var HeightWidth=img.offsetHeight/img.offsetWidth;//设置高宽比
var WidthHeight=img.offsetWidth/img.offsetHeight;//设置宽高比
alert("test"+img.offsetHeight+img.fileSize);
if(img.offsetHeight>1) alert(img.offsetHeight);
if(img.readyState!="complete"){
 return false;//确保图片完全加载
}

if(img.offsetWidth>MaxWidth){
img.width=MaxWidth;
img.height=MaxWidth*HeightWidth;
}
if(img.offsetHeight>MaxHeight){
img.height=MaxHeight;
img.width=MaxHeight*WidthHeight;
}
}

function CheckImg(img)
{
 var message="";
 var MaxWidth=1;//设置图片宽度界限
 var MaxHeight=1;//设置图片高度界限
 
 if(img.readyState!="complete"){
  return false;//确保图片完全加载
 }
 if(img.offsetHeight>MaxHeight) message+="\r高度超额："+img.offsetHeight;
 if(img.offsetWidth>MaxWidth) message+="\r宽度超额："+img.offsetWidth;
 if(message!="") alert(message);
}
</script>
</HEAD>
<BODY>
<img src="images/frequency.gif" border=0 id="img1" onload="CheckImg(this);">
<br>
<input id=inp type="file" onpropertychange="img1.src=this.value;">
</BODY>
</HTML>

学习，再学习。

http://www.cnblogs.com/ghd258/archive/2006/03/17/352310.aspx