UX ve HTML5: Kullanıcıların Mobil Formunuzu Doldurmasına Yardımcı Olalım (1. Bölüm)

Formlar, kullanıcıların web sitelerinizle (ve mobil uygulamalarınızla) sahip olacağı en temel birincil etkileşimlerden biridir. İnsanları birbirine bağlar ve iletişim kurmalarına izin verirler. Makaleler hakkında yorum yapmalarına ve yazdıklarına kesinlikle katılmadıklarını yazara açıklamalarına izin veriyorlar. İnsanların “biriyle” tanışmaları için doğrudan bir flört uygulamasında sohbet etmelerine izin veriyorlar. Forumlar, ürün siparişleri, çevrimiçi topluluklar, hesap oluşturma veya çevrimiçi ödeme için formlar, kullanıcıların çevrimiçi yaşamının büyük bir bölümünü oluşturur.

Yıl 2018 ve dünya genelinde masaüstünden daha fazla mobil kullanıcımız var . Yine de bu kullanıcılara web'in ikinci sınıf vatandaşları gibi davranıyoruz. Herkes her zaman kullanıcı deneyimi hakkında yazar ve konuşur. Peki, neden, neden, neden bu kadar çok web sitesi ve ürün hala yanlış yapıyor. Dünyanın yarısı için mobil kullanıcı deneyimi neden zarar görüyor? Neden hala bir acı, bugün bir uçuş rezervasyonu yapmak ve mobil formda bir hesap açmak neden hala çok zor? Kullanıcılar daha iyisini bekliyor!

Önerilen okuma : World Wide Web, Not Wealthy Western Web

Bu, iki makaleden oluşan bir dizinin ilk bölümüdür. Bu yazıda, taranabilirlik ve okunabilirlik dahil olmak üzere mobil formlarınızı geliştirmek için bazı temel en iyi uygulamaları özetleyeceğim. Etiket ve girdi yerleştirme, boyut ve optimizasyon konusunda size rehberlik edeceğim. Etkileşim maliyetlerini azaltmak için doğru form öğesinin nasıl seçileceğini göreceğiz. Son olarak, mobil formlardaki hataları nasıl önleyeceğinizi ve bunlarla nasıl başa çıkacağınızı öğreneceksiniz.

İkinci bölümde, belirli mobil yeteneklere ve HTML5 form öğelerine daha yakından bakacağım ve benzersiz ve eğlenceli web uygulamaları ve web siteleri yapmak için klasik form öğelerinin ötesine geçeceğiz.

Not : Bu makaledeki kod geliştirmelerinin çoğu web ile ilgili olsa da (çünkü Swift veya Java bilmiyorum), en iyi kullanılabilirlik uygulamaları mobil uygulamalar için geçerlidir .

Form Design 101: Taranabilirliğe ve Okunabilirliğe Öncelik Verme

"Form, bir bilgisayarda veri depolamak için bir yapıdaki ad, değer, çiftlerdir, etiketler ve insana giriş alanları olarak dışarı çıkar." Bu, bir konferansta Luke Wroblewski'den doğrudan bir alıntıdır. Onun gibi, çoğu form kullanılabilirlik sorununun, veritabanının yapısını kullanıcılara sunma eğiliminden kaynaklandığına inanıyorum.

Güçlü Bilgi Mimarisi

Daha iyi formlar oluşturmak için önce veritabanınızın yapısından birkaç adım uzaklaşmanız gerekir. Kullanıcıların formları nasıl doldurmak istediğini anlamaya çalışın. Formlarınız üzerinde bazı kullanılabilirlik testleri ve kullanıcı araştırması yapmanın kullanışlı olduğu yer burasıdır. Kullanıcı zihinsel modelleri, bu konuda size yardımcı olabilecek bir UX konseptidir. Nielsen Norman Group, bunu “kullanıcının eldeki sistem hakkında neye inandığı” olarak tanımlar. Test kullanıcınızdan sesli düşünmesini ve formu nasıl dolduracağını size söylemesini isteyin. Hangi adımları bekliyorlar? Önce ne gelir? Sırada ne var? Bu, formunuzu daha kullanıcı dostu bir şekilde nasıl yapılandıracağınız konusunda size daha iyi bir fikir verecektir.

Birbirine ait alanları görsel olarak gruplamak, kullanıcıların bir formu doldurmasına da yardımcı olacaktır. Kodda, bunları programlı olarak gruplandırmak için fieldset etiketini kullanın. Ayrıca ekran okuyucuların hiyerarşiyi anlamasına yardımcı olacaktır.

Form uzunsa, varsayılan olarak her şeyi ifşa etmeyin . Ne gösterdiğiniz konusunda akıllı olun. Yalnızca insanların ihtiyaç duyduğu alanları görüntülemek için dallanmayı akıllıca kullanın. Örneğin bir ödeme formunda, tüm gönderi seçenekleri için ayrıntılı alanların tümünü görüntülemeyin. Bu, kullanıcıyı bunaltacaktır. Doğru gönderi seçeneğini seçmelerine yardımcı olacak yeterli bilgiyi görüntüleyin. Ardından, yalnızca o seçimle ilgili ayrıntıları ve alanları görüntüleyin.

Kullanıcıların dikkat süreleri zamanla kısalır: Formun sonunda isteğe bağlı şeyler isteyin . Örneğin, formunuz bir müşteri memnuniyeti anketiyse, sonunda demografik bilgi isteyin. Daha da iyisi, mümkünse bunları otomatik olarak doldurun. Kullanıcılara yalnızca gerekli olanı sorun.

Son olarak, yerelleştirme için önceden plan yapın: Formunuz tercüme edildiğinde ne olacak? Diyelim ki Almanca için ne olacak? Tasarımınız çalışmaya devam edecek mi?

Etiket Yerleştirme ve Giriş Optimizasyonu

Tek Sütunlu Düzen En İyi Çalışır

Yer olmaması nedeniyle, mobil ekranlara etiket ve alan yerleştirmek için sonsuz seçeneğiniz olmaz:

• Alanları tek sütunlu bir düzende sunun. Mobil cihazlarda birden fazla sütun için yer yoktur. Çok sütunlu formlar zaten masaüstünde de harika bir fikir değil.
• Portre modunda, kullanıcıların yazarken alanda ne olduğunu görebilmeleri için etiketi alanın üstüne yerleştirmek daha iyidir.

