Weekly#11

兹冯金对孩子和成人同样有效的一个方法是，反复重复一些事情，让重复之间间隔很长时间。

这和我自己想弄明白一件事时，会认真思考一段时间，然后出去散步或洗澡的道理是一样的。

你是在劫持认知的集中模式和扩散模式之间的相互作用。

如果每次重复时，你都能从不同的角度来解决问题，那么效果会更好，这样你的潜意识就会有新的材料来咀嚼。

这只是为人父母的普遍经历的极端版本。

从第二个孩子出生的那一刻起，有时甚至在他们出生之前，他们就开始告诉你，你对第一个孩子的人生轨迹所产生的影响是多么微不足道。

他们之间的差异，尽管你们所做的一切几乎都是一样的，却证明了养育孩子的过程实际上是一个无能为力的过程，是一个看着新生命发现并向世界展示自己的过程。

从某种程度上说，这使得正在发生的事情更具有戏剧性–你培养出的不是一个可以编程的白板，而是一个外星智慧生物，它将创造出一个全新的宇宙。

Vue 的作者尤雨溪宣布了一家新公司 VoidZero 的成立，目前已经筹集了 460 万美元的种子基金，计划打造下一代 JavaScript 工具链。

他们目前交付出来的产品有： Oxc， vitest， Rolldown 。

感兴趣还可以看看 ViteConf 2024 Replay。

"Let's take the bus home!" my daughter said.

What a terrible idea. It would take an hour and two busses to get there, and I would most certainly get a call to come and pick up the car as soon as we'd arrive home. Terrible.

"Ok, let's do it," said I reluctantly. I know how much my daughter enjoys riding the bus. We never do it, so every time feels special.

Seeing how happy she was, it was all worth it—best $4 I've ever spent.

What's something a bit counter-intuitive you could do to delight your child this week?

P.S.: When we finally got home, it was, as anticipated, time to pick up the car. I was planning on taking a taxi but … Sophie asked if we could ride the bus back there. No regrets!

虽然乘坐公交时间长也比较麻烦，但是女儿开心，就值了。

Feynman famously said: Imagine how much harder physics would be if electrons had feelings.

Getting started shouldn't be an afterthought after you built the product. Getting started is the product!

入门不应该是在构建产品之后才考虑的问题。入门就是产品！

…

Make it possible for users to use your product on their laptop in a couple of minutes, tops.

让用户在几分钟内就能在笔记本电脑上使用您的产品。

产品要让使用者能快速上手，要是需要配置一堆东西，花半天时间，可能不少用户会放弃使用。

Too many programming books and tutorials are like “let’s build a house starting from scratch, brick by brick” when what I want to “here is a functioning house, let’s learn about it by changing something and then seeing what happens”

太多的编程书籍和教程就像“让我们从头开始，一砖一瓦地建造一座房子”，而我想要的是“这里是一座正常运转的房子，让我们通过改变一些东西来了解它，然后看看会发生什么”。

The sad but true part of programming is, the default mode is that you're fixing an error of some sort. This means that users are going to spend the majority of the time with your tool trying to figure out what's not working.

编程的可悲但真实的一面是，默认模式是你在修复某种错误。这意味着用户在使用工具的过程中，大部分时间都在试图找出问题所在。

• Developers getting to success faster are happy developers. They will like your tool. 更快获得成功的开发人员是快乐的开发人员。他们会喜欢你的工具。
• Developers banging their heads against errors are sad developers. They will blame your tool. 在错误面前磕头的开发人员是可悲的开发人员。他们会指责你的工具。

Put code snippets in the exceptions. Emit helpful warnings when users are likely to do something weird. Do what you got to do to make the user succeed.

在异常中加入代码片段。在用户可能做出奇怪举动时发出有用的警告。尽你所能让用户成功。

如果使用你工具的人总是碰到问题，而且也没有足够的反馈告诉用户如何解决问题，用户就会有很多挫败感，从而放弃使用这个工具。

相反，给用户足够的反馈，尽可能地帮助他们顺利地使用你的工具，用户就会快乐地继续使用你的工具。

Every new conceptual thing you have to understand before using the tool makes is a new friction point. If it's 2-3 things, that's fine. But no one is going to bother learning 8 new concepts.

在使用工具之前，你必须了解的每一个新概念东西都是一个新的摩擦点。如果是 2-3 个东西，那还好。但是没有人会去费心学习 8 个新概念。

