開發人員構建靈活組件的決策

在現實世界中，內容通常與設計中呈現的整潔、完美契合的內容大相徑庭。 除此之外，在現代網絡上，用戶對於如何訪問我們構建的網站的選擇範圍越來越廣。

在本文中，我們將介紹一個看似簡單的文本和媒體組件設計過程，並決定如何最好地將其轉換為代碼，同時牢記用戶和內容作者的需求。 我們不會深入研究如何對其進行編碼——而是將決定我們的開發決策的因素。 我們將在每一步考慮我們需要問的問題（我們自己和其他利益相關者）。

改變我們的發展心態

我們再也不能只為“最佳”內容或瀏覽條件進行設計和開發。 相反，我們必須接受網絡固有的靈活性和不可預測性，並構建彈性組件。 靜態模型無法滿足所有場景，因此許多設計決策在構建時就落到了開發人員手中。 不管你喜不喜歡，如果你是一名 UI 開發人員，那麼你就是一名設計師——即使你不認為自己是一名設計師！

我在 WordPress 專業網絡機構Atomic Smash的工作中，我們為需要我們提供的組件提供最大靈活性的客戶構建網站，同時確保網站仍然看起來很棒，無論他們向其投放什麼內容。 有時解釋設計意味著要求設計師進一步闡述他們的想法（甚至重新評估它們）。 其他時候，這意味著即時做出設計決策或根據我們的知識和經驗提出建議。 我們將看看這些方法在本案例研究中可能適用的某些情況。

該設計

我們從一個簡單的文本和媒體組件設計開始——這在產品登陸頁面上很常見。 它由左側的圖像或視頻和右側的列組成，該列包含標題、一段文本和一個號召性用語鏈接。 這個設計是為一個（虛構的）創業公司設計的，它可以幫助想要學習新技能的人找到導師。

注意：如果你想直接跳轉到代碼並查看我們為這個組件設計的所有可能的解決方案，你可以在這個 Codepen 演示中找到它。

佈局和順序

設計者規定，所有其他組件都應翻轉佈局，使圖像在右側，文本列在左側。

然而，在移動佈局中，圖像在所有情況下都堆疊在文本內容之上。 假設我們使用 Grid 或 flexbox 構建此佈局，我們可以使用flex-direction或order屬性為每隔一個組件重新排序佈局：

 .text-and-media:nth-child(even) { flex-direction: row-reverse; }

值得記住的是，雖然這些會在視覺上重新排序內容，但它不會改變 DOM 順序。 這意味著對於使用屏幕閱讀器瀏覽網站的弱視者來說，內容的順序可能看起來不合邏輯，從左到右跳到右到左。

就個人而言，在其中一個列中唯一的內容是圖像的情況下，我覺得使用order屬性或多或少是可以的。 但是，如果我們有兩列文本，例如，使用 CSS 重新排序可能會產生令人困惑的體驗。 在這些情況下，我們還有其他一些可用的選項。 我們可以：

1. 提出我們的可訪問性問題並建議對於移動佈局更改視覺順序以匹配桌面順序。
2. 使用 Javascript 對 DOM 中的元素進行重新排序。

我們還需要考慮是通過:nth-child選擇器強制執行順序還是允許客戶端控制順序（例如，通過向組件添加一個類）。 每個選項的適用性可能取決於項目。

處理不同的內容長度

在設計上，文字內容與圖片的比例相當討喜。 它允許圖像保持理想的縱橫比。 但是，如果文本比呈現的更長或更短，會發生什麼？ 讓我們先處理前者。

更長的內容

我們可以在我們選擇的 CMS 中設置文本字段的字符限制（如果我們願意的話），但我們應該至少允許我們的組件有一些變化。 如果我們添加更長的段落，相反的媒體欄可能會以以下幾種方式之一表現：

