知鸦日报2022-07-22

上一篇文章我谈论了用户故事的话题，讲到了人们为什么爱听故事，以及人们喜欢听怎样的故事，感兴趣的朋友可以去看看浅谈用户体验（五）一个用户故事。

今天我们就继续来讨论和故事相关的话题，聊聊那些成功的企业是如何讲好故事的，我打算通过分析苹果公司的一些案例，来分享我的一些观察和理解。

用户体验设计作为产品设计中的一环，很多时候我们说体验好不好，其实是相当主观的。我们带着我们既往的经验和价值取向，来评价一个产品的用户体验是好是差，这是十分不客观的，即使我们是专业的从业人员，但我们很可能并不是产品的目标用户。

所以我们需要把话筒递给真实的用户，让他们去发声，好与坏，对与错，他们才是真正的裁判员。

本篇文章总结了交互新人在初工作过程中可能面临的疑惑与问题，并结合自身经历总结了相关设计经验，希望能够帮助新人设计师快速上手B端设计，游刃有余的应对工作中面临的各种机遇与挑战。

我们的目标是帮助用户用最快的形式、方法完成注册或登录，但这个环节需要实际输入、选择等操作，注册&登录交互设计最佳原则、案例实践。

表单是交互设计中一项重要的组成部分，尤其是人机交互、界面设计、信息反馈、可视化等相关层面，我们通过 30 项最佳设计实践案例，分析表单的设计方法和技巧，提升表单设计能力。

Joni Trythall takes a detailed look at path data in SVG, breaking down the different parts of the code to make it more familiar and easier to work with.

性能测试是 SDK 发版的重要依据，VolcRTC 的业务方对于性能指标都比较重视，对于 RTC 准入有明确的准入标准。因此我们建立了线下的性能自动化测试系统，测试过程中我们发现 VolcRTC 的内存占用较高存在较大的优化空间。

随着云计算、大数据技术的日趋成熟，复杂多元、规模庞大的数据所蕴含的经济价值和社会价值逐步凸显，数据安全也是企业面临的巨大挑战，B站一直致力于对用户隐私数据的保护。本文将介绍B站基于Apache Ranger的大数据权限服务的技术演进之路。

视频内容类的业务对延迟比较敏感，现总结之前工作中的一些技术性探索和优化，分享给大家。

How Slack is bringing automation to bear to solve the problem of maintaining, modifying, and upgrading codebases.

In early 2020, we took a deeper look at this ecosystem. We discovered that a large percentage of the experiments had fatal problems and often needed to be rerun. Obtaining high-quality results required an expert-level understanding of experimentation and statistics, and an inordinate amount of toil (custom analysis, pipelining, etc.). This slowed down decision-making, and re-running poorly conducted experiments was common.

After assessing the customer problems and the internals of Morpheus we concluded that the core abstractions supported only a very narrow set of experiment designs correctly, and even minute deviations from such designs resulted in incomparable cohorts of users in control and treatment and compromised experiment results. To give a very simple example, while gradually rolling out an experiment that was split 30/70 between control and treatment, due to peculiarities of rollout and treatment assignment logic it would be ok to roll it out to 10% of users but not to 5%. Furthermore, the system was not able to support advanced experiment configurations needed to support Uber’s diverse use cases, or other advanced functionality at scale such as monitoring/rolling back experiments that were negatively impacting business metrics. So we decided to build a new platform from scratch with correct abstractions.

Shopify Inbox is a single business chat app that manages all Shopify merchants’ customer communications in one place, and turns chats into conversions. As we were building the product it was essential for us to understand how our merchants’ customers were using chat applications. Were they reaching out looking for product recommendations? Wondering if an item would ship to their destination? Or were they just saying hello? With this information we could help merchants prioritize responses that would convert into sales and guide our product team on what functionality to build next. However, with millions of unique messages exchanged in Shopify Inbox per month, this was going to be a challenging natural language processing (NLP) task.

Our team didn’t need to start from scratch, though: off-the-shelf NLP models are widely available to everyone. With this in mind, we decided to apply a newly popular machine learning process—the data-centric approach. We wanted to focus on fine-tuning these pre-trained models on our own data to yield the highest model accuracy, and deliver the best experience for our merchants.

We’ll share our journey of building a message classification model for Shopify Inbox by applying the data-centric approach. From defining our classification taxonomy to carefully training our annotators on labeling, we dive into how a data-centric approach, coupled with a state-of-the-art pre-trained model, led to a very accurate prediction service we’re now running in production.

The purpose of this article is to give insights into analyzing and predicting “out of memory” or OOM kills on the Netflix App. Unlike strong compute devices, TVs and set top boxes usually have stronger memory constraints. More importantly, the low resource availability or “out of memory” scenario is one of the common reasons for crashes/kills. We at Netflix, as a streaming service running on millions of devices, have a tremendous amount of data about device capabilities/characteristics and runtime data in our big data platform. With large data, comes the opportunity to leverage the data for predictive and classification based analysis. Specifically, if we are able to predict or analyze the Out of Memory kills, we can take device specific actions to pre-emptively lower the performance in favor of not crashing — aiming to give the user the ultimate Netflix Experience within the “performance vs pre-emptive action” tradeoff limitations. A major advantage of prediction and taking pre-emptive action, is the fact that we can take actions to better the user experience.

