‘网页重构’ 分类的存档

• Axure RP 快速原型制作软件 – 线框图，原型，规格文档

  日期：2010.03.10 | 分类：网页重构, 设计制作 | 评论数：0

  

  今天刚接触了Axure RP，感觉很方便，特别是做大型项目，有很大的辅助作用！给我的感觉是，它是一款可以快速实现、准确表达、带有交互效果且易于上手的原型设计利器！

  好了，FH我少说了哈，了解哈Axure RP它。

  Axure RP 快速原型制作软件，由美国Axure Software Solutions, Inc.公司开发。

  Axure RP 能让操作它的人快速准确的创建基于 Web的网站流程图、原型页面、交互体验设计、标注详细开发说明，并导出Html原型或规格的Word开发文档。（通过扩展还会支持更多的输出格式）。

  它的功能特性有：

  • 网站架构图 (Site Structure)
  • 示意图 (Wireframe)
  • 流程图 (Flowchart)
  • 交互设计 (Interaction Design)
  • 原型设计 (HTML Prototype)
  • 规格文档 (Specification)

  界面如下：

  

  官方视频介绍

  交互实例演示

  Axure RP中文社区

• 页面重构中的模块化思维

  日期：2010.01.18 | 分类：网页重构, 设计制作 | 评论数：0

  “模块化”只是我们对于过去一直使用的技术、方法的一个新潮的称谓，就像“Ajax”。不过做为页面重构发展的一种趋势，越来越被大家重视，不自觉也满口的“模块化”，只是你真的理解什么是“模块化”吗？

  什么是模块化？

  对“模块化”的解释，在 CNKI 中就有28种。可见“模块化”思维使用的广泛。最接近页面重构中的“模块化”，现有的解释应该就是软件开发中的解释了。

  先看一下百度词条是怎么解释“ 模块化 ”的：

  模块化是指解决一个复杂问题时自顶向下逐层把软件系统划分成若干模块的过程。每个模块完成一个特定的子功能，所有的模块按某种方法组装起来，成为一个整体，完成整个系统所要求的功能。模块具有以下几种基本属性：接口、功能、逻辑、状态，功能、状态与接口反映模块的外部特性，逻辑反映它的内部特性。在软件的体系结构中，模块是可组合、分解和更换的单元。

  相关的书籍也蛮多的，有兴趣的同学可以搜一下。需要强调一点，我们所借鉴的是一种思维的方式。

  页面制作为什么需要模块化？

  站点内容越来越多、代码越来越臃肿，渐渐影响到了客户端的体验（主要是打开速度），影响到了维护的效率。有什么方法可以解决这些问题呢？

  我们很容易就想到：减少代码冗余、提高代码重用率、图片压缩等等，而这些要如何实现呢？模块化思维可以解决，即可以有效减少代码冗余、提高代码重用率，更重要是可以支持到多人维护，降低维护成本。CSS写法较为灵活，容易产生代码的耦合，使用模块化也可以在一定程度上降低耦合度，对于BUG的定位也有帮助。所以，我们更应该在站点前期就重视并使用“模块化的思维”编写站点。

  我们之前经常提到的站点性能优化，有相当一部分也是“模块化”的内容，比如提高代码重用，提高开发效率等等，“模块化”的优点还有很多，我大概列了一下：

  * 提高代码重用率
  * 提高开发效率、减少沟通成本
  * 降低耦合
  * 降低发布风险
  * 减少Bug定位时间和Fix成本
  * 提高页面容错
  * 更好的实现快速迭代
  * 更好的支持灰度发布

  其中最重要的一点，我认为是“提高代码重用率”，这也是模块化最重要的特点之一。

  如何实现“模块化”？

  这里的主要问题是HTML与CSS的“模块化”，我们可以看下换肤的实现方法：

  * 同一类名，换文件（JS）
  * 同一文件，换类名（JS）

  由此可知HTML与CSS的接口实现：

  * CSS引入的三种方式
  * 类名

  为了更好的实现这种接口，需要有相关的（交互、设计、页面、开发）约定、规则、规范，比如：所有当前状态都使用同一个类名“nonce”，所有变灰的表现都使用原类名后加“_n”，Tab的实现方式等等。有了这些约定、规则、规范后，HTML代码就很容易可以实现模板化，统一接口规范。

  有两个误区需要先认清下：

  * 模块化后并不是就能被使用在任何位置（模块化后的代码段也是有适用的范围限制，需要一个提供接口规则的环境）
  * 模块化后并不是就不能再变更（模块化后的代码段可根据实际需要做修改）

  完全独立的模块放在同一项目中，由于项目有自己的表现、交互统一性，所以各模块间必定出现类似的部分，这些部分可以被提出来做为公共的定义，减少冗余，这时就会出现耦合的问题，完全不耦合是不可能的，因此模块化中很重要一点就是“适度的耦合”。有了公共定义，就得调整模块样式的实现方式了，而这种调整也会影响到“接口”的实现方式。

  由于本篇主要是讲模块化的思维方式，具体实现的细节留待以后的文章中探讨。

  感谢：tencent UED 分享！

