Duyarlı Tasarım Yeterli Değil, Duyarlı Performansa İhtiyacımız Var

Son zamanlarda , birçok performans sorunu olan çok sayıda duyarlı web sitesine giriyorum. Çoğunda, sorunlar o kadar belirgin ki, en yeni nesil akıllı telefonlar dışında neredeyse hiçbir şeyde işe yaramazlar. Duyarlılığın bir kavram olarak daha geniş bir kitleye ulaşmayı amaçladığı düşünüldüğünde, bu oldukça verimsiz görünüyor.

Bu soruna en büyük katkı, halen yaygın olan masaüstü öncelikli tasarım paradigmasıdır. Önce mobil bakış açısıyla düşünmek sorunu çözüyor gibi görünüyor, ancak bu tek başına tatmin edici performansı garanti etmiyor. Hepimiz az ya da çok zarif bozulmaya çok fazla güveniyor gibiyiz. Eksik işlevselliği sağlamak için şimlere ve çoklu dolgulara güveniyoruz. Hızlı geliştirme sağlamak ve tarayıcı uyumluluğu bir sorun olduğunda arkamızı kollamak için kitaplıklara güveniyoruz.

"Neden endişe?" sorabilirsin. "Ziyaretçilerimizin çoğu, en son işletim sistemi sürümlerini çalıştıran yüksek performanslı akıllı telefonlara sahip. Sitelerimizi idare edebilirler. Analizler bize bunu söylüyor.”

Saman adam tartışması için üzgünüm, ancak sitenizi kullanabilecek kişilerin kullanıcılarınızın çoğunluğu olacağını yüksek sesle belirtmeyi hak ettiğini düşünüyorum. Analizlerinizde Android 2.3'ü görmüyorsanız, bu, bu cihazlara sahip hiç kullanıcı olmadığı anlamına mı geliyor? Yoksa sitenizin bu kullanıcılara sunacak hiçbir şeyi olmadığı anlamına mı geliyor? O neslin birçok cihazının hala raflarda olduğunu ve bugün bile yepyeni satın alındığını düşünün. Onu geçmiş yıllardan kalma bir teknoloji olarak görmezlikten gelmemelisiniz.

Bu nedenle, web geliştirmenin ideal durumları ve gerçek hedeflerinden bahsetmek istiyorum. Ve bizi bu hedeflere yaklaştıran uygulamalar ve paradigmalar hakkında.

Önce Tuğla Tasarım Paradigma

Yıllık telefon satışlarının önemli bir kısmı hala özellikli telefonlar tarafından alınıyor. Nüfusun daha da büyük bir kısmı her yıl telefon almıyor, ancak yine de ellerinde web özellikli bazı cihazlar var. Bu sayılara hala kullanımda olan son nesil akıllı telefonları ekleyin, kindle'ları ve diğer web yarı yetenekli cihazları (WAP cihazları, TV'ler, tost makineleri, tişörtler ve tuğlalar) ekleyin. Hepsini toplayın ve şaşırtıcı bir miktara ulaşabilirsiniz.

Bu kitle için kullanım örneklerini göz önünde bulundurun. Cihazlarında uzun makaleler okumayacak, göz atmayacak ve araştırma yapmayacaklar. Ancak, sayısal klavyede bir URL girmeye çalışmanın ve bir telefon numarasına ulaşmak için yön tuşlarını kullanarak sayfada gezinmenin veya anında bir adresi iki kez kontrol etmenin dehşetini yaşayabilirler.

Öyleyse, belirli bir yetenek ve performans eşiğinin altındaki cihazlara yalnızca bu bilgiyi sağlayacak bir alt-mobil öncelikli düzeni uygulamak bizim için ne kadar zor?

Zarif İyileştirme

Asgari en iyi uygulama olarak zarif bozulma ile, bunun ötesinde düşünmeyi (bir dereceye kadar) engelleyen bir her şeyi yakalama ilkesi yarattık. Zarif bir bozulma gerçekleştiğinde, kesinlikle işimizin yapıldığını ve iyi yapıldığını söyleyebiliriz. Kullanımda olan çeşitli çerçeveler ve kütüphaneler tarafından zaten kapsandığından, giderek daha sık düşünmek zorunda bile kalmıyoruz. Ve son olarak, çoklu dolgular ve şimler, bazı durumlarda işlevsellik bozulması ihtiyacını tamamen ortadan kaldırır.

Bu işlevsellik giderek daha kolay erişilebilir hale geldikçe, onun hakkında düşünme ihtiyacı (bırakın ötesini) gitgide daha uzak hale geliyor.

Bu makalenin bakış açısından şu şekilde ayrılabilir:

Hoş olmayan bozulma: Bir özellik hazır değilse, uygulama o şekilde başarısız olur veya engelleyici bir şekilde elverişsiz bir şekilde kullanılamaz veya kullanılabilir hale gelir.