• Manzara modunda, ekranın yüksekliği azaltılır. Etiketleri sola, girişleri sağ tarafa koymak isteyebilirsiniz. Ama çalıştığından emin olmak için test edin.

Etiket yerleştirme hakkında daha fazla bilgi için Baymard Enstitüsü'nün “Mobil Form Kullanılabilirliği: Etiketleri Alanın Üstüne Yerleştirin” bölümüne bakın.

Etiketler Net ve Görünür Olmalı ve Bağlamsız Çalışmalıdır

Bir alana odaklanıldığı anda klavyenin açılacağını ve ekran alanının en az üçte birini kaplayacağını unutmayın. Küçük mobil ekranlarda, kullanıcıların formu doldurmak için kaydırmaları da gerekecek. Bu, formu doldururken bağlamın bir kısmını kaybedecekleri anlamına gelir. Buna göre planlayın:

• Etiketleriniz, bağlam olmadan okunabilen ve anlaşılabilen açık, görünür metin olmalıdır. Kullanıcı, bağlamı kaybetseler bile her bir etiketi ve alan çiftini ayrı bir görev olarak tamamlayabilmelidir.

• Mümkün olduğunca jargon, kısaltma ve sektöre özgü dilden kaçının.
• Tutarlı ol. Bir etikette bir kez “müşteri” kullanırsanız, o kelimeye bağlı kalın. Kullanıcıların kafasını karıştırabileceğinden daha sonra "istemciler" kullanmaktan kaçının.
• Yazı tipi boyutu yeterince büyük olmalıdır. Formunuzu mümkün olan en kısa sürede gerçek cihazlarda test edin ve boyutu buna göre ayarlayın.
• Tümü büyük harfler bazı kullanıcılar için okunması zor olabilir. Etiketlerde tamamı büyük harfli metin kullanmaktan kaçınmak isteyebilirsiniz.
• Etiket kopyası kısa ve taranabilir olmalıdır. Bir alanın açıklığa kavuşturulması gerekiyorsa, onu etikete koymayın. Bunun yerine bir alan açıklaması kullanın.

Giriş Boyutu En İyi Uygulaması

Mümkünse, girdi öğesinin boyutu, beklenen içeriğin boyutuyla eşleşmelidir . Bu, kullanıcıların formu hızlı bir şekilde doldurmasına ve ne beklendiğini anlamalarına yardımcı olacaktır.

Mobil Cihazda Girdileri Bölmekten Kaçınmak İçin Maskeleri Kullanma

Girdileri yalnızca biçimlendirme uğruna bölmeyin . Kullanıcıların alanlar arasında gezinmek için klavyeyi kullanamadığı mobil cihazlarda özellikle can sıkıcıdır. Formu doldurmak için bir sonraki alana geçmek için fazladan tıklamalar gerekir. “Ama o alanda gerekli sayıda karakteri aldığımda odağı otomatik olarak bir sonraki alana vereceğim” diye düşünüyor olabilirsiniz. Işe yarayabilir. Ancak kullanıcı için öngörülemez hale gelen kullanıcı arayüzünün kontrolünü almış olacaksınız. Ayrıca, onları otomatik olarak bir sonraki alana gönderirseniz ve son alanda bir şeyleri düzeltmeleri gerekiyorsa, acı verici olurdu. Son olarak, bölünmüş girdilerle neyin zorunlu olduğunu tahmin etmek daha karmaşıktır. Öyleyse, "Ama ne olursa olsun" oyununu oynamayı bırakalım ve girdileri bölmeyelim.

Anladım: Alanlarınızı doldurmalarına yardımcı olmak için yine de kullanıcı verilerini küçük parçalar halinde biçimlendirmek istiyorsunuz. Ve bu konuda tamamen haklısın. Bunun için maske kullanabilirsiniz . Bir girişi bölmek yerine, kullanıcının doldurmasına görsel olarak yardımcı olmak için üstüne bir maske koymanız yeterlidir. Aşağıda, kullanıcıların bir kredi kartı alanını doldurmasına yardımcı olmak için bir maskenin nasıl görüneceğine dair bir video örneği verilmiştir:

Maskeler, kullanıcıları doğru formata yönlendirerek hataların önlenmesine yardımcı olur. Bunları kademeli olarak ifşa etmekten kaçının — formatı doğrudan gösterin. Ayrıca, maskeye sahte değerler koymaktan kaçının . Kullanıcılar zaten dolu olduğunu düşünebilir. Bu yüzden demomda sayıları küçük bir "X" ile değiştirdim. Girdi türünüz için en iyi olanı bulun.

Son olarak, bazı verilerin ülkeler arasında farklılık gösterebileceğini ve bazen formatın da (örneğin telefon numaraları) değişebileceğini unutmayın. Buna göre planlayın.

Verimli Alan Açıklamaları

Etkili alan tanımları görüntülemek, kesintisiz ve zahmetli bir form deneyimi arasındaki farkı yaratabilir.

Açıklamalar Ne İçin Kullanılabilir?

Açıklamalar, kullanıcılara birçok yönden yardımcı olabilir. İşte birkaç örnek.

• Tam olarak ne için soruyorsun?
  

  Veritabanıyla ilgili her ne sebeple olursa olsun, bazı sevkiyat şirketleri "Adres 1" ve "Adres 2" alanlarını isterler. Bu, kullanıcılar için oldukça kafa karıştırıcıdır, ancak burada bir seçeneğiniz olmayabilir. Kullanıcıların her alana ne koymaları gerektiğini anlamalarına yardımcı olmak için açıklama alanları ekleyin.

  

  Aynı şey kısaltmalar ve kısaltmalar için de geçerlidir. Onlardan kaçınman gerektiğini söylediğimi biliyorum ama bazen yapamazsın. Örneğin, belirli bir sektör için karmaşık formlar üzerinde çalışıyorsanız, bunların kendi kısaltmaları olabilir. Formu doldurması gereken herhangi bir yeni kullanıcı (henüz) bu kısaltmalara aşina olmayabilir. Bir yerde bir açıklamanın bulunması onlara yardımcı olacaktır.

