或许你已经知道“GoogleSendToPhone”这个小插件但那只支持 Chrome 搭配 Android 手机而且需要网络支持；或许各种手机助手之类的软件可以但那需要安装驱动程序和软件等等。我希望能够有轻量级方便易用高效的方法，横跨多个平台的手段来实现我的目的，于是我利用“二维码”做为信息媒介制作了这个小工具 GoQR 行动二维码生成器，把二维码做为媒介把信息片段从电脑通过手机摄像头扫描到手机，其实目前也有很多这样的网站提供这种行动二维码生成服务但或许我可以做的更好… …

二维码生成器 GoQR 下载安装地址：

Demo in PopWindow：PopupWindow（JavaScript）Beta1 …

GoQR for Chrome：http://url.cn/4f4mwx（ChromeWebStore）Beta1 …

GoQR for Mobile：http://anyliv.com/apps/goqr/（WebAPP）50% …

GoQR for iPhone：http://anyliv.com/apps/goqr/（WebAPP）Beta1 …

GoQR for Drupal：http://anyLiv.com/blog/1302（anyShare）0% …

GoQR for WordPress：http://anyLiv.com/blog/1302（anyShare）99% …

基于 HTML5 + CSS3 构建暂不能支持所有浏览器和平台 ^_^

二维码 是用某种特定的几何图形按一定规律在平面（二维）利用图形来记录数据的符号信息；可通过图象输入设备或光电扫描设备（如手机摄像头等）自动解码还原为数据以实现信息自动处理；二维码能在很小的面积内表达大量的信息并且具有识别率高抗干扰方便易用等特点；世界上常见的二维码标准有几十种，其中以日本的 QR（QuickResponse）和美国的 DM（DataMatrix）编码最为流行，目前 GoQR 只支持 QR 编码。

日本已经有 6000 万用户使用二维码，对二维码的认知度高达 96% 韩国的二维码业务也有近 2000 万用户，二维码生活成为他们的常态，我们可以通过二维码隐藏的一千多个字节而将信息无限地放大，也可以将生活的方式无限地延展。但国内只是近年才逐渐热闹起来，你或许记得新版火车票上的一坨方块图案对那就是二维码，只是中铁对其进行了私有算法所以我们无法获取上面的信息，但利用 GoQR 生成的二维码遵循国际标准，任何支持国际标准的二维码扫描软件都可以正确的解码，可能有些朋友可能不了解什么是“二维码”这里有个视频“奥迪如何动员百名员工制造世界最大二维码”演示了二维码的网址编码应用，视频中也可以发现即使是看似杂乱不整齐的二维码依然可以被手机很好的识别，另外这里有一张图片是 关于 QR 的七件事 很有意思推荐阅读。

行动二维码生成器 GoQR 可以将更多种的信息片段转换为手机可轻易识别的二维码图像信息如：名片通讯录、短信、邮件、电话、网址、普通文本等等；然后在手机上使用专门的扫描软件利用手机摄像头即可轻松获取并解码这些信息，由于二维码有很高的容错性和识别率，所以使用非常方便，有了 GoQR 你就不必像奥迪那样动员近百人来制作二维码了 ^_^

GoQR for Chrome （下载）

这里推荐一些常见手机平台上好用的二维码扫描识别工具：

RedLaser：免费，目前支持 Apple iOS 及 Android 设备，速度较快，打开应用后点击下面的闪电按钮进行扫描，不支持短信的文本部分，该应用目前已被 eBay 收购；

ScanIt：免费，目前仅支持带摄像头的 iOS 设备，识别速度飞快，操作最方便，打开应用后直接扫描即启动相应功能，但不能识别出 vCard 名片和短信的文本部分；

QrAfter：免费，仅支持 iOS 设备，可以从摄像头和相册解码，识别速度也很快，甚至支持名片和短信内容的扫描，唯一的瑕疵是有广告；

TapReader：收费但隔三差五的免费，识别率和速度都不尽人意，要保持手机平稳并离二维码稍微远点会更容易识别，但该应用可以识别由 GoQR 生成的所有类型信息包括短信内容；

Google Goggles：没错，万能的 Goggles 不仅能解数独 OCR 还可以识别二维码；

由灵动快拍开发的 “Quick拍” 目前已经支持 Android 和 iPhone 平台也即将支持 Symbian 平台，该应用甚至可以扫描火车票上的二维码来验证真伪；另外台湾的 QuickMark 也提供了他的二维码扫描工具支持包括 iOS Android WinMobile 及 Symbian 在内的几乎全平台手机型号，但部分功能需要付费。

