• 登录的一些心得


    一、一切以良好用户体验为基础

    1. 视觉效果

    界面的设计就不用多说了,一般情况这个属于美工的活儿,这里要谈的是几个最基础的点。

    第一,你的页面兼容性如何?各个元素的长宽、行高等在不同浏览器上是否表现一致,如果这个都没有保证,那一定是不合格的。

    第二,移动终端上的体验问题,如今很多页面 PC 和移动终端都用的一套结构,也就是我们所说的响应式布局,本博客就使用了响应式布局,缩小窗口可以看到效果,响应式布局是为了让不同的移动终端也能得到同样的优质体验,可是很多开发者却忽略了横屏时的效果。下面是常见的几个移动终端的像素比例:

    Mobilepx rate
    Iphone5 320*568
    Iphone4 320*480
    Galaxy S 3/4 360*640
    Lumia 920 384*640
    iPad 768*1024

    照顾用户的响应式布局除了要考虑这些屏幕的横屏,还得把竖屏考虑进去。我简单的做了一个登陆页面:

    正确的账号是:barret,密码是:123,你可以用错误的信息先去测试下~

    可以戳这个DEMO:http://qianduannotes.duapp.com/demo/login/login.html

    2. 交互

    前面那种方式,点击提交按钮,送到后台去验证,验证没有通过则回到登录页面,这也算是一种交互,不过这种交互的体验是特别不好的,每次都得重新刷新页面,应该利用 ajax 异步去验证表单。为了省去用户的聚焦点击,可以按照下面的思路来做:

    1. 用户名为空,或者格式不对 -》 提示错误,清空密码框,聚焦到用户名框,并全选用户名
    2. 用户名不存在 -》同上
    3. 密码错误 -》 提示错误,清空密码框,聚焦密码框
    4. 聚焦到密码框,全选密码

    告诉用户哪个地方出了问题,并提前预知用户遇到这些问题之后会做哪些事情,我们能够用程序解决的事情,绝不麻烦用户亲自动手操作。当提示用户名错误的时候,用户肯定会回到输入框重新输入,这个时候我们已经聚焦到用户框,并全选了之前的输入,方面用户进行删除操作。类似这样的交互,我们应该提前做预判断。

    3. 状态提示

    什么是状态提示?有时候因为网络原因,点击提交 button 之后,ajax 传输半天没有响应,用户等了半天页面一点提示都没有,这个肯定会让用户焦急的。回头看看 Gmail,一个把 ajax 发挥到极致的 web应用,在用户体验上做的也是相当给力的,登录邮箱的时候一个 loading 动画,旁边还放了一个加载基本HTML(供慢速网络使用),每一个操作都有提示,提示中还有一个撤销操作的按钮,数据进行加载的时候,如果加载时间过长,期间会进行多次不同的提示,并在最后给出一个确切的结果,对于一个登陆框而言,需要做到这些:

    1. 一个明确的用于状态提示的 box
    2. 等待 3s,结果没有出来,提示用户继续等待
    3. 等待 6s,结果没有出来,提示用户网络不畅通
    4. 设置 10s 为超时,并告知用户提交表单失败

    这些东西的实现并没有太多的技术难度,但是可以给慢速网络下的用户带来很好的体验和安全感。

    4. 安全传输

    用户最担心的是账号密码被截获,或者因为密码一处多用,不希望别人看到密码的明文,既然用户担心,我们就应该想办法来处理。

    把密码和时间戳叠加,然后加密,传到后台的是加密的结果以及这个时间戳,如下:

    // 前端
    t = new Date();
    s = encode(pwd + t);
    post(s, t)
    
    // 后台
    decode(s) === pwd + t

    这样就可以保证密码的隐蔽性,如果 hacker 不知道 decode 函数,即便是拿到了 s 和 t,也是徒劳。关于安全传输,之前也写过相关的文章,OAuth认证原理及HTTP下的密码安全传输。如果要做到在用户输入的时候就绝对安全,那就必须使用类似 支付宝安全插件 这样的东西了。他的原理就是在页面中嵌入一个控件,这个控件与页面之间是相互屏蔽的,在控件内部输入也只有控件拿得到输入信息。

    5. 数据走缓存

    表单提交首选应该是 post,但是也不排除会用 get 方式提交,那么这个时候就应该考虑数据缓存了,如果请求的 url 相同,程序就会直接从浏览器的缓存中拿数据,并给出状态是 status: 200 OK(from cache),为了避免这些常识性的问题,记得在请求的参数中加点东西。

    _t = new Date*1
    _n = Math.random

    为了保证参数的绝对唯一性,甚至可以把 时间戳 和随机数叠加起来用

    _s = (new Date*1 + Math.random*1E5)/1E5

    6. 渐进增强

    渐进增强这个词一般是,不支持 javascript 或者对 javascript 支持度不太好的浏览器上利用其它方式实现,或者告诉用户什么原因不能用,就是一种蜕化处理。目前不支持 javascript 的浏览器应该是绝迹了,当然也不是绝对,kindle 内置的浏览器对 javascript 的支持度就不高,或者根本就不支持。还有一种情况是用户禁用了 javascript,这个比例很小,开发者会这么干,一般的用户不会乱改浏览器设置。但是我们的程序,尤其是关键的部位(如搜索,登录,注册等)必须要考虑这一少部分群体。一般采用的方式是:

    1)使用 noscript 标签,这个是最常用,也是最实用的。

    2)hack 方式,document.write("<" + "!--")

    document.write("<" + "!--");
    // code...
    // 如果浏览器不支持 javascript,将显示这中间的内容
    // code...
    document.write("--" + ">");

    这是一种特别巧妙的处理手段,也是值得推荐的。

    7. 浏览器后退按钮

    这个在注册或者登陆的时候是一个普遍的问题,登陆之后,跳转到另外一个页面,我的鼠标有两个侧键,是用于前进和后退的,有时候会误点侧键,这个时候页面又会回到之前的登录页面,但事实是用户已经登录了,所有页面的状态都应该是已登录的,不管什么情况下都不应该让用户在看到这个页面。用户的点击操作会引发上面的问题,而程序 history.go(-1) & history.back() 也会有一样的bug。

    这样的问题处理方案比较简单,ajax 拿到 success 的状态码时立刻做跳转,但是这里不能用 window.location.href,这样浏览器还是会记录这个登录历史,应该使用 window.location.replace,替换当前历史记录。

    8. 记住密码

    用户最烦的就是每次登录页面都要输入长长的账号密码,如果没有勾选“记住密码”,则用户的登录状态保存在回话的 session 中,关闭页面或者浏览器的时候,回话结束,session 被删除,这样当用户下次登录的时候又需要重新输入密码。表单页面的“记住密码”复选框默认状态应该是已选择,用户的潜意识行为都是要少操作的。

    当用户提交信息成功之后,直接在 cookie 中保存账号密码?这样的做法显然是不合理的,密码怎么能够明文保存呢,有人会想到加密处理密码然后再保存,或者使用服务器来设置 cookie,这些做法都是可以的,不过最好的方式是,当用户成功提交信息时,服务器给前端提供一个 token,这个 token 是用于自动登录的,我们只需要保存 token 就行了,这样就很好的避免了 cookie 中存放用户隐私信息了。

    还有一个要注意的是,当用户取消了“记住密码”的复选框时,应该立即清除相关 cookie。

    二、其他相关的几个点

    1. 用户忘记密码

    如果用户很长时间没有来你的网站,他可能会忘记自己设置的密码,一些奇葩的用户甚至会忘记自己的用户名,但是用户永远是没有错的,出错的只有我们的程序和写程序的人。对于忘记密码的人,可以在填写密码的旁边加上一个链接 “忘记密码?”,让用户利用邮箱或者绑定的手机来找到密码,对于忘记密码以及用户名的人,内伤中... @undefined 13# 14# 正解

    2. 脚本注入

    表单信息应该做正则匹配,或者信息的过滤,防止脚本注入,这个主要是后台要考虑的问题,就不多说了。

    3. 多次提交

    我们发微博的时候经常会遇到的问题,因为网络原因,会多次点击发布按钮,这个问题有多种处理方案:

    • 发布之前先从服务器拿 token,该 token 只有一次有效
    • 后端判断一定时间内用户发布的多条信息,相同的信息去重
    • ...

    三、容易出错的几个知识点

    1. setRequestHeader

    利用 ajax 来 post 信息,有的人可能遇到过,后台拿不到数据。原因是没有重写 请求头的 Content-Type,

    xhr.open("POST", url, true);
    xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
    xhr.send($.param({
        "user":$("#user").val(),
        "pwd":$("#pwd").val()
    }));

    一般浏览器不支持 GET 方式时 xhr.send 中添加参数,但是 POST 是可以,也是必须的,如果没有设置 Content-Type 的头部,数据送到后端便没办法解析成 key-value 的模式,后台(PHP)通过 $_POST 也拿不到数据。

    2. checkbox

    这里也是一个体验问题,一些人把 checkbox 和他相关的文字分开写,结果没有使用 label 来指向,如:

    <input type="checkbox" checked="checked" />记住密码

    很显然,我们点击后面的文字是不会让 input 改变状态的,有些人会这么处理:

    <label><input type="checkbox" checked="checked" />记住密码</label>

    这样处理之后,点击文字当然可以选中 input,但是这种处理方式是不合理的,label 本来就是标记 input 框用的,他的内容应该是文字,不应该包含 input 这个框,所以合理的做法应该是这样:

    <input type="checkbox" checked="checked" id="rem" />
    <label for="rem">记住密码</label>

    四、小结

    上面说了一大堆,很多问题都是站在用户的角度去思考的,我们是程序员,但是我们也是用户,我们会吐槽,但是我们也会被吐槽。

    把用户体验做到极致,这个十分重要,不要放过任何一个细节!

  • 相关阅读:
    20179203李鹏举 《Linux内核原理与分析》第一周学习笔记
    20179223《Linux内核原理与分析》第八周学习笔记
    20179223《Linux内核原理与分析》第七周学习笔记
    20179223《Linux内核原理与解析》第六周学习笔记
    20179223《Linux内核原理与分析》第五周学习笔记
    20179223《Linux内核原理与分析》第三周学习笔记
    20179223《Linux内核原理与分析》第二周学习笔记
    20179223《Linux内核原理与分析》第一周学习笔记
    51nod贪心算法入门-----活动安排问题2
    51nod贪心算法入门-----活动安排问题
  • 原文地址:https://www.cnblogs.com/xiaohui108/p/3522051.html
Copyright © 2020-2023  润新知