More servicesWindows Live
HomeHotmailSpacesOneCare
 
MSN
Sign in
 
 
Spaces home  User Experience & User I...PhotosProfileFriendsMore Tools Explore the Spaces community

User Experience & User Interface

May 18

AJAX基础教程

Friday, October 21, 2005

AJAX基础教程

本文来源于(有能够提供最初翻译者的朋友吗?):
http://developer.mozilla.org/en/docs/AJAX:Getting_Started 
这篇文章将带您浏览整个AJAX的基本概貌,并展示两个简单的例子让您轻松上路.

什么是 AJAX?
AJAX (异步 JavaScript 和 XML) 是个新产生的术语,专为描述JavaScript的两项强大性能.这两项性能在多年来一直被网络开发者所忽略,直到最近Gmail, Google suggest和google Maps的横空出世才使人们开始意识到其重要性.

这两项被忽视的性能是:
无需重新装载整个页面便能向服务器发送请求.
对XML文档的解析和处理.

步骤 1 – "请!" --- 如何发送一个HTTP请求

为了用JavaScript向服务器发送一个HTTP请求, 需要一个具备这种功能的类实例. 这样的类首先由Internet Explorer以ActiveX对象引入, 被称为XMLHTTP. 后来Mozilla, Safari 和其他浏览器纷纷仿效, 提供了XMLHttpRequest类,它支持微软的ActiveX对象所提供的方法和属性.

因此, 为了创建一个跨浏览器的这样的类实例(对象), 可以应用如下代码:

if (window.XMLHttpRequest) { // Mozilla, Safari, ...
    http_request = new XMLHttpRequest();
} else if (window.ActiveXObject) { // IE
    http_request = new ActiveXObject("Microsoft.XMLHTTP");
}   (上例对代码做了一定简化,这是为了解释如何创建XMLHTTP类实例. 实际的代码实例可参阅本篇步骤3.)

如果服务器的响应没有XML mime-type header,某些Mozilla浏览器可能无法正常工作. 为了解决这个问题, 如果服务器响应的header不是text/xml,可以调用其它方法修改该header.

http_request = new XMLHttpRequest();
http_request.overrideMimeType('text/xml');  接下来要决定当收到服务器的响应后,需要做什么.这需要告诉HTTP请求对象用哪一个JavaScript函数处理这个响应.可以将对象的onreadystatechange属性设置为要使用的JavaScript的函数名,如下所示:

http_request.onreadystatechange = nameOfTheFunction;

注意:在函数名后没有括号,也无需传递参数.另外还有一种方法,可以在扉页(fly)中定义函数及其对响应要采取的行为,如下所示:

http_request.onreadystatechange = function(){
    // do the thing
};  在定义了如何处理响应后,就要发送请求了.可以调用HTTP请求类的open()和send()方法, 如下所示:

http_request.open('GET', 'http://www.example.org/some.file', true);
http_request.send(null);   open()的第一个参数是HTTP请求方式 – GET, POST, HEAD 或任何服务器所支持的您想调用的方式. 按照HTTP规范,该参数要大写;否则,某些浏览器(如Firefox)可能无法处理请求.有关HTTP请求方法的详细信息可参考http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html W3C specs
第二个参数是请求页面的URL.由于自身安全特性的限制,该页面不能为第三方域名的页面.同时一定要保证在所有的页面中都使用准确的域名,否则调用open()会得到 "permission denied"的错误提示.一个常见的错误是访问站点时使用domain.tld,而当请求页面时,却使用www.domain.tld.
第三个参数设置请求是否为异步模式.如果是TRUE, JavaScript函数将继续执行,而不等待服务器响应.这就是 "AJAX"中的"A".
如果第一个参数是 "POST",send()方法的参数可以是任何想送给服务器的数据. 这时数据要以字符串的形式送给服务器,如下所示:

name=value&anothername=othervalue&so=on 
步骤 2 – "收到!" --- 处理服务器的响应

当发送请求时,要提供指定处理响应的JavaScript函数名.

http_request.onreadystatechange = nameOfTheFunction;   我们来看看这个函数的功能是什么.首先函数会检查请求的状态.如果状态值是4,就意味着一个完整的服务器响应已经收到了,您将可以处理该响应.

if (http_request.readyState == 4) {
    // everything is good, the response is received
} else {
    // still not ready
}   readyState的取值如下:
0 (未初始化)
1 (正在装载)
2 (装载完毕)
3 (交互中)
4 (完成)

接着,函数会检查HTTP服务器响应的状态值. 完整的状态取值可参见 W3C site. 我们着重看值为200 OK的响应.

if (http_request.status == 200) {
    // perfect!
} else {
    // there was a problem with the request,
    // for example the response may be a 404 (Not Found)
    // or 500 (Internal Server Error) response codes
}  在检查完请求的状态值和响应的HTTP状态值后, 您就可以处理从服务器得到的数据了.有两种方式可以得到这些数据:

http_request.responseText – 以文本字符串的方式返回服务器的响应 
http_request.responseXML – 以XMLDocument对象方式返回响应.处理XMLDocument对象可以用JavaScript DOM函数 
步骤 3 – "万事俱备!" - 简单实例

我们现在将整个过程完整地做一次,发送一个简单的HTTP请求. 我们用JavaScript请求一个HTML文件, test.html, 文件的文本内容为 "I'm a test.".然后我们"alert()"test.html文件的内容.

