下一代前端构建工具

2022 年，Webpack + Babel + Terser 仍然是前端项目构建工具的主流，广泛用于各种生产环境。不可否认，Webpack 和 Babel 仍然在持续进化，对各类研发提供了最稳定且全面的支持。但是随着前端项目规模的增长，CI 流水线的普及，构建性能问题已经成为了影响开发效率的一个关键因素。下一代构建工具，试图从不同的角度实现对构建效率的提升。

esbuild

用 Go 语言实现的构建工具，提供了编译，打包，压缩能力。由于是原生程序，且几乎不依赖第三方库，充分利用 CPU 多核架构等原因，esbuild 实现了夸张的毫秒级编译速度，效率数百倍于 Webpack + Babel。

优点：

• 高性能。目前最快的实现，整体上略优于 swc。
• 低占用。Go 语言对字符串的内存优化很好，即使采用多线程工作方式，内存占用仍然远低于基于 Webpack 的工具。

缺点：

• 自身不提供 HMR，需要依赖其他工具实现。
• 不支持 React Refresh，对 React 的 HMR 不能用 webpack-dev-server + esbuild 编译的方案。
• 产物代码分割功能仍处在实验阶段，相比 Webpack 和 Rollup 还是比较简单，不太可靠。
• 插件生态不健全。

适用场景：

• 纯 JS 库构建。不需要 HMR，只需要 watch 能力。
• Node.js 后端应用构建。不需要 HMR，只需要 watch 能力。
• Jest 和 SSR 等 Node 运行环境的代码转译。
• 嵌入其他构建工具。比如 Vite 用了 esbuild 的编译和压缩能力，不足的部分用 Rollup 插件体系和自己实现的 HMR 补全。

swc

用 Rust 语言实现的构建工具，swc 实现了编译和压缩能力，swcpack 实现了打包能力（实验性）。swc 设计之初就是完全对标 Babel 的，相比 esbuild 拥有更广泛的适用场景。

优点：

• 高性能。实际测试略慢于 esbuild，但也比 webpack+babel+terser 快上几十倍。
• 支持 React Refresh。这一点是对 esbuild 的巨大优势，且短期内 esbuild 无法克服的问题。

缺点：

• 自身不提供 HMR，需要依赖其他工具实现。
• 打包能力还是实验性质，缺乏高级配置支持。
• 插件生态不健全，用 Rust 编写插件门槛较高。

适用场景：

• 纯 JS 库构建。不需要 HMR，只需要 watch 能力。
• Node.js 后端应用构建。不需要 HMR，只需要 watch 能力。
• Jest (@swc/jest) 和 SSR 等 Node 运行环境的代码转译。
• 嵌入其他构建工具。比如 Parcel 用了 swc 的编译和压缩能力，不足的部分用自己实现的 HMR 补全，并有 Parcel 自己的插件体系。

Vite

基于 esbuild 的编译和压缩能力，Bundleless 的 HMR 实现，并用 Rollup 插件生态补足了常用的打包特性。目前性能和特性综合考量的最佳选择。

更早的 Bundleless 实现 Snowpack 已经泯然众人了。Bundleless 最大的问题在于，现在前端应用的依赖树太深太广，模块文件太多，逐个文件加载导致启动速度极其缓慢。而 Vite 则是融合了 Bundle 和 Bundleless 两种策略，对 node_modules 还是用 esbuild 去快速 bundle，一次性加载，对于源码再采用 bundleless 策略。这样就平衡了启动速度和热加载速度。

优点：

• 构建速度更快
• 热更新速度更快
• 能够使用众多的 Rollup 插件

缺点：

• 由于 esbuild 不支持 React Refresh，React 项目还是要走 Babel，一定程度上拖慢了速度。
• Rollup 及其插件生态还是以 JS 为主，性能优化空间有限。Vite 作者寄希望于 esbuild 打包能力和插件生态成熟，用 esbuild 替换掉 Rollup。

适用场景：

• Web 前端应用
• 浏览器插件
• Electron 应用
• 小程序

Parcel 2

Parcel 基于 swc 并有自己的 HMR 和插件生态。设计上与 Vite 类似，但 Parcel 自研部分更多，而 Vite 依赖且受限于 Rollup。性能上 Parcel 甚至更快一些，尤其是缓存性能，热启动极快。但在稳定性上 Parcel 控制的并不好，一个最简单的 React 应用都需要一些 hack 才能工作。

优点：

• 构建速度快
• 缓存效率高
• 热更新速度快

缺点：