This is done by first elaborating on the dataset curation stage — specially focussing on device capabilities and OOM kill related memory readings. We also highlight steps and guidelines for exploratory analysis and prediction to understand Out of Memory kills on a sample set of devices. Since memory management is not something one usually associates with classification problems, this blog focuses on formulating the problem as an ML problem and the data engineering that goes along with it. We also explore graphical analysis of the labeled dataset and suggest some feature engineering and accuracy measures for future exploration.

Over the last couple of years, one feature emerged as our top user request: dark mode. Designers were tired of being assailed with a bright screen when working on Figma files late into the night, and studies have shown that people with visual impairments find dark mode more legible than light mode. (Visual contrasts are a core tenet of the W3C Accessibility Guidelines [WCAG] 3.0 standards, and we wanted to make sure our dark mode efforts satisfied those requirements.) That meant that delivering dark mode for us was more than just answering a user request—it mapped back to Figma’s core mission of making design accessible to all.

So, after months of toiling over the right approach, we shipped dark mode in May. Product Manager Jacob Miller and Product Designer Ryhan Hassan detailed the product and design challenges of implementing dark mode at Config 2022, our annual conference. Not only did dark mode surface thorny UI questions—which Jacob and Ryhan talked all about—it required a significant engineering lift. As they said in their talk, “One of the hardest things about dark mode is that people think it’s easy.”

转转的 CI 系统和开发环境为什么要从 npm 切换到 pnpm 呢。因为在使用 npm 的时候，遇到几个问题。

1. 磁盘空间占用过大
2. 首次安装速度慢
3. 幽灵依赖导致一些报错

那 pnpm 又是怎么解决上面的问题呢？

客户端应用中崩溃类型有多种，包括普通崩溃，主线程卡死，野指针崩溃，后台崩溃等等。当进程发生崩溃后系统会自动生成相应的崩溃信息，我们可以根据符号表解析崩溃日志，线上用户可以通过Bugly等第三方工具收集并解析堆栈。但是在解析的过程中大家可以发现解析一个崩溃日志操作非常繁琐，有时候出现解析失败的情况，甚至会解析错误。本文章主要介绍多个不同系统崩溃日志的解析方案。

新方案以业务链路为载体，通过有效组织业务每次执行的日志，实现了执行现场的可视化还原，支持问题的高效定位。

乐高系统是携程市场研发部开发的活动搭建平台，主要满足运营所需的各种营销、广告、频道、定制等页面的快速灵活搭建。平台在自身发展的过程中不断改进。刚开始着力于满足运营配置需求，满足业务需求，不断扩充和丰富组件库，目前平台已配置了10000+ 有效页面，同时在线页面达到1000+，组件类型300+。当体量达到一定程度后，我们又在思考，平台能力的边界在哪里，如何推动平台创造更大的价值？

这个时候，建设平台不再局限于扩展组件等基础建设，会更多地考虑如何将平台建设为一种“开放性”的平台，将平台优秀，成熟，可扩展的“点“开放出去，使平台或者平台相关技术在其他团队或者场景中有更多的应用，产生更大的价值。这种开放性的思路，也积极促进了平台的进一步发展。

这篇文章将总结我们在平台建设中一些相关思考和实现细节。

对于一个初上线的简单服务，只需通过常规的自动化测试加上人工即可解决，但我们线上核心的业务系统往往比较复杂，通常也会频繁的需求迭代，如何保证被修改后的系统原有业务的正确性就比较重要。常规的自动化测试需要投入大量的人力资源，准备测试数据、脚本等，并且覆盖率通常也不高，难以满足要求。

为了保证一个线上系统的稳定性，开发和测试人员都面临不少的挑战：

• 开发完成后难以快速本地验证，发现初步的问题，容易陷入提测->发现bug->fix->提测的循环
• 准备测试数据、自动化脚本编写和维护需要大量的人力成本，而且难以保证覆盖率
• 写服务难于验证，而且测试会产生脏数据，例如我们的核心交易系统，可能会往数据库、消息队列、Redis等写入数据，这部分数据往往比较难以验证，测试产生的数据也难于清理
• 线上问题难以本地复现，排查困难

本文将介绍 Shopee Games 团队自研的 API 网关，包括 API 网关如何进行泛化调用，自定义切面功能，稳定性保障，工程化实践等内容。

京东APP购物的黄金流程包括搜索、商品详情、购物车、结算、订单、支付等。支付是黄金流程重要的收尾环节，也是交易链路的最后一道防线。

老收银台在过去数年间，在多复杂类型、高交互需求的迭代下，出现代码腐化严重、初代架构设计难以支持现有业务的问题。对用户来说，业务接入老收银台流程复杂，难以支持个性化开发。H5版本收银台代码老旧，首次渲染（FCP）、首次可交互被大量资源加载所阻塞，性能江河日下，极大地影响用户体验。

为解决系统和用户层面的问题，进一步彰显技术赋能业务的价值，零售支付团队发起并设计高可用、高扩展、高性能的支付业务架构，即01支付平台。01支付平台融合统一支付服务层和一站式接入平台，致力于打造零售一站式支付内单收银台。统一支付服务层聚合主站支付能力并沉淀多端通用能力。通过领域设计、Paas化，统一支付服务层在沉淀收银台核心支付能力的基础上，具备native、H5、小程序等多业态支持能力。通过逻辑优化、代码去腐化等优化，使得统一支付服务层系统性能大幅度提升。前台支付的原生化提升页面加载速度，进一步优化用户体验。一站式接入平台使收银台的对接流程实现了线上化并提供数智化监控告警服务，成为业务方便捷、高效的接入渠道。

关于基础管理、市场、战略、创新、人单合一、创客平台、企业家精神等。