• Bu Bilgiye Neden İhtiyacınız Var?
  Kullanıcılar, neden ihtiyaç duyduğunuzu ve bununla ne yapacağınızı anlamazlarsa, size kişisel bilgi vermek konusunda isteksiz olabilirler. Ancak bazen yasal nedenlerle (alkol satan bir web sitesinin doğum tarihi gibi) bu tür bilgileri istemeniz gerekir. Burada alan açıklamalarının kullanılması, kullanıcıların bu tür bilgilere neden ihtiyaç duyulduğunu anlamalarına yardımcı olacaktır.
  
  

  E-ticaret sitelerinde, teslimat görevlisinin kendisiyle iletişime geçmesi gerekmesi durumunda kullanıcının telefon numarasını sormak isteyebilirsiniz. Bu meşru bir sebep. Bu nedenle, yine, e-ticaret kullanıcılarına telefon numaralarına neden ihtiyacınız olduğunu açıklamak için açıklamaları kullanın.

  

“Bilgiyi Nerede Bulabilirim?”
Kullanıcılarınızın bir formu doldurmak için belirli bilgileri başka bir yerde bulması gerekiyorsa, onlara nerede bulacaklarını söyleyin. Kullanıcının evini takip etmesini sağlayan bir mobil uygulama üzerinde çalıştım. Kullanıcıların bir seri numarası kullanarak uygulamayı izleme cihazıyla eşleştirmesi gerekiyordu. Cihazda bu seri numarasını bulmak çok kolay değil; biraz talimat gerektirir. Biraz ekledik mi? Seri numarası alanının yanındaki düğmesine basın. Düğme, kullanıcının izleme cihazında seri numarasını nerede bulacağını anlamasına yardımcı olmak için bir resim ve bazı göstergeler gösteren bir modal açar. E-ticaret siteleri, promosyon kodlarıyla aynı şeyi yapar: Kullanıcılara kodları nerede bulacaklarını söyleyen göstergeler verirler.



• “Bilgileri Nasıl Biçimlendirmeliyim?”
  Bazı alanlar belirli bir biçime ihtiyaç duyar. Bu durumda, kullanıcılara biçimlendirme kurallarını önceden bildirmek için açıklamaları kullanın. İşte birkaç örnek:
  • Telefon numarası: Alanın önüne uluslararası arama kodunu (+xx) yazmam gerekir mi?
  • Maksimum uzunluk var mı? Mobil cihazlarda Twitter bununla iyi bir iş çıkarıyor.
  • Parasal tutarlarla uğraşırken, biçim virgülle mi (10.000 gibi) yoksa boşlukla mı (10 000 gibi)?
  • Tarihler için hangi formatı bekliyorsunuz? Bunun nasıl bir kabus olduğunu Wikipedia'dan kontrol etmene izin vereceğim. GG AA YY ve AA GG YY arasındaki fark, çevrimiçi rezervasyon yaparken kullanıcılar için *çok* soruna neden olabilir.
  Bu biçimlendirme sorunlarının çoğunun giriş maskeleriyle çözülebileceğini unutmayın. Buna yazının ilerleyen bölümlerinde geleceğiz (veya sabırsızsanız hemen atlayabilirsiniz).

  

Açıklamalar Nasıl Görüntülenir

Yukarıdaki örneklerde, alan açıklamalarını görüntülemenin birkaç yolunu gördük. İşte ne yapacağınızın bir özeti:

• Satır içi açıklamalar doğrudan görünür olmalı ve alanın yanında görüntülenmelidir.
• Ağır içerikli daha ayrıntılı açıklamalara ihtiyacınız varsa, araç ipuçlarını veya modları kullanabilirsiniz. Araç ipuçları genellikle masaüstünde üzerine gelindiğinde ve mobilde dokunulduğunda tetiklenir. Aynısı modlar için de geçerlidir: Örneğin, kullanıcı yardım simgesine veya "daha fazlasını gör" bağlantısına dokunduğunda açın.

Yer Tutuculara Dikkat Edin

Anlıyorum: Yer kazanmak ve bunun yerine yer tutucuları kullanmak için mobil cihazlarda alanları kaldırmak cazip geliyor. Hepimiz o yoldan geçtik. Ama lütfen yapma. HML5 spesifikasyonu bu konuda nettir: “Yer tutucu özniteliği, kullanıcıya veri girişinde yardımcı olmayı amaçlayan kısa bir ipucunu (kelime veya kısa tümce) temsil eder”. Ve işte nedeni:

• Kullanıcı yazmaya başladığında yer tutucu kaybolur. Kullanıcı daha sonra alana ne koyması gerektiğini hatırlamak için kısa süreli belleğe güvenmelidir . Yapamazlarsa, göstergeyi görmek için alanı boşaltmaları gerekecektir.
• Alanlarda artık herhangi bir etiket göstergesi bulunmadığından , kullanıcıların göndermeden önce alanları iki kez kontrol etmesi zordur .
• Bir alan gönderildikten sonra hatalardan kurtulmak zordur çünkü yine kullanıcıya yardımcı olacak bir etiket yoktur.

Etiketli yer tutucular kullansanız bile, yine de bazı sorunlarınız olabilir. Doldurulmuş bir alan ile yer tutuculu bir alan arasındaki farkı söylemek zor . Ben mobil form tasarımı hakkında yazan bir UX tasarımcısıyım ve hatta geçen hafta bunlardan biri tarafından kandırıldım. Benim başıma gelirse, kullanıcılarınızın başına gelir - bu konuda bana güvenin. Son olarak, yer tutucuların çoğunda açık gri metin vardır, bu nedenle bazı kontrast sorunlarınız da olabilir.

Bu konuda daha derine inmek istiyorsanız, “Placeholder Attribute Is Not A Label” adlı harika bir makale var ve ayrıca Joshua Winn ve FeedbackGuru bunun neden kötü bir fikir olduğuna dair ayrıntılara giriyor. Nielsen Norman Group ayrıca "Form Alanlarındaki Yer Tutucular Zararlı" başlıklı bir makale yazdı.

HTML5'te yer tutucular zorunlu değildir . Kullanılabilirlik açısından, kesinlikle formunuzun her alanında bir yer tutucuya ihtiyacınız yoktur. Ancak Bootstrap ve diğer çerçevelerin büyük ölçüde benimsenmesiyle, birçok insan bileşenleri kopyalayıp yapıştırıyor gibi görünüyor. Bu bileşenlerin yer tutucuları var, bu yüzden sanırım insanlar koddaki yer tutucuya bir şeyler eklemek zorunda hissediyorlar mı? Formunuzun yer tutucuları "Lütfen - etiketinizi - buraya doldurun" gibi görünüyorsa, yanlış yapıyorsunuz demektir.