• 不兼容 pnpm
• 插件生态不足

适用场景：

• Web 前端应用
• 浏览器插件
• Electron 应用
• 小程序

Turbopack(Alpha)

用 Rust 实现 Webpack 替代，工作原理和 Webpack + Webpack Dev Server 保持一致，而没有走时下流行的 bundleless 路线。当项目源码（不包括 node_modules）文件数量达到数千，Vite 启动速度会随文件数量降低，即使本地几乎不存在网络延迟，数以千计的 HTTP 请求以及代码转译任务仍然耗时不菲。而 Turbopack 则通过提升打包性能，在保持 Webpack 工作方式的情况下，实现了快速启动和 HMR。当前 Turbopack 的测试性能是领先 Vite 的。

假如 Vite/Parcel 也用 Rust/Go 完全重写，那么 Vite/Parcel 和 Turbopack 应该具有以下关系：

• 在文件数量小于 N 时，Vite/Parcel 的冷启动速度更快，但是 Turbopack 也足够快。
• 在文件数量大于 N 时，Turbopack 的冷启动速度更快，且于 Vite/Parcel 的差距越来越大。
• Vite/Parcel 的 HMR 速度总是快于 Turbopack，但是两者都足够快，以至于差异肉眼无法分辨。

可惜 Turbopack 目前并没有推出正式版本，完全没有达到 Vite/Parcel 的成熟度，因此完全没有可比性。目前只能关注，深入分析或评测意义不大。

2022年 10月 28日 | 评论

JavaScript 十进制库选型

众所周知，计算机以二进制存储数字，而真实世界中用十进制表示数字。二进制和十进制的差异可以用一个乍看非常怪异的例子说明：

> 0.1 + 0.2
0.30000000000000004

不管是 JavaScript, Python 还是 Java，都能够得到类似的结果。

分析原因，就像十进制中的 1/3 是无限循环小数，二进制中的 1/10 和 1/5 也是无限循环小数。计算机的基本数字类型都是有精度限制的。两个无限循环小数相加，导致精度损失，产生了 0.30000000000000004 这样的结果。

在很多情况下，这个并不会有实际影响。因为十进制同样有精度误差，十进制并不比二进制更精确。它真正导致的问题是违反直觉。对于人直接可见的数字计算，比如购物车结算总价，出现二进制精度问题显然会让不了解二进制原理的普通用户感到诧异。

另外，原生浮点数的取整方法都是四舍五入。按照统计学规律，大量累加起来，总数会偏大。对于电商，银行和支付系统，会导致交易的某一方长期多付出，是违反公平的。因此这些系统常常采用银行家算法（四舍六入五成双）。

最后，整数和浮点数都有固定的精度限制，且受限于硬件或编译器无法更改。计算超出范围的大数会出错，不安全。

基于这三点原因，在电商和金融系统中，会使用十进制类而非基本数据类型来计算和存储交易数字。

JS 常用库比较

JavaScript 目前仍然没有原生的十进制类。我们只能从一些提供十进制类的 NPM 包中选择。不同的十进制库提供的功能不完全相同。通常功能越多体积越大。目前开发比较活跃且比较流行的 JS 库都来自同一位作者。差异详见此处。

从简单到复杂排列：big.js < bignumber.js < decimal.js

从打包体积来看，big.js 最小，在浏览器端占据优势。

在电商和金融场景，更常见的精度控制方法是控制 N 位小数，big.js 和 bignumber.js 更加合适。而在科学计算和工程领域，可能 decimal.js 的控制 N 位有效数字的特性会更合适一些。

除法都是有精度损失的，这是无法避免的。但是 decimal.js 的加减乘法也有精度损失，这一点需要注意。

big.js 对于超大数的计算会比 bignumber.js 或 decimal.js 慢，要结合具体场景分析是否会性能瓶颈。在前端/客户端场景，或者小型电商后端，计算量很小，且大数不常见，那么 big.js 完全可以胜任。在大型电商平台和金融交易后端，大数计算量繁重，那么 bignumber.js 会更好一些。科学和工程领域需要的超大数计算，则 decimal.js 会更合适。（但是这些领域通常也不会用 JS 这么慢的语言，所以 decimal.js 的定位有点尴尬）

超小数通常只在金融，科学和工程领域出现，这种数据的计算 decimal.js 会比 big.js 和 bignumber.js 快。和上面的大数应用场景分析类似，要视情况选择。

默认的舍入模式都是四舍五入（ROUND_HALF_UP），且都支持银行家算法——四舍六入五成双（ROUND_HALF_EVEN）。对于大多数电商和金融场景都足够用了。

