HYXT Blog

we produce valuable software for K12.
clock March 25, 2009 17:27 by author ethan
Subscribing to Content with Web Slices New for Windows Internet Explorer 8

Today, many Web sites provide content updates through Really Simple Syndication (RSS) news feeds. This requires a Web site to duplicate some content as a special XML file, called a feed, that a news reader application can download and check for updates. In contrast, a Web Slice enables users to subscribe to content directly within a Web page; a separate feed file is not required. Users monitor content changes and view the updated portion of the Web page directly from the Favorites bar (the improved Links toolbar) of Internet Explorer.

This article is organized into the following sections:

Key Points

  • A Web Slice uses simple HTML markup to represent a clipping of a Web page. When a user subscribes to a Web Slice, a portion of the Web page is added to the Favorites bar.
  • The Web Slice or the user can specify how frequently Internet Explorer will check for updates from the Web server. The smallest update interval is 15 minutes.
  • To detect a Web Slice on a Web page, Internet Explorer scans for elements that are of class hslice, have an id property, and contain at least one child element with an entry-title class name.
  • All elements marked as entry-content are combined and shown in the Web Slice preview window when the Web Slice button is clicked. To access the full Web page, click the Open button Cc196992.webslice_open(en-us,VS.85).gif in the preview window.
  • The Web page's author can control how Web Slices are discovered and the order of their appearance on the Feed Discovery button. Cc196992.webslice_discovery_button(en-us,VS.85).gif

What is a Web Slice?

The Web Slice is based on the hAtom Microformat World Wide Web link, with a few additional properties. The Web Slice itself uses simple, semantic HTML markup to represent a portion of Web page that can be subscribed to. Annotations can be applied directly to content within the HTML page; additional files can be used for optimization, but are optional.

A Web Slice has four major features:

Discovery

Note  For Internet Explorer to detect a Web Slice, the Web page must be served from a Web server.

Typically, users discover a Web Slice by moving the mouse pointer over it; this is called in-document discovery.

Web Slice shortcut button screenshot.

Figure 1: A shortcut button appears when the mouse pointer is moved over a Web Slice.

Each Web Slice that Internet Explorer detects is added as an entry to the Feed Discovery button Cc196992.webslice_discovery_button(en-us,VS.85).gif, located on the Command bar. Although a Web page can include up to 100 Web Slices, only 20 entries can appear at one time on the Feed Discovery button. You can customize which Web Slice appears at the top of the list by Setting the Default Web Slice.

Feed Discovery button screenshot.

Figure 2: The Feed Discovery button also detects Web Slices.

In-document discovery only applies to Web Slices in the topmost document. Discovery and subscription of Web Slices is disabled for documents within a frameset; however, publishers may provide their own interface for subscribing. For more information, see Customizing the User Experience.

If a user subscribes to a Web Slice, Internet Explorer adds it to the Favorites bar.

Update

To be notified of updates, a user must first add a Web Slice to the Favorites bar. Upon subscription, the Feed Download Engine will periodically update the Web Slice using information from from the Web site. If Internet Explorer detects a change, it will notify the user by making the text of the Web Slice button bold.

By default, Internet Explorer uses the suggested update interval specified by the Web Slice publisher in the ttl property element, if such element exists; otherwise, updates follow the default feed interval, normally every 24 hours. Users can either adjust the update frequency inside the Web Slice Properties dialog box, or update the cached Web Slice at any time by clicking the Refresh button Cc196992.webslice_refresh(en-us,VS.85).gif in the preview window.

Preview

To view a Web Slice, click its button on the Favorites bar. The preview window, also called the flyout, displays the locally cached content of the Web Slice, or an Alternative Display Source, if one has been defined by the publisher.

Note  When testing Web Slices on an intranet, you might need to disable Compatibility View to ensure that the Web Slice is rendered as it will appear on the Web. To do this, open the Page menu, click Compatibility View Settings, and clear the Display Intranet Sites in Compatibility View option button.

Navigation

To quickly access the full Web page, click the Open button Cc196992.webslice_open(en-us,VS.85).gif in the preview window. By default, Internet Explorer returns to where a particular Web Slice was discovered; the publisher can modify this behavior through the bookmark property.

The remainder of this article provides more details about these four features.

Discovering Web Slices

To detect a Web Slice on a Web page, Internet Explorer scans for elements that have certain class names and attributes.

The following properties are required:

hslice property

The hslice element describes a section of a Web page to which the browser can subscribe. The hslice element contains all of the required and optional properties of a Web Slice.

<div class="hslice" id="score"> 

In contrast to traditional style classes, Web Slice class names do not require a CSS rule in the style sheet. Using a space-delimited list, you can combine Web Slice class names with those of other classes.

<div class="hslice forecast" id="weather"> 

id property

In a manner similar to how a named anchor is used, the id attribute is used to identify the Web Slice in a URL. The id attribute must be present on the same element that uses the hslice class.

The id must be unique: if two or more Web Slices on a Web page have the same id value, Internet Explorer will only recognize the first one. If the id value changes, Internet Explorer will no longer be able to identify the Web Slice.

entry-title property

At least one child of hslice must use the entry-title class name. The value of this property maps to the Web Slice button text and the advertised name on the Feed Discovery button. Cc196992.webslice_discovery_button(en-us,VS.85).gif

<div class="hslice" id="main">    <h2 class="entry-title">Seattle Weather</h2>    ...</div> 

It is possible to combine multiple text spans to create a dynamic title that is updated with the Web Slice. The entry-title class can be applied to more than one element; Internet Explorer will concatenate the values in the order in which they appear in HTML.

In the following example, Internet Explorer displays "Seattle Weather 62°" when the Web Slice is updated.

<div class="hslice" id="main">    <h2 class="entry-title">Seattle Weather</h2>    <p>It is currently <span class="entry-title">62&deg;</span>.</p></div>  

Web Slice titles are limited to 128 characters.

Controlling Updates and Notification

To check for updates, Internet Explorer compares the Web Slice against the cached version. The Windows RSS Platform updates feeds and Web Slices on a regular basis: by default, every 24 hours. However, if the Web Slice includes a ttl property, the Feed Download Engine will use the specified value to adjust its update schedule. The frequency can also be adjusted in the Web Slice Properties dialog box.

The following Web Slice elements are used to control the duration and frequency of update checks:

ttl property

The time to live (TTL) value is the number of minutes during which a Web Slice is considered to be up to date. Unless the user has changed the update interval, the Feed Download Engine will consider this value to be the suggested update frequency. For more information, see Understanding the Feed Download Engine and FSS_SUGGESTED.

<p>Updates occur every <span class="ttl">60</span> minutes.</p>

Alternatively, an abbr object with a title attribute can be used to define the TTL. Using this method, the inner text of the object can be applied towards creating a user-friendly representation of time, as shown in the following example:

<p>Updates occur every <abbr class="ttl" title="60">hour</abbr>.</p> 

The minimum interval used by Internet Explorer to check for updates is 15 minutes.

endtime property

Expiration time for a Web Slice. The date and time is specified in the title attribute, leaving the inner text of the element for a user-friendly representation of time, if needed.