Bununla birlikte, alanların içindeki etiketler, alanların tahmin edilebilir olduğu kısa formlar için iyi çalışabilir . Giriş formları bunun için iyi bir adaydır. Ancak lütfen bunu kodlamak için HTML5 yer tutucusunu kullanmayın. Kodda gerçek bir etiket kullanın ve onu CSS ve JavaScript ile hareket ettirin.

Android'in malzeme tasarımının başarısından bu yana bir model ortaya çıkmaya başladı: yüzen etiket. Bu etiket, alan doldurulmadığında alanın içindedir, bu nedenle mobilde biraz daha az dikey alan kaplar. Kullanıcılar alanla etkileşime girmeye başladığında, etiket alanın yukarısına hareket eder.

Bu, yukarıda belirtilen "etiketler yerine yer tutucular" sorunlarına girmeden biraz alan kazanmanın ilginç bir yolu gibi görünüyor. Yine de, kullanıcıların bir yer tutucuyu doldurulmuş içerikle karıştırması sorununu çözmez.

Başarılı Formlar İçin Etkileşim Maliyetinin Azaltılması

Görevlerini gerçekleştiren kullanıcıların etkileşim maliyetini (ör. dokunma, kaydırma vb.) azaltmak, kusursuz bir form deneyimi oluşturmanıza yardımcı olacaktır. Bunu başarmak için farklı teknikler var. Birkaç tanesine ayrıntılı olarak bakalım.

İnternette Bir Sihir Çalışması Bana Alan Sayısını Azaltmamı Söyledi

Daha fazla alan, daha az dönüşüm anlamına gelir, değil mi? “Abonelik formumuzu 11 alandan 4 alana indirdik ve dönüşümleri %160 artırdık” çalışmasıyla karşılaşmış olabilirsiniz. Bu bir klasik. Ve onların iletişim formuna bakarsanız, bu biraz mantıklı. Kullanıcılar neden sadece şirketle iletişim kurmak için 11 alanı doldurmak istesinler? Seni zar zor tanıyan insanlardan bu kadar büyük bir bağlılık isteyemezsin, değil mi?

Yalnızca yararlı bilgiler isteyerek başlayın. Bir hesap oluşturmak için neden bir kişinin cinsiyetine ihtiyacınız var? Abonelik formunuz çevrimiçi bir hizmet içinse, adres için neden iki satırınız var?

Yalnızca ihtiyacınız olan bilgileri isteyin. Ve sonra bağlamdaki bilgileri isteyin. Bir e-ticaret web siteniz varsa, kullanıcılar kaydoldukları zamana göre ödeme sürecinin kargo bölümünde size adreslerini vermeye daha meyilli olabilirler. E-ticaret kayıt formunuzu mobil cihazlarda doldurmayı çok daha kolay hale getirecek!

Ayrıca internette bulduğunuz her istatistik ve araştırmaya körü körüne güvenmeyin. 11 alandan 4'e çalışmasını hatırlıyor musunuz? Daha yakın tarihli bir başka çalışma, alanları 9'dan 6'ya düşürerek dönüşümlerin %14 düştüğünü gösterdi. Şok edici, değil mi? Niye ya? En ilgi çekici alanları kaldırdılar. Uzun lafın kısası, daha sonra 9 alana geri döndüler, en önemlisini en üste koydular ve işte, dönüşümler %19.21 arttı.

Sonuç olarak, bu çalışmalar ilginç olsa da, bu web siteleri sizin web siteniz değil. İnternette bulduğunuz ilk araştırmaya körü körüne güvenmeyin.

Peki ne yapabilirsin? Ölçek. Ölçek. Ve test et!

• Mobil formunuzu tamamlama zamanını görmek için bazı kullanıcı testleri yapın.
• Çıkışları ölçün.
• Belirli alanlarla ilgili sorunları ölçün.
• Belirli alanlarla ilişkili hayal kırıklığını ölçün. Kullanıcılar bu bilgiyi vermeye ne kadar istekli? Bu bilgi ne kadar kişisel?

Dokunmatik Etkileşimleri Optimize Etme

Kontrolleri Dokunmatik Dostu Hale Getirme

Alanlarınız çok küçük veya ulaşılması zorsa, kullanıcılar hata yapacak ve hedeflerine ulaşmak için ekstra etkileşimlere ihtiyaç duyacaktır. Fitt yasasını hatırlıyor musun? Bunu mobil tasarıma da uygulayabilirsiniz: Dokunma hedefi boyutunu artırarak etiketlerinizi, alanlarınızı ve form kontrollerinizi dokunmayı kolaylaştırın. Web'deki etiketler için biraz daha fazla dolgu, dokunulabilir alanı artırabilir. Bazen, kaçırılan muslukları önlemek için öğeler arasına biraz boşluk eklemeniz de gerekebilir.

Ayrıca for ve kimlik değerlerini eşleştirerek etiketleri bileşenleriyle ilişkilendirmeyi unutmayın. Bu şekilde, kullanıcı etikete dokunmayı kaçırırsa, ilgili alan yine de odaklanacaktır.

Steven Hoober, dokunmatik alanlar hakkında bazı kullanıcı araştırmaları yaptı. “Dokunma için Tasarım” bölümünde bir özet bulacaksınız. Keşfettiklerinden yola çıkarak küçük bir plastik cetvel aracı yaptı: mobil dokunmatik şablon. Araç, dokunma alanlarınızın mobil formlar ve daha genel olarak mobil tasarım için yeterince büyük olduğundan emin olmanıza yardımcı olabilir.

Dokunma için tasarım hakkında daha fazla bilgi edinmek için aşağıdakileri okuyabilirsiniz:

• “Parmak Dostu Tasarım: İdeal Mobil Dokunmatik Ekran Hedef Boyutları”
• “The Thumb Zone: Mobil Kullanıcılar için Tasarım”

Geribildirim Sağlamak

Mobil kullanıcıların faresi yoktur (şaka değil), bu nedenle masaüstü kullanıcılarının bir düğmeye bastıklarında aldıkları "tıklama" geri bildirimini almazlar. Mobil form kullanıcıları, öğelerle etkileşim kurarken net geri bildirime ihtiyaç duyar:

• Kullanıcının etkileşimde bulunduğu form alanı için bir odak durumu sağlayın .
• Kullanıcı bir düğmeyle etkileşim kurduğunda görsel geri bildirim sağlayın.