decimal.js 还支持对数，复数，三角函数等高级数学运算。

按应用场景选择

中小型电商

中小型电商的交易数字都偏小，big.js 在前后端都可以胜任，满足精度控制，舍入模式和性能的需求。同时 big.js 的体积较小，有利于优化前端传输速度。

大型电商平台和金融系统

前端/客户端通常只处理单一客户的计算需求，大数出现频率较少，通常不存在性能问题。 big.js 依然可以胜任。

后端则可能会频繁处理大数，这时候 bignumber.js 会更快一些。但是，这种情况通常表明整个系统都面临性能问题，更加实际的做法是将重度计算的服务用 Java 之类的更高性能语言重构……

科学计算和工程领域

decimal.js 功能更加丰富，对极大和极小数计算的性能更好，比 big.js 和 bignumber.js 更合适。

但是，这些领域通常对性能要求很高，用 JS 的情况非常少见。建议直接使用一种更合适的语言……

总结

前端选择 big.js 一般都没错。它简单小巧，却又能提供所有我们需要的功能。

后端 Node.js 不需要考虑打包尺寸，如果有比较多的大数计算量，也可以上 bignumber.js 的。

decimal.js 的定位则比较尴尬，除非你特别需要某些科学计算功能，否则没有必要选它。

实践

1. 阿里巴巴 Fusion Design 从 bignumber.js 切换到 big.js PR 链接

2022年 6月 18日 | 评论

前端最佳实践：字体

字体单位

px 依旧是最全面的选择，尤其是重交互的网站：

1. 能够做到设计稿的像素级还原。
2. 用户体验统一，变量少，可控。
3. 方便配合 JS 动态计算布局，JS 接口通常只能获取像素为单位的尺寸和位置。
4. icon，图片和 border 通常都是使用像素尺寸，字体采用像素单位更容易配合。

rem 在文字内容型网站上更加灵活，适合新闻，博客等：

1. 自适应不同设备，不同用户偏好，获得最佳阅读体验。
2. 无需手写繁复的 media query。

有些创意内容网站使用 vw 尺寸系统，字体和图片总是同窗口比例缩放，以实现类似海报布局的整体感，但也仅限于这一类型的网站。

em 和 % 会用在局部使用，但存在嵌套后尺寸不容易控制的问题，极少在项目中大范围使用。

pt 是印刷常用单位，不适合现如今的 Web 环境，且和 px 对应关系复杂，应该避免。

正文字体大小

12px 是 Chrome 浏览器默认支持显示的最小字体。即使 CSS 设置了 9px，最终用户看到的仍然是 12px 字体。因此在设计中使用小于 12px 的字体是一个严重的错误。12px 的英文字体可读性尚可，但是中文可读性比较差。建议作为次要文本字体的尺寸。

13px 是信息密度较高，中文可读性尚可的选择。比如 Facebook 和百度用的就是 13px。

14px 是信息密度和中文可读性的一个比较好的平衡点，适合界面复杂且空间比较紧张的网站的正文字体大小。比如

16px 是大部分浏览器的默认字体大小，可读性好，但是信息密度不高，适合一般网站。

18px 以上通常只有在创意营销网站上才会作为正文字体大小使用。

一个比较通用的策略是：

• 12px：次要文字，页脚链接，标签分类，面包屑，输入框提示，小按钮，小输入框
• 14px：普通文字，正文，输入框，按钮
• 16px：突出文字，卡片标题，大按钮，搜索栏

标题层级字体大小

HTML 支持 H1 到 H6 共六级标题。但实际应用中，我们应当控制标题的层级数量，层级越多，使用体验会越差。

功能为主的网站对标题依赖比较小，更多是靠 Card 和 Tab 等容器进行界面层级管理。

内容型网站对标题层级的需求会更高一些，但也尽量不超过三级。

H1 字体大小取决于网站类型对信息密度的要求。以功能为主的系统通常 H1 会比较小，不会超过 40px。

H1, H2, H3 之间应当有 30% 左右的递减，视觉上差异才够显著。比如：

• H1, 36px：页面标题
• H2, 24px：章节标题
• H3, 16px：子章节标题，卡片标题，弹窗标题

字重

最早字体只支持两种字重，正常（normal, 400）和粗体（bold, 700）。现代 Web 字体的字重支持 100 到 900 等 9 种字重，100 最细，900 最粗。但是系统字体支持的字重数量通常较少。