<abbr class="endtime" title="2008-07-25T17:30:00-07:00">(friendly date format)</abbr> 

Time values can be expressed using the ISO 8601 international standard for Date and Time on the Internet: Timestamps (RFC3339) World Wide Web link. The date-and-time string follows the common format: YYYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm].

  • YYYY - 4-digit year
  • MM - month, 01 through 12
  • DD - day, 01 through 31
  • "T" - date and time separator
  • hh - hour, 00 through 23
  • mm - minute, 00 through 59
  • ss - second, 00 through 59 (optional)
  • One of the following:
    • "Z" - UTC/GMT ("zero")
    • ("+"|"-")hh:mm - hour and minute of time zone offset

Note that the time zone offset is the actual time difference from UTC and does not automatically account for daylight saving time. For example, the time zone offset for Seattle is "-08:00" in the winter (Pacific Standard Time) and "-07:00" in the summer (Pacific Daylight Time). For best results, convert local time values to UTC.

You can also use the RFC822 date format (with 4-digit years) to include information about daylight saving time. The following encodes the same time as the preceding ISO 8601 example.

<abbr class="endtime" title="25 Jul 2008 17:30:00 PST">(friendly date format)</abbr>  

Alternative Update Source

When a user subscribes to a basic Web Slice, Internet Explorer returns to the Web page to check for updates.

Basic Web Slice graphic.

Figure 3: Basic Web Slice handles both discovery and update.

Returning to the original Web page to update a single Web Slice might be inefficient, especially if the Web page is large. For better control of network use, a Web Slice can declare an alternative source for updates.

a rel=feedurl

Any Web Slice link that specifies a rel attribute of feedurl is treated as an alternative update source. When an alternative source is present, Internet Explorer will subscribe to the alternative source and no longer use the original Web page content to update the Web Slice.

Alternative update source graphic.

Figure 4: Specifying an alternative source for Web Slice updates.

In the figure above, the two Web pages represent the same Web Slice. The user discovers and subscribes to the Web Slice on the original Web page, Basic.html. However, the source of the Web Slice indicates that an alternative update source should be used, as shown in the following example:

<div class="hslice" id="auction">    <span class="entry-title">Auction Item</span>    <a rel="feedurl" href="update.html#auction-update" style="display:none;"></a></div> 

Although an empty link is not visible to users, it creates an extra tab stop and will be read by screen readers. To provide a good user experience, it is best to suppress the display of alternative links, so that users do not accidentally navigate to these Web pages.

Update.html is a simplified Web page that represents just the basic Web Slice. Internet Explorer uses this Web page to get updates and notify users.

<div class="hslice" id="auction-update">    <h2 class="entry-title">Auction Item</h2>    <p class="entry-content">Current bid is $66</p></div> 

The alternative update source might also point to a short RSS or an Atom feed that has only one item. Note that an optional expiration time can be specified using the mon namespace and mon:endtime element, as shown in the following example:

<?xml version="1.0"?><rss version="2.0"    xmlns:mon="http://www.microsoft.com/schemas/rss/monitoring/2007">    <channel>        <title>Auction Item</title>        <link>http://www.example.com</link>        <ttl>15</ttl>        <mon:endtime>2008-12-06T01:00:00Z</mon:endtime>        <item>            <title>Nintendo DS System = $66.00</title>            <link>http://www.example.com/auction.aspx#slice</link>            <description> ... </description>        </item>    </channel></rss> 

Previewing in the Favorites Bar

The following property is optional but highly recommended.

entry-content property

This property defines that part of a Web Slice which Internet Explorer brings to the Favorites bar. When the Web Slice button is clicked, the entire entry-content element is displayed in the Web Slice preview window. The default width and height of the preview window are determined by the size of the container designated as entry-content. Like the entry-title property, a Web Slice can include more than one entry-content, and all elements are combined to create a single preview.

For security reasons, the Web Slice preview does not allow script or Microsoft ActiveX controls; consequently, HTML forms and buttons are not supported. Instead, to perform related actions, you can provide links that include URL parameters. (Navigation occurs within the currently selected tab.) If additional functionality is required, use an Alternative Display Source.

Applying Styles

The following style sources are used to create the Web Slice preview:

  • The inline styles of the entry-content property and its children
  • Style rules defined in the head of the original Web page
  • Imported and linked style sheets

Styles from parent elements are not inherited by the Web Slice preview. In the following example, the Web Slice preview does not display blue text, because the style is applied to the hslice instead of the entry-content element.

<div class="hslice" id="main" style="color:blue">    <h2 class="entry-title">Seattle Weather</h2>    <p class="entry-content">It is raining.</p></div> 

To affect the HTML preview, apply the style to the entry-content element itself:

<div class="hslice" id="main">    <h2 class="entry-title">Seattle Weather</h2>    <p class="entry-content" style="color:blue">It is raining.</p></div> 

Internet Explorer wraps the entry-content in a body element when rendering the preview. This guarantees that style rules applied to the body element of a Web page are also applied to the body of the Web Slice preview. To apply a body style that is not inherited by the preview, use a class name or id to differentiate the body of the original Web page; then, write specific style rules for that element. In the following example, the green background applies to the original Web page but not to the preview.

<style type="text/css">    .MyBody { background-color: green; }</style><body class="MyBody">    <div class="hslice" id="main">        <h2 class="entry-title">Seattle Weather</h2>        <p class="entry-content">It is raining.</p>    </div><body> 

The preceding style guidance only applies to Web Slices extracted from the main Web page. An Alternative Display Source has full control over the style of the Web Slice preview.

Alternative Display Source

Clicking a Web Slice button on the Favorites bar will generate a preview of the cached value of the entry-content element. Because the Windows RSS Platform is used for storage, active content such as script or ActiveX controls is removed. To host interactive Web content in a Web Slice preview, an alternative display source must be used.

Alternative display source graphic.

Figure 5: Specifying an alternative display source.

a rel=entry-content

The alternative display is specified by changing the entry-content element to a link that has the following attributes:

  • href: Location of the alternative display Web page.
  • rel: The value must be entry-content.
<div class="hslice" id="auction">    <span class="entry-title">Auction Item</span>    <a rel="entry-content" href="display.html" style="display:none;"></a></div> 

When a user opens the Web Slice preview window, it will navigate to Display.html; the cached copy of entry-content is not used. The alternative display source preview should be small enough to fit into a 320-by-240 (WH) space, on a 96-dots per inch (dpi) screen. The preview window does not automatically resize to the dimensions of the Web Slice, if a different size is used.

The following are not supported in an Alternative Display Source preview:

  • Dialog boxes and popups — Script alerts, HTML popups, and dialog boxes such as Print or Add a Favorite are all blocked. No windows of any kind can be launched from the Web Slice flyout.
  • First-time installation of ActiveX controls — The preview window does not display an information bar (gold bar), so the publisher needs to ensure that any ActiveX objects are enabled for the domain beforehand; otherwise, a broken control icon (red 'X') is displayed. The same restriction applies to downloads or anything else that might require user interaction with the information bar.
    Note  Alternative text inside the object tag is displayed if the ActiveX control is not installed. Publishers can use this text to provide download instructrions, for example.
  • Calls to window.external — There is no valid external object associated with the preview window.

