看似簡單，無人注意過的縮略圖也隱藏著有趣的細(xì)節(jié)
這里我們主要討論聊天列表中展示的縮略圖，縮略圖通常是將圖片內(nèi)容進(jìn)行一定的縮小展現(xiàn)，或裁剪展現(xiàn)，主要有兩個目的，一是提供一定的預(yù)覽功能，二是節(jié)省屏幕展示空間、節(jié)省流量。
用戶發(fā)送的圖片長短不一，有正方形的，有豎長形的，有橫寬型的，甚至有不規(guī)則形的（比如一些用戶保持的 png 表情）如何設(shè)計(jì)一個合理的縮略圖展示規(guī)則能最大可能的滿足展示需求，又讓整個聊天列表整齊美觀呢？
首先我們來看看我們想在聊天中提供的體驗(yàn)：
· 單個圖片更多的圖片內(nèi)容信息展示
· 多張圖片更好的瀏覽定位找尋
· 同時發(fā)送多張圖片更高效的展示
如果我們希望盡可能保留圖片的長寬比樣式，在聊天列表中錯落有致地展示，則我們需要對橫向和縱向圖片的長和寬都做相應(yīng)的閾值限制。
在 Facebook Messenger 的例子中，我們發(fā)送了以下一組測試圖片：
有常見照片的 4:3 比例，也有常見截圖的 16:9 比例，還有 21:9 這樣超長/超寬圖片。
裁切閾值方面：我們發(fā)現(xiàn)：
對于豎向圖，F(xiàn)acebook Messenger 設(shè)定了一個比例的閾值，長圖超出 5:3 比例會被裁切、寬圖超過 1:2 會被裁切。未超過這個比例值，圖片的內(nèi)容將被完整縮放。
展示尺寸方面，我們發(fā)現(xiàn)：
· 對于豎向圖
高度固定為 300pt，寬度是根據(jù)圖片比例動態(tài)變化的。
· 對于橫向圖
寬度是固定為 264pt，高度是根據(jù)圖片比例動態(tài)變化的。
這種方案中，最大地兼顧了圖片原始比例和圖片內(nèi)容。
限定寬和高的策略也在微信縮略圖規(guī)則中體現(xiàn)
與 Messenger 不同之處在于，
微信的裁切比例閾值設(shè)定更寬松一點(diǎn)，21:9 的比例都未被裁切，這會照顧到更多的圖片比例，除非是超長、超寬，其他都能在微信中展示完整圖片信息，完整縮放。
Messenger 將高度和寬度分別設(shè)定，而微信簡化了寬和高的閾值設(shè)定，以正方形作為基準(zhǔn)，去限定高度和寬度，不去考慮是橫向圖還是縱向圖，換一種說話，即比例較大的邊等于正方形的邊，這意味著你在微信中能產(chǎn)生最大顯示面積的是正方形圖片，并且無需為正方形做特殊判斷，Messenger 則需要將正方形視作橫向圖片的寬度規(guī)則，缺點(diǎn)是，正方形展示成了最大面積，其他比例圖片都較小，似乎「有失公平」。微信設(shè)定的高度和寬度閾值較 Messenger 來說小很多，這樣在一屏幕中可以展示更多的圖片縮略圖，但同時，縮略圖太小可能無法識別信息。
微博在私信、發(fā)微博的縮略圖規(guī)則和和微信是一模一樣的；Telegram 也幾乎一樣，只是將「正方形」設(shè)置的大了一些。
所以設(shè)定多大的寬高閾值取決于我們的 App 的使用場景和我們的取舍，是經(jīng)常出現(xiàn)圖片還是偶爾出現(xiàn)，是想在一屏幕中更多的展示圖片數(shù)量，方面用戶快速瀏覽時檢索定位，還是希望縮略圖展示更明確的信息。
如果我們希望一堆圖片展示時能盡可能整齊，而不是像以上兩種策略一樣橫橫豎豎，可能簡化一個維度會好一些。
在知乎 Live 的縮略圖策略中，對于橫向圖、豎向圖，都只設(shè)定了寬度的閾值，沒有向微信或者 Messenger 那樣設(shè)定高度的閾值，高度是靠比例閾值動態(tài)變化的，豎向圖超過 3:2 比例的圖片就會被裁剪；橫向圖超過 1:2 的比例就會被裁剪。
從展示效果看來，設(shè)定統(tǒng)一的寬度讓發(fā)送的圖片無論是橫向還是豎向在一屏幕內(nèi)展示的都很整齊。
缺點(diǎn)是展示的圖片大小的排序是 縱向圖>正方形>橫向圖，對橫向圖不友好，縱向圖占據(jù)了屏幕較多面積，不利于多張圖片的快速縱覽，但卻無法縮小寬度閾值，因?yàn)檫@樣的話會連帶橫向圖展示的更小。
如果你發(fā)現(xiàn)用戶更愛發(fā)縱向圖，且沒有頻繁發(fā)圖，需要快速滾動去找尋圖片的目的的話，那么這個方案可能適合你。
一些產(chǎn)品的縮略圖寬度并不是定值，而是一個相對位置的距離，甚至相對位置的百分比，這樣展示較為靈活，能充分利用不同設(shè)備的不同屏幕尺寸。
同時，基于相對位置的寬度通常會設(shè)定一個最大值，超過最大值則不再放大，以防在 iPad 等設(shè)備上展示過大：
如果再進(jìn)一步，針對豎屏、橫屏單獨(dú)設(shè)定相對位置和最大寬度，則在橫屏也有較好的體驗(yàn)。
同理，如果用戶發(fā)送的是小尺寸的表情包，不滿足我們的寬高設(shè)定，難道我們也要把表情包拉伸到那么大嗎？所以，針對小于我們設(shè)定的寬高閾值的圖片，我們也應(yīng)該判斷其不應(yīng)該被縮放。
以上都是對圖片做了相應(yīng)的裁切，也有不想裁剪，原模原樣想保留原始比例的。
在微博 Web 版的早期版本中，為超長超寬圖片設(shè)定了最大限時值，再將等比縮放的內(nèi)容塞進(jìn)去，四周進(jìn)行空白填充，所以發(fā)送寬高比再大的圖片，都會完整展示比例，只是可能這個縮略圖在根本沒法獲取有效信息，完全喪失了「縮略圖」的功能了。
為解決用戶連續(xù)發(fā)圖后，在屏幕內(nèi)快速瀏覽找尋的方便性問題，一些 App 傾向合并多次發(fā)送的圖片，例如iMessage、 Facebook Messenger 、知乎 Live
iMessage 的合并看上去只是為了減少兩次發(fā)送之間的間隔空間，而縮略規(guī)則 則與發(fā)送單張圖片無異，只是在四周的邊角上視為一體做圓角處理。
Facebook Messenger 與知乎 Live 則是常見的的九宮格方式（這更多的在微信朋友圈見到），正方形的邊角的兩條邊不與其他圖片接壤時，帶有 Raduis ，不同的是，Messenger 多出來的某張圖片是靠向發(fā)送者，而知乎 Live 則不論發(fā)送者還是查看者都靠左，比較兩者，Messenger 符合直覺，而知乎 Live 則照顧到了多方視角視角的圖片順序統(tǒng)一問題，畢竟，會有人瀏覽九宮格圖片的視覺路徑是 S 型 ，就會造成理解順序的偏差。
小小縮略圖也有著這么多的考量，如何設(shè)計(jì)縮略圖，還是取決于產(chǎn)品的實(shí)際需求和使用場景，希望這篇文章能帶給大家收獲，第一次寫設(shè)計(jì)文章 ~ 撒花~~