Windows 默认中文字体“雅黑”支持 300, 400 和 700 三种字重。macOS 和 iOS 默认中文字体“苹方”支持 100/200/300/400/500/600 六种字重（苹果更喜欢使用较细的字体设计）。也就是说“苹方”的粗体，会比“雅黑”要细一些。Android 系统默认字体 Noto Sans CJK 支持 200/300/400/500/700/900 六种字重，最为全面。部分 Android 系统，比如魅族 Flyme 和小米 MIUI，甚至搞出了字重的无极调节。

由于中文字体体量巨大，通常网站不会加载远端中文字体，而是使用系统字体。因此，在使用字重的时候，就需要考虑系统字体的字重支持。综合主流操作系统，得出兼容性最好的字重集合：细体 300，正常 400，粗体 700/600。

2022年 4月 5日 | 评论

前端必学&勿学清单（2022更新）

前端技术发展很快，有些技术如常青树，有些则已日渐式微。不断涌现的新技术，有的是真创新，有的是换汤不换药。本文希望帮助大家避免在没有学习价值的技术上浪费事件。

需要注意的是，仅凭个人经历去判断一项技术是不是不流行，是很片面的。很多人在整个职业生涯中都没有遇到过 Angular 项目，但这并不代表 Angular 没有人用。有人觉得 Vue 小众，是玩具，但是其生态仍然在蓬勃发展。本文尽量从技术架构和统计数据来分析，而非个人经验。

更新于 2022 年二月。

2021年 3月 14日 | 评论

技术对 UX 的影响

做一个应用程序有非常多不同的技术选择。使用 Web 技术既可以用做小的开发成本做出跨平台的应用，但是性能和功能又有诸多限制。完全使用原生技术则需要极高的成本。选择技术的因素固然有很多，不同的技术可能实现相同的功能，但体验上是有差异的。

下面介绍的顺序是从更接近 Web 技术到更接近原生技术。

Web 后端渲染

典型的 Web 应用模式，网页在后端进行渲染，配合少量的 JavaScript而构成的应用。这种模式适合交互简单，以内容为主的应用。典型的例子是 GitHub, WordPress, Wikipedia 之类的网站。

后端渲染对服务器的压力更大，每跳转一个页面，浏览器都要等待至少数秒钟。除了 Safari 之外的移动浏览器都有一个刻意而为的点击延迟 (300ms)，这让点击链接跳转在移动端的体验变得更差了。速度是最大的弊端。

单网页应用

使用 Angular, React, Vue 之类的 JavaScript MVC/MVVC 框架制作的应用。前端作为 JavaScript 被整个或部分加载到浏览器。然后只从服务器获取需要的数据，更新页面的部分内容而不需要重载页面。服务器不再需要处理网页渲染，数据可以缓存，数据库查询等耗时操作也更少。这种模式适合交互频繁，数据更新频繁的应用。典型的例子有 Twitter, Facebook, Instagram 之类的网站。

缺点仍然很多：

1. 初次加载仍然非常耗时。
2. 受到浏览器限制，尤其是移动浏览器。
   1. 大多数移动浏览器在滚动时会自动隐藏地址栏。如果有浮动元素的话，这会非常讨厌。
   2. iOS Safari 强制所有网页可两指手势缩放。这种缩放可能会破坏原有布局，给人一种不可靠的感觉。而原生应用是不可以被整个自由缩放的。
   3. 仍然有点击延迟 (300ms)。这是单网页应用给人一种比原生应用慢的最常见原因。
   4. 移动浏览器的性能导致很多动画变得缓慢卡顿。
3. 设计/开发模式的问题。
   1. Web 开发者通常不会花心思去做手势操作和过渡动画。
   2. 在桌面用响应式设计模式开发，并不能完全模拟实际设备的交互感觉。主要问题在于屏幕尺寸，手指的精度和活动范围，以及导航栏和键盘的影响。
   3. 桌面和手机共用结构和组件，常常在手机上不太好用。

Electron 和 Cordova

这两个东西都是提供了原生系统接口的 Web 容器。Electron 主要用于桌面应用，只要 NodeJS 可以做到的它都可以做到，因此可以使用非常之多的原生接口。Cordova 或者 PhoneGap 面向移动平台，能使用的接口由插件提供，非常之有限。

1. 加载时间快，不需要下载界面组件。
2. 界面仍然是 Web 引擎渲染的。运行性能仍然比原生差，但是优于浏览器。
3. 相比浏览器，消耗更多的系统资源。
4. 浏览器界面的干扰被削弱。没有标签页，地址栏，更像是单应用。
5. 无法使用一些原生的库和系统接口。