Zarif bozulma: Bir özellik hazır değilse, yine de kabul edilebilir kullanılabilirlik sağlayacak şekilde başarısız olur.

Hoş olmayan iyileştirme: Özellik hazır değilse, bir çoklu dolgu veya altlık ile taklit edilir.

Orada, sorun çözüldü.

Aynı düşük seviye cihazların performansını düşünmezseniz.

Küçük kardeşlerinin işlem gücü ve veri yeteneklerinden yoksun oldukları için çok daha fazla yük taşımaları istenmektedir. Polyfill'leri bir çözüm olarak almak, tüm modern işlevlerin artık tüm cihazlarda mevcut olduğu ve endişe duymadan kullanılabileceği yanılsaması yaratır.

Ve böylece modernizr'i uygularsınız ve her ihtimale karşı her şeyi çoklu doldurursunuz. En az yetkin cihaz, en fazla miktarda veriyi yükler ve en fazla miktarda işleme gerçekleştirir. Böylece “en iyi” son kullanıcı deneyimi sağlanır.

Zarif iyileştirme fikri, en düşük özellik gereksinimleriyle başlayıp, cihaz yeteneklerine dayalı olarak performans-kullanılabilirlik dengesi optimal olana kadar yükseltmeleri yükleyerek konsepti tersine çevirir. Böylece veri trafiği ve işleme gereksinimleri, bunları işlemek için en uygun cihazlara taşınacaktır.

Elbette, şu anda konsept aşırı derecede karmaşık: çoğu çerçeve ve kitaplık tarafından desteklenmiyor, çoğunlukla tartışılmıyor ve bu tür uygulamalara yapılan referanslar çok az, birbirinden uzak ve mikro işlevselliklerle sınırlı. Ancak bir noktada tüm konseptler ve işlevler böyleydi.

Yapabilir, Ama Zorunda mı?

Web geliştirme ile ilgili diğer bir en iyi uygulama, bir özelliği etkinleştirmeden önce bir cihazda kullanılabilir olup olmadığını kontrol etmektir.

Ancak, Google Chrome'un en son sürümünü eski Android telefonunuza yükleyebileceğinizi ve CSS animasyonlarını, WebGL'yi, arka plan paralaks efektlerini ve diğer birçok işlevi çalıştırabileceğini iddia edeceğini unutmayın. Ama gerçekten, gerçekten , olamaz. Öyle ki, tarayıcı çökecek ve tüm cihaz, kontrolü yeniden kazanmak için yeniden başlatılması gerekecek bir noktaya tepkisiz kalacak.

Bu sorun son zamanlarda Android uygulamalarını büyük ölçüde etkilemeye başladı (kullanıcı açısından). Bu anlamda en göze çarpan bozulmalardan biri, hizmetlerini eski cihazlardaki performans sorunları nedeniyle mevcut en hafif sohbet uygulamasından neredeyse kullanılamaz hale getiren Google Talk/Hangouts uygulaması yükseltmesini etkiledi. (Bu noktayı bir kez daha vurgulamak gerekirse: burada "daha eski", onu hemen hemen her mağazadan hazır, yepyeni satın alabileceğiniz anlamına gelir). Aynı sorun YouTube uygulamasını ve Twitter uygulamasını (deneyimlerime göre) ve görünüşe göre diğerlerini de etkiledi.

Bu nedenle, yüksek performanslı bir temel özelliğin son teknoloji makyaj üzerindeki değerini değerlendirmek için planlama aşamanızın bir noktasında biraz zaman ayırın. Veya en azından uygulamanızın/hizmetinizin/içeriğinizin son neslini eski kullanıcılar için bir biçimde kullanılabilir durumda bırakın. Hangisinden bahsetmişken…

Kullanıcıların Bleeding Edge'den Çıkmasına İzin Verin

Kendinizi hiç eski bir cihazdan veya zayıf bir bağlantı üzerinden Gmail'i kullanmaya çalışırken buldunuz mu? Bu "temel HTML yükle" bağlantısı kesinlikle işe yarar.

Son teknoloji ürünü, duyarlı, hareketli, dokunmaya yönelik çevrimiçi vitrininiz neden bu işlevselliğe sahip değil?

Bir düşünün: Daha fazla potansiyel müşteriye ulaşabilmek için duyarlı olmasını istediniz. En iyi ilk izlenimi bırakmak için son teknolojiyi yaptınız. Ve sonuç olarak, daha az potansiyel müşteri, siz ve hizmetleriniz hakkındaki temel bilgilere bile ulaşabilir. Zarif iyileştirme sizin için çok maliyetli bir kavramsa, “WOW” sürümü cihazları için çok fazlaysa, neden ziyaretçilerinize içeriğinizin salt metin sürümüne erişme seçeneği sunmuyorsunuz?

Gerçekten Tüm Kütüphaneye İhtiyacınız Var mı?

