2004年12月28日 星期二
感谢eros_chan 提供翻译
Based on recommendations from top Macromedia Flashdesigners, developers, and usability experts we've collected the top ten tipsfor creating usable Macromedia Flash sites.
基于从MACROMEDIA的顶级FLASH设计专家，开发者和可用性专家的建议，我们收集整理了创建可用的FLASH站点的十条提示。
These tips are just a start and we will continue to providemore usability research, studies and articles.
这写小提示只是一个开始，我们将继续提供更多的可用性调查，研究和文章。
查看全文 »
2004年12月27日 星期一
在老布的blog上看见一个好文章 转了过来，以作保存 (老布的blog地址：http://blog.9zi.com)
1：阐述做这个事情的需求，必要性
2：描述现有解决此类需求的方法，以及有缺点
3：需要优化或者解决的问题（减轻做什么事情的负担，提高那方面效率，使用上什么工具，从哪里解放出来）
4：描述理想方法，简单原理（计算机、软硬件），优点,以及避免缺点的手段：例如：异常处理（自动处理出错的情况下），可以支持传统手法（作为补充），兼容旧模式，防止计算机系统出故障造成日常工作不正常。(导入导出)。把后顾之忧解决方法清清楚楚的展现给用户。
5：推出软硬件解决方案，架构方案，组成结构。
7：时间进度表，项目关键人员基本情况，（项目招标中需要的）
6：报价，成本预算。
这是从日本人一个小软件产品ＰＰＴ上总结过来的，简单几个Page就把软件的意义解释清楚了。
查看全文 »
2004年12月09日 星期四
用户研究：
http://uicom.net/ui00/ui01.htm
=======================
眼动测试 查看全文 »
2004年12月09日 星期四
作者：windy
http://www.dedream.com/research/archives/2004/09/aeaeeeaec.html
一个交互实例
vivi（薇薇，26岁，一位优雅迷人的OL）打开钱包，从卡夹层里拿出那张有着金黄葵花的银行卡，又了到发工资的时候，不知道今天到帐了没有，还约好了明天和死党一起Shopping呢！刚才路过银行想查一下余额，但是排队的人太多了，不过还有电话银行嘛，vivi一边想，一边拿出手机，拨通了电话银行的号码：
一个温柔礼貌的MM语音提示：“您好，欢迎使用招商银行电话银行系统，1，自动语音服务，2人工服务；”
vivi把手机从耳边拿下来，找到1号键，按了一下； 查看全文 »
2004年12月07日 星期二
有时候，公司管理不规范、运作混乱自有好处，在特定的阶段里，只有残缺才是美。
作为个体的集合，组织就如一个大树林，不同的鸟儿聚在其中，构成了一个复杂的生态环境。面对于此，有效管理决不是一个单纯过程，它应当具有针对性、包容性和灵活性，否则，管理就丧失了它的本质意义。
水至清则无鱼
有一个故事：在日本的一家动物园，有位饲养员特别爱干净，对动物也特别有爱心，每天都把小动物住的小屋打扫得干干净净。结果呢，那些小动物一点也不领他的情，在干净舒适的环境里，动物们开始慢慢萎靡不振了，有的厌食消瘦，有的生病拒食，有的甚至死了。原因是什么？后来，通过观察才发现，那些动物都有自己的生活习性，有的喜欢闻到那混浊的骚气，有的看到自己的粪便反而感到安全等等。这个故事就说明了一个道理，有效的管理必须针对组织内个体的需求，包容个体的差异性，并在此基础上灵活应对、多元管理。假如像故事中的饲养员那样，无视个体的差异，一味求看似完美的统一，这样的组织最终一定会因抹杀了个体的个性而导致组织的解体或僵死。 查看全文 »
2004年12月07日 星期二
本文来自yesky
2004-01-08
成功的软件产品是建立在成功的需求基础之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。
需求获取可能是软件开发中最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。
其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知 查看全文 »
2004年12月07日 星期二
转载，出处不详。
.
如果将需求分析阶段的工作归结为编写需求规格说明书，这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首。建议采用以下步骤形成软件需求：获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求。下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）的做法。
获取用户需求
这是该阶段的一个最重要的任务。以下为获取用户需求需要执行的活动（如图1所示）。
● 了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。
● 对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。
查看全文 »