React Native

JavaScript + 原生 UI。一个性能和快速跨平台开发的折中选择。但也可能是一个陷阱。

1. 界面与原生应用几乎没有差异，交互非常流畅。
2. 只提供了原生 UI 组件的一个子集。
3. 可用的原生系统接口有限，第三方 SDK 就更少了。很多功能仍然用 Web 技术实现，变成了混合式应用。
   
4. 可能会使用更多的资源，启动较为缓慢。

原生应用

原生应用可以在所支持的平台上做尽可能多的优化，取得最好的效果。但代价是巨大的开发成本。

以视频播放器为例，原生应用可以支持任意视频格式，并尽可能优化性能，获得悬浮窗等系统权限。

总结

待续……

2018年 11月 7日 | 评论

一周的进展

本周做了 Santakani 网站首页的改版。

对比旧版，新版将首页/设计/设计师三个列表页面合并为全新的首页。导航栏因此得到简化，只有 Design，Map 和 Story 三个选项。首页顶部采用了一种浅色有机纹理，取代了滚动的图片。文字也大大简化，更注重表达简介明了的含义，无需深度阅读。列表我最终还是决定用设计师作为主体，一行照片，一行产品。希望每个设计师的设计风格得以表达，而不是被散落在随机的产品列表中。图片采用了类似 500px 的等高填充布局，让横版和竖版的照片都能完美呈现，只做微小裁剪。

本周做的另一个项目是 openSUSE 的新网站主题。

试用了 Bootstrap 4 Alpha 6 版。虽然还有很多小缺陷，但整体上非常棒。使用 Bootstrap 自身的 Utility 类就能调节各种布局，大大减少了自己写 CSS 的工作量。

在 Google+ 上分享这个 Demo 之后得到了很多好评，感觉动力满满。

另外参考 KDE 的翻译项目，给 openSUSE 的文档项目添加了 XML ↔ PO 转换功能，这样就可以利用 Weblate 网站翻译文档。

毕业设计艰难进行！做了一次范围更大的问卷调查，参与调查的女性 100%，好像很不科学的样子。或许就像老师曾说的，女性更热衷于参与和奉献。

2017年 1月 21日 | 评论

验证码：UX 终结者

网络验证码技术虽然是外国人发明的，但却在天朝泛滥成灾。

我们有那么多同学去做 UX ，花了那么多心思给用户提供更好的体验。到最后，被一个验证码全毁了。万恶的验证码，以及走不动的进度条，总是最烦人的。

简单的麻烦——淘宝的滑动验证码

淘宝和微博目前使用这个验证码，原理和 Google 的 reCAPTCHA 2 类似。第一步让用户拖动滑块（触屏或鼠标），然后记录鼠标或手指触摸的轨迹，猜测用户是人还是机器。同时还会测试浏览器的排版引擎，JavaScript 引擎等等，确定这是一个人类使用的浏览器，而不是机器人程序。

在滑动过程中，鼠标位置/手指位置的数据是发送到服务器进行验证的（密文，如下图）。由于这一过程很短，采样率有限，而且直线滑动的人为特征性也不是很明显，即使算法再好也很容易被破解程序骗。

如果第一步判断不是人或者把握不准，则进入第二步，即传统的图形验证码。

有没有必要

它挡不住破解程序。滑动验证比图片验证要弱，所以图片验证码才会作为第二道防线。只要写一个程序控制鼠标，并且让鼠标轨迹看起来不那么有规律就可以了。（配合浏览器，骗过浏览器性能验证机制）

如果是通过用户的交互行为来判断其是人还是机器，大可不必显示这个滑块。用户在浏览网站或使用应用的过程中必然要进行大量交互，记录这些数据要比滑动那么一下有效得多。

滑动验证是不能证明其对错的，它的数据和算法都是不透明的，而且可以推测其原理极其复杂。即使用户觉得自己是滑动到了最右端，它仍然可以强硬地不通过验证，给用户一种很无奈的挫折感。目前看来这算法确实有问题，因为通过率出奇地低于文字验证码的通过率。如是玄学，寡人不服 XD

这就造成了两种常见结果：

1. 破解程序没被挡住。
2. 一些用户验证了两步。

在我使用的十次当中，有七次没有通过滑块验证码，而不得不使用图形验证码。滑动和使用图形验证码所需的反应时间其实是差不多的，这意味着我比使用单一图形验证码反而多用了 70% 的时间。