Malzeme tasarımının düğmeler üzerindeki dalgalanma etkisinin büyük bir hayranı değilim. Ancak, Android'deki animasyonların, kullanıcı bir düğmeyle etkileşime girdiğinde net geri bildirim sağladığını itiraf etmeliyim.

Sonraki ve Önceki Düğme Sırasını Onurlandırın

Son olarak, mobil klavyelerdeki sonraki ve önceki düğmeleri onurlandırın. Kullanıcılar, alanlarda hızla gezinmek için bunları kullanabilir. tabindex sırası, alanların ve bileşenlerin görsel sırasına uymalıdır.

Mümkünse Mobilde Açılan İndirmelerden Kaçının

Web'deki açılır menüler (HTML seçme öğesi) çok sayıda sekme ve etkileşim gerektirir. Bu nedenle, Luke Wroblewski'nin dediği gibi, son çare olarak UI olmalıdırlar. Diğer birçok UI bileşeni, birçok durumda açılır listelerden daha iyi çalışır.

Segment kontrolleri ve radyo düğmeleri , iki ila dört seçeneğiniz varsa, açılır menülere iyi alternatiflerdir. Hepsini doğrudan tek bir ekranda gösterebilecekken, seçenekleri neden bir açılır listenin altına gizleyesiniz? Radyo düğmeleri gibi, segment kontrollerinin de birbirini dışladığını unutmayın.

Bir ülke listesi , bir bileşen için iyi bir adaydır. Yüzden fazla ülkenin listelenmesi, mobil cihazlarda bir etkileşim kabusu. Afganistan'ı (listenin başında) veya Zimbabve'yi (listenin sonunda) arıyorsanız sorun değil. Lüksemburg'u arıyorsanız, listenin ortasına ulaşmak için kaydırma, M harfine çok ileri gitme, L'ye geri dönmeye çalışma vb.

Uzun açılır menüler, tahmini metin giriş alanları ile değiştirilebilir . Kullanıcı L yazmaya başladığında, arayüz dokuz ülke önerecektir. Bir U eklerlerse - işte! — Lüksemburg öyle. Açılır menü ile altı veya yedi kaydırmalı etkileşime karşı iki yerine dört etkileşim.

Kullanıcıların bir tarih seçmesine ihtiyacınız varsa, insanların kağıt formlar üzerinde yapmaya alışık olduğu gibi bir gün, ay ve yıl açılır listesine bölmeyi unutun . Birden çok tarih açılır listesini bir tarih seçiciyle değiştirin . HTML5 giriş type=date çoğu durumda çalışır. Ancak, özellikle rezervasyon işindeyseniz (oteller, arabalar, uçuşlar) bazı özel ihtiyaçlarınız olabilir ve JavaScript'te kendi tarih seçicinizi oluşturabilirsiniz.

Klaus Schaefers, “Mobil DropDowns Revisited” adlı makalesinde varış ve ayrılış tarihleri ​​için bir tarih seçici kullanmanın etkileşimleri nasıl %60 daha hızlı hale getirdiğini açıklıyor.

Rezervasyon işine devam edelim. Kullanıcının seyahat planlarına birden fazla gezgin eklemesi gerektiğini varsayalım. Yolcu sayısını seçmek için **açılır menüyü * bir * stepper** ile değiştirebilirsiniz. Stepper, kullanıcının sadece + ve - düğmelerine dokunarak değerleri artırıp azaltmasına izin veren bir kontroldür. Bu, altıdan daha az kişinin eklenmesi gerektiğinde daha hızlı olma eğilimindedir. Ayrıca daha sezgisel. Aşağıda, konukları seçmek için Android'e özgü Airbnb uygulamasında ve yolcu eklemek için mobil cihazlar için optimize edilmiş Kayak web sitesinde kullanılan bir stepper örneği verilmiştir.

Açılır listelere son bir alternatif, liste görünümüdür. Seçenekler, örneğin radyo düğmeleri gibi belirli bir alt görünümde listelenir . Android ayarları çoğunlukla bu şekilde çalışır.

Otomatik Tamamlama ile Akıllı Olmak

Formunuzun etkileşim maliyetini azaltmak istiyorsanız akıllı olun. Kullanıcıların size verdiği diğer bilgilere dayanarak otomatik olarak tespit edebileceğiniz veya tahmin edebileceğiniz bilgiler istemeyin. Mümkün olduğu kadar otomatik tamamlama ve önceden doldurma.

Yerler ve Adresler

Kullanıcı bir yer ararsa veya bir adres girmesi gerekiyorsa, onlara yardımcı olmak için otomatik tamamlamayı sunabilirsiniz. Onlar yazarken, bir API onlar için adresin geri kalanını doldurur. Bu da hataları azaltır.

Kullanabilirsin:

• Google Rehber API'sı
• OpenStreetMap tabanlı Algolia Places

Fransa'da ve diğer birçok ülkede, şehri alan koduna göre tahmin edebilirsiniz. Bu nedenle, bir Fransız kullanıcı bir alan kodu girerse, otomatik olarak otomatik olarak tamamlayabilir veya en azından şehri önerebilirsiniz. Ülkem Lüksemburg küçüktür (benimle dalga geçme). Alan kodum sokağıma bağlı. Yani alan kodumu girersem, form benim sokağımı bile önerebilir.

Kredi kartları

Otomatik algılamanın kolay olduğu bir diğer alan da kredi kartlarıdır. Kullanıcıya ne tür bir kredi kartına sahip olduğunu sormanıza gerek yoktur. Bunu, girdikleri ilk sayılara göre otomatik olarak algılayabilirsiniz. İşi sizin için yapabilecek bir kütüphane bile var.

HTML5 Otomatik Tamamlamayı Kullanma (Otomatik Doldurma)

HTML otomatik tamamlama özelliği, kullanıcının önceki girdilerine dayalı olarak alanları önceden doldurabilir. Bu özniteliğin bir açık ve kapalı durumu vardır. Bazı akıllı insanlar, bunu daha güçlü hale getirmek ve form alanları için otomatik tamamlama özelliğini genişletmek için bir belirtim üzerinde çalışmaya başladı. WHATWG'nin de ilginç bir listesi var.

