@
chrox 问题:
2: 点击删除会收起摘录卡片,删除按钮并不生效。
5:
大概找了下相关的讨论,页码获取似乎比较困难。
我是参考了 android 的掌阅、多看,它们的页码是准确的,但是文件比较大的时候会显示 "分页中"。这时候应该是后台还没算出总页数和当前页码。我也没有实际做过这些功能,所以无法评估真正的复杂度。
也有些阅读器是用百分比进度,但是感觉没有页码好。
建议:
2: txt 主要是因为不想再手动编成 epub 。不支持也问题不大,就是用户得花时间。
6:
这个类似 2 ,主要就是因为改 epub 要花点时间。懒得改的时候直接设置阅读器配置会比较方便。
具体配置可以参考其他竞品,字体的相关配置主要包括:字体、字号、字重、字间距、行间距、段间距、首行缩进。布局就是页边距之类的了,当前其实已经可以了。
而且个人认为比较重要的就是支持相关的开关,用户能够自己选择强制覆盖原书样式还是保留原书样式。原书排版完美,就关掉配置,像 pdf 一样直接原样显示。排版有问题再开启。像多看和掌阅强制首行缩进我就比较反感,把排版都搞乱了。
5:
放在 6 后面是因为自定义 css 其实完全能实现 6 的功能,而且更强大。只不过不够傻瓜式,不适合非专业用户。不太清除作者做这个功能的出发点是什么,我觉得这个功能很棒,已经有插件的味道了。而且要做得彻底一点的话,建议把应用范围扩大到除侧边栏和工具栏之外的整个界面,当前好像只能设置书内容区域很小一块。
更高阶的形态应该是类似 foobar2000 ,给用户完全的权力,爱怎么改怎么改,当然这太过不切实际了,略过。
总体看下来,个人感觉当前的产品形态是一个应用场景局限在平板、pc 上的阅读器,移动端还不太行。两个路径:
1.专注做阅读器,这时候不需要考虑 7 图书管理,也不用考虑多端同步,只需要把移动端搞好就行了。但说实话这样的产品没太大用,用户为了方便大概率不会去用。
2.maganer+ reader ,整条链路打通,把图书功能包圆。这是最理想的了,但是也是最花资源的。如果做到了就我个人而言完全能接受付费。