SHERPA Blog’da neler değişti?

SHERPA Blog’a son 5 yıl boyunca bir çok özellik ekledik. Basit bir blogdan, bir topluluk platformuna dönüşmesi için her zaman sağlam adımlarla ilerlemeyi tercih ettik. Sürekli değişen ve yenilenen yapımızı göz önünde bulundurduğumuzda, yepyeni bir arayüz tasarımı ve arayüz geliştirmesi sürecine girmenin temel amacımız olan içerik üretimini sekteye uğratacağını düşündüğümüzden, temel problemlerimize odaklanan kapsamlı ve verimli bir çalışmayla, SHERPA Blog’u arayüzünde bir dizi yenilik gerçekleştirdik. Bu süreçte attığımız en önemli adım, yazılımcı ve tasarımcıların bir arada çalışarak ve tüm süreci göz önüne alarak, ortak problemleri belirlemesini sağlamaktı.

2 yıl önce giriştiğimiz büyük güncelleme sürecinde de temel problemimiz, sonraki yeni geliştirmelere de temel olacak bir geliştirme alt yapısı oluşturmaktı. Bu yüzden işe, blogun en temel öğesi olan içerik detay sayfalarını iyileştirerek başladık. Bunu yaparken, aynı zamanda bize bir stil rehberi de sunacak şekilde çalıştık. Bu sayede 2 yıllık süreç boyunca kurduğumuz bu yapıyı yeni geliştirdiğimiz tüm özelliklerde kullanarak, olabildiğince hızlı bir üretim ortamı sağladık. Ancak arayüz tasarımımız, içerik tiplerimiz ve geliştirdiğimiz yeni özellikler arttıkça artık ihtiyaçlarımızı karşılayamaz hale geldi. Tüm bu süreç boyunca edindiğimiz birikimlerden faydalanarak ve kullanıcılarımızdan aldığımız geri bildirimleri de önümüze koyarak memnun olmadığımız unsurları belirledik.

Nelerden memnun değildik?

• İçerik listeleme formatımızda eksiklikler vardı ve listeleme tipleri kullanışlı değildi,
• Bir tasarım kılavuzumuz (style guide) olmasına karşın, içerik listeleme için kullanabileceğimiz bir arayüz bileşenimiz yoktu,
• Yeni eklenen video eğitim ve webinar gibi hayatımıza giren yeni ve farklı içerik türleri, içerik listeleme sayfasında kendine has özellikleriyle görüntülenemiyordu,
• Farklı listeleme ve içerik detay sayfası bileşenleri ortak bir şablon üzerinden yönetilemiyordu,
• Ortak bir şablonumuz olmadığı için, sayfa içeriklerini özelleştirmek ve yeni sayfalar üretmek zordu ve çok zaman alıyordu,
• Ana sayfamız, web sitemizin genelini karşılayacak şekilde oluşturulamıyordu,
• Geliştirme ortamındaki klasörleme yapısı karmaşıktı,
• Farklı cihazlarda görüntülenme ve okunabilirlik problemleri vardı.

Bu problemlerin tümünü 2 başlık altında topladık:

1. İçerik listeleme sayfalarının ve bileşenlerinde bir dil bütünlüğü olmaması
2. Web sitemizin, cihaz uyumluluğu konusunda sağlıklı bir yapı sunmaması

Yeni SHERPA Blog arayüzü. İncelemek için: https://sherpa.blog

Bu problemleri nasıl çözdük?

Bu güncelleme sürecinde, içerik listeleme sayfaları olarak kullandığımız kategori ve diğer taksonomi sayfalarını “en öncelikli problem olarak” belirledik. Mevcut yapıda, 5 farklı içerik tipi, 8 farklı özel taksonomi grubu ve bu farklı içerik tipleriyle bağlantılı 20 civarında özel alanımız (custom field) var. Bu yüzden, öncelikli olarak tek bir içerik gösterim elementini ele alarak bir içerik gösterim komponenti (bileşeni) oluşturmaya başladık.

Öncelikli olarak komponentlerimizin yapısını sağlıklı bir şekilde oluşturabilmek için hem yazılım hem de tasarım sürecinde şu 4 kuralı takip etmeye karar verdik.

Komponentler mutlaka,

• Tekrar kullanılabilir (reusable) olmalıdır.
• Her yerden erişilebilir (accessible) olmalıdır.
• Her sayfa ve kategori tipine göre en az eforla özelleştirilebilmelidir (customizable).
• Farklı ekran boyutuna ve durumuna göre düzgün görüntülenebilir (responsive) olmalıdır.

Belirlediğimiz bu 4 kural, tüm geliştirme ve tasarım sürecinde bize rehberlik etti. Bu 4 kuralın herhangi birinden saptığımızı fark ettiğimizde, bu sapmaya neden olan eksikliği kapatmak için komponenti tekrar düzenledik, hatta arayüz tasarımı sürecine geri giderek, bu çözüm üzerine yeniden tartışmaktan geri durmadık.

Her iki problemi de ortak yoldan çözebilmek için, komponenti bir şablon olarak oluşturduk. Bu şablonu, tüm site genelinde kullanılabilecek şekilde, hem CSS’de hem de WordPress tema yapısı içerisinde uygun bir şekilde konumlandırdık. Böylece oluşturduğumuz bu komponent şablonunu farklı farklı sayfa tiplerine uygun olarak kullanabilecek ve aynı zamanda, ihtiyaç duyduğumuz her durumda aynı şekilde erişilebilecek şekilde düzenledik. SHERPA Blog’da yer alan tüm sayfaları da bu şablona uygun olarak güncelledik.

