用户名:
  密    码:
  验证码:
看不清?点击这里换一个
  注    册
  忘记密码   修改密码
首页
知名架构师博客中心
微软架构师网络广播
在线架构技术教程
架构师技术阅读
经典.NET架构启蒙
Architect Journal
国内成功案例
国外成功案例
历史活动
  .NET架构师论坛
  微软活动资讯
当前活动
会员登陆
立即注册
个人信息
会员推荐
RSS 源   Ron Jacobs
投递时间 2007年10月17日星期三 0:23
作       者 ronjacobs
主       题 可见性+可支持性+一致性 == 强大的用户体验?
整篇文章链接:http://blogs.msdn.com/rjacobs/archive/2007/10/16/visibility-supportability-consistency-great-ux.aspx
       在我最近的两篇文章当中,对于可见性可支持性作为架构的工具进行了深入的研究。这些都是架构师们在以用户为中心进行设计的时候必须要注意的问题,正如Frank Lloyd Wright 所说的那样,一套系统的设计应该首先考虑的是用户。一定不能忘记我们人是主导,我们是主人,机器的存在只是为我们服务的。直到老天爷宣布末日到来的那一天都是如此,呵呵,我有点儿跑题了……
       一部分看过我之前文章的人反应, 在微软近期发布的产品当中,Office Communicator 只是唯一的一个就连寻找菜单都很费劲的软件。我们马上来看一组例子……
Windows Media Player 11
       你以前应该见过这个用户界面了。现在假设你的工作是教会你的奶奶用Windows Media Player 11打开一个mp3文件。很简单,只需要在菜单中点击 “文件”,“打开”,对吗?Oh,等一下……没有菜单?有吗??事实上如果你按下Alt+F 键,文件菜单才会出现。然而,如果你并不熟悉Alt 键,你就看不到菜单。
       有什么解决方案?尝试右键点击窗口上部的黑色区域。
       不行……不是Window 标题栏区域(如果你开启Aero 功能的话,这里有可能不是黑色,而是半透明效果)
       不行……是那个叫"正在播放"的按钮吗?对,就是他。
       什么?你说当你点击那个按钮以后没有找到“文件”选项?
       哦……嗯……你只能找到黑色区域上的一块没有诸如“正在播放”或者“媒体库”这些文字提示的一个小点。如果你右键点击这个小点,你将会看到一个带有这些文字的一个特殊菜单,当然如果你左键点击看到的效果是一样的 (方便那些不能区分左右的人使用)。
那么我右键点击什么地方才可以看到真正的菜单呢?
       由于没有明显的视觉提示,所以在上图中,我把自己能够找到的、右键点击以后能够显示出菜单的区域,都做了阴影处理。你会注意到这些点击以后可以显示菜单的区域要比不能显示菜单的区域小得多。而且即使你右键点击距离“Rip” 按钮很远的地方,同样可以打开"Rip" 菜单。
我们为什么要让这种情况出现?
       我们渴望拥有一个很酷很干净的设计界面 ,遗憾的是,我们忘记了古老的座右铭:“形式服从功能”。如果Windows Media Player 11是你能够自由使用的第一款应用程序也就罢了,但事实上应用程序已经在Windows 平台上盛行了将近20年。在Windows3.0发布初期,也曾经发生过类似的混乱状况。菜单,工具栏以及其他的用户界面小工具的位置都是不可预知的,而且没有统一的模型来说明Windows 应用程序应该是什么样子的。
重新强调概念模型
       在90年代中期(我记不清具体时间了) ,关于Windows 应用程序的样式指南出现了。这个样式随着Windows 版本的更新 也会相应的做出一些微小的改动。这份样式指南明确了"Window" 应该如何工作以及菜单应该如何组织,我们将这个概念模型的理念在全世界范围内进行传播
       "心智模式,也就是我们的概念模型中组件工作、事件发生或者人的行为举止的方法,是根据我们依照发展趋势定义出的模型而产生的。这些模型对于我们理解体验,预测行动的结果以及处理意外事件来说是必不可少的。这个模型基于我们所了解的所有知识——无论是真实的还是虚构的,幼稚的还是老练的。
