举个例子是我可以用诸如（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 的模板渲染引擎机制才恍然大悟……

如果是实现简单的 Drupal 根据用户客户端浏览器设备切换移动版非常容易只需要主题模板在站点的 setting.php 配置文件中添加及修改以下代码：

$mobi = strpos($_SERVER['HTTP_USER_AGENT'], 'iPhone') || strpos($_SERVER['HTTP_USER_AGENT'], 'Android');
$conf = array('theme_default' => $mobi ? '移动版主题名称' : '普通版主题名称');

首先从客户端浏览器的 UA 来判断客户端的具体类型，这里只做了 iPhone 和 Android 的判断其他可自行添加，值得一提的是 iPhone Safari 和 Android Chrome 使用的浏览器核心均为 webkit 也是目前对于 HTML5 + CSS3 支持的最好的浏览器核心，在页面渲染上几乎没有差别大可做统一处理。在当前站点设置目录的 setting 控制着当前站点的所有基本设置信息 $conf 可以用来配置一些默认的属性当然包括用户的主题模板。

由于 iPhone 和 Android 内置的 Safari 及 Chrome 浏览器已经具备几乎全部的富因特网功能，所以需要考虑用户也有使用完整版页面的期望及可能也就是为此多数移动版站点也同时提供切换到完整页面的链接，当然 drupal 中也可以通过修改 $user 对象来实现这一需求 Drupal 中用来控制用户当前主题模板的变量字段为 $user->theme 当然可能需要开启用户多主题支持，然后就可以用程序为 $user->theme 赋值来修改用户当前的主题模板核心代码如下：

function setheme_setheme($theme = NULL){
    global $user;
    user_save($user, array('theme'=>$theme));
    drupal_goto('');
}

上面提供的只是核心函数的代码这里用到了一个 drupal 的内置函数 user_save 可以用来向 $user 对象赋值非常方便，当然需要写成一个小的模块才会完整最好用 hook_menu 定义一个菜单路径例如 /setheme/ 这样就可以通过 /setheme/garland 或者 /setheme/minnelli 将打算切换的主题名称传递给这个函数达到通过链接切换主题模板的目的，最好切换完成后使用 drupal_goto 返回到需要的页面即可，当然这样做还有一些问题例如对于缓存的处理……

什么是前端工程师：

互联网前端工程师或 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 一样返回值而不是输出；另外还有很多参数可从本文开头提供的链接查询。

安装过程

整个安装过程与之前的版本并没有太多区别，唯一的改进是终于可以自定义超级管理员的用户名和密码了，不用使用默认的管理员名称和随机密码登录再修改那么麻烦了。

界面调整

新版的 WordPress 后台管理界面也做了小小的调整，原来位于“工具”菜单下面的的“升级”功能被挪到了“控制面板”下，主题管理页面的版式有了小小的改进，选项卡式的页面确实层次清晰也使用方便重要的是便于展示主题的缩略图，但安装插件的页面仍是旧的一个“Add New”按钮后期应该也会有所改变。

默认主题

新版 WordPress 只附带了一个默认主题叫 Twenty Ten 该主题支持 WP 3.0 的一些特性：可更换头部图片 颜色 背景等，特别的是支持 WordPress 3.0 中新引入的 “Menu” 菜单系统，这使得没有 HTML CSS PHP 经验的用户也可以方便的定制博客上的链接菜单。

菜单系统

新版 WordPress 引入了一个新的菜单系统，该系统可以使用户方便的修改定制模板中涉及菜单和链接列表的内容条目，新的菜单系统为 WordPress 用户和主题开发者之间建立了又一座友好的桥梁，明天我会专门针对 WordPress 3.0 的菜单系统做一个详细的说明和代码演示。

其他改进

其他的一些改进多是 WordPress 原来已经有的一些功能在 3.0 新版系统中进行的优化和完善如：用于定制内容类型的 register_post_type 及用于定制分类内容的 register_taxonomy 其实在之前的 WordPress 中也有这里进行了完善，另外 WordPress MU 也在 3.0 版本并入主分支但默认并没有开启，这里我也不推荐个人站点开启该功能实在没有必要，如果指望用 WordPress MU 做一个 Blog Service Provider 的话虽然技术上可以但市场运作成功的概率几乎为零，另外之前版本的 WordPress 只支持 wp.me 的网址缩写在新版中可支持个人域名的网址缩写，暂时我只有看到有上面这些改进或变化，后续随着运用和开发的深入我会继续更新本文……

