Medya sorguları harika olsa da…
Medya sorguları, çeşitli boyutlardaki cihazlarda kullanıcılara daha iyi bir deneyim sunmak için stil sayfalarında küçük değişiklikler yapmak isteyen web sitesi geliştiricileri için harika bir çözümdür. Medya sorguları, ekran boyutuna bağlı olarak sitenizin CSS'sini özelleştirmenize olanak tanır. Bu makaleyi incelemeye başlamadan önce duyarlı tasarım hakkında daha fazla bilgi edinin ve medya sorgularının kullanımına dair bazı güzel örnekleri mediaqueri.es adresinde inceleyin.
Brad Frost'un daha önceki bir makalede belirttiği gibi, görünümü değiştirmek mobil web için geliştirme yaparken göz önünde bulundurulması gereken birçok şeyden yalnızca biridir. Mobil web sitenizi oluştururken tek yaptığınız şey düzeninizi medya sorgularıyla özelleştirmekse aşağıdaki durum söz konusudur:
- Tüm cihazlar aynı JavaScript, CSS ve öğeleri (resimler, videolar) alır. Bu da gereğinden uzun yükleme sürelerine neden olur.
- Tüm cihazlar aynı ilk DOM'u alır. Bu durum, geliştiricileri aşırı karmaşık CSS yazmaya zorlayabilir.
- Her cihaza göre uyarlanmış özel etkileşimler belirtme konusunda esneklik yoktur.
Web uygulamaları için medya sorgularından daha fazlası gerekir
Yanlış anlamayın. Medya sorgularıyla duyarlı tasarımdan nefret etmiyorum ve kesinlikle dünyada bir yeri olduğunu düşünüyorum. Ayrıca, yukarıda bahsedilen sorunların bazıları duyarlı resimler ve dinamik komut dosyası yükleme gibi yaklaşımlarla çözülebilir. Ancak belirli bir noktadan sonra çok fazla küçük değişiklik yaptığınızı fark edebilirsiniz ve farklı sürümler sunmak daha iyi bir seçenek olabilir.
Oluşturduğunuz kullanıcı arayüzlerinin karmaşıklığı arttıkça ve tek sayfalık web uygulamalarına yöneldikçe her cihaz türü için kullanıcı arayüzlerini özelleştirmek üzere daha fazla işlem yapmak isteyeceksiniz. Bu makalede, bu özelleştirmeleri en az çabayla nasıl yapacağınızı öğreneceksiniz. Genel yaklaşım, ziyaretçinizin cihazını doğru cihaz sınıfına göre sınıflandırmayı ve bu cihaza uygun sürümü sunmayı içerirken sürümler arasında kodun yeniden kullanılmasını en üst düzeye çıkarır.
Hangi cihaz sınıflarını hedefliyorsunuz?
İnternete bağlı çok sayıda cihaz var ve neredeyse hepsinde tarayıcı bulunuyor. Bu cihazların çeşitliliği, zorluk yaratır: Mac dizüstü bilgisayarlar, Windows iş istasyonları, iPhone'lar, iPad'ler, dokunmatik girişli Android telefonlar, kaydırma tekerlekleri, klavyeler, sesli giriş, basınca duyarlı cihazlar, akıllı saatler, ekmek kızartma makineleri ve buzdolapları gibi birçok cihaz. Bu cihazlardan bazıları her yerde bulunurken bazıları çok nadirdir.
İyi bir kullanıcı deneyimi oluşturmak için kullanıcılarınızın kim olduğunu ve hangi cihazları kullandıklarını bilmeniz gerekir. Fare ve klavye kullanan bir masaüstü kullanıcısı için kullanıcı arayüzü oluşturup bunu akıllı telefon kullanıcısına verirseniz arayüzünüz başka bir ekran boyutu ve başka bir giriş yöntemi için tasarlandığından kullanıcının canını sıkar.
Yaklaşımların spektrumunda iki uç nokta vardır:
Tüm cihazlarda çalışan tek bir sürüm oluşturun. Farklı cihazlarda farklı tasarım hususları olduğundan sonuç olarak kullanıcı deneyimi olumsuz etkilenir.
Desteklemek istediğiniz her cihaz için bir sürüm oluşturun. Bu işlem, uygulamanızın çok fazla sürümünü oluşturacağınız için çok uzun sürer. Ayrıca, bir sonraki yeni akıllı telefon geldiğinde (yaklaşık olarak haftada bir kez) başka bir sürüm oluşturmanız gerekir.
Burada temel bir denge söz konusudur: Ne kadar çok cihaz kategoriniz olursa o kadar iyi bir kullanıcı deneyimi sunabilirsiniz ancak bu deneyimi tasarlamak, uygulamak ve sürdürmek o kadar çok zaman alır.
Karar verdiğiniz her cihaz sınıfı için ayrı bir sürüm oluşturmak, performans açısından veya farklı cihaz sınıflarına sunmak istediğiniz sürümler arasında büyük farklılıklar varsa iyi bir fikir olabilir. Aksi takdirde, duyarlı web tasarımı tamamen makul bir yaklaşımdır.
Olası bir çözüm
İşte bir uzlaşma çözümü: Cihazları kategorilere ayırın ve her kategori için mümkün olan en iyi deneyimi tasarlayın. Seçeceğiniz kategoriler, ürününüze ve hedef kullanıcınıza bağlıdır. Günümüzde popüler olan web özellikli cihazları güzel bir şekilde kapsayan örnek bir sınıflandırmayı aşağıda bulabilirsiniz.
- küçük ekranlar + dokunma (çoğunlukla telefonlar)
- büyük ekranlar + dokunma (çoğunlukla tabletler)
- büyük ekranlar + klavye/fare (çoğunlukla masaüstü/dizüstü bilgisayarlar)
Bu, olası birçok dökümden yalnızca biridir ancak yazıldığı sırada oldukça mantıklı bir dökümdür. Yukarıdaki listede dokunmatik ekranı olmayan mobil cihazlar (ör. özellikli telefonlar, bazı özel e-kitap okuyucular) yer almamaktadır. Ancak bu cihazların çoğunda klavye ile gezinme veya ekran okuyucu yazılımı yüklüdür. Bu yazılımlar, sitenizi erişilebilirlik göz önünde bulundurarak oluşturduğunuzda sorunsuz bir şekilde çalışır.
Form faktörüne özgü web uygulamalarına örnekler
Farklı form faktörleri için tamamen farklı sürümler sunan web mülklerine dair birçok örnek vardır. Google Arama ve Facebook bu işlemi yapar. Bu kapsamda hem performans (öğeleri getirme, sayfaları oluşturma) hem de daha genel kullanıcı deneyimi dikkate alınır.
Yerel uygulamalar dünyasında birçok geliştirici, deneyimlerini bir cihaz sınıfına göre uyarlamayı tercih ediyor. Örneğin, iPad'deki Flipboard, iPhone'daki Flipboard'a kıyasla çok farklı bir kullanıcı arayüzüne sahiptir. Tablet sürümü iki elle kullanıma ve yatay çevirmeye, telefon sürümü ise tek elle etkileşime ve dikey çevirmeye göre optimize edilmiştir. Diğer birçok iOS uygulaması da telefon ve tablet sürümlerinde önemli farklılıklar sunar. Örneğin, aşağıda gösterilen Things (yapılacaklar listesi) ve Showyou (sosyal video) uygulamaları bu türdendir:
1. yaklaşım: Sunucu tarafı algılama
Sunucuda, işlem yaptığımız cihaz hakkında çok daha sınırlı bir anlayışa sahibiz. Muhtemelen en faydalı ipucu, her istekte User-Agent başlığı aracılığıyla sağlanan kullanıcı aracısı dizesidir. Bu nedenle, aynı UA algılama yaklaşımı burada da işe yarayacaktır. Aslında DeviceAtlas ve WURFL projeleri bunu zaten yapıyor (ve cihaz hakkında çok daha fazla bilgi veriyor).
Maalesef bunların her biri kendi zorluklarını beraberinde getirir. WURFL çok büyüktür ve 20 MB XML içerir. Bu durum, her istek için önemli bir sunucu tarafı ek yüküne neden olabilir. Performans nedeniyle XML'yi bölen projeler vardır. DeviceAtlas açık kaynaklı değildir ve kullanılabilmesi için ücretli lisans gerektirir.
Detect Mobile Browsers projesi gibi daha basit ve ücretsiz alternatifler de vardır. Elbette bunun dezavantajı, cihaz algılamanın kaçınılmaz olarak daha az kapsamlı olmasıdır. Ayrıca yalnızca mobil ve mobil olmayan cihazlar arasında ayrım yapar ve tablet desteğini yalnızca geçici bir dizi ince ayar aracılığıyla sağlar.
2. yaklaşım: İstemci tarafı algılama
Özellik algılama sayesinde kullanıcının tarayıcısı ve cihazı hakkında birçok bilgi edinebiliriz. Belirlememiz gereken temel noktalar, cihazın dokunma özelliğinin olup olmadığı ve ekranın büyük mü yoksa küçük mü olduğudur.
Küçük ve büyük dokunmatik cihazları ayırt etmek için bir sınır belirlememiz gerekiyor. 5 inç Galaxy Note gibi uç durumlar ne olacak? Aşağıdaki grafikte, bir dizi popüler Android ve iOS cihazın (ilgili ekran çözünürlükleriyle) üst üste yerleştirilmiş hali gösterilmektedir. Yıldız işareti, cihazın çift yoğunluklu olarak geldiğini veya gelebileceğini gösterir. Piksel yoğunluğu iki katına çıksa da CSS aynı boyutları raporlamaya devam eder.
CSS'deki piksellerle ilgili kısa bir not: Mobil web'deki CSS pikselleri, ekran pikselleriyle aynı değildir. iOS Retina cihazlar, piksel yoğunluğunu iki katına çıkarma uygulamasına (ör. iPhone 3GS ve 4, iPad 2 ve 3) öncülük etti. Retina Mobile Safari kullanıcı aracıları, web'in bozulmasını önlemek için aynı cihaz genişliğini bildirmeye devam eder. Diğer cihazlar (ör. Android) daha yüksek çözünürlüklü ekranlar elde etmek için aynı cihaz genişliği hilesini kullanıyor.
Ancak bu kararı zorlaştıran nokta, hem dikey hem de yatay modların dikkate alınmasının önemidir. Sayfayı farklı şekilde oluşturmak isteyebilsek de cihazı her yeniden yönlendirdiğimizde sayfayı yeniden yüklemek veya ek komut dosyaları yüklemek istemiyoruz.
Aşağıdaki şemada, dikey ve yatay ana hatların üst üste yerleştirilmesi (ve karenin tamamlanması) sonucunda kareler her cihazın maksimum boyutlarını temsil etmektedir:
Eşiği 650px olarak ayarladığımızda iPhone ve Galaxy Nexus'u "küçük dokunma", iPad ve Galaxy Tab'i ise "tablet" olarak sınıflandırırız. Bu durumda, androjen Galaxy Note "telefon" olarak sınıflandırılır ve telefon düzenini alır.
Bu nedenle, makul bir strateji şu şekilde olabilir:
if (hasTouch) {
if (isSmall) {
device = PHONE;
} else {
device = TABLET;
}
} else {
device = DESKTOP;
}
Özellik algılama yaklaşımının nasıl çalıştığını gösteren kısa bir örneği inceleyin.
Buradaki alternatif yaklaşım, cihaz türünü algılamak için kullanıcı aracısı yoklama yöntemini kullanmaktır. Temel olarak bir dizi sezgisel yöntem oluşturup bunları kullanıcınızın navigator.userAgent ile eşleştirirsiniz. Sözde kod şu şekilde görünür:
var ua = navigator.userAgent;
for (var re in RULES) {
if (ua.match(re)) {
device = RULES[re];
return;
}
}
UA algılama yaklaşımının nasıl çalıştığına dair bir örnek görün.
İstemci tarafı yükleme hakkında not
Sunucunuzda kullanıcı aracısı algılama yapıyorsanız yeni bir istek aldığınızda hangi CSS, JavaScript ve DOM'un sunulacağına karar verebilirsiniz. Ancak istemci tarafı algılama yapıyorsanız durum daha karmaşıktır. Birkaç seçeneğiniz vardır:
- Bu cihaz türünün sürümünü içeren, cihaza özel bir URL'ye yönlendirin.
- Cihaz türüne özel öğeleri dinamik olarak yükleyin.
İlk yaklaşım basittir ve window.location.href = '/tablet' gibi bir yönlendirme gerektirir. Ancak konuma artık bu cihaz türü bilgisi ekleneceğinden URL'nizi temizlemek için History API'yi kullanmak isteyebilirsiniz. Maalesef bu yaklaşım, özellikle mobil cihazlarda yavaş olabilen bir yönlendirme içerir.
İkinci yaklaşımın uygulanması biraz daha karmaşıktır. CSS ve JS'yi dinamik olarak yüklemek için bir mekanizmaya ihtiyacınız vardır ve (tarayıcıya bağlı olarak) <meta viewport> gibi işlemleri özelleştiremeyebilirsiniz. Ayrıca, yönlendirme olmadığı için sunulan orijinal HTML'yi kullanmak zorunda kalırsınız. Elbette JavaScript ile değiştirebilirsiniz ancak bu işlem, uygulamanıza bağlı olarak yavaş ve/veya zarif olmayabilir.
İstemci veya sunucuya karar verme
Yaklaşımlar arasındaki farklılıklar şunlardır:
Profesyonel müşteri:
- UA yerine ekran boyutlarına/özelliklerine dayandığı için gelecekte daha kullanışlı olacaktır.
- Kullanıcı aracısı listesini sürekli olarak güncellemeniz gerekmez.
Pro sunucusu:
- Hangi cihazlara hangi sürümün sunulacağının tam kontrolü.
- Daha iyi performans: İstemci yönlendirmelerine veya dinamik yüklemeye gerek yoktur.
Kişisel tercihim, device.js ve istemci tarafı algılama ile başlamaktır. Uygulamanız geliştikçe istemci tarafı yönlendirmenin önemli bir performans dezavantajı olduğunu fark ederseniz device.js komut dosyasını kolayca kaldırabilir ve sunucuda UA algılamayı uygulayabilirsiniz.
device.js ile tanışın
Device.js, kullanıcı aracısı dizesi ayrıştırması yapmak için gereken zaman ve çabayı azaltarak özel bir sunucu tarafı yapılandırmasına gerek kalmadan semantik, medya sorgusuna dayalı cihaz algılama için bir başlangıç noktasıdır.
Buradaki fikir, <head> bölümünün en üstünde arama motoru dostu işaretleme (link
rel=alternate) sağlayarak sitenizin hangi sürümlerini sunmak istediğinizi belirtmenizdir.
<link rel="alternate" href="http://foo.com" id="desktop"
media="only screen and (touch-enabled: 0)">
Ardından, sunucu tarafında UA algılama yapıp sürüm yönlendirmesini kendiniz yönetebilir veya cihaza dayalı istemci tarafı yönlendirme yapmak için device.js komut dosyasını kullanabilirsiniz.
Daha fazla bilgi için device.js proje sayfasını ve istemci tarafında yönlendirme için device.js'yi kullanan bir sahte uygulamayı inceleyin.
Öneri: Form faktörüne özel görünümlere sahip MVC
Şu anda muhtemelen her cihaz türü için ayrı bir uygulama olmak üzere üç farklı uygulama oluşturmanızı istediğimi düşünüyorsunuz. Hayır Kod paylaşımı çok önemlidir.
Umarız Backbone, Ember gibi MVC benzeri bir çerçeve kullanıyorsunuzdur. Bu durumda, özellikle kullanıcı arayüzünüzün (görünüm katmanı) mantığınızdan (model katmanı) ayrılması gerektiğiyle ilgili endişelerin ayrılması ilkesini biliyorsunuzdur. Bu konuyla ilgili yeniyseniz MVC ile ilgili bazı kaynaklar ve JavaScript'te MVC ile başlayın.
Cihazlar arası hikaye, mevcut MVC çerçevesine sorunsuz bir şekilde uyar. Görünümlerinizi kolayca ayrı dosyalara taşıyabilir ve her cihaz türü için özel bir görünüm oluşturabilirsiniz. Ardından, görünüm katmanı hariç tüm cihazlara aynı kodu sunabilirsiniz.
Projenizin yapısı aşağıdaki gibi olabilir (Elbette uygulamanıza bağlı olarak en mantıklı yapıyı seçebilirsiniz):
models/ (paylaşılan modeller) item.js item-collection.js
controllers/ (paylaşılan denetleyiciler) item-controller.js
versions/ (cihaza özel öğeler) tablet/ desktop/ phone/ (telefona özel kod) style.css index.html views/ item.js item-list.js
Bu tür bir yapı, her cihaz için özel HTML, CSS ve JavaScript'niz olduğundan her sürümün hangi öğeleri yüklediği üzerinde tam kontrol sahibi olmanızı sağlar. Bu yöntem çok güçlüdür ve uyarlanabilir resimler gibi yöntemlere başvurmadan, cihazlar arası web için geliştirmenin en yalın ve en iyi performanslı yolunu sunabilir.
En sevdiğiniz derleme aracını çalıştırdıktan sonra, daha hızlı yükleme için tüm JavaScript ve CSS'nizi tek dosyalarda birleştirip küçültürsünüz. Üretim HTML'niz de aşağıdaki gibi görünür (telefon için device.js kullanılır):
<!doctype html>
<head>
<title>Mobile Web Rocks! (Phone Edition)</title>
<!-- Every version of your webapp should include a list of all
versions. -->
<link rel="alternate" href="http://foo.com" id="desktop"
media="only screen and (touch-enabled: 0)">
<link rel="alternate" href="http://m.foo.com" id="phone"
media="only screen and (max-device-width: 650px)">
<link rel="alternate" href="http://tablet.foo.com" id="tablet"
media="only screen and (min-device-width: 650px)">
<!-- Viewport is very important, since it affects results of media
query matching. -->
<meta name="viewport" content="width=device-width">
<!-- Include device.js in each version for redirection. -->
<script src="device.js"></script>
<link rel="style" href="phone.min.css">
</head>
<body>
<script src="phone.min.js"></script>
</body>
(touch-enabled: 0) medya sorgusunun standart olmadığını (yalnızca Firefox'ta (touch-enabled: 0) satıcı önekiyle uygulanır) ancak device.js tarafından doğru şekilde işlendiğini (Modernizr.touch sayesinde) unutmayın.moz
Sürümü geçersiz kılma
Cihaz algılama bazen yanlış olabilir ve bazı durumlarda kullanıcılar, telefonlarında tablet düzenine bakmayı tercih edebilir (ör. Galaxy Note kullanıyor olabilirler). Bu nedenle, kullanıcılarınıza manuel olarak geçersiz kılmak istedikleri takdirde sitenizin hangi sürümünü kullanacaklarını seçme olanağı sunmanız önemlidir.
Genellikle, mobil sürümünüzden masaüstü sürümüne bir bağlantı verilir. Bu işlevi uygulamak kolaydır ancak device.js, bu işlevi device GET parametresiyle destekler.
Sonuç
Özetlemek gerekirse, duyarlı tasarım dünyasına tam olarak uymayan cihazlar arası tek sayfalık kullanıcı arayüzleri oluştururken şunları yapın:
- Desteklenecek bir dizi cihaz sınıfı ve cihazları sınıflara ayıracak ölçütler seçin.
- MVC uygulamanızı, görünümü kod tabanının geri kalanından ayırarak güçlü bir şekilde ilgi alanlarını ayırma prensibine göre oluşturun.
- İstemci tarafında cihaz sınıfı algılama işlemi için device.js dosyasını kullanın.
- Hazır olduğunuzda komut dosyanızı ve stil sayfalarınızı cihaz sınıfı başına birer tane olacak şekilde paketleyin.
- İstemci tarafı yönlendirme performansı sorun oluşturuyorsa device.js'yi bırakıp sunucu tarafı UA algılamaya geçin.