"The Design of Everyday Things" 第38页 - Donald A. Norman
       从你第一次点击 Windows 应用程序那一天起,你就开始对这些应用程序如何工作形成了一个概念模型,你就知道如果想打开一个文档,一个媒体文件或者其他你想打开的东西,只需要点击“文件”菜单。也许这并不是最好的模型,但这个模型是你最熟悉的。当下一个新版本的应用程序出来的时候,你不需要改变脑海中的概念模型,因为他们本质上都是一样的。这种概念模型让世界变得 可预知,也让你感到很舒服。
       但是现在为了追求一些养眼的效果我们却打破了这种长期以来认真建立并且不断补充的模型。
如果人们不能够成功的预知软件使用的步骤,那么还有谁会关心你所设计的界面有多酷?
       我知道有些人在说……有必要这么认真吗?让我来说明一下。是这样,但你作为一个软件专家,你的一些好奇的天性会导致你不停的去尝试理解一些东西直到你最终达到目的。但另一方面,大多数人对这种事情没有耐心,并很快会厌烦去猜测一个软件的工作方式。他们也许会使用Windows Media Player 11,因为他们没有其他的媒体播放器。但一些聪明的家伙会在这个时候抢占你的市场份额,因为他们知道让设备或者用户界面遵循用户喜欢的方式意味着什么。
       我确信开发Windows Media Player 11的工程师是杰出的。我敢打赌在处理多媒体文件以及实现很酷的音乐方面,Windows Media Player 11都是非常棒的。 但是如果这些功能都因为几个菜单的设计失败而变得暗淡,将会是一件多么遗憾的事情……
停止你的抱怨...
       OK,已经抱怨够了,现在的问题是,我们如何避免这种错误发生?
       答案就是改变我们思考问题的方法。我们需要用一种用户导向的、基于任务的方式来进行思考。 我的建议是你最好能先将你所关注的任务列出来 。我相信你的应用程序可以让用户完成上百种功能,但是我们没有那么多的时间以及资源去认真考虑所有的功能。你需要做的是确定最重要的5到10个功能,并一一解决他们。
       Windows Media Player 主要做什么?
  1. 从文件或者网络中播放媒体流(音频/视频)
  2. 管理媒体库
  3. 共享媒体库
  4. 其他
       你需要一个应用程序必须要实现的功能的优先级列表,一旦你有了这个列表,就会很清楚自己该去关注什么地方。现在就从最重要的功能开始, 将每一步进行分解,并最终让用户可以在特定场景中实现该功能。例如,你可以采取不同的方法来播放一个音乐文件,通过媒体库,右键菜单,流媒体URL 地址等等。既然这样,也不妨考虑一下在Windows Media Player 中使用菜单功能。
场景:用户通过Windows Media Player 11从“我的音乐”文件夹中打开文件
  1. 用户通过右键点击当前窗口的某个特殊区域来打开菜单
  2. 用户通过选择“文件”/“打开”的方式来打开一个文件
       稍等一下……
  • 第一步的时候你有没有注意到什么?
  • 用户能够成功完成这一步的机率是多少?
  • 这个神秘的“特殊区域”在什么地方有没有视觉线索提示我们?
       我们如何来评估这种设计?其实很容易,只需要尝试一些简单的可用性测试。
       Seek.com.au 网站的Mia Northrop曾经告诉我他们如何来设计文章的原型。
       如果你要在一张纸上打印一个用户界面的截图,并且让10个人用铅笔指出他们将如何通过鼠标来显示菜单。不要告诉他们需要进行右键点击还是左键点击,只让他们用铅笔指出要点击的地方,并说出“右键点击”,“左键点击”或者“双击”。
       能够成功完成这项测试的用户比例有多少?我猜测如果给用户界面按照字母来评级的话,单在这一项上Windows Media Player 11 只等获得“F”。如果一个软件的用户界面设计在最重要的5项功能当中,用户认为只取得了不足70%的成功,那么我是不会继续使用这款软件的。
