奧推網

選單
科技

【乾貨】7個實用性技術知識點,讓你的產品設計更加科學、更順暢!

編輯導語:設計師在日常工作中除了設計的工作以外,也需要去了解一下技術原理,可以讓設計師們做出更加科學的產品設計,並且在日常與開發的溝通中也能更加順暢;本文作者分享了關於設計師的七個實用性技術知識點,我們一起來看一下。

本文主要介紹幾個工作中常遇到的技術知識點,希望能夠幫助設計工作者更好地理解技術原理,從而幫助我們做出更科學的產品設計。

先來個大綱:

APP/網站是怎麼執行的

iOS和安卓的佈局原理

web App和nativeAPP

cookie 和session的區別

介面是什麼

開發口中的寫死是什麼

控制元件和元件的區別

之前讀了一本書,書名叫《產品經理必懂的技術那點事兒》,對於做設計的我來說非常受益,也十分推薦大家去讀讀看,通俗易懂。

雖說我是學通訊工程出身,這書裡的技術知識我大學其實也是學過的,不過……額,你們懂的,大學的時候哪裡知道這些知識點日後用得到呢?當時只覺得晦澀無趣,工作後才來惡補,希望為時不晚…

正是因為我覺得書裡提到的技術知識對於我的日常工作非常有幫助,所以想把其中一些我覺得對設計同學來說比較有用的知識點提煉出來,同時加入自己的理解和案例;一來幫助自己鞏固知識,二來如果能給大家一些啟發也是好的。

為什麼要了解技術知識點?

1) 助力溝通

可能有的設計同學(不管是互動還是UI)會覺得,不用瞭解技術也不影響日常工作。

話雖沒錯,可是能夠了解一個產品背後的工作原理不僅能驚豔我們的認知,覺得計算機的世界居然如此神奇而美妙。

也能讓我們更好地與開發小哥哥溝通而不至於雞同鴨講,結果都聽不懂對方想要表達的意思。

2)避免超過技術邊界

這點對於UI設計的小姐姐們非常受用,UI設計師往往對視覺的敏感度大於產品背後的研發邏輯,有時候會設計出一些研發難以落地的效果圖。

時間充裕尚可尋求解決方案,可是網際網路產品往往小步快走,敏捷開發,工作中沒有太多時間去探索一種“小眾”的介面實現方式;或者說是需要把資源分配給優先順序更高的任務。

所以瞭解一些計算機背後的工作原理,能幫助互動設計和UI設計在設計產品的時候更好地衡量互動和視覺的落地技術邊界。

一、APP / 網站是怎麼執行的?

我們首先了解一下“前端”和“服務端”的概念,《產品經理必懂的技術那點事兒》中是這麼描述的:

網際網路產品技術架構整體分為兩部分,分別是前端和服務端,前端和服務端透過中間網路進行資料傳輸。

前端就是使用者使用的客戶端,包括最初使用個人電腦透過瀏 覽器進行網頁瀏覽,現在透過智慧手機使用App進行一系列的操作。

服務端包括應用伺服器和資料庫,應用伺服器用來部署服務端程式,處理前端請求並進行服務響應,資料庫用來儲存資料,伺服器透過專門與資料庫進行互動的程式對資料庫進行讀寫操作。

——《產品經理必懂的技術那點事兒》

如果沒有接觸過技術方面的知識,光讀文字可能有些不容易理解。

舉女生喜歡逛的淘寶APP的例子:

比如小紅開啟淘寶進入首頁會看到商品列表,商品列表包含了:商品圖、商品名稱、商品銷量等等。

問:商品列表裡的這些資訊從哪裡來的呢?

你可能會說“是賣家在後臺建立的。”

沒錯,就是賣家在後臺建立的。

那麼這些資訊又是怎麼跑到小紅的淘寶APP裡面的呢?

例子中的商品資訊從後臺傳到淘寶APP的過程就是一個網際網路的執行機制。

資料不會憑空從後臺跑到前臺,資料的流動過程就是我們需要了解的知識點。

下面講解小紅淘寶裡的商品列表中的資料的流動過程:

首先,賣家在後臺建立一條商品資訊,比如一條裙子。

輸入商品基本資訊:尺寸、顏色、板式等等。