这里还有一些由 iApps 推荐的二维码扫描工具：http://www.iapps.im/archives/19389 大家可以多尝试几个找出适合自己使用的；

虽然有部分中国移动定制的“心机”里面也预装了二维码扫描工具，但由于中国移动采用的私有标准所以对于 GoQR 生成的二维码并不能解读，而其他平台如 Android 的二维码软件我个人没有条件测试，大家有测试环境的话欢迎提供建议以帮助我改进 GoQR 这个小工具。

二维码生成器 GoQR 刚刚制作完成，编码过程中采用了 HTML5 的一些特性制作成了 WebAPP 应用，加载了几个较大的库首次启动会比较慢也不能兼容一些旧型号的手机，其二维码图片生成部分是基于 GoogleChartAPI 所以生成过程需要网络支持，还存在很多其他问题以后我会逐渐扩展平台支持功能敬请期待……

举个例子是我可以用诸如（select * from flickr.photos.search where text=”apple” limit 9）的语句得到 flickr 上关于 apple 的 9 条数据，返回结果为 XML 或 JSON 而引用方法只是将以上语句做为参数即 URL 的一部分直接向 YQL 请求即可，当然看似与 xQuery GQL SimpleDB 等查询类似却潜力无限，试想既然可以拓展到跨域及跨服务，那么无论你需要地图支持、搜索支持、图片支持、天气甚至股票等等将均可以从 YQL 获取而不需要自己去学习一套又一套的私有接口，雅虎 YQL 为我们获取数据和内容提供了一个“以不变应万变”的中间层……

雅虎 YQL 模型

YQL：http://developer.yahoo.com/yql/

YQL Guide：http://developer.yahoo.com/yql/guide/

YQL Console：http://developer.yahoo.com/yql/console/

以上是雅虎 YQL 的模型及项目网站及手册和调试地址，随着 Web 2.0 服务的越来越多，各个网站所提供的开放 API 也越来越多，开发者如果需要借助这些 API 进行开发就必须重新学习及掌握这些 API 需要地图服务就得看看地图的 API 文档需要搜索支持就又得去学习搜索的 API 等学会了 Google 的又发现需要 Twitter 的，而雅虎 YQL 就为我们提供了解决这样一个问题的中间层，这对于开发人员特别是前端开发人员将意义重大，下面是来自阿里 UED 博客上的一个简单示例：

由于篇幅我隐掉了查询语句中的 where 和 limit 部分以帮助大家简单理解 YQL 的一种用法，在新版的 YUI 3.2 中已经加入了 YQL 的组件可以通过 YUI().use(‘yql’, function(){}); 来直接进行调用，可以看得出来使用还是非常方便的，另外你甚至可以向 YQL 提供你自己的数据产品以拓展 YQL 的能力，一旦被 YQL 接纳，那么你的数据将会为千万开发者所用。

再举一个简单的例子：比如我想抓取某个网页的主要内容部分，很多人会采用正则按照特定的规则来摘取页面的 html 代码，但我是个极其喜欢偷懒的人，我希望直接抓出其在自己的 feed 里面的主要内容，通常在 feed content 里的内容都是某个页面的主要内容如下：

SELECT * FROM feed
WHERE url IN (
    SELECT href FROM html
    WHERE url="http://anyLiv.com/blog/1313"
    AND xpath="//link[@type='application/rss+xml']" LIMIT 1
)
AND link = "http://anyLiv.com/blog/1313"

（查看运行结果）

我用了一个子 SELECT 来获取这个页面的 feed 地址，有点绕性能也不好但无所谓交给 Yahoo! 处理就好，因为在 YQL FEED 表里 url 是唯一的必选参数，所以我得先知道当前页面的 feed 地址是什麽然后再用地址去筛选一下获得页面的 content 还是相当方便的！

雅虎 YQL 查询语言通过提供类 SQL 语法消除了开发人员学习大量 API 的麻烦，节约了开发时间和学习成本，依托雅虎 YQL 的稳定和高效，使更多的开发者拥有无比强大的数据获取及计算能力，这将帮助我们更方便快捷高效的创造更多更好的互联网产品……

拓展阅读：阿里 UED 关于 YQL 介绍

我们有了可靠的用户体验要素模型，在具体的实际操作中可以去很好的运用这个模型运用这些要素，当然成立由专注于各个方面专家组成的小组行之有效例如：腾讯 ISD 和 淘宝 UED 等等，不过多数情况下考虑到有限的资源，小团队通常没有能力去组建此类专家小组，但大部分情况下有限资源的小团队其实也能达到相似的目标，甚至能够产生比一个大团队更好的结果。

