Esnek Bileşenler Oluşturmak İçin Geliştirici Kararları

Gerçek dünyada içerik, tasarımlarda sunulan düzgün, mükemmel uyumlu içerikten genellikle çok farklıdır. Buna ek olarak, modern web'de kullanıcılar, oluşturduğumuz sitelere nasıl erişecekleri konusunda sürekli artan seçeneklere sahiptir.

Bu makalede, hem kullanıcıların hem de içerik yazarlarının ihtiyaçlarını göz önünde bulundurarak, bir metin ve medya bileşeni için görünüşte basit bir tasarım alma ve onu koda en iyi nasıl çevireceğimize karar verme sürecini ele alacağız. Nasıl kodlanacağına değil, geliştirme kararlarımızı belirleyecek faktörlere değinmeyeceğiz. Her adımda sormamız gereken soruları (hem kendimiz hem de diğer paydaşlar) dikkate alacağız.

Gelişim Zihniyetimizi Değiştirmek

Artık yalnızca “optimum” içerik veya tarama koşulları için tasarlayıp geliştiremiyoruz. Bunun yerine, web'in doğal esnekliğini ve öngörülemezliğini benimsemeli ve esnek bileşenler oluşturmalıyız. Statik maketler her senaryoya hitap edemez, bu nedenle pek çok tasarım kararı, geliştirme sırasında geliştiricilere düşer. Beğenin ya da beğenmeyin, bir UI geliştiricisiyseniz , bir tasarımcısınız - kendinizi bir tasarımcı olarak görmeseniz bile!

WordPress uzman web ajansı Atomic Smash'daki işimde, sağladığımız bileşenlerden maksimum esnekliğe ihtiyaç duyan müşteriler için web siteleri oluştururken, siteye hangi içeriği atarlarsa atsınlar sitenin hala harika görünmesini sağlıyoruz. Bazen bir tasarımı yorumlamak, tasarımcıdan fikirlerini daha fazla detaylandırmasını (hatta onları yeniden değerlendirmesini) istemek anlamına gelir. Diğer zamanlarda, anında tasarım kararları vermek veya bilgi ve deneyimlerimize dayanarak önerilerde bulunmak anlamına gelir. Bu vaka çalışmasında bu yaklaşımların uygun olabileceği bazı durumlara bakacağız.

Dizayn

Ürün açılış sayfalarında oldukça yaygın olarak görülen bir metin ve medya bileşeni için basit bir tasarımla başlıyoruz. Solda bir resim veya videodan ve sağda bir başlık, bir metin paragrafı ve bir harekete geçirici mesaj bağlantısı içeren bir sütundan oluşur. Bu tasarım, yeni bir beceri öğrenmek isteyen kişilerin bir öğretmen bulmasına yardımcı olan (kurgusal) bir başlangıç ​​içindir.

Not: Doğrudan koda atlamak ve bu bileşen için üzerinde durduğumuz tüm olası çözümleri görüntülemek istiyorsanız, onu bu Codepen demosunda bulabilirsiniz.

Düzen ve Sipariş

Tasarımcı, görüntünün sağda ve metin sütununun solda olması için diğer tüm bileşenlerin mizanpajının ters çevrilmesini şart koştu.

Ancak mobil düzende, resim her durumda metin içeriğinin üzerinde yığılır. Bu düzeni Grid veya flexbox kullanarak oluşturduğumuzu varsayarsak, düzeni her ikinci bileşen için yeniden sıralamak için flex-direction veya order özelliğini kullanabiliriz:

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

Bunların içeriği görsel olarak yeniden sıralasa da DOM sırasını değiştirmediğini akılda tutmakta fayda var. Bu, bir ekran okuyucu kullanarak siteye göz atan, kısmen görebilen bir kişi için, içeriğin sırası, soldan sağa, sağdan sola atlayarak mantıklı görünmeyebileceği anlamına gelir.

Kişisel olarak konuşursak, sütunlardan birindeki tek içeriğin bir resim olması durumunda, order özelliğini kullanmanın aşağı yukarı doğru olduğunu düşünüyorum. Ancak örneğin iki metin sütunumuz olsaydı, CSS ile yeniden sıralamak kafa karıştırıcı bir deneyime neden olabilir. Bu gibi durumlarda, bizim için mevcut olan başka seçeneklerimiz de var. Yapabiliriz:

1. Erişilebilirlik endişelerimizi dile getirin ve mobil düzenler için görsel sıranın masaüstü düzeniyle eşleşecek şekilde değiştirilmesini önerin.
2. DOM'deki öğeleri yeniden sıralamak için Javascript kullanın.