为蠢人设计的用户界面
       我知道,就是那些愚蠢的用户。确实有一个叫做学习曲线图的东西,但是用户能够克服他吗?不能!他们会选择容忍你的产品直到他们实在无法忍受或者找到了更好的产品。与此同时,他们并不会喜欢你的产品并告诉身边的人你的产品有多么的酷,而会默默的痛恨你的产品,因为你的产品让他们感觉到很愚蠢 。
       你如何才能知道用户对你的用户界面设计方案将会如何评价?尝试先界面设计方案在用户当中测试一下效果,这样我们就可以做到未雨绸缪。
>> 查看文章
RSS 源   Ron Jacobs
投递时间 2007年10月3日星期三 0:21
作       者 ronjacobs
主       题 可支持性 – 把握住“重点”
整篇文章链接:http://blogs.msdn.com/rjacobs/archive/2007/10/02/supportability-keeping-the-main-thing-the-main-thing.aspx
       您的应用程序的主要功能是什么?
       您的应用程序是为谁编写的(客户)?
       可支持性作为软件的一个重要特性,可以确保您的客户使用该软件完成重要任务。当然您的应用程序可以做很多事情,但是您必须清楚最重要的任务是什么。
       OK,明白了吗?现在问问你自己这些问题:
  • 在这个场景当中最容易出现错误的地方是什么?
  • 有没有方法可以让我们防止出现这种错误?
  • 我们如何发觉错误何时发生?
  • 我们按照什么步骤来指导用户修复错误?
  • 我们的技术支持人员如何远程诊断并修复发生的问题?
       以Office Communicator 2007为例。该软件最主要的功能就是让用户之间可以通过聊天、视频等方式互相交流。通过文字方式聊天很容易实现也很易于相互之间的理解,但是通过语音以及视频聊天则对于软件的可支持性提出了很大的挑战,因为这需要额外的硬件来支持。今天在这里我将会对Office Communicator 和Skype 这两款软件所能够提供的可支持性进行对比。毫无意外,Skype 在这方面要做的更好一些,因为这关系到该公司的生存问题 。数百万的用户免费下载并使用Skype,他们有权利获得软件的支持性。
       当用户希望进行语音聊天的时候,让我们考虑一下这种场景下有可能发生的一些问题
       Q: 最有可能出现什么问题?
       A: 不能听到对方说话或者对方不能听到自己说话
       Q: 有什么方法可以帮助我们预防这种问题的出现吗?
       A: 有 – 例如像Skype 呼叫测试服务这种可以预先进行语音测试的功能。这个服务可以让用户呼叫一个已知的自动化语音系统,并将通过将语音录制、回放来对设置进行全面的检查。这样就可以保证音频I/O 以及网络连接在功能性上没有问题。
       我如何知道这个全面检查正在工作?
       Skype 支持着数以百万的用户,即便是他们当中的一小部分遇到了语音失败的问题并且联系技术支持部门,这种成本也是难以让人接受的。Skype 构建了一个呼叫测试服务,这样就可以让用户首先了解他们的网络连接是否工作正常。每次我在新电脑上安装Skype 的时候都会怀疑我的第一次呼叫能否成功,比如麦克风是否工作正常?音量大小是否可以让双方听清除?这个测试可以让我做一个全面的检查。如果一切工作正常我会听到自己的声音被重播回来。当对最终用户进行技术支持的时候,通过这个呼叫测试来检测系统是否工作正常是至关重要的。
       Q: 当出现问题的时候我们怎么检测?
       A: 在语音呼叫的过程中用户可以检查音频流来回波动的程度。如果波动很小表明音量很低,那么用户很有可能听不到声音。
       事实上,Skype 已经提供了这项功能。如果线路几秒钟一直没有声音,Skype 会弹出提示,告诉用户无法听到声音并会提供相应的帮助(以一种略微狡猾但却不烦人的方式)。如果你点击这个提示Skype 会显示音频设备的音量调节控制台,用户在这里可以看到当前的通话窗口的音量是多少。
       与此相对比,在Office Communicator 中用户无法了解语音是否可以正常工作。所以我采用的方法是直接拨打到我的手机上,看看是否可以听到语音邮件的提示以及是否可以留言。如果不能听到,我可以很确信它不能正常工作。
       Q: 我们应该如何指导用户解决问题?
       A: Skype 和Office Communicator 都采用基于WEB 方式的帮助文档来帮助用户。Office communicator 邀请用户点击菜单上的按钮(请参阅我发表的 上一篇文章)。在修复问题的时候,Skype 采用的排错方法有非常详细的文档,提供了5页甚至更多的排错方法让用户尝试,并可以带给用户向导式的体验。Office Communicator 的帮助只是简单的指导我运行音频和视频设置向导。
       Q: 我们的技术支持人员如何远程诊断并修复发生的问题?
       A: 我从来没有接触过Skype 的技术支持人员因为我从来也没有这方面的需求——我总是能够自己诊断和音频相关的问题。但是我和Office Communicator 的支持人员关于一些问题进行过探讨。比如我曾经花费很多时间搜索网页和知识库,然后为USB 耳机安装了相应的补丁。但是我并没有感到速度变快,尽管我非常确信我的耳机可以在Skype 中正常工作,但是技术支持似乎要说服我问题出在我的耳机上。
       最终结果
       啰嗦了半天,最后终于得出了如下的结论。音频和视频安装向导可以帮助我证明我的耳机确实工作正常
       正如你所看到的,和Skype 相同的是,他可以显示所选音频设备的当前音量;但和Skype 不同的是,用户很难找到启动这个向导的位置。当然,这个打开的窗口显示了我的耳机工作正常,那么问题出在什么地方呢?
       到了自己寻找解决方案的时间了
       当我正在等待我的在线聊天技术支持代理帮我找到问题所在的时候,我决定自己也对每一个菜单以及每一个对话框进行尝试,看看能不能找到一些可以帮助我的功能……最终似乎有6个备选功能。所以我们放弃了刚才的那个菜单,转而探讨这6个功能。这看起来很酷,不是吗?
       最终我在偶然之中发现了一个和呼叫转移相关的设置项。之前我忽略了这个选项是因为我没有打开呼叫转移功能。
       但是任何和设置相关的选项都能给我带来希望,所以我点下了鼠标,如下图所示
       我只能说这个设置对呼叫转移没有什么作用,但我的首选通话设备应该被设置为Computer。这个关键的信息在帮助文档,网页以及知识库中都没有找到。
       但是让我们再考虑一下这个问题。 如果采用该软件初始默认设置,就不能实现正常通话,除非将一个USB接口的电话接在电脑上。更糟糕的是,当你的Office Communicator 在这种有问题的设置的时候(首选设备设置为电话但事实上没有接电话),他居然还很乐此不疲的去尝试建立通话(事实上虽然可以成功建立通话但是却没有声音)。音频和视频设置向导不能够发现首选设备是如何设置的,事实上不管首选设备选择的是什么,都将会优先采用首选设备。
       A Lesson From Frank Lloyd Wright
       Frank Lloyd Wright 作为美国著名架构师,坚信设计工作应该以人为本。Office Communicator,Skype 以及您自己的应用程序都是为人而设计的。如果人们不能够使用你的应用程序的某一个主要功能,那么你的应用程序就是失败的。测试人机交互,了解什么功能可以正常工作什么功能不可以, 我们就可以花更少的时间去进行毫无意义的搜索,而这种搜索的目的却是让程序的主要功能完成自己的工作。
       