Son olarak, standardın biraz ötesine geçtiğini görmek istediğim son en iyi uygulama “kullan ya da kaybet”tir. Hangi kitaplıkların ve modüllerin gerçekte kullanımda olduğunu takip etmek ve yalnızca bunları dahil etmek bazen sıkıcı olabilir, ancak araç setinizin tamamını her sayfada tutmak sadece özensizdir.

Son zamanlarda, bir kitaplık ekledikten sonra gerçekte ne kadar işlevsellik kullandığımı takip etmeye başladım. Ve en sık kullandığım araç jQuery. Çoğu zaman, yalnızca bir veya iki işlev ($.extend veya $.ready gibi) kullandığımı veya daha da kötüsü, öğeleri yalnızca sınıfa veya kimliğe göre almak için kullandığımı görüyorum. Bazen böyle bırakıyorum, bazen de bağımlılığı kaldırmak veya ayırmak için koda geri dönüyorum.

Sonuçlara göre bir kitaplığın ne ve ne kadarının kullanıldığını ve kilo vermeyi otomatik olarak analiz edebilseydiniz güzel olmaz mıydı?

Birçok kitaplık ve uygulama, kullanmaya başlamadan önce yüklemeyi özelleştirme seçeneği sunar. Ancak, kütüphanelerimizde otomatikleştirilmiş bir "kullan ya da kaybet" yapı mimarisini standart hale getirmenin çok uzaklarda olmaması gerektiği hissine kapılıyorum.

"Her şeyi dahil et" yaklaşımına alerjim var. Ancak bunu böyle bir işlevsellik ile birlikte kullanmak, yaklaşımı bir prototip panosuna benzer bir şeye dönüştürebilir: yalnızca sözdiziminde değil, gerçek işlevselliğin kendisinde de küçülen aşırı esnek bir geliştirme aracı.

Gerekli olan, bağımlı işlevsellik birim testi yoluyla, kullanılan özelliklerin izlenmesini ve minimum bağımlılığın veya en azından kullanım ölçeğinin çıktılanmasını sağlayan kitaplığın yalnızca geliştirme sürümüdür (örneğin, jQuery'yi %8'e ekledim mi? işlevselliği veya %80'i). Bağımlılık çıktısı daha sonra üretim için çıktıyı toplama, toplama ve en aza indirme için kullanılabilir.

Ama Bu Konuda Ne Yapabilirim?

Her şeyden önce, konuyu meşgul edin . Bir düşünün, akranlarınızla tartışın ve sorunu gerçek dünya senaryolarında tespit etmeye çalışın.

Denemek. Çekmecede bir yere sakladığınız son nesil telefonu çıkarın. Kendi web sitelerinizde kullanmayı deneyin ve içeriğin uzaktan kullanılabilir olup olmadığını kontrol edin. Git ülkedeki bazı eski akrabaları ziyaret et ve onlara teknoloji müjdecisi olmayı dene. Teknolojiyi benimsemedeki gecikmelerinin aslında erişilebilirlik sorunları tarafından kolaylaştırılıp kolaylaştırılmadığına bakın.

Bir web sitesini devreye alan bir alıcıysanız, bu konuda (en azından) düşük düzeyde bir destek talep ettiğinizden emin olun. Unutmayın: amaç, düşük seviyeli cihazlara tüm özelliklerinizin tam bir bağlantı noktasını oluşturmak değildir. Sorulan tek şey, bu kullanıcıların cihazlarının çökmesi yerine iletişim bilgilerinizi almasıdır.

Bunun için gerçek kaynakları ayırın: Sorunun en basit çözümü bir veya iki günden fazla sürmemeli ve biraz ileriyi düşünmeli. Web sitesini ilk etapta yapmanın en temel nedenlerini aklınızda bulundurun (duyarlı bir site yapmayı bırakın).

Bir kitaplık, çerçeve, paket veya başka herhangi bir gömülebilir yazılım üzerinde çalışan bir paket geliştiriciyseniz : burada en fazla farkı yaratabilecek kişi sizsiniz. Bu kavramları kolaylaştırabilir veya platformunuza dahil edebilirseniz, web geliştirmenin tüm manzarasını etkilersiniz. Paket tasarımınıza dahil ederseniz, bana bildirin, ben de sizin için müjdeleyeyim.

Son olarak, **bir geliştirici veya tasarımcıysanız**, yalnızca en iyi uygulamalarla yetinmeyin. Her zaman bu ufkun biraz ötesine bakmaya çalışın. Müşterileriniz ve kullanıcılarınız için henüz kimsenin talep etmediği, desteklenmeyen ve belgelenmemiş bu kavramları zorlamak için çok çalışmanız gerekiyor.

Nihayetinde, birinin saatlerce bunun hakkında konuştuğunu duymak ve kendinizi Zagreb'in yakınında bulmak istiyorsanız, bana bildirin. Gidip bir kahve içebiliriz.