1. 圖像或視頻保留在頂部，而下方添加空間（圖 1）。
2. 圖像或視頻居中，在頂部或底部增加空間（圖 2）。
3. 使用object-fit: cover縮放圖像或視頻的比例以匹配高度，以防止失真並確保圖像填充可用空間。 這意味著圖像的某些部分可能會被剪裁（圖 3）。

我們認為選項 3 在視覺上是最令人愉悅的，並且在大多數情況下，內容作者將能夠在可以接受少量剪輯的情況下獲取適當的圖像。 但它對視頻內容提出了更大的挑戰，其中重要部分可能被剪輯的風險更大。 我們選擇了另一種選擇，即創建一個不同的設計變體，其中視頻將保持其原始縱橫比，並包含在最大寬度內，而不是與頁面邊緣對齊。

當它更適合他們的需要時，內容作者可以選擇此選項。

此外，我們選擇將此選擇擴展到使用圖像而不是視頻的情況。 它為客戶提供了更廣泛的佈局選項，而不會對設計產生不利影響。 在更廣泛的頁面上下文中看到它甚至可以被認為是一種改進，當在頁面上使用這些塊中的幾個時，允許更多有趣的頁面。

較短的內容

處理較少的內容稍微簡單一些，但仍然給我們帶來了一些問題。 當文本內容較短時，圖像應該如何表現？ 它是否應該變淺，以便組件的整體高度由文本內容決定（圖 4）？ 或者我們應該設置一個最小縱橫比，這樣圖像就不會變成信箱，或者讓圖像佔據其自然的、固有的高度？ 在這種情況下，我們還要考慮將文本居中對齊還是頂部對齊（圖 5 和 5a）。

標題長度

別忘了我們還需要測試不同長度的標題。 在設計中，標題短小精悍，很少換行。 但是如果一個標題有幾行長，或者內容使用了很多長詞，導致文本換行不同怎麼辦？ 這在諸如德語之類的語言中尤其是一個問題，例如，其中的單詞往往比英語長得多。 在此佈局中使用時，設計中的標題字體大小是否允許適當的行長？ 長詞在換行時應該連字符嗎？ Ahmad Shadeed 的這篇文章解決了內容長度的問題，並包含了一些在 CSS 中處理它的實用技巧。

是否允許內容作者在適合他們的地方完全省略標題？ 這將我們帶到下一個考慮因素。

省略內容

盡可能靈活地構建此組件意味著確保內容作者可以省略某些字段並且仍然具有正確的設計外觀和功能。 在野外使用此組件時，客戶端可能希望省略正文、鏈接甚至標題，這似乎是合理的。 我們需要注意對每一種可能的內容組合進行測試，這樣我們才能確信我們的組件不會在壓力下崩潰。 當字段內容不存在時，確保我們不會呈現空的 HTML 標記是一種很好的做法。 這將幫助我們避免不可預見的佈局錯誤。

我們可以在 CMS 中使用“必填”字段來限制內容作者，但也許我們可能還希望考慮客戶可能選擇省略圖像，或者相反，沒有任何文本內容的場景？ 為他們提供這些選項可能會有所幫助。 下面是一個示例，說明在這些情況下我們如何選擇渲染組件：

通過稍微縮進文本並增加正文的寬度，即使沒有圖像，我們也可以保持平衡。

多個鏈接

省略內容是一種情況。 但在 Atomic Smash，我們發現客戶更經常希望選擇向組件添加多個鏈接。 這給我們提供了另一種選擇：如何佈局多個鏈接？ 我們是並排放置它們（圖 8），還是垂直堆疊（圖 8a）？

我們如何處理長度差異很大的鏈接標題？ 一個不錯的技巧是將兩個鏈接的寬度設置為最長的最大寬度（圖 9）。 （本文僅介紹了這一點。）這適用於垂直堆疊的按鈕，而水平放置它們為我們提供了更多選擇（圖 9a）。

我們是否需要輔助鏈接樣式來區分它們？ 這些都是需要考慮的問題。

