bookhub

工具还在开发中，client-PC 目录下是 active 的代码。

• UI Design Preview
• Release Plan

调查问卷 https://jinshuju.net/f/3wSWpy

调查的结果，以邮件的方式 share 给填写了邮箱的有效回答。昵称／邮箱／微信／坐标不会 share。

日常痛点

1. 花了那么多时间整理电子书，找书的时候依旧一脸懵。

信息大爆炸的时代，最好的交互工具就是“搜索引擎“

• 互联网上的 Google
• Mac 上的 SpotLight
• Windows 下的 Everything(软件名)

能不能做一个软件，不需要太多时间整理书，但找书的时候，搜一下就够了。

随着使用时间的增加，搜索可以越来越 AI 智能(障）

2. 电子书管理工具和笔记管理，一直是两条平行线, 为什么？

或许，开发成本／技术栈是个主要原因。

现在，我们有 electron 了，无所不能的 node.js 什么都可以写。

3. Calibre 可以根据文件信息自动从豆瓣等网站匹配作者、出版社等信息

如果有一个云端，就可以把电子书文件及其匹配结果共享出来，不用每个人重复做一遍了。

4. 电子书管理和文献管理之间的距离，很近，又很远。

文献管理，只考虑怎么能简单的生成参考文献。

电子书管理，似乎从不在乎科研群体。

一个好的阅读工具，是可以做图书推荐的。

举个例子：

最近读 <机器学习高手攻略>, 看不懂。

A 读过，很喜欢。B 读过，也很喜欢。他们在读这本书以前，都读了《机器学习入门》。

那么，我们可以认为，我应该先读一读这本书。

A 和 B 之后又都读过 《颈椎病指南》，我看懂这本书之前，不要给我推荐，看不懂的。

从图书推荐到知识地图

做图书推荐的时候，阅读顺序是很重要的。

这其实已经有知识地图的概念了，

豆瓣也有这些数据，但那个标记一本书的成本太低，装 X 的因素也很重。

标记自己全部阅读记录的成本又太高，

无法做到基于阅读顺序的推荐。

电子书工具，可以获取用户完整的阅读记录，甚至打开一本书的时间和频率。

数据更真实，推荐更靠谱。

技术栈

PC Client

Electron + React + Redux

Data Platform

Python