然後賣家提交了這些資訊或者說叫資料,提交後這條商品資料去哪裡了呢?

得有地方儲存這些資料呀,儲存這些資訊的地方就叫做資料庫。

這時候小紅在淘寶APP裡購買了這條裙子,這時候裙子的庫存就減去了1,相應的賣家後臺裡裙子的庫存也減去了1。

問題來了,為什麼淘寶APP購買了後臺的庫存就相應改變呢?誰做的計算?

嗯,計算和處理這些資訊的就是伺服器。

商品資訊存在資料庫中,透過中間網路(也就是網際網路)傳到到了APP中。

小紅在APP購買了商品,APP傳送請求原路返回到伺服器進行處理。

然後伺服器返回請求給APP告訴他“你購買成功啦!”

再舉個簡單的例子:

比如登入的時候,我們輸入手機號和密碼。

點選提交後,前端就將資訊傳輸到服務端,查詢輸入的手機號之前有沒有註冊過,密碼是否正確。

如果已經註冊且密碼正確,服務端就告訴前端“你可以登入啦”。

如果沒有註冊過或者密碼錯誤,服務端就會告訴前端“你沒註冊啦”或“密碼錯誤啦”這些都是資料的流動。

二、iOS和安卓的佈局原理

瞭解iOS和安卓的佈局原理可以幫助我們更好的適配。

安卓的線性佈局:

由上到下依次排列的佈局方式叫作“線性佈局”,線性佈局簡單說就是按照順序從左至右或者從上到下依次在介面上排列控制元件——《產品經理必懂的技術那點事兒》

上下線性佈局比如表單填寫介面的控制元件上下依次排列:

左右線性佈局比如搜尋頁面的熱搜詞,很多時候熱搜詞的字數不一樣。

設計師在描述換行的時候可能會標註大段文字比如:

“間距都為34,從左至右依次排列,遇到距離螢幕邊界15時換行”。

現在我們瞭解了佈局原理,直接說一句“線性佈局,邊界離螢幕15”就可以啦,是不是提升了效率的同時又讓研發小哥哥對你刮目相看呢。

相對佈局也是經常使用的,比如說下面的相對佈局案例。

三、web APP和native APP

移動App的實現有兩種形態,一種是透過Web的方式實現,也就是在App內部透過載入Web網頁的方式實現產品功能;另一種是Native或者叫原生的方式實現,這種方式是使用移動平臺原生的控制元件開發而成。

——《產品經理必懂的技術那點事兒》

web APP也就是H5,native APP也就是原生APP。

我們經常會聽到這個詞彙:H5。

H5實際上是HTML的版本號,之前還有HTML4、HTML3等;HTML稱為超文字標記語言,感興趣的小夥伴可以在書裡瞭解更多。

現在基於Web技術的開發基本都是基於H5技術進行的,web APP就是透過web/H5實現的介面,相當於在APP內部載入了一個網頁介面。

那麼為什麼需要H5呢?

我們都知道APP的更新需要重新下載安裝包,安裝成本不低,而H5更加靈活,只要前端更改釋出後,APP裡進行載入後就更新了,是不是快很多。

比如說現在很多電商網站的活動運營頁面,這些頁面需要經常更換活動,如果靠下載APP更新的話, 那搞活動可太難了。

但是如果用H5的話,今天雙十一明天狂歡節天天剁手……

既然H5 這麼棒,為APP裡不全部使用H5 呢?

嗯,最開始我也是這麼想的。其實H5雖然很靈活,可是H5的體驗上不管是流暢度還是效能上都比不上原生。

H5 or 原生?

如果內容變更小,對流暢度和效能要求高,那麼用原生。

如果內容變更大,尤其是一些運營內容,H5也許是更好的選擇。

但是現在的APP很少用純H5 或純原生,用Hybrid APP開發更多。

Hybrid App是一種混合開發技術。

Hybrid App是一種混合開發技術,所謂混合開發就是指在一個產品中同時使用 Native技術和Web技術。

根據產品使用場景的需要和技術框架設計,在不同的頁面 或者同一個頁面的不同模組同時使用Native和Web技術,這種透過混合技術開發實 現的產品就叫作Hybrid App。——《產品經理必懂的技術那點事兒》

意思就是同時使用原生和H5。

四、cookie 和 session的區別