Bu komponentin tüm farklı ekran çözünürlüklerinde doğru bir şekilde çalıştığından emin olduktan sonra komponentlerimizin yerleşimlerini, yeniden düzenlediğimiz ve sadeleştirdiğimiz grid (ızgara) yapısına uygun olarak düzenlemeye başladık. Bunu da tamamladıktan sonra, artık her ekran çözünürlüğünde, temel aldığımız grid yapısına göre tam uyumlu çalışan bir içerik komponentini elde etmiş olduk.

Bundan sonraki adım ise, içerik listeleme ve diğer taksonomi sayfalarının bu komponent yapısıyla uyumlu olarak geliştirilmesiydi. Bu, içerik komponentlerinin bir sayfadaki yerleşimini test etmemize de olanak sağladı. Yeni komponentlerimizi sayfalara uygularken karşılaştığımız problemlerden sonra, farklı içerik ve taksonomilere göre yukarıdaki 4 kurala uygunluğunu test ederek güncellemeler yaptık.

Sayfalar için de temel birer şablon oluşturduk. Komponentlerde olduğu gibi, sayfalar arasında da yukarıda bahsettiğimiz dört kritere uygun olarak bir temel sayfa şablonu geliştirdik.

Cihaz uyumluluğunu sağlamak

En önemli problemimizse, tüm cihazlarda kabul edilebilir bir görünüme ulaşabilmekti. Bu konuda yaşadığımız problemlerin uzun süredir fakrındaydık. Özellikle okunabilirlik konusunda farklı cihazlardaki deneyimi iyileştirebilmek için çok titiz bir çalışma yürüttük. SHERPA Blog’un temel amacı okunabilir bir deneyim sunmak olduğu için, tümüyle okuma deneyimine dayalı bir yapı kurmaya odaklandık.

Komponentlerin sağladığı esneklik sayesinde neredeyse tüm cihazlarada görüntülenme problemlerimizi çözdük. Daha önceki yapıda kullandığımız Bootstrap yerine daha sade ve yeni sayfa düzenimize göre özelleştirdiğimiz bir grid dosyası oluşturarak farklı cihazlardaki görünümleri daha kolay yönetebileceğimiz bir hale getirdik.

Klasörleme yapısı

Komponent yapısının tüm sisteme entegre edilmesinden sonra, optimizasyon sürecine adım attık. Bu aşamada tüm sayfa ve post komponent şablonlarını ortak bir yazım şekliyle (syntax) oluşturduk. Bu da, gereksiz oluşturulan ve sayfa hızını etkileyen CSS ve JS kodlarını daha kolay tespit edebilmemizi sağladı. Özellikle SCSS’in sağladığı olanaklarla SCSS dosya ve klasör yapısını, şablonlara göre tekrar düzenledik ve klasörleri atomik design prensibine göre küçükten büyüğe gidecek şekilde oluşturduk:

default_components(buttons.scss, links.scss etc.) → post-component.scss → page.scss → style.scss

Yaptığımız bu temizlik sonrasında:

• Tarayı tarafından yüklenen css miktarını yaklaşık %30 oranında azalttık. SCSS dosya ve klasör yapısını component ve sayfa şablonlarının yapısına göre tekrar yapılandırdık,
• Kullandığımız JS dosyalarını ve 3rd party eklenti ve kodlarını azalttık. JS kullanımında da %20’ye yakın tasarruf elde ettik,
• PHP ve WordPress tarafındaki dosyaları daha düzenli hale getirerek, taksonomi sayfalarındaki içerik listeleme yapılarını tamamen şablon dosyalara göre kullanmaya başladık,
• Toplam dosya boyutunda da %15’e yakın bir tasarruf elde ettik.

Erişilebilirlik

Erişilebilirlik konusu da hassasiyet gösterdiğimiz konulardan bir tanesi oldu. Özellikle içerik listeleme yapıları ve içerik detay sayfalarındaki erişilebilirlik testlerini yaptık ve hatalı alanların tümünü temizledik. Ekran okuyucular üzerinden yaptığımız testlerde de bu işlemlerin sağlamasını yaptık.

Şimdi sırada ne var?

Bu düzenlemelerin tamamı aslında bundan sonrasında yapacağımız yeni geliştirmeler için sağlıklı bir alt yapı hazırlamaktı. Tasarım ve geliştirme sürecini parçalı bir şekilde, alt projelere bölerek yaptık. Böylece, yeni içerik üretim sürecimizi zayıflatmadan; yazılımcı ve tasarımcı takım üyelerinin ortaklaşa ilerlemesiyle, ürünün problemlerine ve geliştirme sürecinde ortaya çıkan problemlere hızlı çözümler üretebildik.

Sıradaki hedefimiz, performans problemlerimiz olacak. Arayüzle ilgili yapacağımız kişiselleştirilebilir anasayfa, header düzenlemeleri, kullanıcı kayıt/giriş yap sürecindeki hatalar ve satın alma sürecinin iyileştirilmesi gibi birkaç güncellemeden sonra performans ile ilgili hatalara yoğunlaşacak ve daha performanslı bir SHERPA Blog deneyimi oluşturacağız.

Fatih Akgöze
Arayüz ve Altyapı Geliştirici
SHERPA Blog