新版 WordPress 视频：官方新版 WordPress 介绍视频

新版 WordPress 下载：http://wordpress.org/latest.zip（支持下载工具）

一、结构层（Structure）：虽然网页上到处都是各种各样的选项卡但从结构层即 HTML 上主要有两种写法：普遍采用的是第一种即将用于触发动作的所有选项卡的标题写到一组，再将该选项卡中所有页的内容写到一组并保持两者对应顺序一致，然后使用 JavaScript 判断触发点击或划过的是第几个标题然后显示与该标题相应的第几个内容即可，该结构因为代码比较简单 JS 也容易加所以被多数网站采用；而我个人则倾向于第二种结构即每一个选项卡页的内容均单独编码，然后额外添加一个容器用来展示被选中的选项卡内容，虽然该方法的代码量会较第一种更多及复杂但可以保证在客户端即使禁用掉 CSS JavaScript 也仍具有很好的可读性，而同样的对于搜索引擎优化（SEO）更是如此，该结构可以更为清晰的告知搜索引擎你的内容组织方式及相互关系其代码如下：

//首先是多数站点采用的写法：

标题一标题二标题三


内容一

内容二

内容三



 //如果用户禁用 CSS JS 内容将失去相关性及联系性

//然后我自己比较推荐的写法：


标题一
内容一
标题二
内容二
标题三
内容三



 //对于搜索引擎和禁用 CSS JS 的客户端依然可以保持良好的结构性

二、表现层（Presentation）：然后就可以为上述 HTML 代码添加 CSS 样式了，其目的很简单就是将选项卡修饰一个使其更像一个选项卡吧，这里仅提供第二种结构写法的样式代码关键部分，其他如果需要更多的修饰可以自行添加，具体代码如下：

.itab { }
.itab dl { margin:0; padding:0; }
.itab dt { float:left; padding:5px; cursor:pointer; }
.itab dt.active { }
.itab dd {/* display:none; */} /* 这个隐藏也建议由 JS 来实现如果客户端仅禁用 JS 却支持 CSS 的情况下不影响 */
.itab .tabBody { clear:both; }

三、行为层（Behavior）：最后当然是起重要作用的行为层了，主要对用户的一些操作如点击划过等触发一些事件从而改变现有的结构层代码达到选项卡的目的，具体代码如下：

$('.itab dd').hide();  //这里可以交给 CSS 隐藏但那样支持 CSS 不支持 JS 的客户端就郁闷了；
$('.itab').append('


');
$('.itab dt').click(function(){
	$('.itab .active').removeClass('active');
	$(this).addClass('active');  //用于辅助 css 修饰的 class 可区分哪个是当前点击的标题；
	$('.itab .tabBody').empty().append($(this).next().clone());
}).eq(0).click();

我这里偷懒用了 jQuery 首先是隐藏掉原来已经有的各个内容 dd 然后为整个选项卡 itab 最后添加了一个名为 tabBody 的容器用来存放要展示的内容，接着就可以为标题绑定事件了这里选了点击（click）当然你可以可以使用划过（hover）等等，当鼠标点击标题 dt 的时候先清空容器 tabBody 的内容，然后将当前被点击的标题 dt 下面的内容 dd 克隆一份放置到容器 tabBody 中，过程非常简单，另外用于操作 class 的两句是为了方便 CSS 修饰当前被激活的标题。

这样结构的选项卡其优点是很明显的，可以很清楚的告诉搜索引擎和关闭 CSS JS 的客户端你的内容结构层次，当然代码上特别是 JS 代码上会稍显复杂但这样的成本我个人认为是非常值得的，也有人会说现在哪还有不支持 CSS 和 JS 的客户端呢，其实我很多时候也有过这样的想法，但好在当我看到自己的项目在一些掌上浏览器的浏览效果的时候及时否定了自己的想法……