TimeTrack开发备忘(2008-06-08 23:23:41)本文不断更新中…… 这个文档只描述对各个功能需求的考虑，具体的实现办法在别的博文中解释，这里给出相应链接。 （01）TimeTrack可以搜集、跟踪用户时间的使用情况，为用户合理使用、规划时间提供数据支持。 （02）首先要能够通过简单的双击，记录某个事情（job）的开始和截止时间，并自动给出该job的时间开销timeCost。timeCost=endTime-beginTime。具体实现在这里。 （03）活动activity和业务business的概念。活动是统计时间开销的单元，做同一类事情用的时间应该差不多，这种数据搜集得足够多了，有助于制定比较切实可行的时间安排计划；业务是指生活中一件完整的事，比如开发时间记录数据库这个业务，可能涉及多类活动。通过统计在某类业务上所耗费的时间，可以知道自己在生活中时间用的怎样、是否妥当、是否在某件事上花的时间太多了。 （04）business应该有个单独的表。这样在为每个job指定它所属的business的时候，只要从列表中选择就行了，不需要反复录入。具体实现在这里。 （05）类似的，activity也应该有个单独的表。不过，与business不同的是，activiy的录入可能需要树形结构的支持。因为同一时期忙活的业务也无非就那么几件，而要统计的活动（需要了解时间开销的事情单元）则很多，只提供一个没有层次结构的长长列表，在录入时要定位到想要的那一种活动会比较麻烦。因此在录入activity的时候，可能需要先指定它所属的大的活动类别、然后再指定其下再细分的类别、层层递进。 （06）job也应该有个单独的表，在那里指出这个事情属于哪类活动、属于哪个大业务。因为同一件事，比如煮杂粮粥，可能反复地做，每次都要重新输入属于哪类活动、属于哪个大业务，有点烦。 （07）有了job表之后，记录job的开始截止时间时，需要先录入jobId。有两种办法：对于已有job直接选jobID，对于新job则先在job表里录入一个新job，然后再选jobId。因为事情很多，选jobID时可能很麻烦，所以可能需要有个树形结构来方便录入，先选大活动分类、再选小活动分类、最后具体到位于叶子结点处的job。 （08）总结05－06的需求，在录入新activity和job时用统一的级联窗体，具体实现在这里；在指定jobID的时候也调用这个级联窗体，具体实现在这里。注意：同一job必定有同样的activity属性，但可能有不同的businessID，这个businessID在timeRecord表指定。比如“下载资料”这个job都属于上网activity，但可能属于饮食business（下载菜谱）、也可能属于健身business（下载健身视频）。 （09）列表行数不够问题以及新记录在列表里不出现问题，具体实现在这里。 （10）手动补记时间的问题。开始一个job的时候没记这个信息，这个job做完后想起应该记上一笔，于是这个job只有结束时间没有开始时间，这时系统应该自动用上一条记录的结束时间作为当前记录的开始时间。取得当前记录的前一条记录的方法在这里。 （12）待完善：为时间规划提供支持。初步的想法是：系统自动给出新拟定的事件的估计时间，然后在outlook或project的甘特图上手工利用这些信息（待实现）。对时间估计的基本想法是：如果同类job有timecost记录的多于两条，就用它们的平均值；否则就用其所属activity下的所有timecost记录的平均值。具体实现在这里。 （13）待完善：需要图形化显示时间的使用统计。系统应能自动生成一个饼形图或柱状图，该图可以指定统计的时间区间（一天、一周、一月、一年）和统计的分类标准（事务、活动类别或者活动单位）。比如，可以看到一整天是怎么过的，浪费的时间占几成、饮食的时间占几成等。 （14）待解决：时间拆分和job接续的问题。 （15）待解决：为“按点儿来”习惯提供统计服务，功能设计在这里和这里。 （18）待解决：补充TimePanic里一些好的设计，初步设计见这里。 （19）待解决：对方便录入的支持：在录入做饭这类事情的时候，能灵活选取元素，如：带银耳、洗锅、洗碗、葡萄等等；另外businessid和jid能按最常使用的倒序排列。 |
|
|
转载▼