When using an alternative display source, all hyperlinks in a Web Slice preview will navigate within the preview window. For links to open in the current tab, specify that they be opened in a new window, as shown in the following example:

<a href="gotosite.html" target="_blank">view full site</a>

For the server, consider using the no-cache HTTP header response for the Web page that acts as the Alternative Display Source. This will ensure that users previewing a Web Slice will see the most recent content.

Using Both Alternative Update and Display Source

It is also possible to combine alternative update with an alternative display.

Alternative display and update graphic.

Figure 6: Using both alternative update and display source.

For this scenario to work, the code for Basic.html only needs to include the alternative update source, as shown in the following example:

<div class="hslice" id="auction">    <span class="entry-title">Auction Item - Alternative Update</span>    <a rel="feedurl" href="update.html#auction-update" style="display:none;"></a></div> 

Update.html will then provide information about the alternative display source:

<div class="hslice" id="auction-update">    <h2 class="entry-title">Auction Item - Alternative Display</h2>    <div class="entry-content">Current bid is $66</div>    <a rel="entry-content" href="display.html" style="display:none;"></a></div>  

Navigating to a Different Web Page

When you click the Open button Cc196992.webslice_open(en-us,VS.85).gif on the Web Slice flyout, Internet Explorer normally navigates to the Web page where the Web Slice was first found or, alternatively, to the the Alternative Update Source if one was specified. The publisher can also modify this behavior by specifying another location altogether, using the bookmark property.

bookmark property

The bookmark property causes the Open button to navigate to the specified location when clicked. The following example opens Location.html.

<div class="hslice" id="auction">    <h2 class="entry-title">Auction Item</h2>    <a rel="bookmark" href="Location.html" style="display:none;"></a></div> 

Customizing the User Experience

The following advanced techniques help you customize how users interact with the Web Slices on your Web site.

Using the Web Slice Icon

Web Slice Icon (64x64)

The Web Slice icon is intended to provide a common visual cue that a Web site includes Web Slice functionality, which makes content from the Web site available for subscription. It must be used in accordance with the Web Slice Icon Guidelines. Developers can download .png and .gif renderings of the Web Slice icon in various sizes.

Setting the Default Web Slice

The Feed Discovery button Cc196992.webslice_discovery_button(en-us,VS.85).gif lists each Web Slice in the order it was parsed from the document by Internet Explorer. A publisher can choose which Web Slice is presented first, thus promoting one particular Web Slice to represent the whole Web page. For example, a bookseller might mark up a list of top sellers, as well as book reviews on the same Web page. It might make sense for the bookseller to promote the top-seller Web Slice as the default, because that facilitates the financial goals of the Web site whereas book reviews merely increase readership.

To specify the default Web Slice, add a link element in the head of the document:

<link     rel="default-slice"    type="application/x-hatom"     href="#auction" /> 

The link element requires the following attributes:

  • rel: The value must be default-slice.
  • type: The value must be application/x-hatom.
  • href: The #id of the Web Slice within the current document.

If the default Web Slice is not found within the current document, the link is ignored.

Disabling In-Document Discovery

To disable in-document Web Slice discovery for all Web pages, in the Internet Options dialog box, click the Content tab, then click the Settings button for feeds, and then clear the Turn on in page Web Slice discovery check box. Web developer can disable in-document discovery for the current Web page by adding the following meta element to the head of the document (all values are case-insensitive):

<meta name="slice" scheme="IE" content="off"/> 

If in-document discovery is disabled, the Feed Discovery button Cc196992.webslice_discovery_button(en-us,VS.85).gif will still indicate that the Web page includes a Web Slice, but the Web page must provide its own UI for discovering and installing it. To prompt users for installation, call window.external.AddToFavoritesBar().

Creating Dynamic Web Slices

Although Web Slices work well with static content that can be downloaded to be viewed at a later time, creating a Web Slice for content that changes in response to form data, Asynchronous JavaScript and XML (AJAX), or user interaction is more difficult. For example, a Web Slice might offer movie listings for all theaters within a few miles of the user's location. Or, a Web Slice might offer a list of newly released books that match a user's search criteria. To update Web Slices like these, Internet Explorer would have to recreate the conditions that generated them.

If you dynamically create or update a Web Slice after the document has loaded, you must provide an Alternative Update Source and/or Alternative Display Source to handle the preview. Pass URL parameters to the external resource so that it can generate a response based on the user's input. Finally, after updating or inserting a Web Slice, call window.external.ContentDiscoveryReset() to refresh the list of Web Slices and feeds on the Feed Discovery button. Cc196992.webslice_discovery_button(en-us,VS.85).gif

Authenticating the User

If your Web site requires user authentication, consider providing a way for the user to save login credentials in a cookie that can be used to identify the user after the browser is closed. Although user name and password settings are available in the Web Slice Properties dialog box, they are only used for HTTPS+Basic and HTTP/HTTPS+Digest authentication. Cookie-based authentication is more broadly supported, and will work regardless of the security settings of the Web Slice.

Note  HTTP-based authentication is not supported for Web Slices that use an alternative update and/or display source. For these scenarios, use cookie-based authentication.

Because some users will choose not to persist their personal information, your Web Slice should explain how to log into your site if authentication was unsuccessful. If you use an Alternative Update Source, then return a single item feed that contains this information in the item's description.

Related Topics


clock November 27, 2008 14:19 by author Sky Jia (贾超)

By robert at 2008-11-11

原文地址: http://www.tianya8.net/zblog/post/90.html

  

1、关注用户任务

1.1、告诉我填写这个表单是做什么的?

如果这是一个注册表单,你需要告诉我注册能带给我什么;如果这是一个联系网站管理员的表单,你需要告诉我管理员将如何处理我的信息。

1.2、表单提交后,不要把我晾在一边

是的,还有很多用户在提交表单后不知所措,没有告诉我提交是否成功,或者提示我提交成功,然后就把我晾在某个地方。

虽然很喜欢mister-wong的界面风格,但是当我注册完了之后,我还是不知道该干什么。Errr...那么我现在要做的就是去收邮件吗?

1.3、如果表单较长,创建表单导航

在线购物是一个很好的例子,几乎所有的购物网站都建立了"挑选商品——查看详细信息——添加购物篮——支付——订单完成"或与之类似的全局导航。这样当用户在购物流程中并不会觉得自己是在一个很长的表单中,而只是为了一个特点的目标而进行的必要的点击。

即使是在一个表单里,如果表单包含多个任务,也应该将其分步骤进行。参考blogger.com的注册表单:

为每个任务添加说明。也许你需要了解一下fieldsetlegend属性。

2、必要、简单

2.1、自以为是技术约束

我实在不能理解要求用户"必须使用字母是数字组合作为密码"有何意义,尤其是在银行网站上,尽管我能理解这些网站对于安全性的考虑,但我仍然因此必须对于自己的常用密码进行适当的修改以适应要求,这由此产生另外一个问题——我经常忘记我的密码,比如adsense

2.2、站在你的用户角度想问题

我同意不能理解当我填写一个在线表单投诉问题,却要我留下电话号码和地址?OMG,你们的营销人员是第一天上班吗?如果我愿意电话联系,我难道看不到你们网站底部的800电话号码吗?