• 你是一个职业的页面重构工作者吗？

  日期：2009.12.31 | 分类：网页重构, 设计制作 | 评论数：0

  做为一个专职的页面重构者， 我们从事的工作简单的说就是“将设计稿转换成WEB页面”，这一过程可以很简单到直接把PSD从PS里导出成网页；也可复杂到需要考虑页面中每个标签的使用，考虑“页面性能”。以“前端工程师”为目标的同学可能会不愿承认将页面重构这块分出来，但随着工种的细分，加上页面重构本身的专业性，独立为一个职业也不是不可能，至少我现在从事的就是一个专职的职位。如果你觉得一个前端工程师必须去画设计稿，可以不理会下面的内容。

  单纯的页面重构，所涉及到的工作内容一般是“分析设计稿=>切图=>写 HTML 和 CSS ”，虽然看起来很少，但要做好这份工作，绝非所想的那么容易。原因很简单：工作内容单一，在时间和工作量上必会很苛刻，往往跟设计师的工作时间是3:1，即设计师给三天的时间，制作只给一天的时间完成；在这种工作强度下，很多人都是靠着对这份工作的喜爱在维持着，一旦工作热情消失，很容易就会变得枯燥，保持热情也成了重构工作者（也许是所有参加工作的人）应该具备的能力。

  跟“前端工程师”所要求的有所不同，“页面重构”虽然也是“前端工程师”的一个范畴，在职业化中，对专职的页面重构者，要求当然也更高。不单是做出页面，而是做出好页面。又引出另一个话题，“何为好页面？”，一般包括下面几点：

  1. 结构完整，可通过标准验证
  2. 标签语义化，结构合理
  3. 充分考虑到页面在站点中的“作用和重要性”，并对其进行有针对性的优化

  很多同学多少都遇到过方向不明，不知道自己应该提高些什么，我们可以从“分析设计稿=>切图=>写HTML和CSS”这个工作内容，针对每一点提出一些要求，以方便我们分析自己的能力水平，为继续提高确定个方向：

  设计稿的分析
  是指对设计稿如何制作成页面的分析，即哪一块的内容可以做为公共的部分、哪一块的内容结构可以如何实现等。

  对设计稿的分析能力可以划分成下面的几个阶段：

  1. 能分清设计稿中的公共与私有的部分
  2. 在1的基础上对各部分的实现方式有一个初步的方案（包括如何切图、写结构、写样式）
  3. 在1的基础上，准确的给出各部分的实现方案（包括如何切图、写结构、写样式）
  4. 在3的基础上，能同时考虑方案的扩展性、复用性及页面性能（包括如何切图、写结构、写样式）
  5. 在4的基础上，考虑整站的结构分布（包括文件分布、目录结构）

  上面这些都是在还没开始动手制作之前所要做的。

  切图
  是指将设计稿切成便于制作成页面的图片。

  很多人都有个误区，觉得切图就是把图片切出来，其实并不完全是这样，还包括把切出来的图片合并到一起，怎么切、从哪切才能将性能最大化，说“切图是一门艺术”完全不为过。切图也可以划分成几个阶段：

  1. 切成所需要的图片（如何将需要的部分切出来）
  2. 在1的基础上，对切出来的图片进行一些优化（包括压缩文件大小、选择图片类型）
  3. 在2的基础上，规划切出来的图片（包括文件分布）
  4. 在3的基础上，考虑整体的性能（包括合并图片、压缩文件大小）

  HTML和CSS的编写
  是指将上面完成的内容，通过HTML和CSS的编写，将设计稿转换成WEB页面

  这块是最重要的一块，也是我们所要重点掌握的内容，把它们放在一起，是因为它们相互的关联性太强，HTML的写法会影响到CSS的写法，它又可以划分成下面几个阶段：

  1. 还原设计稿视觉效果，并通过标准验证（HTML）
  2. 在1的基础上，实现多浏览器的兼容（HTML）
  3. 在2的基础上，标签语义化（HTML）
  4. 在3的基础上，选择较优的实现方式（包括模块化结构，方便程序脚本使用，HTML和CSS）
  5. 在4的基础上，考虑到扩展性、复用性和可维护性（HTML和CSS）
  6. 在5的基础上，考虑到整站的样式分布（包括如何实现分布）
  7. 在6的基础上，样式写法的优化（包括技巧的应用）

  还有一点是对所遇到问题的解决能力，这一点在不同的阶段都可能会遇到，所以没有写到上面。

  如果你已经达到或超过4、4、5，恭喜你，你已经是一个职业的“页面重构工作者”了。

  为了我们自身的发展，关注新技术、技术创新、提高用户体验、审美观、程序脚本的实现方式等，也是十分必要的。大家一起进步吧。

