个人数据收集

个人数据收集和科学数据收集在一定程度上有所区别。个人数据收集通常较为不正式，而且不是发生在具备控制条件下的实验室里。人们收集现实世界中的数据，而在现实世界中，存在干扰、网络连接故障或者访问受限的计算机。用户不一定是数据专家，所以如果出了问题（这通常是不可避免的），他们可能不知道如何调整来解决问题。

因此，从用户角度，我们需要使得数据收集变得尽可能简单。它应该是无干扰的、直观的且易于访问的，这样数据收集才更有可能成为日常生活的一部分。

使数据收集成为日常生活

这是我选择Twitter作为YFD数据代理的主要原因，它可以通过电话或者计算机连到数据库。Twitter允许用户通过一些不同的渠道发布Twitter消息(teet)。用户可以通过移动电话发布Twitter消息，由于这一点，用户可以在任何地方通过电话发送SMS消息记录数据，这意味着人们可以随时记录实际情况，而不需要等到他们可以访问计算机时才开始记录。如果需要等待，人们很可能会忘记。因此，易于访问获取是很关键的。

人们可以通过E-mail而不是Twitter来完成一些相似的事情，因为很多手机允许人们给E-mail发送SMS，而这实际上正是YFD的最初实现方式。然而，我们回到数据收集作为日常生活的一个基本部分。成百上千万的人们已经在频繁地使用Twitter，由于这一点，其挑战性已经被部分削弱了。人们确实也在很频繁地使用E-mail，而且比起Twitter，人们也有可能更习惯于使用E-mail。但是这二者在本质上还是很有区别。在Twitter上，人们发布自己正在做的事，每天更新好多次信息。Twitter最初被创建也仅仅是因为这个原因。某个人可能正在吃三明治、出去散心或者在看电影。成千上万的人每天发布这类Twitter消息。而另一方面，E-mail本身就意味着其主要是一些更有价值的信息。绝大多数人不会给朋友发E-mail，告诉朋友他们正在看一个电视节目——尤其不会每天或者每个小时告诉朋友们这些事情。

通过利用Twitter得到的这种发布频率，我们期望它能够用于数据收集。我尝试着使得在YFD上记录数据和在Twitter上的感觉一样。举个例子，如果有个人吃意大利香肠的三明治，他发送了一条消息：“吃了意大利香肠三明治”(ae salami sandwich)。通过这种方式，数据收集就变成了交谈方式。用户不需要学习像SQL一样新的语言。相反地，他们只需要记住关键字及其对应值。在前一个例子中，关键字是“ate”，值是“salami sandwich”。为了跟踪睡眠，用户简单地发送一个关键字：睡觉时是“goodnight”，醒来时是“gmorning”。

在某些方面，用PEIR频繁发布信息的挑战要比在YFD上小一些。因为PEIR是在后台自动收集数据，用户只需要通过点击几下按钮，就可以启动其手机上的软件。开发那种软件本身存在一定的困难，但那就是另一回事了。

异步数据收集

对于PEIR和YFD，我们发现异步数据收集实际上是必要的。当人们遇到一些感兴趣的事情发生后，他们会希望输入和上传数据。在YFD，人们希望能够给他们的Twitter消息增加时间戳，而PEIR用户想要手工上传GPS数据。

正如之前所述，创建YFD的初始想法是人们在遇到一些事情时，会希望输入数据来记录它们。这是使用Twitter的好处和目的。然而，很多人没有通过手机使用Twitter，因此他们需要等到可以用电脑时才登录Twitter。即使是那些确实给Twitter发送SMS消息的用户通常也会忘记记录数据；有些人只是想在每天结束前输入所有的数据。

不用说，YFD现在支持时间戳。数据入口的语义尽可能地贴近交谈仍然很重要。为了实现这个目标，用户可以给他们的Twitter消息添加时间戳，比如“早上6点吃烤鸡和土豆”(ae roast chicken and potatoes at 6：00pm)或者“晚上11点晚安”(godnight at 23：00）。时间戳语义上只是简单地在Twitter消息的最后添加一个“at hh:mm”。我还发现同时支持标准格式和军事格式的时间戳是有用的。最后，当用户输入一个时间戳，YFD将会记录该时间的最近出现频度，因此在先前的“goodnight”例子中，YFD会输入昨天晚上的时间点。

PEIR的初始设计也只是为了“当时”(i the moment)的数据收集。正如前述，Campaignr运行在用户的手机上，周期性把GPS数据（每20分钟上传一次）上传到中心服务器。这对一个每天运行PEIR的用户来说，他本身只需要很少的付出，就可以收集成千上万的数据点。一旦在手机上安装PEIR应用，用户只是简单地按动几下按钮就可以启动应用。然而，几乎从一开始，我们就发现不能依赖100%可达的网络连接，因为几乎总有地区是服务无法覆盖的。最简单虽然也是最幼稚的做法是只有当手机可以上网时才收集和上传数据。这种做法的代价是我们可能会失去大量的数据。相反地，我们通过缓存把数据存储在手机的本地内存，直到手机可以重新连上网络。我们还提供了另一个方案来收集数据，而不需要同步上传这些数据。

这种做法的一个不足之处在于，期望人们在事件发生时收集数据是不合理的。人们会忘记收集数据或者在当时不方便收集数据。在以上任何情况下，提供用户在后期也能够输入数据的功能是很重要的，这一点又反过来影响了数据流的下一步设计。