避免概念过载，降低用户的心智负担。关于心智负担，可以看看 Cognitive Load is what matters。

Somewhat related to the previous point, let's say in your framework you introduce a thing that takes some values and evalutes to a new values. What do you call it? A compute node? A valuator? A frobniscator?

No! You call it a function!

与前一点有些关联的是，假设在你的框架中引入了一个东西，它可以获取一些值并求值到一个新值。你怎么称呼它？计算节点？估值器？估值器？

不！你称之为函数！

If it walks like a duck, and it quacks like a duck, it probably is a duck.

如果它走起路来像鸭子，叫起来也像鸭子，那么它可能就是一只鸭子。

Calling it a function means you latch onto a users pre-existing mental model of what a function does. Which will save you like, 90% of the explanation of how to think about this object.

将其称为函数意味着你抓住了用户关于函数作用的已有心智模型。这将省去 90% 的解释工作，让你知道如何看待这个对象。

Unless defaults apply in 97%+ of the time, and unless magic applies 99% of the time, be careful about introducing it. These are not exact numbers obviously, but my point is, you need to be very very judicious.

除非在 97% 以上的情况下使用默认设置，除非在 99% 的情况下使用特殊方法，否则在引入时一定要小心谨慎。这些显然不是精确的数字，但我想说的是，你需要非常非常谨慎。

I sometimes think the challenge of designing for the 1st time user is similar to making a pop song. The producer will listen to the song a thousand times. But still the 999th time they hear it, they need to imagine what it sounds like to a person that hears it the first time, which seems… super hard.

我有时认为，为第一次使用的用户进行设计所面临的挑战与制作一首流行歌曲类似。制作人会听上千遍这首歌。但在第 999 次听到这首歌时，他们仍需要想象第一次听到这首歌的人听起来是什么感觉，这似乎……超级困难。

Increased efficiency can sometimes, counterintuitively, lead to worse outcomes. This is true almost everywhere. We will name this phenomenon the strong version of Goodhart's law. As one example, more efficient centralized tracking of student progress by standardized testing seems like such a good idea that well-intentioned laws mandate it. However, testing also incentivizes schools to focus more on teaching students to test well, and less on teaching broadly useful skills. As a result, it can cause overall educational outcomes to become worse.

效率的提高有时会导致更糟糕的结果，这与直觉相反。

这种情况几乎无处不在。我们将这种现象命名为古德哈特定律的强力版本。

举例来说，通过标准化测试对学生的进步进行更有效的集中跟踪似乎是个好主意，以至于用心良苦的法律对此做出了规定。

然而，考试也会激励学校把更多精力放在教学生如何考好考试上，而不是教学生掌握广泛有用的技能。

因此，它可能会导致整体教育成果变得更糟。

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.

一旦出于控制目的对其施加压力，任何观察到的统计规律性都会趋于崩溃。

Goodhart's law

一篇论文，作者提出了一些编辑器的设计思路。

其中，将注释放到左边，让注释更明显的设计感觉不错。

文学编程，我理解就是反转注释和代码的重要性，不再编写包含文档的代码，而是编写包含代码的文档。

I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title: "Literate Programming."

我认为，大幅改进程序文档的时机已经成熟，而将程序视为文学作品是实现这一目标的最佳途径。因此，我的标题是"文学编程"。

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

让我们改变传统的程序设计态度：与其认为我们的主要任务是指导计算机做什么，不如让我们集中精力向人类解释我们希望计算机做什么。

– Donald Knuth. "Literate Programming (1984)" in Literate Programming. CSLI, 1992, pg. 99.

Progressive enhancement is a way of building websites and applications based on the idea that you should make your page work with HTML first.

Only after this can you add anything else like Cascading Style Sheets (CSS) and JavaScript.

渐进增强是一种构建网站和应用程序的方法，它基于这样一种理念，即首先要让页面使用 HTML 运行。

然后才能添加其他内容，如 CSS 和 JavaScript。

文章提出了一些建议，主要是为了让页面稳健，不容易出错。

Progressive enhancement means building the interface of a website or application in layers. If the user’s browser only supports HTML they get content and forms. If the user’s browser also supports styles and fonts the application looks better. If it can run JavaScript the user gains extra interactions. Only the core HTML though is required in order to meet users’ basic needs.

渐进增强意味着分层构建网站或应用程序的界面。

如果用户的浏览器只支持HTML，他们就会得到内容和表单。