2.3"我不是很聪明,但也不会太笨"

对不起,我不需要你告诉我邮编是5位数字。

web2.0风潮吹遍神州大地的时候,我们的网站设计刮起了一股清新之分,与之相应的,表单设计却变成了冗余与累赘的试验田。看看163或者zhuaxia的注册表单,你就会明白什么叫过尤不及

2.4、如果使用email作为用户名,密码重复是否必要?

对于传统的注册表单而言,密码重复验证非常必要,理由很简单,对于非可见的输入,在没有其他取回密码的机制下,保证用户不会输入错误只能采用这种简单的验证机制。

但是现在很多新的互联网服务都开始采用email作为登录名,这就给表单设计提供了一个新的思考方式:当密码可以方便的重新取回,那么让人厌倦的密码重复验证是否还是必不可少?不少网站已经开始将repeat password从页面上去除了,下面是twitter的注册页面,何其清爽:

3、减少信息迷惑

3.1、用星号区别必填和选填项

尽管这已经是几乎所有guidelines的标准,仍然有很多网站并没有在意这一点。看看pownce的注册表单:

为什么不直接告诉我这些是必填的,一定要我点击提交后再告诉我这些非填不可

3.2、表单指引务必明确而直接,不要故弄玄虚,不是所有用户都有兴趣和你玩。

在我随机挑选测试的注册表单中,xing无疑是做的最糟糕的。糟糕的并非界面设计或代码结构,而是失败的本地化。

作为一个读过十几年语文并且一直在互联网里生活的网民,我对于这个表单的疑问实在太多了。

我可以理解xing原本是国外网站,但是你要在中文圈里混,至少也要适应一下姓在前名在后的中国传统吧。好吧,姑且认为要你为中文用户修改页面比较麻烦,那么能不能请你告诉我,what's the meaning of"城市(商务)" and "身份"

4、防止用户错误

4.1、与其在提交后检测,不如在提交前检测

可以参考3.1里的pownce的案例。事实上,现在推出的大多数web服务已经越来越多的使用javascript来进行表单验证,jqueryprototype等也都有很多好用的表单验证插件。

记得,用户最厌倦的情况之一就是:当提交表单后刷新页面,然后告诉他有信息填写不完整和错误,然后密码部分被清空要用户重新填写。

4.2、如果提供验证码,不要太过分

之前看"史上最强验证码 "时,其实颇觉理所当然,那些网站本身就是服务某些专业人士,因此问你Na2S4O6的中文名称是什么也无可厚非,那大门本来就是对俺们关闭的。但是你要做普罗大众如我辈的web服务,也忒考验俺辈的耐心了吧。

4.3、千万,千万,千万不要使用reset按钮

有什么理由要用户将刚刚填写的所有信息全部清空?

5、提供反馈

5.1、对于已完成的任务进行提示和鼓励

在适当的时候给用户一点掌声和鼓励会起到很大的效果,就行《使命召唤2》开始的那个苏联教官在我的射击课上跟我说的,"很好,就差一点了,继续训练吧"

对于网站而言,一个典雅而有效的例子就是用百分比来描述表单的完成率,你会发现用户有一种使用时的"洁癖",拒绝任何的不完美,因此当看到这个70%时,他会迫切的要将其变为100%,是的,你的目的达到了。

5.2、不要恐吓用户

对不起,用语夸张了点,但是大多用户都遇到过"可怕的"alert窗口的情况。当你提交一个表单,滴的一声弹出一个灰色窗口,"weqwew32673712323错误,请重新输入"

于是你心惊肉跳,哪里错了,哪里错了?友好一些的就告诉你Email地址填写不合法,不友好的就干脆就是一个只给程序员哥哥看的错误代码。俺的小命啊,只是填写一个表单吗,用得着这样吓俺幼小的心灵吗?


clock November 27, 2008 14:17 by author Sky Jia (贾超)

Article copyright by Jakob Nielsen

Jakob Nielsen版权所有

作者:Jakob Nielsen

译者:UCD翻译小组Link
原文地址:
http://www.useit.com/alertbox/20000416.html 

大在大部分网页表单中,移除重置按钮会有效提升可用性,同样的,取消按钮对网页的意义也不太大。

启发式的交互设计中最基本的一点是在任何情况下为用户提供"紧急出口",离开当前环境。撤销功能是最好的解决方法之一,基本原则只是告诉我们要提供撤销功能但并没有告诉我们怎么做。往往,不同的原则适用于不同的用户界面:

  • 在基于窗口环境的用户界面中,取消按钮可以让用户通过对对话框的操作,实现探索性的学习。相比较而言,你在老些的系统中下达了错误的命令往往意味着你将陷入绝境。
  • 在编辑系统中通常会有撤销命令来使文档回复到用户编辑之前的状态。有时,多级撤销和重复命令是很有用但又令人困扰的功能。

网页试图通过重置和取消按钮来复制以上特性,但用户往往更愿意通过浏览器的后退按钮来离开误入的页面。

不要使用重置按钮!

如果去掉所有重置按钮,网页将变为一片净土。这些按钮非但不能帮助用户,还可能伤害到他们。

重置功能会把用户输入到表单中的所有信息清除掉,但为什么用户要使用这样的功能呢?用户浏览网页的时候会在页面之间频繁转换,他们很少重复访问相同的表
单,因此,表单在呈现给用户的时候就是干干净净的。而当用户使用相同的进程重新访问一个表单时,编辑原有的数据往往比重新填写更便捷。

重置按钮会在以下三个方面伤害用户:

  • 最糟糕的问题是用户想点击提交却误点了重置,他们填写的信息将一下子付之东流。
  • 在表单底部提供两个按钮将混淆交互界面并让用户难以搞清下一步要做什么。用户会把一小部分时间浪费在浏览无用的按钮和决定哪一个才是该点的上面。
  • 当用户希望在表单中修改已经填写的信息时,面对额外的按钮会做出以下两个选择:
    • 在输入框中修改不正确的内容
    • 点击重置,在清空的输入框中重新填写内容

额外的选择会迫使用户进行额外的思考,而使用最佳的交互方式所节省的时间往往小于用户考虑决定使用最常用的方式所花费的时间。这将浪费用户一到两秒的时间来从中取舍,这也是尽量不要让用户选择的原因。(一秒钟听起来没什么了不起,但它意味着每年一亿美元左右的生产力浪费。)

让所有输入可撤销

去掉了重置按钮,我们有必要为用户提供其他的修改错误输入的方式。对于文本框和选择框来说,用户可以随时输入或恢复到最初的状态。

不幸的是,有些使用了非标准风格的单选框(radio button)和下拉菜单的表单并没有提供回到初始状态的选项,而这是网页设计的典型错误之一。往往,一旦用户选择了一个选项,就没有办法作出"什么都不
"的选择。永远别忘了在单选按钮和下拉菜单中加入明确的默认选项,否则你用户的麻烦就大了。(请参考
复选框和单选按钮设计的13条军规

例外:重复输入表单的重置按钮

当同时满足以下两个条件时,重置按钮将发挥它的作用:

  • 表单总是由一个用户反复填写
  • 填写的内容每次都有较大差异

