IT瘾翻译推荐

【译】Java8 之后对新开发者非常友好的特性

Sun, 06 Feb 2022 20:47:57 CST

在这篇文章中，我将描述自 Java8 依赖对开发者来说最重要也最友好的特性，之所以选择 Java8 ，那是因为它依然是目前使用最多的版本。

具体可见这个调查报告：

Switch 表达式 (JDK 12)

使用 switch 表达式，你可以定义多个 case 条件，并使用箭头 -> 符号返回值，这个特性在 JDK12 之后启用，它使得 switch 表达式更容易理解了。

     public String newMultiSwitch(int day) {
        return switch (day) {
           case 1, 2, 3, 4, 5 -> "workday";
           case 6, 7 -> "weekend";
           default -> "invalid";
        };
     }

在 JDK12 之前，同样的例子要复杂的多：

     public String oldMultiSwitch(int day) {
        switch (day) {
           case 1:
           case 2:
           case 3:
           case 4:
           case 5:
              return "workday";
           case 6:
           case 7:
              return "weekend";
           default:
              return "invalid";
        }
     }

文本块 (JDK 13)

文本块是一个多行字符串，可以避免使用转移字符；从 Java13 之后它成为了预览特性，使用 """ 符号定义。接下来看看使用它声明一个 JSON 字符串有多简单。

     public String getNewPrettyPrintJson() {
        return """
               {
                  "firstName": "Piotr",
                  "lastName": "Mińkowski"
               }
               """;
     }

Java13 之前的版本：

     public String getOldPrettyPrintJson() {
        return "{\n" +
               "     \"firstName\": \"Piotr\",\n" +
               "     \"lastName\": \"Mińkowski\"\n" +
               "}";
     }

新的 Optional Methods (JDK 9/ JDK 10)

Java 9/10 版本之后新增了几种可选方法，有意思的是这两个：

orElseThrow
ifPresentOrElse

使用 orElseThrow 当数据不存在时你能抛出 NoSuchElementException 异常，相反会返回数据。

     public Person getPersonById(Long id) {
        Optional<Person> personOpt = repository.findById(id);
        return personOpt.orElseThrow();
     }

正因为如此，可以避免在 isPresent 中使用 if 条件。

     public Person getPersonByIdOldWay(Long id) {
        Optional<Person> personOpt = repository.findById(id);
        if (personOpt.isPresent())
           return personOpt.get();
        else
           throw new NoSuchElementException();
     }

第二个有趣的方法是 ifPresentOrElse ,当数据存在时，会执行带数据参数的函数，相反会执行参数为空的函数。

     public void printPersonById(Long id) {
        Optional<Person> personOpt = repository.findById(id);
        personOpt.ifPresentOrElse(
           System.out::println,
           () -> System.out.println("Person not found")
        );
     }

在 Java8 中，你需要在 isPresent 方法中使用 if else 语句。

集合工厂方法(JDK 9)

使用 Java9 中的集合工厂方法可以简单的使用预定义数据创建不可变集合。

1 2	List<String> fruits = List.of("apple", "banana", "orange"); Map<Integer, String> numbers = Map.of(1, "one", 2,"two", 3, "three");

在 Java9 之前，你可以使用 Collections ，但肯定是更复杂：

     public List<String> fruits() {
        List<String> fruitsTmp = new ArrayList<>();
        fruitsTmp.add("apple");
        fruitsTmp.add("banana");
        fruitsTmp.add("orange");
        return Collections.unmodifiableList(fruitsTmp);
     }
     
     public Map<Integer, String> numbers() {
        Map<Integer, String> numbersTmp = new HashMap<>();
        numbersTmp.put(1, "one");
        numbersTmp.put(2, "two");
        numbersTmp.put(3, "three");
        return Collections.unmodifiableMap(numbersTmp);
     }

Records (JDK 14)

使用 Records 你可以定义一个不可变、只能访问数据（只有 getter 方法) 的类，它可以自动创建 toString，equals，hashcode 方法。

1	public record Person(String name, int age) {}

以下效果与 Records 类似：

      public class PersonOld {
      
          private final String name;
          private final int age;
      
          public PersonOld(String name, int age) {
              this.name = name;
              this.age = age;
          }
      
          public String getName() {
              return name;
          }
      
          public int getAge() {
              return age;
          }
      
          @Override
          public boolean equals(Object o) {
              if (this == o) return true;
              if (o == null || getClass() != o.getClass()) return false;
              PersonOld personOld = (PersonOld) o;
              return age == personOld.age && name.equals(personOld.name);
          }
      
          @Override
          public int hashCode() {
              return Objects.hash(name, age);
          }
      
          @Override
          public String toString() {
              return "PersonOld{" +
                      "name='" + name + '\'' +
                      ", age=" + age +
                      '}';
          }
      }

接口中的私有方法 (JDK 9)

从 Java8 之后你就可以为接口创建默认方法，但从 Java9 的私有方法你就能充分使用该特性：

     public interface ExampleInterface {
        private void printMsg(String methodName) {
           System.out.println("Calling interface");
           System.out.println("Interface method: " + methodName);
        }
     
        default void method1() {
           printMsg("method1");
        }
     
        default void method2() {
           printMsg("method2");
        }
     }

局部变量类型推导 (JDK 10 / JDK 11)

从 Java10 之后你就能使用局部变量类型推导了，只需要使用 var 关键字来代替具体类型；在 Java11 之后你就能在 lambda 表达式中使用类型推导了。

     public String sumOfString() {
        BiFunction<String, String, String> func = (var x, var y) -> x + y;
        return func.apply("abc", "efg");
     }

【译】你可能不知道但却很有用的 Java 特性

Mon, 17 Jan 2022 02:28:46 CST

原文链接

在这篇文章中你将会学习到一些你可能没听过但有用的 Java 特性，这些是我个人常用的一些特性或者是从其他文章中学习到的，重点是关注 API 而不是语言本身。

延迟队列

众所周知，在 Java 中有许多类型的集合可以使用，但你听说过 DelayQueue 吗？它是一个特定类型的集合，允许我们基于延时时间对数据排序，这是一个非常有意思的类，它实现了 BlockingQueue 接口，只有当数据过期后才能从队列里取出。

使用它的第一步，你的 class 需要实现 Delayed 接口中的 getDelay 方法，当然也可以不用声明一个 class，使用 Record 也是可以的。

这是 Java14 的新特性

     public record DelayedEvent(long startTime, String msg) implements Delayed {
     
         public long getDelay(TimeUnit unit) {
             long diff = startTime - System.currentTimeMillis();
             return unit.convert(diff, TimeUnit.MILLISECONDS);
         }
     
         public int compareTo(Delayed o) {
             return (int) (this.startTime - ((DelayedEvent) o).startTime);
         }
     
     }

假设我们需要一个延时 10s 取出的数据，我们只需要放入一个比当前时间多 10s 的任务即可。

     final DelayQueue<DelayedEvent> delayQueue = new DelayQueue<>();
     final long timeFirst = System.currentTimeMillis() + 10000;
     delayQueue.offer(new DelayedEvent(timeFirst, "1"));
     log.info("Done");
     log.info(delayQueue.take().msg());

最终输出如下：

时间格式的日期

这个特性可能对大部分人来说没什么用，但老实说我个人非常喜欢；不管怎么说 Java 8 在时间 API 上改进了许多。从这个版本开始或许你不再需要其他任何扩展库了。

你能想到嘛，从 Java 16 中你甚至可以用标准库表示一天内的日期了，比如 “in the morning” “in the afternoon” ，这是一个新的格式语句 B。

     String s = DateTimeFormatter
       .ofPattern("B")
       .format(LocalDateTime.now());
     System.out.println(s);

以下是我的输出，具体和你当前时间有关。

你可能会想为什么会是调用 “B” 呢，这确实看起来不太直观，通过下表也许能解答疑惑：

Stamped Lock

在我看来，并发包是 Java 中最有意思的包之一，同时又很少被开发者熟练掌握，特别是长期使用 web 开发框架的开发者。

有多少人曾经使用过 Lock 呢？相对于 synchronized 来说这是一种更灵活的线程同步机制。

从 Java8 开始你可以使用一种新的锁： StampedLock.StampedLock，能够替代 ReadWriteLock。

假设现在有两个线程，一个线程更新金额、一个线程读取余额；更新余额的线程首先需要读取金额，再多线程的情况下需要某种同步机制（不然更新数据会发生错误），第二个线程用乐观锁的方式读取余额。

     StampedLock lock = new StampedLock();
     Balance b = new Balance(10000);
     Runnable w = () -> {
        long stamp = lock.writeLock();
        b.setAmount(b.getAmount() + 1000);
        System.out.println("Write: " + b.getAmount());
        lock.unlockWrite(stamp);
     };
     Runnable r = () -> {
        long stamp = lock.tryOptimisticRead();
        if (!lock.validate(stamp)) {
           stamp = lock.readLock();
           try {
              System.out.println("Read: " + b.getAmount());
           } finally {
              lock.unlockRead(stamp);
           }
        } else {
           System.out.println("Optimistic read fails");
        }
     };

现在更新和读取的都用 50 个线程来进行测试，最终的余额将会等于 60000.

     ExecutorService executor = Executors.newFixedThreadPool(10);
     for (int i = 0; i < 50; i++) {
        executor.submit(w);
        executor.submit(r);
     }

并发累加器

锁并并不是并发包中唯一有意思的特性，并发累加器也同样有趣；它可以根据我们提供的函数更新数据；再多线程更新数据的场景下， LongAccumulator 是比 AtomicLong 更优的选择。

现在让我们来看看具体如何使用，我们需要两个参数进行初始化；第一个是用于累加计算的函数，通常是一个 sum 函数，第二个参数则是累加计算的初始化值。

接下来我们用 10000 作为初始值来创建一个 LongAccumulator，最终结果是多少？其实结果与上文相同，都是 60000，但这次我们并没有使用锁。

     LongAccumulator balance = new LongAccumulator(Long::sum, 10000L);
     Runnable w = () -> balance.accumulate(1000L);
     
     ExecutorService executor = Executors.newFixedThreadPool(50);
     for (int i = 0; i < 50; i++) {
        executor.submit(w);
     }
     
     executor.shutdown();
     if (executor.awaitTermination(1000L, TimeUnit.MILLISECONDS))
        System.out.println("Balance: " + balance.get());
     assert balance.get() == 60000L;

数组的二分查找

假设我们想在一个排序列表中插入一个新元素，可以使用 Arrays.binarySearch() 函数，当这个 key 存在时将会返回 key 所在的索引，如果不存在时将会返回插入的位置 -(insertion point)-1。

binarySearch 是 Java 中非常简单且有效的查询方法。

下面的这个例子中，对返回结果取反便能的到索引位置。

     int[] t = new int[] {1, 2, 4, 5};
     int x = Arrays.binarySearch(t, 3);
     
     assert ~x == 2;

负数的二进制是以正数的补码表示，对一个数取反+1 就等于补码，所以这里直接取反就等于 Arrays.binarySearch() 不存在时的返回值了。

Bit Set

如果你需要对二进制数组进行操作你会怎么做？用 boolean[] 布尔数组?

有一种更高效又更省内存的方式，那就是 BitSet。它允许我们存储和操作 bit 数组，与 boolean[] 相比可省 8 倍的内存；也可以使用 and/or/xor 等逻辑操作。

假设我们现在有两个 bit 数组，我们需要对他们进行 xor 运算；我们需要创建两个 BitSet 实例，然后调用 xor 函数。

     BitSet bs1 = new BitSet();
     bs1.set(0);
     bs1.set(2);
     bs1.set(4);
     System.out.println("bs1 : " + bs1);
     
     BitSet bs2 = new BitSet();
     bs2.set(1);
     bs2.set(2);
     bs2.set(3);
     System.out.println("bs2 : " + bs2);
     
     bs2.xor(bs1);
     System.out.println("xor: " + bs2);

最终的输出结果如下：

【译】Hybrid移动应用：用网页技术提供Native体验

Wed, 04 Mar 2015 10:21:47 CST

原文： http://www.smashingmagazine.com/2014/10/21/providing-a-native-experience-with-web-technologies/
翻译：叮当当咚当当小胖妞呀杀手爱elva Ivan_z3 肖弦

根据最近的一篇报告显示，HTML是移动应用开发人员使用最多的语言，开发人员对于选择哪种网页技术考虑的最主要因素，是代码的跨平台便携性和开发的低成本性。我们常常听说，hybrid app使用起来非常慢，而且设计也很糟糕，让我们看看是否有可能又有原生应用的形，又有我们习惯使用的感。

这篇文章会提供很多关于如何构建良好的hybrid移动应用的线索、代码片段和经验。我将会大致介绍一下hybrid移动应用的开发，包括它的优点和缺点。然后，我会分享一下过去两年我在开发Hojoki和CatchApp时积累的经验，这两个项目都运行在主流的移动平台，并且是由HTML、CSS和Javascript建成的。最后，我们会介绍一下打包代码到原生app的一些比较好的工具。

什么是混合模式移动应用

移动app可以大致被分为三种，native、hybrid和web app。如果使用native app，你可以使用设备和操作系统的所有能力，同时，平台的性能负荷最小。然而，构建web app可以让你的代码跨平台，使得开发时间和成本大大减少。而hybrid app把这两者的优点都结合起来，使用一套共同代码，在许多不同的平台上部署类似原生的app。

有两种构建hybrid app的方法：

Webview app：HTML,CSS和Javascript基础代码在一个内部的浏览器（叫做WebView）中运行，这个浏览器打包在一个原生的app中，一些原生的API可以通过这个包被Javascript获得，比如 Adobe PhoneGap和 Trigger.io。
被编译的hybrid app：用一种语言编写代码（如C#或者Javascript），对于每一种支持的平台都把代码编译进原生代码中，这样做的结果是，每一个平台都有一个原生的app，但是在开发过程中少了一些自由空间。可以看一下这些例子， Xamarin， Appcelerator Titanium， Embarcadero FireMonkey。

这两种方法都被广泛使用，存在即合理， 不过今天我们只关注WebView app，因为WebView app可以让开发人员平衡他们现有的网页技术。我们来看一下hybrid app相对于native app和web app的各种优点和缺点。

优点

开发人员可以使用现有的网页技术
对于多种平台使用一套基础代码
减少开发时间和成本
使用响应式网页设计可以非常简便的设计出多样的元素（包括平板）
一些设备和操作系统特征的访问
高级的离线特性
可见度上升，因为app可以原生发布（通过app store），也可以发布给移动端浏览器（通过搜索引擎）

缺点

某些特定app的性能问题（那些依赖于复杂的原生功能或者繁重的过渡动画的app，如3D游戏）
为了模拟native app的UI和感官所增加的时间和精力
并不完全支持所有的设备和操作系统
如果app的体验并不够原生化，有被Apple拒绝的风险（比如说一个简单的网站）

这些缺点比较显著，不能忽略，它们告诉我们，并不是所有的app都适合混合模式，你需要小心的预计你的目标用户、他们对平台的选择和对app的需求。对于许多app来说，好处都是大于坏处的，比如内容驱动的app。

Hojoki和CatchApp都是内容驱动的app，所以我们一开始觉得它们非常适合混合模式的开发方式。我们之前提到的好处中的前三点对于我们构建Hojoki的移动app帮助很大，不过也仅仅是4周的时间而已。显而易见，Hojoki的第一个版本缺失了很多重要的东西，接下来的时间里，我们都把精力扑在提升性能、对每一个平台制作自定义的UI和利用不同设备的高级特性上。那个时候积累的那些经验对于让app形似并神似native app很重要，下面我会尽可能多的分享一下我的经验。

那么， 怎么能让你的app形似并神似一个原生的app呢？对于一个移动网页开发人员来说，能够使用设备和操作系统的能力，能够打包他们的app，这些都听上去很棒。然后，如果要用户相信这是一个native app，那么它就必须长得像并且表现的像。如何完成这一点对于混合模式移动开发人员来说仍然是最大的挑战之一。

让你的用户宾至如归

虽然我们只写一套基础代码，但这并不意味着多种不同平台上的感官都要完全一样，你们用户根本不在乎什么潜在的跨平台技术，他们只想要app根据他们的期望来展现，他们想要“宾至如归”。你的第一步应该是为每一个平台做设计概览：

“ IOS设计资源”, IOS开发人员库
“ Android设计”, Android开发人员
“ 设计”, Windows开发中心

虽然这些概览并不能完美适应全部的app，但是它们仍然提供了一套非常全面和标准的界面和体验，每一种平台的用户都会希望得到这样的体验。

DIY VS. UI框架

如果你一个人实施这些组件、样式和动画，这是个很大的挑战，现在有各种各样的UI框架来帮助你，从商业（ Kendo UI）的到开放（ lonic）的，从共同UI（ JQuery Mobile和 Onsen UI）到许多有平台针对性的UI（ Sencha Touch和 ChocolateChip-UI）。有些能够很好的提供精确到像素的布局，有些则相对粗糙，这些各式各样的框架能够很方便的让使用者定义一个web app。然而，就我的观念而言，框架最主要的缺点关乎性能，因为大多数UI框架都尽量“海纳百川”，要根据自己的情况在设备上试试demo后再决定是否要使用。

在制作Hojoki的时候，我们尝试自己用CSS3和极少的Javascript来创建所有的组件，这样做的好处是能够帮助我们控制性能，减少负荷。当然，我们也会使用一些别人使用过的较小的库来解决一下复杂的任务。

自定义UI组件

自定义UI组件也有很多很好的使用例子，你需要根据你的目标用户来决定使用平台的UI还是自定义UI，如果你想要单干，你需要对UX设计有很深的理解，因为之前的那些概览都是专家们为了迎合他们平台用户的需求而制作的。

不管你是决定坚持使用平台的UI概览还是自己做自定义的组件，你都必须知道，有一些特定的设计样式是用户每天使用并热爱的。通常我们如何把一个app介绍给用户呢？通过幻灯片讲演或者教学覆盖。用户如何导航？如果标签栏或者侧边栏。用户如何快速加载或者刷新数据？下拉刷新。（在接下来的文章中会讲到类似原生的滚动）

移动端UI设计的资源

“ 移动端UI设计样式：10几个灵感迸发的网站”，Jacob Gube，Six Revisions
“ 用HTML、CSS和Javascript克隆IOS 7的UI“，Côme Courteault
“ 用HTML5点进移动端UI”（幻灯片），Luke Melia and Yael Sahar, Slideshare

设计一个看起来原生的标题栏

在UI中，标题栏是一个很重要的部分，包括它的标题、导航元素、尤其是前进和后退按钮。对于我来说，许多流行框架在提供HTML和CSS解决方案方面，相比一些原生的app是失败的，而为每个平台用最小的DOM和最少行的css代码来仿照这个UI部分其实相当的简单.

html <header> <button class="back">Feed</button> <h1>Details</h1>  </header>

在JSFiddle中查看“ IOS、Android和Windows Phone中看起来原生的标题栏”的完整代码，下面是我的成果：

用html5和css做成的看起来原生的标题栏

在不同的平台上使用相同的DOM更为便利，因为代码整洁而且易于维护，我发现这样做对于许多IOS和Android上的UI组件都适用(包括标题栏、标签栏、定制的导航菜单、设置页面、浮层，还有很多其他的东西)。然而，想要更多的支持Windows Phone变得更加困难，因为它带来了许多非常不一样的设计模块。

支持高分辨率屏幕

现如今，高分辨率的智能手机和平板构成了巨大的移动设备市场，在 ios设备中占有率超过80%，在 android设备中占有率超过70%。为了让你设备上的图片展现得更清晰，你通常不得不将其尺寸放大到超过它原本大小的两倍，因此现在响应式网站设计中，如何针对所有不同的分辨率提供适合尺寸的图片，成为了现在热议的话题之一。现在有非常多的途径解决，每一种的优点和缺点都与带宽、代码易维护性和浏览器的兼容性有关，现在让我们来快速的回顾一下当下最流行的方法，顺序不分先后：

服务端的调整和传输
客户端通过javascript的检测和替换
html5的picture元素
html5 的srcset属性
css image-set属性
css media queries
可伸缩矢量图形(SVG)

一直以来，针对响应式图片都没有一个完美的方法，这主要还是取决于图片的类型和它们在app上的展现使用方式。如果是静态图片(比如logo和教程图片)，我尽量使用SVG，它们能不费吹灰之力的完美缩放，并且只要你是Android 3+就能获得很好的浏览器支持。

当你不能选择SVG的时候， html5的picture元素和srcset属性一定会成为日后前端开发人员的首选。当下，它们最大的不足就是在浏览器上的支持太局限，因此他们需要一些插件.

同时， css背景图片和media queries是比较可靠的解决方案:

css /* Normal-resolution CSS */ .logo { width: 120px; background: url(logo.png) no-repeat 0 0; } /* HD and Retina CSS */ @media only screen and (-webkit-min-device-pixel-ratio: 1.25), only screen and ( min--moz-device-pixel-ratio: 1.25), only screen and ( -o-min-device-pixel-ratio: 1.25/1), only screen and ( min-device-pixel-ratio: 1.25), only screen and ( min-resolution: 200dpi), only screen and ( min-resolution: 1.25dppx) { .logo { background: url(logo@2x.png) no-repeat 0 0; background-size: 120px; /* Equal to normal logo width */ } }

但是，你的app也许已经包含了许多内容(比如新闻文章)，要调整所有的图片标签或者用css替代会让我们筋疲力竭，在这种情况下，服务端解决方案就会是最好的选择。

从去年开始，越来越多的android系统已经离XXHDPI(超高分辨率)屏幕又进了一步。不论上面提到的哪种方案更适合你的需要，你要记住的是你需要用到三倍于原图大小的图片来支持android的最新的设备。

使用系统字体

使用系统字体是一种让用户体感到宾至如归的一种简单但是重要的方法。

ios、 android和 windows的原生字体

主流平台上，我比较推荐这些字体样式：

/* iOS */ font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif;

/* Android */ font-family: 'RobotoRegular', 'Droid Sans', sans-serif;
/* Windows Phone */ font-family: 'Segoe UI', Segoe, Tahoma, Geneva, sans-serif;
此外，ios7提供了一些有趣的预处理，这些预处理可以自动的设置正确的字体、文字大小和行高，在普通文本中应用 font:-apple-system-body,在标题中使用 font:-apple-system-headline，这样不仅简化了文字的声明，而且还提升了动态类型（这是Apple系统范围的字号设置）的可访问性，你可以在 Thomas Fuchs的文章中了解到更多关于ios7的字体预处理。

一个图标胜过千言万语

图像学在所有主流移动平台的用户体验上是一个重要的部分。相比字体，你一定更愿意使用用户已知的icon，回顾一下我之前说过的高分辨率屏幕，要确保你的icon的大小是可调节的，将它们作为字体通过css的 @font-face来实现，浏览器会有很好的兼容性支持，你甚至可以通过css改变icon的样式（比如颜色、阴影和透明度)。以下是我的推荐:

获取多个平台的icon字体 Ionicons是我们的基本设置，因为它几乎包含了所有我们需要的东西。除了他们常用的一些icon之外，还包含了ios和android的一些特殊的icon，其余的来源于 ios、Android set 1和 set 2以及 Windows Phone的特殊icon字体.
将它们用icon字体生产器结合起来用不同的icon字体让我们感觉非常混乱，还会迅速的增加文件大小，这就是我们为什么使用 Fontello来结合不同字体、调整代码和针对每个平台输出的原因。这样的结果就是 <span class="icon">s</span>在IOS、Android和Windows Phone中看起来是一个搜索图标。同时，还可以了解一些其他比较流行的方案，比如 IcoMoon和 Fontastic。

在 Windows Phone上,你还可以脱离Native font-family: 'Segoe UI Symbol'。

性能优化

性能经常被认为是hybrid移动app中一个主要的缺陷，尤其当你的app有大量的动画，包含大量的滚动列表并且需要在旧设备上运行的时候，缺点会越发的明显。然而，如果你觉得能够接受只支持一些比较新的平台版本(Android 4+,iOS 7+和Windows Phone 8+)的话，那你应该就会看到满意的效果。最终的问题就在于你在优化DOM和CSS选择器、书写高性能的Javascript、减少渲染时间和最少化重排重绘上花了多少工夫。关于移动网页性能的文章和教程一大把，以下是我最喜欢的一些:

“ 成功PhoneGap App的性能和UX考虑因素”，Andrew Trice
“ 移动：网页性能” (幻灯片)，Estelle Weyl
“ 书写快速、内存高效的Javascript,” Addy Osmani, Smashing Magazine
“ 浏览器重排最少化,” Lindsey Simon, Google Developers
“ 如何让你的网站在移动设备上运行更快,” Johan Johansson, Smashing Magazine

此外，随着每天都有新的设备推出，移动硬件和渲染引擎都在以一个非常迅猛的速度提升，开发者能够做到使iPhone5系列、Android手机与Nexus4和5的纯原生App的性能上基本一致。

提升感知速度

构建高效的app是一回事而，让app感觉上运行很快又是另一回事儿。无论你的app是否需要一些时间来完成某项任务(比如一些复杂的计算或者客户端和服务器端的交流)，实时反馈对于提供流畅和响应式体验至关重要。一个比较常用的方法是，在用户还不需要某些功能的时候推迟加载，对用户接下来可能进行的操作作预估和预加载。Instagram有一个著名的例子，当用户忙于添加标签和分享的时候，在后台上传图片。感知速度和真正的速度是不一样的，让我们合理运用它。这里有一些非常简单的例子：

消除触屏设备上点击的延迟

触屏设备中的一个普通Javascript点击事件，从点击的最开始到得到响应会有轻微的延迟(大约300毫秒)，浏览器的这种行为是在判断用户是单击还是双击，如果你不需要“双击以放大”特性，你可以安全的消除这300毫秒从而换取更多响应操作，我最喜欢的解决方案是 FastClick库，你可以把它用在除了IE的所有浏览器上：

js if ('ontouchstart' in window) { window.addEventListener('load', function() { FastClick.attach(document.body); }, false); }

IE10以上比较容易解决,你只需要添加一些css代码:

css html { -ms-touch-action: manipulation; /* IE 10 */ touch-action: manipulation; /* IE 11+ */ }

设计点击状态的样式

只要用户点击一些可操作的元素（例如按钮或者链接），app检测到以后应该马上给他们一些回应。就像在台式机上表现不错的css的伪类 :hover，在移动端你需要换成 :active或者一些javascript解决方案。我曾经在JSFiddle上比较过三种点击状态的方案，你可以根据你的实际情况使用。

还有，记得在调整移动端点击状态的时候清楚默认点击高亮的样式，此外我建议禁用用户在一些活动的元素上选择，因为如果用户不小心点击按钮的时间过长，出现的选择菜单会很烦人。

iOS and Android:

css button { outline: 0; -webkit-tap-highlight-color: rgba(0,0,0,0); -webkit-tap-highlight-color: transparent; -webkit-touch-callout: none; -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; }

Windows Phone 8+:

html <meta name="msapplication-tap-highlight" content="no">

提示加载

你的app总是需要一些时间来完成动作，即使只有一秒，所以要考虑添加加载提示，否则用户就可能认为有时候app卡住了，或者在不应该点击的时候乱点，甚至他们可能会乱砸东西并且归责于你的app。根据我的经验，移动端浏览器运用gif动画不是一个好方法。一旦CPU上有一个加载项，gif卡住了，那么这个GIF对用户的加载提示就完全没有作用了。我更喜欢 Spin.js，因为可以自己配置并且运用简单，当然，还有一些其他的方法： javascript解决方案和 css加载方案。

一些跨平台的工具比如PhoneGap和Trigger.io也提供一些原生的加载状态，对于全屏动画加载的展现很棒。

正确设置滚动

滚动在许多app中是决定用户体验的最重要因素之一，它让人又爱又恨，因为要实现这一点取决于你应用依赖的滚动细节以及需要手机系统支持。

几乎所有的app都使用了可滚动内容和固定头部和/或底部。通常有两个CSS方法来实现：

在 body上启用滚动，在header上增加 position: fixed；
在 body上禁用滚动，在内容上增加 overflow: scroll；
在 body上禁用滚动，在内容上增加JavaScript默认滚动。

虽然第一种方法有一些优点（例如IOS的原生滚动到顶部动作以及简洁的代码结构），我强烈推荐第二种方法： overflow: scroll。这个方法渲染问题更少（虽然还是比较多），现代平台上的浏览器支持更好（Android 4+，IOS 5+和Windows Phone 8+)，对于低版本浏览器有方便的小插件。另外，你可以把 overflow: scroll换成自定义的滚动库（第三种选择），例如 iScroll。虽然这些JavaScript解决方案使得特性更加灵活（例如，带动量效果的滚动位置，事件处理，可定制的效果和滚动条等），但它们通常会影响性能。当你在内容里用了许多DOM节点和/或CSS效果（例如 box-shadow， text-shadow, opacity和 rgba)时会很危险。

让我们来看一些基本的滚动特性。

动量效果

触摸友好的动量效果使得用户在大块内容区域的快速滚动显得很直观。通过一些简单的CSS就能在IOS 5+以及Android上一些版本的Chrome中激活。在IOS上，这也会使得内容不溢出顶部和底部边界。

css overflow-y: scroll; -webkit-overflow-scrolling: touch;

下拉刷新

网页上有许多实现这个效果的方法，例如 Damien Antipa写的一种。这个方法在IOS和Windows Phone中效果和体验很相似，Android最近发布它特有的结构（如下）。我们通过一些JavaScript和CSS keyframes在CatchApp里实现了这个效果。（我还没有总结好放到Github上，所以还在调整！）

IOS中的下拉刷新。 (图片属于: Damien Antipa)

Android中的下拉刷新。 (图片属于: Android Widget Center)

Windows Phone中的下拉刷新。 (图片属于: David Washington)

滚动回到顶部

不幸的是，在 body上禁用滚动的同时会破坏IOS中允许用户通过点击状态栏快速回到页面顶部的原生特性。我写了一小段可以添加在任何元素上的脚本来使用JavaScript解决滚动到顶部的问题，即便内容当前处于动量效果中。把它添加到手机端网页头部或通过原生插件添加到状态栏上（例如，PhoneGap）。

许多其他滚动的特性可以通过原生 overflow: scroll实现，例如关闭特定元素或只是无限滚动。如果需求更加复杂，一定考虑使用JavaScript方法。

让点击更容易

用户触摸时，很容易跟目标偏差几个像素，尤其是点击小按钮时（例如IOS顶部条上的按钮）。开发者可以在保证设计的情况下通过在小目标周围开启不可见触摸区域来使用户体验更好。

html <button> <div class="innerButton">Click me!</div> </button>

你需要在按钮元素上绑定事件处理器，同时用 div.innerButton定义样式。在JSFiddle上查看完整的，含有CSS的例子。

使用触摸手势

智能手机的精髓就是触摸和手势。在和触摸设备交互时，我们总是滑动，按压，缩放，拖动和长按。所以，为什么不提供相同的方式来让用户控制你的hybird应用呢？ QuoJS和 Hammer.js是广为人知的支持所有手势类型的库。如果你想要更多选择，看一下Kevin Liew对” 11个多点触摸和触摸事件JavaScript库“的比较。

不要忘了原生功能

用网页技术构建你的应用并不意味着你不能用原生特性。事实上，所有主要的跨平台开发工具提供了提供了内置的对重要功能的接口。其中有许多API包括调用设备数据，文件系统，网络连接，地理位置定位，加速度传感器，提示（包括推送）等等。

通常，你甚至可以通过构建自定义插件来扩展开发工具。在Hojoki,我们加入了许多缺失的特性，包括读取用户对于我们app的推送提示的设置，读取用户时区，检查是否安装第三方APP并启动。让我们来看两个关于用原生插件实现的效果的例子。首先，让我们对IOS 6+里的input启动JavaScript focus（）：

js if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 6) { [YourWebView setKeyboardDisplayRequiresUserAction:NO]; }

下面是在IOS上把给定字符串复制到设备剪贴板里的代码：

[[UIPasteboard generalPasteboard] setString:@"Your copied string"];

总要留有出口

网页开发者经常忽视如何处理hybird应用中的糟糕情况（例如，连接超时，错误输入，时间问题等等）。hybird应用从根本上区别于网站，主要因为它没有全局刷新按钮，在一些移动端操作系统里应用很容易在后台运行数周。如果用户死机了，他们唯一的选择是重启应用，这势必要强制退出然后重启。许多人甚至不知道怎样重启，尤其是在Android 2.x上（它深深隐藏在app设置里）和IOS 6及以下版本上（你需要双击home键，长按图标并且关闭它）。

所以，在开发中先不要觉得有刷新按钮就万事大吉而不考虑出错的情况，我们应该做的是遇到问题就立即解决。对于其他所有意外的情况，例如包含客户端-服务端的通信，准备好应对错误情况，给用户提供一个出口。可以简单得显示一个全屏的错误信息-“欧！出了些问题。请检查你的连接并再次尝试”-下面放一个大大的“重新载入”按钮。

如何打包

开发hybrid移动app就需要用到通常开发（移动）网站一样的工具，开发流程也一样。虽然这么说，我真正喜欢hybrid的地方是你能比较轻松地使用HTML、CSSS和JavaScript来部署移动web app。确保对原生特性实现回退，或在完全不支持该特性的情况下找到优雅的解决方案。大多数移动开发者更喜欢让用户群留在原生app上，甚至可以向使用移动网站的用户宣传这个app。

基于HTML、CSSS和JavaScript的原生WebView打包器

那原生部分怎样呢？移动web app（纯的HTML、CSSS和JavaScript）将加载到一个WebView中。作为一个内部浏览器引擎，WebView会按照设备的默认浏览器渲染网页的方式渲染app（可能会存在细微差别——你遇到的情况可能有所不同）。而且，原生“应用开发平台”用来暴露设备和操作系统的特性，而JavaScript能通过API调用到这些特性。这个API通常包含有调用特性的接口，比如设备摄像头、通讯录、地理位置、文件系统和原生事件（比如通过Android的硬件按钮）等特性。

有一些跨平台的开发工具提供了原生应用开发平台，简化了整个打包流程。下面深入研究部分工具。

PHONEGAP和APACHE CORDOVA

PhoneGap绝对是一个最流行的跨平台开发工具之一，它的名字本身经常被当作hybrid移动app开发的同义词。

关于它的名字以及与 Apache Cordova的关系存在的一些误解是可以理解的。后者是顶级Apache项目，曾用名就是PhoneGap。它提供了一套设备API，并通过运行在WebView中的HTML、CSSS和JavaScript调用原生的功能。现在，Adobe PhoneGap是Cordova的一个分支——与Chrome使用Webkit作为其引擎没有什么不同。

两者都是开源和免费的，支持所有主流平台，拥有一个开发各类插件和扩展的活跃社区。

PhoneGap对塑造hybrid贡献巨大，涌现出的很多新的工具提供了 附加功能，使开发流程简单。这些工具带来了很多便利：通过在云端构建app，免去了在本地安装所有不同平台的SDK和工具的工作。每个工具都有不同的关注点、平台支持度和价钱：

PhoneGap Build
Telerik AppBuilder（前身是Icenium）
AppGyver Steroids
Appery.io（前身是Tiggzi）
Monaca
Intel XDK

SENCHA TOUCH

Sencha Touch最初是一个针对移动web的UI框架，存在有几年了。过去，开发者使用Sencha构建app需同时使用其他如PhoneGap这样的服务来部署成hybrid app。现在Sencha内置了这种功能，可免费使用。支持的平台有iOS和Android（都需要通过Sencha自有的原生打包工具），BlackBerry、Windows 8等更多（通过PhoneGap Build）。

TRIGGER.IO

在Hojoki，我们在两年半前开始用 Trigger.io，因为当时想找一个比PhoneGap轻量级的替代品。虽然它只支持iOS和Android平台，但它提供了一套很不错的原生API、自定义插件和第三方集成（包括Parse消息推送服务、Flurry分析器以及部分Facebook的SDK）。通过Trigger.io的命令行工具，可以将app打包集成到 Grunt的构建过程。如果喜欢自动化，这一点很棒。

它的一个重要特性是 Reload，该特性能使开发者推送HTML、CSSS和JavaScript的更新到运行中的app。与PhoneGap Build的 Hydration不同，Reload专门为开发和生产app设计。这样就使得合法绕过Apple的提交流程去提交bug解决方案和用A/B测试快速迭代就成为可能。

对很多开发者来说，一旦14天的试用期结束，Trigger.io 极高的价格可能就是它最大的缺点。

MoSync似乎是另一种不与PhoneGap有瓜葛的工具，但不太确定当下它的开发活跃度怎样。

在真机上测试

显然，用web技术构建移动app会诱使我们在web浏览器上做大部分的测试。在开发非原生特性时还算说得过去，但在发布时一定要避免。提交app之前，要在尽量多的生产商、平台和各种机型各种版本上测试。Android的机型和版本太多，在浏览器渲染、特性支不支持和生产商更改上会千差万别。虽然iOS渲染的差异好很多，但Apple生产的不同尺寸、分辨率和像素密度的设备越来越多。想了解更多请点击查看“ 设备优先级：测试和响应式web设计”。

在2012年，Facebook放弃绝大部分HTML5开发转向原生开发，其中一个主要原因是“ 缺少调试工具和开发者API”。半年后， LinkedIn得出同样的结论，声称HTML5本身准备好了，但基础工具和生态系统还没来得及支持它。从我的角度来说，情况正变得越来越好：Android 4.4+支持WebView的远程调试；各平台的开发工具越来越多：

“ Web检测器”，Safari（iOS）
“ 使用Chrome在Android上远程调试”
“ 在Visual Studio里调试商店app” (Windows Phone 8.1), Windows Dev Center
Weinre（针对所有平台），Patrick Mueller
Edge Inspect（针对iOS和Android），Adobe

开始考虑硬发布

为web浏览器构建app时，为用户部署修复程序是简单的一步，这意味着测试会失去其重要性。当通过app商店发布app，这就需要重新考虑了。把它想成上世纪90年代的软件开发：你现在就生活在硬发布的世界里。

那么，为什么这很糟糕？首先，提交过程随便就是一两周（寨见，Apple！）。其次，即使修复程序很快发布，也不能保证用户在短时间更新app。以下是我的建议：

测试的优先级要高。
有类似“强制更新”的逻辑来放弃旧有客户端版本。
使用类似Trigger.io的 Reload的机制来修复运行中的代码。
如果想快点，申请紧急app审核。

发布到商店

上面提到的工具会为每个平台生成一个版本，然后将这些版本提交到相应的商店。从这点，过程和发布一个“普通”的原生app几乎一样。在这方面，有些已讨论过的工具可能有更好的文档。尽管这样，以下是官方指南：

“ App分发指南”，Apple
“ 发布入门手册”和“ 发布清单”，Android开发者
“ Windows Phone发布”，Windows研发中心

结论

既然开发的hybrid移动app在Apple的App商店和Google Play已经上线两年了，这里我就总结下在本文开头提到的一些优点和缺点。

对于我们这样一个资源有限、没有原生iOS和Android开发经验的创业公司，要在短短的几周内构建一个多平台的app是不可能的。选择hybrid，我们就能复用很多web app的代码，根据用户反馈迭代速度就快。我们已经成功发布了支持桌面Windows 8和微软Surface的原生app，支持Mac OS X的app也使用了基本一样的代码。移植到另一个平台的工作量很大程度上取决于给定浏览器与设备的能力和所需要的原生功能的水平高低。我们需要消息推送、app内置购买、获取用户联系方式，以及其他功能。根据你的需求，很多原生功能会使你很依赖于所选择的原生打包工具。

最后，我们来看看hybrid app是否真的能给出一个原生的感官享受。以下精选了来自app商店的用户评论。积极和消极的评论都有，其中很多消极的评论来自早期版本——各平台UI一样，性能相对较慢。

评论略去

的确，我们正远离特定平台的app开发而面向不断涌现的很多新技术。去年的Google I/O大会上被问到关于web的未来， Larry Page说：

在很长一段时间，我不认为作为开发者的你会考虑是否为这个平台或那个平台或其他类似平台在开发。我认为你应该在更高的层次上工作，你所写的软件能在每个平台运行起来，而且是很容易地运行起来。

在这方面，（移动）web取得了很大的成功。使用这个平台而且仍然能在所有商店分发app是向前迈出的巨大一步。未来会发生什么敬请期待。无论发生什么，使用世界上1/3人口（其中超过2/3来自欧洲和美国）依赖的技术大概不会是一个坏的选择。

传说中的新版Google翻译到底有多厉害？

Wed, 14 Jan 2015 08:50:17 CST

上周末，纽约时报的一篇有关于语言翻译技术进步的报道，让许多人为科技发展的速度之快所震撼：该报道指出， Google多年没有过大变化的翻译（Google Translate）服务，即将迎来一次大功能更新，将可以聆听并识别用户所讲的语言，然后几乎实时地将语音翻译为目标语言的文字。这个功能听上去十分强大，看起来Google的自然语言处理技术已经发展的足够好，估计可以让不少翻译和同声传译员工丢掉工作了。

Google翻译是目前全世界最多人使用的翻译产品，支持90种语言之间的互相翻译，包括了阿拉伯语、英语、法语、德语、汉语、西班牙语等在内的所有热门语种。纽约时报的报道显示，web、iOS和Android等各平台上的月活跃用户已经超过了5亿，仅Android版Google翻译应用的下载安装量（这是一款非预装应用）就已经高达1亿。

在机器翻译的领域内主要由三种大层面上的翻译技术门类，分别为“基于规则”（rule-based）、“基于统计”（statistical-based）和混合。其中，Google属于“基于统计”，可以通过用户直接搜索的翻译结果、对网页内容的抓取翻译等多种不同的渠道获取大量的语料资源用于深度学习，从而逐渐获得一种明白两种语言的文字之间如何匹配的能力，并且将这种能力作为服务提供给用户。

显然，这次Google翻译的服务水平又上了一个等级。如果你把你已经安装了Google翻译的手机看做是一个人的话，其实ta已经变成一个翻译效率相当高的电子翻译官了。不过，Google翻译给很多人的印象之前一直不怎么好，比如那些出现在交通标志上、超市甚至厕所里的令人啼笑皆非的翻译，就经常被吐槽为“Google机翻”的结果。人们不由得感叹：Google这么厉害的一家公司，连个机翻都搞不好吗？

一位前Google翻译团队科学家告诉 PingWest品玩，Google这个即将发布的新版翻译产品，其背后所需要的研发远比想象的复杂。

过去的Google翻译的功能背后的主要技术是机器翻译（Machine Translation），后来随着Android以及iOS操作系统功能的进步，在移动端支持了语音输入，这又引入了语音识别（Speech Recognition）。“机器翻译和语音识别从技术层面上是单独的产品，背后都会用到很多自然语言处理（Natural Language Processing，NLP），‘深度学习’的基本技术。”这位专家表示。

专家认为，从目前媒体报道和行业了解的信息来看，新的Google翻译是一个将机器翻译和语音识别整合起来的产品，“从技术层面，Google应该早就有能力推出这种功能了（编者注：指语音识别并实时翻译），但是拖到现在才出来，可能会有一些其他的考虑。总的来说，两大技术集成起来需要做大量的优化，而不是简单地拼凑起来。”

也即意味着，新版Google翻译是Google的机器翻译技术和语音识别技术进行了系统性的整合之后投产的结果，将能够代表Google在自然语言处理方面的深度学习所取得的进展，以及其商业化能力。前述的前Google科学家指出，Google的翻译技术在他在职期间（两年前）就已经处在业界领先水平。而这两年以来Google在深度学习方面的进展一直十分突出，因此有理由（比较稳妥地）相信，Google基于深度学习提供的翻译服务，其背后的技术依然可以代表业界的最高水准。

当然，人们对于Google翻译的技术到底有多厉害可能并没有多少感知——他们能够感知到的，其实是不要把干货翻译成f**k good就好。

2014盛行与即将消逝的网页设计趋势

Sun, 02 Mar 2014 01:03:32 CST

[国外设计第30期]

过去两年来，我们见证了网页设计不可思议的变化，继而预测下一股可能出现的热潮。不管怎样，关于今年哪些趋势将会盛行，哪些将会消逝，我已经有些自己的预感了。看看你是否与我不谋而合！

（这是 2013年网页设计趋势回顾）

即将盛行的趋势

有几种趋势即将到来，每一种都令我兴奋不已。今年的设计圈将大有看点，因为我觉得有一大堆变化即将发生，导致激动人心的走向。

模糊背景

幸亏去年夏天的 iOS7发布，设计师们像发疯般地将它作为灵感来源。其中诞生了一种出色的趋势，模糊背景被更多地使用。这个概念是指你当前所在的界面盖在前一个的上面。想想水雾弥漫的浴室门，它的背景就是模糊的。它确实是种非常酷的趋势，因为很多这类背景创造出了相当美观的非线性渐变。

Emotions of sound

Trippeo

简单的动画

从iOS7中诞生的另一个趋势，就是简单的动画效果。在网站和app中随处可见，它们是一些精妙的动画，为设计增添释义和个性。你可以在手势操作中发现它的身影，比如当你在信息中上下移动聊天气泡时，它们会相互碰撞。点击事件中也有，当你点击导航，它不是直接出现，而是向下滚动出现。CSS动画和变换的广泛使用，造就了诸多此类效果。

Theme kingdom

Big Cartel

简单的配色

过去一年里，大胆明亮的颜色已经为自己正名了。不过，使用亮色的微妙浅色搭配也一样。我说这个趋势时，基本上是指Google。很多他们的UI广泛使用了浅灰色和少量微妙的颜色，让网站看上去轻巧干净。

Ora ito

更棒的用户体验

还有一种由来已久的趋势，在网页设计中提升用户体验。我觉得这一点只会日趋重要。有一场重大的运动正在进行，旨在将用户体验与商业战略相结合，在网站和app上提供更好的整体体验。这确实是商业中相当重大和明智的转变，当然，它们两者是相辅相成的。

Exposure

Trail spring

大字体

网页字体也获得了高度关注。随着 SVG图标字体的崛起，它们也变得越来越受欢迎。当我思考网页字体时，我所想的是将大字体整合进设计当中。它们圆滑、浑厚，也很美观，但不只限于此。目前，Iconic的奇才正在掀起一场图标字体的革命，他们在尝试创作响应式图标。

Time Brack

Happy

私人化内容

人们不喜欢没有人情味的东西，尤其在网上。一想到与机器甚至另一个企业打交道，他们就没有好感。因此，你会看到一些创业公司去除了他们网站上那些优雅的内容，却凭公司背后活生生的人物脱颖而出。内容为王，这是你和你的在线读者联系的唯一方式。你得将它个性化。让你的文章和图片显得友好、厚脸皮或是古怪，这样便能让用户与你建立联系。

Wondersuance

Create pilates

糟糕的趋势

另一方面，今年有一些东西会变得越来越罕见。见证设计和行业趋势变化确实是件了不起的事情。你不觉得吗？无论怎样，对于这点你不必太难过。

低画质的照片与视频

作为设计师，囤积照片一直是个坏主意。不管怎样，你是否注意到近一两年来，照片的画质总体在上升？它绝对与更大尺寸的图片作为设计元素来使用有关，比如图片放大充满整个页头的宽度与高度。想到画质糟糕的图片正在淡出历史舞台，真是让人心情愉悦。整个行业把照片画质的标准定得非常高——它也应该如此——因为图片也是内容的一部分，画质会成就或破坏一件设计与公司品牌。无需多说，我觉得这一段陈述对于视频的画质也是一样。

FiftyThree Pencil

Agst

扁平与拟物

扁平与拟物设计之争已经逐渐被淡忘。我坚定地相信这两个极端都将被淘汰，取而代之，我们会看到更多介于两者之间的界面，它们有着微妙的渐变和讨喜的阴影。我觉得扁平与拟物这两者的粉丝，不得不将它们吸收融合，它们都只是一种趋势，两者都会走到尽头。如果你愿意的话，为两者找到某种妥协吧。

Bright Media

Elegant Seagulls

冗长的表单

随着极简主义的兴起，我注意到表单的填写正在变得更简单。这是因为公司最终听取了用户调研的意见，人们不喜欢在网上填写表单。表单越大越长，用户就越难顺利填完。你多久一次能见到不需要重复确认email和密码的表单？无论是多久，你会看到更多这样的设计。而那些询问你生活中的每个细节，还有你生的第一个小孩，就仅仅为了注册一个免费email的笨拙讨厌的表单，会逐渐减少。

Treehouse

General Assembly

原文链接

随意看看吧
网页设计中的方块元素	网页设计中的半透明运用准则	将APP设计理念用于网页设计	网页设计的10个灵感来源	“理所当然”的设计
无觅

通过留白打造简洁有效的设计

Sun, 12 Jan 2014 14:16:57 CST

[国外设计第26期]

有时最有效的设计技巧，就是什么也没有。

而且它的目的性非常强。

留白是最有力的设计素材之一。它使得文字清晰易读，将注意力吸引至某部分，并且有助于打造整体氛围。

本文中，我们来看看一些优秀的留白使用案例，看看它们如何创造简洁的同时，有效地为不同网站定义了设计风格。

留白的基本要素

留白和负空间的术语近年来被交替使用，它们指画布（或数码设备屏幕）上不包含任何内容的空间。简而言之，留白就是空白。

但是留白空间不一定要是白色的。这个术语指的是任何与背景相同的空间。所以它可以是白色、黑色，甚至包含微妙的纹理。

空间是所有设计的重要组成。字间距和行间距决定了文字的易读性。如果文字靠的太近或太松散，就很难阅读。关键是找到平衡点。

留白也能把图片和其他元素区分开。回想一下你见到过的杂乱无章的网站。通常问题就在于元素间没有足够的空间。记得在元素和文字间留下足够的边距，为了更加专业的外观，应该进一步使用统一的边距。在设计多列网站时也是同样的道理（即使只有主栏和边栏），在垂直元素间加入适当的空隙，就创造出了明显的划分。

留白还有助于引导视线，为设计建立层次，区分什么是重点和关键点。视线会立即移动到被留白包围的元素上。留白为其中的元素增添了冲击力。

留白是创造平衡、协调的工具，也是组织网站内容的基础。没有留白，如何为元素分组？如何找到导航？你又怎么知道滚动有更多内容，或是应该从左上往右下浏览？所有这些视觉线索，都来自于设计中留白的合理运用。

重点使用留白的地方

虽然有效使用留白是任何设计的重要部分，还是有些地方值得注意。

请看以下清单：

logo周围
每个导航按钮或图标周围，并围绕这些元素的“容器”
在两列文字间，在主体部分与边栏之间
当你使用视觉差效果时，在每页“滚屏”之间
在所有不同的元素之间，比如照片和文字之间，或是主体内容与页尾之间

12例留白的有效运用

Adhara：看看左侧的边栏和主体内容的距离。此处的留白确实在元素之间创造了很棒的区分，并使彼此通过自己独有的方式突出展示。

BeoPlay A9：背景与中央物体形成简洁的对比，创造了独特的视觉焦点。与优秀的对齐排布结合时，留白还有助于将注意力从图片引导至文字段落。

Fixate：在一个像这样丰富的设计中，留白告诉你的眼睛应该看哪里（还有点击哪里）。

Google：这个搜索引擎已经使用留白很长时间了，白色的海洋中，它只有一个简单的数据入口和一个logo在。

Jac in a Box：留白在此处的运用是如此抢眼，因为它真的很大面积。将的视线从logo（本身的留白就运用非常完美）吸引到另一个角落的主体文字上。

Lapka：这家公司用了一种独具创意的方式，通过阴阳式的留白，将视线吸引到这些小物件上。

Leah Haggar：白色字体在黑色空间上很突出。精妙的底纹为整体效果增色不少。

Medium：这是一个使用非白色留白的绝佳案例。

Metta Skincare：通过对图片进行设计，留白为文字提供了绝佳的展现位置。

PandaWeb：留白直接将注意力转移至这家公司的业务上。

Square：这个网站将元素间的留白运用得很棒，作为图片和按钮的视觉焦点，也作为分栏的间隙。每个细节处的留白都精心处理过，创造了视觉冲击。

The Mealings：简洁、美观、舒适。留白——在设计与logo中——成就了这些特点，看起来简洁得不可思议

原文链接

随意看看吧
网页设计中的方块元素	丸子烘焙LOGO设计	隐形设计	将APP设计理念用于网页设计	设计与魔法师
无觅

[翻译]十条有用的 Go 技术

Thu, 24 Jul 2014 16:10:57 CST

原文在此，实用总结。
————翻译分隔线————

十条有用的 Go 技术

这里是我过去几年中编写的大量 Go 代码的经验总结而来的自己的最佳实践。我相信它们具有弹性的。这里的弹性是指：
某个应用需要适配一个灵活的环境。你不希望每过 3 到 4 个月就不得不将它们全部重构一遍。添加新的特性应当很容易。许多人参与开发该应用，它应当可以被理解，且维护简单。许多人使用该应用，bug 应该容易被发现并且可以快速的修复。我用了很长的时间学到了这些事情。其中的一些很微小，但对于许多事情都会有影响。所有这些都仅仅是建议，具体情况具体对待，并且如果有帮助的话务必告诉我。随时留言:)

1. 使用单一的 GOPATH

多个 GOPATH 的情况并不具有弹性。GOPATH 本身就是高度自我完备的（通过导入路径）。有多个 GOPATH 会导致某些副作用，例如可能使用了给定的库的不同的版本。你可能在某个地方升级了它，但是其他地方却没有升级。而且，我还没遇到过任何一个需要使用多个 GOPATH 的情况。所以只使用单一的 GOPATH，这会提升你 Go 的开发进度。

许多人不同意这一观点，接下来我会做一些澄清。像 etcd 或 camlistore 这样的大项目使用了像 godep 这样的工具，将所有依赖保存到某个目录中。也就是说，这些项目自身有一个单一的 GOPATH。它们只能在这个目录里找到对应的版本。除非你的项目很大并且极为重要，否则不要为每个项目使用不同的 GOPAHT。如果你认为项目需要一个自己的 GOPATH 目录，那么就创建它，否则不要尝试使用多个 GOPATH。它只会拖慢你的进度。

2. 将 for-select 封装到函数中

如果在某个条件下，你需要从 for-select 中退出，就需要使用标签。例如：

func main() {

L:
    for {
        select {
        case <-time.After(time.Second):
            fmt.Println("hello")
        default:
            break L
        }
    }

    fmt.Println("ending")
}

如你所见，需要联合 break使用标签。这有其用途，不过我不喜欢。这个例子中的 for 循环看起来很小，但是通常它们会更大，而判断 break的条件也更为冗长。

如果需要退出循环，我会将 for-select 封装到函数中：

func main() {
    foo()
    fmt.Println("ending")
}

func foo() {
    for {
        select {
        case <-time.After(time.Second):
            fmt.Println("hello")
        default:
            return
        }
    }
}

你还可以返回一个错误（或任何其他值），也是同样漂亮的，只需要：

// 阻塞
if err := foo(); err != nil {
    // 处理 err
}

3. 在初始化结构体时使用带有标签的语法

这是一个无标签语法的例子：

type T struct {
    Foo string
    Bar int
}

func main() {
    t := T{"example", 123} // 无标签语法
    fmt.Printf("t %+v\n", t)
}

那么如果你添加一个新的字段到 T结构体，代码会编译失败：

type T struct {
    Foo string
    Bar int
    Qux string
}

func main() {
    t := T{"example", 123} // 无法编译
    fmt.Printf("t %+v\n", t)
}

如果使用了标签语法，Go 的兼容性规则（ http://golang.org/doc/go1compat）会处理代码。例如在向 net包的类型添加叫做 Zone的字段，参见： http://golang.org/doc/go1.1#library。回到我们的例子，使用标签语法：

type T struct {
    Foo string
    Bar int
    Qux string
}

func main() {
    t := T{Foo: "example", Qux: 123}
    fmt.Printf("t %+v\n", t)
}

这个编译起来没问题，而且弹性也好。不论你如何添加其他字段到 T结构体。你的代码总是能编译，并且在以后的 Go 的版本也可以保证这一点。只要在代码集中执行 go vet，就可以发现所有的无标签的语法。

4. 将结构体的初始化拆分到多行

如果有两个以上的字段，那么就用多行。它会让你的代码更加容易阅读，也就是说不要：

T{Foo: "example", Bar:someLongVariable, Qux:anotherLongVariable, B: forgetToAddThisToo}

而是：

T{
    Foo: "example",
    Bar: someLongVariable,
    Qux: anotherLongVariable,
    B: forgetToAddThisToo,
}

这有许多好处，首先它容易阅读，其次它使得允许或屏蔽字段初始化变得容易（只要注释或删除它们），最后添加其他字段也更容易（只要添加一行）。

5. 为整数常量添加 String() 方法

如果你利用 iota 来使用自定义的整数枚举类型，务必要为其添加 String() 方法。例如，像这样：

type State int

const (
    Running State = iota 
    Stopped
    Rebooting
    Terminated
)

如果你创建了这个类型的一个变量，然后输出，会得到一个整数（ http://play.golang.org/p/V5VVFB05HB）：

func main() {
    state := Running

    // print: "state 0"
    fmt.Println("state ", state)
}

除非你回顾常量定义，否则这里的 0看起来毫无意义。只需要为 State类型添加 String()方法就可以修复这个问题（ http://play.golang.org/p/ewMKl6K302）：

func (s State) String() string {
    switch s {
    case Running:
        return "Running"
    case Stopped:
        return "Stopped"
    case Rebooting:
        return "Rebooting"
    case Terminated:
        return "Terminated"
    default:
        return "Unknown"
    }
}

新的输出是： state: Running。显然现在看起来可读性好了很多。在你调试程序的时候，这会带来更多的便利。同时还可以在实现 MarshalJSON()、UnmarshalJSON() 这类方法的时候使用同样的手段。

6. 让 iota 从 a +1 开始增量

在前面的例子中同时也产生了一个我已经遇到过许多次的 bug。假设你有一个新的结构体，有一个 State字段：

type T struct {
    Name  string
    Port  int
    State State
}

现在如果基于 T 创建一个新的变量，然后输出，你会得到奇怪的结果（ http://play.golang.org/p/LPG2RF3y39）：

func main() {
    t := T{Name: "example", Port: 6666}

    // prints: "t {Name:example Port:6666 State:Running}"
    fmt.Printf("t %+v\n", t)
}

看到 bug 了吗？ State字段没有初始化，Go 默认使用对应类型的零值进行填充。由于 State是一个整数，零值也就是 0，但在我们的例子中它表示 Running。

那么如何知道 State 被初始化了？还是它真得是在 Running模式？没有办法区分它们，那么这就会产生未知的、不可预测的 bug。不过，修复这个很容易，只要让 iota 从 +1 开始（ http://play.golang.org/p/VyAq-3OItv）：

const (
    Running State = iota + 1
    Stopped
    Rebooting
    Terminated
)

现在 t变量将默认输出 Unknown，不是吗？：

func main() {
    t := T{Name: "example", Port: 6666}

    // 输出： "t {Name:example Port:6666 State:Unknown}"
    fmt.Printf("t %+v\n", t)
}

不过让 iota 从零值开始也是一种解决办法。例如，你可以引入一个新的状态叫做 Unknown，将其修改为：

const (
    Unknown State = iota 
    Running
    Stopped
    Rebooting
    Terminated
)

7. 返回函数调用

我已经看过很多代码例如（ http://play.golang.org/p/8Rz1EJwFTZ）：

func bar() (string, error) {
    v, err := foo()
    if err != nil {
        return "", err
    }

    return v, nil
}

然而，你只需要：

func bar() (string, error) {
    return foo()
}

更简单也更容易阅读（当然，除非你要对某些内部的值做一些记录）。

8. 把 slice、map 等定义为自定义类型

将 slice 或 map 定义成自定义类型可以让代码维护起来更加容易。假设有一个 Server类型和一个返回服务器列表的函数：

type Server struct {
    Name string
}

func ListServers() []Server {
    return []Server{
        {Name: "Server1"},
        {Name: "Server2"},
        {Name: "Foo1"},
        {Name: "Foo2"},
    }
}

现在假设需要获取某些特定名字的服务器。需要对 ListServers() 做一些改动，增加筛选条件：

// ListServers 返回服务器列表。只会返回包含 name 的服务器。空的 name 将会返回所有服务器。
func ListServers(name string) []Server {
    servers := []Server{
        {Name: "Server1"},
        {Name: "Server2"},
        {Name: "Foo1"},
        {Name: "Foo2"},
    }

    // 返回所有服务器
    if name == "" {
        return servers
    }

    // 返回过滤后的结果
    filtered := make([]Server, 0)

    for _, server := range servers {
        if strings.Contains(server.Name, name) {
            filtered = append(filtered, server)
        }
    }

    return filtered
}

现在可以用这个来筛选有字符串 Foo的服务器：

func main() {
    servers := ListServers("Foo")

    // 输出：“servers [{Name:Foo1} {Name:Foo2}]”
    fmt.Printf("servers %+v\n", servers)
}

显然这个函数能够正常工作。不过它的弹性并不好。如果你想对服务器集合引入其他逻辑的话会如何呢？例如检查所有服务器的状态，为每个服务器创建一个数据库记录，用其他字段进行筛选等等……

现在引入一个叫做 Servers的新类型，并且修改原始版本的 ListServers() 返回这个新类型：

type Servers []Server

// ListServers 返回服务器列表
func ListServers() Servers {
    return []Server{
        {Name: "Server1"},
        {Name: "Server2"},
        {Name: "Foo1"},
        {Name: "Foo2"},
    }
}

现在需要做的是只要为 Servers类型添加一个新的 Filter()方法：

// Filter 返回包含 name 的服务器。空的 name 将会返回所有服务器。
func (s Servers) Filter(name string) Servers {
    filtered := make(Servers, 0)

    for _, server := range s {
        if strings.Contains(server.Name, name) {
            filtered = append(filtered, server)
        }

    }

    return filtered
}

现在可以针对字符串 Foo筛选服务器：

func main() {
    servers := ListServers()
    servers = servers.Filter("Foo")
    fmt.Printf("servers %+v\n", servers)
}

哈！看到你的代码是多么的简单了吗？还想对服务器的状态进行检查？或者为每个服务器添加一条数据库记录？没问题，添加以下新方法即可：

func (s Servers) Check() 
func (s Servers) AddRecord() 
func (s Servers) Len()
...

9. withContext 封装函数

有时对于函数会有一些重复劳动，例如锁/解锁，初始化一个新的局部上下文，准备初始化变量等等……这里有一个例子：

func foo() {
    mu.Lock()
    defer mu.Unlock()

    // foo 相关的工作
}

func bar() {
    mu.Lock()
    defer mu.Unlock()

    // bar 相关的工作
}

func qux() {
    mu.Lock()
    defer mu.Unlock()

    // qux 相关的工作
}

如果你想要修改某个内容，你需要对所有的都进行修改。如果它是一个常见的任务，那么最好创建一个叫做 withContext的函数。这个函数的输入参数是另一个函数，并用调用者提供的上下文来调用它：

func withLockContext(fn func()) {
    mu.Lock
    defer mu.Unlock()

    fn()
}

只需要将之前的函数用这个进行封装：

func foo() {
    withLockContext(func() {
        // foo 相关工作
    })
}

func bar() {
    withLockContext(func() {
        // bar 相关工作
    })
}

func qux() {
    withLockContext(func() {
        // qux 相关工作
    })
}

不要光想着加锁的情形。对此来说最好的用例是数据库链接。现在对 withContext 函数作一些小小的改动：

func withDBContext(fn func(db DB)) error {
    // 从连接池获取一个数据库连接
    dbConn := NewDB()

    return fn(dbConn)
}

如你所见，它获取一个连接，然后传递给提供的参数，并且在调用函数的时候返回错误。你需要做的只是：

func foo() {
    withDBContext(func(db *DB) error {
        // foo 相关工作
    })
}

func bar() {
    withDBContext(func(db *DB) error {
        // bar 相关工作
    })
}

func qux() {
    withDBContext(func(db *DB) error {
        // qux 相关工作
    })
}

你在考虑一个不同的场景，例如作一些预初始化？没问题，只需要将它们加到 withDBContext就可以了。这对于测试也同样有效。

这个方法有个缺陷，它增加了缩进并且更难阅读。再次提示，永远寻找最简单的解决方案。

10. 为访问 map 增加 setter，getters

如果你重度使用 map 读写数据，那么就为其添加 getter 和 setter 吧。通过 getter 和 setter 你可以将逻辑封分别装到函数里。这里最常见的错误就是并发访问。如果你在某个 goroutein 里有这样的代码：

m["foo"] = bar

还有这个：

delete(m, "foo")

会发生什么？你们中的大多数应当已经非常熟悉这样的竞态了。简单来说这个竞态是由于 map 默认并非线程安全。不过你可以用互斥量来保护它们：

mu.Lock()
m["foo"] = "bar"
mu.Unlock()

以及：

mu.Lock()
delete(m, "foo")
mu.Unlock()

假设你在其他地方也使用这个 map。你必须把互斥量放得到处都是！然而通过 getter 和 setter 函数就可以很容易的避免这个问题：

func Put(key, value string) {
    mu.Lock()
    m[key] = value
    mu.Unlock()
}
func Delete(key string) {
    mu.Lock()
    delete(m, key)
    mu.Unlock()
}

使用接口可以对这一过程做进一步的改进。你可以将实现完全隐藏起来。只使用一个简单的、设计良好的接口，然后让包的用户使用它们：

type Storage interface {
    Delete(key string)
    Get(key string) string
    Put(key, value string)
}

这只是个例子，不过你应该能体会到。对于底层的实现使用什么都没关系。不光是使用接口本身很简单，而且还解决了暴露内部数据结构带来的大量的问题。

但是得承认，有时只是为了同时对若干个变量加锁就使用接口会有些过分。理解你的程序，并且在你需要的时候使用这些改进。

总结

抽象永远都不是容易的事情。有时，最简单的就是你已经实现的方法。要知道，不要让你的代码看起来很聪明。Go 天生就是个简单的语言，在大多数情况下只会有一种方法来作某事。简单是力量的源泉，也是为什么在人的层面它表现的如此有弹性。

如果必要的话，使用这些基数。例如将 []Server转化为 Servers是另一种抽象，仅在你有一个合理的理由的情况下这么做。不过有一些技术，如 iota 从 1 开始计数总是有用的。再次提醒，永远保持简单。

特别感谢 Cihangir Savas、Andrew Gerrand、Ben Johnson 和 Damian Gryski 提供的极具价值的反馈和建议。

没读过设计院校，如何成为设计师

Sun, 23 Feb 2014 01:09:16 CST

[国外设计第29期]

我没有读过设计院校，却成为了设计师。我曾经想要改变职业生涯，当一名设计师，但我没有4年时间和10W美元重回学校去读。所以我决定自学。首先，我很怀疑一个人是否可以通过自学，达到足够胜任工作的水平。

如果你也有相同怀疑，答案是肯定的。

我在6个月时间内完成了自己的设计学业，同时还做着一份全职工作。那时我没觉得自己做好了准备，但还是开始应聘了——并且在一家很棒的创业公司得到了一份工作， Exec。

我承认，我还远不及许多从精英院校学习4年出来的设计奇才。但肯定足够我做好自己工作了。我的设计范围很广——网站、iPhone app、email、社交媒体，还有印刷品。

或许你想改变人生，成为一名全职设计师。或者你只是想学一点基础，支持你的创业公司或副业。

那么这是一份设计自学指南。

第1步：学着观察

最大的错误是过早陷身Photoshop。学习Photoshop没法让你成为设计师，就像买了笔刷也不会让你成为艺术家一样。从基础开始。

首先，学习如何绘画。

不必和一伙艺术家坐在屋子里尝试画一名裸女。
甚至不用那么精于绘画。学一些基础，能够舒服地用钢笔绘图就行。
学习绘画只需要做一件事：买一本书《You Can Draw in 30 days》，每天练习半小时，坚持一个月。我看了很多绘画书籍，这本是最好的之一。

学习平面设计理论

从这本书《Picture This》开始。它是一本小红帽的故事书，但同时也会教你平面设计的基础。
学习色彩，字体，和使用网格设计。如果当地有平面设计的基础学习班，去参加。
每天参加这些课程。

学习基本的用户体验

有很多关于用户体验的书籍。从这两本快速读物开始，它们会帮你树立正确的观念：

学着写作

别用Lorem Ipsum之类的占位符填充你的设计稿。作为一名设计师，你的工作不只是做出漂亮的图片——你得是个优秀的沟通者。思考整个体验，仔细斟酌每个词。东西是写给人看的。不要用校刊上那些让自己显得聪明的学术调调。
读 Made to Stick，我有史以来最喜欢的书之一。它会教你如何抓住你的读者。
Voice and Tone是个很不错的网站，里面都是如何与用户沟通的案例。

学会否定自己的作品

这是整个指南中最困难的一步
准备好否定每件自己的作品。准备好粗暴地毙掉你先前的宝贝设计。越快拥抱这一点，你的作品会越好。当你意识到自己的作品不够好，消灭它。再来一次。
要有另一双眼睛。拿着你的作品去找那些关心设计的人，获得反馈。一个也不认识？结交一些设计师朋友——参加设计师聚会和活动。
还有那些不关心设计的人。向一些潜在用户展示你的作品，请他们试用你的网站或者APP。别怕找陌生人——我有一回利用飞机延误，让航站楼里的每个人试用了我正在设计的app。他们中的很多人都正无聊着，很乐意帮忙，然后我得到了一些很棒的可用性反馈。
听。真正的聆听。不要去争论。如果你想从某人那里得到反馈，他们付出了时间与注意力来帮你的忙。不要用争论来报复他们的帮助。感谢他们并提问，而不是与之理论。以后再决定是否采纳他们的反馈。

第2步：学习使用Photoshop和Illustrator

万岁！现在你有相当牢固的基础了——视觉与用户体验。可以开始学习Photoshop了。实际上，我建议从Illustrator开始学，然后再转移至Photoshop。Illustrator是设计师用来制作LOGO与图标的工具。InDesign擅长制作印刷品设计，比如传单与名片。

学习Illustrator

可以通过大量的书籍、在线教程和当面课程学习Illustrator。选择最适合你的方式。下面这几本书对于学习Illustrator基础尤其有帮助：
Adobe Illustrator Classroom in a Book——它挺枯燥的，但如果你学习了至少一半，你的Illustrator将掌握得非常好。
Vector Basic Training——这本书教你如何在Illustrator里绘制美观的东西。
接下来是有趣的部分！关注在线教程，你能做的东西会让你印象深刻。其中我最喜欢这两个——一个 logo和一副风景画。

学习Photoshop

有成千上万的的教程。大部分都一文不值。还好有一些确实质量很高的教程网站。 TutsPlus的 PSDTuts就是其中之一。
这是一个很棒的制作iPhone应用的photoshop教程。
这是一个很棒的制作网站效果图的photoshop教程。
每天挤出一两个小时来学习这些教程，你的进步速度绝对令人难忘。

第3步：学一些专长

你是想设计移动app？网站？还是信息图表？多多探索，然后选择你最感兴趣的，让自己更加熟练。

学习Logo设计

学会做出还过得去的logo： Logo Design Love。
不过你还会希望在logo上更进一步。学习创作统一的品牌形象——从网站到名片。看看这本书， Designing Brand Identity。

学习移动app设计

从这个教程入手，开始你的移动app视觉设计历程。
读一读这本全面且深思熟虑的iPhone设计书： Tapworthy。它会教你如何设计出不仅美观而且易用的app。
认真研究你手机上的app。评价它们。哪些好用哪些不好用？

学习网页设计

阅读 Don’t Make Me Think来学习如何制作让人容易使用和浏览的网站。
如果你希望让网站看起来更棒，读一读 The Principles of Beautiful Web Design。
将你觉得漂亮的网页设计列一份清单。注意他们的共同点。 SiteInspire上有一些经典案例。

接下来要面对一个令人纠结的问题，作为一名设计师你是否需要掌握HTML/CSS：这取决于你的工作。掌握它肯定能让你在职场上拥有优势。即使你不想成为网页开发者，它也能帮你了解一些基础。你就能知道什么是可实现的，什么不行。

这里有些不错的HTML与CSS学习资源。

Web Design Tuts是免费教程中我的最爱。
我最爱的付费教程是 Treehouse（真的很实惠，每个月25美元）。如果你从零起步，需要有人给你清楚全面地解释，为Treehouse的教程大手笔支付吧。

第4步：创建作品集

你用不着去精英设计院校来成为一个设计师。但你需要一个可靠的作品集。

第一次着手时，要如何建立作品集呢？幸好你未必需要参与真正的项目、接触真正的客户来建立作品集。虚构一些自己的副业。这里有些点子：

在T恤上设计一些简单的创意。
寻找一些设计很糟糕的网站，重新设计它们。
想到一个iPhone app点子？做出它的效果图。
在 Startup Weekend上加入一个团队，在周末项目中担任设计师。
加入 99 designs contest来练习设计，作为一份简历。
通过 Creative Workshop这本书来做平面设计练习。
找到当地的非营利组织，免费提供设计服务。

要抵制住把每件作品放进作品集的诱惑。这是仅仅展示你最优秀作品的地方。

最开始就是借鉴，借鉴，再借鉴。不用担心原创性——以后会有的，当你对自己的手艺更满意时。学一门乐器的时候，你总是先学着演奏别人去曲子，然后才谱写自己的。在设计中也一样。像艺术家那样抄袭。

去 Dribbble从一些顶尖设计师那里寻找灵感。从 pttrns获取iOS设计灵感，从 siteinspire寻找网页的。

第5步：找到一份设计工作

当我第一次开始学习设计，我去了一个设计师招聘会。走进一间房间，里面坐满了经验比我丰富的设计师——5年、10年、15年工作经验。所有人都在找工作。情形很吓人。自学上路的我就在那里，很清楚地知道，自己是要与这些经验丰富的设计师竞争。

仅仅一年之后，我得到了一份设计师工作。与很多其他设计师相比，我的关键优势在于：我知道如何与开发者协作。

增进你就业能力的最重要因素，是能够和开发者一起工作。学习一些交互设计。学一些基础的HTML与CSS。科技行业的设计师（交互设计师、网页设计师、app设计师）都是稀缺人才，而且薪资可观。那正是我现在从事的工作。

如果你没有与开发者共同工作的经验，去体验。去 Startup Weekend，参加黑客马拉松，或者在合作项目网站找到一名开发者。

做一个个人网站，把你的作品集作为核心内容展示。

出去创造一些奇遇——告诉每个人你在寻找设计工作。你永远不会知道，谁会认识什么人能帮上忙。

研究你感兴趣的公司与机构。在LinkedIn上搜寻那些公司的人，与他们建立深入联系，询问信息。得到工作的最好方式是关系。如果你没什么人际关系，还有很多其他方式为自己建立优势。

找到了工作之后，继续学习

我在Exec待了一年，现在在工作上已经学了很多。我寻找那些比我有天赋的设计师，向他们学习。寻找设计课程（好的在线课程有 Skillshare、 General Assembly、 Treehouse和 TutsPlus）。做一些副业项目。在书店的设计专区认真钻研。还有那么多可以学习和进步的空间。

时刻打磨你的技能，而且学无止境。

有疑问？和@ karenxcheng打个招呼吧。如果你很认真的想学习设计，并希望每天练习，你或许会对我运营的一项激励实验感兴趣： 100。

“没有人告诉新手这些事情，我希望当时有人能告诉我。所有我们这些从事创意工作的人，选择它是因为我们有好的品味。但也有条鸿沟，你在头两年做出的东西，可能没那么好。你觉得它会更好的，它有潜力，结果却没有如你所愿。但是你的品味，你在设计领域中的成绩，仍然可能是罪魁祸首。你的品味导致你的作品让自己失望。很多人没有熬过这阶段，就放弃了。我认识的大多数从事有趣、有创意工作的人，花了很多年才度过这个阶段。我们知道，在自己的作品中，并没有我们所希望赋予的那些特质。这些我们都经历过。而如果你才刚入门，或是仍然处在这一阶段，你得知道这很正常，你能做的最重要的事情，就是创作大量的作品。这需要时间。需要时间也很正常。你得杀出一条自己的路。”——Ira Glass

作者注：本文最初发布在 Karen的博客。经过修订和校正后，发布到Medium上。

原文链接

随意看看吧
“理所当然”的设计	设计师的自我提升	隐形设计	设计师VS开发者	[国外设计第2期]
无觅

火云术语 – 专业术语翻译工具

Sat, 24 Aug 2013 13:09:51 CST

火云术语是款用于专业术语翻译的辅助工具，不同于普通翻译工具， 火云术语的专业术语库大多来自用户维护，目前已有 200+ 行业术语以及很多很多条术语。任何人都可以创建自己的术语库，并且与其他用户分享、收藏。同样适用于创建自己的私有翻译术语库工具。@Appinn

火云这个词总让我想到邪神…

火云术语提到的团队功能，@Scavin 表示木有发现在哪里。还有个 术语助手工具，可以利用术语库来进行文档的翻译工作。

术语库分享是 火云术语最有意义的功能，就如同维基百科分享全人类的知识一样。

http://term.iol8.com/

翻译：清除各个浏览器中的数据研究

Tue, 18 Sep 2012 23:06:53 CST

by zhangxinxu from http://www.zhangxinxu.com
本文地址： http://www.zhangxinxu.com/wordpress/?p=2630

原文地址： http://www.stevesouders.com/…/clearing-browser-data/
原文作者：没找到
翻译编辑：张鑫旭

——–最近较忙，直接进入正题以下为翻译全文——

对于快速Web APP，缓存四赢得性能的关键。最近个把月，我做了个所谓“清除浏览器实验”，研究下用户清除缓存的时候会发生哪些奇葩的事情。另外，除了浏览器的磁盘缓存（指图片啊等数据），我还折腾了其他一些数据格式，如：cookies, localStorage, 以及 application cache. indexedDB并不在其中，因为貌似其要嗝屁了。

实验的准备与操作(大致看看)

该测试从 Save Stuff这个页面开始。该页面做了4件事情：

设置了一个叫做”cachetest”的永久Cookie, JavaScript创建；
测试 window.localStorage以确定是否支持本地存储。如果支持，将会看到一个关键字为”cachetest”的本地存储值；
测试 window.applicationCache以确定是否支持应用程序缓存 – appcache(Application Cache – 可用来实现离线应用)。如果支持，会使用appcache加载一个 iframe. 该 iframe的manifest文件有个包含“iframe404.js iframe.js”的备份片段。因为 iframe404.js是不存在的，appcache会加载 iframe.js（定义了全局变量 iframejsNow）代替之。
加载一个需要5秒返回的图片，并缓存30天。

OK，现在数据已经保存到浏览器中了，然后用户根据系统提示清除浏览器数据，然后去检查缓存页面去查看之前保存的数据项还在不在。

查找名叫”cachetest”的Cookie;
检查关键字为”cachetest”本地存储数据；
再次加载iframe, 通过iframe的onload事件处理，检查 iframejsNow是否被定义，以确定appcache是否被清掉了；
加载同样那个要超过5秒的图片，如果这回图片加载的时间多于5秒，说明图片的缓存被干掉了。

我的测试结果

上图所示结果虽然不尽相同，但是跟我预想的很接近，然后其他一些知识碎片：

Chrome 21不清除localStorage. 这个异常结果可能归结于测试结果。 Chrome 21清除localStorage，但是并不在当前选项卡的内存中清除。如果你切换选项卡或者是重启Chrome浏览器，则被清掉了，是从内存中也清掉了。这实际上是一个bug, Chrome 23.0.1259以及后续版本修正了这个问题。
Firefox 3.6不清楚磁盘缓存，该问题的出现似乎与Chrome 21约好的：图片已经从磁盘缓存中清掉，但是，内存缓存中还在。按理说，两者都应该被清除掉的，2010的时候，FireFox团队修复了这个 bug.
IE 6-7不支持appcache以及localStorage.
IE 8-9不支持appcache
Firefox 3.6, IE 8-9, and Safari 5.0.5不清除localStorage, 我猜想，出现这个问题的原因是浏览器没有连接这些本地存储的界面。可参考下面展示的浏览器界面。

浏览器的交互界面们

在查看广泛数据下的结果前，有必要先看看各个浏览器清除数据的界面是怎样的，包含哪些清除的选项。下面截图来自Mac或window, 因此，可能和你自己看到的是有一些差异的。

Chrome
点击扳手图标 → 历史 → 清除所有浏览数据…Chrome 21浏览器下如下显示。复选”Empty the cache”（“清空缓存”）清除磁盘缓存，”Delete cookies and other site and plug-in data”（“删cookie以及其他站点和插件数据”）清除cookies, localStorage, 及appcache.

Firefox
清除Firefox 3.6点击工具 → 清除最近历史…然后复选Cookie和Cache. 没有清除localStorage的复选框。

FireFox12通过新增离线站点数据(Offline Website Data)这个复选项修复了这个问题。Firefox 15 有同样选择。结果localStorage被成功清掉了！

Internet Explorer
IE6下可能要折腾点。点击工具 → internet选项… → 两个按钮：删除Cookie…(Delete Cookies…)和删除文件…(Delete Files…). 两个按钮都需要确认是否选择并删除。这里有个“删除所有离线内容”(“Delete all offline content”)选项，但因为appcache和localStorage不支持，对于本实验而言纯属打酱油的。

清除IE7则点击工具 → 删除浏览历史…仍然是两个分离的按钮，删除文件(deleting files)和删除cookie(deleting cookies), 同样有个“删除所有…”按钮，可以一键搞定everything~~

IE8的UI通过工具 → Internet选项 → 常规 → 删除…访问，相比IE7其多了个复选框“私人筛选数据”(“InPrivate Filtering data”)（其还有“保留收藏网站数据(Preserve Favorites website data)”项，这个在以后的文章我会讨论的）, IE8已经支持localStorage, 不过看样子是清不掉的，因为没有提供相关的复选框，就像FireFox12中清除离线数据一样。

IE9的界面又变了，添加了“下载历史”(“Download History”), “私人筛选数据”(“InPrivate Filtering data”)被“ActiveX筛选以及跟踪保护数据”(“ActiveX Filtering and Tracking Protection data”)替换了。类似IE8, localStorage在IE9中是支持的，但是，貌似不能被清除（木有清除的复选框框）~~

iphone
iPhone（果不其然）有这最简单的清除数据的界面。通过设置 → safari浏览器，我们可以看到一个单按钮：“清除Cookie和数据(Clear Cookies and Data)”。结果显示，这个可以清除掉cookies, localStorage, appcache, 一级磁盘缓存。在iPhone上很难运行我的测试，因为你要离开浏览器去进行设置，当你回到浏览器的时候，这个页面已经被清除了。为解决这个问题，我在下一个页面键入下面地址进行测试： http://stevesouders.com/tests/clearbrowser/check.php

Opera
Opera的删除选项最细化。Opera 12中，访问工具 → 删除私有数据…就会出现一个对话框。关键的复选框是“删除所有Cookie(Delete all cookies)”， “删除全部缓存(Delete entire cache)”，以及“删除长期存储(Delete persistent storage)”。有很多选择，但都在一个对话框中。

Safari
Safari 5.0.5下，进入齿轮图标→重设Safari…(windows下)，然后，会出现一个有很多选项的对话框，没有“离线数据(offline data)”很明确地表明时无法删除localStorage的。（“清除历史(Clear history)”是没有效果的——当时我只是想看看是否可以把localStorage删掉的）。

Safari 5.1.7让我有些疑惑。一开始，我选择了Safari → 清空缓存(Empty cache)…（在Mac上），但只影响了磁盘缓存。而后我看到了 Safari → 重设Safari(Reset Safari)… ，但是只有“清除所有网站数据(Remove all website data)”，这个看上去太含糊太宽泛了。再后来，我搜索寻找更多清除选项，然后发现了Safari → 首选项… → 隐私，有一个按钮“清除所有网站数据(Remove all website data)”，这……也太不细分了吧~这个按钮可以成功清除Cookies，本地存储，appcache和磁盘高速缓存。

大测试数据下（众包形式）的结果

下面的结果产生大致这样：作者折腾了一个测试页面，放出来，然后N多同行或莫名被忽悠进来的人点击几个帮助其完成了测试，然后这N多人的测试结果就是下面所要展示的结果。类似于外包中的众包。作者自己无需傻不拉几的一个一个浏览器去测。

下面的测试结果包含~100个浏览器(webOS, Blackberry, 及RockMelt)，我摘录中相同主浏览器下的一些结果（点击下图可查看更详细的表格结果）。

//zxx: 下面几段就是原作者的一些颠来倒去的“废话”了，我就翻译个大致意思……

本实验没杀刻骨铭心，发人深省的提示，因此，数据还算是蛮客观滴。

我个人测试结果和大家的测试结果不同的是iPhone, 估计原因是iPhone清除数据要离开浏览器……然后，什么什么的~~

不同浏览器清除数据的界面的复杂度和缺乏一致性可能导致了这些不太一致的结果，Chrome浏览器21和Firefox 15都有相当数量的测试（154，46），但是，挑落Boss的只有50％或68％。FireFox可能是特例，因为其本地数据存储之前会先询问用户；然后还有Chrome等浏览器有隐私浏览模式~~等

大家测试结果的不同可能与不同浏览器界面不一致有关。应该有跨浏览器的更一致的交互界面。一致的交互界面应该长什么样子呢？像iPhone那样直接一键解决，早死早超生吗？这真的是用户需要的吗？我有时候就想清除磁盘高速缓存，而不想删除Cookie~~ 不过嘛，现在希望所有浏览器都能按照用户所想删除数据是不可能的！

——–以上为翻译全文，虽然不是什么深奥的东西，对于知识拓展还是有一定的帮助的——

原创文章，转载请注明来自张鑫旭-鑫空间-鑫生活[ http://www.zhangxinxu.com]
本文地址： http://www.zhangxinxu.com/wordpress/?p=2630

（本篇完）

有话要说，点击这里发表评论。

翻译：关于完美圆角实现的研究

Sat, 05 Jan 2013 21:40:02 CST

by zhangxinxu from http://www.zhangxinxu.com
本文地址： http://www.zhangxinxu.com/wordpress/?p=2904

原文链接： In search of the perfect radius
原文作者：没找到
翻译编辑：张鑫旭

//zxx: 以下为翻译全文————–
数周前，我碰巧读到 Chris Coyer一篇关于边框半径嵌套的文章，这触发了我之前一直想做相关研究的蠢蠢欲动的心。

下图中，那个按钮比较正点？你是否曾经有意或无意要设计这样一个按钮，一个圆角矩形嵌套在另外一个圆角矩形中，然后你不知道应该怎么根据给定的外部半径设置内部半径大小，或者反过来根据内部半径大小设置外部大小？这就是我们接下来要探讨的。

创建圆角矩形的四种方式

假设，你需要需要去创建一个内陷的按钮，你可以这样，

使用看上去靠谱的半径
内外圆角矩形使用相同的半径
复制外面的矩形并自由变换创建它
设置内径大小为外径大小再减去边框宽度

选择哪种方式

因为轻信我们的眼睛，我们不会指望选项1。从上图看来，显然选项2没什么效果。选项3和选项4看上去算是那么回事，我来在他们之中选择一个合适的~

对于外矩形，我选择宽度1，外半径3，边框宽度6，并在PhotoShop图层中花了18个矩形。
对于内矩形，两种处理，一是复制外矩形进行自由变换（选项3）；二是内描边大小相等的边框宽度（选项4）。
坐等结果

就是你了，选项4

上面结果清楚地表明，选项4对于所有边框宽度（从1像素到24像素）都表现不错。从Photoshop判断看，也是该结果。因此，公式很简单： 内半径=外半径-边框宽度。

研究继续

研究byebye了？恩，一部分吧，不是全部。你有没有注意到这种情况，当边框宽度大于等于外半径时候，内半径就是0，且按钮就是个简单的尖锐的方形？这好看吗？可以改善吗？如果有略微圆润的边角，岂不是会更好看？

进入下一阶段的学习。在机械工程中，这个圆形部分被称作为“圆角( fillet)”，通过机器操作生成这个圆角曲线称之为“角隅填密法( filleting)”（我有机械工程的学士学位:)）。在我们这个例子中，角隅填密法会不会让设计更好呢？如果是这样的话，我们应该如何计算应该的圆角半径呢？

边角填充提高设计

为了确认filleting可以提高设计，我选择了下面这些方形的情况，并切出了2, 4, 6以及8像素的圆角半径。下面这个表显示了结果。您可以发现，通过特定大小的圆角半径填塞，设计确实好看些了。

我想看看，是否半径在小尺寸有用，大尺寸也有用。所以，我就增加了一倍和四倍按钮，结果罗列入表。最好看的圆角半径貌似随着按钮大小而增加。

圆角半径的公式是什么

我试图去需找是否有确定最佳圆角半径的公式。这有可能吗？答案是Yes, 如果你给我2刀，我将来给你4刀，你给我6刀我还你12刀，给我25刀我给你50刀，那你可以轻易知道公式。从数学上讲，你可以通过将数据(2-4, 6-12, 25-50)绘制成在图表上的点，然后找到连接这些数据点的直线或曲线的公式，这个过程被称为曲线拟合。

该选择哪些数据对呢？其中一个是圆角半径；圆角半径在我看来是最好的（这不科学，我知道，但是那不属于我们现在的范围）。那另外一个呢？看上去像外半径，但谁知道呢，甚至边框宽度都能扮演一个角色。所以我绘制了两个图表，一个是找出（最佳）内半径是如何随着外半径变化的，另外一个是找出内半径是如何随着边框半径变化的。下面就是图表。注意：如果你通过选择最佳圆角半径重复该实验，结果可能不一样，因为在某些情况下，并不清楚哪个圆角半径是最佳的，因此，您就会选择相邻的圆角半径。

内半径的增加似乎既跟外半径又跟边框宽度同步，但不是很流畅。据我所知，只有当曲线遵循模式的时候，曲线拟合可以产生有意义的公式。该模式既可以是一条直线，抛物线，正弦波等。但是，我怀疑它是否有规律，绘制的曲线实在是太锯齿状了。

我基于自己生锈的数学知识做了整个实验。我可能错过了一些东西，或者我绘制的点不是足够的多，如果谁更加见多识广做了这个实验，绘制了更多的点，我很乐意看到结果。到目前为止，毕竟我们必须依靠我们的眼睛找到最好的圆角半径。我不入地狱谁入地狱。圆角半径公式正在躲猫猫。

总结

下次你想创建内嵌圆角矩形，遵循下面要求会有最佳结果：

内半径=外半径-边框宽度
如果内半径为0，圆角之。通过目测找到最好的圆角半径（基本上，外半径小于100像素，最佳圆角半径是1-15像素中任意位置）

//zxx: 以上为翻译全文————–

译者结语

上面内容是不是有不知所云的感觉，确实，但这也是理所当然的。一些拓荒者，希望身体力行尝试些新的东西，这些东西的成果往往都是纯粹的实验结果，或者总结的可能并不准确的理论。对于实用主义者而言，这些似乎是很枯燥的。

还有一类人属于实践者，他们总敏锐捕捉到一些新颖的理论或实验结果，然后尝试性地应用在实践中。可能这些实践并不完美，也有可能成为了该方法的创造者。

还有一类人属于求知者，时刻关注新技术的发展与脉动，于是他们成为了一些新方法飞推广者。

还有一类人属于跟风者，这个技术大牛或某大网站使用了，于是，不假思索地，葫芦画瓢地也应用上了，于是，成就了所谓的流行技术。

本文译文内容，可能原本是针对网页设计师而言，如何在Photoshop中把握内外圆角的大小，以实现最佳的内外圆角矩形嵌套效果。但是理论这东西往往是相通的，于是，我们在实现网页一些UI效果的时候，也可以应用文章所述的结论，例如：

1. 内半径=外半径-边框宽度
如下测试代码(内borderRadius = 外borderRadius – padding值 → 10=30-20)：

.radius1{width:200px; padding:20px; background:#a0b3d6; border-radius:30px;}
.radius1_in{height:200px; background:#fff; border-radius:10px; }

<div class="radius1"><div class="radius1_in"></div></div>

效果如下（现代浏览器，如果您看不到效果，可能是在RSS或是其他网站查看，原文地址： http://www.zhangxinxu.com/wordpress/?p=2904）：

1. 内半径<0 ，边框40宽度像素对照上面的图表，估计4像素内半径
如下测试代码：

.radius2{width:160px; border-radius:30px; border:40px solid #a0b3d6; background:#a0b3d6;}
.radius2_in{height:160px; background:#fff; border-radius:4px;}

<div class="radius2"><div class="radius2_in"></div></div>

于是，就有了最佳内外圆角大小。

原创文章，转载请注明来自张鑫旭-鑫空间-鑫生活[ http://www.zhangxinxu.com]
本文地址： http://www.zhangxinxu.com/wordpress/?p=2904

（本篇完）

有话要说，点击这里发表评论。

【CDC翻客】移动用户体验要素（下篇）

Tue, 19 Feb 2013 12:00:32 CST

　　译者注：对于移动用户体验的从业人员，本文可以说是一部宝典。文章不仅提纲挈领地概要了移动用户体验的12大要素及其规范，更提供了详实而丰富的参考文献。Queen的上篇介绍了 功能、信息框架、内容、设计、用户输入，下篇将介绍 移动情景、可用性、信任感、反馈、帮助、社交、营销。相信对大家肯定有帮助的。

　　英文原文: The Elements Of The Mobile User Experience

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

上篇链接 :【CDC翻客】移动用户体验要素（上篇）

｛移动情景｝

　　我们可以在任何时间、任何地点使用移动设备，因此，移动情景指的是用户使用时的环境和状态——也就是任何可以影响用户与设备进行交互的内容。由于这些情境持续而快速地变化，对移动设备而言就显得尤为重要。我们在考虑用户分心、多任务、手势操作、低电量条件和糟糕的连接环境的同时，也要考虑极端好的情景——假设在一个快速Wi-Fi环境下使用平板电脑。

《移动交互的情景》（参见： The Context of Mobile Interaction ） ,Nadav Savio

规范

1. 根据设备功能和硬件能力来预测和支持用户的使用情景。iCookbook应用中，用户可以用语音来查看食谱——就再也不用担心手上糊满面糊怎么办了。

2. 根据一天不同的时段或用户使用过程，来适应情景的变化。Navfree GPS应用能在白天、夜间模式下自动切换，夜间采用低眩光的地图，开车会更安全。

3. 判断用户当前位置并展示附近相关的内容和帮助。用户在移动设备上用Google搜索电影，可以搜到附近正在热映的电影以及当天的电影场次，如果有票的话，还能看到买票的链接。

4. 权衡用户提供的信息，并且尊重用户的喜好和设置。在完成多线航班的第一站后，TripIt应用向我展示了下一个航班、登机信息以及必须要花费的时间。而United应用并没有做这样的事情，尽管它知道得更多。我就纳闷了，既然知道我是会员，它为什么不向我展示如何从当前飞机前往下一班飞机，另外明确标明途中United的贵宾休息区，好让我舒适地度过这等待的两小时呢？

5. 默认为用户提供最合适的体验（例如：一种适合小屏幕的移动体验，也可能是适合平板电脑的桌面产品体验），但还要提供高级选项。最近一次关于如何向用户展示这些信息的大型的讨论会上， Jakob Nielsen 建议将移动网页与 Web 网页分开（参见 Jakob Nielsen recommending a separate mobile website）， Josh Clark 则觉得自适应的移动网页设计更好（链接： Josh Clark arguing instead for a responsive design）， 而其他人认为 Nielsen 和 Clark 都错了（参见 believe that Nielsen and Clark are both wrong）。

拓展阅读

1. “ The Context of Mobile Interaction” (0.2 MB, PDF), Nadav Savio, Jared Braiterman

2. “ On Mobile Context,” Jason Grigsby

3. “ When and Where Are People Using Mobile Devices?,” Luke Wroblewski

｛可用性｝

　　可用性指的是全面衡量信息架构、设计、内容和其他元素是否让用户很好地完成任务的标准。

规范

1. 让用户清晰地知道什么是可选的、什么是可点击的或可滑动的，尤其是在触摸屏设备上。 尼尔森诺曼团队在 iPad 的可用性调研（参见 Nielsen Norman Group’s usability studies of the iPad）中发现，用户通常不知道什么是可点击的，有时也被滑动这个手势搞得迷糊，尤其同一个滑动手势在同一界面的不同区域滑动却有不同的功能。所以，请确保可点击的内容是清晰的，比如链接、icon和按钮，要一看上去就是可点的。

2. 在触摸屏上，确保点击对象的尺寸和位置以避免误操作。另外，将点击对象放在合适的区域，比如：把“删除”等具有破坏性的功能对象放在下图所示的“Reach”区域，Luke Wroblewski在 《移动为先》（ Mobile First）中提及。

Luke Wroblewski , 《移动为先》

3. 遵守规范和模式来减少用户的学习成本，也能让移动体验更加自然。App的设计应该遵守特定平台规范标准和指南。在Breaking the Mobile Web网站中，《 移动设备和平板电脑的网页应用设计指南》一文的作者综合收集了很多来自官方的UI和UX指南链接（参见 UI Guidelines for Mobile and Tablet Web App Design）。

4. 通过设计元素比如对比度、颜色、排版和字体大小，确保产品在情景变化下的可用性，变化的情景包括白天刺眼的阳光下，以及改变设备的物理角度和朝向时。

5. 不要依赖那些不被移动设备广泛支持的的技术，比如Java、JavaScript, cookies, Flash, frames, 弹出框和自动刷新。当需要打开一个新窗口，或者从应用跳转到网页上时，要提醒用户避免重新加载已打开的页面。

拓展阅读

1. “ Usability of iPad Apps and Websites,” Nielsen Norman Group

2. “ UI Guidelines for Mobile and Tablet Web App Design,” Max Firtman

3. “ Mobile Usability Update,” Jakob Nielsen, Alertbox

｛信任感｝

　　这里讨论的是当用户使用移动网站或App的自信心、信任感以及舒适度的问题。根据 Truste和Harris Interactive两家公司在2011年的研究，隐私和安全是智能手机用户最关心的两个问题。

规范

1. 在未经用户明确许可下，不要使用移动设备里的个人信息（比如地理位置和通讯录）。今年的头几个月中，已经有不少关于从手机中私自复制通讯录的报告，文章 watchdogs up in arms 和 users retaliating中有所提及。

2. 让用户轻松掌控App如何分享个人信息，比如访问位置前询问用户，允许他们退出目标广告。

3. 在合适的情况下，清楚地阐述你们公司的商业行为（包括隐私、安全和投资回报）（比如在注册页面告知隐私和安全条款）。这些条款应作为次要元素出现（比如可以放在底部栏或是“more”标签里）。通过显示受信任的标记来加强用户的信任感，尤其当用户需要提供个人或财务信息时。

4. 在移动设备上适当地为用户提供条款，包括简洁的概述和是否发送到邮箱的选项。众所周知，隐私和安全条款通常冗长而无趣，用户往往都会盲目地点击同意继续下去，因此我们要尽量让这个过程容易一些。

5. 当提供条款的时候，不要打断用户的任务流程。在被打断之前， 让用户返回到之前的位置（参见： Take them back to where they were），而不是重新开始。

拓展阅读

1. “ Layered Policy Design“, TRUSTe Blog

｛反馈｝

　　这指的是如何吸引用户的注意力以及如何展示重要信息。

规范

1. 将提醒次数降低到最少，确保每一次的提醒都提供了重要的信息和有用的选项。可以去看看Chris Crutchfield的文章 视频上过多的信息和提示（参见： video on notification and alert overload）。

2. 确保提醒简短而清晰，解释为什么会有这样的提示，用户可以做什么。另外，按钮标记要清晰。

3. 消息提示应该简短而带有告知性，不要干扰用户的操作，并且很容易操作和离开。

4. 在界面上提供的反馈和确认信息不要打扰用户的操作流程。

5. 如果这个App有消息标记或是在状态栏上有提醒，就要保持这个标记和消息的更新。当用户添加新消息时要清除这个标记。当用户访问到消息标记时提醒要被清除，即使用户还没有发现究竟是哪个账号触发了消息提醒，这也会迫使用户一个个账号去试探。

拓展阅读

1. “ Mobile Notifications,” Fred Wilson

2. “ The Future of Mobile Notifications,” True Ventures

3. “ Chapter 8: Feedback and Affordance,” Theresa Neil

｛帮助｝

　　这指的是能帮助用户使用网页或者应用的相关选项、产品和服务。

规范

1. 让用户能轻松进入帮助和支持选项。用户通常会在移动网页的底部和应用的工具栏，或tab栏寻找帮助选项。

2. 帮助的形式要多样化，尽量与移动应用场景相关，比如自助服务式的常见问题，现场帮助式的点击通话，接近实时的直接消息推送。美国运通（American Express）和花旗银行（Citibank）这两家金融服务公司都积极地通过Twitter提供支持。

3. 在用户首次进入应用的时候，提供快速的介绍和简短的教程，但也要提供跳过和稍后查看的选项。

4. 当首次引入新的或者特别的功能时（比如首次介绍如何使用移动应用检查支票），需要提供给用户情景化的帮助和提示，这也是对不经常使用的功能的回顾。

5. 在合适的情况下，提供视频指导，但是要允许用户可以按自己意愿开始、暂停、停止和控制音量，并记住上文 “ 内容 ”中提到的多媒体相关的规范。

拓展阅读

1. “ Chapter 7: Invitations” and “Chapter 9: Help,” Theresa Neil
Chapter 7 is available online at UX Booth.

2. “ Top 6 Help Design Patterns for iPhone Apps,” Catriona Cornett, inspireUX

｛社交｝

　　这指的是有社交元素的内容和功能，从而让用户在已有的社交网络上进行分享和交互。

规范

1. 创建和维护社交网络（如Facebook）和本地服务（如综合的服务页面，像谷歌地图、Bing商业门户和雅虎本地）。在搜索结果和基于位置的社交网络服务中重点突出它们，除了你的商业名称，也包括了你的家庭住址、电话号码、URL和营业时间。

2. 将社交活动和移动体验进行融合：如在网上展示最新活动，提供简单的方式关注或喜欢。

3. 将社交网络的特性与网站的移动体验进行融合，用户可快速连上社交网，这就像使用APIs（ using APIs）支持社区分享、书签、加标签、喜欢和评论一样简单。

4. 邀请用户使用移动设备创建能展示你品牌、产品和服务的内容，并提供一些激励作为回报。例如，汉堡连锁店红罗宾向用户发起邀请：只要分享一张孩子在店里读书的照片，就能获取一杯免费的奶昔。

5.让移动端的内容可以被分享和病毒式的传播。比如，美国运通公司（American Express）最近提供的信用卡的储蓄和折扣优惠，只要你将个人信息同步到Facebook、Twitter和Foursquare上，就可获得。

6. 那些依靠用户创建内容的App，应该要探索出一套让初始内容有用并最终能进行不断维护的方法。比如：My TSA应用有一个用户创建内容的功能，展示了安检站等待的时间，但是它常常显示一些过时的消息，尽管机场工作人员已经将等待时间贴了出来。

拓展阅读

1. “ The Definitive Guide to Adding Social Features to Your Mobile Apps“, Verious

｛营销｝

　　这指的是如何让用户发现一个网站和应用的途径以及鼓励反复使用的因素。

规范

1. 通过优化移动端搜索和发现来确保产品的可寻性，比如保持URL简短。如果你有一个独立的移动网站，请遵循URL命名约定(m.site.com或mobile.site.com)。在移动搜索结果里，提供快速访问本地的内容的入口（如当前位置的方向）以及系统自带功能（比如点击快速拨号）。

左边是移动端对UPS搜索结果优化后的网页，右侧是没有优化的

2. 二维码的出现让移动设备的登录得到很大的优化，我们不需要到传统的那种需要放大才看得清楚的页面上，更加不需要到网站首页上寻找登录入口。另外， 附在产品上的二维码（参见 QR codes painted on buildings）应该清晰明确，这样移动设备才能辨识和解读。

3. 给用户发送的邮件应当以移动设备支持的格式，内容应该包含一条可以查看产品相关信息的链接——而不要回到设备自身的网站首页上去。

4. 可能情况下，在其他平台上（如电视、纸媒、店内广告）推销你的App，并且激励用户下载使用，通常可采取打折的办法。如果你的App有价格标签，那么可以在过度拥挤的市场中通过限时促销来吸引用户。另外你还可以通过每日限免市场来吸引用户。

5. 提示使用过你App的用户进行评价打分，或是分享到社交平台，但是要给延迟或停止提示的选项。虽然这不是唯一产生口碑的途径，但能让你洞察到用户喜欢什么不喜欢什么。Smalltech在 控制你的评论（参见 Taking Control of Your Reviews）一文中讨论了如何让用得爽的用户进行评价，以及让不爽的用户用邮件反馈意见的策略。

拓展阅读

1. “ iPad App Marketing Case Study: Flickpad,” Chad Podoski, Mobile Orchard

2. “ The Art of Launching an App: A Case Study,” John Casey, Smashing Magazine

3. “ How to Market Your Mobile Application,” Michael Flarup, Smashing Magazine

｛总结｝

　　移动用户体验是一个正在蓬勃发展的领域，也不断涌现更多可完善的契机。本文作者已经概述了移动用户体验的要素以及每个要素的规范，这些内容必将帮助我们创建更好的移动用户体验。

了解“CDC翻客”，请移步：【CDC翻客】翻客来袭！Fanke is coming！(链接： http://cdc.tencent.com/?p=6518)

(本文出自腾讯CDC博客: http://cdc.tencent.com/?p=6986)

为什么说48帧率是电影的未来

Sun, 24 Feb 2013 10:24:06 CST

【翻译/校对：赵翔宇】

译者注：此文是《霍比特人》在美国上映不久时，外媒对48帧率(HFR、高帧率)的一篇强大讨论，翻译出来跟大家一起交流。文章从电影技术、神经学原理等多方面，深入讨论了HFR现在面临的问题，以及争论产生的原因，更讨论了我们能否适应以及是否应该去适应HFR等等。作为48帧率的拥趸，希望这6500字能让更多影迷选择支持这项技术的革新，不要让它像70年代那次一样，前功尽弃。翻译有删改，下面是正文：

作为影迷，你大概看过不少电影。据我们的统计，你们多数人已经看过《霍比特人》了，而且看到的是每秒48帧的《霍比特人》。几乎你们所有人都会觉得这种高帧率看起来有些奇怪，至少开始的时候会有这种感觉。然而，《霍比特人》导演彼得•杰克逊宣称48fps会是电影制作的未来。评论家们对此深表怀疑，说那是“华而不实的高清画面”、“不仅直白单调，过于真实也是不可饶恕的”。

杰克逊对48fps（又称高帧率，High Frame Rate，HFR）的推进，已经引发了一场出乎意料的热议，而作为热议主体的48fps原本看起来是相对简单的技术革新。尽管我第一次看《霍比特人》时感觉有些奇怪，但是我仍是48fps的信徒。在本文中，我会分析关于48fps的争论、反对声音背后的神经学因素以及如何才能使高帧率得到广泛的认可。

【最离谱的事】

开始前，我推荐各位听一下这段来自 Radiolab的《音乐语言》（Musical Language）节目片段，这个节目片段主要讨论了对伊戈尔•斯特拉文斯基（Igor Stravinsky，美籍俄罗斯作曲家）的《春之祭》（The Rite of Spring）音频的测试结果（译者注：音乐略，见下段描述，不耽误理解）。

《春之祭》剧照

简单回顾：1913年5月，伊戈尔在巴黎首映了芭蕾舞剧《春之祭》。伊戈尔的作曲听起来与观众熟知的瓦格纳（德国歌剧家，作曲家）那种传统优美的音乐不同。尤其是，他用了一种刺耳的弦音，整个过程中一遍又一遍使用。观众很是反感。他们变得烦躁不安，开始叫嚷、厮打，最后演变成一次暴乱。这场暴乱肯定不仅仅是因为人群中那种不满的情绪。一定还有其他原因。

神经学家乔纳•莱勒解释说：“成群的神经细胞中，每个神经元的作用是转变那个刺耳的声音，分析它，分离它，并且试着去理解它。Radiolab表示，在《春之祭》那刺耳的声音一遍遍到来时，那些神经细胞无法搞清楚它们听到的是什么意思。识别失败后，导致了大脑化学过程（尤其是多巴胺层）的改变，进而使那些观众临时变得有点儿疯狂。

然而，在1914年4月，《春之祭》第二次公演时，观众陆陆续续地来观看并且喜欢上它，当然肯定有一部分人是来看看是怎样的音乐导致了那场暴乱的。他们报以热烈的欢迎。《春之祭》成为了古典音乐的一部分，仅仅20年后，它便已成功地出现在了迪斯尼儿童电影《幻想曲》中。莱勒称之为“证明大脑惊人的可塑性的最好证据”。

我们的大脑对新的信息是一直开放着的。开始的时候，会难以接受，我们讨厌它。之后，我们慢慢知道了来龙去脉，接受了新的信息，并且学习去评价它。我相信48帧率能遵循同样的路线，从争论变成理所当然的革新。但是下面的讨论也是必要的。

【为何要增加帧率？】

电影通过拍摄、投影单张静态的画面模拟动态运动。早期无声电影大多是16至24帧率的，之后随着有声电影的出现，电影的帧率标准被定为24帧。电影制作者们想要更高的帧率，这样可以更好的捕捉动作、获取合适的音质。可是电影采购者们却支持低帧率，因为高帧率意味着需要更多的胶片，胶片是昂贵的。最终的结果是折中的24帧，这一帧率对于上个世纪来说足够了，但是未必是最理想的。见鬼的是，据说电影先驱托马斯•爱迪生亲自推荐46帧率，因为少于这一帧率会使眼睛疲劳。

道格拉斯•特鲁姆布（Douglas Trumbull）在70年代末开始研发“ 休斯坎”技术（Showscan，采用60帧率的高品质画面冲印技术），这种技术被用在主题公园里（迪斯尼乐园的星际之旅、香港的环球影城主题乐园都使用60fps），但是一直没在电影院里流行起来。詹姆斯•卡梅隆早在2008年就开始宣扬高帧率的好处：

“经过了75年的2D电影制作技术，我们已经习惯了24帧率带来了频闪效果。同样的东西，我们在3D状态下看，这种频闪的效果就会更明显，不是因为它本质上更糟糕了，而是因为所有其它的地方都变得更好了。（3D技术使）画面突然看起来如此的真实，好像你就跟角色站在同一间屋子里一样，但是当摇动镜头时，会有一种奇怪的虚影。可能你以前从没发现过，事实上它一直被隐藏在最显眼的位置。一些人管它叫做抖动，也有人管它叫频闪。我把它叫做“烦人的东西”。它也很好解决，因为数字电影可以实现立体再生，而且它也提供了解决频闪问题的方法。”

卡梅隆很是沮丧，因为即使是《阿凡达》之前，我们技术上也是有这个能力来改为48fps的：
“如果需要，提高放映机和服务器的计算能力不是什么难事儿。我已经测试了立体48fps，效果很棒。摄像机可以实现，放映机（做轻微的调整）也可以实现。所以作为一个产业，我们为什么不去做呢？”

卡梅隆已经表达过他想用48fps来拍摄《阿凡达》系列的意向。于此同时，稀有的技术控电影创作者之一，在电影工业中有跟卡梅隆几乎相同大的能力的彼得•杰克逊，带头开始了这场48fps的战役。如下是杰克逊在2011年4月拍摄《霍比特人》期间，发表在他 facebook上的一段宣扬高帧率的内容：
“成品看起来是正常的速度，但是画面的清晰度和流畅度大幅提高了。看24帧率的也许没啥问题，而且在过去90年中，我们已经看过了数以千计的像这样的电影。但是（当主体）快速移动时，画面经常有模糊，而且如果是摄影机快速移动时，画面会有抖动和频闪。用48fps拍摄及放映可以很大程度上解决这些问题。48帧率看起来更逼真，更容易观看，尤其在3D的情况下。这几个月里，我们已经观看了《霍比特人》的测试片段及样片，并且我们经常连看两个小时也没有普通3D带来的眼睛的疲劳。”

所以高帧率听起来倒像是基本的自然的技术发展。那问题出在哪呢？我们大抵可以把批评的声音分成两类：1.看起来像廉价视频。2.看起来太真实。

【肥皂剧效果】

“感觉就像在看日间肥皂剧，糟糕的BBC广播，或者是《神话剧场》（约1985年的剧集），只不过非常清晰然后再加上些霍比特人。”——-Jen Yamato, Movieline。

除了帧率问题，我们也必须要考虑到闪烁率或者是刷新率。当放映电影时，放映机每关闭一次快门（“闪烁”），换上一个新的一帧。所以24帧率的放映机需要每秒至少闪烁24次（Hz）。现在多数的放映机已经是在48hz下播放24fps的影片，意味着对于每一个新的帧，快门要打开关闭两次。一些放映机甚至已经支持72hz（每帧3下快门）或者更高。这已经超过了一个观看者确认光是稳定的的临界闪光融合率（CFF）。（比如一个60Hz的灯泡。灯泡并不是一直都有光，而是不停地闪烁着，只是60Hz已经足够使人眼分辨不出它在闪烁了）。

刷新率也已经是一台电视的销售点。基本标准是60Hz，每秒刷新60次，但是更新的电视已经达到120hz、240hz，甚至已经达到480hz。通常视频是隔行显示的，即把每一帧的画面拆分开，分别填充到画面的奇偶行中。所以一个60hz的电视会以30fps的频率来显示隔行扫描的视频，每行每秒刷新30次。这种方法使用了全部60次刷新，但是可怕的“肥皂剧效果”用的是更高的刷新率。

由2个临近帧计算得到中间插入帧

拥有120hz或者更高刷新率的电视，有一个“插入帧”的功能设置。这个功能不是简单的重复一个相同的帧，而是通过计算相邻的两个帧的平均明暗和颜色，得到一个新的帧，把这个新帧插入到两个原来的相邻帧中间。对于那些意识到这种效果的人，会觉得看起来不自然，因为它本来就是人造的。计算机算法会估算实拍情况下的中间帧，然后给这个多少会有失真的中间帧添加信息。尤其是摄像机快速移动时，两个连续帧的差别较大，计算后插入的帧也就会不太精确。

肥皂剧是以30fps的帧率拍摄的隔行扫描视频，会有廉价视频的感觉，不过它也多少在努力营造一种电影的感觉。插入帧人工地提高了帧率，来改善这种肥皂剧般的廉价视频（之类的画面）。

可是采用48fps拍摄是完全不同的。48fps没有廉价或是虚假之感，它是通过实际拍摄时，记录两倍的视频信息来达到插入帧的目的的。高帧率是完全真实的生活，或者说是比24fps更真实的生活。

【太真实】

“它让一个画面看起来如此的清晰以至于看起来不再真实。或者如此的真实以至于让你出戏。好像……你就在片场” -Mike Ryan, Huffington Post

其它主要对48fps的抱怨是，它的画面展示了太多的细节，看起来太真实。高帧率在两个帧之间增加了视频信息，所以我们在每个画面上看到了非常多的细节。但是由于高帧率减少了动态模糊，每一帧都那么逼真，它制造出了如此清晰透彻的电影画面，以至于有人说，它已经把电影屏幕转换成了一扇窗户。虽然一些尖锐的批评者也都承认：“ 这个（高帧率）对动画、体育和自然摄影是有用的”。但是这看起来与《霍比特人》追求的沉浸感不对路，或者说争论还是存在。

超精细的画面

这就带出了一个问题，一个虚幻的电影应该是什么样子的，以及通常所说的“看起来像电影”到底是什么意思。《霍比特人》不是48fps理想的测试用例，它是一个虚幻的电影没有错，但它是在一个“非常熟悉的”虚幻世界里拍摄的。我们之前都在《指环王》上花了很多时间，所以已经熟知了杰克逊的中土世界。但是《指环王》是35毫米、2D、24fps的胶片电影。一下子都换成数字的、3D、48fps，确实会显得有些突然。如此巨大的变化是难以被接受的，于是当大多数评论者说故事不好的时候，这个高帧率技术很容易会被当成阻碍观众感知这个电影的罪魁祸首。

我相信只有24fps才是电影是绝对的谬误。觉得24fps才是电影，是因为在过去的世纪中，主要电影都是用它，但是我们不该假设使用24fps是因为它定义了电影的理想标准。电影仍是一种相对较年轻的艺术形式，它因技术而生，所以我们仍该继续通过实验来定义电影到底能成为怎样的东西。20年代有了声音，30年代有了颜色，50年代有了宽荧幕，70年代有了环绕声，90年代有了CGI，而现如今什么都可以数字化。当下，我们正在搞IMAX，3D，4K投影，最后终于开始着手弄帧率了。

现在，我们把高帧率使用到高清体育和纪录片中。但是伴随着胶片到数字的必然转变，这种使用（的局限性）是可以被打破的。杰克逊想提供这个神奇的体验，但是2012年，48fps在实现这个目标上，不像是工具，更像是绊脚石。48fps会使任何细节上的错误都无法被掩盖，这也许会迫使电影制作者们改变他们设计场景、道具、服装以及化妆的方式。如果做出这种改变，他们会找到一条（新的）出路，而且杰克逊会邀请你进入一个虚幻的世界，那里没有“动态模糊”这样的东西。

当然，48fps的成功完全取决于我们适应高帧率的能力。

【我们能适应得了高帧率吗？】

Movieline之前有一篇文章，大胆揭示了高帧率的原理，或者说是为何采用48fps的《霍比特人》看起来很糟糕。文章中，电影人James Kerwin基于量子论提出了一个理论：

“大多数研究者认为，人类每秒有40个有意识的瞬间。换句话说，我们的眼睛看到很多，但是我们每秒只能识别其中的40个瞬间。所以，如果一个帧率达到或者超过40fps，它看起来就是真实的。反之如果远低于这个标准，比如24fps、哪怕是30fps，就会有间隔，就会有不同，我们会立刻意识到我们看到的东西是不真实的。有人说，你看（低帧率）时间长了以后，就不会再有肥皂剧的感觉了。这是没道理的，不科学。这不是习得行为。它是一种我们大脑固有的观察事物的方式。

眼睛接收外界信息，后台大脑同步处理

我对此半信半疑，而且当有人下定论说人类大脑每秒只能识别某个数量的“帧”时，你应该也会怀疑的。 Vulture联系到约克大学人类知觉反应的专家Rob Allison，Rob否认了这个说法：“人类不是每秒接收24个帧，也不是每秒处理24个帧。我看到网上那些愚蠢的说法，说人类每秒处理40个帧，但是（人类知觉）是没有“接收限制”这回事儿的。

Tim J. Smith，伯克贝克大学视觉认知专家，对 Tested确认：光连续不断地从实物上反射到我们的视网膜上，不是像电影那样是一系列分离的帧，所以无论怎样增加帧的频率也不会超过（眼睛看到的）实物的“帧率”。

人类大脑有着足够的能力，来处理现实生活中连续运动的无穷的帧。所以应该不会有适应48帧的生理问题。然而，我们已经在影院里训练了自己几十年，来认同24fps（和相关产物）。我问过Michael J. Berry II，普林斯顿大学神经科学研究所的副教授，我们能否同样地训练自己适应48fps。他回复到：“可以，我认为我们可以适应。我们的视觉系统毫无疑问有能力处理更高帧率，因为所有闪烁地传来的视觉刺激物所带来的信息量，都比我们能够处理的现实世界的信息量要少。所以这真是个“先入为主”的问题。认为那（24fps）就是电影该有的模样。

这个观点得到了加州大学伯克利分校验光与视力科学教授Marty Banks的支持。他对Vulture解释到：“电视或者显示器里的颜色（与现实相比）不那么多，画面不那么流畅，亮度不那么好。可我们已经适应了，也接受了。所以当我们看见一个比我们之前所习惯的更接近现实的画面时，我们会有“过度真实”的感觉。我认为这就是正在发生的事儿。（《霍比特人》）看起来太过清晰，然而我们看到的其实是更接近现实的。如果人们失望，是因为它看起来跟我们认为的常态不符了。想想有色电影开始出现的时候人们的反应，或者高清，或者杜比音效！最初对这些技术也都有消极的反应。但是现在如果少了这些，你不会满意的。”

所以，好消息是，没错，我们能适应（高帧率）。永远不要低估大脑惊人的可塑性。只是需要点时间。

【我们应该适应吗？】

（2012年）4月份，杰克逊预估观众能够在看完他电影的前 10分钟后，开始逐渐适应48fps。事实是，对于很多人来说，是需要花超过10分钟的时间的。Allison则比较保守：“等你看到第4个或第5个高帧率影片时，你就能适应它了”。这跟Berry的推测是一致的，Berry推测说“适应48fps电影的过程，是逐渐发现这种电影的种种细节的过程”。不过他也提醒到，“我希望要有几分克制，还需要通过继续看24fps的电影，来加强我们当前对“普通”电影的认知。”

当下是关于48fps未来的关键时刻。与3D不同，高帧率放映是没有附加费的，所以电影公司和电影院不会因为推进48fps而得到更多的收入。华纳兄弟选择小范围放映高帧率3D版的《霍比特人》来试水。根据这些高帧率放映的销售情况，华纳兄弟会决定是否要把《霍比特人》系列接下来分别会在2013年12月和2014年7月上映的两部影片推广到更多的影院。2年内3部电影也许不足够（让影院、影迷和电影制作者）调整好来适应48fps，但是如果观众（通过他们手中的钱来投票）仍然广泛地抵制这项技术，高帧率会再次停止，就像上世纪70年代那样，尽管有特鲁姆布的努力（前文有提到）。

那场暴乱是评论家与音乐爱好者们，用来批评和埋葬《春之祭》的好理由，借此希望回归那些更熟悉的旋律。《春之祭》的转折点是在它的第二次公演，当一个好奇的观众不抱任何成见来到影院，才发现了Stravinsky的作品之美。《春之祭》的成功让其他作曲家开始去尝试Stravinsky所为，Stravinsky也在古典音乐的改革中开辟了一条新路！

如果我们把电影转变成48fps也会有缺点。杰克逊在他的facebook里写到：“实际上我现在已经习惯48fps了，已经到了看其他（低帧率）电影会觉得有点粗糙的地步。我周日看了一个新的电影，中途被摇晃和闪烁弄得不断出戏。我们被（48fps）宠坏了！”

Badass Digest的Devin Faraci提出了一个合理的问题：如果对48fps的适应导致了24fps的观影体验变得糟糕，这也会是另一个跨在未来电影和一整个世纪的传统电影之间的障碍。他说：“我不傻，旧电影对于新一代人来说总是难做的买卖。八九十年代的电影对于 Kurt Cobain自杀以后出生的人来说，会显得过于陈旧。但是高帧率的广泛采用只不过是让这种差异更加明显、更加深化而已。有些老电影比如《绿野仙踪》（The Wizard of Oz）或者《阿拉伯的劳伦斯》（Lawrence of Arabia），即使用现在的眼光来看，也依然受用于当代观众。想象一下这样的未来，那时不仅有美学上（与传统）的疏离，而且还有表述格式（译者：如24fps到48fps的格式转变）上的差别。对我来说，这样的未来会是一条非常鲜明的分割线，就如无声电影和有声电影之间的分别，一边是人们在当下看的电影，另一边是100多年的电影历史。”

我们离全部48fps化还要有几年的时间，所以最后24fps对我们所有人是否会看起来很奇怪还有待观察。即使出现了这种不大可能的情况，使我们每看到24fps都会使眼睛疲劳，也不能作为拒绝48fps的理由。电影，必须总是在它所处时代背景下被观看，不管它是默片、黑白、老式表演风格还是粗糙的效果。也许有一天，低帧率也会是上述这一系列名词之一。而用48fps带来的好处，来完成下一次电影技术的改革，是值得的。有顾虑时，（就告诉自己）不要为了保护旧事物而拒绝新事物。

批评家在为他们所爱所认知的艺术争斗，我对此表示尊重。但是这不是一个可以单纯基于我们自己的第一次主观体验来判断的问题。24fps陪我们幸福得度过了过去的那些岁月，但是48fps带来的是更棒的东西。作为影迷，给48fps一个机会是我们的责任。摒除所有成见，然后试着去看看那些喜欢高帧率的人们所看见的世界吧！

【豆瓣原文链接，未经授权请勿转载】

10大你不该做自由网页设计师的理由

Mon, 25 Feb 2013 13:43:28 CST

大家垂涎于成为自由网页设计师的理由有成千上万个，其中三大主要的即是经济自由，创作自由，以及你可以在任何你喜欢的地方工作。但是，我现在要告诉你，为什么这是一个坏主意。你也许有成百上千的理由讨厌你目前的工作。也许，你偶尔打电话请病假，仅仅是想多多休息一天，而并不在乎这一天的工资。又或许，你从两周前就一直推拖着朋友的邀请？小而简单的理由也会有重大的影响。

我可以列举100个你为什么不该做自由网页设计师的理由，但是不会有人愿意阅读这样的列表，对吧？所以，我就在这里列举为几个较为热门的理由。至少，是目前比较热门的！你的目标是回答不！

1.你总是犹豫不决

一次，一个同事邀请你领头公司的聚会，带动全部气氛热起来，而你却一言不发的停顿了一分多钟，你本可以简单的说 “让我想一想”，“行 ”或者“不行”就是你一瞬间的念头。又或者曾几何时你只是因为害羞而没有向同事求救？要记住，如果你不能马上决定，你可以说让我想一想，千万不要在与你对话的人面前停顿或者发呆。

那么，为什么这也是你不该做自由网页设计师的理由呢？

当网页设计师与客户共合作时，这关系到如何在交易中的方方面面能顺利沟通。从设计的提案，到签订合同或者整理归纳。片刻的迟疑都会毁掉你的信誉，因为客户希望服务提供商真正清楚自己在做什么。

当谈论到网页设计的时候，会有类似“我们该做些什么？”“你认为什么是最好的”这样的问题提出，而你通常需要迅速的回答上来，因为时间就是金钱。如果你花掉几分钟的时间去想解决办法，或者应对措施，你会很难留住你的客户。

2.你决定事情操之过急

同上面的观点相反，操之过急的决定事情也会危害你的事业。我说的主要是那些答应每个需求，并接受每一份修改需求，基本上成为了客户想法的奴隶的人。你应该学会说不，或者至少暂缓做出你的决定并要求一些时间考虑一下。如果你同意或者反对事物过急，你会发现你自己要么是被要做的任务所淹没，要么是完成一个项目之后就失去了那个客户。

解决方案1和2

最好是做出改变？学会事先考虑。从你跟客户或是老板的过去的谈话中学习，并从互联网上阅读那些预想的问题，然后尽可能了解多一些问题不至于到时候触不及防。当面对一些从未接触的事物的时候，你随时可以请求多些时间去考虑一下。这个方法会安全很多，对吧？

3．你认为这很容易赚钱

不，这绝对不是事实。自由职业赚钱并不容易，也不像是广告上说的那样“做你自己的老板”。你知道是什么导致了自由网页设计师更难赚钱吗？他们不仅要用自己的设计作品来取悦潜在客户，而且还要建立自己的市场。这关乎到他们怎么管理自己的财政，怎么在成千上万的竞争者中脱颖而出，以及怎么使得人们不管花多少钱都愿意找他们做设计。

这样的钱并不容易赚，甚至比你目前的工作还难。你目前的工作并不需要你很积极的去寻找客户。你的老板还会确保你交够了税，同时这很可能是一份一星期工作时间不超过50-70小时的全职工作。这与自由职业全然不同，特别是自由网页设计师需要常常保持创造力，或者甚至是更跟具挑战性的东西，就像是需要平抚客户的怒火。

送你一些技巧，下面是我的一个朋友与客户合作的全过程。

1.讨论需求，颜色，宽度以及其他的材料。

2.传发几份线框图/草图（依据以往来看他一般会发5份不同的设计）供客户挑选。

3.一旦方案被选中了，他便开始基于选中的框架使用photoshop开始设计。

4.如果客户说他可以自由选着配色方案，那他会做几份不同的配色方案供客户挑选。

5.一旦设计方案确认了，就可以开始对设计稿进行HTML+CSS重构了。

值得提醒你一下，这个谈话是发生在两人之间的，并没有监制或者经理在场。并且从沟通到交付大约是从几小时或者一周时间不等，这取决于项目的大小。这只是整个过程的一部分而已。关于讨论价格，合同，以及其他非设计相关的东西也会随之而来。衡量一下，这样赚钱容易吗？如果你怀着自由职业容易赚钱的心思进入这个行业，你会不知不觉的陷入困境而且会以惨痛的失败告终。

4.你的得意佳作不超过5个

我知道开始从事网页设计师这份职业已经是很难的了，但是如果你的作品集里得意之作不超过5个，那么你别指望着成功了。不管你的作品是之前工作上的还是只是为了给你的作品集添色做的，这都没关系，重要的是它能吸引人就够了。这些作品同时能证明你很擅长做这些事。你不会在网上买差评的东西，对吧？网页设计也跟这同理。客户寻找的是能做好他们网站项目的人，而不是那些只会口头承诺做得有多好的人。

让他们知道你能做什么！如果你一直不创建个人作品集，那你还是放弃成为一名自由网页设计师的想法吧。

解决方案：从现在开始创建你的个人作品网站。花点时间，从现在开始建立你的个人网站，同时用你的优秀的作品让它流行起来。现在就开始做，你绝不会后悔！

5.你要付的账单很多，但是却没有积蓄

踏入自由职业的世界是一个大冒险。如果没有熟练的技巧，工具，以及引导人，那么你很可能连续几个月都找不到一个客户。如果你每个月的薪水支付那些财政支出让你筋疲力尽，那么你甚至想都不用想从事自由职业。如果你正好联系到好的客户，你的项目可能会完成得很顺利。但是，这同样种冒险，因为客户并不是络绎不绝的。

我们假设你已经具备了足够的技能，拥有作品集，除了客源，一切都准备好了。你对于寻找需要网页设计师的人有计划吗？况且，这存在个问题，并不是每天都有人想要建站的。好消息是网页设计师可以用很多方法与这个死胡同做斗争，其中最好的方法之一是将客户转换为被动收入来源。关于这点，我们将在日后的更新的1WD的文章中详细说明，所以请确保你订阅了我们的资讯，或者关注我们的Facebook或是Twitter来关注我们的更新。

总而言之，进入自由职业的世界是一个大冒险。请务必要相信我说的，如果你的银行存款不够你至少三个月没有收入的生活，那就不要做自由职业者。

6.你认为photoshop就是网页设计的一切

如果你将网页设计定义为仅仅是使用photoshop设计一个网页模板，那么你应该重新考虑你的标题，因为这只能叫做图形设计（拓展术语）。

作为一个网页设计师意味着三件事：

1．你应该擅长使用phtotoshop将思想转化为现实。（或者使用其他的图片编辑工具）

2. 你应该擅长将设计图进行html+css重构。

3. 你同样也很想成为一位网站开发人员。

好，让我们来讨论2和3。如果现在想要进入自由网页设计的世界，你应该具备相当好的html+css技术，因为这是目前的标准。如果现在html+css技术对你来说还很陌生，那我强烈建议你现在开始好好学习它。许多的网页设计师因为只专注于photoshop，html, css而被自身限制，因为他们不会编码导致他们不能加功能性的东西，而会编码却能帮助他们的的职业生涯走得更顺。

当然，这是随个人所愿的，但是如果你想成为一名网页开发者，前方会有一个光明的未来等着你。

7.你讨厌修改

你认为成为自由职业者没有老板，是吗？很不幸，这这完全是个错误的认识。有人付钱给你为他们工作，那么他们就是你的老板。没有任何一份网页设计的工作，是设计初稿就可以满足客户的。通常都是会被要求修改，甚至修改多次。

让我告诉你这些：客户喜欢修改。他们觉得自己掌控着大局，就像他们知道他们正在做什么似的。你不得不顺从吗？当然，如果他们的意愿与你觉得更好的方案相违背，那么就大胆告诉他们，但是如果你不能，那么只能服从了，因为是他们付给你钱。

8.你不愿意与人交谈

作为一个自由网页设计师，在很多方面还是跟自由作家和网站开发者是不同的。自由网站开发员和作家都以更加系统的方式工作着，而自由网页设计师却是靠一半的主观因素和另一半的客观因素工作着。

他们并没有走下面这样的流程：

1.客户把需求发给你

2.你开始工作

3.你提交方案

4.客户通过你的方案或者要求修改。

现实是残酷的：

1.接收客户的需求

2.你跟客户讨论交流

3.你开始工作

4.你提交方案

5.客户要求修改

6.你开始修改

7.客户提出新的修改需求

8.你又开始修改

9.客户决定换另一种方式

10.你厌倦了他的闹剧

11.但是你仍然继续做着，因为你已经开始了

12.你忍耐着并且完成这个项目直到客户满意为止

这就是现实，每次修改都需要交谈，谈判，甚至有企图自杀的念头！

9.你不思进取

如果你的作品没有打动客户，那么他们不会给好评你的服务。大客户通常会查看你之前客户对你的评价。没有这些评价，你很难接到大的项目。追求完美是网页设计师的一种自我定义方式。你的作品应该反映你的能力，所以，如果你的作品很优秀而且拥有很多好评，那么你的新客户就会认为跟你合作放心。如果你常把“大概做完成了”或者“这已经够好了”这样的话挂在嘴边，那么你不适合做自由网页设计师。网页设计是一门艺术，你的每一个作品都该是精心雕琢过的。如果你抱着大概差不多就可以了的心态，那么人们还能期待你什么呢？

10.你没有精读我所列出内容

如果你没有读完这里的每一个字，你会是：犹豫不决- 你打开这个文章是为了阅读，不是看几眼就走。不愿意学习- 好吧，是这样？不思进取- 你最多花了十分钟看完这篇文章。觉得自由职业容易-你觉得了解关于自由职业的一切?如果你很认真的考虑过成为一名自由网页设计师，而且如果你来这里是为了想学习这些，那么你为什么直接跳到了最后呢？如果你是极少数的能精读并仔细考虑这些观点的，很好！这是种很好的态度！

问题：你仍想成为一个自由网页设计师吗？

如果我在这里列举的每一条你的回答都是“不”，那么，请马上开始自由职业吧！但是，如果你的回答是“是的”，那么你至少应该解决这些问题再开始做其他的！

一月 29, 2013 -- 在photoshop中制作一个飘浮于空中的茂盛的“树屋” (6)
十一月 3, 2012 -- 在Photoshop中学习创建一个复古的游戏手柄 (4)
十月 20, 2012 -- 美国艺术家Dave Rapoza的动画角色绘画作品欣赏 (1)
十月 7, 2012 -- 使用illustrator中的3D选项创建高亮的网页按钮 (4)
八月 13, 2012 -- 可扩展的移动设备上搜索表单 (3)

20130306早读课：从语言学角度来看按钮的文案设计

Wed, 06 Mar 2013 07:15:32 CST

推荐理由：早读课原创翻译小组成员 @沐沐成长中翻译。原作者Jonathan Richard是名经验丰富的产品设计师。在文中，他从自己的经验出发，独辟蹊径的设计出自己的检验按钮文案设计的方法，让我们一起来看看他的观点。

用户体验设计总是要求在按钮上写些文字，但是我们如何才能选择合适的文字来诱导用户点击？从语言学角度出发，或许能提供一些线索。本文从语言学的角度来验证行为召唤（call to action ）按钮是否符合体验元素的语法。

正确判断按钮的文案价值，不仅有助于让我们在设计按钮时充满信心，更可以解释为什么总有一些网站似乎能够优美的将设计的思路传递给用户。

每当我们回顾那些写着“Click here to…”的行为召唤按钮的日子，不禁虎躯一震。但是如果有人挑战你，问你在按钮上使用什么样的文字才算合适？你能给出一个的正确的解释吗？对于如何选择符合语法规则的文字，能否概括出一些规律呢？

以动词开始（ It starts with a verb ）

很多文章对按钮的措辞提出了建议，其中最实用的一句如下：

按钮是指向（用户）行为，如“咨询”（“Get a quote,”）、“下载”（”Download”）、“打开账户”(“Open an account”)、“去结算”(“Go to checkout”)。按钮上的话一般以一个动词开始，否则就不是一个召唤行为按钮。例如“More information”就不是一个召唤行为。

——David Hamill

想想你的用户该会如何解释，如果你问他为什么试图这样做。如果他说：“我想比价”，于是“比价”就是你将要写在按钮上的文字。这就是Jared Spool所说的“触发文字”（“trigger words”）。

笔者认为，文字应该“以动词开头”。这一说法的真正价值在于：” Think about what your user would say if you asked him what he was trying to do.”

在这里，笔者忽然想到一个语言学的问题：我们如何发明一种语言格式，既是用户想说的也正是我们所希望他们去做的？问题的答案意义重大，因为按钮有个双重功能：他们既是call-to-action（信息发布者向用户展示一个机会），又是用户表现其决定的媒介。

因此，什么样的语法规则能解决这一问题？

设定语气（ Setting the mood）

很多语言都有一个语法概念叫“语气”。简单来说，语气就是说话者想要表达的观点的一种“态度”，例如“I am stating a fact” （我在陈述一个事实）、“I am suggesting this might be true”（我认为这可能是真的）与“I am commanding you to do something” （我命令你去做某事），这几句话的语气是不一样的。

具体来说：

The conditional mood（条件语气）表达假定的逻辑，如：“他将会返回到他的篮子里如果……”
The subjunctive mood（虚拟语气）表示可能性，如“如果它是一个篮子，他或许会返回来”。
The imperative mood（命令语气）用于发号施令，如“返回篮子”
The interrogative mood（疑问语气）表示疑问，如“他会返回篮子里么？”

所以的语气共同点在于，说话者非常明确，但是网络上不同。网页制笔者写下文字引导用户行动，但是最终却是他能够给用户来点击，但下一步的行为由用户自己来把控。所以那些写在按钮上的文字，必须在笔者和用户的双重主语之间需求合理的方案。一个典型的例子：在按钮上是使用所有格形式的“my”还是“your”？微软的风格指南建议两者都该留有余地，在不同的时机迎合不同的“说话者”：

1.运用第二人称（you,your）告诉用户去做什么。

例如：Choose the pictures you want to print.（选择你想打印的图片）

2.运用第一人称(I, me, my)让用户告诉程序该做什么。

例如：Print the photos on my camera.（在我的相机里打印照片）

虽然这种区分看起来是随意的，那“告诉用户去做什么”与“让用户告诉程序去做什么”之间有什么本质的区别么？真有一种文字格式可以很好的兼顾笔者和用户么？

Wilty-Wilt测试

以语言学为指导，一个可行的解决方案是：按钮上的文字应该同时兼顾 疑问句式——“你想…么？”（设计者想让用户去做的）和 条件句式——“我想要…”（用户所希望做的）。我喜欢称之为“Would you like to? / I would like to”测试，或者简写为 WYLTIWLT (发音同 “wilty-wilt” )

Wilty-Wilt测试提供了一种评估你所见的每一个按钮好坏的方法，甚至可以自己创造（好的按钮文案）。

用这个测试来评估，那些世界著名的网站上的按钮表现如何呢？事实上，表现非常好。（值得一提的是Facebook，在它上面，我一个不通过测试的按钮都找不到。Twitter 和 Google偶尔有差错。）上面的图是网络上搜集到的一些通过了“WYLTIWLT”测试的按钮。当然，也有不少表现很糟糕的例子，如下图：

有意思的是，至今为止最常见的错误（至少按照这个逻辑如此）是在按钮中使用所有格形式的词语（如“我的”、“你的”“my” / “your”）。

如何去判断一个设计正确的按钮?

以WYLTIWLT 测试作为指导，下面是一些帮助你制作“语法正确”按钮的规则：

1.功能性第一 (FUNCTIONALITY FIRST )

表达个性时，总是想详细以致变得冗长罗嗦。相反，千万不能这样做。请试着使用更直接的表达：“Keep out!”, “Stop”, “Give way.”这些词就很高效。不要担心太简洁，尽量使用直接的（简洁的，有用的）各种形式如“邀请朋友”，“找朋友”这样的话，这样的按钮就足够友好。

2.保留人情味儿（RETAIN THE HUMAN TOUCH）

与此同时，也不要放弃个性。只需记得遵守语法规则，不要违背就好。Smug Mug（一个照片分享网站）就是一个很好的例子。他们的APP（Camera Awesome），拥有类似Instagram的功能，可以给照片添加各种滤镜效果，而行为召唤按钮是“Awesomize”，编造的一个词，很可爱但也表意清楚，同时也是一个动词，意味着符合WYLTIWLT 测试的标准(“Would you like to Awesomize?” “I would like to Awesomize!”)。虽然是人造的词，它却很好的兼顾了信息发布者的邀请和用户的意愿。

3. 使用设计语言来衔接（USE DESIGN IN CONJUNCTION WITH LANGUAGE）

如果你还在为如何避免使用第二人称而挣扎——如“你的信息”等等，试试设计能否有所帮助。不要再按钮中写“你的”、“我的”，相反，涉及特殊目的或者需要用户做出一系列行动，要尽量简洁明了——或许就是在下拉菜单的顶部。Pinterest 直接用“messages’, “pins’, “likes’来引导登录用户。他们不使用“你的”但同样很清楚。

4.例外（EXCEPTIONS PROVE THE RULE）

规则并不意味着不能打破。一些一流的网络公司在设计按钮时并不依附语法规则。例如“I’m feeling lucky”可能是迄今为止最糟糕的按钮，但是如果没有它，Google主页将看起来有点奇怪。最重要的事情是简洁，在大多数时候使用有效的措辞，你就能负担得起每隔一段时间去越野滑雪一次。

最后

在网站上，按钮上的文案不是你所担心的唯一问题，但它们却蕴含了重要的信息，按钮上你所选择的文字将决定其承载信息成功与否。这个WYLTIWLT 测试将帮助你选择合适的文字，既简洁明了，符合语法规则，又能兼顾用户的意愿，从而创造更和谐的网站体验。

Via：原文出处原作者Jonathan Richards

“互联网er的早读课”翻译小组原创翻译，转载请注明本文出处。译者水平有限，如有不妥欢迎在评论中指正。

如果看到这段文字，证明您已经看完这篇文章了，有什么收获有什么感想有什么不赞同，我们期待您的留言评论，并诚挚邀请您加入“互联网er早读课”官方2群：74447564，一同交流每天文章的心得并结识同好。注：官方QQ群非水群，喜欢闲聊的童鞋请勿加入。再次感谢您对早读课网站的支持。

我们猜您可能也喜欢：
20130222早读课：移动产品的典型设计思路	20130227早读课：如何设计产品里优秀的反馈循环	20130304早读课：产品设计中“行为召唤”的意义	20130228早读课：为移动而设计，也谈信息的架构	20130225早读课：如何设计优秀的登录框？
无觅

网页设计中的方块元素

Sun, 05 Jan 2014 14:44:39 CST

[国外设计第25期]

当你欣赏下面这些案例时，留意一下他们如何以及为何使用矩形或正方形元素，会使得你思路大开。此处列举的方块元素，被用来对齐、组织、装饰、排列页面上的方与圆。在设计中使用方块元素有很多方法和原因。我们来详细了解一下。

使用方块布局的目的是什么？

或许这对你而言有点哲学和理论化，我们来看看别人选择方块布局的原因。（顺便提一句，我所指的方块也包括矩形，有些案例也使用矩形。）使用这种元素有两大原因。首先也是最重要的，它有助于组织内容。其次，它也能打造特殊的样式。它们是展现内心渴望和需求的完美元素。

看看Dennis Adelmann的作品集，显而易见，方块元素被用来组织排列他的作品。这是组织排列任意数量内容的简单途径，让事物保持简洁。

不过再看看We Love Noise这个网站，它就完全不同！是的，到处都是方块，移动鼠标时还有个有趣的动画效果。不过除了组织内容之外，你会发现方块元素也成为了设计风格的一部分。它是这种风格关键的决定性元素。

怎样用好它们？

我不觉得使用方块元素是什么难事。尤其是网页，自从诞生之初就开始使用方块形状来设计界面。但是你若想更有效地使用它，请遵循以下几个步骤。

制定希望达成的目标

根据你所要达成的目标，页面和区块会有很大的不同。一旦你确定了，方块元素就能帮助你完成目标。你是用它来组织内容？还是想为页面增添一点乐趣？

看看Paper and Paint。他们使用方块元素保持页面井井有条，并且突出了页面特有的流动性。随着鼠标向下滚动，每个方块中的不同内容都在进行着视觉差滚动——这是个非常酷的效果——每个方块都向你讲述独特的故事，汇聚成整个页面。这些方块元素的作用，就是保持各部分对齐，形成一种整洁的时尚，同时也为各个页面营造不同的故事氛围。

Anthony John Group使用方块来展示他们创作的各个项目，还有关键的公司信息，比如“幕后团队”。主页的规划与构建很棒，但也结合紧密。很明显，他们致力于创造像这个页面一样优雅的高端建筑设计，如果没有这些方块，可达不到这样的效果。

使用方块来组织内容

既然了解了你所追求的目标——尽管那几乎就是整合现有的信息——你会接触到内容组织的。你得把内容编成目录。要如何在各个方块中组织信息——某些方块内容会比其他的更多吗？这对组织内容很有帮助，你会来回摆弄，看看哪些有用哪些没用，发现哪些内容太多，哪些内容太少。我保证这不是什么高超技巧，实际上它不太需要凭直觉，大多时候都很简单——坐下来去完成它就是了。

注意到上面这个网站没有，Block Level，方块和方块中的图标就是全部了，只有图标。这就是我所指的组织内容，Block Level的设计者故意在每个方块中只留下一个图标。下一步就是要考虑如何将调整过的内容放在令人愉悦的设计中，这正是我们下面要讲的。

调整这些方块，或者干脆不动它！

既然组织内容的工作让你了解一组组信息看起来是什么样，你就要思考应该怎么处理这些方块。这是让你打磨内容块大小的一步，可能你希望它们都保持一致——又或者你决定让它们错落杂乱排布。这还是得取决于你的具体目标。

从Nedd中可以看出，方块元素都非常巨大，它们有着近似的宽度和相等的高度，让网站看起来井井有条。我希望你注意的是，虽然这是偏向于内容组织的用法，网站的样式仍然非常有趣轻快，这主要得益于它的颜色、矢量元素、圆形的应用、字体等等。

另一方面，我们还有像Banana Café这样元素散乱的网站——如果你想，也可以这样优美地乱序排列。这个网站看起来也很好玩，得益于它的字体、颜色的选用等等。方块的这种特殊用法其实没什么，只是一种特定的设计手段。

点缀样式

有千万种设计方法，可以为你下个项目中的方块元素打造特殊风格。你可以将它们与其他元素自由组合，比如圆形，或者采用贯穿始终的矩形或正方形来营造网站的视觉焦点。最后两个例子中，你会再次见识如何将方块良好地应用于设计中，希望对你有所启发，并能在你下个项目中发挥作用。

Jan Finnesand用了全屏的宽度与高度来放置方块，每一块都有特殊作用，大多展示了他以往的项目案例。充满整个浏览器窗口的方块造就了一件非常酷的设计。

这家公司无处不用方块！主页上可以看到，他们也展示不同的案例。通过不同尺寸的正方形引导用户视线。我最喜欢的一点是，他们用两个正方形来组成一张更大的图片，但每一张都指向一个独特的项目——我觉得这很酷。

原文链接

随意看看吧
将APP设计理念用于网页设计	网页设计中的半透明运用准则	网页与APP中那些优美的登陆表单	网页设计的10个灵感来源	隐形设计
无觅

20131024早读课：提升iPad应用用户体验的5个技巧

Thu, 24 Oct 2013 08:02:06 CST

此文由互联网er早读课翻译小组成员@小悍_ 原创翻译。据9月份的数据，App Store里iPad应用即将达到40万，iPad Air也更加轻薄的闪亮登场。没有任何时候比现在更适合去研究如何提升iPad应用的用户体验了。

本文中的一些想法不只是针对iPad，也跟所有的平板电脑有关。但考虑到iPad的巨大成功（去年销量占所有平板电脑的73%），它是绝对值得我们去特别关注。所以，话不多说，我们来看一下提升iPad应用用户体验和设计的五个界面指南。

1. 舍弃标签栏

在iPad上，标签栏已经过时了。与以任务驱动、需来回切换的智能手机不同，标签栏在像iPad这种“后仰式”的设备上已经不需要了。换句话说，iPad更轻松的使用方式，意味着不必急于在导航选项的前面和中心快速地切换视图，而这正是标签栏的主要作用。与iPhone应用不同，人们在使用iPad应用时，会以更长的时间和更轻松的状态沉浸其中。

标签栏在大屏幕上也较少使用。大拇指不能对它们进行操作，它需要变化手的位置。从视觉上讲，它们占据了视觉焦点；从布局上讲，它们常常占了非常重要的位置。比标签栏更优雅的选择包括滑出式（见Facebook），基于手势的操作（见Paper），内容驱动的导航（见USA Today）。除了更美观、实用外，这些方式额外的好处是，它们与视网膜显示屏非常互补。

2. 别捏我

手势是触控设备独特的原因之一。它们使应用更人性化、更有趣和更直观。不幸的是，当手势与应用自带的手势不一致或手势不标准时，它们能引起用户的挫败感。手势的一致性是移动设备普遍存在的问题。尤其在iPad上更为常见，只因iPad上有更多的手势操作方式。如多点触控、捏合、滑动等。

在iPad上用手势操作时：

1）请记住，通常会有一只手一直放在设备上

2）在第一次操作时用实例来介绍非标准手势

3）当用户头几次或每一次使用它们时，可以考虑通过视觉或动画来强调非标准手势

4）要了解iOS的手势，包括四指轻扫，五个手指向左或向右滑动，五个手指捏合等，所以应用的手势不能与iOS的手势冲突

3. 高度写实化

高度写实与拟物化设计随着iPad的出现变得更加流行，这反过来又影响了Mac电脑上应用程序的设计风格（例如iCal）。在苹果的人机界面指南中写道：“应用程序呈现的虚拟物体和行为看起来越接近现实生活中的事物，用户就能越快的知道如何使用他们。”这在理论上听起来不错，但实际情况却并非如此。

这种方法面临的第一个问题是，用户体验设计师对于真实世界中物体的感知和使用方式不一定跟用户一样。其次，除非物理世界所有物体的外形可以转化，否则这个比喻说法将不成立，最终导致应用中出现意外操作。

这些问题能在苹果自己的应用中看到，比如iPad上的Notes。Notes从视觉上看，像一个传统的记事本，但页面不能翻转。要开始一个新页面，必须点击“+”按钮。在每个页面间用侧边栏和浮动菜单来导航。最终，分不清这个界面的哪部分应该像应用程序，哪部分又该像真实的笔记本。

由于这类问题，当涉及到拟物化设计和高度的写实感时，一般不建议使用它们。在不久的将来，应用程序界面应让用户觉得是一种通用、易懂的交互模式。所以，iPad应用的用户体验不必受限于这种陈旧的、老化的、历史的比喻说法。

4.拆分(令人头痛的)视图

拆分视图不是iPhone上遗留下来的，它随着iPad的出现而出现。最终，它被过度作为应用程序的主要视图和导航方式。

拆分视图的经典例子是iPad上的邮件（它对拆分视图的普及起到了一定作用）。拆分视图通常的布局是，左侧是比较小的导航主体窗格，右侧是较大的细节窗格，主要用来展示内容。拆分视图在iPad自带的应用中（如邮件、笔记、消息、提醒、设置）非常普遍，以至于感觉它就像是iPad横向的默认视图。

拆分视图的主要缺点是，屏幕显得拥挤且不集中。在设置类的应用程序中,这没什么大不了。但在邮件中，每封邮件都需有回复、存档或删除操作，不应让用户一定要将iPad旋转成纵向才能看到一个视觉焦点更集中的模式。

虽然拆分视图目前还没有到处用到，这里还是有一些提醒：

1）在iPad上设计视图时,不要简单地默认使用拆分视图

2）虽然苹果没有推荐，但在使用拆分视图时，可以考虑把主窗格隐藏。还有一个更大胆的做法是在纵向视图上加一个浮动菜单来显示列表，在主视图中也可以这样做(见 iA Writer，下图)。

3）如果列表视图没有必要,若需使导航可见,可以考虑把导航放到侧边栏(见iPad 上的PBS)或工具栏里

5. 换角度思考,基于iPad进行思考

总结一下，目前一些最好的iPad应用把iPad屏幕看成了一个空白的画布，它们在上边创建全新的、创新性的用户体验。这些应用与苹果最“神奇”的产品展示了全新的视角，它们包括

Pennant
Nursery Rhymes
Flipboard
The History of Jazz
Paper
Magic Piano

这些应用在追寻苹果“不同凡想”理念的同时，仍然遵循人机界面指南和一些既有标准。对用户体验和设计专业人士来讲，跟上iPad变化的唯一办法是把自己变成消费者，尝试各种最新应用，看看什么行得通，什么行不通。至少现在，这是iPad的时代。所以，是时候“不同凡想”了。

原文出处： uxmag.com 译者微博： @小悍_

关于原创翻译：早读课在每个周四开辟原创翻译专栏，我们将组织早读课原创翻译小组成员一起翻译一些国外优秀产品、交互、用研等方面的文章。如果你有兴趣并能坚持下去，请在早读课QQ群内联系Aimee了解加入方式。译者水平有限，不当之处欢迎指正，不甚感激。

延伸阅读： 20130613早读课：iPad是真正的移动设备吗？

如果看到这段文字，证明您已经看完这篇文章了，有什么收获有什么感想有什么不赞同，我们期待您的留言评论，并诚挚邀请您加入“互联网er早读课”QQ群，一同交流每天文章的心得并结识同行。官方4群： 13555283，加群密码“职业信息+城市+姓名”，否则不予通过，入群后请修改群名片。

我们猜您可能也喜欢：
20130107早读课：十条提升iOS应用用户体验的经验分享	20121023早读课：移动应用设计案例，打造初创型用户体验	20130504早读课：“设计之变”— 从iPhone应用到iPad应用	20121125早读课：什么是好的用户体验？	20131010早读课：我们不再是一个用户体验设计师了
无觅

新的APP演示良方：GIF动画

Sun, 13 Apr 2014 13:24:03 CST

[国外设计第36期]

每种事物都有回归的本能，长期以来，GIF动画在开发者当中，失去了它的统治地位，不再受欢迎，不再通用，近期它摆出了回击的姿态。尽管还是一如既往展示图像序列，但它不再像当年那些生硬的低画质视频，没有粗糙简陋的过渡效果。如今，GIF动画能够通过抢眼的效果和流畅的过渡，有效地聚集人气，给最终的动画一种柔滑精致的感观。

UI/UX开发者迅速估量了这种动画图片的潜力，它们虽小却非常有效，极具解释性。我们都知道，有时向客户或最终用户解释APP最后看起来将是什么样，会是多么困难、气人且耗时的事情；没有华丽的高质量截屏，精心绘制的用户界面配上一大堆解释和“手势”说明效果，并不怎么管用。只有视频和这些简短的GIF动画，才能轻松展示操作流程，并传达一款“活”APP的所有魅力，在众多功能组件之间，有效地展现交互。

颇具讽刺意味的是，我们的展示工具集中，最近补充了一种新工具，而它实际上一直以来就近在咫尺。

今天，我们汇集了一系列GIF动画作品，愉快地展现了各种移动应用的操作流程。

第一件作品是Dmitriy Chuta的Chapps，你可以欣赏它整个漂亮的动画效果，一组不同职业人员的照片卡。这张GIF图片展示了一种讨人喜爱的方式，通过令人愉快的视觉表现，来在数据库中进行选择和搜索。

Bastien Leprince的APP概念设计，这里，我们的主要注意力，集中在地图组件内嵌的拖拽筛选功能上。所展示的所有功能界面和组件，相互间完美互动，为用户提供了一套流畅的操作流程。

George Frigo的FaceScan APP概念设计，尽管动画只持续了12秒，但它足够清晰地表达了这个APP的主要创意。对于那些想要一睹完整版的人，这位UI设计师也提供了AVI文件。

Alexander van Ravestyn设计的WIP音乐发现APP，就如名字所暗示的，设计师想将用户的注意力引导到多媒体内容的浏览过程上来，不出所料，最终来到一个设计精美的音乐播放器界面。

Jakub Antalík设计的Speedcam APP动画，设计师非常棒地通过动画表现他的APP。GIF漂亮地展示了speedcam的一部分，光彩夺目。

Barthelemy Chalvet的Workflow Payment，这个团队展示了他们新APP的几张GIF。下面这张将关注点固定在支付流程上，看起来相当优雅便捷。其他GIF突出了时间轴、支付/费用、卡片和账户处理。

Barthelemy Chalvet的Dashag Tour，这个团队只是展示了一张小GIF动画，让人想起他们之前的项目。如果你想完全熟悉这个APP，可以访问他们的官方网站，里面包含了一大堆GIF动画，展示几乎所有的功能界面。

Sergey Valiukh的GIF动画设计，这个一流的界面有着令人愉快的精心处理的过渡动画，表现了在基本地图组件与主菜单间切换的简短流程。通过舒服的动画效果，一切相互衔接良好。

Devin Ruppert的Walkthrough动画，这张GIF展现了一个欢迎界面，带有多个动态图的幻灯片和登陆按钮面板。一切都活了，有效地表现了这个APP所带来的功能。

Mihnea Zamfir的交互概览，这是个非常简短却有效的动画，初衷是描绘一个从卡片目录中添加和删除项目的简单流程。

Tobs设计了给队友删除和添加任务的动画，这张GIF动态展现了标准的滑动技巧，有效地支撑了整个审美取向，让APP看起来更鲜活、现代和诱人。

Jan Losert的团队信息工具，这个团队为用户提供了大量解释性资料，不仅用来展示带有描述的静态屏幕截图，还有视频和一张巨大的GIF动画，展现这个APP的真实操作过程。

Ben Dunn的菜单交互GIF，这个动画GIF被当作展示动态美感的工具，表现了菜单优雅地从左侧滑出，并列出所有必要链接的过程。

Ed Sansom的Poppin添加任务效果，这个APP有着讨人喜爱的圆形氛围和优雅的扁平美学取向，集各种柔滑效果于一张GIF，使它得到了恰到好处的强调

Dennis Terrey的第一件UI动画作品，这张GIF试图示范，如何使一个基本的菜单看上去干净、时尚和细腻。

Danny Spitzer-Cohn的Zite新鲜事设计，我希望用这个讨人喜爱的GIF动画来补充这篇作品集，它对高雅和传统的运用，绝对给人带来一丝愉悦的怀旧感。

对于那些想要尝试这种展现方式的人，我们也准备了几样赠品——可以被轻松拆解成组件的GIF动画。

赠品：PixelBuddha的扁平风格预加载动画

Areus Wade预制的触摸手势动画

结论

就APP创造者和客户（或最终用户）间的互动而言，像Adobe After Effects这样的视频编辑软件充满了机会和可能，能够解决很多问题。GIF图片可以用来简短的解释动画效果，有效的展现操作流程，让人更好地理解这是怎么回事。

原文链接

随意看看吧
活力四射的状态指示器：移动APP界面的加载动画与进度条	光彩夺目的柔滑渐变APP界面	将APP设计理念用于网页设计	8个优秀的移动APP字体运用案例	网页与APP中那些优美的登陆表单
无觅

浅谈翻译的两个基本问题

Sat, 01 Jun 2013 11:01:52 CST

说起翻译，许多人都有兴趣。但真正能动手去尝试的人，只占其中的一小半；能熬过尝试阶段的煎熬，真正入门的人，更是少之又少。这种现象给不少人造成了错觉，认为翻译是件看起来容易做起来难的事情。但是根据我自己的经历和其它做译友的反馈，这话其实只说对了一半，翻译“做起来”并没有那么难。翻译之所以给人“做起来难”的感觉，很大程度上是难在入门阶段，难在一些基本问题没有解决。所以，这篇文章来谈谈大家关心的两个基本问题：第一，翻译是怎样的工作；第二，直译更好还是意译更好。

谈到翻译，许多人之所以感兴趣又不敢尝试，是因为自认“文字天赋不够，文学造诣不足”，总之，就是艺术修养不够。翻译是与文字打交道的工作，而“文字”总让人联想到“文学”。毕竟，在相当长的时间里，只有少数受过教育的人才识字，他们所追求的只有“经世文章”，而且公众所知的“翻译家”无一不是以翻译文学作品而著称；故而“文字”常常与“文学”和“艺术”紧密起来，由此把众多感兴趣的潜在译者挡在门外。

然而在今天，文字的主要功能已经不再是铸就“经世文章”，而已为普罗大众所使用，传递各式信息；翻译也不再只有“翻译家”一条出路，各行各业都有大量的资料需要翻译，都需要称职可靠的译者。所以，如今大量需要的翻译，与“艺术”的关系已经不再紧密。不妨想想日常生活中所见的各式翻译资料：新闻、博客、说明书、学习资料……用母语编写这类资料完全不需要作者有太高的艺术修养，同样的道理当然适用于译者。或者说，如果一个人可以用母语写出较为规范的使用说明或新闻报道，那么他的“艺术修养”完全可以满足翻译说明书或新闻报道的要求。

有人说，即便用母语写作，要把文章写得流畅也不是人人能做到的。没错，它不是人人都能做到的，但许多人之所以做不到，原因并不是缺乏“艺术天赋”，而是缺乏训练。在我看来，科学在二十世纪的一大进展，就是证明了许多之前认定的“天赋能力”，其实都可以依靠有意识的训练来掌握，比如当今优秀中学生的短跑成绩已经可以超越一百年前的奥运冠军。写作的能力也是如此，20世纪30年代以来，美国文学在世界上的影响力迅速增加，一个重要原因就是美国大量开设了创意写作（creative writing，也就是我们常说的“文学创作”）培训课程，有效提高了普通人的写作水平，所以退伍老兵、监狱囚犯之类普通人也可以写出不错的作品。而“创意写作”的内容，粗略来说无非是介绍写作的基本规范，并要求勤加练习。我相信，国内有志翻译的朋友的“文学天赋”肯定不输于美国的退伍老兵和监狱囚犯，如果文章写得不够流畅，所缺的无非是练习而已。

既然翻译和艺术的关系不大，那么翻译是作为“艺术反面”的科学吗？随着科学的进展，机器翻译的效果已经越来越好，许多时候甚至可以“胜任”简单规范的文本翻译了。可是，翻译与“科学”的距离还相当遥远。科学是一种认知体系，目的在于探究事物的规律；而翻译只是一种语言转换过程，加之自然语言本身就不是规范严格的，里面又掺杂许多“只可意会”的主观因素。所以，即便是现代伟大的翻译理论家奈达，在坚持了几十年“翻译是科学”之后，也不得不承认，翻译是艺术。比如The night breeze came with pleasant guitar，没有艺术的灵光闪现，仅仅靠讲道理做分析，万难翻译为“晚风送来美妙的吉他”。这只是个简单的例子，许多翻译的“神来之笔”，是分毫离不开艺术的。

由此看来，翻译既不是艺术（或者更准确地说，与艺术关系并不紧密），也不是科学，那么它是什么？我的观点是，翻译（纯文学之外的翻译）是一门技艺，它同时包含技术、艺术、科学三方面的因素。

在技术方面，翻译不要求译者有很高的艺术天赋，而强调有意识的练习和总结：名词、动词、代词等应当如何翻译，各种时态、语气如何翻译，新闻、律师函、说明书各应当如何翻译……这类问题都有一定之规，甚至已经整理结集出版，如果善于学习总结并勤加练习，应付普通的翻译是完全没有问题的。

在艺术方面，翻译要求译者有一定的艺术修养，即能够判断出文字的好坏做出取舍，识别学习提升的方向。还是上面The night breeze came with pleasant guitar的例子，初学者可能会翻译为“晚风和吉他一起到来”，一定的艺术修养则可以帮译者判断出“晚风送来美妙的吉他”更流畅更优美，并努力掌握这种转换模式，在以后的翻译中熟练运用。这种素质虽然名为“艺术修养”，但我相信，念过中学语文的人都有这样的判断力。

在科学方面，翻译要求译者有理性探究的精神和学习最新进展的本领。我见到许多译者困扰于英文中常见的复杂结构长句，但每次我与他们详细分析解理出各部分及之间的修饰限定关系之后，问题就迎刃而解了。而且，优秀的译者通常善于运用各种在线词典、搜索引擎、翻译软件等现代工具，提高自己的效率。在这方面，理科出身的译者相对更有优势，大概与接受科学训练较多有关系。

总的说来，翻译不是许多人想的那样，单纯强调文学艺术天赋，也不太可能被科学的发展所淘汰“译者”，它更像可以通过练习登堂入室的手艺。在技术、艺术、科学三方面较为均衡，没有明显短板的人，只要有兴趣，都有机会成为不错的译者。

待续

Android 4.0设计规范优先导读十大改变（附全文翻译pdf）

Wed, 18 Jan 2012 11:20:23 CST

　　在拜读和翻译了Android design设计指导后，对比Android 4.0与Android2.3及之前版本的app设计指导，总结了Android 4.0设计的10大改变：

1. 导航栏 (详见模式PATTERNS>导航Navigation)
　　由之前的物理按键导航（返回、菜单、搜索、主页）变成了嵌入屏幕的虚拟按键（返回、主页、最近任务）。

　　　　　　　　　　左侧为早期有4个物理按键的手机，右侧为新版只有3个虚拟按钮的手机

　　把菜单项和搜索项从导航栏去掉，把之前通过长按主页键才出现的最近任务直接展示在导航栏中。

　　　　　　　　　　　　　　　　　　　　　　最近任务的界面
　　把菜单收起的同时，在软件界面的操作栏上增加了“更多操作”（action overflow），如下图中的黄色圆点所示。

　　　　　　　　　　黄色圈部分为“更多操作”（action overflow）的位置和点击后内容的展示方式

2. 操作栏 (详见模式PATTERNS>操作栏Action bar)
　　操作栏从之前的app图标＋操作，变成如下图所示：
　　1向上＋2 Spinner＋3 重要操作＋4 更多操作。
　　其中，向上按钮，点击后是去到当前界面的上一个层级，非第一层级界面有此按钮，第一层级界面则无向上按钮；Spinner 是用于展示内容的下拉菜单，其内容包括视图的快速切换和显示相关内容的完整信息；更多操作（action overflow）是集合操作栏中不常用的和非重要操作的地方。

　　操作栏可以拆分成下图中的1主操作栏、2顶部栏和3底部栏。如果需要，顶部栏可以承载选项卡tabs，底部栏可以承载主要操作和被收起的更多操作（action overflow）。

　　在空间足够的横向屏幕展示界面时，被拆分的操作栏，可以灵活合并在一起。如下图中的手机端横竖屏操作栏所示。

3. 多面板布局 (详见模式PATTERNS>多面板布局Multi-pane layouts)
　　多面板布局更多的是针对平板电脑，把手机端的目录视图和详情视图两个层级的界面，甚至更多的页面，复合展示在同一个界面中，有效地利用平板电脑的屏幕空间，扁平化层级结构，简化导航。这点在iPad上已经运用得相当娴熟了。

4. 选择 (详见模式PATTERNS>选择Selection)
　　Android4.0中的长按与Android2.3及更早期的版本有很大的不同。早期版本长按操作后，是出现情境菜单的浮出层。在Android4.0中，长按后在操作栏的位置会覆盖一个临时的情境操作栏，不再弹出情境菜单浮出层。在临时情境操作栏的环境下，当前界面的内容项允许被单个处理，也允许被批量处理。

　　　　　　　　　　长按Android2.3及更早期系统版本的内容项时，出现情境菜单的浮出层。

　　　　　　　　　　长按Android4.0系统版本的内容项时，情境菜单栏覆盖在操作栏上。

　　　　　　　　　　　　　　　　　　在情境菜单环境下，支持批量操作。

5. 返回和向上 (详见模式PATTERNS>返回和向上Navigation with Back and Up)
　　返回按键用在手机全局的虚拟导航栏中，基于用户最近查看的界面历史，采用时间倒序的方式，连接界面间的关系。向上按钮用在操作栏的左侧，基于层级结构，点击后是去到当前界面的上一个层级，若当前界面已经是最高一级，则没有向上按钮。

　　　　　　　　　　黄色部分为点击向上按钮后的页面路径，红色部分为点击返回按钮后的页面路径

6. 主题样式 (详见风格STYLE>主题样式Themes)
　　推出三套默认主题：Holo浅色主题、Holo深色主题、Holo浅色底+深色操作栏主题。主推app在这三套默认主题的基础上做设计，以加快app研发效率，但只是建议使用，并没有完全强制。视觉设计师们可以重点看下STYLE和BUILDING BLOCKS这两章。

7. Widgets (详见开始吧GET STARTED>UI概览UI Overview)
　　在原apps页里，用选项卡tabs的方式增加了widgets内容。一改用隐晦方式添加widget的操作和把widgets零散放在桌面呈现的方式。在app设计中，应该提高对widget设计的重视程度。

8. 兼容性 (详见模式PATTERNS>兼容性Compatibility)
　　向后兼容，考虑到物理导航按键手机如何兼容Android 4.0系统和虚拟导航手机如何兼容Android2.3和更早期版本的apps。

　　在物理导航按键手机上安装android4.0系统，点击物理按键，在屏幕下方出现action overflow的内容。

　　在新的虚拟导航手机上安装为android2.3及更早版本系统设计的app，会在屏幕下方的虚拟导航的右侧出现action overflow按钮（如上图的黄色部分）。

　　在新的虚拟导航手机上安装android4.0，点击action overflow后的展示状态如上图。

9. 强调纯粹的Android应用设计 (详见模式PATTERNS>纯粹的Android)
　　在Android4.0 app设计准则中，特别强调为Android设计纯粹的Android app，切勿使用其他平台特定元素的注意事项，有以下5个方面：
　（1）强调视觉元素的样式要符合android系统；
　（2）不用其它平台特有的图标；
　（3）不在界面的下方使用选项卡tabs；
　（4）区分向上和返回，不在操作栏上使用返回样式的按钮；
　（5）不在内容列表里使用向右箭头。

　　Android系统里，选项卡（tabs）会固定放在屏幕上方，不会放在下方。这点与ios系统不同。

10. 其它细节
　　增加许多新的交互细节、信息展示和视觉样式等规范，详细见翻译。其中，有几点在此强调下：
　（1）新增了横滑移除内容的交互手势。在部分模块中，支持向左或向右横滑移除内容的操作，如最近任务和消息通知抽屉。

　（2）视觉的平面化，栅格风正在4.0中上演。
　（3）在writing style中明确指出写wording时，要直接使用第二人称“你”。

　　原文见 http://developer.android.com/design/index.html
　　快速查阅，Android Design全文翻译下载地址： http://cdc.tencent.com/?download=Android-Design-4.0

　　Android Design全文翻译由CDC D3多媒体小组（江宁、张云）出品。
　　感谢您的阅读！

(本文出自腾讯CDC博客: http://cdc.tencent.com/?p=5082)

20130325早读课：如何设计一个优秀的移动支付流程？

Mon, 25 Mar 2013 07:15:36 CST

推荐理由：译者@名字要够长才霸气咧。有数据显示，用户在移动终端上的消费额与日俱增，而用户在支付过程中得到体验却并不尽如人意。如何设计一个优秀的移动支付流程呢，一起来看看uxdesign上的这篇文章。

越来越多的用户通过智能手机来发现和浏览商品，与此同时，一个更大的问题产生了——这些用户是否愿意在他们的移动设备上完成支付呢？——答案马上揭晓。拿美国为例，2012年在移动电商（m-commerce）上的消费同比增长了81%, 达到了惊人的250亿美元。

而这当中，移动网页端对应用占据了压倒性优势。用户更愿意通过移动端网站来搜索比价，浏览产品，参与促销活动及完成支付。大部分受访者（61%-81%）表示更愿意用浏览器而非原生应用。

在今后的一段时间里，零售商们更加需要通过创建一种无缝的，更加友好可信的支付流程并且充分利用移动设备的优势来推动这种增长。就让我们一起来深入挖掘几个移动支付的例子，看看我们能从中学到什么吧。

1. 只保留重要的输入区域

‘你是从什么途径知道我们的？’，我们已经不止一次地回答过类似的问题了。这些问题可能对供应商有用，但它们对那些真正在你这花着血汗钱，应该真正做主的顾客没有任何价值。

如果说这类问题出现在桌面端，是令人厌烦的；那么它们出现在移动端的话，就一定是致命的。左侧的响应式支付流程，通过删减不必要的信息，只保留重要的部分，成功地将支付过程浓缩为一个精华页面。而右侧则展示了一次简单的支付体验是如何变得臃肿不堪的。页面列出了很多非必填信息，如’Evening Phone’，‘Mobile Phone’，还将地址输入区域分为三个不同部分，而非用一个邮编来代替，而且还要求用户输入两次邮箱地址。

2. 允许非注册用户直接支付

给用户提供一个无需登录注册就能直接支付的选项，本该是理所应当的一件事，尤其是在移动端，然而却有24%的电商网站没有这么做。用户如果需要去创建并验证一个账户，才能完成一个订单，那么他很可能会就此放弃。数据表明，事实就是如此。一个零售巨头声称通过移除‘注册按钮’，销售额提升了3亿美元。

Burton给用户开始支付提供了三种不同的方式：登录，创建一个新账号，直接支付

3. 充分利用移动端UI优势

Fandango有着十分顺畅的支付体验。其中一个重要的原因就是它充分利用了触摸控件在移动端比输入控件对用户更友好的优势。

Fandango的桌面版与移动版

在Fandango的桌面版（左侧）中，用户需要通过下拉框来选择商品数量。而在它的移动端（右侧）中，则采用了更高效的加减选择器（同样还包含了输入框）。

4. 移除干扰信息，而非内容

当用户身处支付流程中时，就已经很显然地表达了付款的意愿。换句话说，此时网站所承担的角色就已经从一个销售者转变为订单填写中心了。考虑到这一点，我们应该移除一切会干扰到用户完成订单的信息。

在Amazon的购物经历，想必已经让你意识到闭环的支付流程有助于提升转化率。通过这一方法，网站会移除包括菜单链接和搜索框在内的，容易导致用户跳出的顶部通用模块。因此，支付页面在移动端可以变得极简。

一旦用户进入 Dillard’s的支付环节，离开页面的唯一方式就点击左上角的logo

像 GNC购物车中的社会化网站链接就不应该出现在购物车中，它们会导致跳出一个内容丰富的支付页面看起来可能不错，但它却常常会打消用户付款的意愿。这并不意味着我们要移除所有的内容。移动端通常需要保留桌面端80%的信息量，且这个指数还在增长。用户可能仍然会对配送方式，退换货政策等信息存有疑问。一个完美的支付流程则应该给他们提供找寻答案的入口。

在 Crate & Barrel’s mobile website中，常用问题都列在了购物车页面底部，允许用户直接查看而不用跳出

5. 显示进度

用户往往会想要知道他们到哪一步了，下一个流程是什么，还要多久才能完成。而进度条的存在有助于缓解这种焦虑。最近的调查显示大部分的电商网站都有展示进度条，虽然其中的大部分都还有待改进。

Under Armour

6. 如无必要，勿增实体

时间就是金钱，移动端尤其如此。74%的移动端用户会直接放弃响应时间超过5秒的网站。用户此时的目的是完成一个操作，而且他们已经确信要这么做了，那么，我们要做的就是为他们开路，扫清一切不必要的障碍。

具体方法请参见“ Seven Guidelines for Designing High-Performance Mobile User Experiences和 Mobitest by Akamai is my choice.”及使用测试工具来优化加载速度。

Tom’s Shoes的移动网站很好地诠释了这一点

7. 提供安全保证

电商网站在移动端给用户带来的最大隐忧之一就是安全问题。想要跨越这个障碍，设计就不应该太过隐晦。开门见山，提供尽可能多的安全保证。这也就是说，需要用图解、SSL安全证书、安全标识等形式来告知体验的安全性。

1-800-Flowers.com通过各种手段来告知用户安全性保障

8. 善用Google Wallet, PayPal 和Amazon

与其让用户一步步填写订单信息，不如用一些像Google Wallet, PayPal和Amazon这样的权威第三方服务来帮助用户尽快完成订单。这样订单信息会被自动填充，而此时，整个支付流程也差不多接近完成了。

Shopify上像 DODOcase这样的移动电商网站，视觉上看起来虽然平淡无奇，但这不是关键。它通过允许用户用第三方应用完成快速支付，消除了页面上的多余噪点。

9. 充分利用地理位置信息和一键呼叫

The Home Depot的移动版允许用户上门自取，通过GPS来查询最近的提货点和库存。巧妙地使用GPS信息来定位用户的地理位置，也是提升网站转化率的一种有效手段。通过在移动端使用一组像 http://maps.google.com/maps?daddr=BEST+BUY&saddr=Current+Location这样的字符串，Google将会自动检索用户的方位，并提供导航。百思买调查发现访问它们移动平台的用户中28%的人，通过使用GPS定位来完成店内购买，这也证明了GPS信息的价值。同样的，通过使用 tel: protocol来允许用户完成一键呼叫，是一种比让用户记下号码更友好的体验。

10. 测试不同的设备和系统

在Chrome上用User Agent Switcher进行测试

做手机网站测试很麻烦也很耗时间，但由于市场上存在着各种各样的操作系统，针对不同的市场份额做优化，并测试不同的分辨率是必要且重要的。能直接用不同操作系统的手机来测是最理想的，但如果这么做有些难度，那么你可以通过使用Firefox或Chrome上一个叫User Agent Switcher的插件来完成测试。它允许你直接在电脑桌面上体验不同的操作系统，能够很好的缩短测试时间。

和操作系统有关的另一个话题就是设计。设计师在设计移动端网站时常犯的一个错误就是从他们选择的操作系统借鉴UI元素。比如，一个使用iOS设备的设计师可能就会使用Apple风格的按钮。这在原生系统中没有任何问题，但移动网页版是一个跨平台和浏览器的应用，在其他系统中可能就看不到这些原生应用的效果，甚至可能会看起来更糟。

总结

在此之前，移动端支付流程体验的优劣并没有对网站收入有着如此深远的影响。如果零售商们在认清了上述移动端体验的优势和劣势之后能够给用户提供一个更加清晰，简明，轻巧的路径来帮助用户完成支付，那么，大家都将受益无穷。

Via：原文出处译者博客译者 投稿“互联网er的早读课”，转载请艾特作者并注明出处。

如果看到这段文字，证明您已经看完这篇文章了，有什么收获有什么感想有什么不赞同，我们期待您的留言评论，并诚挚邀请您加入“互联网er早读课”QQ群，一同交流每天文章的心得并结识同行。官方2群：74447564，加群密码“职业信息+城市+姓名”，否则不予通过，入群后请修改群名片。注：官方QQ群非水群，喜欢闲聊的童鞋请勿加入。再次感谢您对早读课网站的支持。

我们猜您可能也喜欢：
20130320早读课：三大移动平台上的交互设计差异	20130314早读课：Justinmind，为移动设计而生	20130228早读课：为移动而设计，也谈信息的架构	20130225早读课：如何设计优秀的登录框？	20130323早读课：Fuubo---优秀以上，完美甚远
无觅

20130426早读课：一例email创新设计案例分享

Fri, 26 Apr 2013 07:15:39 CST

推荐理由：诞生多年的email由于自身的产品特点一直生命力旺盛，现在仍然是电商等互联网新势力仍然在使用EDM作为推广渠道之一。但当我们在推荐算法、情感化营销方面在 email上花尽心思时，是否还有什么被我们忘记了？一起来看看这篇文章吧。

回想起在Netscape Navigator 4和Internet Explorer 5上使用HTML email工作的日志真的太不平凡了。那渲染引擎的质量完全不一致的，更现代的开发技术都不可用，技术是图像——一个大多数email的基本元素——在大多数客户端上都默认地关闭了。这感觉起来想1998年，但是web开发社区从那时起学到很多东西。像渐进增强的策略和像Litmus的现代工具能够帮助我们构建HTML email适合现今各种各样的桌面客户端，大量的web客户端，tablets，只能手机和更先进的显示设备。

上个月我决定开始发送教育email到新的 Beanstalk客户来帮助他们熟悉我们的新功能。这计划要发送在三个互相之间有一些间隔的email。在设计完这些email之后，我决定解析下我的过程以及过一下我用到的工具和技术。

布局工作

我们决定每封教育email会由我们团队里的一个成员编写。Chris，Beanstalk的创始人，写了关于开发的，Ilya，我们的核心开发者之一，介绍客户先进的工具，同时Russ，我们的系统工程学，介绍我们关于安全的方式。

我开始有一个简单的设计，但不是很满意：

由我们团队成员编写的邮件是面向个人的，但设计没有反应出这个。它开起来就像一封企业的邮件，而不是由个人来写的邮件。所以我们决定把作者放在前面位置的同时仍然保留引用Beanstalk，同时元数据是非常适合的位置来放这些信息：

现在它就很清晰的表达了email是来自Beanstalk的，我还简化了界面，加入了作者的图片和移除了logo：

这个外观和感觉就更像写在产品信纸上的私人信件而不是一个公司手册——我更想要的结果。

为email增加响应

为了找出哪个email客户端在我们的用户里最流行，我检查了 Campaign Monitor从我们最新的时事通讯里统计的数据。结果非常明显，但对于如Beanstalk的极客产品不算太让人惊讶——30%使用Apple Mail，23%用iPhone，19%用Gmail，6%是Sparrow，5%的iPad，3%的Android以及剩下的14%涵盖了其他各类的客户端。这意味着我们的三分之一收件人使用小屏幕设备同时我们的email可能对于他们来说可读性不强。

在普通外观我们的文本列宽度设置为600像素，这限制了每行字符数大于是85-90个——对于良好可读性的一个上限值。我开始加入@media来程序那些小于780像素的屏幕，用来允许在文本周围的一些空白和绿色边框：

@media only screen and (max-width: 780px) {
    div[class="bs-email"] {
        padding-right: 20px !important;
        padding-left:  20px !important;
    }
    div[class="bs-email"] .bs-wrap {
        width: 100% !important;
    }
    div[class="bs-email"] .bs-content img {
        max-width: 100% !important;
        height: auto !important;
    }
    ...
}

这里我减少了文本周围的空白，让文本列和图片能够占用所有可用的空间，同时把发送者的图片移进列里面：

下一步是像智能手机一样的小屏幕。我在第一个后面加入了@media查询max-width：380px的，这里我更多地减少空白，移除email周围的绿色边框，同时设置更小的行高度来让屏幕显示更多内容：

在基于旧式表格布局的email里使用@media 查询对我来说还是不太现实，但是它们确实在新设备里得到很好的支持并且在旧客户端也能够被忽略。我能够想到的唯一特殊情况是Yahoo! Mail，它本身忽略@media声明而把所有包含的风格应用到你的标准视图。我使用类似div[class="className"]或者h1[id="unique"]的属性选择器来修复这个问题，但也被忽略了。谈到hack，我并不推荐使用 HTML Email Boilerplate作为email编码的起点——它是一个变通方案和在主要客户端的渲染问题修复的大集合。

适配高分辨率显示设备

人们在使用IPhones，IPads和Android设备收发email时有什么共同点？很多人会使用类似于苹果电脑的retina显示屏。由于大家往往使用龟速并且昂贵的3G网络，在email中添加高分辨率图片是行不通的，而且没有人愿意花一分钟时间去加载email。

我最初是使用div代替img元素，并且使用默认图片作为背景图。只有在真正需要的时候才会使用@media提供高分辨率的版本。不论从哪个角度来说，这都是不科学的。当图片不能显示的时候，它不会提供文本替换。并且一些比较旧的客户端不显示背景图，更糟糕的是Gmail和一些不支持@media的客户端会在高清设备上显示默认背景图，比如使用retina屏的MacBook Pro。

我最后决定使用的最简单的方法就是把所有的图片最大化处理两次，然后使用img元素的width和height属性对图片进行裁剪。我经常使用 ImageOptim and ImageAlpha将图片和截图进行最大化压缩，有时也会用 overcompressed JPEG代替PNG格式，一封含有3-5张大图的邮件大小会在100-150K左右，虽然有点大，但是还不是太糟糕。特别是我们在设计过程中没有使用图片资源（除了地步的LOGO），图片也只会在几段文字之后才会显示出来。

测试电子邮件

所有的测试都是从发送HTML格式的邮件开始，但是它不像听起来那么简单。首先，你要把所有的图片和资源存储起来以便从HTML中调用，其次，你要把你的HTML文件转化为email来发送。一种方法是在Campaign Monitor 或者 MailChimp创建一个免费的账户，然后将你的邮件预览发送到你的邮箱地址——这个方法可行，但是在处理的会后会有一点慢。我新的选择是最近发现的一个Mac上的软件— Direct Mail ，它的免费版每月可以支持多达50封邮件，它设计精美并且运行完美。

Litmus是我的另一个喜欢的软件。我之前调查过，但是把它用作测试和基于屏幕截图的调试时不行的，所以我经常维护我自己的邮件客户端和账户库，当他们发行 Interactive Testing的时候是事情发生了改变，它允许你进行测试、调试、和实时预览。并不是他们库中所有的客户端都有这个工具，但是即使这有限的选择也为我节省了大量的时间。

收集数据

我所冒的风险就像一个Litmus的推进者，但是在我们的电子邮件事务中我们第一次使用的特色功能和最爱是 Litmus Analytics，我们为我们发送的每种类型的邮件都添加了唯一的追踪码，所以现在我们有我们的所发送邮件的接受者反馈的可靠数据，收集这些数据的方式是一种魔法，但是我们看到了约定的报告，电子邮件客户端的统计数字，甚至转发的数量都是真的被准许的！使用我们手上的真实数据，我们可以看到哪个邮件是我们用户最喜欢的，这个因此改变了我们的交流方式。

Via：原文出处翻译： oschina

延伸阅读： 20130210早读课：情感交互，移动应用产品交互趋势

我们猜您可能也喜欢：
20121204早读课：我待用户如初恋---22个产品设计创新案例分享	20130311早读课：从错误里汲取经验，一款产品设计案例分享	20121211早读课：那些产品设计时犯过的错误---一个iPhone应用设计案例分享	20121117早读课：应用设计的创新，“下拉刷新”的彩蛋	20121123早读课：交互的创新，对手势设计的思考
无觅

云计算架构Hadoop：从小象变大象的发展历程

Wed, 13 Jun 2012 18:40:19 CST

由于具备低成本和前所未有的高扩展性，Hadoop已被公认为是新一代的大数据处理平台。就像30年前SQL（Structured Query Language）出现一样，Hadoop正带来了新一轮的数据革命。如今Hadoop已从初出茅庐的小象变成了行业的巨人，但Hadoop仍需继续完善。

基于Java语言构建的Hadoop框架实际上一种分布式处理大数据平台，其包括软件和众多子项目。在近十年中Hadoop已成为大数据革命的中心。MapReduce作为Hadoop的核心是一种处理大型及超大型数据集（TB级别的数据。包括网络点击产生的流数据、日志文件、社交网络等所带来的数据）并生成相关的执行的编程模型。其主要思想是从函数式编程语言借鉴而来的，同时也包含了从矢量编程语言借鉴的特性。

互联网巨头Yahoo！作为Hadoop框架的先驱研究者，在6年时间已经将Hadoop塑造成了极为成功的技术。但相比于SQL，Hadoop在某些方面仍然显得不够完善。这直接导致现今所有目光都集中在Hadoop供应商的身上。包括Amazon、Cloudera等公司带来众多的创新并提供强大的工具。Cloudera推出的CHD3包含众多的附加软件，可以帮助管理、运行Hadoop上的复杂任务，例如：Apache Mahout、Flume、Sqoop、Pig、Oozie、Hive、HBase、ZooKeeper、Whirr等。同时Cloudera也是目前最大的提供企业Hadoop技术支持和培训的厂商。而Amazon是较早在公共云中运行Hadoop的公司，其提供的基于MapReduce的弹性计算可提供海量的数据计算服务。

但数据处理只是大数据处理的一部分，组织最终想要得到的是经过分析后的有价值的数据。商业智能和数据分析厂商如Datameer、Hadapt以及Karmasphere就显的不可或缺。

Hadoop在2011年证明自身的价值，最明显的迹象就是五大数据库管理软件供应商EMC、IBM、Informatica、Microsoft以及Oracle都投入了Hadoop的怀抱。EMC与MapR展开合作，而Microsoft和Oracle则分别与Hortonworks和Cloudera展开了合作。而EMC和Oracle已经推出了Hadoop专有设备。下面就让我们来看一下Hadoop在大数据领域都俘虏了那些公司的心。

Amazon基于MapReduce的服务

Amazon早在2009年就推出了基于Hadoop MapReduce的EC2（Elastic Compute Cloud）服务。因此Amazon在应对用户应用和需求上显得胸有成竹。无论是中小型企业还是超大型的组织，基于MapReduce的EC2服务都经受住了考验。同时AWS（Amazon Web Service）还包括Amazon S3（Simple storage Service）。Amazon S3可提供高伸缩性、靠可靠性、高可用性以及极低的存储成本。利用AWS可高效的处理数据密集型的任务，如Web索引、数据挖掘、日志文件分析、机器学习以及科技和生物信息的学术研究。

Cloudera提供安全的Hadoop平台

Cloudera也是比较早的大规模Hadoop软件和服务提供商。Cloudera一直专注于将开源的Apache Hadoop完善成可靠的平台。Cloudera目前拥有100多家客户，并且在本月还与Oracle展开合作，共同进军大数据领域。

在Cloudera提供了用于管理大数据的管理控制台和负责管理Hadoop部署的工具以及企业级的支持。Cloudera的管理工具提供基于向导式的Hadoop安装和配置菜单。同时提供相应的工具，以帮助系统管理员监控平台的健康状况、诊断问题、优化性能，并进行所需的配置和安全变更。而Cloudera的企业级支持与服务包括配置检查、升级和与第三方系统集成以及其他技术资源。现今Cloudera管理软件现在的价格是每节点每年4000美元（不包括硬件）。

Datameer将大数据与商业智能有机结合

Datameer宣称其公司基于Hadoop平台的产品方案DAS（Datameer Analytics Solution）非常适用于商业智能（BI）。Datameer可通过JDBC、Hive、Http连接任何的数据源。同时包括一个向导驱动集成平台，可安排负载并从任何结构化、半结构化和非结构化的大数据集。Datameer的大数据分析解决方案通过表格接口整合Hadoop的数据挖掘能力。并通过REST API在私有云和公共云中输入和输出数据。

EMC的统一数据分析平台

EMC推出用于支持大数据分析的平台――EMC Greenplum统一分析平台(UAP)。Greenplum UAP是一个唯一的统一数据分析平台，可扩展至其他工具，其独特之处在于，它将对大数据的认知和分享贯穿整个分析过程，实现比以往更高的商业价值。UAP包括EMC Greenplum 关系数据库、EMC Greenplum HD Hadoop以及EMC Greenplum Chorus。UAP就好比一个数据分析团队，包括了从数据科学家和BI分析师到DBA和在线商业用户和管理者。EMC针对硬件设备DCA（Data Computing Appliance），其足以运行EMC Greenplum 关系数据库和EMC Greenplum HD节点。DCA提供控制管理界面，方便管理人员监视、管理Greenplum数据库和Hadoop系统性能。

Hadapt与Hadoop环境无缝集成

Hive作为运行在Hadoop上的数据仓库组件并不像Hadoop那样受人关注。而Hadapt则提供集众多功能于一身的数据分析环境，旨在处理存在于Hadoop和SQL环境中传统结构化的数据。Hadapt平台可运行在私有云和公共云之上，并提供从一个环境访问数据的能力。包括现有基于SQL的工具以及MapReduce处理和大数据分析。Hadapt自动分开执行Hadoop和关系数据库之间的查询，处分利用了Hadoop的高扩展性和关系数据库的高速性。

Hortonworks继承Yahoo！ Hadoop衣钵

Yahoo!在去年剥离了Hadoop业务，并与硅谷风投公司Benchmark Capital合资组建一家名为Hortonworks的公司。新公司包含在Yahoo！贡献最大的50名工程师，旨在继续推动Hadoop的发展。Hortonworks高管断言这支以Yahoo!开发团队为班底的公司将会贡献更多的Hadoop代码，并指引Hadoop平台未来的发展。Hortonworks已在去年10月与微软成为合作伙伴关系。Hortonworks可帮助Microsoft推出Windows平台之上的Hadoop。Hortonworks在去年11月也推出了自由的HDP（Hortonworks Data Platform）V1，而结合了最新0.23版Hadoop的HDP V2将在2012年第一季度推出。Hortonworks还提供Hadoop的培训与支持，加强在这方面与Cloudera和MapR的竞争。

IBM的Hadoop之路

IBM在多年以前就开始研究Hadoop。现今IBM提供基于云服务的海量数据分析方面多种方案的选择，但目前IBM的策略似乎主要是围绕Hadoop在发展。IBM在4月推出了其SmartCloud云计算平台。并承诺改善Hadoop工作负载。IBM提供了基于Hadoop的InfoSphere BigInsights（IBM InfoSphere BigInsights是用于分析和虚拟化海量数据的软件和服务，这款新产品由 Apache Hadoop 提供技术支持。）基本版和企业版。 InfoSphere BigInsights之前作为IBM测试和开发的云产品，现在被SmartCloud取代。

Informatica 向云更进一步

大多数的数据管理软件供应商（如IBM、Oracle、Syncsort、Talend）都涉及到Hadoop。Informatica在去年10月也推出了Hadoop环境下的数据编译转换解决方案――HParser。

该方案可以运行在几乎所有的Apache Hadoop分布式环境中，与MapReduce架构平行，能高效率地把无结构的复杂数据――诸如网络记录、社交媒体数据、通话详细记录以及其他数据格式――转换为Hadoop中结构或半结构格式。当把数据转化为更具结构性的格式后，便可以得到更快速的使用和生效，从而驱动业务发展、提高运营效率。

Karmasphere Hadoop数据分析利器

Karmasphere提供了直接访问Hadoop中结构化和非结构化数据以及进一步分析查询的特性，同时Karmasphere还提供的可视化工作空间。Karmasphere提供的可视化工具提供了SQL或其他特定查询语言分析位于Amazon S3、工作流以及本地文件系统上的结构化和非结构数据的特性。企业还可以使用数据库或相关工具（例如Excel）来提取分析得出的数据。

MapR带来更高性能的Hadoop

MapR在Hadoop的舞台上显得格外耀眼，其提供Hadoop非常独特。MapR基于开源Hadoop，在只需有限硬件的环境中提供更快的Hadoop。同时Mapr配备了快照，并号称不会出现SPOF单节点故障，且被认为是与现有HDFS的API兼容。因此非常容易替换原有的系统。MapR最新的0.23版解决许多开源Hadoop的缺陷。而MapR与EMC的合作体现在了EMC Greenplum HD Enterprise Edition上，其就是基于MapR M5构建的。

Microsoft全面拥抱Hadoop

当EMC、IBM、Oracle都在2011年涉及Hadoop时，Microsoft全面拥抱Hadoop的举动就显得不足为奇了。而Hadoop的Windows Server将在在2012年推出，届时其还会与微软现有的BI工具联合处理任务。去年微软表示推出Windows Azure上的Hadoop预览版，微软还使Hadoop的数据通过部署在基于云的Windows Azure获取。并使其能够与企业的商业智能工具一起分析数据。微软目前正与Hortonworks合作旨在努力简化下载、安装和配置等几个Hadoop的相关技术。包括HDFS、Hive、Pig。这将有利于企业通过Hadoop拓宽自身的业务。微软将编写新的ODBC驱动程序并扩展自己现有的查询系统到Hive。这样一来用户将能够直接从Excel、PowerView执行Hadoop查询。

Oracle进军云计算

Oracle在2011 Oracle全球大会上宣布推出了Oracle Big Data Appliance。Big Data Appliance是一个集成了Hadoop、NoSQL Database、Oracle数据库Hadoop适配器、Oracle数据库Hadoop装载器及R语言的系统。Oracle还在今年1月与Cloudera成为合作伙伴关系。Oracle现已将Cloudera Distribution Including Apache Hadoop（CDH）和Cloudera Manager集成到Oracle大数据机之中。Oracle也将利用Cloudera在Hadoop领域的专业知识提供培训及咨询业务。Oracle大数据机中运行了Oracle Linux操作系统，1个机架中包含18个Oracle-Sun服务器，共计216个核心，同时具备864GB的内存和648TB的存储能力，其售价为45万美元。（李智/编译）

原文链接： informationweek

翻译：http://cloud.csdn.net/a/20120203/311398.html

20世纪最牛逼的10大算法

Thu, 03 May 2012 16:09:13 CST

译者：July 二零一一年一月十日

————————————

参考论文：
The Best of the 20th Century: Editors Name Top 10 Algorithms。
By Barry A. Cipra。地址： http://www.uta.edu/faculty/rcli/TopTen/topten.pdf。

博主说明:
1、此20世纪的十大算法，除了 快速排序算法，或者快速 傅里叶变换算法，其它算法只要稍作了解即可。
2、此文非最新文章，只是本人对算法比较感兴趣，所以也做翻译，学习研究下。
===============================

发明十大算法的其中几位算法大师

一、1946 蒙特卡洛方法

[1946: John von Neumann, Stan Ulam, and Nick Metropolis, all at the Los Alamos Scientific Laboratory, cook up the Metropolis algorithm, also known as the Monte Carlo method.]

1946年，美国拉斯阿莫斯国家实验室的三位科学家John von Neumann,Stan Ulam 和 Nick Metropolis
共同发明，被称为蒙特卡洛方法。

它的具体定义是：
在广场上画一个边长一米的正方形，在正方形内部随意用粉笔画一个不规则的形状，
现在要计算这个不规则图形的面积，怎么计算列?
蒙特卡洛(Monte Carlo)方法告诉我们，均匀的向该正方形内撒N（N 是一个很大的自然数）个黄豆，
随后数数有多少个黄豆在这个不规则几何形状内部，比如说有M个，
那么，这个奇怪形状的面积便近似于M/N，N越大，算出来的值便越精确。
在这里我们要假定豆子都在一个平面上，相互之间没有重叠。(撒黄豆只是一个比喻。)

蒙特卡洛方法可用于近似计算圆周率：
让计算机每次随机生成两个0到1之间的数，看这两个实数是否在单位圆内。
生成一系列随机点，统计单位圆内的点数与总点数，内接圆面积和正方形面积之比为PI:4，PI为圆周率。

(多谢网友七里河蠢才指出:S内接圆：S正=PI：4。具体，请看文下第99条评论。 十六日修正)，

当随机点取得越多（但即使取10的9次方个随机点时，其结果也仅在前4位与圆周率吻合）时，
其结果越接近于圆周率。

二、1947 单纯形法

[1947: George Dantzig, at the RAND Corporation, creates the simplex method for linear programming.]

1947年，兰德公司的，Grorge Dantzig，发明了单纯形方法。
单纯形法，此后成为了线性规划学科的重要基石。
所谓线性规划，简单的说，就是给定一组线性（所有变量都是一次幂）约束条件
（例如a1*x1+b1*x2+c1*x3>0)，求一个给定的目标函数的极值。

这么说似乎也太太太抽象了，但在现实中能派上用场的例子可不罕见——比如对于一个公司而言，其能够投入生产的人力物力有限（“线性约束条件”），而公司的目标是利润最大化（“目标函数取最大值”），看，线性规划并不抽象吧！

线性规划作为运筹学(operation research)的一部分，成为管理科学领域的一种重要工具。
而Dantzig提出的单纯形法便是求解类似线性规划问题的一个极其有效的方法。

三、1950 Krylov子空间迭代法

[1950: Magnus Hestenes, Eduard Stiefel, and Cornelius Lanczos, all from the Institute for Numerical Analysis at the National Bureau of Standards, initiate the development of Krylov subspace iteration methods.]

1950年：美国国家标准局数值分析研究所的，马格努斯Hestenes，爱德华施蒂费尔和
科尼利厄斯的Lanczos，发明了Krylov子空间迭代法。

Krylov子空间迭代法是用来求解形如Ax=b 的方程，A是一个n*n 的矩阵，当n充分大时，直接计算变得非常

困难，而Krylov方法则巧妙地将其变为Kxi+1=Kxi+b-Axi的迭代形式来求解。
这里的K(来源于作者俄国人Nikolai Krylov姓氏的首字母)是一个构造出来的接近于A的矩阵，
而迭代形式的算法的妙处在于，它将复杂问题化简为阶段性的易于计算的子步骤。

四、1951 矩阵计算的分解方法

[1951: Alston Householder of Oak Ridge National Laboratory formalizes the decompositional approach to matrix computations.]

1951年，阿尔斯通橡树岭国家实验室的Alston Householder提出，矩阵计算的分解方法。

这个算法证明了任何矩阵都可以分解为三角、对角、正交和其他特殊形式的矩阵，
该算法的意义使得开发灵活的矩阵计算软件包成为可能。

五、1957 优化的Fortran编译器

[1957: John Backus leads a team at IBM in developing the Fortran optimizing compiler.]

1957年：约翰巴库斯领导开发的IBM的团队，创造了Fortran优化编译器。

Fortran，亦译为福传，是由Formula Translation两个字所组合而成，意思是“公式翻译”。
它是世界上第一个被正式采用并流传至今的高级编程语言。
这个语言现在，已经发展到了，Fortran 2008，并为人们所熟知。

六、1959-61 计算矩阵特征值的QR算法

[1959–61: J.G.F. Francis of Ferranti Ltd, London, finds a stable method for computing

eigenvalues, known as the QR algorithm.]

1959-61：伦敦费伦蒂有限公司的J.G.F. Francis，找到了一种稳定的特征值的计算方法，
这就是著名的QR算法。

这也是一个和线性代数有关的算法，学过线性代数的应该记得“矩阵的特征值”，计算特征值是矩阵计算的

最核心内容之一，传统的求解方案涉及到高次方程求根，当问题规模大的时候十分困难。

QR算法把矩阵分解成一个正交矩阵(希望读此文的你，知道什么是正交矩阵。:D。)与一个上三角矩阵的积，

和前面提到的Krylov 方法类似，这又是一个迭代算法，它把复杂的高次方程求根问题化简为阶段性的易于

计算的子步骤，使得用计算机求解大规模矩阵特征值成为可能。
这个算法的作者是来自英国伦敦的J.G.F. Francis。

七、1962 快速排序算法

[1962: Tony Hoare of Elliott Brothers, Ltd., London, presents Quicksort.]
1962年：伦敦的，托尼埃利奥特兄弟有限公司，霍尔提出了快速排序。

哈哈，恭喜你，终于看到了可能是你第一个比较熟悉的算法~。
快速排序算法作为排序算法中的经典算法，它被应用的影子随处可见。

快速排序算法最早由Tony Hoare爵士设计，它的基本思想是将待排序列分为两半，
左边的一半总是“小的”，右边的一半总是“大的”，这一过程不断递归持续下去，直到整个序列有序。
说起这位Tony Hoare爵士，快速排序算法其实只是他不经意间的小小发现而已，他对于计算机贡献主要包括

形式化方法理论，以及ALGOL60 编程语言的发明等，他也因这些成就获得1980 年图灵奖。

快速排序的平均时间复杂度仅仅为O(Nlog(N))，相比于普通选择排序和冒泡排序等而言，
实在是历史性的创举。

八、1965 快速傅立叶变换

[1965: James Cooley of the IBM T.J. Watson Research Center and John Tukey of Princeton
University and AT&T Bell Laboratories unveil the fast Fourier transform.]

1965年：IBM 华生研究院的James Cooley，和普林斯顿大学的John Tukey，
AT＆T贝尔实验室共同推出了快速傅立叶变换。

快速傅立叶算法是离散傅立叶算法（这可是数字信号处理的基石）的一种快速算法，其时间复杂度仅为O

(Nlog(N))；比时间效率更为重要的是，快速傅立叶算法非常容易用硬件实现，因此它在电子技术领域得到

极其广泛的应用。

日后，我会在我的 经典算法研究系列，着重阐述此算法。

九、1977 整数关系探测算法

[1977: Helaman Ferguson and Rodney Forcade of Brigham Young University advance an integer

relation detection algorithm.]
1977年：Helaman Ferguson和伯明翰大学的Rodney Forcade，提出了Forcade检测算法的整数关系。

整数关系探测是个古老的问题，其历史甚至可以追溯到欧几里德的时代。具体的说:
给定—组实数X1,X2,…,Xn，是否存在不全为零的整数a1,a2,…an，使得:a1 x 1 +a2 x2 + . . . + an x

n ＝0?
这一年BrighamYoung大学的Helaman Ferguson 和Rodney Forcade解决了这一问题。
该算法应用于“简化量子场论中的Feynman图的计算”。ok，它并不要你懂，了解即可。:D。

十、1987 快速多极算法

[1987: Leslie Greengard and Vladimir Rokhlin of Yale University invent the fast multipole

algorithm.]

1987年：Greengard，和耶鲁大学的Rokhlin发明了快速多极算法。

此快速多极算法用来计算“经由引力或静电力相互作用的N 个粒子运动的精确计算
——例如银河系中的星体，或者蛋白质中的原子间的相互作用”。ok，了解即可。

有任何意见和问题，欢迎博客上留言或评论。

完。
——————————————————————————

此文于二零一一年一月二十日，上了CSDN头版头条

CSDN 首页 > 软件研发频道 > Web开发频道 > 正文（一月十二日）：

http://sd.csdn.net/a/20110112/289993.html

作者声明：
本人July对本博客所有文章和资料享有版权，转载或引用任何文章、资料请注明出处。
谢谢。July、二零一一年一月十日。

转自：http://blog.csdn.net/v_july_v/article/details/6127953

新一代海量数据架构分析：NoHadoop

Fri, 30 Mar 2012 11:59:57 CST

在经历了长达25年的统治地位后，关系型数据库正面临越来越火的“NoSQL”挑战，而挑战者是以Hadoop为代表的分布式计算开源架构。可以看到，越来越多的消息表明，不管NoSQL是被解释为“No SQL”还是“Not Only SQL”，如果你面临海量数据的挑战，那么你最应该选的海量数据架构是Hadoop。

但是Hadoop就能代表一切吗？答案显然是否定的，Hadoop的MapReduce在性能上的确是有局限性的：比如MapReduce没有索引，只有靠强大的运算能力来处理；此外，MapReduce本身存在一些lower-level实现的问题, 特别是skew和数据交换等等。

因此有些人开始回到关系型数据库上，因为相比较Hadoop的处理能力，一些SQL架构依然呈现数量级的优势。

也许，我们现在正处于一个新的“NoHadoop”时代，因为越来越多的企业开始认识到，海量数据处理仅有Hadoop是不够的。在他们看来，简单的批处理工具比如MapReduce和Hadoop恐怕并不足以应付将来更大的数据结构。诚然，大多数的比较复杂的海量数据处理我们也许能够用Hadoop就足以对付——也许更多的是一个无奈选择。它们可能涉及更复杂的连接，比如ACID需求、实时要求、超级计算的算法、图形计算、互动分析或者连续增量的需求等等。

事实上，Hadoop之所以受到越来越多的人欢迎，原因在于它对于海量数据的处理方式，而且，最重要的是，它是免费的。

但是随着对海量数据处理的应用程序性能需求不断增加，我们会发现，在很多领域，我们需要除了Hadoop以外的更多的海量数据处理方式。

那么，我们应该怎样看待下一代分布式计算架构呢？或者说，“NoHadoop”的架构应该是怎样的呢？从性能上而言，下一代的架构需要在MapReduce/Hadoop的基础上有10——10000倍的性能提高。

在每一种应用下，都有新一代的数据架构，可以提供所需的规模和效能。在未来的几年内，这些架构中的某些也许会成为主流。

1、SQL：数据库已经有了25年的发展历史。大量的创新正在围绕数据库技术，比如VoltDB、Clustrix等等（也许下一代产品不应该再称为数据库），但当你需要处理复杂的连接，或需要ACID需求时，数据库依然是你最好的选择。

应用场景：复杂的业务查询、在线交易处理。

2、Cloudscale：在海量数据上的实时分析，它打破了自由批量处理的限制。比如，当你打算分析一台百万次的服务器中发生的事件流，你需要一个真正的实时数据流体系结构。而Cloudscale架构提供的这种实时数据分析能力，比Hadoop的批处理系统快了近10000倍。

应用场景：商业算法，欺诈检测，手机广告、位置服务、市场情报。

3、MPI和BSP：相当多的超级计算机应用中，需要在海量数据上建立复杂的算法，为了实现规模效应，需要对处理器的直接访问调用以提高计算的速度。在并行计算中，MPI和BSP这些工具是进行高性能计算的必要。

应用场景：建模与仿真系统，流体动力学。

4、Pregel：当你需要分析一个复杂的社交网，或者是要分析网络的时候，面对的不是数据的问题，而是一个很大的图形。我们面临的现状是，大规模的动态图形正成为一些应用的关键。Google的Pregel结构采用了BSP模型，以便能够进行规模化、高效的图形计算。

应用场景：算法，算法的结构图，地理位置图，网络优化等

5、Dremel：这是一个需要与网络进行大规模交互的数据集。Google的Dremel的设计原理在于支持几秒内万亿行命令的执行，并提供即时查询。而它的查询执行并没有采用MapReduce 的功能。自从2006年以来Dremel诞生以来，已经有了成千上万的用户。

应用场景：数据搜索、客户支持、数据中心监控。

6、Percolator (Caffeine) ：如果需要对庞大的数据增量进行不断更新，你会发现，Percolator是一种很好的实现方式，这也是Google在新的索引系统上采用的架构，Google的即时搜索引擎Instant不能没有它。“由于索引内容可以逐步增加，采用以Percolator的Google Caffeine系统检索速度将百倍于之前采用Hadoop的分布式数据处理方式。”

应用场景：实时搜索

原文链接：http://www.sys-con.com/node/1573226

作者简介：Bill McColl：Cloudscale创始人和首席执行官，牛津大学计算科学系主任，负责并行计算研究中心。

CSDN编译

观点：不要太依赖JavaScript库

Thu, 29 Mar 2012 12:08:02 CST

by zhangxinxu from http://www.zhangxinxu.com
本文地址： http://www.zhangxinxu.com/wordpress/?p=2314

本文翻译自Ross Bruniges 3月21号写的 Don’t rely too much on JavaScript libraries一文。

下面就来看看为何Ross Bruniges说不要过分依赖JavaScript库~~

库是很棒的东西，但千万不要因此让你JavaScript的学习打折扣。 – by 开发者Ross Bruniges

JavaScript库已经成为了一个web开发人员的工具包的重要组成部分，一个很好的理由（zxx: 应指指依赖理由）。库让每个浏览器的JavaScript实现无差异，使开发人员可以专注于编写代码，10次中有9次将只是工作 – 这是一个了不起的事情。

但你可曾停下来想过学习JavaScript，而不是一切都依靠库？尽管我不主张离开库，但我依然要给你些东西让你去思考，以及可能会让您更上一层楼的 JavaScript权威指南。

1. 库库也会尿裤裆，知识在手莫惊慌

每个开发者都怕怕的事情之一就是一些你依赖的东西不顶用了（zxx: 应指冲突之类）。这可能是个核心的库函数或是插件，而这两个都是你迫切需要的（用来修复某些问题）。

库提供了很好的抽象层于浏览器的各种差异之上，但是，“引擎盖”下面，它们仅仅就是JavaScript, 因此，一点点的基础知识就可以让你开始明白大致哪里出了问题。即使你无法自己修正该错误，你还可以高亮错误的位置然后反馈给（编写该）库的核心团队。

2. 坏坏代码难免有，越早发现越好走

如果你使用允许社区插件（zxx：指论坛之类的些杂碎插件）的库（zxx: 如jQuery, 鱼龙混杂太多），您可能已经遇到了一个不得不从你项目上咔嚓掉的糟糕插件，或者你花了大量时间试图让其工作。能够注意到一种可能会造成性能问题的模式就意味着站点上线后是愉悦的还是让人不爽的客户端。

3. 买爱疯，宁换肾；需不需要先自问？

根据你要求的功能，你需要的代码可能不需要库。例如，你只是做一些简单的dom操作，值得你一试。

页面的大小和性能是web上重要因素，一个JavaScript的大小20K ~ 80K大小不等。在高度连接的桌面设备上，80Kb不算多。但是，如果你的站点是针对手机用户的，则越轻量越好。我最近推出了一个CSS动画可用时只需要JavaScript的站点。

我决定我并不需要的库所提供的援助之手，因为我只要处理一个浏览器JavaScript实现。最终，JavaScript的总大小约2KB。

4. 国际油价要接轨，技术俱进抱大腿

JavaScript是一个不断发展的语言，我们现在身处一个全新的世界，远远超出我们认为可用的能力的范围。你可以在Server端使用 node.js, 你可以通过app访问地理位置信息。HTML5提供了新的APIs，可用于控制嵌入式多媒体，信息存储，并确定你的用户是否在线。

因为我们正在谈论有关新技术和开发技术，文档目前的水平是能够在传统深入和密集API文档中发现所需。了解JavaScript对于你研究这些你想使用的功能会是一个巨大的帮助。许多网上例子不使用库，有助于你能够从最底层准确了解发生了什么。

学习资源

那么，我所说的这些对你有所触动了吗？如果是这样，开始学习的最佳之地就是你使用的JS库，在 code.google.com/apis/library上有非压缩版本，而且我推荐你从最新的版本入手。

如果你遇到什么不懂的，可以去 Mozilla MDC（zxx:MDC指Mozilla Developer Center, 类似于国内蓝色理想）寻求解释。如果你寻找HTML5提供的可能示例， html5demos.com满是精彩而又简单的例子。

——— 以上就是翻译内容了 ———

译者现身说法

是不是感觉作者说得有点淡，一股忧郁的无力吐槽的感觉。无法让那些依赖库完成一些功能的泛泛之辈们引起重视，因此，末了，我也一舒己见。

首先，作者的观点我都是赞同的，但是在托辞与表达上过于苍白无力，无法发人深省，看了只会让人打瞌睡。

如果你认定了前端这条路，依赖JavaScript库只会让你日后成为一个悲催的前端人员：工资涨不上，新技术跟不上，混迹于各个公司间，妄图有所发展，结果都是平淡收场，虽说铁定饿不死，但是而立之年的人生压力会让你觉得混得真是惨淡。这些都是可以预见的。

在中国，从事所谓前端之人何其多也，可以依赖JavaScript库实现功能的人何其多也，比牛魔王身上的虱子还要多。时间流逝，就凭抱着JS库过日子，你怎么可能从这么多人之间脱颖而出（当然你爸姓李或有干爹另当别论）。

正如Ross Bruniges所说的，如果JS库报错或是插件冲突了，你晓得症结在哪里吗？好不容易从哪搞来个插件，效果实现了，一上线，尼玛IE6下老是爆掉，你知道什么原因吗？手机页面，没有JS库你能搞定里面的交互吗？你能读懂node.js代码吗？你能读懂HTML5 APIs文档中的JS示例代码吗？如果不能，你永远就是在别人手下干活，按部就班做事的命，这东西不是钓鱼，靠经验积累就行的。你必须好好学习原生JS, 这决定了你以后的位置和高度。

世事无常，如何应对风云万变，扎实的基本功才是王道（学什么新东西都快）。新技术层出不穷，各种框架、库应接不暇，三年河东三年河西，如何在时代大潮中屹立不倒？只要掌握了语言本身，才能兵来将敌水来土堰，永远不要担心没饭吃。

设想下，如果jQuery被国家禁止使用了，你还能完成页面上的各类交互吗？不要将自己栓死在一棵树上。

依赖库，只是应用；掌握核心，才能创造。应用与创造的差异不言而谕。

原创文章，转载请注明来自张鑫旭-鑫空间-鑫生活[ http://www.zhangxinxu.com]
本文地址： http://www.zhangxinxu.com/wordpress/?p=2314

（本篇完）

有话要说，点击这里发表评论。

翻译：关于表单每个设计师都必须知道的10件事

Wed, 11 Apr 2012 18:40:26 CST

by zhangxinxu from http://www.zhangxinxu.com
本文地址： http://www.zhangxinxu.com/wordpress/?p=2336

原文作者： Joe Leech – 2012-04-04
原文链接： 10 things every designer needs to know about forms
翻译编辑：张鑫旭

为避免无用功，翻译之前先要百一下，看看是否有人已经翻译了，结果发现10年的时候有篇名字类似的译文，叫做：“ 每位网页设计师新手都应知道的10件事”，还是不错的译文，有兴趣的可以看下。不过本文内容只是单纯针对表单设计，名字虽然匹配率高，但是内容却迥然不同。好了，节约口水，直接进入译文主体~~

—————- 以下为翻译全文 —————–

有很多设计糟糕的表单，不管你是否喜欢他们，表单都是必不可少的。Joe Leech（cxpartners负责用户体验的）将介绍其在表单设计上的一些经验。

估计没有什么比表单更让设计师出气了。表单不一定可以让（设计师）表现创意，还是可以？我们可能需要从做基本的层面，重新审视表单，理解表单——表单是用户和软件之间的对话。

忘掉切换啊，点击什么的，表单是我们数字设计师（我想应该是依赖计算机进行设计的设计人员）将面临的最富有的交互。下一次，你要对付一个表单的时候，不要认为就是要应用好看的CSS效果或是添加漂亮的jQuery特效。表单设计的水是很深的。

我已经做过上百个表单用户测试，为保险公司、假期预订交互设计过一些非常复杂的表单，以及其他很多。可能你最近使用的某个表单就是我设计的。//zxx: 可有可无的牛皮糖

下面这些经验教训，我希望在我开始设计表单事前先学会之。

1. 不要标记必填字段

你知道小星号(*)就表示必填字段？我已经见过很多次因为这个用户测试失败。作为概念来讲，必填字段没有多大意义，等同离线（这个概念）。对于开发者，这个是很好的，他们提供了一个很好的黑白方式去完成。星号以及必填字段（导致表单完成）失败是因为他是个需要学习的行为。在用户测试中我看到的典型行为是用户在（表单）上面填写表单，结束于某个东西阻止他们时候或者他们碰了某个按钮。

解决方法很简单，可选字段标记，优质用户需要驻足思考是否要填写的字段处标记。

散华礼弥：从原文评论来看，这一段是争议很大的一个地方：是必填字段标记呢还是非必填字段标记？

本文作者语法以及用词上有些怪怪的，加上缺少必要的示例，所以这段译文（虽然中文）理解起来并不顺溜，我个人觉得作者的结论应该是正确与合理的（毕竟做过大量实际用户使用的测试，比设计师或开发者的冥想要靠谱多），但是，在原因的阐述上显得单薄了点，也可能是因为自己（指译者）这方面了解不深。按照作者的解释，单纯使用（红色的*）星号标注必填字段有一定的学习成本，会让用户有学习负担，反而增加出错几率。

“必填选项的概念类似于离线概念”，我想可能意思指：我们平时访问网页，基本上都是处于在线状态（虽然HTML5有离线访问）（我们没有必要专门在页面上弄个符号(eg. ※)表示当前页面在线），因此，对于网页而言，离线这个概念就意义不大；同样的，表单选项基本上都是需要填写的，特意的使用某个符号标示这个必填的也是多此一举没有多大意义的概念。

我们或许过多地站在开发者以及软件测试人员的角度去看待表单设计了，如上面提到的“开发者的黑白方式”，因为我自己也是开发者，所以对于“星号是必填，没有星号选填”很容易理解，但是，实际用户是这种思维习惯，是这样想的吗？软件测试人员也是作为极端作恶用户（非上面提到的优质用户）去使用表单，一些站在自身角度的认知确实会让我们对表单有经久的错误认识。

至于最后的用户表单完成终止我想可能只指：对于大部分正常使用用户，其表单填写行为终止为被动阻止或主动点击按钮。所谓被动阻止，可能包括即时的错误提交；主动点击按钮可能包括点击按钮提交等。为寻找案例，我去了企鹅微博绑定注册页面，发现，其表单所以选项都没有必填字段的提示，所有的必填提示均出现在表单提交之时（即“用户触碰了某个按钮”“某些事件的阻止”），这些都是我比较赞同的——相对比于有些落后（指注册交互）的携程、点评之类，例如携程注册每项都必填，红色星号显然多余；为空必填即时提醒容易中断用户操作，实际是稍稍落后于趋势可以进一步优化的体验。

下面两张截图以腾讯微博注册页面为例分别演示：阻止用户填写表单的事情，以及“不标记必填字段”。

这里所有字段都是必填的

2. 不要使用微调

HTML5近来春风得意，其提供了很多足以亮瞎双眼的工具用来把玩。我们需要好好思考我们的新玩具是否得当。现在的数字字段（指类似 type="number"的 input框）都提供了小小的上下小尖角运行用户来回调数值。

现在有两个问题。首先，浏览器默认显示的小三角真不是一般的小，点击很繁琐，你还可以想象加菲猫般的手指在iPhone上挣扎的情景。这就是所谓的费茨法则（ Fitt’s Law, 人机交互重要法则，其最基本的观点就是任何时候，当一个人用鼠标来移动鼠标指针时，屏幕上的目标的某些特征会使得点击变得轻松或者困难。目标离的越远，到达就越是费劲。目标越小，就越难点中），越小的东西越难点中。

我好想听到你在叫嚣了：你可以直接在数字文本框中键入数值啊。是的，你可以，但是，让我们看看浏览器的显示，向上向下的微调箭头使得文本框长得很像我们信赖的朋友（下拉）选择框。首次使用微调交互的用户（因为长得像下拉框）认为他们不能键入（内容）。

我的建议是避开知道它们（指微调表单元素）变得更普遍，或者浏览器开发者整改默认设计。

3. 只有一种按钮类型或最好每个表单就一个按钮

还有一个鲜为人知的心理学原理，叫做“希克法则(Hick’s Law)”，基本观点是当选项增加时，人们下决定的时间就会增加。我知道，这不是rocket science（电影，是关于青春期焦虑的喜剧佳作），但仍是值得铭记于心的规则。

你可以通过帮助你的优质用户做选择来帮助他们。让所有的基本按钮都是一个颜色，每页都只有一个按钮（非基本按钮）来帮助他们做选择。哪个按钮是我应该点击的呢？哦，很简单嘛，那个大大的色色的按钮！

4. 大块区域

我之前是学神经科学的，因此研究过心理学记忆——特别是短期和工作记忆。现在当面告诉你，不，短期记忆能力不是7+/-2, 4+/-1或是人说三五句话，作为人类的我们擅于处理视觉刺激，局限是数目越小我们做得越好。将表单块分成更小的组可以让评估更容易，往往促使用户进入表单（的东西）来自他们的记忆。

请确保你的字段组长度大约为4。

散华礼弥：我是彻底相信作者就是学神经学的，人总是某方面有问题的时候就是学习这方面东西。语句前后不通，无图无示例，生涩难懂，只能认为是英文中的文言文了，又是坑爹的一段，折腾死我了！阿门阿门。

本着服务大众的精神，我根据自己的理解把这段详细解释下：首先要大致知道这里的“短期记忆(short-term memory, STM)”是什么东西，1974年，“短期记忆”概念被“ 工作记忆(working memory, WM)”所代替。工作记忆指的是一个容量有限的系统，用来暂时保持和存储信息，是知觉、长时记忆和动作之间的接口，因此是思维过程的一个基础支撑结构。

Baddeley提出的工作记忆包括三个部分：

基于语音的语音环。主要用于记住词的顺序。
视空图像处理器。重要用于加工视觉和空间信息。
类似于注意的中枢系统。主要用于分配注意资源，控制加工过程。

因此，作者所说的“短期记忆能力不是7+/-2, 4+/-1或是人说三五句话”是指短期记忆不（只）是用来记住计算值（基于语音 ¹，心中有声音），或是刚刚说过的几句话（基于语音 ¹，嘴巴有声音），还包括人类擅长的视觉加工处理（视空图像处理 ²），但是不足在于数目有限制，下面这个例子有助于理解这里所说的限制：

拿回忆一个新的七位数的电话号码举例。对大多数人来说，它通常只有六到七个数字。换句话说，工作记忆的能力是有限的。某些脑损伤的病人除了他们听到的最后一个字母外，别的一概回忆不起来，但他们的意识却正常。

因此，作者才要求表单块状区域化（便于视觉记忆 – 短期记忆），同时控制数目在4个左右（多了会超出工作记忆的能力）。

5. 想想你为何对某事抱有疑问，对于用户感觉又如何

这可能是我给出的最直接的建议，但经常是利用率最低的。

见下图：

质疑你提出的每个问题。有必要吗？那是什么感觉要问这个？

很多业务需要问问题，作为设计师的我们可以争得面红耳赤（原文说的是争得脸都蓝了）。有必要提这样的问题，对于了解我们的业务需要这样可以让我们妥协的数据（译者：我想应该指问问题得到的数据）。

我们可以通过告诉我们的优质用户我们为何需要问那样的问题再帮助它们。放心的使用和数据共享通常都是好的。

再次示例：

仍是一个艰难的提问，但是希望我们尝到了药丸的甜头。

散华礼弥：作者又在说些有的没的的，唉~~ 实际上作者意思应该是：我们要帮助用户（站在用户角度，自己作为用户）提问，同时，显示告知用户想知道的答案。

下图为译者的补充截图：

//zxx: 下面为广告~~注意不要勿点~~嘻嘻~~

6. 日期是个不安分的家伙

输入日期确实是个挑战，有些缺陷你可以避免。单一的最大问题是错误的处理。

最简单的方法是浮出日历。值得注意的是在英国一周开始于星期一，而在美国则是星期天。如果你的用户注意力不集中，他们可能选择星期天，而实际上他们本想选择星期一的。

同样需要注意的是国际日期的格式。在美国，最开始的是月份，而在日本，最前面的是年份。因此，日期 4/5/12可以以三种方式解释。

这就是为什么最好使用选择框。

下图为译者补充截图（还是企鹅微博注册页）：

7. 表单是开发者的工艺品

与设计师一样，表单也是开发人员的工艺品。了解输入数据可能出现的错误以及设计应付的后端代码是一项挑战（译者：算是对开发人员的赞许，有戴高帽子之嫌，哈哈）。

下面很简单例子。输入货币值。用户可能犯很严重的错误。迫使用户满足某种特定的格式会让用户沮丧，让我们来正视它，这是开发人员这边的偷懒（译者：作者应该认为，对于开发人员而言，匹配固定格式比各种形式都匹配要轻松些，因此，迫使用户满足特定格式是开发人员的一点懒惰）。

对于开发人员而言，没有什么挑战好过构建防弹表单（指防御能力很强的表单）了。

散华礼弥：我想这部分应该是写给开发人员看的吧，意思是说，为了更好的用户体验，你们开发人员不要偷懒，要多辛苦点。然后再用“构建固若金汤的表单”是很有挑战很有成就感的事来激励开发人员~~

8. 不要在表单中使用垂直分栏（列）

在表单中使用列的最大问题是流动。表单开始于上面，结束语底部，而列的出现会打破这种流动。

不要假设用户通过标签访问表单，而因此以列的形式导航表单。在用户测试中，这种情况是罕见的。大部分情况下，我们看到的是：输入细节，使用鼠标/触控板/手指点击进入下一个字段，然后再输入内容，等~~

9. 一个输入框可以搞定的时候就不要使用两个

大部分用户不是盲打，在用户测试中，我们可以看到人在输入内容时候都要看键盘。

当要往表单中输入电话号码的时候，会要求添加区号和电话号码，哦，问题来了。用户看不到，或确实记不住这儿有两个输入框，结果第一个框输入了完整数字，如果这个文本框限制了一定数目的字符限制，问题就更糟了。

电话号码就使用一个字段，同样的，门牌号/街道什么的都是如此 – 只使用一个文本输入框。。

10. 友善点

你会惊讶到底有多少相当粗鲁的错误消息出现在这里或那里。

下面是我最近碰到的一个例子：

事实明摆着你可以选择一个未来时间，结果出现了滑稽的反应，恩，不太好。

你作为用户设身处地想一下，作为用户，看到这个错误提示会有什么反应。恼火？或许更糟糕。亲切友善是容易的。

我折腾了一个图片（如下，点击可以查看超大图），它包含有更多的最佳实践方法，以设计出更好的表单。

散华礼弥：我眼泪都要飙出来了，作者大人你果然很腹黑，怎么只指出问题啊？如何解决完善，以及如何避免至少也要提一下嘛。

—————- 以上为翻译全文 —————–

作者貌似是个英国佬，不循规蹈矩的语句以及一些不太懂的英式幽默可苦了我了。至此，完毕，感谢阅读。

原创文章，转载请注明来自张鑫旭-鑫空间-鑫生活[ http://www.zhangxinxu.com]
本文地址： http://www.zhangxinxu.com/wordpress/?p=2336

觉得这里的文章不错，希望他一直走下去？您可以：

（本篇完）

有话要说，点击这里发表评论。

MongoDB架构图解

Sat, 12 May 2012 18:25:11 CST

本文图片来自Ricky Ho的博文MongoDB构架（MongoDB Architecture），这是个一听就感觉很宽泛的话题，但是作者在文章中确实对MongoDB由内至外的架构进行了剖析。本文截取了其文章中的几张重点架构示意图片进行简单描述。希望对大家有用。

MongoDB数据文件内部结构

MongoDB在数据存储上按命名空间来划分，一个collection是一个命名空间，一个索引也是一个命名空间
同一个命名空间的数据被分成很多个Extent，Extent之间使用双向链表连接
在每一个Extent中，保存了具体每一行的数据，这些数据也是通过双向链接连接的
每一行数据存储空间不仅包括数据占用空间，还可能包含一部分附加空间，这使得在数据update变大后可以不移动位置
索引以BTree结构实现

相关阅读：《 MongoDB数据文件内部结构》

在MongoDB中实现事务

众所周知，MongoDB只支持对单行记录的原子性修改，并不支持对多行数据的原子操作。但是通过上图中的变态操作，实际你也可以自己实现事务。其步骤如图所未：

第1步：先记录一条事务记录，将要修改的多行记录的修改值写到里面，并设置其状态为init（如果这时候操作中断，那么在重新启动时，会判断到他处于init状态，从而将其保存的多行修改操作应用到具体的行上）
第2步：然后更新具体要修改的行，将刚才写的事务记录的标识写到它的tran字段中
第3步：将事务记录的状态从init变成pending（如果在这时候操作中断，那么在重新启动时，会判断到它的状态是pending的，这时候查看其所有对应的多条要修改的记录，如果其tran有值，那么就进行第4步，如果没值，说明第4步已经执行过了，直接将其状态从pending变成commited了就行）
第4步：将需要修改的多条记录的相应值修改了，并且unset掉之前的tran字段
第5步：将事务记录那一条的状态从pending变成commited，事务完成

其实上面的步骤并不罕见，在支持事务的DBMS中，其事务原子性提交的保证大多都与上面类似。其实事务记录的tran那条记录，就类似于这些DBMS中的redolog一样。

MongoDB数据同步

上图是MongoDB采用Replica Sets模式的同步流程

红色箭头表示写操作写到Primary上，然后异步同步到多个Secondary上
蓝色箭头表示读操作可以从Primary或Secondary任意一个上读
各个Primary与Secondary之间一直保持心跳同步检测，用于判断Replica Sets的状态

分片机制

MongoDB的分片是指定一个分片key来进行，数据按范围分成不同的chunk，每个chunk的大小有限制
有多个分片节点保存这些chunk，每个节点保存一部分的chunk
每一个分片节点都是一个Replica Sets，这样保证数据的安全性
当一个chunk超过其限制的最大体积时，会分裂成两个小的chunk
当chunk在分片节点中分布不均衡时，会引发chunk迁移操作

服务器角色

上面讲了分片的标准，下面是具体在分片时的几种节点角色

客户端访问路由节点mongos来进行数据读写
config服务器保存了两个映射关系，一个是key值的区间对应哪一个chunk的映射关系，另一个是chunk存在哪一个分片节点的映射关系
路由节点通过config服务器获取数据信息，通过这些信息，找到真正存放数据的分片节点进行对应操作
路由节点还会在写操作时判断当前chunk是否超出限定大小，如果超出，就分列成两个chunk
对于按分片key进行的查询和update操作来说，路由节点会查到具体的chunk然后再进行相关的工作
对于不按分片key进行的查询和update操作来说，mongos会对所有下属节点发送请求然后再对返回结果进行合并

更多详细内容请看原文： MongoDB Architecture

翻译：http://blog.nosqlfan.com/html/3887.html

翻译：谷歌HTML、CSS和JavaScript风格规范

Wed, 18 Jul 2012 18:04:29 CST

by zhangxinxu from http://www.zhangxinxu.com
本文地址： http://www.zhangxinxu.com/wordpress/?p=2511

原文地址： http://…style-guides/
原文作者： Craig Buckler
翻译整理：张鑫旭

注：本文翻译的内容并不是谷歌官方提供的完整HTML/CSS风格规范，而是一种带有总结性质的简单称述。完整的中文翻译，国内已经有（只有HTML/CSS, 无JS），您可以点击这里访问。

//zxx: 以下为翻译正文，原作者的吐槽保留，同时免费赠送我自己的吐槽

我喜欢浏览风格规范。他们通常有明显的规则，虽然有些有荒诞之感，但是却可以发现之前未注意到的宝石。不幸的是，鲜有公司有这个勇气来发布自己内部的风格规范。 BBC 2010年时候公开其文档以及Google最终发布了其内部项目使用的风格规范。

规则包括C++, Objective C, Python, XML, 以及R, 但是，我们最关心的是HTML, CSS以及JavaScript. 文档短小精悍。我见过太多尼玛写了差不多1001个规则的文档，压根就是显示“学识”，而不是传授有用意见！

让我们来仔细看看……

HTML

HTML样式规范并没有多少惊喜。

语义HTML5作为text/html
分离的标记、样式和脚本
在可能情况下验证你的标记
技术不支持的时候使用备胎，如 canvas

谷歌推荐打理每一个字节：使用UTF-8编码，剔除尾部的空白，避免实体引用，如 —及 ” 甚至推荐忽略可选结构以及结束标签，如：

<!DOCTYPE html>
<title>节约字节数 = 节约钞票数</title>
<p>如题。

作者吐槽：这……我虽然赞同要省字节，但是还是倾向于严格的XHTML解析。

译者吐槽：一字不差同上。

奇怪的是，谷歌建议使用连续的两个小空格代替tab空格。这不是两倍的字节大小吗？

CSS

样式规范主要就是更进一步的最佳实践以及字节节约技术：

使用有效的CSS, 除非是bugs处理或专属语法（浏览器私有前缀）
使用短ID或类命名，但确保他们不要太过隐晦，或直白（如 #blue-button）
大型项目使用前缀，如 #xyz-help, .xyz-column
选择器尽可能简单，如 #example，而不是 ul#example
使用缩写
url()中不使用引号， 0后面不跟单位
使用 #ABC这种简写的16进制颜色表示，而不是 #AABBCC
每个声明最后都要有分号（即使是最后一个）
避免浏览器hacks

谷歌建议尺寸前面的数值0省掉，如 .5em, 可以节约一个字符.

规范还推荐每个声明占据一行。

然后，声明的书写按照首字母顺序排列，如下：

#example
{
    border: 1px solid #000;
    border-radius: 6px;
    display: block;
    font-family: sans-serif;
    margin: 1em;
    outline: 0;
    padding: 10px;
    text-align: center;
}

作者吐槽：对于属性的排序我还是喜欢根据其相关性，如块类型/尺寸，字体，文字对齐，填充，边距，颜色，背景，边框及其他属性。虽然，可以会让其他开发人员困惑，但是我自己用了好多年了！

译者吐槽：一字不差同上。

JavaScript

JavaScript的风格规范比较长，这可以理解，不过我们可以提炼出一些基本点：

总是使用 var声明变量
行末别忘了分号
使用标准而不是不标准的功能
使用驼峰命名（如：camelCaseNames）以及大写的常量（如：UPPERCASE），避免使用 const关键字，因为IE不支持
使用命名空间技术
避免 eval()除非反序列化（奇怪的是JSON解析并未提及）
避免对象上使用 with(), 数组使用 for in
使用对象以及数组字面量而不是更冗长的声明
要知道 truthy和falsy规则
JavaScript资源中不使用IE条件注释
不修改内置对象的原型——这会让人颜面扫地，因为这是让JavaScript更加强大的功能之一，但你知道这会导致问题
小心使用闭包以及不要循环引用
同样，小心使用”this”

这里有个不太寻常的推荐，不在块域中使用 function, 如：

if (x) {
  var foo = function() {}
}

而不是：

if (x) {
  function foo() {}
}

显然，第二种语法到处都有使用。其可以正常运作，但是在ECMAScript中是无效的。

文档还提到，包装对象应该永远不要用在基元上，除非是类型转换。其会导致意想不到的结果，例如：

var x = new Boolean(false);
if (x) {
    // 代码执行
}

愚蠢的JavaScript.

最后，规范说你应该优先使用单引号(‘)于双引号(“)，因为字符串可能包含HTML代码。

作者吐槽：我使用双引号到处沾花惹草，我不确定我能简单地改变这个习惯。但，我在PHP中对静态字符串又使用单引号。可能是我挑剔吧~~

译者吐槽：一字不差同上。

文档最好的建议是：保持一致。开发人员很少会赞同每个程序的规范要按照你自己的那套规则走。保持一致可以让6个月之后别人可以更容易地理解你的代码，可以让生活更加美好！

你是否赞同 Google的规范指南？贵公司是否强迫你遵循奇怪的开发做法呢？

//zxx: 以上为翻译正文

没喝过洋墨水，翻译水平捉襟见肘，文中要是有表述不准确的地方，欢迎指正，感谢阅读。

原创文章，转载请注明来自张鑫旭-鑫空间-鑫生活[ http://www.zhangxinxu.com]
本文地址： http://www.zhangxinxu.com/wordpress/?p=2511

（本篇完）

有话要说，点击这里发表评论。

两个幻觉

Thu, 27 Oct 2011 08:31:47 CST

昨天我在 Twitter 上说：

这次关于《乔布斯传》的讨论怎么都在讲翻译？我以前从来没见过大家对一本书的翻译那么痛心疾首且富有参与精神地讨论，以至于产生了两种幻觉：1.以前人们读的译本都很好，这次的翻译烂到让人不能相信；2.这么多年头一次读厚书一定要抓紧机会多叫几声。

之后 Lawrence Li 在 Apple4.us 有感而发地写了《翻译与字体》一文。其中一段我特别赞同：

要求那些批评翻译的人都去搞翻译是不合理的（「你就会说，有本事自己译一个试试？」），但我们可以试图营建更好的批评氛围。批评者首先应该承认翻译这个工种的专业性，抑制自我表现的欲望，以平和的心态就事论事。我们也应该在平日培养对中文的语感，放弃「反正大家都看得懂英文，有些词就应该直接写英文」这种似是而非的观点，从翻字典式的翻译、插科打诨的翻译、抖机灵的翻译、民粹式的翻译中摆脱出来。我们更应该了解，因为「译事沉疴」而鼓励民众直接读原文，是一种不切实际的幻想。如果民众集体对中国的翻译丧失信心，采取犬儒立场，那么中国的翻译界就会陷入跟中国的字体界一样的窘境。

翻译不是一件容易的事情，哪怕退一步，读原文也不是谁都可以做到的，尽管大部分人都学过英语。且不说要把文中一些只有熟悉英语文化的人才能理解的妙处读出来，即便最低限度的「明白意思」我相信也只有很少的人能做到。虽说我也算是个要留学的人，英文应该在中等水平，但至今从头看完的英文原著书也不过寥寥几本。平时看英文文本时看得头昏脑胀，云里雾里，甚至意思看得正反颠倒更是常事。

以下我想以最大恶意揣测公众的心思，如果有「狗眼看人低」的情况存在，见谅。

中国翻译界水平普遍低劣，应该不是新闻，只要常译文书，在豆瓣混的人都知道。可至于水平怎么个差法？我估计大部分人没有概念。「常凯申」的例子已经够臭名远扬了，但去新浪微博随机找几个人问问，我相信十有八九对此是闻所未闻。至于买《乔布斯传》简体版的读者中究竟有多少能看出这本书翻译的好歹，我心里没底，但我知道，二话不说，直接批评「翻得太烂」绝对是稳赚不赔的买卖 —— 夸书好有风险，骂其烂还能有错？可真要那些人去对照原文找硬伤……哼。

上次在 Facebook 和一个朋友聊天。不到万不得已，我在 Facebook 上是不写中文的，所以我们用英语聊天。对方提了个问题，我觉得以自己的语言能力，一两句话讲不清楚，所以写了六行，其实连100个单词都不到。结果，隔了半晌，对方回复「麻烦翻译 = = 我看一大段英文真头疼」。

这就是我所知道中国人对英语接受的极限：不是什么一本书，一篇报道，而是一段话。况且，我写的还只是中国人的英文，对同胞来说，读起来应该是顺风顺水地流畅。

所以，我真诚且一点不抱鄙视地说：「四六级的同学们，如果没有很急切的学英语需求的话，别勉强，还是看中信版的吧，肯定比你自己读原文读懂的东西多。」

苹果创始人乔布斯的官方传记俨然成为了苹果公司的新产品：iBio 。作为一名果粉有责任去买一本，看不看是另一回事，毕竟从高中毕业后就再也没捧过500页以上的书了；作为一名虔诚的果粉，有义务在教主的杰作 iPad 上买一本英文版，这是身份的证明；作为一名资深的虔诚果粉，体内有一股无法抑制的力量召唤着自己对任何中文翻译进行鞭挞，以至于一句「 It just works.」随便怎么翻都觉得没有译出帮主的气场，以至于一封文笔一般的情书会被翻得天花乱坠。

{lang: 'zh-CN'}

也许您也会喜欢
六个“为什么”	《阿拉丁组曲》两个选段	信祥哥，得永生——请赵忠祥的两个好处	“漠不关心”是个好东西	对封杀BT的两篇评论
无觅

IT瘾翻译推荐

【译】Java8 之后对新开发者非常友好的特性

Switch 表达式 (JDK 12)

文本块 (JDK 13)

新的 Optional Methods (JDK 9/ JDK 10)

集合工厂方法(JDK 9)

Records (JDK 14)

接口中的私有方法 (JDK 9)

局部变量类型推导 (JDK 10 / JDK 11)

【译】你可能不知道但却很有用的 Java 特性

延迟队列

时间格式的日期

Stamped Lock

并发累加器

数组的二分查找

Bit Set

【译】Hybrid移动应用：用网页技术提供Native体验

什么是混合模式移动应用

优点

缺点

让你的用户宾至如归

DIY VS. UI框架

自定义UI组件

移动端UI设计的资源

设计一个看起来原生的标题栏

支持高分辨率屏幕

使用系统字体

一个图标胜过千言万语

性能优化

提升感知速度

消除触屏设备上点击的延迟

设计点击状态的样式

提示加载

正确设置滚动

动量效果

下拉刷新

滚动回到顶部

让点击更容易

使用触摸手势

不要忘了原生功能

总要留有出口

如何打包

PHONEGAP和APACHE CORDOVA

SENCHA TOUCH

TRIGGER.IO

在真机上测试

开始考虑硬发布

发布到商店

结论

传说中的新版Google翻译到底有多厉害？

2014盛行与即将消逝的网页设计趋势

即将盛行的趋势

模糊背景

简单的动画

简单的配色

更棒的用户体验

更多的滚动，更少的点击

大字体

私人化内容

糟糕的趋势

低画质的照片与视频

扁平与拟物

冗长的表单

通过留白打造简洁有效的设计

留白的基本要素

重点使用留白的地方

12例留白的有效运用

[翻译]十条有用的 Go 技术

十条有用的 Go 技术

1. 使用单一的 GOPATH

2. 将 for-select 封装到函数中

3. 在初始化结构体时使用带有标签的语法

4. 将结构体的初始化拆分到多行

5. 为整数常量添加 String() 方法

6. 让 iota 从 a +1 开始增量

7. 返回函数调用

8. 把 slice、map 等定义为自定义类型

9. withContext 封装函数

10. 为访问 map 增加 setter，getters

总结

3. 使用设计语言来衔接（USE DESIGN IN CONJUNCTION WITH LANGUAGE）

4.例外（EXCEPTIONS PROVE THE RULE）