From 2718487c0da5d247a3845fdb6a72cfc52a738509 Mon Sep 17 00:00:00 2001 From: hcy12312 <72703183+hcy12312@users.noreply.github.com> Date: Sat, 13 Jul 2024 18:37:29 +0800 Subject: [PATCH] Delete _posts directory --- _posts/2014-01-29-hello-2015.markdown | 74 -- _posts/2014-08-16-miui6.markdown | 60 -- ...2014-09-04-is-pure-android-better.markdown | 135 --- .../2014-10-01-why-alibaba-ux-sucks.markdown | 68 -- .../2014-11-20-responsive-web-design.markdown | 150 ---- .../2014-12-13-wechat-block-kuaidi.markdown | 70 -- _posts/2015-03-10-apple-event-2015.markdown | 59 -- _posts/2015-03-25-digital-native.markdown | 125 --- _posts/2015-03-31-e2e_user_scenarios.markdown | 78 -- _posts/2015-04-14-unix-linux-note.markdown | 201 ----- _posts/2015-04-15-os-metro.markdown | 112 --- _posts/2015-05-11-see-u-ali.markdown | 104 --- _posts/2015-05-25-js-module-loader.markdown | 310 ------- _posts/2015-06-15-alitrip-strategy.markdown | 202 ----- _posts/2015-07-09-js-module-7day.markdown | 45 - _posts/2015-09-22-js-version.markdown | 67 -- .../2015-10-28-how-designer-learn-fe.markdown | 189 ----- _posts/2015-12-15-ios9-safari-web.markdown | 340 -------- _posts/2015-12-28-css-sucks-2015.markdown | 115 --- _posts/2016-02-01-React-vs-Angular2.markdown | 244 ------ _posts/2016-06-05-pwa-in-my-pov.markdown | 40 - _posts/2016-09-22-the-open-web.md | 87 -- _posts/2016-10-20-pwa-qcon2016.markdown | 64 -- _posts/2016-11-20-sw-101-gdgdf.markdown | 47 -- _posts/2017-01-09-wechat-miniapp-ux.md | 139 --- _posts/2017-02-09-nextgen-web-pwa.markdown | 515 ----------- _posts/2017-04-06-html-document.md | 63 -- _posts/2017-05-28-sw-precache.md | 256 ------ _posts/2017-06-25-you-are-slaves.markdown | 68 -- ...2017-07-12-upgrading-eleme-to-pwa.markdown | 26 - _posts/2017-07-26-farewell-flash.md | 87 -- _posts/2017-10-06-css-complaints.md | 43 - _posts/2017-12-12-halting-problem.md | 125 --- _posts/2017-12-12-uncomputable-funcs.md | 70 -- _posts/2018-05-11-pwa-zh-preface.md | 27 - _posts/2018-06-30-dreamer.md | 35 - ...2018-09-27-avoiding-success-at-all-cost.md | 55 -- _posts/2018-10-06-vim-cn-im.md | 27 - _posts/2019-09-03-vim-from-finder.md | 52 -- _posts/2019-09-08-spacemacs-workflow.md | 64 -- _posts/2019-11-19-is-pwa-dead-in-2019.md | 47 -- .../2020-04-03-react-hooks-vue-composition.md | 221 ----- _posts/2020-07-05-reflection-2020.md | 87 -- ...ic-failure-of-higher-education-in-china.md | 32 - _posts/2021-04-10-js-20yrs-preface.md | 16 - .../cs_idols/2019-09-13-peter-john-landin.md | 33 - _posts/data_rep/2020-06-19-data-rep-int.md | 333 -------- _posts/data_rep/2020-06-21-data-rep-float.md | 331 -------- _posts/data_rep/2020-06-21-data-rep-todo.md | 22 - _posts/hidden/2020-05-05-pl-chart.md | 18 - .../read_sf_lf/2019-01-01-sf-lf-01-basics.md | 209 ----- .../2019-01-02-sf-lf-02-induction.md | 142 ---- _posts/read_sf_lf/2019-01-03-sf-lf-03-list.md | 169 ---- _posts/read_sf_lf/2019-01-04-sf-lf-04-poly.md | 617 -------------- .../read_sf_lf/2019-01-05-sf-lf-05-tactics.md | 351 -------- .../read_sf_lf/2019-01-06-sf-lf-06-logic.md | 587 ------------- .../read_sf_lf/2019-01-07-sf-lf-07-indprop.md | 648 -------------- _posts/read_sf_lf/2019-01-08-sf-lf-08-map.md | 226 ----- .../2019-01-09-sf-lf-09-proof-object.md | 487 ----------- .../2019-01-10-sf-lf-10-ind-principle.md | 329 -------- _posts/read_sf_lf/2019-01-11-sf-lf-11-rel.md | 265 ------ _posts/read_sf_lf/2019-01-12-sf-lf-12-imp.md | 739 ---------------- .../2019-01-13-sf-lf-13-imp-parser.md | 144 ---- .../2019-01-14-sf-lf-14-imp-ceval.md | 104 --- .../2019-01-15-sf-lf-15-extraction.md | 156 ---- _posts/read_sf_lf/2019-01-16-sf-lf-16-auto.md | 223 ----- .../read_sf_plf/2019-03-01-sf-plf-01-equiv.md | 532 ------------ .../2019-03-02-sf-plf-02-hoare-1.md | 15 - .../2019-03-03-sf-plf-03-hoare-2.md | 16 - .../2019-03-04-sf-plf-04-hoare-logic.md | 15 - .../2019-03-05-sf-plf-05-smallstep.md | 547 ------------ .../read_sf_plf/2019-03-06-sf-plf-06-types.md | 269 ------ .../read_sf_plf/2019-03-07-sf-plf-07-STLC.md | 315 ------- .../2019-03-08-sf-plf-08-STLC-prop.md | 255 ------ .../2019-03-09-sf-plf-09-more-STLC.md | 472 ----------- .../2019-03-10-sf-plf-10-subtyping.md | 147 ---- .../2019-03-11-sf-plf-11-typechecking.md | 253 ------ .../2019-03-12-sf-plf-12-records.md | 40 - .../2019-03-13-sf-plf-13-references.md | 331 -------- .../2019-03-14-sf-plf-14-record-sub.md | 42 - .../2019-03-15-sf-plf-15-norm-STLC.md | 15 - .../2019-03-16-sf-plf-16-lib-tactics.md | 15 - .../2019-03-17-sf-plf-17-use-tactics.md | 160 ---- .../2019-03-18-sf-plf-18-use-auto.md | 70 -- .../2019-03-19-sf-plf-19-partial-eval.md | 15 - .../2019-09-02-sf-qc-02-typeclasses.md | 796 ------------------ 86 files changed, 15494 deletions(-) delete mode 100644 _posts/2014-01-29-hello-2015.markdown delete mode 100644 _posts/2014-08-16-miui6.markdown delete mode 100644 _posts/2014-09-04-is-pure-android-better.markdown delete mode 100644 _posts/2014-10-01-why-alibaba-ux-sucks.markdown delete mode 100644 _posts/2014-11-20-responsive-web-design.markdown delete mode 100644 _posts/2014-12-13-wechat-block-kuaidi.markdown delete mode 100644 _posts/2015-03-10-apple-event-2015.markdown delete mode 100644 _posts/2015-03-25-digital-native.markdown delete mode 100644 _posts/2015-03-31-e2e_user_scenarios.markdown delete mode 100644 _posts/2015-04-14-unix-linux-note.markdown delete mode 100644 _posts/2015-04-15-os-metro.markdown delete mode 100644 _posts/2015-05-11-see-u-ali.markdown delete mode 100644 _posts/2015-05-25-js-module-loader.markdown delete mode 100644 _posts/2015-06-15-alitrip-strategy.markdown delete mode 100644 _posts/2015-07-09-js-module-7day.markdown delete mode 100644 _posts/2015-09-22-js-version.markdown delete mode 100644 _posts/2015-10-28-how-designer-learn-fe.markdown delete mode 100644 _posts/2015-12-15-ios9-safari-web.markdown delete mode 100644 _posts/2015-12-28-css-sucks-2015.markdown delete mode 100644 _posts/2016-02-01-React-vs-Angular2.markdown delete mode 100644 _posts/2016-06-05-pwa-in-my-pov.markdown delete mode 100644 _posts/2016-09-22-the-open-web.md delete mode 100644 _posts/2016-10-20-pwa-qcon2016.markdown delete mode 100644 _posts/2016-11-20-sw-101-gdgdf.markdown delete mode 100644 _posts/2017-01-09-wechat-miniapp-ux.md delete mode 100644 _posts/2017-02-09-nextgen-web-pwa.markdown delete mode 100644 _posts/2017-04-06-html-document.md delete mode 100644 _posts/2017-05-28-sw-precache.md delete mode 100644 _posts/2017-06-25-you-are-slaves.markdown delete mode 100644 _posts/2017-07-12-upgrading-eleme-to-pwa.markdown delete mode 100644 _posts/2017-07-26-farewell-flash.md delete mode 100644 _posts/2017-10-06-css-complaints.md delete mode 100644 _posts/2017-12-12-halting-problem.md delete mode 100644 _posts/2017-12-12-uncomputable-funcs.md delete mode 100644 _posts/2018-05-11-pwa-zh-preface.md delete mode 100644 _posts/2018-06-30-dreamer.md delete mode 100644 _posts/2018-09-27-avoiding-success-at-all-cost.md delete mode 100644 _posts/2018-10-06-vim-cn-im.md delete mode 100644 _posts/2019-09-03-vim-from-finder.md delete mode 100644 _posts/2019-09-08-spacemacs-workflow.md delete mode 100644 _posts/2019-11-19-is-pwa-dead-in-2019.md delete mode 100644 _posts/2020-04-03-react-hooks-vue-composition.md delete mode 100644 _posts/2020-07-05-reflection-2020.md delete mode 100644 _posts/2021-01-19-the-systematic-failure-of-higher-education-in-china.md delete mode 100644 _posts/2021-04-10-js-20yrs-preface.md delete mode 100644 _posts/cs_idols/2019-09-13-peter-john-landin.md delete mode 100644 _posts/data_rep/2020-06-19-data-rep-int.md delete mode 100644 _posts/data_rep/2020-06-21-data-rep-float.md delete mode 100644 _posts/data_rep/2020-06-21-data-rep-todo.md delete mode 100644 _posts/hidden/2020-05-05-pl-chart.md delete mode 100644 _posts/read_sf_lf/2019-01-01-sf-lf-01-basics.md delete mode 100644 _posts/read_sf_lf/2019-01-02-sf-lf-02-induction.md delete mode 100644 _posts/read_sf_lf/2019-01-03-sf-lf-03-list.md delete mode 100644 _posts/read_sf_lf/2019-01-04-sf-lf-04-poly.md delete mode 100644 _posts/read_sf_lf/2019-01-05-sf-lf-05-tactics.md delete mode 100644 _posts/read_sf_lf/2019-01-06-sf-lf-06-logic.md delete mode 100644 _posts/read_sf_lf/2019-01-07-sf-lf-07-indprop.md delete mode 100644 _posts/read_sf_lf/2019-01-08-sf-lf-08-map.md delete mode 100644 _posts/read_sf_lf/2019-01-09-sf-lf-09-proof-object.md delete mode 100644 _posts/read_sf_lf/2019-01-10-sf-lf-10-ind-principle.md delete mode 100644 _posts/read_sf_lf/2019-01-11-sf-lf-11-rel.md delete mode 100644 _posts/read_sf_lf/2019-01-12-sf-lf-12-imp.md delete mode 100644 _posts/read_sf_lf/2019-01-13-sf-lf-13-imp-parser.md delete mode 100644 _posts/read_sf_lf/2019-01-14-sf-lf-14-imp-ceval.md delete mode 100644 _posts/read_sf_lf/2019-01-15-sf-lf-15-extraction.md delete mode 100644 _posts/read_sf_lf/2019-01-16-sf-lf-16-auto.md delete mode 100644 _posts/read_sf_plf/2019-03-01-sf-plf-01-equiv.md delete mode 100644 _posts/read_sf_plf/2019-03-02-sf-plf-02-hoare-1.md delete mode 100644 _posts/read_sf_plf/2019-03-03-sf-plf-03-hoare-2.md delete mode 100644 _posts/read_sf_plf/2019-03-04-sf-plf-04-hoare-logic.md delete mode 100644 _posts/read_sf_plf/2019-03-05-sf-plf-05-smallstep.md delete mode 100644 _posts/read_sf_plf/2019-03-06-sf-plf-06-types.md delete mode 100644 _posts/read_sf_plf/2019-03-07-sf-plf-07-STLC.md delete mode 100644 _posts/read_sf_plf/2019-03-08-sf-plf-08-STLC-prop.md delete mode 100644 _posts/read_sf_plf/2019-03-09-sf-plf-09-more-STLC.md delete mode 100644 _posts/read_sf_plf/2019-03-10-sf-plf-10-subtyping.md delete mode 100644 _posts/read_sf_plf/2019-03-11-sf-plf-11-typechecking.md delete mode 100644 _posts/read_sf_plf/2019-03-12-sf-plf-12-records.md delete mode 100644 _posts/read_sf_plf/2019-03-13-sf-plf-13-references.md delete mode 100644 _posts/read_sf_plf/2019-03-14-sf-plf-14-record-sub.md delete mode 100644 _posts/read_sf_plf/2019-03-15-sf-plf-15-norm-STLC.md delete mode 100644 _posts/read_sf_plf/2019-03-16-sf-plf-16-lib-tactics.md delete mode 100644 _posts/read_sf_plf/2019-03-17-sf-plf-17-use-tactics.md delete mode 100644 _posts/read_sf_plf/2019-03-18-sf-plf-18-use-auto.md delete mode 100644 _posts/read_sf_plf/2019-03-19-sf-plf-19-partial-eval.md delete mode 100644 _posts/read_sf_qc/2019-09-02-sf-qc-02-typeclasses.md diff --git a/_posts/2014-01-29-hello-2015.markdown b/_posts/2014-01-29-hello-2015.markdown deleted file mode 100644 index 962263968b4..00000000000 --- a/_posts/2014-01-29-hello-2015.markdown +++ /dev/null @@ -1,74 +0,0 @@ ---- -layout: post -title: "Hello 2015" -subtitle: " \"Hello World, Hello Blog\"" -date: 2015-01-29 12:00:00 -author: "Hux" -header-img: "img/post-bg-2015.jpg" -catalog: true -tags: - - Meta ---- - -> “Yeah It's on. ” - - -Hux 的 Blog 就这么开通了。 - -[跳过废话，直接看技术实现 ](#build) - -2015 年，Hux 总算有个地方可以好好写点东西了。 - - -作为一个程序员， Blog 这种轮子要是挂在大众博客程序上就太没意思了。一是觉得大部分 Blog 服务都太丑，二是觉得不能随便定制不好玩。之前因为太懒没有折腾，结果就一直连个写 Blog 的地儿都没有。 - -在玩了一段时间知乎之后，答题的快感又激起了我开博客的冲动。之前的[个人网站](http://huangxuan.me/portfolio)是作品集形式的（现在集成进来了），并不适合用来写博文，一不做二不休，花一天搞一个吧！ - - -

