2010年10月27日
#
---逻辑分组模式：
问题：为了完成一个任务，用户必须填写一个比较长的表单。但是，web设计师可以给用户一个表单是很容易填写的印象，因此他们不会不愿意完成填写的。
解决方案：
把各个元素进行分组，因此用户可以比较清楚知道那些组的信息是必须填写的（比如收货信息，付款信息等等）
原因：
由于表单元素进行了分组后，用户可以比较清晰的知道每个组需要那些信息，这些组的信息又是如何组织起来的。因此用户可能会想从更小型的分组来考虑而不是认为是一个大的集合的单独元素集合。
如何做：
把表单元素按照他们的功能比如收货地址，账单地址，联系人信息等等进行分组。每个分组，确保其顺序能和用户对如何组织信息的思维模式一致。比如，在美国的用户，组织地址的相关表单元素是从街道，然后到城市，再到州和邮编。对于注册账户信息，是先有用户名或者邮箱地址，然后才有密码。
2010年10月25日
#
--短表单模式
问题：用户提供更多的信息，就越容易理解他们的底细，也就能更好的精简web程序来提供给用户更多他们需要和相对个性化的信息。然而，长的表单增加了用户放弃填写标准和提供错误信息的机会。
解决方案：尽可能把表单设计得短点，不要想客户询问一些未来可能需要的信息，如果某些信息可能有用，并且不能够给删除，可以考虑把它们放到候选页中，并且指出默认同意的项。
原因：把表单设计得短点能够减少错误的发生，提高用户填写表单的成功率，可以导致比较高的用户转化率。
如何做：按照每个表单元素的重要性，包括那些没有放到表单上的元素。同时考虑用户如何才能更方便的提信息。如果用户需要停顿下来思考该如何填写时，考虑把该填写项从表单中去除。
把长的表单使用短表单分割成多个页面，放在不同的块中。
表单设计：
表单主要由text boxes，dropdown lists，scrolling list,radio buttons,check-boxes and action buttons.用户利用表单可以完成诸如购买商品和服务，预定机票，寻找方向，上传和共享图片等等。
设计一个成功的表单必须注意以下几个方面：
1、表单的目的是明确的（清楚的好处）
2、相对来说只要求比较少量的信息（简短的表单）
3、组织形式简单明确的表明表单里面各种元素的关系（逻辑分组）
4、标签和相对应的表单元素应该为了容易被扫描和完成填写而被排列起来。
5、表单必须清楚的指出希望从用户那边获取那些必填的项，输入提示或者提醒。
6、表单只要求用户填写最少的项，不要求用户重复输入2次同样的信息（聪明的利用默认值）
7、用户能够高效的完成一个表单的填写（聪明的默认值，忽略格式，键盘导航）。
8、表单必须清楚的支持如何完成一个任务（行动按钮）
9、当错误发生时，表单必须清晰的引导用户（错误提示信息）
清晰的好处：
1、问题：当页面上出现一张表单时，用户可能不知道如何填写和提交表单，从而帮助他们完成他们的目标和任务。
2、解决方案：当在设计一张表单是，必须清楚的告诉用户填写完成和提交表单能够获得什么好处。这个是特别重要的，当用户创建一个账户时。
3、为什么：用户可能不行填写和提供自己的私人信息除非他们理解填写后能够获得什么回到和在多大程度上能够帮助他们达成自己的目标。
同时，他们可能比较关系个人信息的安全，因为他们不知道这些信息将会被如何使用。清晰的指出好处和写明用户个人信息安全保证，是防止用户放弃填写表单的第一步。
4、如何做：用户应该意识到填写表单的好处，即使只需要填写一项信息。
经常需要提供的表单：
1、login form。如果用户访问登录表单，这是一个很好的机会向用户展示注册的好处，这能够让用户做出是否注册的决定。
2、leading user to the form：在很多场合下，用户都不知道注册表单的好处。因此，如何引导用户去注册必须被放在注册登录表单前。
引导的标签题目必须有比较明确的意思，而不是那些通常的“知道更多”，“继续”等。
和清晰的好处相关的模式：联系客户按钮。这个现在被很多大的互联网网站，保险公司网站，银行网站，游戏网站大量使用。这样方便用户在不知道如何完成一件事情时，可以联系在线的客户进行解答。
2010年10月23日
#
web应用的好处：
1、容易访问。因为用户只需要一个浏览器就可以在能连接上网络地方浏览任何的web应用。特别是现在的移动互联网和mid（多媒体互联网设备），平板电脑，智能手机的降价普及，且随着国内3G网络的普及，随时随地连接上互联网已经不在是一个可望不可求的事情，而是变得先自来水那一样普遍，伸手能获取的东西。作者在书上讲了2个例子，saas和云计算。
2、容易部署。web应用如此发展迅猛的原因是它的开发，更新，维护都比较方便，不需要下载，安装，卸载等常规的客户端软件使用方式。因为web应用都是部署在服务器端，而服务器是可以通过远程的方式连接上去，可以随时的做维护升级等，特别是现在开源运动的流行推动了服务器端软件的采购成本比较低，有的甚至免费。比如像lamp平台（linux+apache+mysql+php）就是现在大部分网站的或者网络应用系统的标准运行环境，而搭建这么一套平台的费用基本就是请技术人员的工资费用和买机器设备，网络带宽租借费。
3、成熟的客户群。web的发展和传播从1995年12月的1600万，增长到2008年6月份的15亿。用户现在对web应用已经非常熟悉，对浏览器中常用的家目录，后台，前进，标签，超链接，提交按钮等都已经很熟悉。
4、成熟可靠的网络链接和web技术的飞速发展给web应用设计提供了非常好的条件。
web应用面临的挑战：
1、高度解耦和无状态的web架构。目前的web应用都是在http协议的基础上搭建起来的，而http协议是一个无状态的协议，用户的每一次请求服务器都要像响应第一次请求那样重新向服务器发起请求，等待服务器响应，然后浏览器进行加载处理，再显示给最后用户。每一次页面的重载，刷新，都有可能收到网络链接延迟的影响。
2、web应用设计可以用的控件，文摘，都比较有限。现在html4.01版本只支持常见的text boxes,radio buttons,checkboxes,dropdown list, command 或者action buttons。它支持复杂像桌面程序那样复杂的UI界面，比如spin controls，calendars，wizards，tabs，toolbars，drag-and-drop,floating palettes,dialog boxes,context-sensitive menus 等等。
3、不一致的交互行为。现在市场浏览器厂商众多，ie，firefox，safari，opera，还有国内一些使用ie内核的浏览器，如maxthon，360浏览器。但是这些浏览器在解析html时都没有完全按照w3c制定的标准html来执行，所以现在设计师要设计一个web应用程序时需要考虑到各种浏览器的兼容性问题，这无疑会阻碍web应用的快速发展。
web 设计模式的定义：
模式的来源是由建筑师christoper alexander在他的一本书 《A Pattern Language》和《The Timeless Way of Building》中提到的。
书中大概的意思：每个模式都描述了一个在我们周围环境都会不断碰到的问题，并且同时会描述解决该问题的核心解决方案，按照这个方案你能够解决数以万计的相似问题，并且不需要同样的事情再做2次。
由于模式在软件设计的大量应用，比如Gof的设计模式，同时设计模式也被应用到用户交互接口的设计中，主要原因是模式有以下好处：
1、被证明的设计解决方案和指引。设计模式指出解决问题真实而不是抽象的原则指导。
2、被证实的设计过程。明确的设计模式和分类能够帮助用户交互设计师提高生产力，减少需要重新发明轮子的时间，更进一步讲如果用户界面设计能够做成像代码库那一可以提供给其他设计师调用是，这样有利于快速的迭代，减少发布的周期。
3、重用和一致界面。开发一个可以重用的用户界面组件能够充分的适应在各个不同的或者交叉的项目中保持一致用户体验。
4、一个通用的，公共的设计师交流语言。如果有一个确定的模式，这样设计在交流彼此之间的设计思想时可以比较容易的理解设计思想中蕴含的内容。
5、有效的教学和引用工具。在训练新兵时，可以采用设计模式的方式来和明确的告诉新手，那些应该该怎么设计，有一个非常清晰的指引。
6、容易使用的web应用。如果web设计师能够按照模式的指引来设计的话，那么web应用的用户体验会大大的提高。
2007年6月1日
#
Submitted by Paul Dix on Fri, 2005-10-28 09:04. How-To | Ruby
A project I'm working on has a difficult requirement to meet. It needs to be able to support a multi-master database model. If you're already familiar with the concept, please forgive the following short introduction. This means that multiple systems need to be able to create records in their local database and sync up to other ones later. Connection among the systems is not guaranteed to be up 100% of the time. A prime example of this type of system is Microsoft's Active Directory.
Some of the key concerns when designing this solution are how to select primary keys that will avoid collision and how to keep relational data in tact when syncing data from one database to another. The method I follow for this is to use a UUID or GUID as the primary key for every table, just like Active Directory. When I initially looked at Rails for this project this was a major concern. ActiveRecord ties an auto-incrementing integer as the primary key for all tables/models and I was worried about my ability to override that. Well with a little searching, reading and a tiny amount of effort I was able to get Rails to do exactly what was needed. The following is how I did it.
The first thing you'll need to do is grab UUIDTools, which is a ruby gem written by Bob Aman. The preferred method for installing is through gems from the command line like so:
gem install uuidtools
Then go into your rails application and create uuid_helper.rb in your app/helpers directory. Make that file look like so:
Note: the following code is from this post and its comments:
require 'rubygems'
require 'uuidtools'
module UUIDHelper
def before_create()
self.id = UUID.timestamp_create().to_s
end
end
All that's left in code is to add a line into your models that will use this functionality. The reason it's this incredibly easy is because of Ruby's Mixins (which should be the topic of another post entirely). So if we have a model named Product it would look like this:
class Product < ActiveRecord::Base
include UUIDHelper
# your module code...
end
The last part is the database itself. This will vary depending on what database you use. In my case it's MySQL. Since MySQL doesn't have a UUID field we use VARCHAR(36). I keep the field name the same (id) and everything is ready to go. In the comments of this post (mentioned earlier) Bob suggests the possibility of using a 128 bit integer as an alternative to a 36 character string. At first glance this doesn't seem possible in MySQL. MySQL's BigInt datatype doesn't seem to be able to store the range of values as mentioned in this thread.
So you can see that it's pretty simple to get ActiveRecord using UUIDs for the primary keys. Using Bob's UUIDTools gem we can design a solution that is platform and database independent.