>> 查看文章
RSS 源   Ron Jacobs
投递时间 2007年6月5日星期二 4:07
作       者 ronjacobs
主       题 Tech-Ed US 2007 – 架构前景展望
整篇文章链接:http://blogs.msdn.com/rjacobs/archive/2007/06/04/tech-ed-us-2007-the-architecture-landscape.aspx
       哈哈!终于完成了。我刚刚在Tech-Ed US 2007上讲授了一段课程。我不得不告诉你我非常喜欢它。2年前,我曾经讨论过“SOA的模式与反模式”的问题,之后我知道我必须做一些不同的事情。问题是,应该做些什么呢?起初,我想过三个主题,但是后来我发现这些主题的范围太宽了,我根本就没有时间来研究这三个方面,所以我决定把精力放在其中一项上。测试驱动开发和它在架构模式(例如Model-View-Presenter,MVP)上的影响。
       为了打一个基础,我必须先做一个简单的TDD的示例,然后我展示了一个视频,其中Peter Provost解释了为什么TDD是那么的出色。然后,在讨论中我展示了一些示例代码,从而深入的研究这些概念,其中一些示例代码使用NMock(我非常的喜欢它)。
       这个话题拥有一个奇怪的名字…当他们让我提交的时候,我已经没有什么选择了。否则的话,我肯定会选择一个更好的。
       幻灯片: ARC201 – Ron Jacobs on the Architecture Landscape
       我还主持了一个话题叫作PRCN01-Introduction to Software Architecture
       希望 ARCast的听众和ARCast.TV的观众可以来到Tech-Ed,而全球其它地方的人可能要到几个月后才能听到了。