- -## 正文 - -接下来说说搭建这个博客的技术细节。 - -正好之前就有关注过 [GitHub Pages](https://pages.github.com/) + [Jekyll](http://jekyllrb.com/) 快速 Building Blog 的技术方案，非常轻松时尚。 - -其优点非常明显： - -* **Markdown** 带来的优雅写作体验 -* 非常熟悉的 Git workflow ，**Git Commit 即 Blog Post** -* 利用 GitHub Pages 的域名和免费无限空间，不用自己折腾主机 - * 如果需要自定义域名，也只需要简单改改 DNS 加个 CNAME 就好了 -* Jekyll 的自定制非常容易，基本就是个模版引擎 - - -本来觉得最大的缺点可能是 GitHub 在国内访问起来太慢，所以第二天一起床就到 GitCafe(Chinese GitHub Copy，现在被 Coding 收购了) 迁移了一个[镜像](http://huxpro.coding.me)出来，结果还是巨慢。 - -哥哥可是个前端好嘛！ 果断开 Chrome DevTool 查了下网络请求，原来是 **pending 在了 Google Fonts** 上，页面渲染一直被阻塞到请求超时为止，难怪这么慢。 -忍痛割爱，只好把 Web Fonts 去了（反正超时看到的也只能是 fallback ），果然一下就正常了，而且 GitHub 和 GitCafe 对比并没有感受到明显的速度差异，虽然 github 的 ping 值明显要高一些，达到了 300ms，于是用 DNSPOD 优化了一下速度。 - - ---- - -配置的过程中也没遇到什么坑，基本就是 Git 的流程，相当顺手 - -大的 Jekyll 主题上直接 fork 了 Clean Blog（这个主题也相当有名，就不多赘述了。唯一的缺点大概就是没有标签支持，于是我给它补上了。） - -本地调试环境需要 `gem install jekyll`，结果 rubygem 的源居然被墙了……后来手动改成了我大淘宝的镜像源才成功 - -Theme 的 CSS 是基于 Bootstrap 定制的，看得不爽的地方直接在 Less 里改就好了（平时更习惯 SCSS 些），**不过其实我一直觉得 Bootstrap 在移动端的体验做得相当一般，比我在淘宝参与的团队 CSS 框架差多了……**所以为了体验，也补了不少 CSS 进去 - -最后就进入了耗时反而最长的**做图、写字**阶段，也算是进入了**写博客**的正轨，因为是类似 Hack Day 的方式去搭这个站的，所以折腾折腾着大半夜就过去了。 - -第二天考虑中文字体的渲染，fork 了 [Type is Beautiful](http://www.typeisbeautiful.com/) 的 `font` CSS，调整了字号，适配了 Win 的渣渲染，中英文混排效果好多了。 - - -## 后记 - -回顾这个博客的诞生，纯粹是出于个人兴趣。在知乎相关问题上回答并获得一定的 star 后，我决定把这个博客主题当作一个小小的开源项目来维护。 - -在经历 v1.0 - v1.5 的蜕变后，这个博客主题愈发完整，不但增加了诸多 UI 层的优化（opinionated）；在代码层面，更加丰富的配置项也使得这个主题拥有了更好的灵活性与可拓展性。而作为一个开源项目，我也积极的为其完善文档与解决 issue。 - -如果你恰好逛到了这里，希望你也能喜欢这个博客主题。 - -—— Hux 后记于 2015.10 diff --git a/_posts/2014-08-16-miui6.markdown b/_posts/2014-08-16-miui6.markdown deleted file mode 100644 index 680ebd7dd34..00000000000 --- a/_posts/2014-08-16-miui6.markdown +++ /dev/null @@ -1,60 +0,0 @@ ---- -layout: post -title: "如何评价 MIUI 6？" -date: 2014-08-16 12:00:00 -author: "Hux" -header-img: "img/post-bg-miui6.jpg" -tags: - - 知乎 - - 产品 - - UX/UI ---- - -> 这篇文章转载自[我在知乎上的回答](http://www.zhihu.com/question/24783844/answer/29286896) - - -
-
MIUI 6，充满了“借鉴”，iOS 7 版的 Android…… -
米 4，碉堡了，不服跑个分，简直就是 iPhone 4……
你们说得这些我一点都不反对。 -
-
可是，你们对小米的要求太高了。 -
-
其实小米说到底也不过是一个才初创4年的公司而已， -
你是指望小米能引领一套新的设计风格？ -
还是指望它能在国际上体现一下我国的自主创新能力？ -
-
你想太多了。 -
-
更何况，MIUI也不是没有设计，它比很多国内，国际大厂的ROM好看好用太多了。 -
它只是没有多少新设计而已， iOS 7 的视觉，混着大部分 Android ＋ WP 的交互。也不知道是因为确实欣赏 Android 的一些交互，还是因为毕竟是基于 Android 懒得改了。 -
-
因为没有一个背后的设计思想在支撑，于是它就把所有自己觉得好，觉得会被认可的东西抄过来了而已。 -
-
这思路一点问题都没有，大部分用户一定会觉得更好看了，国际范儿又有设计感。最多是少数圈内人士（包括我），那群也不真正买它手机用的人，在那愤愤不平而已。 -
-
自立门派风险太大了。 -
MI 4 的配置 + MIUI 6，在这个价位几乎是无敌的，这就够了。 -
-
至于官方说的什么“糖果式”设计，那简直就是笑话。跟 Ive 的 iOS 7 或是 Material Design，Metro 所设计之设计，完全不在一个高度上。 -
-
-
其实有的时候觉得小米很像腾讯（尤其是更早些年的腾讯）。 -
其实本来也就不是什么创新者的角色，那就做借鉴和整合呗。 -
-
用户喜欢什么， -
公司需要什么， -
大众流行什么， -
那我们就做呗。 -
-
拿下市场才是第一位的，不出错才是第一位的。 -
先做大了才有可能去做更大的事啊。 -
-
老罗再有情怀，锤子要是死了，那也就这么死了。 -
-
你指责小米没有多少创新，或是腾讯老是山寨 start up ，我同意，我陪你愤愤不平，可是又有什么意思呢。 -
-
它们这么做，对现有公司发展来说， -
简直是一点错都没有。 -
-
-
diff --git a/_posts/2014-09-04-is-pure-android-better.markdown b/_posts/2014-09-04-is-pure-android-better.markdown deleted file mode 100644 index e4c57e9481d..00000000000 --- a/_posts/2014-09-04-is-pure-android-better.markdown +++ /dev/null @@ -1,135 +0,0 @@ ---- -layout: post -title: "对中国用户而言，Pure Android 是否比 MIUI 或 Flyme 体验更好？" -subtitle: "" -date: 2014-09-04 12:00:00 -author: "Hux" -header-img: "img/post-bg-android.jpg" -tags: - - 知乎 - - 产品 - - UX/UI ---- - -> 这篇文章转载自[我在知乎上的回答](http://www.zhihu.com/question/25104721/answer/30108886) - - -

哎呀～不要站队嘛。其实这是一个很有意思的题目，让我们一点点来看 -
-
哦对，谢妖～。本人是Nexus 5用户，系统当然是Pure Android KitKat啦（臭谷粉！点Down！喂喂喂我还没给结论呢） -
毕竟是回答问题嘛，先给一个明确的答案： -
-
否。（对中国用户而言，Pure Android 并不比 MIUI 或 Flyme 体验更好。） - -

从下面「 居然比关注数还多」的回答中，就可以看出大家都是急于站队的样子：

- - -
从答案我们也可以看出，中国用户的确是一个过于复杂的群体，那这个问题怎么办？ -
-
数学老师教过哒，分类讨论啊！ -
（来，开始认真了。注意，我只分两类，数量非常小的Geek用户，和其余都算在内的非Geek用户） -
-
- -

先说好理解的：

- - 在国内，使用Pure Android其实是有很多障碍的：众所周知Google基本被墙死，去年还能上上的G+，Gmail 最近基本报废，回国后Google Now不开VPN永远都是Sign error或者No internet connection……那干嘛还用？ -
-
因为这群人是Geek呀！这群谷粉、安卓粉、IT科技粉、设计师、工程师们，这群充满技术情节的人儿们，为了我们的品味（逼格），挂着VPN，连着美版的Play Store，用着Android/Material Design 的 GMS，Chrome Beta，FB，Twitter，WhatsApp……就这么一路高歌的走下去了。 -
-
你看！Action Bar ＋ Navigation Drawer 多好用！ -
你看！Fixed Tabs 可以滑的好吗！ -
你看！流畅不！ART开起来妥妥的流畅度爆iOS！ -
你看！原生Android 哪里会越用用卡！？你升4.4.4了吗 ？ -
-
哪里要担心这群人啊。国内买不到的Nexus，用不了GMS，这都不叫事。 -
-
- -

那么，

- - GMS的问题就不多说了，妥妥是用不了，在VPN之间切换也是麻烦。 -
也不说Pure Android不那么好刷到的问题（当然你可以刷CM）， -
我们就直接来看最核心的问题： -
-
「 Pure Android 的交互设计真的比 MIUI / Flyme 好吗？」
 -
不见得。 -
所谓设计，第一个要考虑的就是目标用户。 -
-
为什么Pure Android的交互设计让Geek觉得用户体验好？ -
- -
而 Pure Android 之于 普通用户 呢？ -
「 这些优势基本荡然无存」，反而，混乱的国内生态环境带来大部分中国用户对Android Design的陌生，相比iOS复杂许多的Android逻辑带来较高的学习成本…… -
-
而MIUI/Flyme在设计方面上的本地化，主要就是出来解决这个问题的。 -
我们可以看到，其实MIUI/Flyme做得大部分工作，除了视觉外，就是简化信息层级，降低交互学习成本，遮住Android系统过于复杂的部分，在易用性上向iOS靠拢。 -
-
如果说在这里MIUI/Flyme还只能和Pure Android 打个平手的话…… -
-
MIUI 和 Flyme 的本地化还远没有完： -
-
你在国内总要用国内的互联网服务吧？ -
集成，我全给你全整合进来，打造一条龙服务 -
- 不够酷？对大部分用户来说够酷了 -
- 渠道成本低（不是指价格）。这个其实也相当重要 -
- -
更何况，对于大部分非Geek用户，手机虽不再只是当年的通讯工具那么简单，但充其量也就是一个智能电子设备而已。能方便快速的享受到国内主流的互联网应用与服务，完成日常的需求就足以。 -
-
MIUI/Flyme 在这方面上的成绩，是Pure Android远不能比的。 -
-
所以我的结论是： -
-
对中国用户而言，Pure Android 并不比 MIUI 或 Flyme 体验更好。 -
对大部分中国用户而言，MIUI 或 Flyme 比 Pure Android 的体验更好。 -
-
-
-
-
没啥利益相关，我又不是云OS的 -

diff --git a/_posts/2014-10-01-why-alibaba-ux-sucks.markdown b/_posts/2014-10-01-why-alibaba-ux-sucks.markdown deleted file mode 100644 index 23150fdd548..00000000000 --- a/_posts/2014-10-01-why-alibaba-ux-sucks.markdown +++ /dev/null @@ -1,68 +0,0 @@ ---- -layout: post -title: "为什么阿里系软件体验都不好？" -subtitle: "或许这就是所谓的企业 DNA " -date: 2014-10-1 12:00:00 -author: "Hux" -header-img: "img/post-bg-alibaba.jpg" -tags: - - 知乎 - - 产品 - - 阿里 ---- - -> 这篇文章转载自[我在知乎上的回答](http://www.zhihu.com/question/25657351/answer/31278511) - - -
-
-
一言以蔽之，优先级。 -
这个优先级并不是由谁或者哪个Boss定的，而是长期的市场竞争和业务需求下的结果 -
-
- - 企鹅家的主力产品，QQ、微信、QQ音乐、QQ空间 等，多是IM（即时通讯）、SNS（社交网络）、数字娱乐 等形态的产品。 -
-
这类产品往往必须「直接依靠优秀的产品服务与用户体验」来赢得用户。 -
-
如果这点做不好，产品就无法在竞争中脱颖而出。这也使得在企鹅内部，围绕这部分的要求，需求，反馈 都一定最多，使得企鹅不得不把这部分做好。 -
-
- - 阿里系的主力产品，从1688、淘宝、再到支付宝、天猫、淘宝旅行、淘点点、一淘、旺旺，要么是电商类产品，要么就是电商类的延伸产品。 -
-
而这类产品的核心竞争力（或者说要做好的难处），往往在「如何与实体经济，甚至政府 打交道」、「如何做好运营」，而非优秀的用户体验。 -
-
应该说，阿里从来都不是不重视用户体验，这两年更是愈发重视。但是因为身处这样的市场环境，阿里必须先完成这些优先级更高的需求（海量的业务，运营需求）以抢占市场， -
这才导致阿里内部无法有太多精力focus到客户端体验上。 -
-
-
-
上面就算基本回答了题主的问题， -
不过，知乎惯例，多说几句： -
-
其实，上面的答案，也可以说这都是说辞。 -
-
在我刚刚加入阿里的时候，我也一度纳闷甚至郁闷这个事。直到我开始接触更多的项目，我才能逐渐理解「为什么会这样」。 -
-
但是，这并不足以成为借口。 -
该不该改？ 当然该改。 -
-
我相信几乎所有阿里人，尤其UED，肯定都不希望这样。 -
只能说，这需要阿里投入更多的人、更多的时间、更多的努力来做好 -
-
-
-
以上。 -
-
利益相关： -
阿里员工 -
-
-
diff --git a/_posts/2014-11-20-responsive-web-design.markdown b/_posts/2014-11-20-responsive-web-design.markdown deleted file mode 100644 index 16a4e44c5a9..00000000000 --- a/_posts/2014-11-20-responsive-web-design.markdown +++ /dev/null @@ -1,150 +0,0 @@ ---- -layout: post -title: "你们觉得响应式好呢，还是手机和PC端分开来写？" -date: 2014-11-20 12:00:00 -author: "Hux" -header-img: "img/post-bg-rwd.jpg" -tags: - - 知乎 - - Web ---- - -> 这篇文章转载自[我在知乎上的回答](http://www.zhihu.com/question/25836425/answer/31564174) - - -
-

- 根据你的产品特点，进行两种不同的设计， -
根据你的设计需求，选择合适的技术方案。 -

-
A与B不是硬币的正反面，它们为了解决同一个问题而生，它们是同一种思想的延伸。 -
-
-
移动和桌面设计的差别远不止是布局问题。只要有足够的编程量，这些差别是可以通过响应式设计来解决的。事实上，你可以认为如果一种设计不能兼顾两种平台的主要差别，就不能算是合格的响应式设计。但是，如果确实想要处理好平台间的所有差异，我们就回到了原点：进行两种不同的设计。 -
-
——《Mobile Usability》（《贴心设计 打造高可用性的移动产品》）
-
-
其实无论是什么解决方案，我们先来看看我们想要解决的问题： -
-
“屏幕尺寸越来越多，不同设备的交互特质也有着巨大的差别，我们希望我们的网站能够在移动手机、平板、桌面电脑，在键鼠、触摸、无障碍设备上都有优秀的用户体验。所以，我们需要网站的用户界面在不同的平台上有所不同。” -
-
-
那怎么做呢，一个解决方案应运而生： -
-
- 狭义上，我们把主要依靠前端 CSS （包括 Media Query 媒体查询，百分比流式布局，网格与Typography系统……）来对各种屏幕尺寸进行响应的做法，称之为响应式布局，又称作自适应网页设计，或者弹性设计。 -
-
这种主要依靠CSS的方案有很多优点，比如： -
- 但问题也很明显，比如： -
- -
-
如果你的移动用户对网站所有的功能和内容有着与桌面用户同等的需求，比如 新闻、报纸（媒体类）网站，或者活动、专题页等 偏重信息传达而轻交互 的网站，那么这个解决方案其实恰到好处： -
触摸屏优化（胖手指）、减少次要信息…… 这些通过 CSS 解决就够了。 -
-
-
但是，如果我想要做更多的 「移动化设计」，比如 减少信息层级、增强手势操作、让网页更接近一个Native App ？ -
-
好吧，为了更复杂的需求，为了我们的网站能更牛逼的 「响应」 各个平台， -
又有了这些解决方案： -
-
-
- 提倡 RESS 的人认为：基于前端 CSS 的响应式方案只是一种妥协： -
“ UI 只是在很被动的进行「调整」，而不能真正达到各个平台的最优。好的设计应该达到「这个设备该有的体验」（Device Experiences）。 ” -
-
Device Experiences ：A device experience is defined by how a device is most commonly used and the technical capabilities or limitations it possesses.
RESS 的本质还是服务器端动态的生成，返回 HTML、JS、CSS、图像等资源文件，但是只使用同一个 URL 就可以提供给移动端定制化更强的网页，同时还大大节省了网络资源。 -
-
-
- -
-
这下，我们的网站可以更牛逼的 “响应” 各个平台了。 -
（对，我还是称之为响应：这的确还是在“响应”啊 ，不是吗？） -
-
-
但是等下…… -
后端开发成本上去了，前端开发成本也上去了，配合着估计产品、设计资源也都上去了，那我们为什么不干脆把 移动设备网站 和 桌面设备网站 分开呢！？ -
-
-
是啊，如果你的需求真的都到这一步了，你的移动网站也应该可以被称作 WebApp 了。这种时候，把移动设备网站彻底分开或许真的是更好的选择。 -
-
开发资源如此充足，你还可以让专门的团队来维护移动端的网站。 -
（嗯，BAT 就是这么干的） -
-
于是又一个概念来了： -
-
- 不过，它有那么独立么？ -
我们知道，我们访问网站是通过 URL 来访问的。 -
将移动网站 和 桌面网站 分开，如果不使用 RESS 技术，往往也就意味着要维护两个URL（不同的二级域名） -
难道我们要让所有桌面用户自觉访问 taobao.com ，所有 移动用户 都自觉访问 m.taobao.com ？ -
-
不可能吧 ＝ ＝。 -
-
于是，我们还是得依靠前端或服务器端的一次 “响应”（设备检测），做 URL 重定向，才能将不同设备的用户带到那个为他们准备的网站。 -
-
-
-
所以其实在我看来，手机和PC端分开来写，只是 狭义响应式设计 的一种发展和延伸罢了。他们的界限没有，也并不需要那么清晰。 -
-
就如开题所引用的： -
-
事实上，你可以认为如果一种设计不能兼顾两种平台的主要差别，就不能算是合格的响应式设计。 -
“而无论是用什么解决方案。” —— 这句是我补的。 -
-
-
-
-
故我的结论是： -
-
这不是一个二选一的问题，而是选择一个合适的度（你的桌面版本代码与移动版本代码分离、耦合的程度） -
-
而这个度，则是由你的设计需求决定的。 -
而我们的需求原点其实也很简单： -
-
“根据你的产品特点，进行两种不同的设计”。 -
-
-
以上。 -
-
-
diff --git a/_posts/2014-12-13-wechat-block-kuaidi.markdown b/_posts/2014-12-13-wechat-block-kuaidi.markdown deleted file mode 100644 index 7118692fb31..00000000000 --- a/_posts/2014-12-13-wechat-block-kuaidi.markdown +++ /dev/null @@ -1,70 +0,0 @@ ---- -layout: post -title: "如何看待微信屏蔽快的打车事件？" -subtitle: "恰有小感。" -date: 2014-12-13 -author: "Hux" -header-img: "img/post-bg-kuaidi.jpg" -tags: - - 知乎 - - 产品 ---- - -> 这篇文章转载自[我在知乎上的回答](http://www.zhihu.com/question/26774049/answer/35041458) - - -
- 唉。今天恰巧有感，过来小聊几句。 -
还是要先声明下：所有言论出自个人，与阿里和我所在的团队无关。 -
-
-
正文。 -
-
应该很多互联网公司都有这项 “福利” —— 加班到X点以后，报销打车费。 -
阿里大约是晚上9点。 -
-
初进阿里时还不习惯，想着6点下班后，吃个免费晚饭，赶快坐地铁回家。 -
后来一是发现高峰期的地铁简直要命，二是确实有太多需求做不完， 平常经常会说： “这个我们晚上再谈…” -
-
所以晚上加班就成了公司里很多人的常态 ，就算今天 8 点多就已经工作得差不多了，也会习惯性得等到 9 点左右，叫个车回家。 -
-
于是，每天 9 ～ 12 点间，公司里的叫车声、电话约车声、络绎不绝。我们团队私下里也有个微信群，用以和工作的旺旺群区分。在打车软件玩起红包返现后，大家就都会在群里分享叫车红包，52个人的群，有时一分钟内不抢，红包就没了。 -
-
-
众所周知的，阿里和快的打车的关系。 -
-
所以群里好像约定俗成般的，从来就没有出现过滴滴的红包。而由于红包返现利滚利带来的超强用户粘性，大家连叫车也都开始只用快的了。 -
- - 结果好景不长，微信突然就玩了这么一手，直接把快的打车屏蔽了。 -
当天大家就发现了，还讨论了下对策……比如什么「先分享到微博，然后把链接复制出来，再发到旺旺群」…… -
-
嗯。我 TM 也觉得挺拼的。。 -
于是大约微信群就沉寂了一天… -
-
然后才第二天……第一个滴滴红包就在群里出现了！那时的文案还是什么：“4个小伙伴，3个用滴滴！红包召唤新伙伴归队啦！” -
我我我我当时就不由自主的纠结了一会儿 “价值观” ，放下手机 debug 去了…… -
等我再想起来，点开链接一看：特么的……「红包已抢完」。 -
-
。。。 -
再后来。就根本收不住了，滴滴红包那个飘。 -
-
-
唉其实我就是想说：这也就一天……用户习惯就被彻底干翻过来了。 就算是盟友…也没救。 -
- - 所以我今天还是打着滴滴回来的……分享红包的一瞬间，心里突然一阵小惆怅。就回来写下了这段答案。 -
-
说了半天，好像也没说到什么干货…权当故事听吧。 -
其实你要问我这有没有违反互联网平等开放法则什么的。我觉得上面 @覃浩tommy@赛门 都说得挺好的，两种思路而已，大家可以自行选择。 -
-
但是关于怎么看待，其实这次我以普通用户的身份来说……真心觉得：「小良心小正义感在强需求面前真特么太弱了」。更何况这个强需求被干掉的同时还双手奉上了替代品。 -
-
所以大厂们你们就使劲撕逼吧，需要打到用户脸时，多给糖多给枣就好了。 -
-
-
哦对了，今天微信宣布朋友圈内限制分享未备案网页了。 -
枣呢 ！？！？ -
-
-
diff --git a/_posts/2015-03-10-apple-event-2015.markdown b/_posts/2015-03-10-apple-event-2015.markdown deleted file mode 100644 index 68c1f26fe8c..00000000000 --- a/_posts/2015-03-10-apple-event-2015.markdown +++ /dev/null @@ -1,59 +0,0 @@ ---- -layout: post -title: "如何评价 2015 年 3 月 9 日 Apple 春季发布会？" -subtitle: "聊聊科技与新式奢侈品" -date: 2015-03-10 12:00:00 -author: "Hux" -hidden: true -header-img: "img/post-bg-apple-event-2015.jpg" -tags: - - 知乎 - - 产品 ---- - -> 这篇文章转载自[我在知乎上的回答](http://www.zhihu.com/question/28617408/answer/41626694) - - -
-
一个 gay，一个 gay-like ，带着 Apple 向着新式奢侈品的方向飞去了。
-
无论是 Apple Watch ，还是 new MacBook，这次发布会都象征着 Apple 更明显的转型。 -
-
不应该再把 Apple 跟 Microsoft 简单粗暴的对比，它们的受众产生了愈大的差异。两家公司对数字时代有着完全不同的战略，它们改变世界的思路，跟盖茨-乔布斯时代比有着更巨大的分歧。 -
-
MS 还是 MS，就像纳德拉 7 月的全员信，微软的战略还是回到了“生产力”。其实微软对“极致”，对“未来”的追求是一种很直观的，我们最初理解的科技，比如手势交互、虚拟现实、机器化自动化、高效办公什么的。微软的受众更多的也还是面向生产力、工作群体（工程师、办公人员）。所以软狗们在知乎永远可以说微软 blah blah，因为对于这部分场景，微软确实有着不可替代的牛逼。 -
-
而 Apple 则逐渐转变成为数字时代的 LV。这并不是说它放弃了科技，而是“科技追求极致”的另一种可能性 —— 科技与人文的交汇，甚至是科技与时尚的跨界融合。 -
-
让我们来稍稍想象一下未来： -
-
科技与生活的融合一定是越来越紧密的。更多的“物件”将与科技结合，而这些智能设备也将越来越普及，它们面向的人群，会越来越宽，直到覆盖所有人。 -
可以说现在的科技还是很生硬的，我们很容易把科技和 Geek、Nerd 联系在一起。当一个东西和科技沾边时，我们往往会很清楚的意识到：“哦，这是一个科技产品”，于是我们忽略了其他东西，更多的去关注它的科技性（功能性），但是未来不一样。 -
未来的科技将会很平常，未来的科技将会更加隐形，就像现在的眼镜、家具、衣服、箱包……普通人谁还会在乎它们背后复杂的材料科学与工艺？我们只会觉得它们是生活必需品，然后去在乎它们的外观、舒适性，挑选自己喜欢的产品。 -
-
科技也一样，当科技无处不在时，我们对“科技产品”本身的功能性要求，就不再是唯一的考量。 -
-
-
LV 的包之所以成为奢侈品，不止是因为“当它作为一个包时，它的功能性（选材、做工）非常优秀，结实耐用”，还因为它的艺术性，观赏性，精致感，幸福感，社会价值等等，带来的种种溢价。 -
-
而 Apple Watch、new MacBook，很明显在做相同的事情。 -
-
说到奢侈，“奢侈”这两个字，在我国基本上是贬义的，词典里的翻译是“挥霍浪费钱财，过分追求享受”，但 Luxury 在英文中其实要中性许多。 -
-
与旧式奢侈相比，新奢侈主义在这一代中产消费者中则被广泛接受。所谓新奢侈主义指的是在同类产品中服务质量更高，品位更高的产品，让消费者心驰神往。它们价格不菲，但是还不至于昂贵到可望不可即。 -
-
德国的实业家拉茨勒在《奢侈带来富足》(2001)一书中对旧式奢侈和新式奢侈做过有趣的论述。他以手机为例说明了两种方式的不同：如果一部手机是因为其先进的技术和为客户提供超值的功能而使价格出众，那么生产和消费这样的手机就是需要倡导的新式奢侈；相反，如果一部手机不是因为卓越的技术性能，而是因为手机套上了嵌有钻石的黄金外壳而使得价格昂贵，那么生产和消费这样的手机就是令人憎恶的旧式奢侈。 -
-
补充一下：这句话出自 2001 年，放在现在来看其实并不是完全适用的。 -
-
手机对当今社会的意义早已不是简单的通讯设备。真正的区别还是在那句话：“Design is about how it works”，新式奢侈的内涵在于产品的某个设计是真的有意义，还是单纯的为了贵而贵。 -
对于当今数码产品，工业设计、艺术设计是其作为消费品非常重要的部分，如果你是为了给用户提供更多的外观选择而使用黄金，或是为了硬度使用钻石。而不是单纯的堆砌它们来增加价格，那么这些设计都是符合“新式奢侈”的内涵的。 -
-
所以当我们回过头看看 new MacBook，私以为是数字产品界新式奢侈品的典型。 -
-
当我们吐槽 Apple 为了极致的轻薄牺牲了主频、风扇、接口，当我们吐槽买它就是买电池，当我们拿它与 MBA、MBP、Surface 对比吐槽它的 “参数/价钱比” …… -
-
其实人家的受众是那些有消费能力追求生活质量的 Sir or Lady，它们并不需要天天对着电脑做开发、重型办公或者打游戏，对于只需要便携安静（轻薄＋续航＋无风扇）、看看电影（Retina Display）、又希望无时不刻彰显自己的品味与身份（外观优雅＋极致设计）的他们来说，new Macbook 简直是最适合“佩戴”的轻奢品。 -
-
-
有人说 Apple Watch 简直是 Jony Ive 这个一心向往做奢侈品设计的天才将 Apple 引入了歧途里，而我却觉得科技与时尚的结合为何就不是一件美丽的事情？ -
diff --git a/_posts/2015-03-25-digital-native.markdown b/_posts/2015-03-25-digital-native.markdown deleted file mode 100644 index fbd3e334407..00000000000 --- a/_posts/2015-03-25-digital-native.markdown +++ /dev/null @@ -1,125 +0,0 @@ ---- -layout: post -title: "hUX 随想录（一）：Digital native 数字原住民" -subtitle: " 两岁的侄女天天叫着手机手机 " -date: 2015-03-25 -author: "Hux" -header-img: "img/post-bg-digital-native.jpg" -catalog: true -tags: - - hUX 随想录 - - UX/UI ---- - -> 那是一种与生俱来的天赋，就好像矮人天生擅长舞锤，而精灵则拥有魔法庇护。那些数字时代的原住民们，天生具备着一种操纵数字世界的领悟。 - -## 前言 - -从 2010 年 iPhone 4 横空出世席卷中国，到时隔不到半月的 Apple 2015 发布会。短短几年里，身边就几乎再也看不到“非智能手机”的身影了。 - -想想发布那时（2010.6.8），博主应该还是一个高一小屁孩，等着暑假快点到来。虽然父上大人用着 iPhone 3GS ，不过那时我对 Apple 可没啥感觉，还用着后来被 Apple 干翻的 Nokia （5320），抱着算是被 Apple 干翻的 IBM ，偶尔玩玩后来被 Apple 干翻的 Adobe Flash…… -虽然不是含着着金 iPhone 出生的一代，但好歹也算是摸着电脑长大的一代人，估摸着也算是 **Digital native** 了。你说这词是什么意思？别急，我们慢慢说。 - - -## 正文 - -今年暑假回了两个老家，也看望了不少长辈。 -长辈们的手机果然都进行了可以想见的升级，除了爷爷奶奶辈外，清一色的 iPhone 或者 Android 4.2+ ，呃，没有 WP。 - -智能手机啊智能手机，Smart Phone —— 聪明又能干的手机。可是每每我看到年龄稍微大点的长辈们顶着一附花镜，瞪大了眼睛，一只手托着，另一只手则伸出一根手指小心翼翼得戳着硕大的屏幕时，我就瞬间觉得这哪里是 Smart ，分明是 Stupid Phone 。于是我就看着父辈们不厌其烦得教着老人家如何解锁，如何打电话，回短信。却又常常要像子女们请教微信里的图片存到了哪（这基本都是 Android 的毛病），朋友圈的文章如何分享转发，视频和小视频为什么不一样，视频通话怎么玩这一类“高级问题”。 - -这现象既尴尬又有趣，至少我 10+ 岁时还觉得自己什么都得请教父母。可是这一代孩子，居然能天天被父母请教手机问题然后理直气壮得回一句：“你怎么连这都不会？” - -
-**最让我惊讶的还是我两岁的小侄女阿布。** -两岁的小孩子，刚刚能跑能跳，学会说话也不久，甚是可爱。 - -第一次感受阿布的神奇，是跟阿布和阿布爸（姐夫）在车的后座上坐着，阿布突然就向姐夫喊起了“手机，要手机…”。“就玩一会儿哦” 于是姐夫从口袋里掏出了 iPhone ，放到了比手机小好几号的小手上。我第一反应只是觉得好玩，大概小孩子觉得这个黑漆漆但是又能被点亮的“玩具”很好玩吧，姐夫和姐姐又无时不在教小孩子认东西，小孩子记得这个“玩具”叫作手机也很正常。 - -**紧接着阿布就用她的行为狠狠得打了我的脸：Home 键 → 滑动解锁 → 照片 App → 点开一张照片然后开始左翻右看；一串 Combo 动作娴熟一气呵成。** - -大家脑补一下柯南那个“脑海中‘唰’的一道亮光”！对对我当时就是这样，**然后就犯了职业病，连续几天都开始观察阿布是如何玩手机的。**（小孩子玩手机不好，是要控制时间的） - - -#### I. 超强的学习能力 - -小孩子的大脑思维简单却又有着惊人的学习能力，他们十分擅长模仿，而且能非常高效的对信息进行记忆和处理。 - -**我确信阿布已经在无数次学习中完美得理解了 Home 键的含义。**阿布知道主屏上的每一个长得一样的东西（App Icon）都可以点击，点击之后就会进入一个新的东西，如果阿布不喜欢，她知道按 Home 键返回主屏。 - -阿布不完全具备分辨众多 icon 的能力，但唯独最喜欢“照片”这个应用，她总是可以在几次划屏之后找到并打开它。 -**可以说理解下图 “主屏幕与应用” 这样的一级逻辑是相对比较轻松的，而且 Home 键作为物理按键，认知成本也比屏幕中的虚拟按钮要低得多。** - -
-    Icon
-主屏幕 ⇌ 应用
-    Home 
-
- -可是接下来阿布在照片应用内的表现就足以说明问题：阿布不但能够对“照片方块”进行归类学习，知道**“既然一张照片可以点开，那么每张都是可以的”**。阿布居然还学会了 **Back 按键**的使用！ -要知道阿布是一定不认识 Back 箭头右边的文字的。我猜测阿布可能是通过空间位置记忆（屏幕左上角），也有可能是通过图形记忆的（要知道人对图形的认知能力要远高于文字）。总之无论如何，阿布学会了 Back ，并可以进行下图这样“如此复杂的操作”了： - -
-  照片Icon     One   One
-主屏幕 ⇌ 相簿列表 ⇌ 相簿 ⇌ 单张照片
-    Home      Back  Back
-
- -而且其实在“单张照片”这个环节是有个“坑”的：**如果点一下照片，所有导航会消失（切换到照片全屏观看模式），要再点一下照片导航才会回来。** 我不能清楚的知道阿布是否了解了这个规律，但是一旦阿布看到 Back 键回来时就会懂得依靠按它来返回。 - - -#### II. 完美理解隐喻 - -小孩子的思维是直白的。它们不会试图掩盖什么想法，它们想到什么就会去做什么。 - -我们都知道如果一个东西在你的右边，那么你需要把这个“世界”向左拉，做一个相对运动，你才能重新看到这个东西。小孩子不用知道什么相对运动，但是自然而然的就能懂 —— **阿布知道在屏幕上左右划能让手机里的这个小世界跟着移动起来，阿布知道被划走的东西相反划就可以划回来。** - -这就是我们常说的**物理隐喻**，小孩子不知道物理也不知道什么隐喻，But it works. - -不过让我惊讶的不是这个，我 2 岁的时候要是有 iPhone ，我应该也是能那么瞎扒拉一两下的吧…… -真正让我觉得非写此文不可的是：有一次，我给阿布玩我的 iPhone ，阿布照常打开了相册开始翻，**说时迟那时快，来了一条微信通知！** - -对对对，就是那个从上往下滑下来 ↓↓↓↓ 的 Push Notification. - -
-微信 
-Kant 给你发了一个红包 
-
- -**接着高潮就来了，阿布非常淡定的伸出小手，把推送给我顶 ↑↑↑↑ 回去了！！** -卧槽你们一定不能体会我当时有多惊讶。 - -**隐喻啊！从上面掉下来的东西，不 想 要 的 话 就可以划回去好吗。** 小孩子对数字世界交互隐喻的理解，真是完爆了不知道多少 Digital immigrant (下文会解释) 。 - - -#### III. 世界观的树立 - -这是为什么？为什么小孩子可以具备对数字世界如此的领悟能力？ - -我的答案不难理解：**数字世界已经完美地融入了阿布的世界体系里。阿布从小就在感受数字世界的“定律”，这种学习，对于阿布来说，与她对现实世界的学习完全无异。** - -**这种感觉就好像我们从小其实就在感受这个世界的物理规律**：我们不知道万有引力，但是我们知道东西从手中放开就会掉下去；我们不知道热交换，但是我们知道冷水和热水可以对成温水；我们不知道杠杆原理，但是我们知道在门把手附近推门会更省力…… - -有个很好玩的案例可以证明阿布脑中体系的建立过程：我的相册中有不少 UI 截屏，**截屏对于阿布来说是个更有难度的认知（就好像大多数动物都无法认知镜子一样）** 。当 Back 按钮成为阿布脑海中对虚拟世界“返回”的定义，就算是截屏中的 Back ，阿布也会毫不犹豫的点上去，可是居然没有效果 —— **这违背了阿布的认知，于是她会感到疑惑和不安**，直到下一次 Back 奏效…… - -世界观是一个需要长时间建立起来的东西，**当我们跟小孩子一样对世界最为无知时，我们也对世界最为好奇，于是眼前的一切都一股进脑。然后大脑进行着快速的记忆和学习，逐渐形成了你对这个世界的认知。** -所以世界观也是一个很顽固的东西，已经建立起来的部分很难摧毁，新的东西也就没有太多立足之处 —— 这也算是解释了为什么小孩子学习数字设备如此之快，而越是大龄就相对越难接受（当然这其实与不同年龄大脑的生命活动有关系，这里只是比喻的说法） - -说到这里，我们终于可以回归最初的问题： -什么是 Digital native ？还有与之对应的 Digital immigrant ? - -> **Digital native，数字原住民**： 指代从出生开始就习惯有互联网、无线技术的一代人 （logically there's a whole generation of individuals for whom concepts such as the Internet and wireless technology are just humdrum, because they've never lived in a world where they didn't exist. These are the so-called digital natives） -> -> **Digital immigrant，数字移民**：指代更早的一代人，已经情愿或者不情愿地适应了这个数字世界，并且将各类数字工具运用到生活当中。（Digital immigrants are their antithesis, being the folks born earlier who, either reluctantly or enthusiastically, have adapted to the digital world and incorporated its tools into their lives.） - -定义如此，但其实边界模糊。而真正重要的是：**或许在这个飞速发展的世界里，只有保持小孩般的好奇与初心，才能不被时代轻易的抛弃。** - -## 结语 - -我一度欣喜阿布是不是将来要成为计算机或者交互领域的大师，可是转念一想**我更愿意相信这一代小孩子都将具备如此神力**。就好像世界如果重新建立了秩序，那么最先适应秩序的一定是在新秩序下诞生的孩子们。因为他们对世界的认知里没有任何过去，也就没有任何 boundary 。 - -我经常想象假如我出世在一个以魔法为秩序的纪元里，那个世界里的小孩子一定生来就具备对魔法的领悟与操纵能力。**我想那种能力或许不是血脉或者种族里自带的天赋吧，而是从你呱呱坠地，开始认知、学习这个世界的那一天起，魔法就习以为常地印在了你的世界观里。**你从小就知道母亲空手就可以变个小太阳温暖你，而父亲则可以挥挥手放出一片星空来逗你开心。 - -**于是你坚定不移，当你第一次有力气挥动你的小胳膊时，一道流星划过天际。** - - diff --git a/_posts/2015-03-31-e2e_user_scenarios.markdown b/_posts/2015-03-31-e2e_user_scenarios.markdown deleted file mode 100644 index 74bd62cecb8..00000000000 --- a/_posts/2015-03-31-e2e_user_scenarios.markdown +++ /dev/null @@ -1,78 +0,0 @@ ---- -layout: post -title: "Definition of End to End User Scenarios" -date: 2015-03-31 -author: "Hux" -header-img: "img/post-bg-e2e-ux.jpg" -published: false -lang: en -tags: - - UX/UI - - En ---- - - -### End to end? - -To explain what is "End to End User Scenarios", we should first explain what is "End to End", which we can called E2E for short. - -There is not a very clear definition of E2E in wiki.[[1]](#ref1) In dictionary, it can both refer to "throughout" or "the end of one object connect to the end of another object".[[2]](#ref2) - -E2E is usually used in Logistics, Computer Networking and Software Testing. For example, End-to-end testing is a methodology used to test whether the flow of an application is performing as designed from start to finish. The entire application is tested in a real-world scenario. - -So in my view, the most essential part of E2E is that **we must focus on the entire process, including every parts in a use case.** - - -### User Scenarios! - -User scenarios is a common term in UX Design,[[3]](#ref3)[[4]](#ref4) which expands upon our persona and user stories by including details. It told us about users' motivation, goals and actions on our products. - -To make it better, there comes **"End to End User Scenarios", not just tell a fragment of users' activities, but pay attention to the entire process the user undergoes.** - -That means we should consider the whole things from the start point that user want to use our products to the ended up point that user get results and leave our products. - -Only when we know **who** does **what** on our products, **how** and **why** they do it, can we define design requirements concrete enough to actually meet them. So it really helps us to improve our UX of our products. - - -### Let's go deeper... - -We just put the two terms together and give it a explanation, but it can be farther. When we truly design an experience, End to End User Scenarios can helps more: - -* **Extend the scope** - -There is a interesting instance [[5]](#ref5) told that sometimes we are already satisfy of our designed UX, but if we look beyond the both ends of the designed experience by extending the scope of the timeline before and after… we may sadly realize that it’s a complete car crash outside the scope of the designed experience... - -Try to extend the scope and consider more, so can we design a much broader experience for our user. - -* **Shorten the path** - -UX Designers always dive into a User Flow and try to shorten the user paths. The idea of End to End User Scenarios can do the same things. - -For example, in the past, if I want to know the weather today. I should typically visit a search engine website, input and search "weather", click the first link that search result page shows, then jump into a kind of weather website like "The Weather Channel", and finally, I got today's weather information! - -But wait! **Just consider it using "End to End User Scenarios"**, I just want to know about weather so I use search engine right? why should I took a so long user path to get there? Smart Search Engine should told me the weather directly. - -That is what all search engine have doing nowadays. - - -### In sum - -There is many design tools like "End to End User Scenarios" were used by designers, they are really awesome. But the most essential things in my opinion is, still, always thinking about user. All this tools are powerful only based on a truly user-centric mind. - -From my perspective, the "End to End User Scenarios" can be generally defined as **"Entire Process Considered, User Requirement Centric, Anticipated Experince Design".** - - - -That's all, thank you. - -### References - -1.[End-to-end - Wikipedia, the free encyclopedia](http://en.wikipedia.org/wiki/End-to-end) - -2.[end-to-end - definition of end-to-end by The Free Dictionary](http://www.thefreedictionary.com/end-to-end) - -3.[How User Scenarios Help To Improve Your UX - The Usabilla Blog](http://blog.usabilla.com/how-user-scenarios-help-to-improve-your-ux/) - -4.[How to Create User Stories, Scenarios, and Cases](https://www.newfangled.com/how-to-tell-the-users-story/) - -5.[Designing end-to-end user experiences. | 90 Percent Of Everything](http://www.90percentofeverything.com/2008/11/11/designing-end-to-end-user-experiences/) diff --git a/_posts/2015-04-14-unix-linux-note.markdown b/_posts/2015-04-14-unix-linux-note.markdown deleted file mode 100644 index 9e61adfe67a..00000000000 --- a/_posts/2015-04-14-unix-linux-note.markdown +++ /dev/null @@ -1,201 +0,0 @@ ---- -layout: post -title: "Unix/Linux 扫盲笔记" -subtitle: "不适合人类阅读，非常水的自我笔记" -date: 2015-04-14 -author: "Hux" -header-img: "img/post-bg-unix-linux.jpg" -catalog: true -tags: - - 笔记 ---- - -> This document is not completed and will be updated anytime. - - -## Unix - - -> Unix is a **family** of multitasking, multiuser computer OS. - - -Derive from the original **AT&T Unix**, Developed in the 1970s at **Bell Labs** (贝尔实验室), initially intended for use inside the **Bell System**. - -- #### Bell Labs -Bell 和 AT&A 在那时已经是一家了，可以看到那时的通信公司真是一线 IT 公司呢。 -**C 语言也是 Bell Labs 的产物**，从一开始就是为了用于 Unix 而设计出来的。所以 Unix （在 73 年用 C 重写）在高校流行后，C 语言也获得了广泛支持。 - - - -AT&T licensed Unix to outside parties(第三方) from the late 1970s, leading to a variety of both **academic** (最有有名的 BSD ) and **commercial** (Microsoft Xenix, IBM AIX, SunOS Solaris) - -- #### Xenix -微软 1979 年从 AT&A 授权来的 Unix OS，配合着 x86 成为当时最受欢迎的 Unix 发行版。后来 M$ 和 IBM 合作开发 OS/2 操作系统后放弃，后来最终转向 **Windows NT**。 - -- #### BSD -**Barkeley Software Distribution**, also called Berkeley Unix. Today the term "BSD" is used to refer to any of the BSD descendants(后代) which together form a branch of the family of Unix-like OS.(共同组成了一个分支) - - **BSD 最大的贡献是在 BSD 中率先增加了虚拟存储器和 Internet 协议**，其 TCP/IP(IPv4 only) 代码仍然在现代 OS 上使用（ Microsoft Windows and most of the foundation of Apple's OS X and iOS ） - - BSD 后来发展出了众多开源后代，包括 FreeBSD, OpenBSD, NetBSD 等等……很多闭源的 vendor Unix 也都从 BSD 衍生而来。 - -- #### FreeBSD & Apple -FreeBSD 不但是 Open Source BSD 中占有率最高的，还直接影响了 Apple Inc : NeXT Computer 的团队在 FreeBSD 上衍生出了 NeXTSTEP 操作系统，这货后来在 Apple 时期演化成了 **Darwin** ，这个“达尔文”居然还是个开源系统，而且是 the Core of **Mac OS X** and **iOS**. - -- #### NeXTSTEP -An **object-oriented**, multitasking OS. Low-level C but High-level OC language and runtime the first time, combined with an **OO aplication layer** and including several "kits". -大家都知道 NeXT 是 Steve Jobs 被 forced out of Apple 后和 a few of his coworkers 创办的，所以 **NeXTSTEP 绝对是证明 Jobs 实力的作品。** - -- #### Darwin -[Darwin](https://en.wikipedia.org/wiki/Darwin_(operating_system)), the core set of components upon which Mac OS X and iOS based, mostly POSIX compatible, but has never, by itself, been certified as being compatible with any version of **POSIX**. (OS X, since Leopard, has been certified as compatible with the Single UNIX Specification version 3) -**所以说 Mac OS X 算是很正统 Unix 的了** - -- #### POSIX -可移植操作系统接口, Portable Operating System Interface, is a family of standards specified by the IEEE from maintaining compatibility between OS, defines the API along with Command Line Shells and utility interfaces, for software comaptibility with variants of Unix and other OS. - - Fully POSIX compliant: - - OS X - - QNX OS (BlackBerry) - - Mostly complicant: - - Linux - - OpenBSD/FreeBSD - - Darwin (Core of **iOS** & OS X) - - **Android** - - Complicant via compatibility feature （通过兼容功能实现兼容） - - Windows NT Kernel - - Windows Server 2000, 2003, 2008, 2008 R2, 2012 - - Symbian OS (with PIPS) - - Symbian was a closed-source OS. - - -## Unix-like - -> A Unix-like (sometimes referred to as UN*X or *nix) operating system is one that behaves in a manner similar to a Unix system, while not necessarily conforming to or being certified to any version of the **Single UNIX Specification**. - -There is no standard for defining the term. -其实 Unix-like 是个相对模糊的概念： - -* 最狭义的 Unix 单指 Bell Labs's Unix -* 稍广义的 Unix 指代所有 Licensed Unix, 即通过了 SUS 的 Unix-like ，比如 OS X -* 最广义的 Unix 即所有 Unix-like 系统，无论它是否通过过任何 SUS，包括 Linux，BSD Family 等 - -#### Single UNIX Specification -The Single UNIX Specification (SUS) is the collective name of a family of standards for computer OS, compliance with which is required to **qualify for the name "Unix"**, like **POSIX**. - -#### Apple iOS -iOS is a **Unix-like OS based on Darwin(BSD)** and OS X, which share some frameworks including Core Foundation, Founadtion and the Darwin foundation with OS X, but, Unix-like shell access is not avaliable for users and restricted for apps, **making iOS not fully Unix-compatible either.** - -The iOS kernal is **XNU**, the kernal of Darwin. - -#### XNU Kernel -XNU, the acronym(首字母缩写) for ***X is Not Unix***, which is the **Computer OS Kernel** developed at Apple Inc since Dec 1996 for use in the Mac OS X and released as free open source software as part of Darwin. - - -## Linux - - -> Linux is a Unix-like and mostly POSIX-compliant computer OS. - - -![Unix_timeline](http://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Unix_timeline.en.svg/800px-Unix_timeline.en.svg.png) - - -#### Linux Kernel - -严格来讲，术语 Linux 只表示 [Linux Kernel](http://en.wikipedia.org/wiki/Linux_kernel) 操作系统内核本身，比如说 Android is Based on Linux (Kernel). Linus 编写的也只是这一部分，一个免费的 Unix-like Kernel，并不属于 GNU Project 的一部分。 - -但通常把 Linux 作为 Linux Kernel 与大量配合使用的 GNU Project Software Kit (包括 Bash, Lib, Compiler, 以及后期的 GUI etc) 所组合成的 OS 的统称。（包括各类 Distribution 发行版） - -这类操作系统也被称为 **GNU/Linux** - - -#### GNU Project - -The GNU Project is a **free software, mass collaboration** project, which based on the following freedom rights: - -* Users are free to run the software, share (copy, distribute), study and modify it. -* GNU software guarantees these freedom-rights legally (via its license). -* So it is not only FREE but, more important, FREEDOM. - -In order to ensure that the *entire* software of a computer grants its users all freedom rights (use, share, study, modify), even the most fundamental and important part, **the operating system**, needed to be written. - -This OS is decided to called **GNU (a recursive acronym meaning "GNU is not Unix")**. By 1992, the GNU Project had completed all of the major OS components except for their kernel, *GNU Hurd*. - -With the release of the third-party **Linux Kernel**, started independently by *Linus Torvalds* in 1991 and released under the GPLv0.12 in 1992, for the first time it was possible to run an OS **composed completely of free software**. - -Though the Linux kernel is not part of the GNU project, it was developed using GCC and other GNU programming tools and was released as free software under the GPL. - -Anyway, there eventually comes to the **GNU/Linux** - - -* **GPL**: GNU General Public License -* **GCC**: GNU Compiler Collection - -其他与 GPL 相关的自由/开源软件公共许可证： - -* [Mozilla Public License](http://en.wikipedia.org/wiki/Mozilla_Public_License) -* [MIT License](http://en.wikipedia.org/wiki/MIT_License) -* [BSD Public License](http://en.wikipedia.org/wiki/BSD_licenses) - * GPL 强制后续版本必须是自由软件，而 BSD 的后续可以选择继续开源或者封闭 -* [Apache License](http://en.wikipedia.org/wiki/Apache_License) - - -![Public License](/img/in-post/open-source-license.png) - -#### Android - -Android is a mobile OS based on **Linux Kernel**, so it's definitely **Unix-like**. - -**Linux is under GPL so Android has to be open source**. -Android's source code is released by Google under open source licenses, although most Android devices ultimately ship with a combination of open source and proprietary software, including proprietary software developed and licensed by Google *(GMS are all proprietary)* - -#### Android Kernel - -Android's kernel is based on one of the Linux kernel's long-term support (LTS) branches. - -**Android's variant of the Linux kernel** has further architectural changes that are implemented by Google outside the typical Linux kernel development cycle, and, certain features that Google contributed back to the Linux kernel. Google maintains a public code repo that contains their experimental work to re-base Android off the latest stable Linux versions. - -Android Kernel 大概是 Linux Kernel 最得意的分支了，Android 也是 Linux 最流行的发行版。不过，也有一些 Google 工程师认为 Android is not Linux in the traditional Unix-like Linux distribution sense. 总之这类东西就算有各种协议也还是很难说清楚，在我理解里 Android Kernel 大概就是 fork Linux Kernel 之后改动和定制比较深的例子。 - - -#### Android ROM - -既然提到 Android 就不得不提提 Android ROM - -ROM 的本义实际上是只读内存： - -**Read-only memory** (ROM) is a class of storage medium used in computers and other electronic devices. Data stored in ROM can only be modified slowly, with difficulty, or not at all, so it is **mainly used to distribute firmware (固件)** (software that is very closely tied to specific hardware, and unlikely to need frequent updates). - -ROM 在发展的过程中不断进化，从只读演变成了可编程可擦除，并最终演化成了 Flash - -* PROM (Programmable read-only memory) -* EPROM (Erasable programmable read-only memory) -* EEPROM (Electrically erasable programmable read-only memory) - * Flash memory (闪存) - -Flash 的出现是历史性的，它不但可以作为 ROM 使用，又因其极高的读写速度和稳定性，先后发展成为U盘（USB flash drives）、移动设备主要内置存储，和虐机械硬盘几条街的固态硬盘（SSD），可以说这货基本统一了高端存储市场的技术规格。 - -所以我们平时习惯说的 ROM 其实还是来源于老单片机时代，那时的 ROM 真的是写了就很难（需要上电复位）、甚至无法修改，所以那时往 ROM 里烧下去的程序就被称作 firmware ，固件。久而久之，虽然技术发展了，固件仍然指代那些不常需要更新的软件，而 ROM 这个词也就这么沿用下来了。 - -所以在 wiki 里是没有 Android ROM 这个词条的，只有 [List of custom Android firmwares](http://en.wikipedia.org/wiki/List_of_custom_Android_firmwares) - -> A custom firmware, also known as a custom ROM, ROM, or custom OS, is an aftermarket distribution of the Android operating system. They are based on the Android Open Source Project (AOSP), hence most are open-sourced releases, unlike proprietary modifications by device manufacturers. - -各类 Android ROM 在 Android 词类下也都是属于 **Forks and distributions** 一类的。 - -所以我说，其实各类 Android ROM 也好，fork Android 之流的 YunOS、FireOS 也好，改了多少东西，碰到多深的 codebase ……**其实 ROM 和 Distribution OS 的界限是很模糊的**，为什么 Android 就不可以是移动时代的 Linux ，为什么 Devlik/ART 就不能是移动时代的 GCC 呢？ - -#### Chrome OS - -Chrome OS is an operating system based on the **Linux kernel** and designed by Google to work with web applications and installed applications. - -虽然目前只是个 Web Thin Client OS ，但是 RoadMap 非常酷…… - -* **Chrome Packaged Application** (Support working offline and installed) -* **Android App Runtime** (run Android applications natively...fxxking awesome) - -平复一下激动的心情，还是回到正题来： - -#### Chromium OS - -Chrome OS is based on Chromium OS, which is the open-source development version of Chrome OS, which is a **Linux distribution** designed by Google. - -For Detail, Chromium OS based on [Gentoo Linux](http://en.wikipedia.org/wiki/Gentoo_Linux), emm... - diff --git a/_posts/2015-04-15-os-metro.markdown b/_posts/2015-04-15-os-metro.markdown deleted file mode 100644 index 375dc689aa3..00000000000 --- a/_posts/2015-04-15-os-metro.markdown +++ /dev/null @@ -1,112 +0,0 @@ ---- -layout: post -title: "hUX 随想录（二）：操作系统的浪漫主义 —— Metro 篇" -subtitle: "信息、载体、抽象、UI 设计乱谈" -date: 2015-04-15 -author: "Hux" -header-img: "img/post-bg-os-metro.jpg" -catalog: true -tags: - - hUX 随想录 - - UX/UI ---- - - -> 操作系统的背后不只是冷冰冰的 0 和 1 ，数字时代的设计师们，如初神般刻画着新世界的秩序。信息、量子、宇宙，他们取世间万物为灵感来表达自己，那是它们对数字时代最浪漫的隐喻。 - -## 前言 - -操作系统，数字时代当之无愧的地基。当大部分从业人员都更关注它的技术与功能时，操作系统的 UI 设计师们却赋予了它无限的艺术气息：他们用充满着浪漫主义幻想色彩的设计语言，配合着物理定律般严谨的交互体系，描绘着自己心目中的数字世界，那些界面 的背后是他们对数字世界的思考、理解、期待、抽象与隐喻，**这些艺术思想支撑着浮在表面的设计**。他们用一切你熟悉或不熟悉的方式，告诉世人： - -*“看呐，那个虚拟又真实的世界”* - - -## Metro - -我们第一个要聊的，就是 [Metro](http://en.wikipedia.org/wiki/Metro_(design_language\)) 。虽然它已经改名为 Modern UI ，虽然它作为 Windows Phone 、Windows 8 甚至 Windows 10 的 UI 风格算不上成功，但是作为一个设计语言，它却是声名显赫。以它而非 Windows 来命名这一章节，就是出于对它的敬意。 - -![img](/img/in-post/post-metro-ui.jpg) - -众所周知 Metro 借鉴了交通标示语言、包豪斯现代风格与瑞士国际主义平面设计，其核心思想在于剔除多余信息，专注于内容传达（Content, not chrome），所以 Metro 采用了以 Typography、Color 为主要元素的视觉语言，另外它也非常重视动效设计（Motion Design），这是同期 UI 设计的共识，Motion provides meaning，动效对于表达隐喻有着巨大得作用。 - -我们暂且不去讨论 Metro 在实际运用中的情况，而是尝试去猜想一下 Metro 的设计师们对数字世界的思考，以及那些隐藏在 Metro 背后的奇思妙想： - -#### 思考 —— 极致抽象信息 - -数字时代是基于信息的。这也是为什么我们称这个产业为 IT (Information Technology) ，我们每天使用 PC、Mobile 等数字设备、其实本质是主动或被动的接收、筛选、消化与产生信息。 - -语言与文字的发明是人类信息革命的第一个里程碑，掌握同种语言或文字的人类从此可以高效得进行信息的交换与传播。而现在我们正在走进人机交互与万物互联的时代：人类不但要和人类通信，还要和智能设备建立连接。历史总是上演着重复因此值得借鉴，为什么不把已经发明的东西在数字世界重新发明一次呢？**于是 Cortana 承担了微软在数字时代复刻语音的使命，而 Metro 则继承了老祖宗文字的魔力。** - -无论 Typography-based 还是 Content, not chrome ，**Metro 试图对一切数字时代的信息进行一种非常极致的抽象 —— 我们的 UI 不需要来自真实世界的隐喻，我们只需要足够直接的信息。** 既然文字就是信息、图片就是信息、音视频就是信息，所以它们理所当然应该直接呈现；而所有的样式也都必须直接传达信息，于是网格和灰度表示层级，颜色的存在也更多代表着符号化的视觉传达：比如用于 VI 的品牌色，或者是刻板印象心情。 - -这种对信息简单粗暴的抽象使得 Metro 的首秀极具冲击，却也成为其日后发展最大的绊脚石。 - - -#### 载体 —— 信息平面 - -信息总归需要载体，而设计师们的目的就是寻找，或者创造一种介质来承载、传递、可视化这些信息，然后呈现给用户， 最后才得以成为 UI - -我们都看着屏幕越来越趋于一种扁平的状态，所有设计师们理所当然的想到这种介质可能是一种类似平面的东西，比如说 WebOS 具有抽象意义的“卡片纸” ，或是 iOS/OS X 改变风格前使用的“亚麻桌布”，他们尝试告诉你藏在屏幕后面的数字世界，可能是由某种类似真实世界的平面状物体来承载信息的。 -而 Metro 则做得更加彻底，在它看来这种拟物是强加给数字世界的不必要信息，于是它抛开了所有自然界存在的元素，又一次将信息抽象做到了极致 ：其实那就是一个单纯放置信息的平面而已，或者说，**其实是信息组成了这个平面，数字世界的信息根本无需额外的载体——文字与图像，一方面可以看作是狭义信息的载体，另一方面也可以被看作是广义信息的一种表现形态。** - -**所以我们可以看到 Metro UI 的背景经常是一个空旷的黑色，其实那个黑色代表着 Nothing ，意味着这个平面的下方没有任何东西。**而如果你在下方使用了图像作为背景，你就会发现这其实是两个平面 —— 上层是一个背景透明、漂浮在图像层上的信息平面。而下层则是另一个完全由图像信息组成的信息平面，当我们去划动上层时，产生的视差移动也在告诉我们：这是两个层级。 - -![img](/img/in-post/post-metro-panorama.jpg) - -在所有的 Metro 组件里，我印象最深刻的叫 Panorama Panel（上图） ，Panorama 在我看来是 Metro 对信息最直接的隐喻：**不同的信息体，聚合成了一个完整的信息平面**。当我们在手机屏幕上左右滑动 Panorama 时就好像在操作一个摄像机平移镜头。这种“数字报纸”区别于报纸的最大感受就好像它可以随着信息的量级在 X 轴和 Y 轴 上无限延伸下去，变成一个信息的海洋，在你的面前流动。 - -对啊，那不就是信息流吗。 - - -#### 世界 —— 卡片飞舞的世界 - -我之所以不愿称 Metro 的信息平面为纸片，是因为它不能卷曲也不能折叠； -而之所以不愿称 Metro 的信息平面为卡片，是因为它并非实体，而且尺寸无限； - -**可 Metro 的世界却又让我觉得是卡片飞舞的。** - -一张卡片的秩序是动态磁贴（Live Tiles），它很硬，只能翻转。却又具备魔力，好像在每一次的翻转中，信息都可以得到重组和再现。 -二张卡片的秩序是视差原理（Parallax），当你移动镜头时，任意两张卡片在你眼中的位移，都必须由它们距离屏幕 (Z=0) 的深度决定 -三张卡片的秩序就像飞来咒，原有的平面撤离，被呼唤的卡片俏皮的翻滚着从侧后方飞进视野，Metro UI 的动画设计隐喻着一切。 - -Status Bar 和 Application Bar 就像是紧贴在屏幕上的卡片，所以不受视差影响。而 Pivot Control 则更有魔幻色彩一点，你操纵它就如操作交通枢纽，指挥一个个小的信息片，来来去去在你的面前。 - -所有这些零厚度的卡片，或近，或远，最终组成了整个 Metro 世界。**在我的想象里，那个次元就好像，所有的信息都以片状飞在空中，而你只能看见你所需要的那些，它们有条不紊的在纵横间穿梭，就好像到处都是信息流的交通轨道，你仿佛置身于，那个数据包飞来飞去、路由器控制地址的 —— 网路世界。** - - -![img](/img/in-post/post-metro-real.jpg) - - -## 结语 - -Metro 对信息极致的抽象与压平，与同期的 iOS 6- 风格形成鲜明对比，引发大家对于数字世界与用户界面的新一轮思考，里程碑式的推动了 Flat Design 在新一代数字设计中的普及。不过我们也知道 Metro UI 在微软的实际运用中却其实不成功，这又是为什么呢？ - -笔者抛砖引玉一些自己的观点： - -当年 Metro 第一次运用在 Zune 身上时是非常惊艳的，风格超前、细节精致、动画细腻。再看现在的 Xbox （图一），Pivot 配合磁贴组、简单大气，几乎成为电视 UI 设计的模版。可偏偏在 PC 和 Mobile 两个场景，Metro 却饱受非议。 - -在我看来 PC 和 Mobile 其实代表着两个信息密度最高的场景、PC 是传统互联网的计算中心，而 Mobile 则是移动互联网和可以预见的未来内的个人计算中心。 -**在如此复杂的场景下，其实 Metro 作为设计语言的尺度是不够的。**为什么这么说呢，虽然 Metro 对信息的抽象方式不无道理，但其实还是过分理想和纯粹了。有太多的屏幕像素因此被浪费，有太多其他维度的信息表达方式因此被舍弃掉了。 - -也就是说：Metro 这个设计语言本身是没有问题的，但是拿目前的它作为 PC/Mobile 这种操作系统级别的设计语言却是存在问题的。**一个操作系统的设计语言与交互体系，一定不能太小，必须是一套包容性足够强又可被拓展和延伸的体系。**其实我们能看到 Windows Phone 的 UI 设计容纳度是非常低的，这或许就可以说明问题。 - -**这也是为什么 Win 10 for PC 和 Win 10 for Mobile 都开始削弱最初的那个纯粹的 Metro 体系，转而采用一种 Metro 的视觉语言混搭非 Metro 交互逻辑的方式来设计。** -期待 new Metro (Metro 2.0) 能在 Win 10 上逐步走向成熟，让我们一同见证。 - ---- - -本文是“操作系统的浪漫主义”系列的第一篇文章，如果您喜欢，请继续关注我的博客 ;) - -尽请期待： - -* **Android 篇** - * 思考 —— 从卡片的层叠说起 - * 载体 —— 量子纸 - * 世界 —— 魔法材质统一世界 - -* **iOS 篇** - - 思考 —— 盒子里的蒸汽朋克 - - 载体 —— 景深的无穷近与无穷远 - - 世界 —— 小宇宙里的小宇宙 - - diff --git a/_posts/2015-05-11-see-u-ali.markdown b/_posts/2015-05-11-see-u-ali.markdown deleted file mode 100644 index 96836ba0866..00000000000 --- a/_posts/2015-05-11-see-u-ali.markdown +++ /dev/null @@ -1,104 +0,0 @@ ---- -layout: post -title: "See you, Alibaba " -subtitle: "再见，阿里。" -date: 2015-05-11 -author: "Hux" -header-img: "img/post-bg-see-u-ali.jpg" -tags: - - Meta - - 阿里 ---- - - -> 世界那么大，我想去看看 - -Hi all -这里是鬼栈的离职信。 - -![img](/img/in-post/post-c-u-ali-team.png) - - -## Review - -去年 5 月，大二的我拿到阿里的交互实习生 Offer，成为阿里的实习员工，刚好过去一个年头。 - -8 月，感谢 [@拔赤](http://weibo.com/jayli) 的提携，同意了我转岗到航旅前端团队的申请，分在了老大亲自带队的 **航旅事业群-无线业务部-无线技术-前端团队-前端三组**，从此开始了一名**前端程序猿**的职业生涯。 - -我的第一个 mentor 是大家的"小师妹" @晴舞 姐，不过很可惜的是她居然早于我离职，回北邮任教了。我跟着她在 H5 酒店 的业务线上学习、厮杀，从一个连 git 都用不熟的小小鬼，变成了一个可以独立战斗的小鬼。 -在 Acting H5 酒店/团购 业务线时，也非常感谢 @骏隆 的指导和信任，算是我的大半个 mentor 了。 - -我的第二个 mentor 是人超 nice 的 @智峰 师傅，前手机腾讯网主管，负责团队 CSS 框架，很有生活哲学的一个人。我们一起拿下了 h5 红包等工作，不过很可惜的是没机会从师傅身上学更多的 CSS 了。 - - -有幸来阿里工作一遭，加入航旅前端团队，经历 [离线包/Hybrid容器共建](https://www.zhihu.com/question/31316032/answer/75236718) 这样的牛逼项目，负责过酒店详情、团购详情重构、个人中心红包等工作，为象声汇做过第一版 Logo、海报、颁奖证书，进行过一次团队分享[《聊聊产品与旅行》](http://huxpro.coding.me/2015/06/15/alitrip-strategy/)，更有幸认识大家。 - ---- - -在航旅的 270 天里，我还经历了不少**大事件**： - -* 一次 阿里 IPO （千载难逢的大事，可惜我没有股票，战利品是一件纪念 T 恤） -* 一次 新品牌发布 （*阿里旅行·去啊* 的发布，BU 的大事，战利品还是一件 T 恤） -* 一次 年会 （北京 office 第一次大规模年会，马云老陆 Lucy 悉数到场） -* 一次 双十一 （双十一购物狂欢节，有幸从内部参与一次） -* 一次 Outing （每年才一次的公派娱乐，滑雪＋温泉记忆深刻） -* 一次 Team Building（晴舞姐的 lastday ，难得的团建） -* 一次 中秋节 （战利品是包装特别用心的“马云牌”月饼） - - -真的运气非常好，不但该经历的都经历了，连 IPO 这么难得的也撞上了。 - -![img](/img/in-post/post-c-u-ali-memo.jpg) - - -## To Mates - -感谢大家这么多天的照顾！ - -无线组的小伙伴们： - -* @拔赤：感谢老大！当年慕名而来，非常感谢“收留” -* @虎牙：超牛的虎牙！非常佩服，人也超 nice ，一直学习的对象 -* @兰梦：大姐大！每次问问题都超级热心的解答，非常非常感谢 -* @孝瓘：大哥大！技术超牛不说了，对我超级超级好，帮我解答问题送我回家什么的，特别感动。 -* @豹子：双子座美女姐姐哈哈，前两天生日快乐哦，队花 BU 花！ -* @弘树：简直学霸 & 学神！超年轻超钻，感觉以后会是阿里前端顶梁柱人物哟 -* @若狸：猫爷！京腔儿～虽然总是在朋友圈骂 PD 不过其实特别靠谱活儿特别好哈哈哈 -* @圣耀：首页守护神！加班时你总是在，然后一起分吃，的再去苦逼干活 OTZ -* @智峰：叶师傅！虽然总是不让我叫师兄互相学习云云，不过真的跟我说了很多人生哲理，超受用 -* @擎黄：麦霸！特别聊得来，缘分大概最早来自于坐我旁边，你和舒博搬走时我超舍不得的 T T 你还记得你拿我机箱垫脚吗！ -* @舒博：同上都是 90 后，聊得来！经常一起吃饭，Outing 的时候睡一屋，晚上打鼾完早上还会问我然后道歉特别萌哈哈哈 -* @骏隆：分不清你是哪组！不过一起共事一起玩经常一起吃饭，特别 nice，非常非常感谢，一起做酒店时非常开心！ -* @夕剑：虽然已经离职了看不到不过必须补上，机票的代名词！超 nice 超靠谱，又帅又有趣 -* @晴舞：虽然已经离职了看不到不过必须补上，特别感谢的师姐，最难的开头都是你带我走过去的 -* @已过：虽然已经转岗了看不到不过必须补上，一度觉得很像大反派！印象最深的就是刚进来 git 写错了看我 log 帮我回滚 OTZ，当时觉得特别凶 -* @清锁：实习生小伙伴！你居然先我离职了喂。不过我知道你都签三方啦 - -其他组的我就捡比较熟悉的说啦： - -* @银翘：校友师姐！特别萌，负责象声汇特别尽心尽力 -* @皓勋：充满战斗力的小伙伴！超级青春洋溢，看好你哟～！ -* @懂象：Hey Flasher！Flasher 果然都爱动画爱交互，很聊得来～ -* @龙芒：好像一起打过球？哈哈哈其实没有原因就是觉得特别可爱！ -* @伯元：咦是离职了吗？一起打过好久的球！ - -当然，还有很多前端、UED 、测试、后端、行政 的小伙伴们，就没法一一照顾到啦。 - -**希望所有人都能工作顺利（少加班）、生活开心（多旅游）、身体健康哈。** - -## Future - -距离毕业还有一年多的光景，前路未卜，还是想到处逛逛，多看看再做选择。 - -在陆续看了几家公司后，我决定前往**微信电影票**开始我的下一段旅程。特别巧的是，带队的饼饼居然也曾是我们团队的“老人”，花名 @痴灵 - -世界这么大，更要 Keep Contact. - -* 微博：@Hux黄玄 -* 知乎：@黄玄 -* 博客： - - -**Hey，这里是编号 79717** - -![img](/img/in-post/post-c-u-ali-079717.png) diff --git a/_posts/2015-05-25-js-module-loader.markdown b/_posts/2015-05-25-js-module-loader.markdown deleted file mode 100644 index e0327a04ca1..00000000000 --- a/_posts/2015-05-25-js-module-loader.markdown +++ /dev/null @@ -1,310 +0,0 @@ ---- -layout: post -title: "JavaScript Module Loader" -subtitle: "CommonJS，RequireJS，SeaJS 归纳笔记" -date: 2015-05-25 -author: "Hux" -header-img: "img/post-bg-js-module.jpg" -catalog: true -published: false -tags: - - 笔记 - - Web - - JavaScript ---- - - - -## Foreword - -> Here comes Module! - -随着网站逐渐变成「互联网应用程序」，嵌入网页的 JavaScript 代码越来越庞大，越来越复杂。网页越来越像桌面程序，需要一个团队分工协作、进度管理、单元测试……我们不得不使用软件工程的方法，来管理网页的业务逻辑。 - -于是，JavaScript 的模块化成为迫切需求。在 ES6 Module 来临之前，JavaScript 社区提供了强大支持，尝试在现有的运行环境下，实现模块的效果。 - - - -## CommonJS & Node - -> Javascript: not just for browsers any more! —— CommonJS Slogen - -前端模块化的事实标准之一，2009 年 8 月，[CommonJS](http://wiki.commonjs.org/wiki/CommonJS) 诞生。 - -CommonJS 本质上只是一套规范（API 定义），而 Node.js 采用并实现了部分规范，CommonJS Module 的写法也因此广泛流行。 - - -让我们看看 Node 中的实现： - -```js -// 由于 Node 原生支持模块的作用域，并不需要额外的 wrapper -// "as though the module was wrapped in a function" - -var a = require('./a') // 加载模块（同步加载） -a.doSomething() // 等上一句执行完才会执行 - -exports.b = function(){ // 暴露 b 函数接口 - // do something -} -``` - -`exports`是一个内置对象，就像`require`是一个内置加载函数一样。如果你希望直接赋值一个完整的对象或者构造函数，覆写`module.exports`就可以了。 - -CommonJS 前身叫 ServerJS ，**后来希望能更加 COMMON，成为通吃各种环境的模块规范，改名为 CommonJS** 。CommonJS 最初只专注于 Server-side 而非浏览器环境，因此它采用了同步加载的机制，这对服务器环境（硬盘 I/O 速度）不是问题，而对浏览器环境（网速）来说并不合适。 - - -因此，各种适用于浏览器环境的模块框架与标准逐个诞生，他们的共同点是： - -* 采用异步加载（预先加载所有依赖的模块后回调执行，符合浏览器的网络环境） -* 虽然代码风格不同，但其实都可以看作 CommonJS Modules 语法的变体。 -* 都在向着 **COMMON** 的方向进化：**兼容不同风格，兼容浏览器和服务器两种环境** - -本文接下来要讨论的典例是： - -* RequireJS & AMD（异步加载，预执行，依赖前置。默认推荐 AMD 写法） -* SeaJS & CMD（异步加载，懒执行，依赖就近，默认推荐 CommonJS 写法） - - - - - -## History - - - -> 此段落参考自玉伯的 [前端模块化开发那点历史](https://github.com/seajs/seajs/issues/588) - -09-10 年间，CommonJS（那时还叫 ServerJS） 社区推出 [Modules/1.0](http://wiki.commonjs.org/wiki/Modules) 规范，并且在 Node.js 等环境下取得了很不错的实践。 - -09年下半年这帮充满干劲的小伙子们想把 ServerJS 的成功经验进一步推广到浏览器端，于是将社区改名叫 CommonJS，同时激烈争论 Modules 的下一版规范。分歧和冲突由此诞生，逐步形成了三大流派： - - -1. **Modules/1.x** 流派。这个观点觉得 1.x 规范已经够用，只要移植到浏览器端就好。要做的是新增 [Modules/Transport](http://wiki.commonjs.org/wiki/Modules/Transport) 规范，即在浏览器上运行前，先通过转换工具将模块转换为符合 Transport 规范的代码。主流代表是服务端的开发人员。现在值得关注的有两个实现：越来越火的 component 和走在前沿的 es6 module transpiler。 -2. **Modules/Async** 流派。这个观点觉得浏览器有自身的特征，不应该直接用 Modules/1.x 规范。这个观点下的典型代表是 [AMD](http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition) 规范及其实现 [RequireJS](http://requirejs.org/)。这个稍后再细说。 -3. **Modules/2.0** 流派。这个观点觉得浏览器有自身的特征，不应该直接用 Modules/1.x 规范，但应该尽可能与 Modules/1.x 规范保持一致。这个观点下的典型代表是 BravoJS 和 FlyScript 的作者。BravoJS 作者对 CommonJS 的社区的贡献很大，这份 Modules/2.0-draft 规范花了很多心思。FlyScript 的作者提出了 Modules/Wrappings 规范，这规范是 CMD 规范的前身。可惜的是 BravoJS 太学院派，FlyScript 后来做了自我阉割，将整个网站（flyscript.org）下线了。这个观点在本文中的典型代表就是 SeaJS 和 CMD 了 - - -补一嘴：阿里 KISSY 的 KMD 其实跟 AMD 非常类似，只是用 `add`和`use` 两个源自于 YUI Modules 的函数名替换了 `define` 和 `require` ，但其原理更接近 RequireJS ，与 YUI Modules 的 `Y` 沙箱 Attach 机制并不相同 - - -## RequireJS & AMD - -[AMD (Async Module Definition)](http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition) 是 RequireJS 在推广过程中对模块定义的规范化产出。 - -> RequireJS is a JavaScript file and module loader. It is optimized for in-browser use, but it can be used in other JavaScript environments - -RequireJS 主要解决的还是 CommonJS 同步加载脚本不适合浏览器 这个问题： - -```js -//CommonJS - -var Employee = require("types/Employee"); - -function Programmer (){ - //do something -} - -Programmer.prototype = new Employee(); - -//如果 require call 是异步的，那么肯定 error -//因为在执行这句前 Employee 模块肯定来不及加载进来 -``` -> As the comment indicates above, if require() is async, this code will not work. However, loading scripts synchronously in the browser kills performance. So, what to do? - -所以我们需要 **Function Wrapping** 来获取依赖并且提前通过 script tag 提前加载进来 - - -```js -//AMD Wrapper - -define( - [types/Employee], //依赖 - function(Employee){ //这个回调会在所有依赖都被加载后才执行 - - function Programmer(){ - //do something - }; - - Programmer.prototype = new Employee(); - return Programmer; //return Constructor - } -) -``` - -当依赖模块非常多时，这种**依赖前置**的写法会显得有点奇怪，所以 AMD 给了一个语法糖， **simplified CommonJS wrapping**，借鉴了 CommonJS 的 require 就近风格，也更方便对 CommonJS 模块的兼容： - -```js -define(function (require) { - var dependency1 = require('dependency1'), - dependency2 = require('dependency2'); - - return function () {}; -}); -``` -The AMD loader will parse out the `require('')` calls by using `Function.prototype.toString()`, then internally convert the above define call into this: - -```js -define(['require', 'dependency1', 'dependency2'], function (require) { - var dependency1 = require('dependency1'), - dependency2 = require('dependency2'); - - return function () {}; -}); -``` - -出于`Function.prototype.toString()`兼容性和性能的考虑，最好的做法还是做一次 **optimized build** - - - -AMD 和 CommonJS 的核心争议如下： - -### 1. **执行时机** - -Modules/1.0: - -```js -var a = require("./a") // 执行到此时，a.js 才同步下载并执行 -``` - -AMD: （使用 require 的语法糖时） - -```js -define(["require"],function(require)){ - // 在这里，a.js 已经下载并且执行好了 - // 使用 require() 并不是 AMD 的推荐写法 - var a = require("./a") // 此处仅仅是取模块 a 的 exports -}) -``` - -AMD 里提前下载 a.js 是出于对浏览器环境的考虑，只能采取异步下载，这个社区都认可（Sea.js 也是这么做的） - -但是 AMD 的执行是 Early Executing，而 Modules/1.0 是第一次 require 时才执行。这个差异很多人不能接受，包括持 Modules/2.0 观点的人也不能接受。 - -### 2. **书写风格** - -AMD 推荐的风格并不使用`require`，而是通过参数传入，破坏了**依赖就近**： - -```js -define(["a", "b", "c"],function(a, b, c){ - // 提前申明了并初始化了所有模块 - - true || b.foo(); //即便根本没用到模块 b，但 b 还是提前执行了。 -}) -``` - -不过，在笔者看来，风格喜好因人而异，主要还是**预执行**和**懒执行**的差异。 - -另外，require 2.0 也开始思考异步处理**软依赖**（区别于一定需要的**硬依赖**）的问题，提出了这样的方案： - -```js -// 函数体内： -if(status){ - async(['a'],function(a){ - a.doSomething() - }) -} -``` - -## SeaJS & CMD - -CMD (Common Module Definition) 是 [SeaJS](http://seajs.org/docs/) 在推广过程中对模块定义的规范化产出，是 Modules/2.0 流派的支持者，因此 SeaJS 的模块写法尽可能与 Modules/1.x 规范保持一致。 - -不过目前国外的该流派都死得差不多了，RequireJS 目前成为浏览器端模块的事实标准，国内最有名气的就是玉伯的 Sea.js ，不过对国际的推广力度不够。 - -* CMD Specification - * [English (CMDJS-repo)](https://github.com/cmdjs/specification/blob/master/draft/module.md) - * [Chinese (SeaJS-repo)](https://github.com/seajs/seajs/issues/242) - - -CMD 主要有 define, factory, require, export 这么几个东西 - - * define `define(id?, deps?, factory)` - * factory `factory(require, exports, module)` - * require `require(id)` - * exports `Object` - - -CMD 推荐的 Code Style 是使用 CommonJS 风格的 `require`： - -* 这个 require 实际上是一个全局函数，用于加载模块，这里实际就是传入而已 - -```js -define(function(require, exports) { - - // 获取模块 a 的接口 - var a = require('./a'); - // 调用模块 a 的方法 - a.doSomething(); - - // 对外提供 foo 属性 - exports.foo = 'bar'; - // 对外提供 doSomething 方法 - exports.doSomething = function() {}; - -}); -``` - -但是你也可以使用 AMD 风格，或者使用 return 来进行模块暴露 - -```js -define('hello', ['jquery'], function(require, exports, module) { - - // 模块代码... - - // 直接通过 return 暴露接口 - return { - foo: 'bar', - doSomething: function() {} - }; - -}); -``` - - - -Sea.js 借鉴了 RequireJS 的不少东西，比如将 FlyScript 中的 module.declare 改名为 define 等。Sea.js 更多地来自 Modules/2.0 的观点，但尽可能去掉了学院派的东西，加入了不少实战派的理念。 - - - -## AMD vs CMD - -**虽然两者目前都兼容各种风格，但其底层原理并不相同，从其分别推荐的写法就可以看出两者背后原理的不同：** - -1. 对于依赖的模块，AMD 是**提前执行**，CMD 是**懒执行**。（都是先加载） -* CMD 推崇**依赖就近**，AMD 推崇**依赖前置**。 - -看代码： - -```js -// AMD 默认推荐 - -define(['./a', './b'], function(a, b) { // 依赖前置，提前执行 - - a.doSomething() - b.doSomething() - -}) - -``` - -```js -// CMD - -define(function(require, exports, module) { - - var a = require('./a') - a.doSomething() - - var b = require('./b') // 依赖就近，延迟执行 - b.doSomething() -}) -``` - - - - - - -## WebPack - -> working... diff --git a/_posts/2015-06-15-alitrip-strategy.markdown b/_posts/2015-06-15-alitrip-strategy.markdown deleted file mode 100644 index 3abebcfc353..00000000000 --- a/_posts/2015-06-15-alitrip-strategy.markdown +++ /dev/null @@ -1,202 +0,0 @@ ---- -layout: post -title: "聊聊「阿里旅行 · 去啊」" -subtitle: "聊聊在线旅行行业与老东家的产品思路" -date: 2015-06-15 -author: "Hux" -header-img: "img/post-bg-alitrip.jpg" -catalog: true -tags: - - 产品 - - 阿里 ---- - -## 前言 - -近几年，互联网产品从线上斗到了线下，互联网行业和传统行业的跨界融合屡见不鲜，“渗透传统行业”几乎成为了全行业下一轮创新的标配，新词“互联网+”也应运而生： - -> 将互联网行业的生产要素，深度融入经济、社会等各个领域，尝试改变一些传统的实体经济行业，创造出新的产品形态、商业模式和生态 - -O2O 领域已经有了非常多成功的案例：从最早的千团大战，到前年打车大战，再到餐饮 O2O……传统行业被撬动的同时，无数新的市场也在被发掘： - -* 金融： 蚂蚁金服、芝麻信用、京东白条 -* 通信： 微信电话本，阿里通信 -* 交通： 打车、租车、专车 -* 地产： 二手房、租房 -* 医疗、家电、教育、票务…… - -当然，还有我们的在线旅游行业，BAT 纷纷入局，盛况空前。 - - -## 正文 - -历史总是现在与未来的明鉴，**垂直领域互联网产品**更是与行业的历史紧密相连。想要用互联网产品解决传统行业的问题，就得先了解这个行业的发展规律，看看这个行业都经历过怎样的变革。 - -### 传统老大：旅行社 - -旅行社，一个耳熟能详的名字。在互联网的变革到来之前，旅游行业几乎就是旅行社的天下。 - -在行业术语里，旅行社被称为 **TA：Travel Agency —— 旅游代理**。 -旅行社为你提供旅游信息，代理你办航班，定酒店，买门票，办签证，找导游。通过代理你的旅游消费行为，TA 从中获利。 - -![img](/img/in-post/post-alitrip-pd/post-alitrip-pd.013.jpg) - -### 第一轮革命：兴起的电商与 OTA - -1995 年，中国互联网沸腾元年，北京上海接入 Internet 节点。 -1998 年，中国互联网电商元年，第一笔在线交易产生。 -1999 年，马云的阿里巴巴创办。同年，旅游行业未来的两大巨头，**携程**、**艺龙** 双双出世。 - -携程、艺龙利用互联网的体验优势，迅速占领了 TA 的市场，它们被称作 **OTA：Online Travel Agency** - -![img](/img/in-post/post-alitrip-pd/post-alitrip-pd.014.jpg) - -在他们诞生之初，其实都叫 XX旅行网。那为什么不说他们是做网站的，而说他们是做 TA 的呢？ - -这叫要引出本文涉及的第一个常见商业模式： - -#### Agency 模式 - -Agency，即**代理模式**。通过代理用户的消费行为，代理商就可以靠佣金的方式从中获利。 -举个例子：假设携程旅行网今天给某某酒店拉来了 100 个日间，那么这个酒店就要以 30元/日间 的方式给携程旅行网反多少的红利。 - -**佣金，说白了，就是中介费。** - -![img](/img/in-post/post-alitrip-pd/post-alitrip-pd.016.jpg) - -了解了 Agency 模式，我们再回过来看携程、艺龙： -虽然渠道改成了互联网，但其商业模式还是 TA 的那套玩法，它们其实是在和传统 TA 分同一块蛋糕。 -还是咨询、酒店、机票、旅游团、旅游套餐，只是**你们在线下玩，我去线上玩了**，我有渠道优势。 - -### 第二轮革命：比价搜索与去哪儿 - -时光飞驰到 2005 年，单纯做线下已经满足不了很多传统 TA 们了，大家纷纷向携程、艺龙学习，进攻线上，转型 OTA 。 - -就在这样的格局下，**去哪儿** 横空出世，一下占据了半壁江山： - -![img](/img/in-post/post-alitrip-pd/post-alitrip-pd.021.jpg) - -去哪儿做了一件什么事呢，它把这些 OTA 的数据全都爬过来，做了一个**比价平台**。这样，用户就可以在去哪儿的网站上看看哪家 OTA 更便宜，然后用户就去消费哪家的服务。 - -所谓“比价平台”，本质上说，就是 **Search Engine —— 搜索引擎**。 - -![img](/img/in-post/post-alitrip-pd/post-alitrip-pd.018.jpg) - -这个这个玩法一下就厉害了： -**去哪儿挡在了用户和所有 OTA 之间，OTA 还是做原来的事情，而去哪儿则拿下了用户找 OTA 的过程**。同是搜索引擎的百度也是如此：百度自己并不生产内容，而是拿下了用户找内容的过程。 - -That's why search engine awesome：因为用户在互联网的信息海洋上找信息太难了，所以用户必须要靠搜索引擎来解决这个痛点，而搜索引擎自己也就成为了渠道： - -#### Channel 模式 - -Channel，即**渠道模式**。通过优化用户的体验路径，在用户和 B 方之前挡了一道，主要对 B 盈利。 -最常见的对 B 盈利方式就是广告：**Pay For Performance** - -![img](/img/in-post/post-alitrip-pd/post-alitrip-pd.019.jpg) - -简单看一眼携程和去哪儿的收入占比就可以发现： - -* 携程主要靠来自酒店、机票的佣金盈利 -* 去哪儿则主要靠 PFP 广告盈利 - -![img](/img/in-post/post-alitrip-pd/post-alitrip-pd.020.jpg) - -通过去哪儿的比价平台，小 OTA 开始有机会通过价格战和大 OTA 周旋。去哪儿在给予了小 OTA 机会的同时也造就了自己，这和 2003 年淘宝 C2C 的崛起，颇有异曲同工之意。 - - -### 第 2.5 轮革命：尴尬的淘宝旅行 - -为什么说淘宝旅行是 2.5 次革命呢，因为它想革，但没革上。 -为什么没有革上呢？ - -**首先是切入时机太晚** - -阿里其实 2010 年就开始做淘宝旅行了，一直划分在淘宝网下，由那时的淘宝北研（淘宝 UED 北京研发）团队负责，这个团队吸纳了大批雅虎中国的精英，技术水平相当高。 -可是 2010 年才切入这个市场实在是太晚了，携程、去哪儿的口碑和用户习惯早都养成好几年了，没人会去你淘宝上搜航班酒店，你有大入口也没有用。 - -**二是资源倾斜不足** - -2010 年还没有什么 **互联网+** 的概念，结合传统行业也还没有现在这么热，淘宝做旅游这事用了多大力气推很难说，反正我是没听过。 -阿里同年的发展重心还是在其电商体系的完善上：**淘宝商城** 启用独立域名，其 B2C 的模式刚好弥补了淘宝 C2C 的问题，这货就是后来的**天猫**，我们可以比较一下两者在资源倾斜上的差异： - - - BU | 2008 | 2010 | 2011 | 2012 | 2013 | 2014 | 2015 ----- | ------------- | ------------ -天猫 | 淘宝商城 | 独立域名 | 分拆 | 更名天猫
天猫事业部（1/7）| -去啊 | | 淘宝旅行 | | | 航旅事业部（1/25）| 分拆
更名去啊 | 独立域名 - -**三是思路问题** - -淘宝旅行想怎么玩呢，它实际上就是想用淘宝/天猫的思路去做在线旅行，其实背后还是淘宝卖家和天猫卖家，只不过这次的商户换成 OTA 入驻了，然后大家开开心心像卖衣服一样去卖旅行产品。 - - -![img](/img/in-post/post-alitrip-pd/post-alitrip-pd.023.jpg) - -听上去很美，不但利用了阿里系的大量资源，还直接复刻了淘宝/天猫的牛逼模式 —— 平台模式 - -#### Platform 模式 - -Platform，即**平台模式**，可以说是当今最叼的商业模式了，它相当于构建了一个完整的生态、市场环境，在这里整合买卖双方的资源。通过维护市场秩序、制定市场规则，让市场活跃，从而**赚取场子费**。 - -![img](/img/in-post/post-alitrip-pd/post-alitrip-pd.026.jpg) - -想想看，每一笔交易都在你的地盘上发生，只要市场一直活跃，你就可以在其中**双边、多边盈利**。什么竞价排名、广告平台、VIP 特权，盈利模式太丰富了 - -美梦做完了，回到淘宝旅行来。做平台是每个产品的梦想，肯定是对的。那么问题出在哪呢？ - -**太不垂直了！** 旅游行业，极度要求信誉：去哪儿对接的都是 B 类商家（OTA，品牌连锁酒店，直销等），从根本上就保证了产品体验。淘宝旅行的产品则充斥着大量的小旅行社、个人之类的小卖家，严重影响购买体验。你能想象预定一间酒店发现下面十几二十页的卖家，选完卖家又要跟人在旺旺上扯半个小时么？价格便宜作为唯一的优势，是以严重牺牲产品购买体验为代价的，极为得不偿失。更何况，旅游产品的受众大部分还是消费能力较强的人群，更是看重商家/产品质量而不是价格了。 - - -### 第三轮革命：Now - -OK，经过这么一番折腾，第三次变革就来了。 -BAT 纷纷介入，行业进入了传说中的 BATX 格局： - -![img](/img/in-post/post-alitrip-pd/post-alitrip-pd.028.jpg) - -阿里最近动作频频，力推去啊不说，更是收购线下酒店软件石基，配合蚂蚁金服期下芝麻信用开展“酒店信用住”等业务 -百度早早投资去哪儿，两个搜索引擎起家的公司风格一脉相承。同时，百度也悄悄发布了百度旅行这样的试水产品 -腾讯入股艺龙，同程网等，也在尝试 QQ 旅游等产品 - -Update：不过，就在 2015.5 左右，携程宣布收购艺龙，非常戏剧性的局面啊…… - -为什么都要介入呢？ -一是互联网结合传统行业的大潮到来，大家都发现旅游行业是一个金矿，市场其实特别大…… -二是这个领域确实还有很多可以突破的商业模式存在，很多细分领域都开始有创业公司起来，整个行业的生态也越来越丰富： - -![img](/img/in-post/post-alitrip-pd/post-alitrip-pd.029.jpg) - -这种时候，BAT 这样的土豪公司就想进来收网了 —— 砸钱也得砸出个平台来！ -所以，这一轮游戏一定能看到一次大洗牌（艺龙第一个就阵亡了） - -那么，这轮革命怎么演变呢？ - -**一是模式融合**，以前做 OTA 的做 OTA，做渠道的做渠道，尝试做平台的做平台。现在，大家都知道平台模式可能是更好的形态，纷纷开始进化了。 - -* 都做 OTA，拿下各种牛逼直营，最典型的就是航班 -* 都做平台，尤其是质量相对比较高的 B2C 平台。然后尝试可能的 C2C 产品形态 （去啊的客栈是一个很好的尝试） - -![img](/img/in-post/post-alitrip-pd/post-alitrip-pd.030.jpg) - -**二是思路进化** - -* 从单一的购买/渠道业务转向服务平台。融合周边服务，拉上细分领域，外围行业一起玩 -* 强调用户体验与用户留存，强调**一站式服务**、**个性化服务** 等更极致的产品形态 - -![img](/img/in-post/post-alitrip-pd/post-alitrip-pd.031.jpg) - - -而这些演变，正是 **阿里旅行 · 去啊** 致力去做到的。从大版本 5.0 开始，淘宝旅行将 **洗心革面**，去追求一个更极致，更垂直，体验更优秀的产品形态。 - -让我们一起见证去啊的成长，与在线旅游行业的变革吧！ - - ---- - -*本篇完。* - - - -> 本文作者系前「阿里旅行 · 去啊」前端实习生，本文系业余时间学习之作。 -> 如有任何知识产权、版权问题或理论错误，还请指正。 -> 转载请注明原作者及以上信息。 diff --git a/_posts/2015-07-09-js-module-7day.markdown b/_posts/2015-07-09-js-module-7day.markdown deleted file mode 100644 index 5bcfcd7ac6b..00000000000 --- a/_posts/2015-07-09-js-module-7day.markdown +++ /dev/null @@ -1,45 +0,0 @@ ---- -layout: keynote -title: "JavaScript 模块化七日谈" -subtitle: "🎞 Slides:JavaScript Modularization Journey" -iframe: "//huangxuan.me/js-module-7day/" -date: 2015-07-09 -author: "Hux" -tags: - - Slides - - Web - - JavaScript ---- - - -> 下滑这里查看更多内容 - -7月9日，我在公司内部进行了名为「JavaScript 模块化七日谈」分享，并将该 Slides 分享到了微博上。出乎意料地，这篇微博先后被 @JS小组 @尤小右 @寸志 等近 200 人转发，阅读达到 10w，获得了还不错的评价。 - -于是，我决定将它重新发到我的博客上，并为它专门制作了适用于 Keynote 展示文稿的新布局。它能自动根据屏幕大小/旋转以一定比例填充屏幕，你也可以直接点击下方链接在新页面打开，来获得更好的、沉浸式的全屏体验 - - -### [Watch Fullscreen →](https://huangxuan.me/js-module-7day/) - -
- -你也可以通过扫描二维码在手机上观看 -
- - -这个 Web Slides 开源在[我的 Github 上](https://github.com/Huxpro/js-module-7day)，欢迎你帮助我完善这个展示文稿，你可以给我提 issue，可以 fork & pull request。如果它能帮助到你了，希望你还能不吝啬 star 一下这个项目 - - -### Catalog - -- 第一日 上古时期 ***Module?*** 从设计模式说起 -- 第二日 石器时代 ***Script Loader*** 只有封装性可不够，我们还需要加载 -- 第三日 蒸汽朋克 ***Module Loader*** 模块化架构的工业革命 -- 第四日 号角吹响 ***CommonJS*** 征服世界的第一步是跳出浏览器 -- 第五日 双塔奇兵 ***AMD/CMD*** 浏览器环境模块化方案 -- 第六日 精灵宝钻 ***Browserify/Webpack*** 大势所趋，去掉这层包裹！ -- 第七日 王者归来 ***ES6 Module*** 最后的战役 - -### Thanks - -[Reveal.js](http://lab.hakim.se/reveal-js) diff --git a/_posts/2015-09-22-js-version.markdown b/_posts/2015-09-22-js-version.markdown deleted file mode 100644 index 382d0a8930a..00000000000 --- a/_posts/2015-09-22-js-version.markdown +++ /dev/null @@ -1,67 +0,0 @@ ---- -layout: post -title: "「译」ES5, ES6, ES2016, ES.Next: JavaScript 的版本是怎么回事？" -subtitle: "ES5, ES6, ES2016, ES.Next: What's going on with JavaScript versioning?" -date: 2015-09-22 -author: "Hux" -header-img: "img/post-bg-js-version.jpg" -tags: - - Web - - JavaScript - - 译 ---- - - -JavaScript 有着很奇怪的命名史。 - -1995 年，它作为网景浏览器（Netscape Navigator）的一部分首次发布，网景给这个新语言命名为 LiveScript。一年后，为了搭上当时媒体热炒 Java 的顺风车，临时改名为了 JavaScript *（当然，Java 和 JavaScript 的关系，就和雷锋和雷锋塔一样 —— 并没有什么关系）* - -![java-javascript](/img/in-post/post-js-version/javascript-java.jpg) -歪果仁的笑话怎么一点都不好笑 - -> 译者注：[wikipedia 的 JavaScript 词条](https://en.wikipedia.org/wiki/JavaScript#History) 更详细的叙述了这段历史 - -1996 年，网景将 JavaScript 提交给 [ECMA International（欧洲计算机制造商协会）](http://www.ecma-international.org/) 进行标准化，并最终确定出新的语言标准，它就是 ECMAScript。自此，ECMAScript 成为所有 JavaScript 实现的基础，不过，由于 JavaScript 名字的历史原因和市场原因（很显然 ECMAScript 这个名字并不令人喜欢……），现实中我们只用 ECMAScript 称呼标准，平时都还是使用 JavaScript 来称呼这个语言。 - - -> 术语（译者注）： -> -> * *标准（Standard）*： 用于定义与其他事物区别的一套规则 -> * *实现（Implementation）*： 某个标准的具体实施/真实实践 - - -不过，JavaScript 开发者们并不怎么在乎这些，因为在诞生之后的 15 年里，ECMAScript 并没有多少变化，而且现实中的很多实现都已经和标准大相径庭。其实在第一版的 ECMAScript 发布后，很快又跟进发布了两个版本，但是自从 1999 年 ECMAScript 3 发布后，十年内都没有任何改动被成功添加到官方规范里。取而代之的，是各大浏览器厂商们争先进行自己的语言拓展，web 开发者们别无选择只能去尝试并且支持这些 API。即使是在 2009 年 ECMAScript 5 发布之后，仍然用了数年这些新规范才得到了浏览器的广泛支持，可是大部分开发者还是写着 ECMAScript 3 风格的代码，并不觉得有必要去了解这些规范。 - -> 译者注：[ECMAScript 第四版草案](https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_.28abandoned.29)由于太过激进而被抛弃，Adobe 的 [ActionScript 3.0](https://en.wikipedia.org/wiki/ActionScript) 是 ECMAScript edition 4 的唯一实现（ Flash 差点就统一 Web 了） - -到了 2012 年，事情突然开始有了转变。大家开始推动停止对旧版本 IE 浏览器的支持，用 ECMAScript 5 (ES5) 风格来编写代码也变得更加可行。与此同时，一个新的 ECMAScript 规范也开始启动。到了这时，大家开始逐渐习惯以对 ECMAScript 规范的版本支持程度来形容各种 JavaScript 实现。在正式被指名为 ECMAScript 第 6 版 (ES6) 之前，这个新的标准原本被称为 ES.Harmony（和谐）。2015 年，负责制定 ECMAScript 规范草案的委员会 TC39 决定将定义新标准的制度改为一年一次，这意味着每个新特性一旦被批准就可以添加，而不像以往一样，规范只有在整个草案完成，所有特性都没问题后才能被定稿。因此，ECMAScript 第 6 版在六月份公布之前，又被重命名为了 ECMAScript 2015（ES2015） - -目前，仍然有很多新的 JavaScript 特性或语法正在提议中，包括 [decorators（装饰者）](https://github.com/wycats/javascript-decorators)，[async-await（async-await 异步编程模型）](https://github.com/lukehoban/ecmascript-asyncawait) 和 [static class properties（静态类属性）](https://github.com/jeffmo/es-class-properties)。它们通常被称为 ES7，ES2016 或者 ES.Next 的特性，不过实际上它们只能被称作提案或者说可能性，毕竟 ES2016 的规范还没有完成，有可能全部都会引入，也有可能一个都没有。TC39 把一个提案分为 4 个阶段，你可以在 [Babel 的官网](https://babeljs.io/docs/usage/experimental/) 上查看各个提案目前都在哪个阶段了。 - -所以，我们该如何使用这一大堆术语呢？下面的列表或许能帮助到你： - -* **ECMAScript**：一个由 ECMA International 进行标准化，TC39 委员会进行监督的语言。通常用于指代标准本身。 -* **JavaScript**：ECMAScript 标准的各种实现的最常用称呼。这个术语并不局限于某个特定版本的 ECMAScript 规范，并且可能被用于任何不同程度的任意版本的 ECMAScript 的实现。 -* **ECMAScript 5 (ES5)**：ECMAScript 的第五版修订，于 2009 年完成标准化。这个规范在所有现代浏览器中都相当完全的实现了。 -* **ECMAScript 6 (ES6) / ECMAScript 2015 (ES2015)**：ECMAScript 的第六版修订，于 2015 年完成标准化。这个标准被部分实现于大部分现代浏览器。可以查阅[这张兼容性表](http://kangax.github.io/compat-table/es6/)来查看不同浏览器和工具的实现情况。 -* **ECMAScript 2016**：预计的第七版 ECMAScript 修订，计划于明年夏季发布。这份规范具体将包含哪些特性还没有最终确定 -* **ECMAScript Proposals**：被考虑加入未来版本 ECMAScript 标准的特性与语法提案，他们需要经历五个阶段：Strawman（稻草人），Proposal（提议），Draft（草案），Candidate（候选）以及 Finished （完成）。 - -在这整个 Blog 中，我将把目前的 ECMAScript 版本称作 ES6（因为这是大部分开发者最习以为常的），把明年的规范称作 ES2016（因为，与 ES6/ES2015 不同，这个名字将在整个标准化过程中沿用）并且将那些还没有成为 ECMAScript 定稿或草案的未来语言概念称为 ECMAScript 提案或者 JavaScript 提案。我将尽我所能在任何可能引起困惑的场合沿用这篇文章。 - -#### 一些资源 - - - -* TC39 的 [Github 仓库](https://github.com/tc39/ecma262)上可以看到所有目前公开的提案 -* 如果你还不熟悉 ES6，Babel 有一个[很不错的特性概览](https://babeljs.io/docs/learn-es2015/) -* 如果你希望深入 ES6，这里有两本很不错的书： Axel Rauschmayer 的 [Exploring ES6](http://exploringjs.com/)和 Nicholas Zakas 的 [Understanding ECMAScript 6](https://leanpub.com/understandinges6)。Axel 的博客 [2ality](http://www.2ality.com/) 也是很不错的 ES6 资源 - - -来学 JavaScript 吧！ - -#### 著作权声明 - -本文译自 [ES5, ES6, ES2016, ES.Next: What's going on with JavaScript versioning?](http://benmccormick.org/2015/09/14/es5-es6-es2016-es-next-whats-going-on-with-javascript-versioning/) -译者 [黄玄](http://weibo.com/huxpro)，首次发布于 [Hux Blog](http://huangxuan.me)，转载请保留以上链接 - diff --git a/_posts/2015-10-28-how-designer-learn-fe.markdown b/_posts/2015-10-28-how-designer-learn-fe.markdown deleted file mode 100644 index 946ef3bcd42..00000000000 --- a/_posts/2015-10-28-how-designer-learn-fe.markdown +++ /dev/null @@ -1,189 +0,0 @@ ---- -layout: post -title: "设计师如何学习前端？" -subtitle: "How designers learn front-end development?" -date: 2015-10-28 12:00:00 -author: "Hux" -header-img: "img/home-bg-o.jpg" -tags: - - 知乎 - - Web - - UX/UI ---- - -> 这篇文章转载自[我在知乎上的回答](https://www.zhihu.com/question/21921588/answer/69680480)，也被刊登于[优秀网页设计](http://www.uisdc.com/head-first-front-end)等多个网站上 ;) - - -笔者的经历在知乎就可以看到，大学专业是数字媒体艺术，大一实习过动效设计师，大二拿到了人生第一个大公司 offer 是阿里的交互设计，后来转岗到淘宝旅行的前端团队，现在在微信电影票做前端研发。 -
-
也是走过了不少野路子，不过还好有小右哥 @尤雨溪 这样艺术/设计转前端的大神在前面做典范，也证明这条路是玩的通的 ;) -
-
接下来就说说自己的学习建议吧，一个小教程，也是自己走过的流程，仅供参考哈 -
-
------------ -
-
背景篇 -
-
在这个时代学习新东西，一定要善于使用 Bing/Google 等搜索引擎…网络上的资源非常丰富，自学能力也尤为重要，尤其是对于学习技术！ -
-
-
-
入门篇（HTML/CSS） -
-
说起设计师希望学前端的初衷，大概还是因为各种华丽的网页特效/交互太过吸引人，这种感觉大概就是：“Hey，我的设计可以做成网页访问了呢！” -
好在，“展示”对于前端技术来说反而是最简单的部分。所以，放下你对“编程”两个字的恐惧，从“称不上是编程语言”的 HTML/CSS 开始，先做点有成就感的东西出来吧！ -
-
对于设计师来说，最有成就感的一定是“可以看到的东西”，而 HTML/CSS 正是用来干这个的，HTML 就是一堆非常简单的标签，而 CSS 无非就是把你画画的流程用英语按一定的格式写出来而已： -
- - -```html -

p is paragraph!

- - -``` - - -是不是非常容易，就跟读英语一样！ -
接下来，你就需要开始自学啦，比如常用 HTML 标签的意思，各种 CSS 的属性，还有 CSS 的盒模型、优先级、选择器……放心，它们都很容易；能玩得转 PS/AI/Flash/Axure/AE/Sketch 的设计师们，学这个洒洒水啦 -
-
推荐几个资源： -
- -
这个阶段的练习主要是“临摹”：用代码画出你想画的网站，越多越好。 -
-
对于书，我非常不推荐上来就去看各种厚厚的入门/指南书，没必要！这一个阶段应该快速上手，培养兴趣，培养成就感。先做出可以看的东西再说，掌握常用的 HTML/CSS 就够用了 -
-
如果完成的好，这个阶段过后你大概就可以写出一些简单又好看的“静态网页”了，比如这个作品集/简历：Portfolio - 黄玄的博客 （好久没更新了…丢人现眼） -
-
-
-
入门篇（JavaScript/jQuery） -
-
想要在网页上实现一些交互效果，比如轮播图、点击按钮后播放动画？那你就必须要开始学习 JavaScript 了！JavaScript 是一门完整、强大并且非常热门的编程语言，你在浏览器里看到的所有交互或者高级功能都是由它在背后支撑的！ -
-
举个小栗子： -
- -```js -alert("Hello World!") -``` - -就这一行，就可以在浏览器里弹出 Hello World 啦！ -
-
在了解一些基础的 JavaScript 概念（变量、函数、基本类型）后，我们可以直接去学习 jQuery，你不用知道它具体是什么（它是一个 JavaScript 代码库），你只要知道它可以显著地降低你编写交互的难度就好了： -
- -```js -$('.className').click(function(){ - alert("Hello jQuery") -}) -``` - -通过 jQuery，我们可以继续使用在 CSS 中学到的“选择器” -
-
对于没有编程基础的人来说，想要完全掌握它们两并不容易。作为设计师，很多时候我们可以先不必深究它们的原理，而是尝试直接应用它！这样成就感会来得很快，并且你可以通过实际应用更加理解 JavaScript 是用来做什么的。 -
-
我仍然推荐你使用 w3school 在线教程 与 http://www.codecademy.com/ 进行学习。另外，你可以看一看诸如《锋利的jQuery (豆瓣)》 这一类非常实用的书籍，可以让你很快上手做出一些简单的效果来！ -
-
如果学习得顺利，你还可以尝试使用各种丰富的 jQuery 插件，你会发现写出支持用户交互的网站也没有那么困难～很多看上去很复杂的功能（比如轮播图、灯箱、下拉菜单），搜一搜然后看看文档（教程）、改改示例代码就好了。 -
-
比如说，配合 Huxpro/jquery.HSlider · GitHub 这样的轮播图插件，你可以很轻松的写出 HSlider | Demo 这样的网页相册或者 HSlider | Weather 这样的手机端 App 原型～ -
-
最后，我想推荐下 Bootstrap · The world's most popular mobile-first and respons ，这是世界上最知名的前端 UI 框架之一，提供了大量 CSS 样式与 jQuery 插件。它非常容易学习并且中英文教程都非常健全，你并不需要理解它背后的工作原理就能很好的使用它，让你快速达到“可以建站的水平”。有余力的话，你不但可以学习如何使用它，还可以学习它背后的设计思想。 -
-
-
-
转职方向一：前端重构 （Web Rebuild） -
-
业内通常把专精 HTML/CSS 的前端从业人员称为重构，而对于注重视觉效果的设计师来说，在掌握基本的 HTML/CSS 后，就可以朝着这个方向发展了。 -
-
到了这个阶段，你不但要知道怎么写页面，还要知道它们都是为什么，并且知道怎么做更好。这对你理解 Web 世界非常有帮助，并且能帮助你做出更“系统化”的设计。 -
-
CSS 的学问很多，你需要开始理解文档流、浮动流等各种定位的方式与原理，理解 CSS 的继承复用思想、理解浏览器的差异、兼容、优雅降级……这里强烈推荐一本书：《精通CSS（第2版） (豆瓣)》，虽然前端技术突飞猛进，但这本书的思想永远不会过时。 -
-
HTML 方面，要开始注重语义化、可访问性与结构的合理，你要开始学习“结构与样式的分离”，这里有一本神书将这种分离做到了极致：《CSS禅意花园 (豆瓣)》 -
-
另外，各种炫酷屌的 CSS 3 属性你一定会喜欢：你可以用媒体查询做响应式网页设计，你可以用 transiton 和 animation 做补间动画与关键帧动画，用 transform 做缩放、旋转、3D变换，还有圆角、渐变、阴影、弹性盒！样样都是设计师的神器！ -
-
如果你还掌握了 入门篇（JavaScript/jQuery）的知识，那么恭喜你！你已经可以做出很多有趣的网页了！很多 minisite 或者微信上的“H5” 小广告，这个程度的你已经可以轻松完成了！ -
-
配合上你的设计功力，你可以开始尝试创作一些好玩的东西，比如这种富含交互和动画的网站 绅宝 SENOVA ，它仍然是基于 Huxpro/jquery.HSlider · GitHub 实现的！或者给自己做个小小的个人网站试试 -
-
-
-
转职方向二：前端工程师（Front-end Engineer） -
-
如果你觉得上述的这些都还满足不了你，你渴望做出更多了不起的交互，甚至你已经喜欢上了编程，想要转行做工程师，或者成为一名全栈设计师，那么你可以朝着这个方向继续发展！ -
-
这个阶段的最大难度，是你必须学会像一名软件工程师一样思考。你需要踏踏实实学习编程语言，深入理解作用域、对象、类、封装、继承、面向对象编程、事件侦听、事件冒泡等一大堆编程概念，你还需要了解浏览器，学习 DOM、BOM、CSSOM 的 API，你甚至还需要学习一些网络原理，包括域名、URL、DNS、HTTP 请求都是什么… -
-
你可能会被这一大堆名词吓到。确实，想要搞定他们并不容易。但是，你要相信只要你肯花功夫它们也没有那么难，而更重要的是，如果你能拿下他们，你所收获的并不只是这些而已，而是真正跨过了一道大坎 —— 你的世界将因此打开， 你看待世界的方式将因此改变 -
-
对于这个阶段，你可以继续在 http://www.codecademy.com/ 上学习，但是 w3school 已经不够用了，遇到不会的语法，我推荐你查阅 Mozilla 开发者网络，这是少数中英文都有的非常专业且友好的网站。 -
-
同时，你可能需要看一些书本来帮助你学习 JavaScript ： -
- -
如果你能顺利得渡过了这个阶段，我想你已经能做出很多令你自豪的网站了！试着向身边的工程师朋友询问如何购买域名、配置简单的静态服务器，或者搜搜“Github Pages”，然后把你的作品挂在网络上让大家欣赏吧！ -
-
你还可以试着用 JavaScript 写写小游戏，这不但能锻炼你的编程水平还非常有趣～比如这是我刚学 JS 不久后 hack 一晚的产物 —— 用 DOM 实现的打飞机：Hux - Aircraft （不支持手机） -
-
-
-
入行篇 -
-
如果你能完成上述所有的学习，你已经是一名非常出色的前端学徒了！对于只是想要丰富技能的设计师或者产品经理来说，接下来的内容可能会让你感到不适 ;( -
但如果你铁了心想要真正入行进入大公司从事专职前端开发的工作，那么你可以接着往下看： -
-
近几年的前端技术发展迅猛，前端工程师早已不是切切图写写页面做点特效就完事的职位，你需要具备相当完善的工程师素质与计算机知识，成为一名真正的工程师。 -
-
你需要非常了解 JavaScript 这门语言，包括 闭包、IIFE、this、prototype 及一些底层实现（ES、VO、AO）、熟悉常用的设计模式与 JavaScript 范式（比如实现类与私有属性）。另外，新的 ES6 已经问世，包括 class, module, arrow function 等等 -
-
你需要非常了解前端常用的网络及后端知识，包括 Ajax、JSON、HTTP 请求、GET/POST 差异、RESTful、URL hash/query、webSocket、常用的跨域方式（JSONP/CORS、HTTP 强缓存/协商缓存，以及如何利用 CDN 、静态网站/动态网站区别、服务器端渲染/前端渲染区别等等 -
-
你需要学习使用进阶的 CSS，包括熟悉 CSS 3，使用 Scss/Less 等编译到 CSS 的语言，使用 autoprefixer 等 PostCSS 工具，了解 CSS 在 Scope/Namespace 上的缺陷，你还可以学习 CSS Modules、CSS in JS 这些有趣的新玩意 -
-
你需要非常了解前端的模块化规范，可能在你学习到这里的时候，Require.js/AMD 已经再见了，但是 CommonJS 与 ES6 Modules 你必须要了解。（你可以观看我的分享《JavaScript Modularization Seven Day》 来学习 JS 模块化的历史） -
-
你需要熟悉 Git 与 Shell 的使用，包括基于 git 的版本管理、分支管理与团队协作，包括简单的 Linux/Unix 命令、你要知道大部分程序员的工作可以通过 shell 更快更酷的完成，并且很多“软件”只能通过 shell 来使用。你还可以把你的代码放到 github 上与人分享，并且学习 github 上其他优秀的开源代码 -
-
你需要熟悉并且习惯使用 Node，包括了解 npm、使用 Grunt/Gulp/Browserify/Webpack 优化你的工作流、对你的代码进行打包、混淆、压缩、发布，你还可以使用 Express/Koa 配合 MongoDB/Redis 涉足到后端领域，或者尝试用 Node 做后端渲染优化你的首屏体验 -
-
你需要了解各种 HTML 5 的新 API，包括 <video>/<audio>，包括 Canvas，webGL、File API、App Cache、localStorage、IndexedDB、Drag & Drop、更高级的 DOM API、Fetch API 等等 -
-
你需要学习 JavaScript 的单线程与异步编程方法，因为它们非常非常常用、包括 setTimeout/setInterval，回调与回调地狱、事件与event loop、还有 Promise 甚至 Async/Await -
-
你需要非常了解浏览器，包括主流浏览器的名称、内核与差异、包括私有属性与 -webkit- 等厂商前缀，你需要学习如何使用 Chrome DevTool，你需要了解浏览器渲染的 reflow/repaint 来避免 Jank 并进行有针对性的性能优化 -
-
你需要专门学习 Mobile Web，因为移动互联网是趋势。包括 viewport、CSS pixel、 touch 事件、iOS/Android 浏览器的差异与兼容、移动端的性能优化、300ms delay 等等…你还需要知道 Hybrid 是什么，包括 Cordova/Phonegap，更复杂的比如和 iOS/Android 通信的机制，比如 URI Scheme 或者 JS Bridge -
-
你需要学习一些非常火热的前端框架/库，他们不但能帮助你更快的进行开发、更重要的是他们背后所蕴含的思想。包括 Backbone、Angular、Vue、React、Polymer 等等、了解它们背后的双向数据绑定、单向数据流、MVC/MVVM/Flux 思想、Web Component 与组件化等等 -
-
你需要学习如何构建 web 单页应用，这是 web 的未来，包括利用 history API 或者 hash 实现路由，包括基于 Ajax + 模版引擎或者其他技术的前端渲染、包括组织较为复杂的软件设计等等 -
-
我还建议你学习更多的计算机知识，它们能对你的代码能起到潜移默化的作用，包括简单的计算机体系结构、更广泛的编程知识（面向对象/函数式等）、栈、堆、数组、队列、哈希表、树、图等数据结构、时间复杂度与空间复杂度以及简单的算法等等 -
-
你需要了解业内的大神并阅读它们的博客/知乎/微博，比如 @尤雨溪@贺师俊@张云龙@徐飞@张克军@玉伯@拔赤@寸志@题叶@郭达峰 等等等等，很多思想和新东西只有从他们身上才能学到。我还推荐你多参加技术交流会，多认识一些可以一起学习的小伙伴，你们可以互相交流并且一起成长 -
-
你需要具备很强的自学能力、对技术有热情并且不断跟进。因为 JavaScript/前端的社区非常非常活跃，有太多的新东西需要你自己来发现与学习：比如 Universal JavaScript、Isomorphic JavaScript、前端测试、HTML5 页游、WebRTC、WebSocket、CSS 4、SVG、HTTP/2、ES 7、React Native、Babel、TypeScript、Electron 等等等等… -
-
-
虽然一下扯得有点多，但这些确实就是你未来将会遇到的。你并不需要全部掌握它们，但是却多多益善；你也可以专精在某几个方面，这已经足以让你成为非常专业的前端工程师。 -
-
所以，如果你自认为涵盖了上述要求的 40%，欢迎简历发 huangxuan@wepiao.com ，实习/全职皆可～ -
-
-
咦，这个结尾怪怪的…… diff --git a/_posts/2015-12-15-ios9-safari-web.markdown b/_posts/2015-12-15-ios9-safari-web.markdown deleted file mode 100644 index abb70a855dc..00000000000 --- a/_posts/2015-12-15-ios9-safari-web.markdown +++ /dev/null @@ -1,340 +0,0 @@ ---- -layout: post -title: "「译」iOS 9，为前端世界都带来了些什么？" -subtitle: "iOS 9, Safari and the Web: 3D Touch, new Responsive Web Design, Native integration and HTML5 APIs" -date: 2015-12-15 -author: "Hux" -header-img: "img/post-bg-ios9-web.jpg" -catalog: true -tags: - - Web - - 译 ---- - -2015 年 9 月，Apple 重磅发布了全新的 iPhone 6s/6s Plus、iPad Pro 与全新的操作系统 watchOS 2 与 tvOS 9（是的，这货居然是第 9 版），加上已经发布的 iOS 9，它们都为前端世界带来了哪些变化呢？作为一个 web 开发者，是时候站在我们的角度来说一说了！ - - -> **注！** 该译文存在大量英文术语，笔者将默认读者知晓 ES6、viewport、native app、webview 等常用前端术语，并不对这些已知术语进行汉语翻译 -> 对于新发布或较新的产品名称与技术术语，诸如 Apple Pen、Split View 等专有名词，笔者将在文中使用其英文名，但会尝试对部分名词进行汉语标注 -> 另外，出于对 wiki 式阅读的偏爱，笔者为您添加了很多额外的链接，方便您查阅文档或出处 - - -## 简而言之 - -如果你不想阅读整篇文章，这里为你准备了一个总结： - - -#### 新的设备特性 - -* iPhone 6s 与 6s Plus 拥有 **“[3D Touch](http://www.apple.com/iphone-6s/3d-touch/)”**，这是一个全新的硬件特性，它可以侦测压力，是一个可以让你拿到手指压力数据的 API -* iPad Pro 的 viewport 为 1024px，与以往的 iPad 全都不同 -* 想在 iPad Pro 上支持新的 Apple Pen？不好意思，目前似乎并没有适用于网站的 API - -#### 新的操作系统特性（与 web 相关的） - -* iPad 上的 Safari 现在可以通过 [Split View](https://developer.apple.com/library/prerelease/ios/documentation/WindowsViews/Conceptual/AdoptingMultitaskingOniPad/QuickStartForSlideOverAndSplitView.html#//apple_ref/doc/uid/TP40015145-CH13-SW1)（分屏视图）与其他应用一起使用，这意味着新的 viewport 尺寸将会越来越常见 -* 新的 Safari View Controller（[`SFSafariViewController`](https://developer.apple.com/library/prerelease/ios/documentation/SafariServices/Reference/SFSafariViewController_Ref/index.html#//apple_ref/occ/cl/SFSafariViewController)）可以让你在 native app 内提供与 Safari 界面、行为连贯一致的应用内网页浏览体验 -* 注意啦！Safari 新加入了 Content Blocker（内容拦截器）。以后，并不是所有的访问都一定会出现在你的 Google Analytics 了 -* [Universal Links](https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html#//apple_ref/doc/uid/TP40016308-CH12) 可以让应用的拥有者在 iOS 内部“占有”自己的域名。因此，访问 yourdomain.com 将会打开你的应用（类似 Android 的 Intents 机制） -* [App Search（应用搜索）](https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/AppSearch/index.html#//apple_ref/doc/uid/TP40016308)：现在，Apple 将会抓取你的网页内容（与 native app 内容）用于 Spotlight 与 Siri 的搜索结果，[想知道你的标签都兼容吗？](https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/AppSearch/WebContent.html#//apple_ref/doc/uid/TP40016308-CH8) -* 你的网站现在可以通过 JavaScript API 访问 iCloud 的用户数据 - -#### 新的 API 支持 - -* [Performance Timing API](https://developer.mozilla.org/en-US/docs/Web/API/Performance/timing) 在 iOS 9 得到回归 -* 关于 HTML5 Video，你现在可以在支持 [Picture in Picture（画中画）](https://developer.apple.com/library/prerelease/ios/documentation/WindowsViews/Conceptual/AdoptingMultitaskingOniPad/QuickStartForPictureInPicture.html#//apple_ref/doc/uid/TP40015145-CH14)的 iPad 设备上提供这项新功能；你的视频甚至可以在 Safari 关闭后继续播放 -* 更好的 ES6 支持：classes（类）, computed properties（可计算属性）, template literals（模版字符串）等 -* Backdrop CSS filters（背景滤镜） -* CSS @supports 与 CSS Supports JavaScript API -* CSS Level4 伪选择器 -* 用于支持分页内容的 CSS Scroll Snapping -* WKWebView 现在可以访问本地文件了 -* 我们仍然需要等待 Push Notification，camera access，Service Workers 这些现代 web API 的到来 - -#### 新的操作系统 - -* 新一代 Apple TV 的 **tvOS**： 没有浏览器，也没有 webview。但是 JavaScript、XHR 和 DOM 可以通过一个叫做 TVML 的标记语言来使用 -* Apple Watch 的 **watchOS**：完全没有任何浏览器和 webview - - -> **再注！** 由于原文写于 Apple 发布会之前，为了不让读者感到奇怪，笔者将会对文章进行适当改写与补充，以保证本文的连贯性 - - -## 新的 iOS 设备特性 - -### iPhones 6s 与 3D Touch - -从 web 设计与开发的角度来说，新的 iPhone 6s 与 6s Plus 与之前的版本并没有太多差别。不过，有一个特性注定会吸引我们的目光：**3D Touch** - -我们无法确定 Apple 是不是只是重命名了一下 “Force Touch”（用于 Apple Watch、TrackPad 2 与最新的 MacBook 上）或者 3D Touch 的确是一个为 iPhone 定制的似曾相识却不同的东西。3D Touch 允许操作系统和应用侦测每一个手指与屏幕接触时的压力。从用户体验的角度来说，最大的变化莫过于当你用点力去触碰或者拖拽屏幕时，操作系统将会触发诸如 peek，pop 这些新机制。那么问题来了：**我们是否能够在网站中使用这个新玩意呢？让我们一点点来看：** - -iOS 9 搭载的 Safari 包含了一些用于 “Force Touch” 的新 API，但它们其实并不是那个用于 iPhone 6s 3D Touch 的 API。你可以理解为这些 API 就是 MacBook 版 Safari 里为 Force Touch 准备的那些 API ，因为共享一套 codebase，所以它理所当然得存在了 iOS 版里而已。 - -Force Touch API 为我们添加了两个新东西： - -1. 你的 click 事件处理函数将会从 MouseEvent 中收到一个新的属性：`webkitForce` -2. DOM 也新增了四个事件：`(webkit)mouseforcewillbegin`，`mouseforcedown`，`mouseforceup` 与 `mouseforcechange`。下边的示意图将告诉你这些事件是在何时被触发的： - -![Force Events](http://www.mobilexweb.com/wp-content/uploads/2015/09/foceevents.png) - - -相信你已经从它们的名字中意识到了，这些事件都是基于鼠标而非触摸的，毕竟它们是为 MacBook 设计的。并且，TouchEvent 也并没有包含 `webkitForce` 这个属性，它仅仅存在于 MouseEvent 里。在 iOS Safari 里，你确实可以找到 `onwebkitmouseforce` 这一系列事件处理器，但是很可惜它们并不会被触发，click 返回的 MouseEvent 也永远只能得到一个 `webkitForce: 0` - - -可喜可贺的是，故事还没有结束。[Touch Events v2 draft spec（触摸事件第二版草案）](https://w3c.github.io/touch-events/) 中正式添加了 `force` 属性。3D Touch 也得以在 iPhone 6s 与 6s+ 中通过 TouchEvent 访问到。不过，笔者也要在这里提醒大家，由于没有 `webkitmouseforcechange` 这样给力的事件，在手机上我们只能通过 **轮询 TouchEvent 的做法** 来不断检测压力值的改变……非常坑爹 - -[@Marcel Freinbichler](https://twitter.com/fr3ino) 第一个在 Twitter 上晒出了自己的 [Demo](http://freinbichler.me/apps/3dtouch)。在 6s 或 new Macbook 的 Safari（目前仅 Safari 支持）上访问就可以看到圆圈会随着压力放大。墙内的小伙伴可以直接试试下面这个圆圈，体验下 3D/Force Touch 带来的的奇妙体验。 - - - -如果你不巧在用不支持 3D/Force Touch 的设备，发现尼玛用力按下去之后居然圆圈也有反映！？ - -放心，这真的不是你的设备突然习得了“感应压力”这项技能，而是因为 [Forcify](http://huangxuan.me/forcify) 是一个用于在所有设备上 polyfill 3D/Force Touch API 的 JS 库……它不但封装了 OSX/iOS 两个平台之间 API 的差异，还使用"长按"来模拟了 `force` 值的变化…… - - - -### iPad Pro - -全新的 iPad Pro（12.9 寸）打破了以往 iPad 渲染网站的方式。在此之前，市面上所有的 iPad（从初代 iPad，到 iPad Air 4，到 iPad Mini）都是以 768px 的宽度提供 viewport。 - -而屏幕更大的 iPad Pro 选择了宽 1024px 的 viewport，这使得它天生就能容纳更多的内容。不少人说iPad Pro 就是抄 Microsft Surface Pro 的嘛……嗯哼，IE/Edge 在 Surface Pro 上就是以 1024px 作为视口宽度的…… - -从交互的角度上来说，iPad Pro 虽然不支持 3D Touch，但是可以搭配 Smart Keyboard 与/或 Apple Pen（带有压力侦测）使用。对于键盘其实并没有什么好说的，如果一个网站在搭配键盘的桌面电脑上好用，它在 iPad Pro 上应该也不赖。而对于 Apple Pen，很可惜，目前似乎并没有 API 能让你在网站上获得这根笔的压力与角度。 - - -## 新的 iOS 操作系统特性 - -### iPad 上的多任务处理 - -自 iOS 9 起，iPad 允许两个应用在同一时刻并肩执行，有三种方式：**Slide Over**，**Split View** 与 **Picture-in-Picture**。不过，每一种方式都有其硬件需求，比如说 Slide Over 需要 iPad Air, iPad Mini 2 以上的设备，而 Split View 由于对内存的要求目前只支持 iPad Air 2 与 iPad Pro。 - -#### Slide Over（滑过来！） - -Slide Over 支持的 App 并不多，不过 Safari 名列其中，这意味着我们的网站将可能在这个模式下被渲染。当网站处于 Slide Over 模式下时，它将在屏幕的右 1/4 位置渲染，并且置于其他 native app 之上。 - -这个模式也为 Responsive Web Design（响应式网站设计）提出了新的挑战：**一个只为 iPad 优化的网站，也需要能在该设备上以无需手动刷新的形式支持小屏幕的渲染。**因此，如果你正在使用服务器端探测（RESS），那么你的 iPad 版本需要以某种方式包含手机版本的网站，或者在进入该模式后重新加载一次。（如果你不了解 RESS，你可以观看我的[另一篇博文](/2014/11/20/responsive-web-design/)） - - -![Slide Over](http://www.mobilexweb.com/wp-content/uploads/2015/09/slideover.png) - -在这个模式下，无论横屏还是竖屏，所有的 iPad（包括 Pro）都会把你的网站以 320px 的 viewport 宽度进行渲染，就好像在一个大 iPhone 5 上一样。你可以在 CSS 中通过 media query（媒体查询）探测到这个模式： - -```css -/* iPad Air or iPad Mini */ -(device-width: 768px) and (width: 320px) -/* iPad Pro */ -(device-width: 1024px) and (width: 320px) -``` - -#### Split View（分屏视图） - -在较新版本的 iPad 上，你可以将 Slide Over 的 Side View（侧视图）升级为 Split View。此时，两个应用将以相同比例在你的屏幕上同时工作。 - -在这个模式下，我们的网站将可能…… - -* **以屏幕 1/3 比例渲染时**，viewport 在 iPad Air/mini 犹如 iPhone 5，宽 320px。而在 iPad Pro 上则像是 iPhone 6：宽 375px -* **以屏幕 1/2 比例渲染时**，viewport 在 iPad Air/mini 上呈现为 507px 宽，而在 iPad Pro（横屏）下呈现为 678px 宽 -* **以屏幕 2/3 比例渲染时**，viewport 在 iPad Air/mini 上呈现为 694px 宽，而在 iPad Pro（横屏）下呈现为 981px 宽 - -![Split View](http://www.mobilexweb.com/wp-content/uploads/2015/09/splitview.png) - - -#### Picture in Picture（画中画） - -在一些较新版本的 iPad 上，使用 HTML5 video 标签的网站可以将其暴露到 Picture in Picture 机制中。通过 API（本文稍后会讲）或用户的触发，视频可以独立于网站在其他应用的上方继续播放。 - -![Picture in Picture](http://www.mobilexweb.com/wp-content/uploads/2015/09/pip.png) - - -### iOS 9 下的响应式网页设计 - -下图向你展示了 iOS 9 所有可能的 viewport 尺寸，检查检查你的响应式断点都包含它们了吗？ - -![iOS 9 RWD](http://www.mobilexweb.com/wp-content/uploads/2015/09/ios9rwd.png) - -### Safari View Controller - -如果你用过 Twitter 或者 Facebook（或者微信，微博……），那么你一定知道很多 native app 在打开一个网页链接时并不会默认使用 Safari。它们试图让你留在它们的应用里，所以通过提供 webview 让你在应用内进行网页浏览。可是问题在于，这类 webview 并不会与浏览器共享 cookies，sessions，autofill（自动填充）与 bookmark（书签），为了解决这些问题，就有了 Safari View Controller。 - -现在，native app 可以使用 Safari View Controller 来打开网站，它提供与 Safari 完全一致的隐私政策、local storage，cookies、sessions 同时让用户留在你的 app 中，它通过一个 “Done”（完成）按钮使用户可以回到 native app 的上一个 controller。这个全新的 controller 还可以让我们在 Share（分享）按钮上添加自定义的操作，这些操作在用户使用 Safari 应用时并不会出现。同时，native app 对这个自定义 Safari 实例具有完全的内容控制，你可以屏蔽不想被渲染的内容。 - -当你需要基于 web 的鉴权，比如 OAuth 时，使用 Safari View Controller 同样是一个好主意，这样就不再需要打开浏览器再重定向回你的应用。不过注意了，Safari View Controller 只适用于在线、公开的 web 内容。如果你的 web 内容假设在本地或者私服，那么 WKWebView 仍然是最推荐的选择。 - -> 笔者八卦一下，Safari View Controller 实际上也算是半个社区推进的产物。早在 2014 年 12 月，Tumblr 的 iOS 工程师 Bryan 就发表了一篇著名的 [We need a “Safari view controller”](http://bryan.io/post/104845880796/we-need-a-safari-view-controller) 叙述现有 webview 在第三方登录鉴权时的窘境。 -> 2015 年 6 月，Apple Safari 工程师 Ricky Mondello 的 Twitter 宣告了这个设想的落地：You all asked for it. Come see me introduce it. Introducing Safari View Controller 1:30 PM, Tuesday. Nob Hill. - - -### Safari Content Blockers - -现在，iOS 9 上的 Safari 支持一种全新的 App Extensions（应用拓展）：**Content Blocker**（内容拦截器）。这类拓展以 native app 的形式存在，你可以在 App Store 上下载到，它们可以拦截 Safari 内的任何内容，包括：跟踪器、广告、自定义字体、大图片、JavaScript 文件等等。 - -作为 web 开发者，尽管我们不能禁用 Content Blocker，我们仍然应该注意到它们的存在。诸如 Crystal 的一些拦截器宣称他们[可以提高网页的打开速度](http://murphyapps.co/blog/2015/8/22/crystal-benchmarks)。Crystal 声称可以加快网页的加载速度 3.9 倍并且少用 53% 的带宽。不过问题是：到底哪些东西被拦截器拦截了？[这篇文章](http://thenextweb.com/apple/2015/08/27/content-blocking-in-ios-9-is-going-to-screw-up-way-more-than-just-ads/)提到了一些我们未来可能会遇到的问题。 - -![crystal](http://www.mobilexweb.com/wp-content/uploads/2015/09/crystal.png) - -在 iOS 9 发布后，Peace，一个 Content Blocker，曾在 App Store 排名跻身前十。从用户的角度来说，如果一个网站由于被 Content Blocker 拦截了某些重要资源而不能正常工作，你可以长按重新加载按钮并且以不启用 Content Blocker 的方式重新加载这个网站（见下图，来自 MacWorld.com） - -![disable content blocker](http://www.mobilexweb.com/wp-content/uploads/2015/09/macworld.png) - -Content Blocker 能隐藏元素，也有能力通过 CSS 选择器、域名、类型、或者 URL 来过滤并拦截某个文件的加载，[Purify Blocker](https://itunes.apple.com/us/app/purify-blocker-fast-clutter/id1030156203?ls=1&mt=8) 给用户提供了拦截某一种内容类型的进阶选项，比如 Web Fonts。 - -![purify](http://www.mobilexweb.com/wp-content/uploads/2015/09/purify.png) - -### WKWebView 的增强 - -UIWebView 已经被官方弃用，虽然它还在在那，不过它再也不会得到什么升级。与此相反，WKWebView 正在取代它的位置。一个最受期待的特性现在终于推出：加载本地文件到 WKWebView。因此，现在 Apache Cordova 应用与其他 web 内容都可以直接从 iOS 包中使用本地文件了，不再需要各种诡异的 hack 了。 - -此外，还有一些新特性也一并推出。比如说，通过 WKWebsiteDataStore，Objective-C 或 Swift 有能力查询与管理 webview 的本地存储（比如 localStorage 或 IndexedDB）。这就允许我们将原有的数据存储替换成新的某些东西，比如说替换成一个不永久的（Chrome for iOS 的隐身模式就需要这种东西） - -### Universal Links（通用链接） - -如果你既有一个网站，又有一个 native app，你现在可以通过 Universal Links 来增强用户体验。它允许你在操作系统内“占有”自己的域名，这样，一切指向你网站的链接都会被重定向到你的 app。 - -目前，所有的 app 都是通过自定义 URI 来达到这个效果的，比如 `comgooglemaps://` 就可以用来从网站或者其他原生 iOS 应用中打开 Google Maps。 - -想要提供这个特性的话，你首先需要在 native app 中实现 Deep Linking（深度链接），让应用中的内容与 Safari 的 URL 吻合。然后，你需要在 Apple 的网站上关联你的域名，取得这个域名的 SSL 认证并且把签名后的 JSON 部署到该域名上。这是为了防止第三方的应用“占据”了属于你而不属于他们的域名，比如说 twitter.com 被非 Twitter 的其他应用占据掉。 - -目前唯一的缺点是用户好像并不能决定到底以哪种方式来打开内容（使用 web 还是 app），不过我们可以观望一段时间看看它会如何发展。在不远的这段时间里，你可能会发现在网站或 Google 搜索里点击一个链接时会没有任何预警的就跳进了 native app 里。 - -### App Search（应用搜索） - -Apple 带着自己的 web 蜘蛛杀进了搜索的市场，而我们需要支持它得以在 Siri 与 Spotlight 中提升自己的曝光率。这在我们同时拥有网站与 app 时尤为重要，因为现在 Apple 会索引你网站的内容，但打开时却可能将用户带到了 app 里去。 - -尽管这会开启 SEO 的新篇章，不过却相当容易。你需要使用一些标签标准，诸如 [Web Schema](http://schema.org/)、[AppLinks](http://applinks.org)、[OpenGraph](http://ogp.me) 或者 [Twitter Cards](https://dev.twitter.com/cards/mobile)，配合上 App Banner 与 `app-argument`，如果你有你自己的 native app 的话。 - -> 关于“让你的网页支持 Apple 搜索”的更多详情，请查阅 Apple 官方文档 [Mark Up Web Content](https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/AppSearch/WebContent.html#//apple_ref/doc/uid/TP40016308-CH8-SW5) - -Apple 刚刚发布了一个 [App Search Validation Tool（应用搜索验证工具）](https://search.developer.apple.com/appsearch-validation-tool/)来帮助你搞清楚，需要向你的网站添加什么才能支持 App Search - -![App Search](http://www.mobilexweb.com/wp-content/uploads/2015/09/appsearch-1024x467.png) - -### CloudKit JS - -如果你拥有一个 native app，你很可能会将用户数据保存在 iCloud 上。在过去，只有 iOS 与 Mac 应用被允许使用它。现在，通过 CloudKit JS，你的网站也可以连接上 iCloud 数据了。 - -### Back Button - -现在，当你链接到一个 native app 时（通过自定义 URI 或者 Universal Link），Safari 会询问用户是否想要使用 native app 打开这个链接（见下图）。如果用户同意了，这个应用将被打开，并且在左上角会有一个返回按钮可以返回 Safari ，返回到你的网站。 - -backbutton - -## 新的 API 支持 - -### Navigation Timing API - -Navigation Timing API 在 iOS 9 迎来了回归。让我们回忆一下，这货添加于 8.0 却在一周后的 8.1 中去掉了。这对于 Web 性能是个好消息。通过这个 API，我们可以更精确的测量时间，还可以获得一系列有关加载过程的时间戳，它们对于追踪与在真实场景中做决策来改进用户体验都非常有用。 - - -### Picture in Picture - -PiP API（被称为 Presentation Mode API）目前只支持 iOS，它允许我们手动让一个 `