聊天背景圖聊天回複語?看似簡單，無人注意過的縮略圖也隐藏着有趣的細節，今天小編就來聊一聊關于聊天背景圖聊天回複語?接下來我們就一起去研究一下吧!

聊天背景圖聊天回複語

看似簡單，無人注意過的縮略圖也隐藏着有趣的細節

這裡我們主要讨論聊天列表中展示的縮略圖，縮略圖通常是将圖片内容進行一定的縮小展現，或裁剪展現，主要有兩個目的，一是提供一定的預覽功能，二是節省屏幕展示空間、節省流量。

用戶發送的圖片長短不一，有正方形的，有豎長形的，有橫寬型的，甚至有不規則形的（比如一些用戶保持的 png 表情）如何設計一個合理的縮略圖展示規則能最大可能的滿足展示需求，又讓整個聊天列表整齊美觀呢？

首先我們來看看我們想在聊天中提供的體驗：

單個圖片更多的圖片内容信息展示

多張圖片更好的浏覽定位找尋

同時發送多張圖片更高效的展示

如果我們希望盡可能保留圖片的長寬比樣式，在聊天列表中錯落有緻地展示，則我們需要對橫向和縱向圖片的長和寬都做相應的阈值限制。

在 Facebook Messenger 的例子中，我們發送了以下一組測試圖片：

有常見照片的 4:3 比例，也有常見截圖的 16:9 比例，還有 21:9 這樣超長/超寬圖片。

裁切阈值方面：我們發現，對于豎向圖，Facebook Messenger 設定了一個比例的阈值，長圖超出 5:3 比例會被裁切、寬圖超過 1:2 會被裁切。未超過這個比例值，圖片的内容将被完整縮放。

展示尺寸方面，我們發現：

對于豎向圖：

對于橫向圖：

這種方案，最大地兼顧了圖片原始比例和圖片内容。

限定寬和高的策略也在微信縮略圖規則中體現：

與 Messenger 不同之處在于：：

微信的裁切比例阈值設定更寬松一點，21:9 的比例都未被裁切，這會照顧到更多的圖片比例，除非是超長、超寬，其他都能在微信中展示完整圖片信息，完整縮放。

Messenger 将高度和寬度分别設定，而微信簡化了寬和高的阈值設定，以正方形作為基準，去限定高度和寬度，不去考慮是橫向圖還是縱向圖，換一種說法，即: 比例較大的邊等于正方形的邊，這意味着你在微信中能産生最大顯示面積的是正方形圖片，并且無需為正方形做特殊判斷，Messenger 則需要将正方形視作橫向圖片的寬度規則，缺點是，正方形展示成了最大面積，其他比例圖片都較小，似乎「有失公平」。微信設定的高度和寬度阈值較 Messenger 來說小很多，這樣在一屏幕中可以展示更多的圖片縮略圖；但同時，縮略圖太小可能無法識别信息。

微博在私信、發微博的縮略圖規則和和微信是一模一樣的；Telegram 也幾乎一樣，隻是将「正方形」設置的大了一些。

所以設定多大的寬高阈值取決于我們的 App 的使用場景和我們的取舍，是經常出現圖片還是偶爾出現，是想在一屏幕中更多的展示圖片數量，方面用戶快速浏覽時檢索定位，還是希望縮略圖展示更明确的信息。

如果我們希望一堆圖片展示時能盡可能整齊，而不是像以上兩種策略一樣橫橫豎豎，可能簡化一個維度會好一些。

在知乎 Live 的縮略圖策略中，對于橫向圖、豎向圖，都隻設定了寬度的阈值，沒有向微信或者 Messenger 那樣設定高度的阈值，高度是靠比例阈值動态變化的，豎向圖超過 3:2 比例的圖片就會被裁剪；橫向圖超過 1:2 的比例就會被裁剪。

從展示效果看來，設定統一的寬度讓發送的圖片無論是橫向還是豎向在一屏幕内展示的都很整齊。

缺點是展示的圖片大小的排序是 縱向圖>正方形>橫向圖，對橫向圖不友好，縱向圖占據了屏幕較多面積，不利于多張圖片的快速縱覽，但卻無法縮小寬度阈值，因為這樣的話會連帶橫向圖展示的更小。

如果你發現用戶更愛發縱向圖，且沒有頻繁發圖，需要快速滾動去找尋圖片的目的的話，那麼這個方案可能适合你。

一些産品的縮略圖寬度并不是定值，而是一個相對位置的距離，甚至相對位置的百分比，這樣展示較為靈活，能充分利用不同設備的不同屏幕尺寸。

同時，基于相對位置的寬度通常會設定一個最大值，超過最大值則不再放大，以防在 iPad 等設備上展示過大：

如果再進一步，針對豎屏、橫屏單獨設定相對位置和最大寬度，則在橫屏也有較好的體驗。

同理，如果用戶發送的是小尺寸的表情包，不滿足我們的寬高設定，難道我們也要把表情包拉伸到那麼大嗎？所以，針對小于我們設定的寬高阈值的圖片，我們也應該判斷其不應該被縮放。

以上都是對圖片做了相應的裁切，也有不想裁剪，原模原樣想保留原始比例的。

在微博 Web 版的早期版本中，為超長超寬圖片設定了最大限時值，再将等比縮放的内容塞進去，四周進行空白填充，所以發送寬高比再大的圖片，都會完整展示比例，隻是可能這個縮略圖在根本沒法獲取有效信息，完全喪失了「縮略圖」的功能了。

為解決用戶連續發圖後，在屏幕内快速浏覽找尋的方便性問題，一些 App 傾向合并多次發送的圖片，例如iMessage、 Facebook Messenger 、知乎 Live

iMessage 的合并看上去隻是為了減少兩次發送之間的間隔空間，而縮略規則 則與發送單張圖片無異，隻是在四周的邊角上視為一體做圓角處理。

Facebook Messenger 與知乎 Live 則是常見的的九宮格方式（這更多的在微信朋友圈見到），正方形的邊角的兩條邊不與其他圖片接壤時，帶有 Raduis ，不同的是，Messenger 多出來的某張圖片是靠向發送者，而知乎 Live 則不論發送者還是查看者都靠左，比較兩者，Messenger 符合直覺，而知乎 Live 則照顧到了多方視角視角的圖片順序統一問題，畢竟，會有人浏覽九宮格圖片的視覺路徑是 S 型 ，就會造成理解順序的偏差。

小小縮略圖也有着這麼多的考量，如何設計縮略圖，還是取決于産品的實際需求和使用場景。

希望這篇文章能帶給大家收獲，第一次寫設計文章 ~ 撒花~~

作者：銀光，知乎Live産品設計師

本文由 @銀光 原創發布于人人都是産品經理。未經許可，禁止轉載

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!