>> 查看文章
RSS 源   Ron Jacobs
投递时间 2007年4月18日星期三 22:34
作       者 ronjacobs
主       题 今天在ARCast.TV上献上了关于Architecting for Performance的视频
整篇文章链接:http://blogs.msdn.com/rjacobs/archive/2007/04/18/today-on-arcast-tv-architecting-for-performance.aspx
今天,在ARCast.TV站点上又有了一段来自Kuala Lumpur关于性能和可伸缩性的视频。于是,我想我应该写一些关于这个主题的想法。
当面对性能问题的时候,解决方案架构师应该处于一个什么角色呢?
硬件的工程师将考虑使用真正快速的服务器,那么这是否是这个角色应该考虑的呢?
测试团队将会在压力下测试系统 - 这是这个角色应该考虑的吗?
答案对于所有上面提出的问题都是肯定的。当然,我没有说架构师就应该去考虑服务器到代码编写与测试,但是架构师必须对这些方面进行有效的影响,因为架构师要做的最为主要的工作就是以一种清晰的、可测试的方式去描述系统的性能和可伸缩性目标。如果你不这样做,怎样才能为一个没有定义的目标去调整服务器,优化代码或者测试?
当我询问项目团队,什么是他们的性能和可伸缩性目标时,他们有时候会看着我,就像我是从火星来的似的。"当然,我们希望我们的团队非常快而且具有很高的可伸缩性"他们说 - 当然你是这么做的,但是你会认识到这决定于你如何定义"快"和"可伸缩"这样的词汇,这些目标可能会发生冲突。
在我看来,性能目标应当从三个维度来描述
吞吐量
吞吐量目标回答了"多少"的问题。这时,通常应当从整体上来关注系统的后端。
"服务器场每秒处理多少请求?"
"它每秒钟可以支持多少事务?"
于那些非技术的人员来说,你也可以用商业词汇来描述这些目标。
"我们每个小时能卖多少东西呢?"
"系统每秒钟可以接受多少份订单?"
优化吞吐量就意味着使服务器资源(线程,内存,等)非常有效,并且可以在某些情况下实现秒级别的处理。
响应时间
响应时间是一种客户感受,当人们说一个系统是快还是慢的时候,他们的意思是他们的感觉,因为从他们点击按钮到他们看到响应的时间感觉更快了。你会注意到我正在使用一些非专业的词汇,像"感受"和"感觉",因为这才是人们所说的事情。当然,对于响应时间的一个非常专用的度量值是客户端收到响应的最后一个字节的平均毫秒数(Time to Last Byte,TTLB),并且你应该尽可能的进行优化(同时要平衡吞吐量),但是还有很多事情你可以去做,用来使一个系统"感觉"更快。
负载量
负载量定义了在指定的时间内可以有多少。通常,我们会说并发的用户数量以及他们所发送或接收的数据的容量。为了获得精确的测试结果,你必须创建一个与生产环境相同的环境,使代码可以在其中进行测试。
"你期望平均的并发用户数量有多少?"
"峰值处理时间是多少?"
"一个常规的用户将会获取,存储或搜索多少数据?"
当架构师在这些方面建立目标后,你就可以创建一个可以测试的目标。测试团队可以进行一些特定的测试,运行场景,然后告诉你代码是否可以满足目标。争论"快"和"慢"是没有意义的,直到你知道了这些数字。
就像 Lord Kelvin 写到的那样
"当你去衡量你所说的事情,并且用数字来表示的时候,你将可以了解一些事情。但是,当你不能用数字来表示的时候,你所知道的可能是片面的或者是不充分的。这可能是理解的起点,但是在进行科学的表述之前,你是一无所知的。"
定义,度量,筛选,然后重复。
你可以的-现在就开始你的架构师工作吧…
>> 查看文章
RSS 源   Ron Jacobs
投递时间 2007年4月14日星期六 3:07
作       者 ronjacobs
主       题 想成为一名架构师?那么学习像架构师一样思考
整篇文章链接:http://blogs.msdn.com/rjacobs/archive/2007/04/13/want-to-be-an-architect-learn-to-think-like-one.aspx
你是不是现在正在考虑成为一个架构师呢?人们经常会问我如何成为一个架构师。我通常会回答他们,成为一个架构师最好的方法是像一个架构师一样行动起来。为了帮助你解答这个问题,我采访了世界各地的架构师,为了理解他们的工作方式。
想像…
你被认命为一个公司的架构师,这个公司近期经营的不是非常好。一个非常重要的原有应用现在处于使用状态,但是它的代码非常的陈旧,而且处于原有的平台上。上一任期的公司领导决定创建一个使用.NET的新版本,它可以支持所有的数据库类型,而且配置起来比较灵活,它可能帮助你与市场中的一些巨头竞争。在耗尽他们所有的VC投资后,重担压到了领导人的身上。你正在是新的首席架构师。你将会怎么做?
考虑一会儿。这个问题的答案并不是纯粹技术上的。必须考虑出一种商业策略 - 你需要与新的CEO协商策略。你将会提出什么建议呢?它如何能够影响架构呢?你如何才能推进团队的进展,并且在现有的客户流失前快速的交付价值呢?
如果你希望知道在现实的Pay Global公司是如何处理这些问题的,那么你可以来看一看这段视频。 ARCast.TV - Recovery and Moving Forward - Pay Global
开始像架构师一样思考,你将会像他们一样行动起来。
Ron
>> 查看文章
RSS 源   Ron Jacobs
投递时间 2007年4月12日星期四 8:20
作       者 ronjacobs
主       题 投资"长尾"
整篇文章链接:http://blogs.msdn.com/rjacobs/archive/2007/04/11/investing-in-the-long-tail.aspx
"你必须为你所看到的世界做出改变。"
-Mahatma Gandhi
几乎每天我都在想,我是多么吃惊于互联网为我们带来的改变。如果你让别人去看过去几年(只是20年),然后告诉他们互联网对世界影响有多大,我敢肯定他们一定会震惊的。曾经有很多未来学家预测世界将会越来越统一,企业也会变得越来越大。他们忧虑个人的声音可能会被严密控制的媒体所掩盖,但是网络使得他们所有的预言都烟消云散。
随着越来越多的公司和企业致力服务于个人,网络开始出现了"长尾"现象。慈善主义也参与到了这次革命当中,而且今天我成为了"长尾"的一个投资者,从而消除世界上的贫穷。可能您也像我一样,已经对于世界上范围内的大公司以及他们在消除贫穷上的无能而感到沮丧。大量的救济计划只能解决短期的问题,但是长期的贫穷和机会的缺乏才是他们难以逾越的障碍。但是今天,我听说一个站点叫做Kiva,它允许我作为一个出借人,以信用的形式面向世界另外一边的一些商业人士。
这个小小的投资会改变世界吗?可能不会,但是他会为一个家庭带来改变,可能会由于他们业务的成功而雇佣其他人,或者去采购一些商品,从而可能会调动他们周围的经济环境。当然,投资这笔钱对于我来说不算什么,但是跟你说实话,这里投资的回报并不是钱,而是对于未来的美好愿望。对于我们这些工作在这个产业里的人来说,拥有了太多的其它星球上根本没有的机会,我相信我们必须为我们所看到的世界做出改变。
要世界变得更加美好,现在轮到你了!
>> 查看文章
  个人信息中心 | MSDN中文速递邮件
  ©2007 Microsoft Corporation.版权所有. 保留所有权利 | 商标 | 隐私权声明