Ayrıca, siparişi :nth-child seçici aracılığıyla mı yoksa müşterinin siparişi kontrol etmesine izin mi vereceğimizi (örneğin bileşene bir sınıf ekleyerek) düşünmeliyiz. Her seçeneğin uygunluğu muhtemelen projeye bağlı olacaktır.

Farklı İçerik Uzunluklarıyla Başa Çıkma

Tasarımda metin içeriğinin görsele oranı oldukça tatmin edici. Görüntünün ideal bir en boy oranını korumasını sağlar. Ancak metin sunulandan daha uzun veya daha kısaysa ne olur? İlk önce eski ile ilgilenelim.

Daha Uzun İçerik

Seçtiğimiz CMS'deki metin alanına bir karakter sınırı koyabiliriz (eğer çok istekliysek), ancak bileşenimizde en azından bazı değişikliklere izin vermeliyiz. Daha uzun bir paragraf eklersek, karşıt medya sütunu birkaç yoldan biriyle davranabilir:

1. Resim veya video üstte kalır, aşağıya boşluk eklenir (şekil 1).
2. Görüntü veya video ortalanır ve üstte veya altta boşluk eklenir (şek. 2).
3. Görüntünün veya videonun oranları, bozulmayı önlemek ve görüntünün mevcut alanı doldurmasını sağlamak için object-fit: cover kullanılarak yüksekliğe uyacak şekilde ölçeklenir. Bu, görüntünün bazı bölümlerinin kırpılabileceği anlamına gelir (şekil 3).

Seçenek 3'ün görsel olarak en hoş olduğuna ve çoğunlukla içerik yazarlarının az miktarda kırpmanın kabul edilebilir olduğu durumlarda uygun görseller sağlayabileceklerine karar verdik. Ancak, önemli parçaların kırpılma riskinin daha fazla olduğu video içeriği için daha fazla zorluk teşkil ediyordu. Videonun orijinal en boy oranını koruyacağı ve sayfanın kenarına hizalamak yerine maksimum genişlikte tutulacağı tasarımın farklı bir varyasyonunu oluşturmak olan başka bir seçeneğe odaklandık.

İçerik yazarları, ihtiyaçlarına daha uygun olduğunda bu seçeneği tercih edebilir.

Ek olarak, bu seçeneği video yerine görselin kullanıldığı durumları da kapsayacak şekilde genişletmeyi seçtik. Müşteriye tasarımı olumsuz etkilemeden daha geniş bir yerleşim seçeneği yelpazesi sunar. Daha geniş sayfa bağlamında bakıldığında, bu bloklardan birkaçı bir sayfada kullanıldığında daha ilginç sayfalara izin veren bir gelişme olarak bile düşünülebilir.

Daha Kısa İçerik

Daha az içerikle uğraşmak biraz daha basittir, ancak yine de bize bazı sorunlar sunar. Metin içeriği daha kısa olduğunda görüntü nasıl davranmalıdır? Bileşenin toplam yüksekliğinin metin içeriği tarafından belirlenmesi için daha sığ hale mi gelmeli (şekil 4)? Yoksa görüntünün mektup kutusu haline gelmemesi veya görüntünün doğal, gerçek yüksekliğini almasına izin vermemek için minimum bir en boy oranı mı ayarlamalıyız? Bu durumda, metni merkeze mi yoksa üste mi hizalayacağımızı da düşünürüz (şekil 5 ve 5a).

Başlık Uzunluğu

Farklı uzunluklardaki başlıkları da test etmemiz gerektiğini unutmayalım. Tasarımda başlıklar kısa ve hızlıdır, nadiren ikinci bir satıra sarılır. Ancak bir başlık birkaç satır uzunluğundaysa veya içerik çok fazla uzun kelime kullanıyorsa ve bu da metnin farklı şekilde kaydırılmasına neden oluyorsa? Bu, özellikle kelimelerin İngilizce'den çok daha uzun olma eğiliminde olduğu Almanca gibi dillerde bir sorun olabilir. Tasarımdaki başlık yazı tipinin boyutu, bu düzende kullanıldığında uygun bir satır uzunluğuna izin veriyor mu? Uzun kelimeler sarıldığında tirelenmeli mi? Ahmad Shadeed'in bu makalesi, içerik uzunluğu konusunu ele alıyor ve CSS'de bununla başa çıkmanın yolları için bazı kullanışlı ipuçları içeriyor.

