Conception d'un digest d'espace de connaissances

Conception d'un digest d'espace de connaissances

Knowledge Workspace Digest Design est un exemple officiel OpenDesign de document de digest matinal de type Notion. Son titre original, « 📒 Notion · 昨日 3 条与你相关 », présente l'artefact comme une revue personnelle des activités pertinentes de la veille plutôt que comme une vue générale de l'espace de travail.

La page commence par « Open Orbit / 早安简报 / 5 月 6 日 », puis introduit « 2026-05-06 早安，Eli · 由 Open Orbit 自动生成 ». Cette séquence établit la source, le type de document, la date, le destinataire et le générateur déclaré avant l'activité elle-même. Les éléments visuels attestent d'un document conçu et d'un contenu d'exemple ; ils n'établissent ni une connexion Notion active ni une automatisation en production.

L'encadré clair indique que le digest ne contient que des modifications du connecteur Notion, avec trois notifications et une mention. Les sections suivantes montrent pourtant deux entrées de documents, deux entrées de commentaires ou de mentions et deux lignes de base de données. L'exemple ne réconcilie pas ces nombres et ne précise pas si plusieurs entrées correspondent à une seule notification ; les totaux d'ouverture sont illustratifs et ne résultent pas d'une règle d'agrégation vérifiée.

Cas d'usage pour la revue quotidienne

Le digest est organisé pour un passage rapide le matin. « 📝 文档变更 » liste les documents modifiés ou nouvellement créés, « 💬 评论 / @ 提及 » isole les demandes conversationnelles et « 🗄️ 数据库变更 » présente les mises à jour structurées des projets. Cet ordre va des changements de contenu aux éléments d'attention personnelle, puis aux informations d'état plus larges.

Les entrées de documents combinent un titre, une personne, une action et une heure. « 《Q3 OKR》 Marie 编辑了 2 段 · 22:14 » distingue une modification de « 《Onboarding 文档》 Bob 新建 · 19:08 », de sorte que le lecteur peut déduire s'il doit examiner un contenu modifié ou une page nouvellement créée. Le compromis est la concision : le rapport donne un indice d'activité utile sans montrer les passages modifiés.

La section des mentions rend la pertinence personnelle plus explicite. « 团队周报 Lily 在「设计进度」段落 @你 · 16:30 » identifie à la fois le contexte et l'emplacement de la mention, tandis que le commentaire de Bob, « 这一段需要你确认 », formule directement une demande. Ces entrées facilitent le tri, mais l'exemple ne définit ni priorité, ni échéance, ni si une réponse a déjà été donnée.

Composition et regroupement des données

Le CSS fourni définit « .page-content { max-width: 900px } », et les captures montrent une colonne de lecture blanche sobre avec des séparateurs horizontaux entre les sections. Une bande brun foncé à motif surmonte le corps du document, tandis que le contenu principal utilise de grands titres noirs et des métadonnées grises atténuées. Ce contraste donne au rapport une identité de document sans que la liste d'activités concurrence le titre.

Le bloc de base de données contient un panneau « 项目追踪 » avec des colonnes pour le nom, l'état, l'auteur de la mise à jour et l'heure. Ses deux lignes d'exemple associent le suivi de conception Login v2 à In Progress, Marie et 21:00, et la documentation API v2 à Done, Bob et 17:45. Ces noms identifient l'auteur de la mise à jour, non le responsable d'une tâche. Les couleurs d'état facilitent la comparaison sans définir le flux de travail ni les critères d'achèvement.

Les liens des titres de documents et les clics sur les lignes de base de données construisent localement des URL Notion à partir des titres visibles, avec un préfixe d'espace de travail fixe plutôt que des identifiants de page vérifiés. Leurs destinations externes n'ont pas été testées. Le contrôle final des changements bruts est différent : l'élément natif details ouvre une courte note qui mentionne cinq événements d'API, mais ne contient aucun journal d'événements complet. Le design illustre donc des affordances de navigation et un affichage local dépliable, non un service connecté d'historique des modifications.

Du récit au tableau

Les deux premiers groupes utilisent des phrases à puces lisibles, car les modifications et les commentaires ont besoin de contexte. Le groupe de la base de données utilise des champs alignés, car la comparaison compte plus que la prose. Remplacer le tableau par une autre liste à puces rendrait les deux états de projet plus difficiles à comparer d'un coup d'œil.

Périmètre et limites des capacités

Cet artefact est un exemple graphique purement conceptuel, avec des noms, dates, nombres, contenus de documents et lignes de base de données illustratifs. Les captures montrent la structure visuelle visée et des détails de présentation locaux. Elles ne vérifient ni une intégration Notion fonctionnelle, ni des services connectés, ni un stockage persistant, ni de vraies notifications, ni l'exactitude des enregistrements représentés.

Pour l'adapter, conservez la distinction entre le design observé et le comportement proposé. Une nouvelle implémentation pourrait remplacer les lignes d'exemple par des données sources confirmées, mais elle nécessiterait des règles définies séparément pour le décompte des notifications, la détection des mentions, la signification des états, les permissions et les liens vers les enregistrements d'origine. La référence fournit l'architecture de l'information et le traitement visuel, non ces contrats back-end.