• 输入框的大小

  日期：2009.11.18 | 分类：网页重构, 设计制作 | 评论数：0

  开始的时候我写了个标题：输入框的高度，再一想单讲输入框的高度实际上是没法限定的，输入框的高度取决于需要输入的文本的多少、输入框的宽度这2个因素。
  　　我简单的把输入框归为以下几类：搜索、表单、地址栏、状态栏类；微博、IM工具聊天输入域、短评输入域、自我介绍；博客文章编辑、大段文字输入。

  　　对于第一类这样的输入框似乎是没有什么规则可依的，google.com、g.cn、baidu.com等等这些搜索引擎的输入框貌似都是随性而为的？
  　　好事的对比了一下：google最多允许输入2048个字符而百度最多只能输入100个字符，这也导致了google的输入框要明显比较百度宽许多；g.cn的输入框高度现在已经调整到和百度一致了而google.com还是系统默认的25px。
  　　 我的猜想是这样的：g.cn的调整在于在同等px下汉字要比英文略高一点，因而google.com采用了系统默认的25px高度，而g.cn后来意识到 这个问题调整到了跟百度一样的28px？但是就搜索引擎而言，关键词一般都不会太长为什么google.com的限度是2048个字符呢？木有想明白
  　　对于第三类大段文本的输入框实际上也没有什么可说的，简单说就是刨去必要的功能按键之后其他的区域都是为输入服务的，如果文本长度再大的话就采用下拉条的方式。这个新纸模型大概是来源于我们的纸质笔记本了。

  　　想说一说第二类短文本的输入框现象。

  　　微博类产品中twitter的输入框是长而矮的而国内的类twitter产品是相对较宽较高的。这还是符合我之前的猜测，英文与汉字的区别。
  　　关于输入文字超出限制的处理上：twitter采用的是“报警”式，显示目前可输入字符数目为“-XX”，（很BT的测试了一下，这个XX应该是可以无限大的，只是在超出10W字符之后，我的浏览器卡死…..）但是你仍旧可以继续输入；国内的Ucenter采用的是“限制”式，当字符达到上限后不允许再输入任何字符。
  　　个人觉得Twitter、meme等这样的报警式做法相对ucenter而言欠妥，当超过字数限制的时候应该果断的限制用户继续输入。相对而言Plurk采用的是改进式的“报警”，plurk会把多出来的字符标红，并提示你需要删除多少个。
  　　在这所有的微博类产品中，plurk的输入框我觉得是给我体验最好的。初始输入框是系统默认的34px，随着输入文本的增多输入框的高度随之提高，当文本继续增加到达限定的100px后出现下拉条。
  　　后来MSN很聪明的选定了这个微博产品进行山寨，不过很可惜的是没有山寨到其精神，MSN聚酷的输入框高度是固定死的，随着内容的增加框内的文本根本无法再阅读。

  　　在IM方面，QQ采用的是类twitter的模式而Gtalk采用的是类plurk的模式，不过经过测试发现，当输入的文本到达Gtalk允许的最高限度后，不会出现下拉条，这点上蛮意外的。

  　　总结：
  　　输入框的高度应该由系统规定用户可输入的文本来确定，不可能一个只允许输入150个字的论坛介绍搞一个高的出奇的输入框吧。
  　　对于有字数限制的输入框，当用户输入的字数达到上限时应该强制不允许用户继续再输入或者警示出超过的字符内容并告知删除。
  　　在英文界面和中文界面上，由于字体构造的差异会导致UI设计的差异。而这差异往往就在一个象素之间，但是真正的用户体验往往就在这一象素上！

