M2 Planning Day3

今天中午的时候有和邹欣老师的Lunch Discussion，讨论了很多东西，有很多收获。

首先确定的是page cluster之类的事情是不需要做了，而之前相对比较纠结的就是这一点，是否要做cluster，如何cluster是很蛋疼的问题。讨论的过程中我们注意到其实M2的重点也可以不是这里，虽然将网页聚类并产生新的keywords是非常激动人心的事情，但我们毕竟不是在做research，对于grow search而言，更多的可能还是要考虑用户可能会需要什么。

晚上的讨论里我们又将中午的内容稍微总结了一下，基本上清楚M2我们要做的东西：

1 对于长得过于茂盛的树，我们决定将比较旧的结果周期性地聚为一个叶节点，当然这个叶节点不同于普通的叶节点，当在上面点击的时候应该可以得到被收入内容的枝条。这样做的好处是树本身不会过于“繁茂”而且被收缩的节点会使得树本身有着更深的层次，而非现在的a tree of depth 2。至于何时进行收缩现在有集中想法：按照时间，譬如每一小时收缩一次；按照节点个数，譬如每100个节点收缩一次。但无论如何将收缩功能实现和收缩的criteria无关，但是对于如何“优雅地”收缩枝条，大概是一个需要很多尝试的有难度的事情。

2 应当允许用户剪掉枝条。树长得过于茂盛的时候如果用户可以修剪，好像修剪现实生活中的树那样的话，应该是很有趣的事情。至于修剪的方法当然可以是像割绳子游戏里那样用鼠标划一下就刷刷剪掉，不过我们暂时也还没想要做到那样，点击枝条能删除这样的程度就可以了吧。

3 多棵树。之前我们本来打算放弃多棵树的，但是中午的时候听邹老师提到了“花园”之类的东西，又开始觉得加入多棵树的话也许也不错，而且既然现在既然丢掉了网页聚类的设想，那么实际上一棵树并非会变成一个knowledge graph，换句话讲不会非常地占据空间，所以多棵树还是有必要的，不然只有一棵树未免单调。

4 关于数据来源，之前一直使用的是BingAPI获取的数据进行按时间的排序后再进行显示。但是这样的问题是按照时间排序后会丢失掉原本search engine对结果的排序，而对于搜索新闻的用户而言想要的还是rank最高的排序。之后我们打算使用的数据是BingNews的RSS订阅，今天惊喜地发现自己的关键词也可以使用RSS订阅了，但是因为在最下面所以昨天没有发现，以为只能按类别去订阅。使用RSS订阅的好处是内容会比较make sense。但愿。。。

虽然对于要做的东西有了一些初步的想法，但是仔细看看哪一个都绝非能够轻易实现的东西，所以今天之后队员们都去各自探索各自的内容，看看需要做的东西我们能不能做到，看看我们能做到哪里，再确定具体的计划。

以上。