iDoulist 演示 v0.1

Outline

• 简述
• 背景
• 产品
• 开发历程
• 感想

简述

时光倒回到一个月前的4月28日.

[原型Figure]

一个月之后, 我们的成果是:

[产品视频]

背景

随着信息流通速度不断加快, 信息输入速度已经远远超出我们所能接收的速度----信息过载时代已经来临.
那么, 新时代的我们要面对一个以前并不存在的问题: 如何从茫茫信息汪洋之中选择信息?

寻找信息汪洋之中的灯塔
在开智群不断开光之下, 我们逐渐发现一个朴素的答案: 信任"人". 茫茫书海之中, 寻找那些我们信任的人推荐的资源, 是提高输入信噪比的一条航线.
而豆瓣, 豆列, 则是航行途中指点方向的灯塔, 拥有更高的信噪比.

[豆列实例图1-2]

(niubility 通过大牛来作为索引, iDoulist 借助豆列, 更多给出的是基于专题的学习模式)

但是, 当我们想高效利用豆列功能时, 发现了诸多不尽人意之处..

[尴尬图1-2]

我们知道, 程序最大的优点就是可以无限耐心地进行重复性劳动
为了更好利用豆列资源, 减少重复劳动
有了 iDoulist

产品

功能1: 寻找主题----输出豆列标签云 [暗号豆列]

功能2: 不同资源的评估与对比整理---- [合并书单精选] [书单我没看过哪些?]

功能n: fork 到豆瓣
有了输入当然好, 但最好还有输出? 这样小伙伴们才方便互相比较学习路径呀 [实例] ....

具体功能简短演示?

开发历程

[脑图]

信息流: 豆瓣输入-列表/处理-输出(命令行,文件,豆列,标签云)

技术困难: 除了常识, 没有其它资源了
不确定情况下的学习, 你甚至不知道应该学什么

我们如何解决这个问题:
敏捷开发实践-开发时序图

• 构建基本功能
• 不断更新添加功能

应用的主要模块 python: urllib/re/tk PyAutoGUI word_cloud

敏捷开发实践

弯路

• 没有 MVP 根本无法开发, 迅速写 MVP
• 沟通: 面基信息量才最大
• 技术门槛: 自信与耐心(MVP first-至少总有产品可以交付/最坏选择保底)

否定: 用户的交互需求, 本地开发的优缺点

• 调试测试飞快, 开发门槛低
• 但最终产品使用难度大, 使用门槛高

(缘起

• 为了输出豆列, 但无 api, 故选择此策略
• 也有项目规模考量. 目前 2000 行)

小结

• 为什么要用我们: 针对一个具体需求----以信任为基础, 围绕豆列(高信噪比资源索引)的主题学习
• 为什么要投我们:
• 一起加入: 测试/运行框架已经有了, 还有什么具体需求, 只需要 fork and develop :)
  • 开发门槛最低
  • 计划中的开发内容