<script type="text/javascript" language="javascript">
    var http_request = false;
    function makeRequest(url) {

        http_request = false;

        if (window.XMLHttpRequest) { // Mozilla, Safari,...
            http_request = new XMLHttpRequest();
            if (http_request.overrideMimeType) {
                http_request.overrideMimeType('text/xml');
            }
        } else if (window.ActiveXObject) { // IE
            try {
                http_request = new ActiveXObject("Msxml2.XMLHTTP");
            } catch (e) {
                try {
                    http_request = new ActiveXObject("Microsoft.XMLHTTP");
                } catch (e) {}
            }
        }

        if (!http_request) {
            alert('Giving up :( Cannot create an XMLHTTP instance');
            return false;
        }
        http_request.onreadystatechange = alertContents;
        http_request.open('GET', url, true);
        http_request.send(null);

    }

    function alertContents() {

        if (http_request.readyState == 4) {
            if (http_request.status == 200) {
                alert(http_request.responseText);
            } else {
                alert('There was a problem with the request.');
            }
        }

    }
</script>
<span
    style="cursor: pointer; text-decoration: underline"
    onclick="makeRequest('test.html')">
        Make a request
</span>
本例中:
用户点击浏览器上的 "请求"链接;
接着函数makeRequest()将被调用.其参数 – HTML文件test.html在同一目录下;
这样就发起了一个请求.onreadystatechange的执行结果会被传送给alertContents();
alertContents()将检查服务器的响应是否成功地收到,如果是,就会 "alert()"test.html文件的内容.

步骤 4 – "X-文档" --- 处理XML响应

在前面的例子中,当服务器对HTTP请求的响应被收到后,我们会调用请求对象的reponseText属性.该属性包含了test.html文件的内容.现在我们来试试responseXML属性.

首先,我们新建一个有效的XML文件,后面我们将使用这个文件.该文件(test.xml)源代码如下所示:

<?xml version="1.0" ?>
<root>
    I'm a test.
</root>  在该脚本中,我们只需修改请求部分:

...
onclick="makeRequest('test.xml')">
...  接着,在alertContents()中,我们将alert()的代码alert(http_request.responseText);换成:

  var xmldoc = http_request.responseXML;
var root_node = xmldoc.getElementsByTagName('root').item(0);
alert(root_node.firstChild.data);

这里,我们使用了responseXML提供的XMLDocument对象并用DOM方法获取存于XML文件中的内容.

May 07

I like this guy

Tony Whitter

Name

Tony Whitter

Bio

Tony Whitter has worked as a software developer, consultant and trainer for nearly 30 years, providing solutions and advice to a wide variety of organisations and industries. He first started programming in 1975 on mini-computers, moved to mainframes in 1980, and on to PCs in 1984. After founding a technology company in the early 1980's, his extensive experience includes four years as the Head of Technology for a quoted multinational software corporation. He now runs his own software development and consultancy firm specialising in the Microsoft .NET platform.

Tony has been using .NET since the PDC Technical Preview release in 2000, and has since developed a number of enterprise level systems using Visual Studio .NET, the first of which shipped in 2001 under the terms of the Go Live Licence for Beta 2. He continues to use Visual Studio .NET extensively on a daily basis and consequently has a wealth of relevant knowledge and experience to draw on. More recently, Tony has authored a popular series of .NET training courses, trained numerous developers in .NET technologies, spoken at major international .NET conferences and is currently presenting on Microsoft's European Smart Client Tour.

As for musical tastes, Tony is definitely in the heavy rock camp, both classic and contemporary. His all time favourite album is Long Live Rock 'n' Roll by Rainbow.

 
March 14

Something You Should Know Before Going to Chengdu

Chengdu

From Wikipedia, the free encyclopedia

Jump to: navigation, search
Location within China
Enlarge
Location within China