我們可能還需要考慮（在單個鏈接的情況下）實際上，鏈接的可點擊區域是否應該包含整個組件——以便用戶可以單擊它的任意位置來激活鏈接。 這種選擇可能取決於更廣泛的背景。 這在基於卡片的 UI 中當然很常見。

視頻

當組件用於視頻而不是靜態圖像時，我們可能會注意到設計省略了一些關鍵信息。 視頻播放是如何控制的？ 懸停？ 它會在滾動時自動播放嗎？ 是否應該有用戶可見的控件？

如果視頻在懸停時播放，我們必須考慮沒有懸停功能的設備的用戶如何訪問視頻內容。 或者，如果視頻自動播放，我們應該考慮為喜歡減少運動的用戶防止這種情況，他們可能患有前庭疾病（或者可能只是希望避免不和諧的動畫）。 我們還應該為所有用戶提供一種在他們願意時停止視頻的方法。

把它放在上下文中

在網頁設計中如此關注組件的一個問題是，有時我們忘記考慮我們構建的組件將如何出現在整個網頁的上下文中。 我們需要考慮間距，既包括相同類型的組件之間，也包括在其他組件散佈的頁面佈局中。

這些文本和媒體組件旨在謹慎使用，創造出引人注目的色彩飛濺，並打破原本線性的佈局。 但是使用 WordPress，內容作者可以輕鬆地決定構建一個僅由這些組件組成的整個頁面。 這可能最終看起來相當乏味，根本不是我們希望的效果！

在構建過程中，我們決定添加一個選項來省略背景顏色。 這使我們能夠分解頁面並使其更有趣：

我們可以使用:nth-child強制執行模式，也可以在 CMS 中添加一個字段，以賦予客戶更多的創意控制權。

雖然這不是原始設計的一部分，但它表明設計師和開發人員之間的開放式溝通可以幫助在更靈活和健壯的設計方面創造更好的結果。

所見即所得的文本樣式

在考慮內容時，我們不僅需要考慮文本的長度，還需要考慮正文文本字段中可能允許的實際 HTML 元素。 內容作者可能希望在正文中添加多個段落、錨鏈接、列表等。 在 Atomic Smash，我們喜歡為這些區域提供 WYSIWYG（所見即所得）或富文本字段，它可以允許許多不同的元素。 測試不同類型的內容和適當的樣式非常重要——包括測試所有使用的背景顏色是否有足夠的顏色對比度。

包起來

我們已經討論了構建這個看似簡單的組件所涉及的許多不同決策。 您甚至可以想到我們在這裡沒有介紹的其他一些內容！ 通過考慮設計的各個方面以及如何在上下文中使用它，我們最終得到了更多功能的東西，希望這會帶來更快樂的客戶！

有時，設計中省略的內容越多，開發人員需要的時間和精力就越多。 我在下面整理了一個清單，列出了構建組件時要測試和提問的事項，您可能會覺得這很有用。 它也可以適用於不同的組件。

能夠超越表面上的簡單性，將組件分解為其組成部分，提出關鍵問題（甚至在任何開發發生之前），甚至考慮未來的用途，這些都是在構建網站時為任何開發人員提供良好服務的技能 - 並且將幫助您在需要時提供更準確的估計。 良好的團隊溝通和強大的協作流程對於構建彈性站點非常寶貴，但最終結果值得投資於培育這種文化。 讓我們將靈活性融入我們的設計和構建過程。

清單

要測試的東西：

1. 佈局的可訪問性（移動和桌面）。
2. 不同固有縱橫比的圖像——它們是否被適當地裁剪？
3. 更長和更短的正文（包括多個段落）。
4. 更長和更短的標題（包括各種字長）。
5. 省略（各種）標題、正文、鏈接和圖像。
6. 多個鏈接（包括不同長度的鏈接文本）。
7. 視頻內容的可訪問性。
8. 所見即所得的文本內容（包括正文中的鏈接、列表等）。
9. 在上下文中測試——包括多個組件（具有不同的內容選項），以及混合到頁面佈局中的其他組件。