用于解决用户体验问题的方法成功与失败归根结底只有两点差异：了解正在试图解决的问题 了解解决之后造成的后果。例如大家已经发现主页上的某个按钮是个问题但是问题具体是尺寸太大还是颜色不协调（表现层）又或者是放置的位置不对（框架层）甚至是按钮的功能非用户所预期的（结构层）那样？对于网站做出的任何一个修改都将连锁的反应到之后的各个层次，某个设计非常好的导航可能完全不适合结构层的另一部分。

大部分时间对于用户体验问题的决策被体现在几种情况：由现状决定（Design by Default）由模仿决定（Design by Mimicry）有领导决定（Design by Fiat）大家应该都有同感 ^_^

面对用户体验中需要解决的纠缠不清的小问题，有时是会让人非常沮丧的事情，有时某个问题的解决方法会让你重新考虑之前认为已经解决的问题。很多时候你需要在不同的问题解决方法中进行评估和取舍，多数情况下我更倾向于满足 80% 用户的需求当剩下的 20% 用户与开发或执行成本严重冲突的时刻，当然在用户体验中所犯的最大错误也是 “以节省时间或金钱的名义对用户体验敷衍” 最后你将发布一个明知道很垃圾但却没有机会去修复的网站。

经过深思熟虑的设计可能会在短期内话费大量的时间，但他将在未来一个更长时期中节省更多的时间，中国有句俗话叫“磨刀不误砍柴工”说的就是这个道理。多数情况下，上一级层面中的错误可以被低一级的成功所掩盖，相似的如果在上一级做出的正确的决定是建立在低一级层面错误的基础上，那这些决定则毫无意义。一些漂亮的网站之所以失败是因为完全不可用，过于关注视觉设计而排除其他用户体验要素使得很多网站宣告破产，并使其他公司完全不理解为什么总是被网站问题所困扰。

还有 心态 对于整个处理用户体验过程也起到非常重要的作用，每一次对于用户体验的开发过程都可能受到其他因素的调整以适应时间、金钱、人力等等。如果没有时间去收集用户反馈？也许可以想想办法拿到客服的日志或反馈邮件；负担不起可用性实验室的费用？那就找几个朋友同事甚至家人来做一些非正式的测试。用户体验的过程更像是 “马拉松” 而不是短跑了解比赛的类型才能更好的设计策略赢得比赛。

在网站开发的一开始就从完整的用户体验出发，每一件与用户体验有关的事情都经过有意识的明确的决策，最后得到的必然是一份有价值的资产。

这是我的《用户体验的要素》最后一篇读书笔记，在结构上有点混乱只把我认为非常重要的一些要点整理下来，记得我刚刚学习网络技术时 OSI 七层模型能更好的帮助我去理解网络但实际操作中则更多的使用简化版的 TCP/IP 四层模型或者 CISCO 三层网络模型，对于用户体验也是如此，我们有了很好的理论依据再加上好的心态，相信每个人都可以让自己的网站同时满足战略目标和用户需求……

示例将仅仅针对 NODE 文章节点页面做 SEO 优化演示，其他页面大家可以以此类推，具体需要将以下代码放置于当前使用主题模板的（node.tpl.php）文件中：

if($page != 0){
		//首先判断是否为节点单页而非文章列表页；

	$keys = $info= NULL;
	$info = substr(filter_xss($node->content['body']['#value'], array()), 0, 240);
		//过滤节点内容部分的特殊字符并截取前 240 个字符做为摘要部分；
	foreach($node->taxonomy as $term){ $keys .= $term->name; }
		//遍历节点的术语标签并存入数组备用；

	drupal_set_html_head('');
	drupal_set_html_head('');
		//利用 Drupal 函数将 html 代码加入页面 head 标签；
}

示例中直接使用术语表 taxonomy 中的术语标签 term 做为网页的 keywords 页面关键字，然后使用节点 body 部分的前 240 个文本字符做为 description 页面摘要部分，当然你可以根据具体情况自行调整，如果你是 SEO 控的话大可以把节点的 log 字段好好利用起来做为摘要部分自行录入，也可以单独创建新的 CCK 专门用于 SEO 都是可以的，只是在拾取字段的时候调整代码即可。

推荐阅读使用的几个函数：

drupal_set_html_head：用于在当前页面的 HEAD 标签内添加 HTML 代码；

drupal_set_title：用于修改当前页面的 title 标签；

