奧推網

選單
科技

B端設計總結(二):基本欄位 Basic Fields

在一些B端後臺中,最基礎的就是欄位了。除了“系統欄位”、“業務欄位”、“管理型欄位”、“規則型欄位”之外,還可以在通用的業務場景中按照輸入類和系統類再細分,本文作者從這兩個方面進行了分析,一起來看一下吧。

輸入和選擇控制元件果然鴿了,寫點偏業務的。

01 欄位 Field

前陣子在一個群裡參與了關於「欄位(Field)」的討論。

無論是在黑帕雲、飛書多維表格、維格表、Airtable 還是在一些 B 端後臺中,最基礎的就是欄位。

有個文章對欄位做了區分,分為“系統欄位”、“業務欄位”、“管理型欄位”、“規則型欄位”,定義是:

業務型欄位

:體現業務要求的欄位,承載業務資訊的展示。

系統型欄位

:系統互動之間的的請求日誌資訊欄位,如系統主鍵、業務 ID、建立時間、建立人、版本號、最後修改時間、最後修改人等。以及系統之間的互動的請求編號、請求時間、請求相應資訊等。

管理型欄位

:為了管理需要設定的欄位,如操作時間、操作人、日誌資訊、操作意見、備註等。

規則型欄位

:系統為了某一規則而存續的欄位。比如商品是即將下架的產品,可以設定下架時間、庫存量等,自動觸發後將商品下架。

這樣的方式非常適用於一些後臺產品設計,很好和技術去溝通需求。

在這個基礎上,我想補充一些更通用的欄位型別和欄位格式。

在通用的業務場景中可以按照輸入類和系統類兩個大類去往下根據不同業務來再細分。

這兩個很好區分:需要業務人員填寫的就是輸入類,自動計算的則是系統類。

一般來講,系統欄位都是指自動生成的,比如說修改時間、建立時間、流水號、建立人、操作人。

輸入類欄位都是可以編輯的。

02 輸入類欄位 Input Type Fields

輸入類欄位再往下分,首先是根據數值進行分類。

常見的數值型別有以下幾種:

在確定了數值型別之後,可以對數值進行一些格式填寫的校驗,不同的數值型別有不同的校驗方式。

其中有兩個通用的是:

「必填」校驗:是否允許這個欄位為空。

「重複」校驗:是否允許這個欄位值和其它值重複,如果不允許重複則無法儲存或提交,常見於錄入線索聯絡人手機號或身份證、商品編碼等場景,比如要求身份證號碼必填並不允許重複,避免了重複錄入。

其它的校驗要根據欄位值的結果進行區分。

1. 字串 String

字串通常可以一些正則表示式用來做以下業務常見格式的校驗:郵箱手機號身份證號碼網址。

這幾個型別都很好理解,其中要特殊說明一下「身份證號碼」型別。

大家知道,身份證號碼最後一位可以是 X 的,當時我們在做這個校驗規則的時候沒有了解正規的身份證號碼的 X 應該是大寫還是小寫。

有使用者就問了,這個 X 是否大小寫敏感?我看了一下,當時沒有做大小寫敏感。正規的身份證號碼 X 應該是大寫,也就是說我們輸入小寫 x 也是會透過校驗可以順利提交的。

如果不校驗的話,會發生什麼?——使用者因為按照身份證號碼欄位設定了自動化的觸發,用“線索表”的身份證號碼去自動查詢“機會表”客戶的身份證,如果已經存在,就不會在機會表中新增這個聯絡人,而是直接更新這個聯絡人的其他資訊。而自動化查詢時是大小寫敏感的,也就是說如果在“機會表”中, 假設有一個 “61010119941120003X” 的身份證號,如果銷售再在“線索表”錄入了“ 61010119941120003x”就會把這條資料自動觸發重複錄入到機會表中。

現在的問題是要解決

重複錄入

,重複的根源是

身份證格式校驗要更精確

。一拍腦門的做法可能是會告訴開發,在校驗身份證時,要大小寫敏感,必須要填寫大寫”X”才能透過校驗。

但是站在使用者的角度思考,這種處理方式就很噁心,因為“X”要大寫這件事不是一個熱知識。我們需要保證效率,而不是我們知道使用者錯了,我們會改,但我們就是要讓使用者自己改。

所以,我想到了更優雅的解決方式:如果使用者輸入了小寫的“x”,在存資料時,我們主動幫使用者修正為大寫的“X”。

2. 數字 Number

對數字進行數值校驗時,首先需要設定數字的格式。

其次,如果業務需要,可以用最大最小值來限制數字的輸入範圍。

3. 貨幣 Currency

貨幣欄位和數字欄位很像,都是隻允許輸入數字,區別是貨幣沒有百分比顯示的開關,貨幣欄位能夠設定貨幣符號,小數點位數至多隻允許設定四位。

4. 日期和日期時間 Date&Date Time

在不同的業務場景中對日期還是時間有不同的需求,比如在一些會議時間中就需要「日期時間」,在一些合同簽訂場景則需要的只是「日期」。

二者都可以參與如 DateAdd、DateTime_Diff 這樣的日期運算。

關於多時區協作的問題可參考之前這篇文章

《多時區協作如何保證時間不會產生歧義》

預設值、支援時間、必填都比較基礎,就不用再寫了。

簡單寫一下關於日期格式校驗一些總結。

當時在做這個功能設計的時候,模擬了以下場景:

某旅遊團只允許 18 歲-65 歲購買,出生日期早於 2003 年,晚於 1956

某博物館門票預定只能購買第二天門票

酒店預定開始日期只能預定最近 7 天(不含今天)

管理發票的回款,在填寫回款明細的時候,回款日期不能超過今天。

機票回程日期不能早於啟程日期

酒店預定結束日期不能早於開始日期

比較清楚的是,可以將以上場景收斂為三個分類:

某個具體的日期參與的校驗範圍

動態的“今天”參與的校驗範圍

其它日期欄位欄位值(動態值)參與的校驗範圍

從業務的角度和成本考慮,對“今天”的需求機率會更高並且成本適中,所以在 Phase1 中, 做了前兩個分類的功能。

在應用管理員設定校驗時,可以設定這些規則:早於晚於在範圍內是不是

範圍可以選擇為:

指定日期:可以根據欄位型別設定指定的日期或日期時間

填寫日期(“今天”)

填寫日期前(“今天”):選擇這項後,可以動態設定範圍是填寫日期前[1,3650]區間的整數

填寫日期後(“今天”):選擇這項後,可以動態設定範圍是填寫日期後[1,3650]區間的整數

提供以上幾種的規則和範圍,就能覆蓋除了需要其他日期欄位值的任何校驗場景了。

5. 選擇 Select

選擇在表單中非常常見,可以分為單選和多選。

單選的表現形式有以下兩種:Select 和 Radio Button。

03 系統欄位 System Fields

對於系統類欄位再細分下去是系統自動生成的基礎資訊,就是建立人、建立時間、修改人等,但是還有幾類,一個是公式計算的,比如商品價格*數量這種公式。

如果已經接觸了關係型資料庫,知道表和表之間的關係,那就需要了解以下兩個欄位:

「聚合(Rollup)」

:用於計算所選資料的彙總、求平均值、最大、最小值

「引用Lookup」

:引用它表的資料

04 寫在最後

以上就是基本的欄位的幾種型別,在 B 端產品中,這些欄位型別非常常見。

複雜高階的欄位後續會繼續再寫,比如地址欄位(Address)、多級選擇(Multi-Select)、動態關聯(Dynamic Link Record)。

作者:高拉,微信公眾號:高拉

本文由 @高拉 原創釋出於人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。