İçerik yazarlarının kendilerine uygun olan bir başlığı tamamen atlamalarına izin veriliyor mu? Bu bizi bir sonraki değerlendirmeye getiriyor.

İçeriği Atlamak

Bu bileşeni mümkün olduğunca esnek bir şekilde oluşturmak, içerik yazarlarının belirli alanları atlayabilmelerini ve yine de tasarımın düzgün görünmesini ve çalışmasını sağlamak anlamına gelir. İstemcinin bu bileşeni vahşi ortamda kullanırken gövde metnini, bağlantıyı ve hatta başlığı atlamak isteyebileceği makul görünmektedir. Bileşenimizin stres altında kırılmayacağından emin olabilmemiz için akla gelebilecek her içerik kombinasyonunu test etmeye özen göstermeliyiz. Alan içeriği olmadığında boş HTML etiketleri oluşturmadığımızdan emin olmak iyi bir uygulamadır. Bu, öngörülemeyen düzen hatalarından kaçınmamıza yardımcı olacaktır.

İçerik yazarlarını CMS'de "zorunlu" alanlarla kısıtlayabiliriz , ancak belki de bir müşterinin görseli çıkarmayı seçebileceği veya tam tersine metin içeriğinin olmadığı senaryoları da düşünmek isteyebiliriz. Onlara bu seçenekleri sunmak faydalı olabilir. Bu durumlarda bileşeni nasıl oluşturmayı seçebileceğimize dair bir örnek:

Metni biraz daha girintili hale getirerek ve gövde metninin genişliğini artırarak, görüntü olmadığında bile dengeli hissetmesini sağlayabiliriz.

Çoklu Bağlantılar

İçeriği atlamak bir senaryodur. Ancak Atomic Smash'ta, müşterilerin bileşene birden fazla bağlantı ekleme seçeneğini daha sık istediğini gördük. Bu bize başka bir seçenek sunuyor: birden çok bağlantı nasıl düzenlenir? Bunları yan yana mı yerleştiriyoruz (şekil 8) yoksa dikey olarak mı istifliyoruz (şekil 8a)?

Çılgınca farklı uzunluklardaki bağlantı başlıklarıyla nasıl başa çıkıyoruz? Her iki bağlantının genişliğini en uzun olanın maksimum genişliğine ayarlamak güzel bir numaradır (şekil 9). (Bu makale tam da bunu kapsamaktadır.) Bu, dikey olarak yığılmış düğmeler için iyi sonuç verirken, onları yatay olarak yerleştirmek bize daha fazla seçenek sunar (şekil 9a).

Bunları ayırt etmek için ikincil bir bağlantı stiline ihtiyacımız var mı? Bunların hepsi dikkate alınması gereken sorulardır.

Ayrıca (tek bir bağlantı olması durumunda) bağlantının tıklanabilir alanının aslında tüm bileşeni kapsayıp kapsamaması gerektiğini düşünmemiz gerekebilir - böylece kullanıcılar bağlantıyı etkinleştirmek için herhangi bir yere tıklayabilirler. Bu seçim belki de daha geniş bağlama bağlı olabilir. Kart tabanlı kullanıcı arayüzlerinde kesinlikle yaygındır.

Video

Bileşen, statik bir görüntü yerine video için kullanıldığında, tasarımın bazı önemli bilgileri atladığını fark edebiliriz. Video oynatma nasıl kontrol edilir? Üzerinde gezinme? Kaydırmada otomatik oynatılıyor mu? Kullanıcının görebileceği kontroller olmalı mı?

Video fareyle üzerine gelindiğinde oynatılırsa, fareyle üzerine gelme yetenekleri olmayan bir cihazın kullanıcısının video içeriğine nasıl eriştiğini düşünmeliyiz. Alternatif olarak, video otomatik olarak oynatılırsa, vestibüler rahatsızlıklardan muzdarip olabilecek (veya sadece sarsıcı animasyonlardan kaçınmak isteyebilecek) azaltılmış hareketi tercih eden kullanıcılar için bunu engellemeyi düşünmeliyiz. Ayrıca tüm kullanıcılara istedikleri zaman videoyu durdurmaları için bir yol sağlamalıyız.

Bağlam içine koymak

Web tasarımı söz konusu olduğunda bileşenlere bu kadar yakından odaklanmanın bir sorunu, bazen oluşturduğumuz bileşenlerin genel web sayfası bağlamında nasıl görüneceğini düşünmeyi unutuyoruz. Hem aynı türdeki bileşenler arasındaki hem de diğer bileşenlerin serpiştirildiği bir sayfa düzenindeki aralığı dikkate almamız gerekecek.

