“由內而外”的表單設計
文章“由內而外”整理了表單設計的一些原因,希望能夠對你有所幫助。
記得年前分享的文章中曾提到,由于開發對數據庫進行調整,所以很多需求的研發、測試都暫停了。趁著“閑”下來的時間,我開始對自家產品的表單設計又拿來研究了。
在整個過程中我體會到了表單設計的微妙之處,趁此機會,就把自己體驗到的東西分享給大家,如果能對大家有幫助,筆者不甚榮幸!
很多表單的設計都是根據系統數據存儲標準或者數據采集規范而確立的。例如新用戶注冊,系統為了保存用戶記錄,就需要建立一個user_id,這個id可以是手機號、郵箱等,以作為該用戶在后臺數據庫中的唯一標識。
為了確保系統存儲到有效數據,那么在新用戶登錄某個產品注冊時,產品就會在前端頁面出現手機號輸入框,這就可以理解為一種“由內而外”的表單設計。不光是數據存儲的內容,存儲的字符規范也是“由內而外”的方式呈現。
代碼層面
有些產品注冊時明確用戶名、密碼不得輸入“%”,其目的是為了防止SQL注入(轉至百度:就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串,最終達到欺騙服務器執行惡意的SQL命令)。
假如一個產品的用戶登錄數據存儲在數據表A中,且支持用戶名、密碼錄入“%”。當某用戶將用戶名設為“張三%”,密碼設為“123%”,那么該用戶登錄時,后臺會訪問數據庫執行類似如下指令:“select * from A where name = “張三%” and password = “001%” ”。這個“%”就是表示所有以“張三”、“001”開頭的數據都會查找出來,這就會出現數據泄露的風險。
但是市場上很多產品目前不會聲明“%”不得錄入,是因為在存儲過程中將“%”進行了轉義,從而規避數據安全問題。
系統層面
由于系統自身設計規范,某些特殊字符就也會被限制不得輸入。例如筆者參與過的一次需求設計(外勤申請:員工在公司外辦公,需要進行外請申請,并由主管進行審批),“外勤地址”就不支持輸入“/”,如下原型(因為用戶輸入地址很少會出現“/”,為了避免干擾,我們沒有在移動端將此限制標識出來):
如果用戶在外勤地址中輸入“/”,在提交時系統就會提示用戶不得輸入“/”,并自動清空該字符。
為什么會有這樣的要求呢?員工在一周內可能需要在多個地區辦公,那么就需要支持允許添加多條外勤地址。
為了使得表結構不冗余、復雜,我們的這個“外勤地址”在數據庫表中是存儲在一個單元格內的:
當員工進行外勤申請后,主管就需要審批。在審批頁面中,外勤地址也是逐條顯示的,而具體顯示幾條就是按照數據表中“/”字符判斷的。作為系統重要的劃分字符,在表單設計時就需要作出限制。
采集規則層面
有些數據的采集,在系統、甚至國家都有相應的規范。比如國家規定統一社會信用代碼不得輸入“I、O、Z、S、V”這幾個字母,所以我們有個關于發票的表單設計就限制這些的字符輸入。
除此之外,比如國家相關法律規定的敏感字符也是不允許錄入的。
結語
今天只是將“由內而外”表單設計的一些原因,在我的認知范疇內整理出來。如果大家有其他原因或者想法,歡迎在下方留言。
最后,要感謝一下我的同事歡全,提供了技術層面的普及。下次,我將會給大家分享一下我整理的關于表單提示相關的內容,感謝關注。
#專欄作家#
兮兮,微信公眾號:孤身旅人(ID:gushenlvren),人人都是產品經理專欄作家。關注人工智能、toB產品、大文娛等領域。
本文由 @兮兮 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Unsplash,基于 CC0 協議
更正一下錯誤,同事歡全指出我的sql語句錯了,應該改成“select * from A where name like “張三%” and password like “001%” ”,%是正則表達式,所有都要用like模糊匹配。
棒棒噠
感謝
漲姿勢了
??