<?xml version="1.0" encoding="utf-8"?>
<chapter id="principles" lang="zh-CN">
    
    <title>可用性原则</title>

    <para>这一节阐述了一些具体的文档中的技术指导建议后的基本原则。我们相信这些原则在做应用程序开发的时候是非常重要的。</para>

    <sect1 id="principles-people">
      <title>人性化设计</title>

      <para>记住这一点任何一款软件的目的是能让某些特定群体中的人完成一个特定的设置任务。所以当您设计您的应用程序的时候首先建立的事情是：</para>

	<orderedlist>
		<listitem><para>您的用户是什么人</para></listitem>
		<listitem><para>您希望他们能够做什么</para></listitem>
	</orderedlist>

      <para>例如，您可能会设计一个能让工程师（软件、电气、或者机械）创建一些图表的应用程序。您可能会设计一个能让系统管理员配置并且监听一个网页服务的程序。您可能设计一个能让初中生学习数学的应用程序。</para>

      <para>The important thing is that you know your audience, and you understand both their goals and the tasks necessary to achieve those goals.  There are a large number of professional interaction designers who write books and teach courses on design methods that can help with this process, many of which are extremely useful— see the <xref linkend="bibliography"/> for a selection.  Most of these methods, however, boil down to specific ways of understanding your users, understanding the tasks you want to help them accomplish, and finding ways to support those tasks in your application.</para>

    </sect1>
    <sect1 id="principles-broad-userbase">
      <title>不要限制您的用户群</title>

      <para>如果您设计了一个应用程序为工程师、或者为了孩子、或者为了系统管理员，那么就要确定创建的应用程序能被<emphasis>所有</emphasis>工程师、孩子、或者系统管理员使用，包括那些残障人士或者那些母语和你不一样的人。要知道无障碍问题和国际化和本土化问题，在文档中很多都会被指导解决。</para>

      <sect2 id="accessibility">
	<title>无障碍</title>

	<para>Accessibility (sometimes called <emphasis>a11y</emphasis>) means enabling people with disabilities of some kind to participate in life's activities: in this case, specifically to use your software.  For example:</para>

	<itemizedlist>
		<listitem><para>如果您只是用颜色去标记一些不同类型的信息，那么色盲用户可能就无法使用。</para></listitem>
		<listitem><para>如果您只依靠声音表示重要信息那么听力障碍的用户将无法使用您的应用程序。</para></listitem>
		<listitem><para>如果您不提供键盘录入等价的命令那么那些行动受限的用户将无法使用您的程序。</para></listitem>
	</itemizedlist>

	<para>Your software should also be usable with voice interfaces, screen readers such as <ulink url="http://projects.gnome.org/orca/">Orca</ulink>, alternate input devices, and other assistive technologies.  The standard GNOME libraries do most of this work for you, but with a little extra effort you can make your application every bit as useful to users who rely on those technologies as to those who don't.</para>

	<para>GNOME has excellent inbuilt support for accessibility by means of the ATK and GAIL libraries, which in many cases can do most of the work for you. More information on accessibility in GNOME can be found at the <ulink url="http://projects.gnome.org/accessibility">GNOME Accessibility Project</ulink>.</para>

      </sect2>
      <sect2 id="internationalization">
	<title>国际化与本土化</title>

	<para>国际化意味着在设计软件时要实现不同语言环境的功能。本土化是将一个应用程序中的信息、标签、和其他界面元素翻译成另一种语言的过程。</para>

	<para>GNOME has excellent support for both internationalization (also referred to as i18n) and localization (also referred to as l10n).  In most cases, simply using standard GNOME APIs for displaying text and messages will allow you or others to localize your application for other locales.  For more information on how to make your application localizable, see the <ulink url="http://www.pango.org">Pango project home page</ulink> (Pango is the GNOME library for rendering internationalized text), the <ulink url="http://www.gnome.org/i18n/">GNOME Translations page</ulink>, and the <ulink url="http://developer.gnome.org/projects/gtp/">GNOME Translation Project page</ulink>.</para>
	
	<para>敏感的文化和政治因素是一个非常重要的考虑因素。在设计按钮和声音、甚至选择颜色时要求明白对于世界上其他地方的用户会不会有暗示含义。</para>
	<para>例如这些元素最好避开的原因包括：</para>
	<itemizedlist>
		<listitem><para>标志或者钱的图片</para></listitem>
		<listitem><para>在地图上显示争议的边界或存在争议地区的名称</para></listitem>
		<listitem><para>没有按照字母表的顺序列出国家或者城市（除非在上下文中有特殊的要求或者需要）</para></listitem> 
		<listitem><para>用动物作为图标</para></listitem>
		<listitem><para>之用手或脚作为图标</para></listitem>
	</itemizedlist>

      </sect2>
    
    </sect1>

    <sect1 id="principles-match">
      <title>在您的应用程序和真实世界中间创建一场比赛</title>

      <para id="use-users-language">应当用贴近用户的字眼、词组、和概念而不是系统中那些难懂的术语。用术语解释应用软件支持的任务时要用用户已知的和任务相关的知识。例如，在医学中，包含一个特定病人全部信息的文件夹叫做“图表”。从现在起，一个医学应用程序会一份记录了同样信息内容的一纸图表的记录叫做“病人图表”而不是叫做“病人数据记录”。</para>

      <para>您可以充分利用您的用户所知道的现实生活中使用到的暗喻－就是，一个从外界获得的相似的概念—来表现您的应用程序中的元素。例如：</para>

	<itemizedlist>
		<listitem><para>一个图片文件夹建议设计成一个可以放文件的容器</para></listitem>
		<listitem><para>回收站建议设计成一个可以放一些不再需要的项目的容器</para></listitem>
	</itemizedlist>

      <para>When using metaphors, however, it is important to neither take the metaphor too literally, nor to extend the metaphor beyond its reasonable use.  For example, the capacity of a file folder should not be limited to the capacity of a physical file folder, which presumably could contain only a few documents before becoming unwieldy.  On the other hand, a waste basket should not be used for anything other than holding discarded files.  It should not be used, for example, to eject a removable disk such as a floppy or CD.</para>
    </sect1>

    <sect1 id="principles-consistency">
      <title>保持您的应用程序的一致性</title>

      <para>让你的程序与他自己和其他程序保持外观和行为上的一致。这是最重要的一条这几原则，同时也可能是最著名的，但是经常被遗忘。在GNOME应用程序当中文件服务被当作最基本的一致性，我们鼓励您阅读和模仿其他应用程序的风格，去编写那些没有指南文档的程序。</para>

      <para>一致性使得用户可以使用他们自己已知的计算机环境知识和其他应用程序去理解一个新的应用程序。这不仅让用户更快地熟悉一个新的应用程序，而且营建了一个很舒服的氛围和对整个环境的信赖。绝大多数GNOME人机界面指南建议都会告诉您如何让您创建的应用程序与整个GNOME环境和其他GNOME应用程序保持一致性。</para>

      <para>一个忠告：一个不起作用的或者不完全的一致性比不一致还要差。如果您的程序包含的一个一致性<guimenuitem>撤销</guimenuitem>菜单按钮，但是因为您的应用程序没有完全支持撤销操作导致这个按钮总是失效，这将使得用户对他桌面上其他应用程序的撤销降低信任度。要么让那您的程序支持撤销，要么就移除<guimenuitem>撤销</guimenuitem>按钮。</para>

    </sect1>

    <sect1 id="principles-feedback">
      <title>保持用户的选择权</title>

      <para>经常然用户通过合适跟踪反馈在一个合适的时间让用户知道在您的程序中发生了什么事。用户应该永远不去猜测您的应用程序在系统中或者在程序中的地位。当用户执行一个动作、填写反馈调查去确定系统接受到了输入同时在上面操作。反馈信息可以使可视的、可听的、或者两者结合。如果系统将要用很长时间去处理请求，那么就要提供尽可能多的调查信息来反映这个操作到底要持续多长时间。有用的反馈信息包括但不仅限于：光标变化、动画的“颤动”、过程指示器，音频反馈信息例如蜂鸣、和其他错误信息。错误信息因该用简单的语言，清楚的展现问题的地方，并且提供解决方法或者如果可以告诉用户如何离开这个错误子状态。</para>

      <para>反馈信息关键要<emphasis>准确</emphasis>和<emphasis>精确</emphasis>。如果您希望有一个确定的过程指示器来显示一个任务完成的状态和出错的状态，用户就会对指示器失去信心，同时他们会发现这个环境没什么用。如果您显示一个只说明有一般性错误而没有提供足够的信息来诊断或解决这个问题，您的用户将不会继续他的任务。</para>
      <para>查看 <xref linkend="feedback"/> 和<xref linkend="windows-alert"/>获取更多有关于反馈信息的信息。</para>
    </sect1>

    <sect1 id="principles-simplicity">
      <title>保持简单和精致</title>

      <para>您的应用程序因该能让用户对于手头的任务保持专注。这样，在设计应用程序的时候只显示有用和相关的信息和界面元素。每一个拓展信息或者界面每一位和相关信息竞争的元素和误导您的用户离一些重要信息越来越远。从现在开始，不要让凌乱的东西填充您的界面，也不要让按钮、菜单选项、图标、或者无关信息填满用户的界面。而因该用这样的，用逐步增加的方式和其他限制用户界面上同时显示信息的技术。</para>

      <para>Finally, present your information and interface elements in an aesthetically pleasing manner.  A disorganized, cluttered-looking interface with a few elements can be just as distracting as an organized interface with too much information.  Make sure that dialog elements are cleanly-aligned, and do not overuse or misuse color or graphics.  If you know a graphic designer, seek their advice if possible— the guidelines in this document will help you with the basics, but there is no substitute for a trained eye.</para>

	<para>查看<xref linkend="design"/>和<xref linkend="icons"/>获得有关于您的应用程序的外观视觉设计的更多信息。</para>

    </sect1>

    <sect1 id="principles-user-control">
      <title>让用户有控制权</title>

      <para>记住这一点计算机的存在是为了为人类服务的。用户因该有控制的感觉，有能力在当他想做一些事情时去做他们想做的。这意味着您因该尽可能避开模式；用户应该可以在任何时间转换他们的任务（和具体的、不同的窗口）。查看<xref linkend="window-props-modality"/>获得更多模型信息。</para>

      <para>用户应该有能力去改变环境去适应自己的个人需求。这是非常重要的，经管，要避免允许太多的配置，或配置那些用户不明白的参数或发现有用的地方被修改等这样的陷阱的出现。只要可能，从全局变量和设置中继承视觉和行为参数就好像从GTK＋主题。</para>
    </sect1>

    <sect1 id="principles-forgiveness">
      <title>原谅用户</title>

      <para>我们都会犯错。就好像我们探索和学习如何使用系统，或者我们是刚刚打错字的专家，我们只是普通人。您的应用程序因该允许用户快速撤销他们行为所造成的结果。</para>

      <para>如果动作很危险，同时没有办法撤销结果，警告用户同时获取他们的确认。只在万不得已的情况下这么做；如果经常面对确认信息，用户开始忽略它们，让他们变得更糟也好过什么都不做。</para>

      <para>在所有的情况下，用户的工作都是不可侵犯的。您的应用程序不该在没有用户明确而清晰的动作前丢失或销毁用户的工作。在其他技术中间，这种行为可以被文件的后台自动保存实现，并且提供多级的撤销。</para>

    </sect1>

    <sect1 id="principles-direct-manipulation">
      <title>Provide Direct Manipulation</title>

      <para>Wherever possible, allow users to act on objects and data directly, rather than through dialogs or explicit commands.  For example, it is more intuitive to drag a circle object around in a diagram rather than selecting a "Move" command from a menu while the circle is selected.  Simlarly, in an email application, allow the user to attach files by dragging them from the file manager and dropping them onto the message composition window if they wish.</para>

	<para>See <xref linkend="input"/> for more information on direct manipulation.</para>

    </sect1>

  </chapter>