Chrome ve diğer mobil tarayıcılar, kredi kartları ve adlar için bazı genişletilmiş değerleri zaten desteklemektedir. Bu, kullanıcıların diğer web sitelerinde kullandıkları adları ve kredi kartı verileriyle formları önceden doldurabilecekleri anlamına gelir.

Kısacası, farklı sistemler arasında seçim yapmanız gerektiğinde, her birinin gerektireceği etkileşim sayısını sayın.

Hatalar Oluyor: Mobil Formlarda Hataları İşleme

Daha iyi mobil formlara doğru yolculuğumuzun son adımı, hataları ve hataları ele almaktır. Kullanıcının bilişsel yükünü hafifletmek için hataları azaltmaya çalışabiliriz. Ayrıca, form tasarımınız ne kadar harika olursa olsun, hatalar meydana geldiğinden, hatalardan kurtulmalarına da yardımcı olabiliriz.

Formları Doldururken Hatalardan Kaçınma

“Önlemek tedavi etmekten iyidir” derdi annem. Bu, form tasarımı için de geçerlidir: Hataları önlemek, mobil formunuzun deneyimini iyileştirecektir.

Açık Biçim Sınırlaması

“Yaptığınız işte muhafazakar olun. Başkalarından kabul ettiğiniz şeylerde liberal olun.” Bu sağlamlık ilkesi, alanları oluşturmak için de uygulanabilir. Mümkünse, kullanıcının herhangi bir biçimde veri girmesine izin verin.

Bir kullanıcının alana girebileceklerini sınırlamanız gerektiğini düşünüyorsanız, kendinize “neden” diye sorarak başlayın. Kullanıcı deneyimi alanında “üç neden” adı verilen bir tekniğimiz var. Cevap "çünkü falan filan veritabanı" ise, belki bir şeyleri değiştirmenin zamanı gelmiştir. Örneğin, kullanıcı adı alanında e, a ve o gibi özel karakterleri neden reddediyorsunuz? Kullanıcı adı olarak “Stephanie” girmeye çalıştığımda bana ne kadar kaba formlar olduğunu anlatan bir yazı yazdım. Hala bunun için iyi bir neden bulmaya çalışıyorum (veritabanı nedenleri dışında).

Kullanıcılardan belirli bir biçim talep etmek için iyi bir nedeniniz varsa, bunu önceden belirtin . Kullanıcılara verilerin nasıl görünmesi gerektiği konusunda bir ipucu vermek için HTML5 yer tutucularını kullanabilirsiniz, ancak yine de bunlara dikkat edin. Bu makalenin başında açıklanan tüm alan tanımlama tekniklerini de kullanabilirsiniz. Son olarak, girdi maskeleri kullanıcıları doğru biçime yönlendirebilir.

Zorunlu Alanları İşaretleme (Ve İsteğe Bağlı Alanlar)

Kullanıcıların, zorunlu alanlar hakkında bilgi vermek için yarım doldurulmuş bir form göndermelerini beklemeyin. Bir alan zorunluysa, kullanıcılar bunu bilmelidir . Zorunlu alanların yıldız işareti ( * ) ve açıklama ile işaretlenmesi, formlar için standart bir kalıp haline gelmiştir. İyi yanı, fazla yer kaplamamasıdır. Sorun şu ki, anlamsal bir değeri yoktur, bu nedenle kötü kodlanmışsa ve form etkileşimi ile insanların alışkanlıklarına güveniyorsanız erişilebilirlik sorunlarına neden olabilir.

Bunun yerine hem zorunlu hem de isteğe bağlı alanları "zorunlu" (veya "zorunlu") ve "isteğe bağlı" sözcükleri ile açıkça işaretleyebilirsiniz . Hem Baymard Enstitüsü hem de Luke Wroblewski bu konuda hemfikir. Bu, örneğin bir kaydırma çubuğu kullanırken, başka bir şeyle ilerlerken, sonra geri dönerken ve zorunlu alanların bir yıldızla mı yoksa başka bir şeyle mi işaretlendiğini hatırlamadığında olduğu gibi, mobilde uzun formlarla ilgili belirsizliği önler.

Sonunda, bu alanların nasıl işaretleneceğine ilişkin karar, alanın tasarımına, uzunluğuna ve bağlama bağlı olacaktır. Doğru kararı verip vermediğinizi bilmenin en iyi yolu yine formu test etmektir.

Mantıklı Varsayılanlar

Formlarda varsayılan seçili seçenekler konusunda dikkatli olun . Bir önceki işime başvurduğumda bir bilgi formu vardı. Medeni durum isteğe bağlıydı. Açılır menüdeki ilk öğeyi, varsayılan alan olan "boşandı" yaptılar. Bu yüzden ya cevap veremedim (isteğe bağlı bir alan olduğu için) ve sistemin boşandığıma inanmasına izin veremedim ya da bunu düzeltip istemesem de gerçek medeni durumumu ifşa edemedim.

Ayrıca cinsiyet konusunda dikkatli olun. Yine, ifşa etmek istemeyenler için bir seçeneğimiz var; cinsiyetlerini neden sorduğunuzu açıkça belirtin; daha da iyisi, zamirleri isteyin ya da gerçekten ihtiyacınız yoksa sormayın. If you are interested in this topic, I recommend “Designing Forms for Gender Diversity and Inclusion.” And if the gender is optional, again, don't auto-check the first choice, otherwise people won't be able to uncheck that radio button and choose not to answer.

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you're in a Dr. Who episode, you're not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can't select a date in the past. When you select a return date, the default is the day after the departure date.

Less Painful Password Experience

I've written about password-less authentication, but you can't always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

• When Creating An Account
  I won't get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don't let people guess. Tell users your password criteria up front .
  
  A lot of websites now show you a gauge for password strength telling you in real time what is missing . This is an interesting and excellent pattern. KLM uses it in its sign-in form:

  

  But there are still some big problems with this design.

1. They don't tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
2. They limit the password's length to 12 characters, but they never tell users how many characters are left. Sure, let's add "counting the dots" to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
3. What happens if, like me, you reached the 12-character limit but haven't met all of the criteria? Well, you would just have to delete the entire password and start over again.
4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.