即使某个用户经常使用一个表单,当填入的数据每次都很相似时重置按钮也不是十分必要的。在这种情况下编写原有的数据要比重新来过简单得多。

保守地使用取消按钮

网页并不像软件一样拥有对话框,而是一个用户游走于各个页面之间的导航环境。自从超文本导航成为用户的使用习惯,人们开始依赖后退按钮来逃离窘境。每当用户误入了不想进入的页面,他们就会自然而然地把鼠标放到后退按钮上。

因为后退是网页浏览中很常规的行为,单独的取消功能也就不是那么重要了。如果用户不喜欢当前的页面,可以肯定,后退按钮就要出场了。

当用户害怕自己提交了不想提交的信息时,可以为他们提供取消按钮,这样能够提供给他们比直接退出更安全的的感觉。

在需要多步填写的表单中用户会在超过一个页面上进行输入,这时取消按钮是个不错的选择,因为后退按钮不会撤销之前的输入。

当然,不能指望用户每次都点取消,应该有一个后端/后台逻辑来处理点击后退来中断多步输入的行为。额外的复杂性是我不推荐在网页中加入复杂应用的原因之一,更好的办法是使用另一种形式来实现。

购物车中的移除按钮

很有必要在购物车中添加特殊的按钮来帮助用户移除商品,我们无法知道用户是不是了解他们能够通过购买"0"件商品来取消购物。(但是反正这个小技巧也不影响其它用户,所以还是应该实现出来给懂的人用)

(作者:请参考拙作购物车的可用性,来了解更多表单设计中的规则)

到底什么时候使用用取消按钮就

Lisa Padol 问道:

"当你讨论取消和重置按钮时并没有提及停止(即在载入时停止页面)和刷新按钮,不是吗?

  

我觉得这不仅是可以接受的,也很必要为比如下载文件的过程加入取消按钮。"

她的假定完全正确,浏览器的"停止"按钮很好地加强了用户的控制权。而对于文件传输和其它一些得花好几秒钟的操作也应该这样做。设计师必须给Applet(网页上的Java应用)和

其它耗时的设计元素都加上停止功能。


clock November 27, 2008 14:16 by author Sky Jia (贾超)

Article copyright by Gabriel Svennerberg
Gabriel Svennerberg
版权所有
原作者:Gabriel Svennerberg;译者:
UCD翻译小组mysmth2003

原文网址:http://www.svennerberg.com/2008/09/the-use-of-buttons-in-web-forms/ 

动作按钮存在于每个web表单的底端。它们太平常了,以至于我们甚至不能仔细思考实际怎么去设计它们。从一堆伟大的易用性思想和我自己的经验中可收集到的信息中,我想提出一套做法来让这种设计更高效些。

Position 位置

根据Jakob Nielsen(雅各布·尼尔森)的观点,按钮的规则并没有那么麻烦。每个位置都有它的优点和缺点。而重要的一点是一致,如有可能遵照GUI标准平台的规范。

在网络世界以外,也有GUI标准,问题是他们在不同的平台上是不同的。在Windows平台上,GUI规范表明"确认"应该在左侧,而"退出"在右侧。而在苹果平台下,恰恰相反。






web中,并没有固定的标准要求怎么去做,所以我们必须聪明地找出什么位置是最合适的。
Luke Wroblewski
(卢克·罗博乌斯奇)在《网络应用表单设计》一文中专注于这个话题的探索。他建议把首要动作"确定"放置在表单的左侧,次要动作"退出"放置在表单右侧。
他进一步在《网络表单设计》一书中,阐述了从易用性对比测试中的发现:测试表明主要动作在左侧而次级动作在右侧具有更快的绩效。



Robert Hoekman, jr.
(罗布特·霍克曼)也思考了不少关于这方面的内容,并且在《设计片段》(Designing the Moment)提出他的想法。
他同意Luke Wrobleski的关于首要动作在表单左侧的观点,这样做的原因在于可以形成一条很好的线,视线可以跟随,推下表格,从而轻松扫描。另一个原因在于如果用户用tab键(键盘左上方的制表符)操控表单,首要动作可以先于次要动作在表格命令下进行。

Labeling the actions 标记动作


Robert Hoekman, jr.
也有一些关于按钮标记的想法,比恰当标记"确定""退出"按钮
更好的办法是直接标记实际的动作。如果执行一个"存储一个笔记"save a note)动作,为什么不让"存储笔记(save a note"按钮替代"确定"按钮呢?
Jakob Nielsen也建议按钮上的文字要说明这个按钮究竟要干嘛,不要只用类似于"确定"这种空泛的文字。 这么做用户会更有自信地使用,因为他知道当他按动按钮的时候将会发生什么。

Visual distinction 视觉的差别
另一件事是Robert Hoekman,jr.讨论视觉上区分动作,使得用户能够很轻松地做出正确的选择。

Luke Wroblewski也推断出,做首要的动作要比次要的动作更突出。在易用性测试的调查中,他发现如果首要比次要动作有一点不同的设计的时候,用户会花多一些时间去完成表单。而另一方面,用户会更有信心,较少做出错误的选择。他建议使用不同颜色制作按钮或者让次要动作变成一个普通的链接。

一个简单的方法从视觉上区分两点:我经常去做,则使用粗体(bold font weight),放在首要动作上,而一个正常的字体放在次要动作上。

Robert Hoekman, jr.推荐"对次要动作使用一个普通的链接",他的理由是说这可以更清楚的判断谁是首要的。但是它也适用于费茨法则,即距离和目标尺寸设多大可被触及并且点击——目标越大会越快些(被触及、点击)。首要动作因此应该比次要动作大一些。

The Reset button 重置按钮
重置按钮被用来重新设置一个完整的表单。这种早期相当常见的应用,到如今却很少被看到。不过我想我也说一些关于这个按钮的话,当它经常被当作成对的按钮出现在表单中的时候。在多数情况下,这个按钮最好是完全不用。所有经常错误点击重置按钮的用户因此会删掉他们输入的一切内容。(我在
Confusing Northface contact form中写过),并且认真地说,你需要多频繁重设整个表单,并且如果你这么做,会产生怎样的问题。这个按钮所具有的风险简单要同可能的收益做一个大的对比,加之在很多情况下,会对表单增加更大的混乱。
正如Jakob Nielsen放到他的警示框专栏《复原和退出按钮》中的话:

    
网络将会变成更开心的地方,如果所有的重置按钮被虚拟的移走之后。这种按钮几乎不能帮助用户,反而会伤害他们。可能唯一的时间是当重置按钮被请求的时候,是当一个表单被同一个用户重复使用的时候,并且每次输入的信息是不同的。

关于重置按钮Luke Wroblewski有一个想法,他认为如果你提供一个也应该提供一个撤回(undo)选项。用户点击重置按钮重新恢复表单,可以起到撤回的作用。此举意味着你不得不暂时的存储表单数据,但为用户的方便提供了很小的价值。

Best practices 最佳方法

