Kulercream@marketplace
Kulercream是我们创意团队自行开发的一个小型Windows Phone 7 应用，也是我前阵在写教程的一些内容。这是一个基于Adobe Kuler的API来帮助用户搜索有用的配色组合。这只是一个小小的尝试，功能也非常简单，但帮助整个团队积累了不少有关Windows Phone 7 设计方面的经验。有兴趣的，有WP7的可以下载试试
Experience10 Creative, Develop, UX, Wireframe, Productivity
WP7上的Image使用技巧
部分翻译摘录自swick的blog
如果经常开发App，WP7上的Image显示造成的内存增大问题一定会遇到，以下是一些使用技巧帮助减少这类情况的发生：
JPG vs. PNG
如果不是必须要使用透明图片，JPG是最好的选择，WP7的JPG编码速度要大大快于PNG
Resource vs. Content
将图片(或其它种类资源)用何种类型进行XAP编译绑定的时候。Resource和Content有很大的不同，Resource会绑定到Dll之中，在显示图像时很快，但加载整个XAP包时很慢。而Content会使得加载XAP应用时很快，但加载图像时稍慢一些。根据情况选用，使用方法：
Content: <Image Source=”/ImagesAsContent/smiley1.png”/>
Resource: <Image Source=”..\ImagesAsResource\smiley3.png”/>
Async vs. Sync 异步或同步加载图片
BitmapImage.UriSource = uriSource; // 从URI中读取，异步加载
BitmapImage.SetSource(stream); // 从流中读取，同步加载
图片缓存
如果内存没有被回收，可以考虑主动释放:
BitmapImage bitmapImage = image.Source as BitmapImage;
bitmapImage.UriSource = null;
image.Source = null;
自定义编码
如果所需图片尺寸不需要很大，可以将来源进行重编码，使用PictureDecoder API可完成这个操作如下：
image.Source = PictureDecoder.DecodeJpeg(jpgStream, 192, 256);
WP7 性能提示
一组笔记：
- 永远在真实设备上测试性能
- 不要使用WebClient来做网络数据访问
- 尽量使用静止的背景替代Panorama的滑动背景
- List中尽量使用Visualize stackpanel替代StackPanel
- 尽量使用简单结构的用户控件，如果需要成组元素，考虑一下一个元素是否可以替代
- 不要在XAML中使用太多Converter
- 图片可以设定宽高，而不要让系统动态的计算
- 不要在刚开始就加载Bing Map
- 图片可以设为”Content”以加快程序启动速度
- 如果页面不常用，可以放在另一个Assembly之中
从iPhone Tab Bar学到的…
在过去的几年中，iPhone成功的使得Tab Bar标签栏导航方式在移动设备上流行起来。Apple将tab bar和其它许多的设计原则整合到了他们的人机交互指南(HIG)中——但有些疑问他们从来没有回答。在过去的几年中我一直从事交互与图形设计，在这篇文章中我将分享一些我的想法有关什么是该做的，什么是不该做的。
第一课：魔法数字是5
这对从事iPhone设计的人来说不是新鲜事。自从iPhone的屏幕宽度为320点(dots)开始(1点＝2象素)，Apple设计了标准的tab bar不能超过5个tab，每个tab包含其图标与可读的文字。
5个之后会如何呢？当然，我们可以采用使用”More”标签的方式放进标准的tab bar。但是我还是推荐尽可能的去避免”More”标签。为什么呢？
- 首先，你自然会损失掉一个tab
- 你将记录”More”标签下功能的这个重担交给了用户。如果你的”More”下面的内容达到5个时，问题更加突出，这些加重了用户的认知负荷能力(cognitive load)
- 一些测试表明用户根本不知道”More”功能的用途，而且根本不会影响用户(来源：Tapworthy – Designing Great iPhone Apps by Josh Clark）
当然，当你在各种视图下工作、数据排序以及分类时（例如iPod），使用”More”标签的方式来替代让用户自定义标签会更合理一些。因为自定义标签的这种行为在某些情况下只适用于高级用户。
第二课：询问用户的意见
这种方式在你的设计过程中会非常有帮助，但标签的分类和级别应该更接近于你目标用户群的想法。当我们做这种研究测试时，记得事实1中提到的内容，不断思考所有的内容是否能分类到五个标签之中。如果不行，请问自己是不是非得用tab bar作为导航方式呢？
第三课：花多的时间在图标和文字上
一些用于图标设计及文案设计的点子：
- 确定图标和文案能真实的标签这些标签下所要进行的行为。最让人闹火的事情莫过于明明知道程序中有一个功能，但却不知道在哪个tab下面
- 避免一些语义上无关的设计，例如一个笔刷的图标但下面却写着“报表”。可参见 picture word interference
- 如果你要创建另一个“我的收藏”的标签，不用试着重新设计星形图标或改变文字“我的收藏”(Favorites)。虽然重新识别一个事物的成本低于回忆事物，但是我们应该帮助用户减少认知负荷(Jacob Nielsens Ten Usability Heuristics)
- 避免出现重复的文字。例如，想象你需要创建“我的图书”“我的杂志”“我的CD”这样的情况。根据Stroop effect(斯特鲁普效应)的解释用户会主动忽略掉这些文字。
- 让图标设计得有含义及易于识别这样用户能立即知道该点哪个tab，避免让用户考虑例如“到底是扳手呢？还是在齿轮表示设置呢？”
- 如果你在设计图标的时候遇到一些问题，不妨进这一层下面的内容去看看下面的布局以及内容是否能激发你的灵感。
重申，实地测试和探索非常重要。问问用户他们的理解方式！“你们认为这个脸部图标表示什么？”“你们觉得应该在什么样tab下可以找到Finder”“你觉得图标是脸，而文字写着Finder，这样说得通吗？”
Figure 1 — 左: NUUS 24 使用了相似的图标, 中: Spotify 使用了房子图标和 “What’s new”的文字, Right: Vimeo 重复使用文字 “My Videos” 和 “My Stuff”
第四课：避免自动改变tab
这是在我从事的很多项目中经常争论的问题。我的想法是，如果不是用户主动直接的在Tab上发生交互行为，永远不要改变Tab！我知道你们有可能在一些情况上发现这是唯一能解决一些奇怪的信息架构问题的方式，但是请还是主动去避免！为什么呢？
- 你在尝试打断用户所期望的控制行为。举例当用户点击一个表视图(Table View)的时候，他们永远期待二种结果：a)新视图从右向左滑进，b)新视图从下向上滑进。他们同样不希望在Tab Bar上发生他们预想不到的变化
- 你在扰乱用户早已习惯的iPhone“返回”交互习惯。如果他们没有注意到Tab已经改变，他们有可能以为到了下一级，试图找“返回”按钮
第五课：不要在Tab上做限制
如果你没有提供更好的方式让用户访问某些内容，不用让Tab设计具备限制性（如只针对注册用户）。让用户点击后才发现这些内容不可用时，这会让他们非常苦恼。
Figure 2 – Hemnet 应用中当你点击某个Tab时，提示你必须登录
第六课：小心使用自定义Tab
当越来越多的iPhone应用使用Tab Bar来展示信息架构的时候，设计师已经开始觉得无趣。设计师自己都知道，当设计师自己觉得无趣时，坏情况可能发生。一种方式就是为了避免设计上的无趣，开始自定义Tab Bar。
现在，我也是常常自定义Tab，因为能有个性，好记忆，而且有更好的品牌体验。但是有一些重要的事情必须牢记于心。
- 需花时候，而且有时候要花大量的时间。从开发人员角度来说，自定义Tab Bar 意味着完全重写代码。
- Apple设计Tab Bar和Tool Bar的颜色色调时是有一定理由的；它能很好的区别外观和导航的级别。将这种思想带到你的色彩设计之中。
- 有时候开发者和设计师总是忘了当点击一个Tab时，顶部的导航条显示了当前位置，同时如果有电话打入，系统的状态栏会变成双倍高度。别忘了设计这些情况。
- 有些应用使用一些自定的设计模式来应对具有共享视图的Tab Bar(如Twitter for iPhone)。如果你也考虑这种方式，那注意你有可能让你的用户产生疑惑。
Figure 3 — 在Twitter for iPhone中,这种多层Tab很容易让人困惑。当点了第一屏中的”651 favorites”后，进入了”favorites”视图，如中图所示，再点Back按钮，在第三屏中还是处于同一等级下的Tab，这时图标变成了”More”
总结
tab bar是你导航应用的主要方式。不要低估了设计一个完美的tab bar体验所要花的时间。这些总结中并没有绝对的规则，但希望能让你开启思路。
5种跨越UX设计障碍的方式
1: Stop Thinking So Much不要思考太多
2: Take a Step Back往回退一步
4: Do Some Research做一些研究
3: Separate Entirely将复杂问题分解一下
5: Ask For Help寻求帮助
Silverlight桌面端模拟iPad原型
近来尝试使用Silverlight介入早期的iPad开发，尝试做一些原型用来测试交互设计的效果。由于Silverlight开发工具的便利及对触屏显示器的支持，开发速度非常快，虽然不能完全模拟在iPad上的效果，但也可以算是达到了一半快速原型的目的。以下是使用Dell的触控显示器的原型实际效果：
与此同时，为了方便下次使用，我把用于iPad模拟的项目文件制作成了一个Visual Studio 的项目模板，点此下载，以下是预览效果：
下载ZIP文件包后，拷到
C:\Users\[Your Name]\Documents\Visual Studio 2010\Templates\ProjectTemplates\Silverlight
以后在新建Visual Studio项目的时候，在Silverlight分类下便可以看到这款模板
Douban FM
有人感兴趣为什么Douban电台的新图标是这个样子的吗？
看看这张图是不是有点明白了？
解决WP7渐变色深问题
由于部分Windows Phone 7 的硬件支持的色深只能到16位（部分设备支持32位），所以当一个渐变图片显示在设备上时容易出现条纹状效果，解决办法是在图片输出前做Dithering操作。另一方面是在PC上开发时就做好预防工作，先把模拟器的颜色从默认的32位改为16位，操作方式如下：
- 打开位于C:\Program Files (x86)\Microsoft XDE\1.0下面的WM7_Skin.xml文件
- 将displayDepth=”32″改为displayDepth=”16″
这样在模拟器上运行时就已经能观察到一些细微的变化以防止上机后出现问题：
真正解决渐变的问题，需要在Photoshop中对图片进行Dithering操作。具体的操作步骤见这里，但是不必要这么麻烦，我们可以下载这个已经做好的Photoshop Action动作文件，在输出前对渐变图片进行一次预处理，再置入到项目中输出，实际模拟器中的效果如下，手机上也经过测试没有问题：
设计师的职能界定
早上看到一篇国外的讨论有关如何去界定设计师的技能要求和工作范围，有很多说法值得学习一下，拿到这里记录一下：
>
我们寻找的UI设计师应该是这样：
- 写作：他们能否清晰的思考与沟通？写作能力对UI来说非常重要
- 界面设计：他们能在2D空间中有意义、整洁、便于让人理解的去组织元素吗？除了平面之他们，他们能否在时间顺序上组织元素（导航方式，流程，步骤）来减少不确定因素，以及有效率？
- 产品：他们会认同我们的客户对产品问题的理解以及有效的转换商业价值吗？换句话说，他们知道对我们的客户以及股东来说，什么重要，什么不重要？
- 开发：他们能否把他们的设计转成HTML/CSS?他们能否更进一步把他们的设计整合到应用程序源码中？他们能和程序员沟通吗？
- 人格：他们人品和动机好吗？
>
- 叙述技巧：他们能创作并讲故事吗？视觉上的和语言上的
- 创建好奇感：让用户能对事物产生兴趣
- 重构：喜欢打破常规－“这不是一个勺子”
- 会减法：提供多种想法但知道找到最好的解决方案
- 指导：学会把设计技术教育给客户、团队和公司
提高Wireframe表达能力的三个策略
“当我们在看线框图的时候，有些东西就应该能感受到”
当我听到类似的话时，我常常感觉这不是客户理解能力的事，而是我们的内容如何表达的问题。作为一个交互设计师，我们的工作是当信息无法正确传达时去进行有效沟通，这时候就变成了我们的问题。同时，我们必须面对一个问题：很多人并没有完全接受类似于线框图一类的比较专业的文档。这需要一个学习过程，而且我们必须尝试去教育大家。
从翻开线框图文档的封面开始，整个过程往往比我们想象中要复杂一些。当我们一页页的浏览画面并表述时，客户也在尝试着对这些难以理解的文档提出正确的见解。
接下来是我常常使用的三个可视化的策略，用来使得整个过程更加顺畅并获得有效反馈。这些并不能替换你现有的演示技巧，但会很有帮助。
策略 1：讲故事
我觉得常常很难脱离一个上下文环境去描述设计，所以应该使用较好的讲故事技巧演示。
我喜欢把很多页面放在一张画面下，并展示一个实际的应用场景。这些内容应该能表达动机，前提条件及期望的目标。
让这些画面经过他们的大脑，我发现人们会尝试用角色扮演的方式来理解这些线框图。通常，能尽量少的争论主观上的细节而应该花更多时间讨论如何更好的完成预定的设计目标。第二个好处是，你可以重复使用这些预定的人物原型(Persona)以及场景(Scenario)。
视觉上，我使用流程图(Flow Diagram)加上画面缩图的形式来替代传统的大方块。这些“小局部”帮助我们理解交互之间的变化。当线框图之间有超链接之后，这个图片就变为更好理解的可视化的内容展板。
策略 2：带到幕后
另一难点是如何将整个系统的概念放到你的设计传达之中。页面布局以及设计模块都是关于一些页面中的小局部细节。通常，初始就能定下这些细节，然后再考虑其它页面的情况。
当我设计页面时，我会先创建灰色的方块。这些方块会主动失去一些内容上的细节，相互关系以及访问路径。当我快速浏览这些页面时，这些方块能帮助我去理解页面之间的关系以及是否有相似的内容可以被类型化。在做更多细节前，留给我更多抽象级别的考虑空间。
同时我发现这些灰色方块方式也是一个很好的方式去进行线框图的讨论。细节的缺失反而更容易让我们介绍页面的架构。常规情况下，我会讨论如下内容：
- 页面的意图
- 系统的本质是什么
- 为什么内容这样组织
- 为什么另一些页面共享一些相同的设计模式
在展示更多细节前，通过这些“带到幕后”的方式预览页面，客户常常能更好的去理解我们设计的原因。他们可以分享设计师的意图以及考虑一些细节变化如何影响全局。
下面的图表展示了一个演示的流程。在(1)中我会强调这二页之间的一些相似和不同。之后，我会花一些时间讨论每个页面－同时我会通过调整灰块的透明度(2)来适时的隐藏结构，以便于更清楚的表述。
策略 3：展示工作
我的草图画得很糟－很杂乱。当然，一些客户可能不愿看这些东西，但我发现也会有很多人感激你通过草图把这些想法带到你的工作之中。
设计像一门神秘艺术。有时候难以理解、太多选择、太丰富或过琐碎，整个过程中需要深思熟虑及做适时决策。如果我们能展示整个设计的过程－哪些设计被放弃以及哪些留了下来－帮助我们更好的证明最终结果。它能很好的展示你曾探索过很多不同的方式，并不是仅仅在执行最初的想法。草图同样还能强调设计时的一些限定和约束，最可能的解决方案，以及可以接受的需求妥协。
具体来说，展现这些越早越好－甚至早到最终线框图展示之前。偶尔的，我还会把他们放进最终的演示之间来表达为什么其它的方式效果不佳。
其它技巧：
这些只是仅有的三个策略来帮助你的观众更好的投入你的线框图演示。除了这些之外，我不得不提及其它一些对我非常有用的技巧：
- 从小处开始。很难同一时间去消化10－15个线框图。每当我们表达过多内容时，观众总是觉得疲劳而且给一些很沉闷的反馈。这些会使得发现问题的过程变得缓慢以及影响设计和开发的时间。当然，没有人真的愿意开很开的会。
- Dribbble ideas（注重过程）。引自来自Dribbble，考虑在早期更多的引入各种各样的想法。你的工作不必放在结果上，只是不断的告之客户你的工作进展，并获得反馈，避免后期的风险。获得的回报时，客户也会参与到创作过程中，帮你承担一定的风险。
- 指导你的客户。是不是总是在线框图阶段就得到一些视觉方面的设计建议？与其去向客户解释“这只是线框图而不是设计”，不如直接想办法表达你的设计重点，你可以从这个列表开始尝试。
你呢？
这些当然不是全部的策略。你平时使用什么样的技巧使你的线框图展示更顺畅呢？
原文出处 Viget.com
翻译 Experience10.com