如果用户的浏览器还支持样式和字体，应用程序就会看起来更好。

如果它能运行 JavaScript ，用户就能获得额外的交互。

满足用户的基本需求只需要核心的 HTML。

– Why we use progressive enhancement to build GOV.UK

They may not have set out to share out of altrusitic motivations. I am certain they never intended to inspire a 12 year-old kid to find a better life. But it doesn't matter their motivations. They changed my life. All I can say is thank you. Thank you for sharing your work. Thank you for your blogs posts, your tutorials, thank you for your slashdot comments, for your posts on digg. No matter how small your contribution, it mattered to me. You changed my life. Thank you.

他们也许并不是出于利他主义的动机才开始分享的。

我确信他们从未想过要激励一个 12 岁的孩子去寻找更美好的生活。

但他们的动机并不重要。他们改变了我的生活。我只能说谢谢你们。

感谢你们分享自己的作品。感谢你们的博客文章、教程，感谢你们在 slashdot 上的评论，感谢你们在 digg 上的文章。

无论你的贡献有多小，对我来说都很重要。你们改变了我的生活。谢谢你们。

Eslint 现在可以 lint JSON 和 Markdown 了，真不错。

Linux From Scratch (LFS) is a project that provides you with step-by-step instructions for building your own custom Linux system, entirely from source code.

前阵子将评论系统从 utterances 换成了 giscus，参考了这篇文章。

原来 utterances 生成的 issues 可以批量转换成 giscus 的 discussions。（参考 Converting issues based on labels）

关于 bundle 工具的过去、现在和未来。

JS 函数式编程入门，非常多的概念，准备好一杯咖啡再慢慢看吧 :P

<dialog> 和 popover 的详尽比较。

对于页面上的“危险操作”，如何设计交互。

Therefore, a dangerous action does not necessarily mean deleting something.

Some examples may include the following:

• Sending an email
• Placing an order
• Publishing a post
• Making a bank transaction
• Granting or revoking permissions.
• …

一种常见的交互是 Modal，在使用 Modal 的时候最好详细描述操作的影响，而不是仅仅一句“你确定吗”，让人摸不着头脑。

有时只是让用户确认还不够，可能还需要用户输入一些内容才允许完成操作，例如 GitHub 删除 Repo 时的交互。

此外文中还提到了其他方法：

• Danger Zone
• Inline Guards
• Two-factor Authorization Confirmation
• Second-person Confirmation (类似 Pull request，需要另一个人的审批)
• …

最后作者还补充了一个交互更好的例子。

作者实现了一种滚动选择元素的组件，类似 select。

用到了 overscroll-behavior，scroll-snap-type，Intersection Observer API 等。

结合 JS 去绘制 SVG，将一些 SVG 的变量抽离出来定义，用 JS 计算，这样手写 SVG 就会相对容易一点。

关于 counter() 的一些用法，但是其实 list-style 也能实现类似的功能。

logo 的高度宽度都不太相同，当把多个 logo 放在一起做成 logo 条的时候，如何让不同 logo 保持视觉上的平衡？

文章提出一种基于 logo 长宽比调整高度的方法。

一个手绘风格的网站，画风，音乐，交互都不错。

一个用 CSS 实现的音乐视频。

作者不想每天看屏幕，恰好买了一个点阵打印机（像是打印发票用的打印机），就想着能不能把每天想看的头条打印在一张纸上。

在屏幕不同的位置，会得到不同频率的噪声。

Google 的一个产品，将一些资料喂给它，它可以生成一段很逼真的播客。

炊紙(kashikishi) is a text editor that utilizes GPU to edit text in a 3D space.

编辑交互看起来不错，不过目前只能作为一个方便的记事本，不具备打开和编辑任意文件的功能。

通过几个选项，找到满足你需要的许可证。

一些免费的插画，种类比较多。

Superdiff compares two arrays or objects and returns a full diff of their differences in a readable format.

A light weight interface for running git commands in any node.js application.

Beautiful color gradients in terminal output.

图片占位工具，类似的还有 temp.im。

mitata is a powerful JavaScript benchmarking library with ascii visualizations, automatic garbage collection, and built-in confirmation bias

网站提供了很多图表，并进行分类和解释。

当有一些数据需要可视化，但是不清楚用什么图表比较合适的时候可以参考一下。

周报会分享一些用户体验相关的内容，还不错。