基于以上所有的观点,加上我使用并设计web表单的经验,我提出一些好办法。

  • Position the Primary action to the left 首要动作放在左边 
    把按钮放在表单的左边,可以使得眼睛跟随一条清晰的路线。通过首要动作放在次要动作的左边,也便于tab次序。
  • Label the actions in a natural language 标签动作用自然的语言 
    通过描述实际动作发生,用户更舒适的感受他期待使用的内容。
  • Make the Primary action stand out 使首要动作凸显 
    这样可以让用户更轻松选择他们想要的选项,而不会从一堆选项中艰难的发现。
  • (Almost) Never use a iReset button (几乎)不要使用重置按钮  
    重置按钮经常会伤害用户,而不会太多帮助他们。唯一的可能是他们在表单中需要它们,是同一个用户反复再三做不同输入的时候,即一旦你使用了"重置",也就意味着为用户提供了一个撤回功能。

你同意我的结论或者对此有不同观点,请分享吧!

关于作者
Gabriel Svennerberg
是一位网络开发人员和互动设计师,35岁,自从1996年就从事web的工作。起先自我雇佣,后来在VäxjöVarberg Stockholm等不同的代理商工作,如今为
Saab Security构建网络应用以及强化用户体验工作。
http://www.svennerberg.com/about/


clock November 24, 2008 12:12 by author Sky Jia (贾超)

by Nik Cubrilovic on May 29, 2008


The next-gen web is starting to gather pace, as this week 
MySpace integrated Google Gears, Yahoo! announced their new BrowserPlus product and Google launched a browser-based edition of their 3D Earth product. Technologies and formats such as AIR,SilverlightJavaFXGearsXULWeb Applications 1.0 (DOM5, HTML5 etc.) allow developers to accelerate beyond AJAX and towards a new generation of web applications with better performance, more functionality and tighter desktop integration.

Developers and users are now presented with more web technology choice then ever before; "DLL hell" has been superseded by "plug-in hell", as a variety of companies present their versions of what the next-gen web will look like. But on the web, such choice can come at a cost to both users and developers. More than a decade has passed since the first battle over web formats, back then it was Microsoft, Netscape, Apple, AOL and others laying different foundations in the form of browsers, scripting languages, web servers and more. The legacy of that battle is still being felt today, as Javascript developers rely on whole libraries to assist them in developing cross-browser code and CSS developers depend on a catalog of hacks so that their sites can look consistent across different browsers.

With the new rich web application technologies still in the development phase, there is an opportunity to not repeat the mistakes of the past and instead take a standards-based approach. Thankfully during the course of the previous decade companies such as Microsoft became more receptive to open standards, data portability and cross-platform support. Having broad support for open standards simplifies technology for both users and developers, but it is obvious that not all of the currently announced technologies, such as those listed above, will

During the course of a series of posts here on Techcrunch we will look at various elements that make up the next-gen web and evaluate the options available, current support as well as how well standards are being adopted. In light of the recent announcement from MySpace that they are using Google Gears in their application, in this first post we will evaluate browser-based local storage cache's.

Browser-based Local Storage

As web applications became more popular there was a general demand for an ability to run web-based applications offline. The first such solutions that could work without requiring a browser plugin or separate application were those that relied on the caching headers within HTTP to store objects within the browsers cache. Javascript libraries such as Dojo implemented support for offline web applications using the same principals, but applications were very limited in scope as there was no easy way to store structured data on the browser (Dojo now also abstracts a variety of other storage engines including Gears- tip: Dylan) .

In May of 2007, Google launched Google Gears, a browser plugin that allows web applications to synchronize data into a local data store and then allow web applications to function offline. At the launch of Gears, Google Reader was adapted to support it, and the emphasis of the pitch for Gears was about offline application access. What was less known is that Gears is a lot more than just offline access, as it provides three primary functions:

  • Caching of resources (HTML pages, images etc.)
  • Structured data storage in a database
  • Asynchronous background worker threads

The part of this we will focus on here is the local object and structured data storage. Gears provides these functions via a Javascript API, which can be accessed by any web application. The structured storage is provided by Sqlite, a popular lightweight RDBMS. With the local database, the developer can not only perform queries and inserts to record new data, but also more complex SQL like joining between tables etc. Although you can have multiple applications using Gears, each app runs in a sanboxed environment with a domain-based security model (similar to cookies and Ajax requests). Sqlite has been built into Firefox since version 2.0, but its API is only accessible from an add-on or a core Firefox component. The Gears plugin bridges that gap and makes it available within the client scripting environment.

Before Gears was launched, the Web Hypertext Application Technology Workgroup(WHATWG) had begun work on its Web Applications 1.0 draft spec, which included structured data storage as part of HTML5. The current draft spec from the working group includes definitions for a Database object for accessing and querying a local data store. The details of the implementation are left up to the vendor, but the API is detailed in the spec. Firefox will be implementing parts of the same storage API from the WHATW spec in version 3.0 of the browser, which is currently available as a preview release. The key components of the WHATWG spec are:

  • ApplicationCache - for storing objects in the local browser cache (and checking them)
  • navigator.onLine - check if the browser is online or not (and use cache plus local data store if required)
  • Storage interface and events - used for storing name and value pairs via thesessionStorage DOM attribute.
  • Database interface - used for connecting to the local database. Supports SQL (or a subset thereof, depending on the server used), versioning, error events via callback
  • Threading and Callbacks - so that multiple requests can be sent to the local data store asynchronously.

Implementing local storage, caching and offline access are relatively easy. The application can first check to see if these functions are supported, and then setup the local cache by synchronizing the users data in background processes. While a thread is running, either uploading or downloading, you can query it to check on its status to provide the user with feedback (eg. a progress bar). Once the data is local, by running database queries on the local machine developers are able to drastically improve performance. Currently many web applications use the browser as only a presentation layer, for eg. a spreadsheet application may do a round-trip back to the server to work out even elementary calculations such as=1+1. By utilizing the local data store and client-side code, the developer is able to offload processing and storage to the client and provide a much smoother, desktop-like experience at the same time.

Current And Future Support

The issue is that the majority of the WHATW specification was written after Gears was released, so the Database and LocalServer objects used in Gears are not compatible with WHATW - for now. The good news is that Google have come out and fully backed the storage portions of the WHATWG HTML5 spec, so developers with apps running on Firefox 3 with Gears installed will have a choice to use either the native implementation, or the Google implementation. Google go on to say that they will likely offer extra features as an incentive for developers to continue to target Gears over-and-above the HTML5 implementation (features such as desktop shortcuts, etc.).

Other alternatives for local data storage, such as Flash local storage, are completely incompatible with the WHATW specification. The developers at WebKit were very quick to announce that they have started implementing the storage portions of the HTML5 spec also. It is currently available in nightly builds, so in the near future we will see support in both Konquror and Safari. Opera have also announced similar plans and they are actually leading everybody when it comes to implementing HTML5 and Web Forms. Yahoo! BrowserPlus was only announced yesterday, and it is currently unclear wether their local storage support is compatible with the specification as laid out by the working group.