Bu metin ve medya bileşenleri, göz alıcı bir renk sıçraması ve aksi takdirde doğrusal bir düzenden bir kopuş yaratarak, dikkatli bir şekilde kullanılmak üzere tasarlanmıştır. Ancak WordPress kullanarak bir içerik yazarı, bu bileşenlerden başka hiçbir şeyden oluşan bir sayfanın tamamını oluşturmaya kolayca karar verebilir. Bu, oldukça sıkıcı görünebilir ve umduğumuz etkiyi hiç de sağlayamayabilir!

Oluşturma işlemi sırasında arka plan rengini atlamak için bir seçenek eklemeye karar verdik. Bu, sayfayı bölmemize ve daha ilginç hale getirmemize olanak tanır:

Müşteriye daha yaratıcı kontrol sağlamak için :nth-child kullanarak bir kalıbı uygulayabilir veya CMS'ye bir alan ekleyebiliriz.

Bu, orijinal tasarımın bir parçası olmasa da, tasarımcı ve geliştirici arasındaki açık iletişim hattının, daha esnek ve sağlam tasarımlar açısından daha iyi sonuçlar yaratmaya yardımcı olabileceğini gösteriyor.

WYSIWYG Metin Stilleri

İçeriği değerlendirirken, yalnızca metnin uzunluğunu değil, gövde metni alanında izin verilen gerçek HTML öğelerini de dikkate almamız gerekir. İçerik yazarları, gövde kopyasına birden çok paragraf, bağlantı bağlantıları, listeler ve daha fazlasını eklemek isteyebilir. Atomic Smash'ta, bu alanlar için birçok farklı öğeye izin verebilen bir WYSIWYG (Ne Görüyorsanız Onu Alırsınız) veya zengin metin alanı sağlamayı seviyoruz. Kullanılan tüm arka plan renklerinde yeterli renk kontrastının test edilmesi de dahil olmak üzere, farklı içerik türleri ve uygun stille test etmek önemlidir.

Toplama

Bu görünüşte basit bileşeni oluşturmakla ilgili birçok farklı karara değindik. Burada ele almadığımız birkaç tane daha düşünebilirsiniz! Tasarımın her yönünü ve bağlam içinde nasıl kullanılabileceğini göz önünde bulundurarak, daha mutlu müşterilerle sonuçlanacağını umduğumuz çok daha çok yönlü bir şey elde ettik!

Bazen, bir tasarımdan ne kadar çok şey çıkarılırsa, bir geliştiriciden o kadar fazla zaman ve dikkat gerekecektir. Aşağıda, yararlı bulabileceğiniz bir bileşen oluştururken test edilecek ve sorulacak şeylerin bir kontrol listesini bir araya getirdim. Farklı bileşenler için de uyarlanabilir.

Görünen basitliğin ötesine geçebilmek, bir bileşeni bileşenlerine ayırabilmek, önemli sorular sorabilmek (herhangi bir geliştirme gerçekleşmeden önce bile) ve hatta gelecekteki kullanımları düşünebilmek, web siteleri oluştururken herhangi bir geliştiriciye iyi hizmet edecek becerilerdir - ve gerektiğinde çok daha doğru tahminler sağlamanıza yardımcı olacaktır. İyi ekip iletişimi ve güçlü bir işbirliği süreci, dayanıklı siteler oluşturmak için paha biçilmezdir, ancak sonuç, bu kültürü beslemeye yatırım yapmaya değer hale getirir. Tasarım ve inşa süreçlerimize esneklik katalım.

Kontrol Listesi

Test edilecek şeyler:

1. Düzenin erişilebilirliği (mobil ve masaüstü).
2. Farklı içsel en boy oranlarına sahip görüntüler — uygun şekilde kırpılmışlar mı?
3. Daha uzun ve daha kısa gövde metni (birden çok paragraf dahil).
4. Daha uzun ve daha kısa başlık (çeşitli kelime uzunlukları dahil).
5. Başlığı, gövde metnini, bağlantıları ve resmi çıkarma (çeşitli olarak).
6. Birden çok bağlantı (farklı uzunluklarda bağlantı metni dahil).
7. Video içeriğinin erişilebilirliği.
8. WYSIWYG metin içeriği (gövde metnine bağlantılar, listeler vb. dahil).
9. Bağlamda test edin — birden çok bileşeni (farklı içerik seçenekleriyle) ve ayrıca sayfa düzenine karıştırılmış diğer bileşenleri dahil edin.