drupal_set_breadcrumb：用于修改当前页面的面包屑数组；

这里主要想说明的是 Drupal 的很多函数都是可以在主题模板和模块插件中共用的，而且诸如 drupal_set_html_head 等等函数不仅仅在模板的 page.tpl.php 中管用在其他有效的 tpl 文件中也都是可以使用的，记得我刚刚接触 Drupal 的时候一直苦恼与如何在节点模板区域控制整个页面的 title 标题和 breadcrumb 面包屑直到后来研习 Drupal 的模板渲染引擎机制才恍然大悟……

什么是前端工程师：

互联网前端工程师或 WEB 前端开发工程师，虽然是从网页制作演变而来但名称上有很明显的时代或版本特征，网页制作可能是 Web 1.0 时代的产物那时网站多为静态的 HTML 页面用户使用网站的行为也以浏览为主 2005 年以后互联网进入 Web 2.0 时代各种拥有类似桌面应用的 Web App 大量出现如 Gmail GoogleReader 等等网站的前端与交互由此发生了翻天覆地的变化，网页不再只是呈现单一的文字和图片，各种富媒体让网页的内容更加生动而软件化的交互形式为用户提供了更好的使用体验，这些都是基于多种前端技术紧密协作实现的。

前端开发工程师，简单的说就是将设计师的图稿变成在浏览器里真真正正呈现的 HTML 页面供用户点击操作交互，这个工作可以简单到用 Photoshop Fireworks 点几下鼠标直接导出页面；也可以复杂到考虑每个标签的语义，整体的性能，浏览器的兼容，用户的交互，搜索引擎的优化等等等等；技能的基本要求是熟练使用图形图像处理工具，精通 HTML CSS JavaScript 前端语言，最好了解一种服务器端语言如 PHP 等等；这就是为什麽我题目写的是一位 优秀的网站前端工程师 带来的价值，但寻找一位优秀的网站前端工程师相当困难，因为前端的几种技术都是入门易深入难的，多数人很容易上手但精通很困难再加上公司的不重视等等原因导致前端工程师水平差异较大从而普遍待遇较低，进而更多人不愿意去学习需要多种技术相辅的前端开发，因为可以花更少的精力学习一门后端程序然后，就等着恶心循环吧……

一个公司反面教材：

举一个我朋友所在公司的例子，该公司还算有点规模老总的目标是打造一个某某行业的门户网站，负责网站开发的部门有 8 名服务器端开发人员和 3 名网页设计美工，每位设计负责一个栏目的页面设计，然后交给销售经理过目审核（这点最戏剧）后独立完成 HTML 静态页面，最后交给程序开发人员嵌套 JS 和服务器端程序，且先不说没有前端开发工程师一个以互联网产品为主业的公司居然没有一个合格的互联网产品经理而是由销售部经理来提各种需求其直接结果就是：我觉得某某网站的某某功能很好用我们要加一个另外某某网站的动画很漂亮我们也要用……

网站前端工程师这个职位在绝大多数公司甚至是多数以互联网业务的公司里面都没有设置，从设计稿图纸到静态页面的工作通常由设计美工负责，但绝大多数美工都更倾向于设计方向对于 HTML + CSS 通常只能实现而对于语义规范标准化、浏览器兼容、网页性能、搜索引擎优化等等内容并不具备优势更不用说对于交互非常重要的 JavaScript 则通常交给后端程序员，但多数网站后端程序员通常都不会把 JS 当作是一门真正的程序语言来看待，更不用说使用 JS 去控制 DOM 和 CSS 这需要更多前端的控制能力，需要什么效果从网上搜一段直接粘贴到页面里，而这将直接导致各种问题隐患叠加。

前端工程师的价值：

我们知道互联网产品在用户体验上有两个非常重要的基本要求即 交互 和 速度 当然还有设计和其他的要素暂不在本文讨论范围内，然后我就针对这两点简单分析一下优秀前端工程师所带来的价值：

交互：对于互联网产品来说用户首先所接触到的就是前端页面而不是服务器端冷冰冰的程序，任你有再强大的功能如果用户操作使用起来非常复杂肯定留不住用户。最贴切的例子就是拥有全球最多访问量的 Google 谷歌搜索引擎，谷歌在全球有成千上万台服务器集群但前端也仅仅是一个简简单单的文本搜索框，再者就是目前众多类似于桌面应用的 WEB 应用之所以能够营造良好的用户交互体验很大程度上依赖于 JS HTML CSS 三种技术的紧密结合如 AJAX 技术而整个交互过程中我们需要服务器端提供一定格式的数据即可，更多的是依靠优秀的前端工程师多年的经验和对于这三种技术的结合应用，当然这并不是故意去贬低服务器端的重要性谁离开谁肯定都不能成功，正是这种 把复杂留给自己 把简单留给用户 的交互模式为优秀的互联网产品赢得了用户和价值，在国内互联网产品严重同质化的时候任何对于用户体验和交互所做的努力都将使你的产品大大超越对手；