Local storage is a major new feature of the new web API, and developers will not only have consistent support across browsers but will also have the option of Google Gears (which is already available) as well as Yahoo! BrowserPlus (depending on how it works). There is just one browser maker missing in this discussion so far and that is Microsoft. Microsoft have released an early preview of IE8 and announced a raft of new features, a lot of which are based on open standards such as better CSS and Javascript support (with a more standardized object model). The big question is wether we will see consistent local storage support from IE8 following the same spec as the other browser vendors. The IE team have announced that IE8 will support DOM Storage, but that is only part of the overall local storage spec (ie the Storage object described above only).

Overview of Current And Future Support

  

Gears

BrowserPlus

Firefox

IE8

Webkit

ApplicationCache

soon

detect onLine

LocalServer

Storage

Database

Threading

SQL

Notes: Once details of BrowserPlus are known the table will be filled in. Gears has pledged to adapt the standard. IE8 has only announced partial support. WebKit have most functionality available in their nightly builds. Both Flash and Silverlight have some form of local storage but not the HTML5 standard API.

It is very rare that a new technology such as local browser storage is so broadly advocated and supported mostly under a single spec. While Microsoft may not have yet announced full support, there is no doubt that they are heading in the right direction. It is also encouraging that implementations from Google Gears and Firefox 3 will follow the working group spec for HTML5. While the new versions of these browsers will not be available broadly for a while longer, Google Gears is available today and since all vendors are targeting the same API, developers can today confidently target and write for the Gears storage API with confidence - something that was almost impossible to do not so long ago.

So with local browser storage and caching, so far the open standard is the winner. The alternate solutions are likely to fall by the wayside or will adapt to implementing the same API.


clock November 20, 2008 18:19 by author Sky Jia (贾超)

作者:Luke Wroblewski & Etre
译者:
UCD翻译小组Li Douis
原文地址: http://www.lukew.com/resources/articles/PSactions.asp

近几个月来,我一直忙于我的新书《网页表单设计最佳实践》,使用大量的真实案例数据对一些设计规范进行提炼。接近尾声的时候,我有幸参加了Etre设立于伦敦的可用性团队组织的一些研究工作。这些研究主要是针对网页表单设计的特定元素,进行了一些眼动追踪和可用性测试。其中一项测试,重点考察了网页表单中主次要动作的差异。

一个典型的网页表单,通常带有一些"结束性"动作-比如【提交】、【保存】或者【继续】-用于完成表单任务。因为这些动作会触发表单的最重要的行为(结束表单),所以它们通常属于主要动作。

  

相反,次要动作相对用的较少,而且通常允许用户撤销已经输入的数据。比如【取消】、【重置】或【返回】,与用户完成表单的主要目标相对而言,它们处于次要地位。 

由于次要按钮有可能引发负面后果,特别是无意中被触发时,我过去经常主张把它们从表单中去掉。试想一下,你填写了一个超长的表单后,只是误点了一下【重置】按钮,所有的数据都不见了。 

有人说有时候次要动作也是合理的(【另存为】、【导出】等)。在这种情况下,我的经验是把主次要按钮从视觉上区分开,这样用户就不至于混淆主要目的:完成表单。

弱化次要动作的视觉表现,可以将潜在错误的风险降到最低,同时把用户引导向正确的结果。但是,区别主次动作的最佳方案是什么呢?主要动作与次要动作应当有多大差异?他们应该怎样放置?为了解答这些问题,我和Erte进行了一些测试。 

为了研究主次动作的最佳显示方案,我们使用6种方案测试了23名用户,使用了眼动追踪法和可用性度量法。测试用户按随机顺序查看6种设计方案(以便克服熟悉度偏误),他们都被要求"完整而正确的填完表单"

  

6个方案中,有5个方案完美的完成了任务。A/B/C/D/F方案的正确率为100%,没有引发任何一个错误。它们完成任务的时间大致相当,并且满意度评价也一样高。 

其中,B方案的效果最佳。用户注视的时间最短,而且注视量最少。与其他方案相比,用户能更快更有效的完成任务。

  

但是评论A方案的时候,一些用户认为把【取消】按钮显示成链接形式比较有效。一名用户提到,虽然这种隐性显示法会让他找不到按钮,但却有效避免了意外的(也是灾难性的)取消操作。另一名用户认为,【提交】按钮是用户界面里最重要的按钮,【取消】按钮理所当然的不配享用前者般的同等待遇。 

还有一些用户对C方案把【取消】按钮"灰掉"的做法表示反对。此外,有一人说颜色可以让人更容易找到"正确的按钮"(比如【提交】),而另一人却说不同颜色的按钮"影响速度(并且)让你回头检查你是否点击了正确的东西" 

有趣的是,处理C方案的用户和处理B方案(使用了几乎相同的绿色左对齐按钮)的相比,平均多了8个以上的注视 。这似乎说明,虽然用户的确认可C方案这种灰色【取消】按钮更容易识别,但是在处理速度方面,C方案的确效率不佳。据称,使用B方案时,一部分用户感觉到有点担心他们"也可能很容易点击了错误的按钮"

  

总的来说,似乎人们更喜欢那种【取消】按钮靠边站的设计,即便这些设计会拖一点后腿。这证明用户更加关心数据的安全,而不是更快的提交。

 布局

整个测试中,E方案表现的最差。有6名用户错误的点击了【取消】按钮,而更多的人则在按钮前徘徊,直到他们发现差点犯错为止。整体上看,使用E方案的用户比B方案的平均慢了6秒(当认为按钮的布局是两种方案唯一的不同时,这个6秒的差距还是相当大的)。完成任务需要作出的注视也大大高于平均值(高于平均注视总时长平和均注视时长)。

  

根据我们收集的数据显示,ABC方案是最有效的三个。这三个原型有着一个共同特点:【提交】【取消】按钮全部放置在页面左侧。这说明这两个操作的最佳设计选择是左对齐  特别当表单控件也同样左对齐时。把这两个按钮放在左侧也使得用户眼睛移动的距离最少。 

从眼动的情况来说,F方案效率最差。虽然所有的用户都成功的完成了任务,但我们的眼动跟踪设备数据还是证明了其他方案更加高效。使用F方案时,用户的注视时间最久,相对于其他方案来说,他们注视的也更加频繁了。我们认为这是由于用户本来以为按钮会在左侧(比如直接显示在表单最后一个控件下方),结果却发现并非如此,不仅这样,他们还得到处搜索去寻找按钮。

这一发现很好的符合了一个表单设计方面的长久以来的原则:引导用户正确完成。按一个明显的垂直方向排列输入框和动作按钮,可以清晰的告诉用户如何按顺序完成表单。这一点,可以从下面的热区图中看到:用户的注视路径形成了非常显著的垂直形状。

(注意:心理预期因素可能影响了测试结果。因为在我们测试的所有方案中,【提交】按钮都是摆在【取消】按钮左侧的。)

虽然,大部分网页表单的设计目标都是让用户能够快速准确的完成表单,但是在某种情况下的确有必要减慢用户的速度。需要帮助用户对主、次要动作进行选择的时候,视觉上的区分会是一个有效途径。 

这种区分应做到何种程度?象A方案一样做成按钮vs链接,还是象C方案一样仅改变不同的颜色?A方案在完成时间、平均注视量和平均注视总时长方面更优,这表面用户完成的更快,但并没有快很多。 