Chengdu (Chinese: 成都; Hanyu Pinyin: Chéngdū; Wade-Giles: Ch'eng-tu), located in southwest China, is the capital of the Sichuan province and a sub-provincial city. It is the 4th most populous city in China and a political, cultural and economic centre of southwest China.

More than four thousand years ago, the prehistorical Bronze Age culture of Jinsha (Chinese: 金沙; Pinyin: Jīnshā) established itself in this region. The fertile Chengdu Plain, on which Chengdu is located, is called Tianfu zhi guo (Chinese: 天府之国; Pinyin: Tiānfŭ zhī guó) in Chinese, which means "the Heavenly country".

Chengdu's location in Sichuan

Contents

[hide]

Population

Throughout most of Chinese history, Chengdu has been a city with a large number of people. By 2004 the population was 10 596 900 (5 381 700 males, and 5 215 200 females), which made Chengdu the fourth largest city in China in terms of population, just following Chongqing, Shanghai and Beijing.

There were close to 200 long-term foreign residents (not including Chinese from Hong Kong or Taiwan) living in the city in late 2004, according to unofficial US Consultate estimates.

History

The Dujiangyan Irrigation System located near Chengdu is one of the World Cultural Heritage Sites together with Mount Qingcheng
Enlarge
The Dujiangyan Irrigation System located near Chengdu is one of the World Cultural Heritage Sites together with Mount Qingcheng

In the early 4th century BC, the 9th Kaiming king of the ancient Shu moved his capital to the city's current location from today's nearby Pixian. He was said to have been inspired by the ancient story of King Tai of Zhou, Grandfather of King Wu of Zhou, moving his capital. History recorded King Tai of Zhou's move as "it took a year to become a town; it took 2 years to become a capital". Following this, king of Shu named the new city as "Cheng Du", which means "become a capital" (In Chinese, the word "cheng" means "become", "du" means "capital"). There are, however, several versions of why the capital was moved to Chengdu, and more recent theories of the name's origin point to it as stemming from, or referring to, earlier non-Han inhabitants and/or their languages.

After the conquest of Shu by the State of Qin in 316 BC, a new city was founded by the Qin general Zhang Yi (who as a matter of fact had argued against the invasion). This can be seen as the beginning of the Chinese Chengdu. It was renamed Yìzhōu (益州) during the Han Dynasty.

During the partition following the fall of the Western Han Dynasty, i.e., the era of the Three Kingdoms Liu Bei founded the Southwest kingdom of Shu-Han (Shǔ-Hàn 蜀汉) (220-263) with Chengdu as its capital.

During the Tang Dynasty, both the "Poet God" Lǐ Bó (李白) and the "Poet Sage" Dù Fǔ (杜甫) spent some part of their lives in Chengdu. Du Fu constructed the celebrated "Cǎotáng" (草堂 or grass-hut) in the second year of his four-years stay (759-762). But today's Caotang, a rather sumptuous house in the traditional style, was only constructed in 1078 in memory of Du Fu.

Chengdu was also the birthplace of the first widely used paper money in the world (Northern Song Dynasty, around A.D. 960).

Two rebel leaders, one around the end of Song Dynasty, the other near the end of Ming Dynasty, set up the capitals of their short-lived kingdoms here, called Dàshǔ (大蜀) and Dàxī (大西), respectively.

The Second World War brought an unexpected wave of prosperity to Chengdu as the Guomindang (Chinese Nationalist) government under Chiang Kai-shek fled to Sichuan Province to escape the invading Japanese forces. They brought with them businesspeople, workers and academics, who founded many of the industries and cultural institutions which continue to make Chengdu an important center.

Chengdu was the last city in mainland China to be held by the Kuomintang. Chiang Kai-shek and his son Chiang Ching-kuo directed the defence of the city at Chengdu Central Military Academy, until 1949-12-10 when the People's Liberation Army took the city and the Nationalist Chinese government fled to Taiwan.

Today the industrial base is very broad, including light and heavy manufacturing, aluminum smelting and chemicals. The textile industry remains important, with cotton and wool milling added to the traditional manufacturing of silk brocade and satin.

Alias

  • The Brocade City (Jǐnchéng, 锦城)
    In the Western Han Dynasty (206 BC-23 AD), brocade produced in Chengdu enjoyed great popularity among the royal and elite class in China. Emperor installed Jin Guan (an official in charge of brocade production) to oversee brocade production in Chengdu. Since then, Chengdu has been called "Jin Guan Cheng" (Brocade Official's City), or in its short form, "Jin Cheng" (Brocade city).
  • The City of Hibiscus (Róngchéng, 蓉城)
    In the Five Dynasties and Ten Kingdoms Period (907-960), Mengchang, the king of the Later Shu Kingdom, ordered the planting of hibiscus on the fortress wall surrounding the city. After this, Chengdu started being referred as the City of Hibiscus. Nowadays, the hibiscus is still the city flower of Chengdu. But the last city wall was torn down in the 1960s along with the Royal Palace situated in the middle of the city.

Culture and Folklore

Chengdu natives speak a dialect of Southern Mandarin Chinese. Because of the local dialect's soft tones, Chinese people joke that it is the speech of baby girls, whereas the more rough-sounding dialect of nearby Chongqing is that of baby boys.

In Chengdu the sky is almost always cloudy, and the people are shorter than average; so the locals say that they are so small because the sky is so low. Their is also an old saying "the dogs of Shu bark at the sun" which is still used to decribe someone who, due to unfamiliarity, reacts strongly on something very common.

The Sichuan cuisine is famous for being very spicy, but in fact only slightly more than 30 % of dishes officially labell "local" rely on chili pepper. The reputation for hot food is, however, much older than the use of peppers, which became common only in the 17-18th century.

Chengdu's cuisine is considered to be one of China's most outstanding. The many local specialties include Grandma Chen's Bean Curd (Mapo doufu), Chengdu Hot pot, and Carrying Pole Noodles (Dan Dan Noodles).

An article by the Los Angeles Times (2006) called Chengdu "China's party city". Chengdu outnumbers Shanghai in the number of tea houses and bars despite having less than half the population. The inhabitants have a reputation both within Sichuan and in China at large for having a laid back attitude and for knowing how to enjoy life.

Colleges and universities

Note: Institutions without full-time bachelor programs are not listed.

Music

Astronomical phenomena

For the urban area of Chengdu, the next total solar eclipse will occur on 22 July [[2009].

Chengdu Children's Welfare Institute

The Chengdu orphanage was until recently located at this address:

246 Ying Menkou Road Chengdu, Sichuan Province China 610036

See also

External links

Wikimedia Commons has media related to:


Prefecture-level divisions of Sichuan
Sub-provincial cities: Chengdu
Prefecture-level cities: Bazhong | Dazhou | Deyang | Guang'an | Guangyuan | Leshan | Luzhou | Meishan
Mianyang | Nanchong | Neijiang | Panzhihua | Suining | Ya'an | Yibin | Zigong | Ziyang
Autonomous prefectures: Aba | Garzê | Liangshan
List of Sichuan County-level divisions

March 09

First Principles of Interaction Design

  

The following principles are fundamental to the design and implementation of effective interfaces, whether for traditional GUI environments or the web. Of late, many web applications have reflected a lack of understanding of many of these principles of interaction design, to their great detriment. Because an application or service appears on the web, the principles do not change. If anything, applying these principles become even more important.

• Deutsche (German) Version:
http://meiert.com/de/publications/translations/asktog.com/firstprinciples/

• Nederlands (Dutch) Version:
http://aifia.org/nl/translations/000187.html

• Spanish Version:
http://galinus.com/es/articulos/principios-diseno-de-interaccion.html

Effective interfaces are visually apparent and forgiving, instilling in their users a sense of control. Users quickly see the breadth of their options, grasp how to achieve their goals, and do their work.

Effective interfaces do not concern the user with the inner workings of the system. Work is carefully and continuously saved, with full option for the user to undo any activity at any time.

Effective applications and services perform a maximum of work, while requiring a minimum of information from users.

This work is copyright 2003 by Bruce Tognazzini. Permission to make copies for personal use is granted without reservation, provided this copyright notice remains on the copy. Please contact the author for permission to republish on a web site, to publish in bound form, or to make multiple copies, except that educators and in-house corporate trainers may make sufficient copies for their own students. No commerical use may be made of the work beyond this in-house exception. This notice must be retained together with any version of the work.


Anticipation

Applications should attempt to anticipate the user’s wants and needs. Do not expect users to search for or gather information or evoke necessary tools. Bring to the user all the information and tools needed for each step of the process.

Autonomy

  • The computer, the interface, and the task environment all "belong" to the user, but user-autonomy doesn’t mean we abandon rules.

Give users some breathing room. Users learn quickly and gain a fast sense of mastery when they are placed "in charge." Paradoxically, however, people do not feel free in the absence of all boundaries (Yallum, 1980). A little child will cry equally when held too tight or left to wander in a large and empty warehouse. Adults, too, feel most comfortable in an environment that is neither confining nor infinite, an environment explorable, but not hazardous.

  • Use status mechanisms to keep users aware and informed.

No autonomy can exist in the absence of control, and control cannot be exerted in the absence of sufficient information. Status mechanisms are vital to supplying the information necessary for workers to respond appropriately to changing conditions. As a simple example, workers, failing status information, will tend to maintain heightened pressure on themselves during slow periods, until the moment the work actually runs out. This will stress and fatigue them unnecessarily, so that when the next rush occurs, they may be lacking the physical and mental reserves to handle it.

  • Keep status information up to date and within easy view

Users should not have to seek out status information. Rather, they should be able to glance at their work environment and be able to gather at least a first approximation of state and workload. Status information can be quite subtle: the inbox icon could be switched to show an empty, somewhat full, or stuffed state. This, however, should not be overdone. The Macintosh, for years, showed an icon of a trashcan of imminent danger of explosion if a single document was placed therein. Users quickly formed the habit of emptying the trashcan as soon as the first document hit. This not only turned a single-step operation into a two-step operation (drag to the trash, then empty the trash), it negated the entire power of the trashcan, namely, undo.

As another positive example, a search field icon can change color and appearance to indicate that the search is in progress or has been completed with too many matches, too few matches, or just enough. (Like any element of the interface, just color is not enough; 10% of males show some indication of color blindness. Even a higher percentage may have temporary alterations in perception of blue under varying conditions.)



Color Blindness

  • Any time you use color to convey information in the interface, you should also use clear, secondary cues to convey the information to those who won't be experiencing any color coding today.

Most people have color displays nowadays, but they are not universal. In addition, approximately 10% of human males, along with a rare sprinkling of females, have some form of color blindness.

The cones in the eye are the source of color vision. We have cones separately sensitive to red, green, and blue. If the red ones are not functioning that is called protanopia. If the green are not functioning, that is called deuteranopia. Absence of blue, extremely rare, is called tritanopia.

Protanopia and deuteranopia are the most popular forms of color blindness, collectively called red/green blindness. (There are, in fact, significant differences in their effects, but those differences have no real effect on interaction design.) While tritanopia is far more rare, it nonetheless rules out dependence on yellow-blue differentiation without secondary cues.

Secondary cues can consist of anything from the subtlety of gray scale differentiation to having a different graphic or different text label associated with each color presented.

Consistency

The following principles, taken together, offer the interaction designer tremendous latitude in the evolution of a product without seriously disrupting those areas of consistency most important to the user.

  • Levels of consistency: The importance of maintaining strict consistency varies. The following list is ordered from those interface elements demanding the most faithful consistency effort to those demanding the least. Paradoxically, many people assume that the order of items one through five should be exactly the reverse, leading to applications that look alike, but act completely different in unpredictable ways:
  1. Interpretation of user behavior, e. g., shortcut keys maintain their meanings.
  2. Invisible structures.
  3. Small visible structures.
  4. The overall "look" of a single application or service--splash screens, design elements.
  5. A suite of products.
  6. In-house consistency.
  7. Platform-consistency.

    "Invisible structures" refers to such invisible objects as Microsoft Word's clever little right border that has all kinds of magical properties, if you ever discover it is there. It may or may not appear in your version of Word. And if it doesn't, you'll never know for sure that it isn't really there, on account of it's invisible. Which is exactly what is wrong with invisible objects and why consistency is so important. Other objects are, strictly speaking, visible, but do not appear to be controls, so users, left to their own devices, might never discover their manipulability. The secret, if you absolutely insist on one, should be crisp and clean, for example, "you can click and drag the edges of current Macintosh windows to size them," not, "You can click and drag various things sometimes, but not other things other times."

    "Small visible structures" refers to icons, size boxes, scroll arrows, etc. The appearance of such objects needs to be strictly controlled if people are not to spend half their time trying to figure out how to scroll or how to print. Location is only just slightly less important than appearance. Where it makes sense to standardize location, do so.

  • Inconsistency: It is just important to be visually inconsistent when things must act differently as it is to be visually consistent when things act the same.

Avoid uniformity. Make objects consistent with their behavior. Make objects that act differently look different.

  • The most important consistency is consistency with user expectations.

The only way to ascertain user expectations is to do user testing. No amount of study and debate will substitute.



Defaults

  • Defaults should be easy to "blow away:" Fields containing defaults should come up selected, so users can replace the default contents with new material quickly and easily.
  • Defaults should be "intelligent" and responsive.
  • Do not use the word "default" in an application or service. Replace with "Standard," "Use Customary Settings," "Restore Initial Settings," or some other more specific terms describing what will actually happen.

Efficiency of the User

  • Look at the user's productivity, not the computer's.

People cost a lot more money than machines, and while it might appear that increasing machine productivity must result in increasing human productivity, the opposite is often true. In judging the efficiency of a system, look beyond just the efficiency of the machine.

For example, which of the following takes less time? Heating water in a microwave for one minute and ten seconds or heating it for one minute and eleven seconds?

From the standpoint of the microwave, one minute and ten seconds is the obviously correct answer. From the standpoint of the user of the microwave, one minute and eleven seconds is faster. Why? Because in the first case, the user must press the one key twice, then visually locate the zero key, move the finger into place over it, and press it once. In the second case, the user just presses the same key–the one key–three times. It typically takes more than one second to acquire the zero key. Hence, the water is heated faster when it is "cooked" longer.

Other factors beyond speed make the 111 solution more efficient. Seeking out a different key not only takes time, it requires a fairly high level of cognitive processing. While the processing is underway, the main task the user was involved with–cooking their meal–must be set aside. The longer it is set aside, the longer it will take to reacquire it.

Additionally, the user who adopts the expedient of using repeating digits for microwave cooking faces fewer decisions. They soon abandon figuring out, for example, whether bacon should be cooked for two minutes and ten seconds or two minutes and twenty-three seconds. They do a fast estimate and, given the variability of water content and bacon thickness, end up with as likely a successful result with a lot less dickering up front, again increasing human efficiency.

  • Keep the user occupied.

Since, typically, the highest expense in a business is labor cost. Any time the user must wait for the system to respond before they can proceed, money is being lost.

  • To maximize the efficiency of a business or other organization you must maximize everyone’s efficiency, not just the efficiency of a single group.

Large organizations tend to be compartmentalized, with each group looking out for its own interests, sometimes to the detriment of the organization as a whole. Information resource departments often fall into the trap of creating or adopting systems that result in increased efficiency and lowered costs for the information resources department, but only at the cost of lowered productivity for the company as a whole.

For example, one large California corporation used floppy disks as the medium for collecting benefit enrollment information. At the beginning of open enrollment, each employee would receive a disk with the enrollment applications on which he or she would insert into their computer and run. After asking for the employee’s name, address, phone number, department name, etc., the employee would be permitted to step through all the various benefits, ultimately returning the disk which now contained all their answers and decisions. The IR department then sucked the data off each disk and entered it into their system, all automatically. The IR department saved a great deal of money over the old system, where they had to key in the employee’s decisions from a paper form.

What was the problem? Instead of the IR department bearing the burden of keying in the employees’ decisions, each and every employee now bore the burden of typing in his or her name, address, phone number, department name, etc. The system was just as inefficient as before, but now the cost was borne by all departments, rather than having it concentrated in the IR department’s budget.

  • The great efficiency breakthroughs in software are to be found in the fundamental architecture of the system, not in the surface design of the interface.

This simple truth is why it is so important for everyone involved in a software project to appreciate the importance of making user productivity goal one and to understand the vital difference between building an efficient system and empowering an efficient user. This truth is also key to the need for close and constant cooperation, communication, and conspiracy between engineers and human interface designers if this goal is to be achieved.

  • Write help messages tightly and make them responsive to the problem: good writing pays off big in comprehension and efficiency.
  • Menu and button labels should have the key word(s) first.

Example from a fictitious word processor:

Wrong:

  • Insert page break
  • Add Footnote
  • Update Table of Contents
  • Right:

    Insert:

  • Page break
  • Footnote
  • Table of contents
  • Here, the first example, with its leading words, is actually more informative and more accurate: one does not "insert" a footnote if it is to be placed after all the other footnotes. And one does not insert a table of contents if there is already a table of contents there. Instead, one updates it. Still, the second example will prove much more efficient in time-trials. Why? Because the extra information the first example offers does not outweigh the advantage of being able to scan only the first word in each menu item to find the specific menu item you are after.



    Explorable Interfaces

    • Give users well-marked roads and landmarks, then let them shift into four-wheel drive.

    Mimic the safety, smoothness, and consistency of the natural landscape. Don’t trap users into a single path through a service, but do offer them a line of least resistance. This lets the new user and the user who just wants to get the job done in the quickest way possible and "no-brainer" way through, while still enabling those who want to explore and play what-if a means to wander farther afield.

    • Sometimes, however, you have to provide deep ruts.

    The closer you get to the naive end of the experience curve, the more you have to rein in your users. A single-use application for accomplishing an unknown task requires a far more directive interface than a habitual-use interface for experts.

    • Offer users stable perceptual cues for a sense of "home."

    Stable visual elements not only enable people to navigate fast, they act as dependable landmarks, giving people a sense of "home."

    • Make Actions reversible

    People explore in ways beyond navigation. Sometimes they want to find out what would happen if they carried out some potentially dangerous action. Sometimes they don’t want to find out, but they do anyway by accident.

    By making actions reversible, users can both explore and can "get sloppy" with their work.

    • Always allow "Undo."

    The unavoidable result of not supporting undo is that you must then support a bunch of dialogs that say the equivalent of, "Are you really, really sure?" Needless to say, this slows people down.

    In the absence of such dialogs, people slow down even further. A study a few years back showed that people in a hazardous environment make no more mistakes than people in a supportive and more visually obvious environment, but they worked a lot slower and a lot more carefully to avoid making errors.

    • Always allow a way out.

    Users should never feel trapped. They should have a clear path out.

    • However, make it easier to stay in.

    Early software tended to make it difficult to leave. With the advent of the web, we've seen the advent of software that makes it difficult to stay. Web browsers still festoon their windows with objects and options that have nothing to do with our applications and services running within. Our task can become akin to designing a word process which, oh, by the way, will be using Photoshop's menu bar. Having 49 options on the screen that lead directly to destruction of the user's work, along with one or two that just might help is not an explorable interface, it is the interface from hell. If you are working with complex transactions using a standard web browser, turn off the menu bar and all of the other irrelevant options, then supply our own landmarks and options.



    Fitts' Law

    • The time to acquire a target is a function of the distance to and size of the target.

    While at first glance, this law might seem patently obvious, it is one of the most ignored principles in design. Fitts' law (properly, but rarely, spelled "Fitts' Law") dictates the Macintosh pull-down menu acquisition should be approximately five times faster than Windows menu acquisition, and this is proven out.

    Fitts' law dictates that the windows task bar will constantly and unnecessarily get in people's way, and this is proven out. Fitts' law indicates that the most quickly accessed targets on any computer display are the four corners of the screen, because of their pinning action, and yet, for years, they seemed to be avoided at all costs by designers.

    Use large objects for important functions (Big buttons are faster).

    Use the pinning actions of the sides, bottom, top, and corners of your display: A single-row toolbar with tool icons that "bleed" into the edges of the display will be many times faster than a double row of icons with a carefully-applied one-pixel non-clickable edge between the tools and the side of the display.



    Human Interface Objects

    Human-interface objects are not necessarily the same as objects found in object-oriented systems. Our objects include folders, documents, and the trashcan. They appear within the user's environment and may or may not map directly to an object-oriented object. In fact, many early gui's were built entirely in non-object-oriented environments.

    • Human-interface objects can be seen, heard, touched, or otherwise perceived.
    • Human interface objects that can be seen are quite familiar in graphic user interfaces. Objects that play to another sense such as hearing or touch are less familiar. Good work has been done in developing auditory icons (Gaver).
    • Human-interface objects have a standard way of interacting.
    • Human-interface objects have standard resulting behaviors.
    • Human-interface objects should be understandable, self-consistent, and stable.

    Latency Reduction

    • Wherever possible, use multi-threading to push latency into the background.

    Latency can often be hidden from users through multi-tasking techniques, letting them continue with their work while transmission and computation take place in the background.

    • Reduce the user’s experience of latency.

      • Acknowledge all button clicks by visual or aural feedback within 50 milliseconds.
      • Display an hourglass for any action that will take from 1/2 to 2 seconds.
      • Animate the hourglass so they know the system hasn't died.
      • Display a message indicating the potential length of the wait for any action that will take longer than 2 seconds.
      • Communicate the actual length through an animated progress indicator.
      • Offer engaging text messages to users informed and entertained while they are waiting for long processes, such as server saves, to be completed.
      • Make the client system beep and give a large visual indication upon return from lengthy (>10 seconds) processes, so that users know when to return to using the system.
      • Trap multiple clicks of the same button or object. Because the Internet is slow, people tend to press the same button repeatedly, causing things to be even slower.

    • Make it faster

    Eliminate any element of the application that is not helping. Be ruthless.



    Learnability

    Ideally, products would have no learning curve: users would walk up to them for the very first time and achieve instant mastery. In practice, all applications and services, no matter how simple, will display a learning curve.

    • Limit the Trade-Offs.

    Usability and learnability are not mutually exclusive. First, decide which is the most important; then attack both with vigor. Ease of learning automatically coming at the expense of ease of use is a myth.



    Metaphors, Use of

    • Choose metaphors well, metaphors that will enable users to instantly grasp the finest details of the conceptual model.

    Good metaphors are stories, creating visible pictures in the mind.

    • Bring metaphors alive by appealing to people’s perceptions–sight, sound, touch, and kinesthesia–as well as triggering their memories.

    Metaphors usually evoke the familiar, but often add a new twist. For example, Windows 95 has an object called a briefcase. Like a real-world briefcase, its purpose is to help make electronic documents more portable. It does so, however, not by acting as a transport mechanism, but as a synchronizer: Documents in the desktop briefcase and the briefcase held on portable media are updated automatically when the portable media is inserted in the machine.



    Protect Users' Work

    • Ensure that users never lose their work as a result of error on their part, the vagaries of Internet transmission, or any other reason other than the completely unavoidable, such as sudden loss of power to the client computer.

    (Even here, it has become completely inexcusable that today's computers and operating systems do not support and encourage continuous-save. That, coupled with a small amount of power-protected memory could eliminate the embarrassment of $5000 machines offering the reliability of 10-cent toys.)



    Readability

    • Text that must be read should have high contrast. Favor black text on white or pale yellow backgrounds. Avoid gray backgrounds.
    • Use font sizes that are large enough to be readable on standard monitors. Favor particularly large characters for the actual data you intend to display, as opposed to labels and instructions. For example, the label, "Last Name," can afford to be somewhat small. Habitual users will learn that that two-word gray blob says "Last Name." Even new users, based on the context of the form on which it appears, will have a pretty good guess that it says "Last Name." The actual last name entered/displayed, however, must be clearly readable. This becomes even more important for numbers. Human languages are highly redundant, enabling people to "heal" garbled messages. Numbers, however, unless they follow a very strict protocol, have no redundancy, so people need the ability to examine and comprehend every single character.
    • Pay particular attention to the needs of older people. Presbyopia, the condition of hardened, less flexible lenses, coupled with reduced light transmission into the eye, affects most people over age 45. Do not trust your young eyes to make size and contrast decisions.

    Track State

    • Because many of our browser-based products exist in a stateless environment, we have the responsibility to track state as needed.

    We may need to know:

      • Whether this is the first time the user has been in the system
      • Where the user is
      • Where the user is going
      • Where the user has been during this session
      • Where the user was when they left off in the last session

    and myriad other details.

    In addition to simply knowing where they’ve been, we can also make good use of what they’ve done.

    • State information should be held in a cookie on the client machine during a session with a transaction service, then stored on the server when they log off.

    Users should be able to log off at work, go home, and take up exactly where they left off.

    A private service for doctors, Physicians On Line, does an excellent job with this. Doctors can be 95% of the way through a complex transaction, log off, log in again six weeks later from another part of the world, and the service will ask them if they want to be taken right back to where they were.



    Visible Navigation

    • Avoid invisible navigation.

    Most users cannot and will not build elaborate mental maps and will become lost or tired if expected to do so.

    The World Wide Web, for all its pretty screens and fancy buttons, is, in effect, an invisible navigation space. True, you can always see the specific page you are on, but you cannot see anything of the vast space between pages. Once users reach our applications, we must take care to reduce navigation to a minimum and make that navigation that is left clear and natural. Present the illusion that users are always in the same place, with the work brought to them. This not only eliminates the need for maps and other navigational aids, it offers users a greater sense of mastery and autonomy.

    As with the inherent statelessness of the web (see Track State, above), our job is not to accept blindly what the architects have given us, but to add the layers of capability and protection that users want and need. That the web's navigation is inherently invisible is a challenge, not an inevitability.

    UI Guidelines vs. Usability Testing

    Microsoft Corporation

    October 2000

    Summary: This paper defines UI guidelines and describes the problems inherent in only following guidelines, as well as the danger in being too focused on consistency in your design. It also discusses how usability testing should be used to find out if your product meets the needs of your users and allows them to do their jobs effectively. (4 printed pages)

    Contents

    Introduction
    What Are UI Guidelines?
    Problems with UI Guidelines and Consistency
    Usability Testing
    References & Resources

    Introduction

    During the development of software, the main source of recommendations for designers and developers are user interface guidelines. The first and second parts of this paper describe what UI guidelines are, and the problems inherent in only following guidelines, as well as the danger in being too focused on consistency in your design, especially if poor usability is the result. The final section of the paper describes how usability testing should be what you use to find out if your product meets the needs of your users and allows them to do their jobs effectively.

    What Are UI Guidelines?

    UI guidelines are collections of recommendations that designers and developers follow when creating the user interface for applications. Guidelines can include:

    1. General design principles derived through research. These principles can include the expression of a fundamental design philosophy, assumptions about human behavior, a design methodology, and concepts embodied in the interface.
    2. Standards. Most, if not all, major software platforms have published guidelines for user interface design. One example is the Microsoft® Windows® User Experience, which is subtitled the Official Guidelines for User Interface Developers and Designers.
    3. Local rules or style guide. Many individual companies and organizations have their own set of documented UI rules or styles for interface design that developers in that company use. This is common in large companies especially, where a suite of applications is created internally.

    Problems with UI Guidelines and Consistency

    As an application designer, following UI guidelines might help ensure that the product you give your users allows them to apply skills theyÂ’ve already learned to common tasks and learn new tasks more easily. However, you cannot rely solely on guidelines to ensure the usability of your product. UI guidelines are often too general. On the one hand, to be guidelines they must be somewhat general. Yet itÂ’s that very generality that makes them difficult to apply. When you are trying to make specific decisions within the context of your product, a general set of guidelines might not give you enough information for you to make a decision. An example is when youÂ’re trying to decide between method A and method B of presenting information in a dialog box.

    On the other hand, guidelines can be too specific. For example, a guideline might specify having no more than seven items on a menu. However, adding additional menus might be more confusing to users than having more than seven choices on any one menu. Additionally, guidelines may conflict with one another. For example, one guideline might specify having no more than seven items on a menu, and another might specify keeping similar items grouped together on menus. Which guideline takes precedence? How would you know?

    Nevertheless, when designing an application, visual consistency can be helpful. Consider the consistency you find in Microsoft Word and Microsoft Excel. The user interfaces in these software products are very similar in the basic elements such as menus, toolbars, and placement of buttons in dialog boxes—the surface-level interface. In addition, they are consistent in how they handle many common tasks: formatting text, saving files, and so on. Consistency in these and other elements can make it easier for users to transfer skills when learning different applications. Specific UI guidelines help maintain consistency across different products, but consistency by itself is not the ultimate goal.

    Moreover, consistency in itself doesnÂ’t ensure usability. It is a mistake to think that consistency in the surface properties of the interface will lead to good design.

    These problems really boil down to context: You need to be able to design the user interface for your specific users, goals, and tasks. Guidelines may be a reasonable starting point, but they are only a starting point. The value in UI consistency lies in effective learning, by making it easy to transfer knowledge from another product. However, sometimes ease of learning can get in the way of ease of use.

    You must test your product with users to make sure that your initial design decisions are the best for your users and the work for which they are using your product.

    Usability Testing

    Usability testing is the gold standard by which you can determine if the design of an application meets the needs of its intended users and allows them to work productively. Only by gathering empirical data can you find out how well the user interface for a product fits your usersÂ’ needs and expectations. There are two scenarios for usability testing:

    • If you are a software product vendor, testing real users of your product means you are evaluating for design. Based on how you have designed the application, can users complete the tasks they need to do? Testing real users doing real tasks can also point out if the UI guidelines you are following are working within the context of your product, and when consistency helps or hinders the usersÂ’ ability to do their work.
    • If you are a software product purchaser, you can do usability testing to evaluate a product for purchase. For example, your company might consider buying a product for their twenty thousand employees. Before the company spends its money, it wants to make sure that the product in question will really help employees do their jobs better. Usability testing can also be useful to see if the proposed application follows published UI style guidelines (internal or external). ItÂ’s best to use UI guidelines as an auxiliary, rather than primary, source of information for making purchase decisions.

    References & Resources

    Articles and Books

    • Grudin, Jonathan. "The Case Against User Interface Consistency." Communications of the ACM, October 1989.
    • Microsoft Windows User Experience, Official Guidelines for User Interface Developers and Designers. Redmond, WA: Microsoft Press, 1999. (USBN: 0735605661)

    Organizations

    Other Online Resources

    About the CSS Help Pile

    The Purpose

    There are some amazing resources available for creating powerful standards-based websites (a quick look at this site's inspiration proves that). Unfortunately, often these resources aren't centralized and searching for specific information can often lead to getting lost in a maze of links -- this is an especially daunting task when you're not exactly sure what you're searching for. The css help pile is an attempt to centralize linkage to those resources and tips in a collected and organized manner. The css help pile doesn't intend to compete with these resources, but rather, to promote access and discussion to many of the resources that are out there.

    The Rules

    Don't do what Johnny Don't does.

    • Do link to any CSS resource written and presented in a professional and accurate manner, helpful to a general audience of various skill-levels.
    • Do give yourself credit. If you wrote an article elsewhere, you may post it, but keep it within reason.
    • Don't post anything that may be offensive to other users.
    • Don't be a jerk to other members.
    • Don't use this as a place to advertise any service or product. If someone likes what you have to say, they'll look at your user profile.
    • Don't take credit for someone else's work.
    • Don't abuse the rating system. Make your voice mean something by being fair and respectful.

    The Features

    Besides having easy access to many excellent standards-related information and resources, there are additional features that members get to take advantage of.

    What else is in it for you:

    • Member Profiles A simple member profile is available for you to link to your website. Since the css help pile allows for authors to submit their own essays, members can, within reason, promote their own work through the site.
    • Post Rating All members are welcome to rate all posts. This will help separate the wheat from the chaff, give the members a voice and keep the site fresh.
    • Centralized Link Storage All links, whether they occur in the posts or comments are automatically available to be added to the artypapers centralized bookmark application, scribble. Learn more about scribble.

    The Inspiration / Outside Resources

    The Feedback

    For feedback, please contact rmcox @ artypapers.com. Keep in mind that not all email can be answered, but I'll try my best to get back to you. If you're submitting any criticism of the site, please include a detailed example, URL and description of a possible method to correct the issue.

    The artypapers Connection

    The css help pile relies on the artypapers framework.

    User Experience Design

    By: semanticstudios.com

     

    I've been practicing information architecture since 1994, and from Gopher to Google have seen dramatic changes in the landscape of organization, search and retrieval.

    Through these ten tempestuous years, I've found the infamous three circle diagram to be a great tool for explaining how and why we must strike a unique balance on each project between business goals and context, user needs and behavior, and the available mix of content.Three Circles of Information Architecture

    Figure 1. The Three Circles of Information Architecture

    While this diagram was conceived with IA in mind, it's equally useful for explaining UX. In conjunction with Jesse's