速度：长期以来我的很多客户都存在一种误解即网站要想提速会从这些方面考虑：服务器端代码优化（代码）增加服务器配置（硬件）购买分布式网络（网络）等等；但就我个人目前的经验来说这些做法对于超过 99% 的网站来说收效甚微：就代码和硬件上来说除非是极其复杂的应用型网站否则单程序和数据库对于网站速度的影响并不大因为多数门户网站通常都已经静态化了；至于网速我们目前仍旧困扰在“最后一公里”还有“运营商互通”问题上即使服务器端有 1TB 的带宽对于绝大多数用户也只有 80Kbps 所以作用甚微。但如果是从前端代码优化就可以很容易起到事半功倍的效果，据本文结尾来自 涂雅 的一篇分析报告称，开心网（KaiXin.com）首页可以压缩精简将近 300KB 仅仅一个简单的首页这 300KB 每年可为开心网节省 5-8 万人民币的流量费用想想开心网有多少个这样的页面。与其一些企业把大量的钱花在购买大服务器高带宽和 CDN 分布式网络流量上不如花点小钱请一位优秀的 WEB 前端工程师，因为你的服务器再快带宽再高用户的带宽是不变的，如果超过用户的带宽上线任何努力都是毫无意义的；

其他：当然除了交互和速度以外互联网前端开发工程师还可以为你带来很多附加的价值其中最为吸引的就是 SEO 搜索引擎优化，对于网站用户首先接触的是前端页面搜索引擎也不例外，没有经验的美工会大量使用 DIV 或 TABLE 标签排版导致整个页面内容没有主次轻重之分，你可以模拟搜索引擎爬虫在禁用 CSS 和 JS 之后如果看起来一塌糊涂没有主次那么对搜索引擎来说也是如此，一名优秀的网站前端工程师需要考虑到每一个 HTML 标签的语义合理的使用 Hx 标签 ul ol dl 标签等等让你的页面即使禁用 CSS 也能保持良好的结构，同样是两栏的页面将重要的内容放到页面靠上的位置，准备参与交互的页面元素如何放置可以结构最优化，甚至是浏览器对于 CSS 渲染性能的考虑等等，这些小的细节累加起来将对网站整体起着重要的作用。

我们知道将近 3 亿用户的世界第一大 SNS 社交网站 facebook 所有的设计师被要求编写 HTML CSS 甚至是 PHP 等代码，设计师往往在简化方面做的过头而服务器端工程师往往会在功能上做的过头，我们需要一个角色来实现必须的衔接如同内存之于 CPU 和硬盘，在 facebook 会给与设计师充裕的时间来编写代码 facebook 认为：拥有一个能写代码的设计师能够了解细节并快速执行在 Design at Facebook 一文中作者曾多次提到 facebook 要确保每个设计师具有足够的技术来编写代码，这里提到的设计师其实都是具备优秀的前端开发能力，但这样的设计师寻找起来无异于大海捞针……

如何找到优秀的前端工程师：

大公司可以有具备优秀前端开发能力的顶级设计师可以有专门用于用户体验的 UE UI 部门；而小公司的话考虑到成本可以没有这些，也行会请一些经验并不丰富的美工甚至后端程序员，但请尽可能请一位优秀的前端开发工程师，这样可以为你的网站省下非常高的费用，减少带宽和服务器，甚至是节省数个后端程序员。当然 WEB 互联网前端工程师同时也是最不容易找到合适人选的职位，要想寻找到真正优秀的前端工程师，首先要求负责面试及招聘的主管对前端非常的精通，但目前很多主管都是服务器端技术出身，而后端人员往往会轻视或者忽略前端的工作，文章后面附带了一份前端工程师的面试题目及如何寻找优秀的程序员的文章，考察的非常详细希望能给负责面试的主管一些启发……

推荐阅读：

如何寻找优秀的程序员 from SteveHanov

两个重要而又容易被忽视的角色 from 涂雅

开心网网站分析报告 from 涂雅

一份前端工程师面试题目 from 贺敏