当然,如果没有次要动作的时候,这种区分显然是多余的。应当确定你是否有必要在表单中放置次要动作,并且不要乱用一气。把动作按钮与表单的输入域对齐,可以给用户照亮前进的路途,帮助他们更快的完成表单。要记住,直接把主要动作按钮与输入域对齐能够提高工作效率并且减少耗费的时间,用户也将更加开心。


clock October 26, 2008 22:42 by author ethan

【原文地址】jQuery and Microsoft
【原文发表日期】 Sunday, September 28, 2008 11:32 AM

jQuery 是个轻量级的开源JavaScript库(只有15kb大),在相当短的时间内,已经成为网上最受欢迎的JavaScript库之一。

jQuery如此受欢迎,有很大一部分是因为它允许你用最少数量的代码就能非常优雅地(且非常有效地)找出和操作HTML元素。jQuery是通过一个非常棒的“selector”API来实现这个的,该API允许开发人员查询HTML元素,然后对它们施加“命令(commands)”。jQuery命令的一个特征是,它们可以“串连(chained)”在一起,这样,一个命令的结果可以转而注入到另一个命令中去。jQuery还包含了一套内置的动画效果APIs,这些APIs可以用作命令之用。这样的组合允许你只要击键几次就可以做一些非常酷的事情。

例如,下面的JavaScript用了jQuery找出页面上所有拥有一个CSS类为 "product" 的 <div> 元素,然后使用动画效果慢慢使它们消失:

另一个例子,下面的JavaScript用了jQuery找出页面上一个特定的id为"datagrid1"的<table>,然后获取datagrid中的每隔一行的<tr>,给这些<tr>元素设置一个CSS类为"even",用来设置隔行的背景颜色:

[注意:这两个例子都改变自优秀图书《jQuery in Action》 中的代码片段]

一直以来,许许多多开发人员要求我们在ASP.NET AJAX中添加象上面这样的元素选择和动画效果操作的功能,这些支持其实早就作为提议的功能列在我们几个月前发表的《ASP.NET AJAX 路线图》中了。但当开发团队开始研究实现时,他们很快就意识到jQuery对这些场景的支持已经非常出色,而且围绕着jQuery已经建立有一个巨大的生态系统和社区。jQuery库在同一个页面上也与ASP.NET AJAX和 ASP.NET AJAX Control Toolkit协作良好。

我们想,与其复制这些功能,原封不动(as-is)地使用jQuery,将其作为VS/ASP.NET中的一个标准的,受支持的库不更好吗?然后我们可以将精力集中在建造充分利用jQuery的新功能上。我们给jQuery开发团队发了信,看他们对此是否有兴趣,我们很快收到回复,他们也觉得这是个非常有趣的主意。

对jQuery的支持

今天,我非常兴奋地宣布,从此以后,微软将把jQuery和Visual Studio一起发行。我们将把jQuery JavaScript库原封不动地发行,不会生成分叉或改变jQuery主干的源代码。相关文件会继续在现有的jQuery MIT许可下使用和发布。

我们还将发布intellisense注释版本,在设计时提供很好的Visual Studio intellisense和帮助集成。例如:

在有串连的命令时:

jQuery intellisense注释支持将能在几个星期后免费下载(该支持可以在VS 2008 SP1和免费的Visual WebDeveloper 2008 Express SP1下工作)。新的ASP.NETMVC也将发行jQuery,会将jQuery库默认加到所有新的项目中。

从今年稍后开始,我们还将把微软的产品支持扩展到jQuery,这将允许开发人员和企业每周7天/每天24小时都可以向Microsoft PSS(产品支持服务)电话求助和开设jQuery支持案子。

以后,我们将把jQuery作为类库之一,用来在ASP.NET AJAX控件工具包中实现高层次的控件,以及在ASP.NET MVC中实现新的Ajax服务器端辅助方法。加入ASP.NET AJAX的新功能(象客户端 模板 支持)也将设计来与jQuery完美集成。

我们还计划向jQuery开源项目贡献测试,缺陷修补和补丁。所有这些都将经过标准的jQuery补丁评估(patch review)过程。

结语

能与jQuery开发团队合作,我们非常高兴。jQuery是个极棒的类库,是我们认为能让ASP.NET和ASP.NET AJAX开发人员受益匪浅的东西。我们期待它将与Visual Studio和ASP.NET完美结合,能给更多的开发人员带来好处。

想了解关于今天这个宣布的细节,请参阅jQuery开发团队博客John Resig的贴子。Scott Hanselman也即将发表一个很好的教程,展示jQuery与ASP.NET AJAX(包括新的客户端模板引擎),以及ADO.NET数据服务(是在.NET 3.5 SP1中发布的,以前的代号名为“Astoria”)的集成。

希望本文对你有所帮助,

Scott

 

 

【译注】这应该是个非常重大的事件,好像这是微软第一次公开支持一个开源产品。从原贴子的跟贴来看,众多开发人员都是喜出望外。

clock October 16, 2008 10:28 by author Sky Jia (贾超)

画流程图是程序设计的基本功,但又似乎属于各有各的高招的一个领域。那么到底用什么标准评价流程图的好坏呢?从事用户体验设计咨询的丁宇在博客上分享了他“画Web流程图的一点心得” 。除了给出他自己的一套形状,还逐一说明注意事项,很有爱心:

作为整张流程图的头和尾,必须标清楚到底具体指哪个页面,以免日后出现歧义。
[……]
所有从形状出来的线条,都具有和此形状边框一样的颜色。这样的做法不仅看起来漂亮,在复杂的流程图中还能轻易地标明各形状的关系。
[……]
几乎总是让‘是’的分支往下流动,让‘否’的分支向右流动。因为流程图一般都是从上向下、从左到右绘制的,遵循上述规则一方面可以让绘制者不用为选择方向操心,另一方面也方便了读者阅读。
[……]
并非所有后台动作都绘入流程图中(否则流程图就会变成庞然大物了),只有需要特别强调的后台动作(和用户体验直接相关的)才使用此形状。
[……]
可以利用跳转点来分割篇幅巨大的流程图
[……]
分割篇幅巨大的流程图,更好的办法是用子流程。
[……]
他还特别强调:
在团队合作中,图例是必须的,否则没人知道你画出来的东西到底是什么。

除了确保别人能看懂你的流程图,评价流程图的好坏,还要谨记“流程图是要指导UI设计的,是UI设计的参照物”,必须“覆盖了各种可能的情况和细节”,“考虑到系统的设计和承受能力”。

支付宝交互设计师Joycce总结得更加扼要:

  1. 简单易懂
  2. 表达正确全面,有重点、有细节
  3. 形像生动

丁宇也发起了一个征集活动,邀请大家一起分享自己的心得,各位达人请不吝赐教,InfoQ中文站将继续跟踪报道。

如果想了解流程图的一般用法,Arky Tan翻译了Jesse James Garrett撰写的“描述信息结构和交互设计的图示词汇表 ”。顺便一提,流程图这东西是有标准的,在发明自己的一套图形之前,不妨先翻一下ISO 5807:1985 。


Search

Calendar

<<  September 2010  >>
SuMoTuWeThFrSa
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

Categories

Tags