• 由黄钻等级图标处理引发的思考

  日期：2009.11.15 | 分类：网页重构, 设计制作 | 评论数：0

  

  在实际工作中，图标类的应用非常广泛，如同数组般的等级图标更显其特殊性。下面要共同探讨的两个方向，以什么方式实现及怎么更好在贴近项目实际更好地实现并供应用。

  假设：业务的用户等级共有10个，加上大小2种视觉尺寸的图标，还有“过期未续费用户”的表现，共有38个图标需要入库供调用（如下图）。

  

  在项目的CSS框架研发中，会有几个key作为考虑：请求数、代码量、兼容性、图片文件大小、是否可并为组件模块且方便逻辑性实现。

  1. 众多不同等级的图标在不同方式的广泛应用时，是否会产生过多的文件请求；
  2. 等级图标的代码在实现上是否会使用过多的代码，且页面上真实应用的只是少量代码，从而造成代码臃肿；
  3. (x)html+css输出的图标应用到页面中，是否和页面上其它元素兼容，否则将为达到兼容目标而增加一系列代码；
  4. 如果各图标合并后，权衡项目应用的实际情况，图象文件是否会过大而消耗带宽；
  5. 图标的HTML固定，className命名中的某个数字命为作为变量，通过修改变量来达到表现效果。

  回顾之前的出现的处理方式，可以归总为三种：

  1. 前景图的插入
  这应是最原始的处理方式了，将众多单个等级的图片有序命名存放到一个目录，由前端页面应用，通过修改文件名的方式更换不同的等级显示。在实际的用户列表页面中，因为不同的用户通属不同的等级，那么，就会显示不贩等级图标，如上面假设，就会同时产生38个请求。且在项目的维护上，极易存在瓶颈。假设根据需目需要对图标文件更换存放目录或更改其尺寸大小，那么需要大面积对所有应用过的开发 template文件排查处理（更改URL，宽高定义，文件名等），很多情况难以维系在可控范围。
  2. 透明图+背景的实现
  这是Qzone项目中使用最多的一种方式，在项目的访问速度体验优化及图标实际应用中起到不可磨灭的作用，该方式后期也陆续为国内外其它网站使用。其具体实现方式是，保存一张1*1像素的透明图片，并将其设置长时间cache，因其display属性的特殊性，图片在页面布局上得心应手，且解决了多请求的问题，同时解决图片合并区域扩展维护的问题。但是，一旦在客户端cache文件队列中被挤掉，cache失败，该方式容易让这张透明的前景替位图产生洪水式的请求， 造成服务器压力和大流量。且容易继承项目中其它定义。在图标与文字的垂直对齐上各浏览器的渲染解析不一样，从而增加一些兼容代码。
  也有衍生出来空src的处理方式，如，表面上看，可以节省文件的请求，但事实上，它除了会导致大量的无效请求外，还会向日给apache不断写入错误的log，造成过大的服务端压力，同时，在非IE浏览器（如firefox)也会表现出缺省图象的红叉。

  

  3.内容标签+背景
  这里说的是带文字等内容的标签加入黄钻等级图标背景来实现，如我是黄钻7级用户，给span的左边定义一个图标，把文字向右移动一定的位置。大伙在实践中验证，这种在语义上和实现上，可以说是完美的了。但是，不方便项目代码的规划和管理，特别像等级图片这类的可以归入库的代码及应用方式。同时，标题的大小区域为不可控，在后续的维护中，更会不定期更改其区域大小，那么，就在图片的合并上存在瓶颈，难以确定一个图片该预留多大的透明区域，使之不影响到其它场景的图片应用，也可能会因为后期的维护处理不当，影响到其它标签区域的背景显示异常，造成不良的用户体验。

  

  4.标签载体+背景
  结合前几点所述，用一个标签作为图片的载体，再给它定义背景等属性，显示出相应的图标。它既可以免除用图片处理产生的流量和请求及服务器压力，又减去合并图片时所考虑的预留空间尺寸。一般标签不具img的特殊属性，既能成块状显示出图标，又能和文字等共处一行内，那么在选取的这个标签要在样式上定义得较少，不易继承样式影响表现，破坏页面的兼容和库文件的管理维护。
  在实际项目中，选用了strong作为图标的替代标签：

  

  回顾完各种处理方式后，一起来了解一下实现上的细节，分析一下文章第一张图所示，共有38个图标，且都是图形化，原始想法是，把38个图合并成一个文件。但细心看，这38个图片，有好多的相同的图形，经过整理后，得到下面这张图：

  

  除四个图标载体外，数字都是相同的，因为这里使用的是第四种处理方式，那么在图标的合并上，不用给各小图片块预留过多的透明区域。
  雪碧图处理好以后，就可以着手写代码来实现效果了。

  lv1
  lv2

  为了让标签具有img的特有属性，给strong定义display:-moz-inline-stack;display:inline-block;
  因各浏览器兼容性的原因，需要定义了两个属性，这里不禁一定要问了，为什么不选用-moz-inline-box呢？这里选用-moz-inline-stack而非-moz-inline-box的原因是：

  1. 使用-moz-inline-stack可以解决Firefox2不支持inline-block的问题，但是所有的Firefox版本对于属性为-moz-inline-stack的Element，它的First child element会继承该Element的宽度和高度，但是再下一级的Element不会再继承该属性。
  2. 这里说说一下与本图标应用无关的话题，在实际应用中-moz-inline-box会存在元素间的对齐等问题，在处理自适应宽的按钮就能遇到。虽然Firefox有一个私有属性-moz-box-align来帮助解决Element水平对齐问题，但未能预见的问题依旧不少，而相对来说-moz-inline-stack的表现更像inline-block，这点可以在Firefox3中验证出来。仅管如此，-moz-inline-stack使用时也会有一个bug，如果一个moz-inline-stack的Element外层Element是 inline属性就会使Firefox中其包含的链接不可点(和IE6的filter+position:absolute出现的BUG一样），这个可以借助position:relative;来解决。

  设置完display属性后，我们就给图标定义宽高。实际的图标处理中，完成这两步基本就OK了。但是这个图标应用较为特殊，因为它是两个背景合成一个图标的（载体+等级数），如下图：

  

  下面是两个载体的拼合示意：

  

  所以在结构上加多了两个span，一个是给等级数字的背景载体，另一个是隐藏图标替换文字。
  代码写完后，发现代码量相当的惊人，因为只在最外层定义不同的className，那么，就意味着，我们要对众多个类及其里面的标题定义：

  .gb_vip_1 span,
  .gb_vip_2 span,
  .gb_vip_3 span,
  .gb_vip_4 span,
  .gb_vip_5 span,
  .gb_vip_6 span,
  .gb_vip_7 span

  这样代码就相当臃肿，于是，改变className的定义方式，给各个等级图标最外层容器定义相同的命名，给里面数字的载体定义区别显示的命名(带数字的命名是方便逻辑实现)：

  
  lv1
  
  
  lv2