其实一个简单的道理：无论服务端的硬件多么强大速度多么快捷，前端用户的性能是你无法改变的，前端用户的带宽是你无法改变的，前端用户的眼光是你无法改变的，前端就是要善于解决这“最后一公里”的问题……

开启谷歌 Google Chrome Apps 应用功能

目前即使是开发版本的 Google Chrome 仍需要添加启动参数 –enable-apps –apps-panel 来开启浏览器应用功能和一个类似 Windows 开始菜单功能的 Chrome Panel 新标签页面板。更新：目前 7.0 的开发版已经不需要额外的参数即可启用 apps 模式……

随开发版 Chrome Dev 提供的几个 Google Apps 应用

目前的开发版中 Google 已经提供了三个 Chrome Apps 的源文件位于浏览器的安装目录下 \Chrome\Application\6.?.???.?\Resources\ 里面有三个 Apps 的源文件包括 Gmail 邮箱 Calender 日历 Docs 文档 三个谷歌云服务开启 ChromeApps 功能之后再扩展页面打开“开发人员模式”就可以使用“载入正在开发的扩展程序”来分别载入这三个示例 Apps 应用非常简单其实就是提供一个地址入口而已，但未来的扩展性则非常让人期待；

开发一个简单的 Google Chrome Apps 应用

既然提供了三个示例源程序，我们可以依葫芦画瓢般的制作一个属于自己的 ChromeApp 例如我经常使用的 GoogleReader 阅读器需要做的是准备一个小图标用于在应用选项卡上显示，准备一个 manifest.json 做为应用的入口清单至于 manifest.json 的语法可参考 Chrome 插件的开发文档或者随 Chrome 提供的几个示例应用例如：

{
  "name": "Google Reader", "version": "1",
  "icons": {"128": "128.png", "24": "24.png"},
  "permissions": [ "notifications" ],
  "app": {"launch": {"web_url": "https://www.google.com/reader/"}}
}

这样我的第一个 Hello World 式的 Chrome Apps 就制作好了，当然里面的地址可以是本地地址的也包括 JavaScript 和 CSS 这样看来制作浏览器应用的核心技术当然是 HTML + CSS + JavaScript 了最好是 HTML5 和 CSS3 使用 webkit 和 v8 的 Chrome 对于这两项新标准非常在行，哈哈这明显要比制作 Firefox 的插件要简单的多也更适合互联网工程师的参与要知道写 HTML 还是比写 C++ 的要多的多吧 ^_^ 下面看看截图的效果：

应用的页面看起来和网页没什么区别，我们本来就是要减少两者的区别，这种开发模式当然可以拓展到 WebQQ 甚至是植物大战僵尸等等，其实微软早在很久以前就提供了以 hta 格式文件来运行 html 的应用《如何利用 HTA 构建应用》只是当时的云服务还远远不够成熟而且 hta 将很多东西都限制的很死板，而现在借助 HTML5 新加入的大量功能我们可以自由的实现很多有意思的浏览器应用包括游戏（如 Google.com/PacMan 等）更多开发资源可以访问 http://code.google.com/intl/en/chrome/apps/ Google Installable Web Apps 即谷歌可安装网页应用的项目页面……

一个 Chrome Apps or Extensions 开发完成之后是不是想分享给其他朋友使用，当然最好是提交到 ChromeWebStore 线上应用商店供所有的 Chrome 用户使用，这里有一个视频详细描述了如何提交自己的 Chrome 应用及扩展到 Chrome线上商店，包括设置免费及付费模式，而且 ChromeWebStore 提供多种付费模式而非 AppleAppStore 那种单一的付费模式：

如何上传你的应用到 Chrome 线上商店：How to upload your app to the Chrome Web Store

从视频中可以看出上传是非常方便的，而且期间可以通过选择已经通过 Google 站长工具验证过的网站来为插件打上验证标识。

函数语法：

Menus SubPanel：http://codex.wordpress.org/Appearance_Menus_SubPanel

wp_nav_menu：http://codex.wordpress.org/Function_Reference/wp_nav_menu

register_nav_menus：http://codex.wordpress.org/Function_Reference/register_nav_menus

组件模式：

考虑到目前绝大多数主题模板均不支持新版的菜单系统所以 WordPress 3.0 添加了一个专门为菜单系统使用的 Widget 小组件叫 CustomMenu 定制菜单，对于不支持新菜单系统的主题使用者仍然可以在后台 外观 – 菜单 页面创建一个新的菜单，然后使用 CustomMenu Widget 加载到页面的小组件区域显示，正式版加入的这个小组件使得目前所有的主题无需任何修改即可平滑的支持新版菜单系统，之前在 RC 版则需要为主题添加 add_theme_support(‘nav-menus’) 语句才能开启菜单系统，但使用组件的缺点是显而易见的，使用者只能将菜单放置到小工具的位置以固定的结构显示，这个时候其实和之前的链接 Links Widget 小组件并没有什麽区别甚至可定制性更差，所以我们需要对主题模板做一些修改使其支持最新版的 WordPress 菜单系统。

