UI设计：网页vs移动，设计思路真的不一样，不要照搬经验
些设计师搞起移动UI非常溜，一旦到了网页UI立马抓瞎了，设计场景变了，原来用在移动UI上的设计技巧不灵了，搞出的网页UI不忍直视，那么大千UI工场在这里，给大家分析一下网页UI与移动UI的不同点，网页UI设计的难点是什么，突破口在哪里，设计流程是什么，欢迎大家阅读点赞。
一、网页UI和移动UI在设计上有什么不同点 网页UI和移动UI在设计上有一些不同点，主要包括以下几个方面：
屏幕尺寸：移动设备的屏幕尺寸通常比电脑屏幕小，设计师需要在有限的空间内展示更多的信息和功能，因此移动UI设计需要更加简洁和精炼。 交互方式：移动设备通常采用触摸屏幕进行交互，而网页UI则通常通过鼠标和键盘进行交互。因此，在设计移动UI时需要考虑到用户的手指操作，包括按钮大小、间距等。 导航方式：网页通常有更多的页面和内容，因此导航方式相对复杂，而移动应用通常采用更简洁的导航方式，例如底部导航栏或侧边菜单。 响应式设计：网页需要适配不同尺寸的屏幕，因此需要采用响应式设计，而移动UI设计则需要适配不同分辨率和设备类型，包括手机、平板等。 动画效果：移动设备通常支持更多的动画效果，设计师可以利用这些效果增强用户体验，而网页UI设计则需要考虑到不同浏览器和设备的兼容性。
移动UI设计相对于网页UI设计更加注重简洁、直观和易用性，需要考虑到用户在移动设备上的操作习惯和体验。而网页UI设计则更注重内容的呈现和导航方式的设计。
二、网页UI设计的难点是什么 相对于移动UI设计，网页UI设计的难点可能包括以下几个方面：
多平台兼容性：网页需要在不同的浏览器、操作系统和设备上进行兼容，设计师需要考虑到不同平台的显示效果和交互方式，确保用户在不同环境下都能正常访问和使用网页。 响应式设计：网页需要适配不同尺寸和分辨率的屏幕，设计师需要考虑到不同设备的显示效果，保证在不同屏幕上都能良好展示内容和功能。 导航和信息架构：网页通常包含更多的内容和页面，设计师需要设计清晰的导航结构和信息架构，确保用户能够快速找到需要的信息，同时保持页面的整体性和一致性。 页面加载速度：网页需要通过网络加载内容，设计师需要考虑到页面的加载速度，避免过多的图片和动画效果导致页面加载缓慢，影响用户体验和SEO排名。 设计风格和视觉吸引力：网页需要吸引用户的注意力并传达信息，设计师需要选择合适的颜色、字体和布局，确保页面具有视觉吸引力和用户友好性。
网页UI设计相对于移动UI设计可能更加复杂和挑战，设计师需要考虑到更多的因素和要求，确保网页在不同平台和设备上都能提供良好的用户体验。
三、做为移动UI设计师，在网页设计中如何突破 作为移动UI设计师，在网页设计中突破的方法可以包括以下几点：
借鉴移动UI设计原则：移动UI设计通常更注重简洁、直观和易用性，可以借鉴移动UI设计的一些原则和技巧，如简洁明了的布局、大按钮设计、直观的导航等，应用到网页设计中。 响应式设计：移动UI设计师对于不同设备和分辨率的适配有一定经验，可以利用这些经验来做好网页的响应式设计，确保网页在不同屏幕尺寸上都能良好展示内容和功能。 设计风格和动画效果：移动UI设计通常更注重动画效果和视觉吸引力，设计师可以将移动UI设计中的一些动画效果和交互方式应用到网页设计中，增强用户体验和页面吸引力。 简化交互方式：移动设备的操作方式通常更加直观和简单，设计师可以考虑简化网页的交互方式，减少用户的操作步骤，提高用户体验和页面的易用性。 用户体验优化：移动UI设计师对于用户体验有一定的敏感度，可以通过用户研究和用户测试等方法来优化网页的用户体验，确保用户能够快速找到需要的信息并完成所需的操作。
通过以上方法，移动UI设计师可以在网页设计中突破传统的设计思维，结合移动UI设计的经验和技巧，为网页设计带来新的灵感和创意，提升用户体验和页面的吸引力。
四、网页UI设计的合理流程是什么 网页UI设计的合理流程通常包括以下几个阶段：
确定需求：在设计之前，需要与客户或团队明确网页设计的需求和目标，包括目标用户群体、网页功能和内容等。 用户研究和竞品分析：通过用户调研和竞品分析，了解目标用户的需求和偏好，同时研究竞争对手的网页设计，为设计提供参考和灵感。 制定设计方案：根据需求和研究结果，设计师制定网页的整体设计方案，包括页面结构、布局、颜色、字体等方面的设计。 制作草图和线框图：设计师根据设计方案制作草图和线框图，展示网页的整体布局和功能结构，为后续设计提供参考。
设计视觉稿：基于草图和线框图，设计师开始制作网页的视觉稿，包括页面的颜色、字体、图片等设计元素，呈现网页的整体风格和视觉效果。 完善设计稿：根据客户或团队的反馈，设计师对视觉稿进行修改和完善，确保设计符合需求和预期。 制作原型：设计师可以制作交互原型，展示网页的交互效果和动画效果，帮助客户或团队更好地理解设计方案。
进行用户测试：设计师可以邀请目标用户参与用户测试，收集用户反馈和意见，优化网页设计，确保用户体验和页面功能的完善。 最终交付：经过多次修改和优化，设计师最终完成网页设计，并将设计稿交付给开发团队进行开发和实现。 以上是网页UI设计的合理流程，设计师可以根据具体项目需求和情况进行调整和优化，确保设计过程顺利进行并达到预期效果。
大千UI工场→10年经验的UI设计和前端开发老司机，1400+项目交付经历，专注互联网产品前台部分的研究、设计与开发。关注我，带您了解最新的观点、技术、干货，如有需求可私信。
作者：charryhuang；转自：腾讯技术工程
1991 年 8 月，第一个静态页面诞生了，这是由 Tim Berners-Lee 发布的，想要告诉人们什么是万维网。从静态页面到 Ajax 技术，从 Server Side Render 到 React Server Components，历史的车轮滚滚向前，一个又一个技术诞生和沉寂。 前言 1994 年，万维网联盟（W3C，World Wide Web Consortium）成立，超文本标记语言（HTML，Hyper Text Markup Language）正式确立为网页标准语言，我们的旅途从此开始。 本文将沿着时间线，从“发现问题-解决问题 ”的角度，带领大家了解 Web 技术发展的关键历程，了解典型技术的诞生以及技术更迭的缘由，思考技术发展的原因。 Tim Berners-Lee Tim Berners-Lee（蒂姆·伯纳斯·李），英国科学家，万维网之父，于 1989 年在欧洲核子研究组织（CERN）正式提出万维网的设想。该网络最初是为了满足世界各地大学和研究所的科学家之间对自动信息共享 的需求而设计和开发的，这也是为什么HTML的顶层声明是 document ，标签名、文档对象模型的名称也是由此而来。 1990 年 12 月，他开发出了世界上第一个网页浏览器。1993 年 4 月 30 日，欧洲核子研究组织将万维网软件置于公共领域，把万维网推广到全世界，让万维网科技获得迅速的发展，深深改变了人类的生活面貌。 他创造了超文本标记语言（HTML），并创建了历史上第一个网站。当然，现在只剩下了由 CERN 恢复的网站副本：info.cern.ch. 静态网页时代 早期的静态网页，只有最基本的单栏布局，HTML 所支持的标签也仅有 <h1> 、 <p> 、 <a> 。后来为了丰富网页的内容， <img> 、 <table> 标签诞生了。 这一阶段，Web 服务器基本上只是一个静态资源服务器，每当客户端浏览器发来访问请求，它都来者不拒的建立连接，查找 URL 指向的静态页面，再返回给客户端。 随着网页的飞速发展，人们发现要人工实现所有信息的编写是非常困难 的，而且非常耗时。 设想一下，假如一个页面有两块区域展示的内容是互相独立的，那么你需要涵盖所有的可能，需要编写的页面数量是两块区域的内容数量的乘积！ 此外，静态网站只能够根据用户的请求返回指向的网页，除了进行超链接跳转，没办法实现任何交互。 JavaScript 的诞生 1994 年，网景公司发布了 Navigator 浏览器，但他们急需一种网页脚本语言，以使浏览器可以与网页互动。 1995年，网景公司的 Brendan Eich 迫于公司的压力，只花了十天就设计了 JS 的最初版本，并命名为 Mocha。后来网景公司为了蹭 Java 的热度，把 JS 最终改名为 JavaScript。但实际情况是，网景公司和 Sun 公司结成联盟，才更名为 JavaScript。 从此网页有了一些简单的用户交互 ，比如表单验证；也有了一些JS为基础的动效 ，如走马灯。但是让网页真正开始进入动态网页时代的却是以 PHP 为代表的后端网站技术。 扩展资料：第一次浏览器大战 在网景公司推出 JavaScript 的时候，微软以 JS 为基础，编写了 JScript 和 VBScript 作为浏览器语言，并在 1995 年的 8 月推出了 IE 1.0。 由于微软在系统里捆绑浏览器，而 90% 的人都在使用 Windows 操作系统，大量用户被动地选择了 IE。面对微软快速抢占浏览器份额，网景公司无奈之下只能快速将 JavaScript 向 ECMA 提交标准，制定了 ECMAScript 标准。 在这段时间，还发生过一件趣事，IE 4.0 发布当天 Netscape 的员工们发现公司的草坪上出现了一个 大大的 IE 图标，这明显是 一个挑衅的举动。 作为回应，Netscape 把自己的吉祥物 “Mozilla” 放在 IE 的图标上，并挂上胸牌，写着 “Netscape 72，Microsoft 18”——在当时， IE 的市场份额确实不如 Netscape Navigator。 但这无法解决份额的问题，网景公司最终在第一次浏览器大战中落败，于 1998 年，被美国在线（AOL）以42亿美元收购。 在 1998 年网景公司被收购前，网景公司公开了 Navigator 源代码，想通过广大程序员的参与重新获得市场份额。Navigator 改名为 Mozilla。这也是火狐浏览器的由来，也是第二次浏览器大战的伏笔。 CSS 1994 年，Hkon Wium Lie 最初提出了 CSS 的想法。1996 年 12 月，W3C 推出了 CSS 规范的第一版本。 美观是所有人的追求。HTML 诞生以来，网页基本上就是一个简陋的富文本容器。由于缺少布局和美化手段，早期网页流行用table标签进行布局。为了解决网页“丑”的问题，Hkon Wium Lie 和 Bert Bos 共同起草了 CSS 提案，同期的 W3C 也对这个很感兴趣。 早期的 CSS 存在多种版本，在 PSL96 版本你甚至可以在里面使用逻辑表达式。但因为它太容易扩展，浏览器厂商那么多，会变得很难统一，最终被放弃。 在众多提案中，H?kon W Lie 的 CHSS（Cascading HTML Style Sheets）最早提出了样式表可叠加 的概念。 行尾的百分比表示这条样式的权重，最终将根据权重计算最终值。图中将会计算 30pt * 40% + 20pt * 60% 作为h2字体大小的最终值。 为了解决 CSS 兼容性的问题，网景公司甚至还将 CSS 用 JS 来编写。 CSS 从诞生开始就伴随着大量的 bug，不同浏览器表现不同坑害了无数的程序员。今天我们能用上相对靠谱的 css，不得不说这是一个奇迹。 动态网页技术 1995 年，Rasmus Lerdof 创造的 PHP 开始活跃在各大网站，它让 Web 可以访问数据库了，PHP 实现了人们渴望的动态网页。 这里的动态网页不是指网页动效，而是指内容的动态展示、丰富的用户交互。PHP 就像给网络世界打开了一扇窗，各种动态网页技术（如 ASP、JSP）雨后春笋般的冒了出来，万维网也因此开始高速发展，MVC 模式也开始出现在后端网站技术中。 动态网页技术解决了以前各种令人无法呼吸的痛，生活总会越来越好的： PHP 等动态网页技术的原理，大体上都是根据客户端的请求，从数据库里获取相对应的数据，然后塞到网页里去，返回给客户端一个填充好内容的网页。这个阶段也是前后端耦合的 。 而当一些基础的需求被满足之后，动态网页技术带来的不足也渐渐暴露出来 ： 网页总是刷新 。用户名密码校验需要刷新以展示错误提示；因下拉选择器选择不同而展示的内容需要刷新才能展示；每次数据交互必然会刷新一次页面。网页和后端逻辑混合 。相信老前端们都有过这样的经历：开发完HTML后，会把页面发给后端修改，加上数据注入逻辑；联调或者debug的时候两个人坐在一块看，查问题的效率很低。有大量重复代码无法复用 。举一个典型的例子，论坛。很多时候只有内容有变化，菜单、侧边栏等几乎不会有改变，但每次请求的时候还是得再将整个网页传输一遍。不仅页面会刷新，速度慢，还挺耗流量（这个年代上网也是一种奢侈）。AJAX AJAX，Async JavaScript And XML，于 1998 年开始初步应用，2005 年开始普及。AJAX 的广泛使用，标志着 Web2.0 时代的开启。这同时也是各大浏览器争锋的时代。 现在，我们可以通过 AJAX 来动态获取数据，利用 DOM 操作动态更新网页内容了。来看看加入了 AJAX 的网页是怎么工作的： 这个时候前端路由还没有兴起，大多数情况下还是后端返回一整个页面，部分内容通过 AJAX 进行获取。 随着智能手机的出现，APP 开始萌芽。相比起网页，APP 编写好之后只需要数据接口就能工作；而网页不仅需要后端写业务逻辑，控制跳转，还要写一部分接口用于 AJAX 请求。 这个阶段前端能做的事情还是很少，还背负着“切图仔”的绰号。随着 HTML5 草案的提出，前端能做的交互越来越多，程序员们急需解决以下问题： 后端业务代码和数据接口混合 ，还得兼容 APP 的接口（很多企业既有 APP 又有网站）能不能让前端也像 APP 一样，只需要请求数据接口即可展现内容呢？ 扩展资料：第二次浏览器大战 2004 年 Firefox 发布，拉开了第二次浏览器大战的序幕。同期市面上诞生的各种新兴浏览器，如 Safari、Chrome 等，也加入了战争。 此前由于 XP 系统实在过于火爆，导致 IE 6 无任何竞争对手，微软甚至解散了浏览器的大部分员工，只留下几个人象征性地维护顺便修补一下 bug。这让开发人员非常痛苦。 此时 Firefox 以优越于 IE 的性能和非常友好的编程工具，迅速将那些被 IE6 搞得焦头烂额的网页开发人员们，从水火之中救出，导致先让前端工程师成为忠实的第一批用户，然后，经由这些有经验的开发人员们推广到了普通的用户群体。 基于 webkit 内核的 Safari，借助自家产品（iOS、MacOS）的垄断快速收割移动端和 mac 端市场份额；同样基于 webkit 内核的 Chrome，趁着微软放松警惕，凭借优越于市场上所有浏览器的性能，如同中国历史上的成吉思汗一样大杀四方，快速扩展市场份额。 微软知道，自己已经失去了最初能称霸的机会，这次它不想失去，IE 再次开始迭代，各大浏览器厂商又开始不顾标准，迭代再次开始，为了统一化标准，W3C 开发了 HTML5，但是迟迟得不到微软的认可。在其他浏览器纷纷支持 HTML5 后，微软发现，自己又成了孤家寡人，份额不断缩水。 2016 年，Chrome 浏览器份额超越 IE，第二次浏览器大战结束。 浏览器大战极大的推动了技术进步，正是 Google 研发出的 V8 引擎极大的提升了 JS 的运行效率，NodeJS 才有机会诞生，前端才能走向全栈。JS 其实没有你想象的那么慢 。 SPA 2008 年 HTML5 草案提出，各大浏览器开启良性竞争，争先实现 HTML5 功能。由于 HTML5 带来前端代码复杂度的增加 ，前端为了寻求良好的可维护性和可复用性，也不得不参考后端 MVC 进行了设计和拆分，后来出现了三大前端框架：Vue（2014）、React（2010）、AngularJS（2009）。 单页应用返回一个空白的 HTML，并通过 JS 脚本进行动态生成内容，从此和页面刷新说拜拜。 后端不再负责模板渲染，前端和 APP 开始对等，后端的 API 也可以通用化了。前后端终于得以分离 。（PS：最终目标是成为后端） 但 SPA 因为返回的是空 HTML，所有 JS 也被打包为一个文件，需要在一开始就加载完所有的资源， 这使得前端不得不拆分过于庞大的单页应用，出现了框架的多页面概念，也出现了多种解决方案。 很多网页首次加载的时候其实并不需要太多的东西，比如论坛首页与贴子详情页，完全可以将其拆开，用户在新打开的页面阅读反而体验更好（多页应用 ）。 又比如管理后台，可以在页面框架内，将每个菜单对应的管理页拆出来动态加载 （import）。 Server Side Render Server Side Render，服务端渲染，简称 SSR，又称服务端同构、直出，一般使用 NodeJS 实现。 这里的服务端渲染和以前的不一样，SSR 会利用已经“脱水”的首屏数据来渲染首屏页面返回给客户端，到了浏览器再注入浏览器事件，并且保留单页应用的能力，对 SEO 非常友好。但学习成本高，限制较多。 让我们看看传统 SPA 和加入了 SSR 的 SPA 在请求上的区别： 传统 SPA 可以更快的返回页面，请求响应时间更短；加载 JS 后才开始渲染，白屏时间更长，loading 结束后用户感知到的相对可交互时间更早。 而 SSR 在接到浏览器请求时，先从后端拉取首屏数据渲染在页面内才返回，请求响应时间更长；因为节约了一段浏览器请求首屏数据的时间，白屏时间更短。由于 JS 异步加载，用户感知的相对可交互时间变晚。但体验上 SSR 一般更好。 在极端情况下，用户眼中传统 SPA 会一直显示 loading，使用了 SSR 的页面则会出现“点不动”的情况。 大多数时候 SSR 体验会更佳，因为服务端承担了大部分渲染工作，这也导致服务端负载变高。但在业务复杂的情况下，SSR 首屏请求的接口数很多，导致返回 HTML 变慢。 归根结底，SSR 不能很好的应付业务复杂的情况，首屏要加载的东西还是太多了 。所以我们要怎样让用户感知到的白屏时间变短呢？ NodeJS 说完了 SSR，必须说一下 NodeJS。2010 年 NodeJS 正式立项到现在已经 11 个年头了，NodeJS 的诞生来自于 Ryan Dahl（下图） 的灵感。他想以非阻塞的方式做所有事情 ，用完全异步方式可以处理非常多的请求（高并发）。 NodeJS 的出现让前端向全栈的发展迈出了重大的一步。很多公司开始用 NodeJS 搞 BFF（backend for frontend），我们也开始把 Controller 层放到 NodeJS 来处理，后端只负责基础业务数据。也就是现在的三层架构： 这种架构在跨端的时候具有良好的适配性，我们可以根据业务需求，为不同端设计不同的 Controller 和 View，而后台可以不做变更。这种架构省去了很多沟通成本，前端专注页面的展示，后端专注业务逻辑。 当然，NodeJS 还可以对后端数据进行预处理，前端根据自己的需要自己设计数据结构，页面开发与接口调试形成闭环 ，还为后端分担了压力。 扩展资料：第三次浏览器大战
智能手机的飞速发展，这张图表现的淋漓尽致。第三次浏览器大战是争夺移动端市场份额的一战，也是当下正在进行的一战。 Benedict Evans: “Mobile is eating the world.”（移动设备正在蚕食世界） “Mobile remakes the Internet.”（移动设备正在重构Internet） 而未来，浏览器真正的对手不再是浏览器，而是小程序这样结合了APP和网页优点的新兴技术。 未来 早在 2009 年，Facebook 的工程师就开发了 bigPipe，让 Facebook 页面打开速度提高了两倍。bigPipe 使用 分块渲染 的思想，将网页的渲染变成了一小块一小块的，服务端渲染好一块页面就发送给客户端。他们直接把木桶拆了，打破了短板效应 。 时隔 11 年，也就是 2020 年 12 月，React 团队提出了 React Server Components，算是一个可扩展的前后端融合方案。其理念和 bigPipe 类似，把组件放在服务端渲染，节省了从浏览器进行数据请求的开支，一些运行时也可以不用放到浏览器，减小了包大小（如 markdown 在服务端渲染好了，也就不再需要把工具库发送给浏览器了）。React Server Components 的引入，也同步做到了自动的 Code Split。 React Server Components 原理 不同的是 React Server Components 返回的不是 HTML，而是带有结构和数据的自定义类 JSON 数据。 这种结构，是对服务端渲染的核心（结构+数据）进行抽象，结合 React 的工作方式（如 Suspense），平缓的从服务端过渡到了客户端，维持了组件状态，并且可以更自由的拼装服务器组件和客户端组件。 关于拆分这条思路，让我想到微前端，虽然现在微前端还有很多问题，但微应用即服务也不乏为一条解决之道。未来前端或许会往“小而美”的方向发展，甚至形成一个以服务端组件为单位的包管理器，网页打包大小会越来越小，更多的组件是从网络上直接获取。 此外，我也很期待 Web Components 的发展，有了原生的支持，0kb runtime 也不是不可能了。合久必分分久必合，现存很多前端框架也可以得到统一了。当然现在 Web Components 想要投入使用，首先离不开浏览器的支持，而且必须有一个平缓的过渡，此外兼容性也是一个大问题（最后还是苦了程序员们）。 本文首发公众号：腾讯技术工程（ID：Tencent_TEG），如需转载请联系出处。 着人们越来越依赖智能手机，所以有很多企业都越来越重视移动端的排名，其实移动端和pc端的网站优化同等重要。只是根据用户的需求对移动的网站进行优化调整。
移动端网站优化需要哪些技巧?
百度官方意见的重点之一是使用合理的div和CSS架构，建议使用HTML 5页面。其次，合理的布局，使WAP结束页面。
事实上，移动页面优化和PC页面优化基本上是一样的，下面是对移动站点SEO优化的几个要点的简要描述。
一、域名和robots设置。
1.域名越短越容易记住。很多网站收集端的域名是pc网站的二级域名，让用户更加信赖网站，如果手机端有专门的域名建议取一个简单好记的域名，比较推荐m.开头的二级域名。
二，做好移动和PC站点的适应性转换。
1.确保移动网站或个人电脑网站的每一页上都有相应的导航或提示链接，以便用户在移动版本和PC版本之间切换，而且搜索引擎更好地包含它也是方便的。
2.百度官方声明：对于移动网站，当百度不确定访问来源时建议直接返回html5，不要重定向到pc
三、页面尽量简洁
1.手机网站的网页下载速度较个人电脑网站为慢，网页数目及页数尽量减至最少。
2.此外，由于用户是流动电话用户，浏览网页的时间是零碎的，所以不可能耐心地点击大量网页，直接将网页的主要内容呈现给访客，因此，有必要尽量精简流动网站的设计。
3.导向页或购买程序应尽可能简明扼要，提供从访问者进入网站到购买、直接放弃多余内容和向访问者展示他们想要的内容的最简单步骤。如果购买过程需要登记六七个项目，在购买时再填写几个项目，恐怕下次不会再来了。
四.URL结构优化技巧
具有良好描述、规范和简单性的URL有助于用户更方便、直观地判断网页内容，同时也有助于搜索引擎更有效地掌握和理解网页。
五.如何选择域名?
就像个人电脑网站一样，移动域名越短越好。一个好的移动网站域名不仅应该让用户容易记住，更容易进入，还可以方便用户向他人推荐。短域名使用户更容易直观地理解网站的主旨。
六、尽量避免使用弹窗、闪存、java等行为。同样，闪存和弹出窗口等行为将占用很大一部分流量，对于移动用户来说，无疑会浪费时间和流量。
七、当移动网站被修改或更改时，要做好301重定向的工作。对于移动网站的修改或域名的替换，新旧内容的映射应该尽可能简单，如果你能改变域名，如果你能做同样的路径，负面影响就会更小，影响时间也会更短。
百度站长平台官员还发布了移动台优化指南，希望网站管理员和营销人员仔细阅读，为用户创造一个更好的移动页面。
