因为刚看过亚东的教程和这个有点相似，所以就自己琢磨了一下写了一个仅用到一小段的JS就搞定了。亚东的里面要用到JQuery。我感觉要是简单一点的东西直接上JS就行了，有大量需求时再调用库才好。
核心HTML代码如下：
查看演示
Step1 - HTML结构
看一下菜单的HTML代码，跟平常的菜单代码没有什么区别：
记得要出发的那一天。
我对周弦说：今晚去阳朔哟！
周弦说：你会失望地，（汗的表情）。
我心里说：失望就失望吧。总比没去过好！
阳朔之旅，如期所至。
路上的辛苦不说了。觉得值。
第一天大早去了某洞，有些失望，原来就是个洞！ 无特别！
接着又去了某洞，我在想：怎么都是洞！ 能有点创意吗？
到了洞口不想进去了，不过还是跟随大队伍走吧。 进去后发现此洞非彼洞。 还是有些东西可观！
下午乘车前往向往已久的“漓江”！
我失望了！
正如周弦所说！
这个时候我想起了儿时学习的小学课文。
漓江的水真静啊，静得让你感觉不到它在流动；
漓江的水真清啊，清得可以看见江底的沙石；
漓江的水真绿啊，绿得仿佛那是一块无瑕的翡翠。
可我所看到的不是这样。
漓江的水一点也不静啊,不静得让你感觉到波涛汹涌;
漓江的水一点也不清啊,不清得只能看到一层绿黄色;
漓江的水一点也不绿啊,不绿得仿佛那是一江黄河水。
无尽的失望……
我奇怪的问到本地一些人：为什么我看到的漓江不是传说中的？
他们告诉我是因为下雨了漓江涨水了。
噢，看来我去的不是时候啊！
于是第二天的行程我打算放弃，这个只是打算！ 最终还是跟着队伍去了景点：“图腾古道”。
据说图腾古道景区展出的有石器、陶器、自然图腾柱、古老的弓弩、让人听不懂念念有词充满野性诱惑的肢体语言等原始生活场景，再现了7000--12000年前桂林先民居住、生活、宗教、狩猎和甑皮文化的历史风貌，图腾古道为世人开启了一道远古之门！
离开了图腾古道去了漂流点，我没有下去，随便看看。
漂流点完了就骑着自行车绕着山体一周回到集合点。然后稍作休息，吃了某三姐的饭菜最后坐车回深圳。
嗯，照片？ 后补！
人的天性有一种把自己的喜好投射到全部web用户身上的倾向，认为绝大多数用户喜欢自己所喜欢的，我们通常认为大部分web用户和我们一样。
由于职位的不同，web团队的成员对于好的网站设计如何组成有着非常不同的看法。
“大部分web用户和我们一样”这样信仰背后还有另一个隐藏得更深的信仰：相信大部分web用户是弹性的，可以随意变化。
不要问这样的问题“大部分人喜欢下拉框吗？”正确的问题应该是“在这个页面，这样的上下文中，这个下拉框及这些下拉项目和措词会让可能适用这个网站的大部份人产生一种良好的体验吗？”回答这个问题的方法只有一个“测试”。
争辩人们喜欢什么既浪费时间又消耗团队精力，而通过测试将讨论对错转移到什么有效、什么无效上更容易缓和争论，打破僵局。而且，测试会让我们看到用户的动机、理解、反应的不同，从而让我们不会再坚持“用户的想法和我们的想法一样”。
焦点小组与可用性测试的区别：
焦点小组是一小组人（通常5~8人）围坐在桌子旁边，对展示给他们的想法和设计做出反应。这是一个小组过程，主要价值来自参与人员彼此的反应。焦点小组是快速得到用户意见和感觉的一种不错的方法。
可用性测试是一次一个用户展示一些内容（不管是网站、网站原型、或是一些单个页面的草图），并且要求用户说出：1.这是什么？2.试着用它来完成一些典型的任务。
焦点小组在抽象地确定你的目标受众想要什么，需要什么，喜欢什么的时候会很有用。它们也可以测试出网站的理念是否有意义，价值主张是否吸引人。同时，它们在测试你的网站功能命名，发现用户对你的竞争对手看法等方面也是很好的办法，但这种方法并不适合用来了解你的网站运行情况，以及怎样改进网站。
你能从焦点小组了解到的是你在设计网站之前就应该了解得。焦点小组是用在这个过程早期阶段的方法。
可用性测试的几个事实：
- 如果想建立一个优秀的网站，一定要测试。
- 测试一个用户比不做测试好一倍。
- 在项目中，早点测试一位用户好过最后测试50位用户。
- 人们对招募用户代表的重要性估计过高。
- 测试的关键不是要证明什么或者反驳什么，而是了解你的判断力。
- 测试是一个迭代的过程。
- 没有什么比现场用户的反应更重要。