而某些破解程序，已经能够做到 80% 以上的成功率。令人唏嘘不已。

两步验证码的组合更是浪费时间。

我只能说：这不合理。

四处滥用

昨天，有个人在微博上给我发消息，我用 Android 应用回他一下，然后就冒出了验证码，必须要完成验证才能发送消息。然后连续输入错误，消息没有发送成功。

我今天在淘宝注册账号，更改设置，总共输入了十几次验证码。即使我已经输入了短信验证码，后续还是被要求输入滑动验证码。

对于已经登录的用户，验证码通常是没有必要的。如果想验证用户是不是机器人，为什么不在登录的时候提前验证好？如果想验证用户是不是本人，则应该输入密码或者短信验证码。

我在使用 Facebook 和 Twitter 的这些年里，除了短信验证码和手机令牌，从来没有遇到过滑动验证或文字验证码的时候。Paypal 和 Amazon 的验证码也出现得极少，甚至于我都忘记了他们的验证码是什么样子。

当一个交互过程需要安全检查，而人们又想偷懒的时候：加个验证码吧。

验证码是一个在设计过程中绝对应该尽可能避免的东西。不管形式怎么变，用户都会反感，因为它带来了麻烦，且不止一次。它不能保证安全，任何现有的验证码机制都有破解之法。越复杂的验证码，对于人类的挑战也越大。

Sweet Captcha

参考链接

1. Inside reCAPTCHA – Google “点击验证”的原理和简单破解方法
2. 淘宝滑动验证码研究

2016年 8月 25日 | 评论

互联网内容的语言

世界上的语言有成百上千中，不只有英文，俄文，法文，西班牙文，中文这样的广义语言，还有方言，古语等狭义语言，比如美式英语，英式英语，简体中文，繁体中文，文言文，吴语，粤语等。地理分布越广，文化组成越复杂的语言，其分支往往越多。中文尤其复杂。

如果要设计一个互联网应用，并希望支持多语言，就有很多问题需要考虑。 继续阅读 →

2015年 10月 30日 | 评论

如何愉快地学习网页编程

之前有同学和我说想学习网页编程，我随口答应帮忙，却一直到现在才有空写写。网页编程的教材网上有很多了，我只是搜罗一下，并附上一些学习建议。 继续阅读 →

2015年 3月 28日 | 评论

校内维基的构想与实现

在写下这一篇的时候，我们的维基还是一个知名度不高的校内网站。经过近一年的尝试调整，渐渐得到了发展的方向。去年的时候，我们开始构想一个校内百科。动机很简单，我们觉得每个大学都会需要一个百科全书样的东西。我们的参考目标是维基百科，依靠mediawiki和理想化的社群模式运作。而在这之前，至少有五个类似的网站已经失败。

开始的时候我们有一系列定位和发展规划。制订了内容收录规范，以及社群守则。因为蓝本是维基百科，所以我们觉得它会像维基百科一样依靠用户贡献发展。问题是很多事情不一样。

首先是网站本身的意义。学生们并不是非常需要了解学校的历史，建筑和人物。即便需要的时候，他们也会去查询谷歌搜索。基本的信息维基百科都可以包含，我们只是做了一个更详细的工作，却花费了太多时间。既然是内容主导的网站，什么样的内容最被需要才是关键。

然后说说用户群体。我们的用户群体，是本校学生和教师。我们希望大家能通过此平台分享知识，互助协作。然而师生对此理念并不了解，网站在大多数人眼里仍是一个放内容的工具。一个开始就没有内容的网站，如何让用户参与其中呢？他们会怀疑网站未来的延续问题。

在技术上同样存在麻烦。mediawiki的内容编辑是通过代码实现的，十分复杂，而且不够直观。这严重阻碍了一般用户的参与。

我们的运营也有不少失误。太多的限制和质量要求让早期的内容积累举步维艰。像版权问题，我们并没有能力去验证，实际上是形同虚设的要求。

后来我们陆续进行了几项改变。

收录内容范围扩充，计划成为校内资料库。包含校内信息，在线教材，学习经验，共享文件等。

组建内部编辑组，积累原始内容。我们还通过技术从其他网站导入信息。内容积累足够多，用户对它的认可度也会增加。

在可视化编辑器部署之前，我们通过提供简捷的帮助，降低用户参与的难度。

同时也取消了不可执行的规则，以促进早期的内容积累。

现在的校内维基，已经改变了很多。我们很希望它会是一个成功的网站。

2013年 9月 23日 | 评论