菜单简介：

之前 WordPress 的链接功能虽然可以实现部分菜单的功能，因为我也发现很多主题开发者使用链接功能来使用户可以方便的定制自己的导航和菜单，在新版 WordPress 中则提供了更为自由和先进的菜单系统，就像我之前所说的他为主题开发者和模板使用者直接架起了又一座友好的桥梁，使开发者不用为了一个菜单或导航的变动而修改源代码，用户可以根据自己的情况随时 添加 删除 排序 层级 排列菜单系统，更可以直接在后台页面设置一些菜单属性如 打开方式 菜单描述 链接关系 等等，而这一切只需要添加很少的代码即可实现……

基本运用：

例如，我们在 WP 后台的 外观 – 菜单 页面添加了一个新的菜单其名称为 “菜单示例” 然后在主题模板中就可以使用 wp_nav_menu(‘menu’ => ‘菜单示例’) 来直接调用这个菜单不过具体操作中尽量不要使用中文，因为默认该函数会以菜单名称做为 class 或者 id 的一部分，虽然可以使用参数 container_class 来覆写最外层的 class 但下一级的 ul 仍会引用菜单名称为 id 的一部分。

高级应用：

但显然该方式并不灵活，因为我们的开发者需要告知用户创建菜单的名称是什麽，双方必须有一个约定期间如果有任何差别菜单都不会被正确的显示，这可不是我们所需要的于是更高级的应用则是使用 register_nav_menus 函数为主题注册一个菜单位置（Theme Locations）然后由用户来觉得将哪个菜单什么样的菜单放置到这个主题位置中去，这有点类似 drupal 中的区块（block）概念，这是一个平滑友好的接口：

首先，需要在主题中注册声明菜单位置：需要在你的主题模板 functions.php 中添加一个新的注册语句 register_nav_menus 该函数接收一个数组参数做为注册的菜单项，例要添加两个菜单一个用于导航一个用于页脚链接如 register_nav_menus(array(‘topMenu’ => ‘导航’, ‘subMenu’ => ‘页脚’)) 其中参数数组的下标用于在内部程序调用数组内容则显示给后台用户，添加该语句之后就可以在后台 外观 – 菜单 界面看到 Theme Locations 选择区块了，里面也可以看到我们新添加的这两个菜单位置一个叫导航另一个页脚；

然后，需要在主题模板文件中调用菜单：开发者可根据自己的需求在需要显示菜单的位置使用 wp_nav_menu 函数调用输出由用户自行配置的菜单如要输出导航位置的菜单可使用 wp_nav_menu(array(‘theme_location’ => ‘topMenu’)) 使用参数 theme_location 来指定前面声明的菜单位置，这样就建立了一个很好的中间层帮助用户和开发者处理菜单链接的问题。

补充说明：

另外 wp_nav_menu 也支持很多参数可供调用如：参数 container_id 和 container_class 用来定义输出的菜单外层标签属性；参数 container 用来定义菜单外层的 HTML 标签类型如 div 等等；参数 menu_id 和 menu_class 可用来定义菜单 ul 的 class 属性；参数 echo 可控制返回 return 还是直接输出我觉得 WP 的多数函数都应该添加该参数或者都改为 return 返回方式就像 drupal 一样返回值而不是输出；另外还有很多参数可从本文开头提供的链接查询。

下面提供的方法仅针对 Drupal 5.x 另外对于 Drupal 6.x 可使用新版的 ckEditor 做类似修改也很容易实现，另外下文提到的 fckEditor 模块是指从 drupal.org 下载的模块文件而 fckEditor 编辑器是指从 ckEditor.com 下载的编辑器文件，读者需要仔细阅读区分：

1、下载模块：如果项目中只需要一种编辑器就足够，而且也并不需要 IMCE 来管理每个用户的文件，我们就可以不使用 WYSIWYG IMCE 这两个功能过于强大的模块了，只需要下载并启用 fckEditor 一个模块即可，具体安装方法不再详述在 fckEditor module for drupal 这里有详细的描写，要点是要将下载的 fckEditor 编辑器放置到相应 fckEditor module 模块目录之下，然后就可以进行下面的修改操作了；

