Duyarlı tasarım sadece araçlarımıza ve web tasarım ve geliştirmeye yaklaşımlarımıza meydan okumakla kalmaz, aynı zamanda içerik planlama ve yönetme yöntemlerimizi gözden geçirmemize de zorlar. Yeni iş akışları doğru araçları gerektirir. İlk düşündüğünüzde, bu tamamen yeni içerik yönetim sistemleri (CMS) ve yayınlama platformları için bir fırsat yaratır (ve yakın gelecekte de bunların çoğunu göreceğiz). Ancak, bir CMS'den diğerine göç etmiş olan herkes, sürecin ağrısız olmadığını çok iyi bilir. Bu yüzden, uyarlanabilir içerik oluşturmamıza ve yönetmemize yardımcı olmak için WordPress gibi tanıdık ve popüler bir CMS'yi uyarlayabilir miyiz?
İlk olarak, işleri düz bir şekilde almamız gerekecek. Uyarlamalı içerik ne anlama geliyor ve duyarlı tasarım çağında neden buna ihtiyacımız var? Gelecek dostu bir yayın platformu oluşturmamıza yardımcı olabilecek WordPress'in özelliklerini ve araçlarını da tartışacağız. Yüksek bir hedefi hedefliyoruz: bir kez oluşturulduğunda, farklı cihazlarda ve farklı görüntüleme koşullarında esnek bir şekilde sunulabilecek içeriğe sahip olmak. Bakalım ne kadar yakınlaşabiliriz.
Son kitabında Mobil İçerik için İçerik Stratejisi , UX ve içerik stratejisi uzmanı Karen MacGrane İçerik yönetimine neden yeni bir yaklaşıma ihtiyacımız olduğuna dair detaylı ve iyi bir açıklama sunar. Duyarlı siteler oluşturmaya devam ediyoruz - farklı platformlarda yayınlanabilecek ve çeşitli cihazlarda erişilebilecek içerikler oluşturuyoruz. Ya yarın buzdolabında bilgi tüketmek için birinin birincil aracı olursa ne olur? Web siteniz böyle bir kullanım için hazır mı?
Duyarlı tasarım, mobil kullanıcılara yeterli deneyime sahip olma ihtiyacından kaynaklanmaktadır. Dürüst olmak gerekirse, “mobil” sadece resmin bir parçasıdır. Geleceği düşünürsek, içeriğimizin ortaya çıkacağı diğer yeni platformlar ve cihazlardan kolayca bekleyebiliriz: saatler, buzdolapları, gözlükler, konuşan robotlar - hayal edebileceğiniz her şey. Bu, sitemizin “konuşan robot” versiyonunu oluşturmamız gerektiği anlamına mı geliyor? Bu delilik olurdu. Peki çözüm nedir? Çözüm, uyarlanabilir içeriktir - oluşturulduktan sonra, farklı durumlarda ve senaryolarda yeniden kullanılabilen içeriktir. Kulağa harika geliyor değil mi? Bunu nasıl başarabiliriz?
İçeriğimiz artık “sayfalar” dan oluşmuyor. Her biri önceden tanımlanmış öğelerden oluşan bir paket olarak düşünülmesi gereken nesnelerden oluşuyor. Her yapısal bileşen için - bir parça - tasarım sistemi, tüm senaryolarda nasıl gösterilmesi gerektiğini açıklar. Topaklar, farklı kullanım durumları için alternatif medya veya formatlarda sunulabilir. Örneğin, içerik nesnesinde bir videomız varsa, videonun görüntülenemediği senaryolar için açıklayıcı bir metin veya bir yazıya sahip olabilirdik. Ya da bir nesnenin ek açıklamaları, sosyal medyada paylaşıldığı veya arama sonuçlarına dahil edildiği veya bir siteye eklendiğinde olduğu gibi, senaryoya göre değişebilir.
İçeriği sunumdan ayırmak için bir sonraki adımı atmamız gerekiyor. Aslında bu, yeniden tasarımın ve web standartlarının temel taşı olan önemli bir ilkedir. Fakat daha da ilerlememiz ve WYSIWYG zihniyetinden kurtulmamız gerekiyor. “Gördüğünüz şey” artık “kullanıcılarınızın gördüğü” değil. Bu tehlikeli bir yanılsamadır. Metnimizi italik olarak işaretlememeli veya “sayfa” nın “içerik” alanına HTML olarak resim eklememeliyiz. Bir içerik nesnesine bir referans eklememiz ve tasarım sistemimizin nesnenin nasıl sunulması gerektiğine karar vermemiz gerekir.
Programlama araçlarına daha fazla iş yükledik (her şeyden önce, içeriğimizin önceden tanımlanmış senaryolara dayalı olarak çeşitli platformlarda sunulmasını istiyoruz, değil mi?), İçerikle ilgili bu sistemlere daha fazla bilgi vermeliyiz. Örneğin, geçmişte düz İngilizce yazarak bir metnin yazarı John Doe olduğunu ve ismini cesurca yazabiliriz - şimdi yapamayız. CMS'mizde, farklı senaryolarda nasıl sunulması gerektiğine dair bir ad ve bir dizi kural girmek için ayrı bir alana ihtiyacımız var.
İstenen içeriğin çevreye göre (cihaz, ekran çözünürlüğü, bağlantı hızı vb.) Kullanıcıya nasıl sunulacağına karar verebilecek tek bir içerik kaynağı ve senaryo tabanlı bir yayın sistemine ihtiyacımız var.
Tüm bu yönler WordPress ile elde edilebilir mi? MacGrane, yayıncıları uyarlamalı içerik için bir araç olarak desteklemediği için WordPress ve diğer blog yazılımlarını sorumlu tutuyor. Spesifik olarak, WordPress'de bir WYSIWYG editörümüz var, tek bir metin alanımızla “post” a giriyoruz. Ne yazık ki, bu, WordPress'in açık versiyonunu kullanan bir tasarımcıyla karşılaşan durum. Neyse ki, WordPress sadece “blogging software” den biraz daha fazlasıdır. Geliştiricinin gerçekten modern ve geleceğe hazır bir deneyim sunabildiği bir geliştirme platformu olan bir geliştirme platformuna dönüşmüştür.
Geliştiriciler olarak hangi araçlara sahip olduğumuzu ve bunları WordPress'i müşterilerimiz için uyarlanabilir bir yayın platformuna dönüştürmek için nasıl uygulayacağımızı görelim.
WordPress, özel posta türleri ve özel taksonomilerin tanıtımıyla tam teşekküllü bir CMS olma yolunda harekete geçti. Bunlarla birlikte kullanılabilecek bir başka güçlü özellik, sözde özel alanlar. Bu basit isim GUI'yi ifade eder; Aslında, bu özel alanlar WordPress'teki herhangi bir nesne ile ilişkilendirilebilen meta veri kümesini temsil eder. WordPress, meta verileri için yüksek oranda özelleştirilebilir UI ve depolamak ve ona erişmek için esnek bir API oluşturmamızı sağlar.
Bu neden yardımcı oluyor? Özel posta türleri ile artık "sayfa" kavramına kilitlenmiyoruz. İhtiyacımız olan herhangi bir nesne için bir haber türü oluşturabiliriz (haberler, etkinlikler, ortaklar - bizim gibi). Nesnenin yapısını bu meta veri kümesi aracılığıyla tanımlayabiliriz. Meta verileri yönetmek için ayrı bir kullanıcı arayüzü de oluşturabiliriz. Tüm bunlar içeriğimize daha fazla yapı kazandırır. WordPress, herhangi bir türde meta veri oluşturmamıza izin verir vermez, başlıkları ve açıklamaları gibi yerleşik içerik blokları için alternatifleri depolamak için kullanabiliriz. (Örneğin, her içerik nesnesi için benzersiz bir SEO hedefli başlık ve açıklama sağlayan SEO eklentileri görebiliriz.)
Limitleri neler? WordPress, meta verileri depolamak için tutarlı bir şekilde bir API sağlamadığı için çok fazla eleştirilmektedir. Özellikle, postalar (ve özel gönderim türleri) ve kullanıcılar için meta verilere sahip olabiliriz, ancak taksonomiler için değil (bir eklenti gerekli bunun için). Bir yayın için düzenleme ekranında özel bir UI oluşturmak, olabildiğince kolay değildir. Ön tanımlı fonksiyonlar ve standartlar eksiktir (bu yüzden farklı eklentiler bunu farklı şekilde yapar, bizi bir sistemden ziyade karmaşaya bırakır). Ancak WordPress kontrol panelini birleştirmeye ve optimize etmeye yardımcı olan son değişiklikler bize umut veriyor.
WordPress'in diğer bir harika özelliği de, zengin metin editörünün birkaç örneğinin bir sayfaya izin vermesidir. Bu ile uygulanabilir wp_editor Sadece tekstüre edici metin biçimlendirmesini değil, aynı zamanda zengin düzenleme işlevini ve medya seçim düğmelerini de atar.
Bu neden yardımcı oluyor? Bu işlevle, tek bir içerik alanını bir nesnenin yapısına göre birkaçına bölebiliriz. Bunu yaparken, nesnelerimize yapısal bir bileşen ekliyoruz. Ayrıca, her düzenlenebilir alanda, editörlerin gerekli işaretlemeyi kısa kodlar dahil olmak üzere uygun alanlara kolayca eklemelerine yardımcı olacak birleşik ve tanıdık GUI olacaktır.
Limitleri neler? Bu tür zengin düzenleme alanlarına meta verisi olarak girilen verileri depolamalıyız ve bu da daha fazla veritabanı çağrısı vb. Anlamına geliyor. Bu nedenle, bu yaklaşım, sitenin önbellekleme gibi optimizasyonuna daha fazla dikkat etmeyi gerektirecektir. Bu verileri şablonlarda temsil etmek için yerleşik bir işlev yoktur, bu yüzden onu oluşturmamız gerekecek.
Bu yaklaşımla, tanıdık düzenleme sonrası ekran tamamen dönüştürülecektir:
Yukarıda tartışılan WordPress araçları, içeriği farklı nesneler ve meta verileri depolayan bir dizi alanla, nesneleri tanımlayarak ve tek bir içerik bloğunun yerini alarak içeriğimizi daha yapısal hale getirmemizi sağlar.
Şimdi anlam ve sunumu ayırmak için hangi araçlara ihtiyacımız olduğunu görelim. Aslında sadece iki temel kural var:
İlk kuralın takip edilmesi kolaydır. Basit bir filtreyle, görsel düzenleyiciyi tüm kullanıcılar için kaldırabiliriz.
add_filter('user_can_richedit', '__return_false');
İkinci kuralın takip edilmesi daha zor. Elbette, metnimizdeki her HTML etiketi için avlanmayacağız - gerçekten anlamsal öğeleri temsil edenler kesinlikle sorun değil. Ancak eklemeye başladığımızda Bir başka büyük sorun da WordPress'in zengin medyayı - özellikle de görüntüleri - içerik alanlarına yerleştirme biçiminden kaynaklanmaktadır. Şu anda, görüntünün bağlantısını, boyutunu ve sarma işaretlemesini kodlayan düz HTML'yi yazdırıyor. Uyarlanabilir bir yaklaşım için mümkün olan en kötü senaryo. Belirli bir kullanım durumu için bir görüntünün başka bir versiyonuna ihtiyaç duyarsak ne olur? Medya kütüphanemizi başka bir alana taşıdığımızda ne olur? Ya bir nesnenin tasarımını değiştirdik ve bu yüzden görüntüyü başka bir boyutta mı gerekirse? Bir görüntü için birkaç kaynak belirtmemizi gerektiren duyarlı bir teknik uyguluyorsak ne olur? WordPress'in varsayılan davranışını değiştirmezsek, tüm bu kullanım durumları kesinlikle imkansızdır. Yine de WordPress'in, mümkün olan uyarlanabilir bir yaklaşıma geçiş yapmak için neredeyse her şeyi vardır: Hepsini bir araya getirerek, medya kütüphanesindeki öğenin kimliğini içeren bir kısa kod ile medya için işaretlemeyi temsil edebiliriz. Çok basit bir örnek şöyle görünürdü: uploads
ayrı olarak klasör, böylece tam yol dinamik olarak inşa edilebilir. add_shortcode('frl_image', 'frl_image_screen');function frl_image_screen($atts, $content = ''){extract(shortcode_atts(array('id' => 0, 'link' => 'file', 'size' => 'medium'), $atts ));$out = '';$id = intval($id);if($id == 0)return ''; // no attachment$out = "