• Giriş Yaparken
  Bir oturum açma formunda, bir parolayı maskeleme/maskeyi kaldırma seçeneği , kullanıcı deneyimini büyük ölçüde iyileştirecektir.
  Amazon'un giriş formunda parolaları yineleme konusunda ilginç bir geçmişi var. Şifreyi göremediğiniz bir sürümü vardı. Bir sonraki yineleme, kullanıcıların onu ortaya çıkarmasına izin verdi. Ardından, parola varsayılan olarak ortaya çıktı ve onu gizleyebilirsiniz. 2015'te şöyle görünüyordu:

  

  Amazon son sürümü test etti ve %60 kişi şüphelendi. Bu nedenle, "şifreyi gizle" işaretlenmemiş onay kutusunu "şifreyi göster" işaretli kutusuyla değiştirdiler. Bu, kullanıcı yazarken şifreyi alanın altında daha küçük karakterlerle gösterir. Bu makaleyi yazarken göründüğü gibi:

  

  Gördüğünüz gibi, iyileştirme için her zaman yer vardır.

Satır İçi Doğrulama

Kullanılabilirlik ilkelerine aşinaysanız, Gestalt yakınlık yasasını biliyor olabilirsiniz. Mobil cihazlarda, kullanıcı gönder düğmesine dokunduktan sonra, sayfanın üst kısmında, bağlamsal bilgiler olmadan hataların özetini görmekten kaçının.

Bunun yerine, hata mesajları hataların kendilerine yakın yerleştirilmelidir .

Gerçek Zamanlı Doğrulama

Ayrıca, kullanıcıların gönder düğmesine basmasını beklemeniz gerekmez. Kullanıcı bunları doldururken alanları doğrulayabilir ve geri bildirim görüntüleyebilirsiniz .

Birkaç ipucu:

• Daha önce belirtildiği gibi, parola alanları gerçek zamanlı doğrulamadan ve her tuş vuruşunda geri bildirimden yararlanacaktır.
• Ayrıca, kullanılabilir olduklarından emin olmak için hesaplar oluşturulurken kullanıcı adlarını gerçek zamanlı olarak doğrulamak isteyebilirsiniz. Twitter bu konuda iyi iş çıkarıyor.
• Her tuş vuruşunu doğrulamayın. Kullanıcı yazmayı bitirene kadar bekleyin. (Web formları için JavaScript blur kullanın veya hareketsizliği algılamak için birkaç saniye bekleyin.)

Not : *Mihael Konjevic, “Formlarda Satır İçi Doğrulama: Deneyimi Tasarlamak” üzerine güzel bir makale yazmıştır. “ Erken ödüllendir, geç cezalandır ” kavramını açıklıyor.*

“Kullanıcı, geçerli durumda olan alana veri giriyorsa, veri girişi sonrasında doğrulama işlemini gerçekleştirin.”

“Kullanıcı geçersiz durumda olan alana veri giriyorsa, veri girişi sırasında doğrulama işlemini gerçekleştirin.”

Renk Önemlidir

Şu anki kızıl, pembe ve mor saç rengim yüzünden rengin önemli olduğunu söylemiyorum. Renk, form tasarımında gerçekten önemlidir.

Web'de bozmak istemediğiniz bazı kurallar vardır. Renk körü olmayan kullanıcılar, kırmızının hatalar, sarının uyarılar ve yeşilin neredeyse her zaman onay veya başarı için olduğunu bilir. Bu üç renge bağlı kalmak en iyisidir. Yine de kırmızı insanları endişelendirebilir. Kullanıcı gerçekten ciddi bir hata yaptığını düşünebilir. Hata mesajları için turuncu veya sarı kullanmak daha az paniğe neden olabilir. Sarı ve turuncu ile ilgili sorun, bunların renk körü dostu tonlarını bulmanın zor olmasıdır.

Renk körlüğünden bahsetmişken: Renk, bir hata mesajını iletmenin tek yolu olmamalıdır . Bu bir erişilebilirlik kriteridir.

Aşağıdaki soldaki örnekte hatalı alan turuncu, düzeltilen alan ise yeşile dönmüştür. Ortadaki ekran görüntüsünü almak için bir renk körü test aracı kullandım: Artık varsayılan gri kenarlık ile yeşil kenarlık arasında ayrım yapamazsınız. Son ekran görüntüsüne bazı simgeler eklemek, hata mesajlarının renk körü kişilere iletilmesini sağlar.

Hatalardan Kurtulma: Kullanıcı Dostu Hata Mesajları Yazma

Bu noktada, kullanıcıların formlarımızı doldurmalarına ve hatalardan kaçınmalarına yardımcı olmak için elimizden gelen her şeyi yaptık. Ancak bazen, tüm çabalarımıza rağmen hatalar olur. Kullanıcıların bu hatalardan kurtulmalarına nasıl yardımcı olacağınızı bulmanın zamanı geldi.

İlk olarak şunu unutmayın: Sistemin kontrolünü ele geçirmeyin. Bir sorun kritik değilse, kullanıcı arayüzün geri kalanıyla mümkün olduğu kadar çok etkileşime devam edebilmelidir. Mümkün olduğunda kullanıcıları engelleyen JavaScript uyarı hata mesajlarından ve modellerinden kaçının. Ayrıca, formunuzun bir izne ihtiyacı varsa, kullanım akışında isteyin. İzin verilmezse, verilmediği için bunu bir hata olarak kabul etmeyin. Burada kullandığınız kopyaya dikkat edin.

Siz Robot değilsiniz, Kullanıcılarınız da Robot Değil

Robotlar havalı, biliyorum. Ama siz bir robot değilsiniz ve kullanıcılarınız da değil. Yine de pek çok hata mesajı hala çok kötü yazılmış. Konu insan dostu hata mesajları olduğunda birkaç ipucu:

• Asla “2393 tipi bir hata oluştu” gibi ham bir hata mesajı göstermeyin. Sunucu işlemi tamamlayamadı.” Bunun yerine, ne olduğunu ve neden olduğunu insan dilinde açıklayın .
• Asla "Bir hata oluştu" gibi bir çıkmaz hata mesajı göstermeyin. Bunun yerine hatadan kurtulmanın yollarını önerin . İşlem yapılabilir kopya yazın.
• Asla "Tekrar dene" düğmesiyle "Belirtilen ana bilgisayar adına sahip bir sunucu bulunamadı" gibi belirsiz bir hata mesajı göstermeyin. Bunun yerine, hata mesajlarını bilgilendirici ve tutarlı hale getirin . Lütfen robot gibi konuşma.
• İnsanların bir mesajın içeriğini bildiğini varsaymayın. Kullanıcılarınız teknoloji meraklısı inekler değil. Bunun yerine, onlara bu hatadan nasıl kurtulacaklarını teknik jargon kullanmadan sade bir dille açıklayın .