Cookie是將資訊儲存在本地

而Session是將資訊儲存在伺服器端

不知道大家有沒有這樣的體驗:

當你用谷歌瀏覽器登入一個網站的時候,輸完賬號密碼後,谷歌瀏覽器會提示“是否儲存賬號密碼”。

當你下次用你的谷歌登入這個網站的時候,輸入賬號就能夠填充密碼。

但是當你換了一個新瀏覽器進入這個網站的時候,輸入賬號時就不能填充密碼;但是隻要你賬號密碼輸入正確了,你還是能進入網站。

谷歌儲存的賬號密碼就是cookie;伺服器儲存的賬號密碼就是session——所以當你換了新瀏覽器登入的時候,瀏覽器不會提示你的登入密碼,當你登入進去網站後你的賬號資訊還在。

五、“介面”是什麼?

介面這個名詞我想除了技術,產品經理應該接觸的最多,互動設計其次,UI設計應該接觸得最少,但我覺得非常有必要了解介面的概念。

介面也就是API。估計API聽過挺多次的,很多大廠都會出自己產品的API方便其他產品呼叫,比如百度地圖的API。

《產品經理必懂的技術那點事兒》中說“資料介面是指客戶端與服務端進行資料傳輸和互動的資料協議,資料介面是一種資料交換的標準。”

我之前看過一篇文章,裡面對介面的描述我覺得是最易懂的,文章裡說:

如果我們把常見的函式公式 y=x+2 看成一個介面

那麼當x=2的時候,y=4

此時我們把 y=x+2 稱為介面,x稱為引數,y稱為返回的結果

那這個介面的功能就是能把我們輸入的數值加上2,我們輸入3,返回的就是5

介面就是預先定義的函式邏輯,它是供其他系統請求後返回一個結果的東西。

是不是超級容易理解的!!!!

下面舉幾個API的案例:

相信大家在註冊登入的時候都遇到過拼圖等驗證方式,大多數網站使用的技術都是第三方的。

比較知名的是極驗,直接使用極驗的API介面就可以實現行為驗證等多種驗證方式,大大地節省了開發成本。

六、開發口中的“寫死”到底是什麼?

我剛進入網際網路行業的時候對“寫死”這個詞還挺疑惑,為什麼叫寫死,感覺不是很“正經”的趕腳……

其實“寫死”這個詞的確不算是標準術語,它的意思從字面上也能大概猜出幾分,“死”的意思就是不變的,不改動的。

網際網路產品的資料分為前端寫死和後端伺服器傳輸。

舉個例子:

淘寶的tab欄切換圖示應該就是寫死的,資料是放在客戶端也就是淘寶APP中的。

而淘寶商品列表的商品圖、商品標題、商品價格就是“活”的,要專門寫一個介面去獲取伺服器的資料,所以淘寶的商品才會千變萬化而不是固定不變的。

在設計過程中需要考慮哪些資料適合“寫死”,哪些資料需要介面傳輸。

一般來說,對於不經常變更的資料可以“寫死”;比如tab切換欄、APP的導航欄架構等。

資料的“寫死”一方面減少前端的工作量另一方面也能提升APP的流暢度,畢竟可以減少獲取資料的時間。

而對於一些經常變更的資料就不適合“寫死”。

比如說商品列表、運營位等。

七、控制元件和元件有什麼區別?

說真的,控制元件和元件的區別我想還是有很大一部分設計師沒有做過區分的,感覺聽上去差不多呀。

看看書裡怎麼說的:

任何一個網頁或者App產品都是由大量的輸入框、按鈕、文字展示框構成的,產品中的這些最小介面元素組成單元就叫作控制元件。

件是一種功能更全面的升級版控制元件,或者可以把元件理解成多個控制元件的組合。

——《產品經理必懂的技術那點事兒》

有點原子和分子的意思,原子組成分子,而控制元件組成元件。

元件有一個“組”字,就意味著它是一個組合,這樣就很好理解了。

經常用sketch的設計同學應該不會陌生,sketch對於元件的整理和適配功能是做得相當完善的,沒有用sketch的同學也強烈安利去試試;我覺得就元件化和便捷程度來說,目前來說還沒有sketch的替代品。

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

題圖來自Unsplash,基於CC0協議