2、开启上传：默认的 fckEditor 模块需要搭配 IMCE 才可以实现图片的上传功能，这里需要做一些修改来开启 fckEditor 编辑器内置的 FileManager 来负责上传操作从而代替 IMCE 模块，具体修改方法在 fckEditor 模块下面的 README.txt 也有详细的说明我这里简单翻译一下要点步骤。在编辑器中的 /modules/fckeditor/fckeditor/editor/filemanager/connectors/php/config.php 文件中添加一句代码 require_once “../../../../../filemanager.config.php”; 加到最前面即可然后设置该文件后面的 $Config['Enabled']=true; 还要设置 $Config['UserFilesAbsolutePath']=’files’ 该值为你的文件上传目录对于 Drupal5 通常是 files 需要注意是该目录为相对于站点根路径的目录，修改之后即可在 Drupal 的 admin/settings/fckeditor 中配置 file browser settings 了非常方便；

3、优化交互：照上面修改之后就可以只使用 fckEditor 一个模块来负责编辑器和文件上传功能，但我的用户在使用之后仍然觉得有些繁琐体现在，多数情况下用户都在上传新的图片，而点击编辑器的图片按钮出现的却是“图像属性”和“浏览服务器”上传功能，这会无形中引导用户走向类似 IMCE 的操作方式（看这里）所以最简单的修改是将“上传”选项卡移至首选功能具体需要修改 fck_image.js 文件中将 dialog.AddTab(‘Upload’,FCKLang.DlgLnkUpload) 连同前面的 if 语句拿到 dialog.AddTab(‘Info’,FCKLang.DlgImgInfoTab) 语句之前然后在后面的 window.onload 函数中写入一句 OnDialogTabChange(‘Upload’) 即可实现窗口启动时自动切换到“文件上传”功能以减少点击和误导，具体文件位置比较深自己搜索一下；

4、再次优化：如此修改之后上传文件已经变的相对容易了，但有用户仍反应是否可以在选择文件之后直接触发上传而不用再点“上传到服务器”呢我估计是受了 swfUpload 的影响，当然这也很容易解决需要修改上面同一位置的 fck_image.html 文件中文件选择框 input id=”txtUploadFile” onChange=”document.getElementById(‘btnUpload’).click()” 添加一个事件即可具体是在 file 选取之后由程序触发上传按钮，当然事件改为 this.form.submit() 也是可以的，但那样就没有上传动画了。

5、进阶优化：经过上面这些修改已经基本可以满足目前我的用户需求了，但这里其实可以拓展一下例如还可以将 upload 表单和 image info 表单放到同一个弹出层里面类似腾讯在某些页面的编辑器，这样就可以一劳永逸的解决所有问题，我这里就不提供修改方法了读者可以自己摸索一下。

开源程序的优点就是他的任何内容你都可以看到并可以根据自己的需求修改，这也是我喜欢 HTML CSS JavaScript 喜欢 Drupal WordPress 的原因之一，我知道有人会觉得 Image Assist 模块也会比较容易上传但 Image Assist 每上传会占用一个新的 node 这与 WordPress 的上传机制类似，我个人并不太喜欢，如果你有其他更高明的方法欢迎分享一下！！

下面是简单的实现步骤，目的是传递 drupal 的 basePath 给 JavaScript 使用，当然这在 Drupal6 中是已经默认传递的，大家可以举一反三来使用：

//首先是在模块文件或者是主题的 template 文件中加入如下代码：
drupal_add_js(array('basePath' => $GLOBALS['base_path']), 'setting');

//然后你会发现在页面的 script 输出部分会有以下信息输出：
Drupal.extend({ settings:{"basePath": "/drupal/"} });

//这样你就可以在页面引入的 JavaScript 文件中直接调用该对象了如：
alert(Drupal.settings['basePath']);

非常方便主要起作用的是 drupal_add_js 的第二个参数 setting 他告诉 drupal 系统这段 js 是设置类型的数组，其他使用方法请访问 drupal 的线上 api 函数手册。其实在只传递一个变量时这种方法带来的优势并不明显，但如果有若干个模块需要传递多个变量给 JavaScript 的时候 drupal_add_js 函数会自动将他们合并到一起在页面头部输出，只调用一个 Drupal.extend() 方法为 Drupal 对象增加额外的值，也希望大家在写模块或模板的时候尽量遵循 Drupal 提供给我们的现有的 api 这将让你的工作事半功倍同时也让你的项目更容易维护代码更具有可读性。