Mesajlarda Kullandığınız Dile Dikkat Edin

Ne yazarsan yaz, insanları bir hata konusunda aptal hissettirmekten kaçının . Mümkünse olumsuz kelimeleri dışarıda bırakın ; insanları korkutma ve daha da endişeli hale getirme eğilimindedirler. Bunun yerine nazik, olumlu, onaylayıcı bir ton kullanın.

Hatalar için kullanıcıları suçlamayın ; bunun yerine sistemi suçlayın. Sistem kin tutmayacak, söz veriyorum. Kullanıcının dikkatini sistemin eylemi nasıl gerçekleştiremediğine çevirin ve onlara nasıl bir çözüm bulabileceklerini açıklayın.

Küçük bir numara, kendi mesajınızı yüksek sesle okumaktır. Çalışıp çalışmadığını veya çok sert veya çok rahat olup olmadığını duymanıza yardımcı olacaktır.

Ayrıca hata mesajları konusunda yaratıcı olabilir ve onları daha az tehdit edici hale getirmek için görüntü ve mizahı bir araya getirebilirsiniz. Bu gerçekten markanızın kimliğine ve tonuna bağlı olacaktır.

Daha iyi bir hata mesajı yazmanıza yardımcı olması için aşağıdakileri okumanızı öneririm:

• “UX Yazarları Olmayan Ürün Ekipleri İçin 6 Noktalı Mikrokopi Kontrol Listesi”
• “Hata Mesajı Sanatı: İşler Ters Gittiğinde Anlaşılır, Faydalı Kopya Yazmak”

Formu Gönderme Zamanı

Kullanıcı formu doldurdu, artık hata yok ve her şey yolunda görünüyor. Son olarak, formu gönderme zamanı!

İlk kural, gönder düğmesini maskelememektir . Gerçekten! Bu fikrin hangi çarpık aklın ortaya çıktığını merak ediyorum, ama bunu bazı biçimlerde gördüm. Gönder düğmesi, yalnızca tüm gerekli alanlar hatasız bir şekilde doldurulduğunda görüntülenecektir. Kullanıcının bir şeylerin yanlış olup olmadığını veya formun düğmesinin yüklenmediğini veya web sitesinin bozuk olup olmadığını merak etmesi rahatsız edicidir.

Zorunlu alanlar eksikse veya doğrulama hataları varsa, kullanıcıların gönder düğmesine basabilmesini istemiyorsanız , submit girişinde disabled HTML özniteliğini kullanın. Form geçerli ve gönderilmeye hazır olduğunda JavaScript kullanarak düğmeyi yeniden etkinleştirmeniz gerekecektir.

Birincil ve ikincil bir harekete geçirici mesajınız varsa, hiyerarşiyi göstermek için renk, boyut ve stil kullanın .

Onay butonunun iptal butonundan önce mi sonra mı geleceğini merak ediyorsanız, ben de (ve diğer birçok insan) ben de öyleyim. Yerel bir uygulama oluşturuyorsanız, işletim sistemi yönergelerine bağlı kalın. Android, dördüncü sürümünde düğme konumlarını değiştirdiğinden beri özellikle eğlenceli hale geldi. Web'de, gerçek yönergeler olmadığı için daha karmaşıktır. İşletim sisteminden bağımsız olarak, mobil cihazlar için optimize edilmiş gönderme düğmeleri için bazı genel yönergeler şunlardır:

• Eylem çağrısını açıklayıcı, eyleme geçirilebilir fiiller verin.
• Kullanıcı dokunduğunda görsel geri bildirim sağlayın.
• İki düğmeniz varsa , birincil eylemi öne çıkarın .
• Çok özel bir arka ofis kurumsal formu üzerinde çalışmıyorsanız (bu durumda, mobil için optimizasyon yaparken birçok zorlukla karşılaşırsınız), sıfırlama düğmesinden kaçının . Kullanıcılar bunu gönder düğmesiyle karıştırabilir ve yanlışlıkla tüm verilerini kaybeder.

Çözüm

Bu ilk bölümde, formunuzu bir sonraki düzeye taşımak ve kullanıcıların formu doldurmasına yardımcı olmak için pek çok küçük teknikten bahsettim. Bu genel yönergelerden ve mobil en iyi uygulamalardan bazıları zamanın %100'ünde çalışmayabilir. Asıl mesele bu. en iyi uygulamalarla. Bu nedenle, formlarınızı her zaman gerçek kullanıcılar ve gerçek cihazlarda test edin ve yönergeleri kullanıcılarınızın özel ihtiyaçlarına ve deneyimlerine göre uyarlayın.

Ayrıca, yine gerçek cihazlarda biraz gerileme ve otomatikleştirilmiş işlevsel testler yapın. Chrome'un mobil öykünücüsü, dokunma için optimize edilmiş formları test etmek için yeterli olmayacak. Bunu söylüyorum çünkü mobilde çalışmayan bir arama formuna sahip bir e-ticaret sitesi açmıştım. Yalnızca bir öykünücü kullanarak otomatik testler yaptık. İşte olanlar. Arama formu bir arama simgesinin altına gizlendi. Arama alanını içeren bir kutu açan düğmeye dokunabilirsiniz. Bir dokunma olayı olarak bir fare vurgusunu taklit ederek çalıştı. Düğmeye dokunarak test ettik ve kutuyu açtı. Kimse arama başlatmaya çalışmadı. Böylece, hiç kimse (müşteri bile), kullanıcılar onunla etkileşime girmeye çalıştığında arama alanının kaybolduğunu görmedi. Ne oldu? Giriş öğesi odaklandığında, düğme vurgulu durumunu kaybetti, bu nedenle alanla birlikte kutuyu kapattı. Otomatik test bunu yakalayamadı çünkü girdi odağı kaybetmedi. Bu nedenle, mobilde arama işlevi olmayan bir e-ticaret web sitesini kullanıma sunduk. Süper bir deneyim değil.

Bu serinin ikinci bölümünde, daha gelişmiş mobil özel teknikler göreceğiz. Alanları biçimlendirmek için harika HTML5 özelliklerinin nasıl kullanılacağını ve mobil kullanıcı deneyimini bir sonraki düzeye taşımak için mobil yeteneklerin nasıl kullanılacağını göreceğiz.