Mobil arayüz tasarımının ilkeleri

Mobil arayüz masaüstünden nerede ayrılır?

Üç noktada ve üçü de teknik değil. Birincisi girdi: fare imleci bir nokta, başparmak ise yumuşak bir leke; farenin tam isabet ettirdiğini başparmak yarı yarıya ıskalar. İkincisi duruş: masaüstü kullanıcısı oturur, mobil kullanıcı genellikle yürür ya da bekler. Üçüncüsü kesinti: telefonda her an bir arama ya da bildirim gelir, kullanıcı geri döner ve nerede kaldığını çıkarması gerekir.

Mobil arayüz aynı görünür ve dokunulur katmandır, ama bu üç kısıt altında. Gerisi buradan çıkar: neden her ekranda tek birincil eylem, neden ana düğmeler aşağıda, neden form kısa, neden yükleniyor durumu önemli.

İşi dört sütun yapar. Başparmak erişimi, telefonu elde kaydırmadan neye basılabileceğini söyler. Hiyerarşi, gözün ilk nereye düşeceğini söyler. Geri bildirim, dokunuştan sonra ekranın bir şeyin olduğunu nasıl gösterdiğini söyler. Tutarlılık, bir kalıbın her ekranda aynı kaldığını söyler.

Dersin kalanı net olsun diye bir şeyi baştan söyleyelim: arayüz tasarımının ilkeleri mobilde de geçerlidir ve onları burada tekrarlamıyoruz. Temeli okumadıysanız başlangıç noktası kullanıcı arayüzü tasarımının ilkeleridir; bu ders yalnızca mobilin eklediğini ya da değiştirdiğini anlatıyor.

Başparmak nereye ulaşır ve hedef ne kadar olmalı?

Telefonu tek elle tutun ve kaydırmadan başparmağınızı döndürün. Ekran dört bölgeye ayrılır: elin bulunduğu tarafta aşağıdaki rahat bölge, ortada ve üste yakın uzanma bölgesi, telefonu elde kaydırmadan ulaşamadığınız uzak köşe ve büyük telefonlarda tek elle fiilen erişilemeyen üst çubuk. Bir ekranın birincil eylemi ilk bölgeye aittir; silme gibi tehlikeli bir eylem ise bilerek daha zor basılan bir yere gider.

Hedef boyutu ise tahmin işi değildir, çünkü sayısı vardır ve sayılar yayımlanmıştır. WCAG 2.2, 2.5.8 ölçütünde, işaretçi girdileri için hedefin en az 24 e 24 CSS pikseli olduğunu söyler; kendi saydığı istisnalarla: çevresinde yeterli boşluk bulunan daha küçük bir hedef, aynı işlevin sayfada başka bir yolla yapılabilmesi ya da hedefin bir cümlenin içinde olması. Android in kendi erişilebilirlik rehberi daha büyük bir sayı verir: en az 48 e 48 yoğunluktan bağımsız piksel, iki hedef arasında en az 8 birim ayrım ve 48 birimin her ekranda yaklaşık dokuz fiziksel milimetreye denk geldiği açıklaması.

Aynı Google sayfasında sayının kendisinden daha işe yarar bir nokta var: dokunma hedefi öğenin görsel sınırlarının dışına taşar. 24 birim genişliğinde görünen bir simge, çevresindeki dolgu sayesinde 48 birimlik bir hedef olur. Yani düğmeyi büyütüp çirkinleştirmeniz gerekmez; dokunuşu dinleyen alanı büyütmeniz gerekir.

Ve herkesin aktardığı sayı hakkında bir uyarı. "Apple 44 e 44 punto diyor" cümlesi, mobil tasarım üzerine her Türkçe ve İngilizce yazıda tekrarlanır. Bugün Apple ın İnsan Arayüzü Kılavuzu sayfalarını taradık: yerleşim sayfası, erişilebilirlik sayfası, düğmeler sayfası, hareketler sayfası. Bu sayı hiçbirinde asgari dokunma hedefi olarak yazılı değil. 44 puntoyu gördüğümüz tek yer visionOS düğme boyutları tablosuydu ki o başka bir şey. Yani sayı yanlış demiyoruz; ona canlı bir kaynak bulamadık ve Apple a söylemediği bir sözü yakıştırmaktansa bilmiyoruz demeyi yeğleriz. Dayanabileceğiniz sayılar yukarıdaki ikisidir.

Platform kuralını mı izlemeliyim, kendi tasarımımı mı?

Kısa yanıt: kullanıcının içinde hareket ettiği her şey platforma, markanız olan her şey size aittir. Geri düğmesinin davranışı, kenardan kaydırma hareketi, sekme çubuğunun yeri, klavyenin davranışı ve tarih seçicinin biçimi, kullanıcınızın uygulamanızı kurmadan önce bin kez karşılaştığı şeylerdir. Bunları değiştirirseniz yaratıcı olmuş olmazsınız; kullanıcının zaten bildiği bir şeyi elinden almış olursunuz.

Buna karşılık renk, illüstrasyon, metnin tonu, tanıtım ekranı ve ürün kartı sizindir ve orada herkese benzemek size hiçbir şey kazandırmaz. Pratik sınır basit: bir şeyi değiştirmek kullanıcıyı onu yeniden öğrenmeye zorluyorsa değiştirmeyin.

Yüklenicilerin genelde geç söylediği bir nokta: platform kuralına uymak daha pahalı değil, daha ucuzdur. Standart Android ve iOS bileşenleri sistem yazı boyutuyla, koyu modla, ekran okuyucuyla ve sağdan sola yönle zaten çalışır. Aynı bileşenin elle yapılmış kopyası bunların hepsini yeniden kurmak zorundadır ve genellikle kurmaz. Gerçekten özel bir bileşene ihtiyacınız varsa yalnızca mutlu duruma değil, bütün bu durumlara bütçe ayırın.

Ve satış sayfalarında pek görmediğiniz bir konum: bütçeniz darsa önce kuralları düzgün uygulayın, görsel ayrışmayı sonra hedefleyin. Arayüzü sıradan ama doğru olan bir uygulama, ayrıksı ama kafa karıştırıcı olandan daha çok kullanılır.

Farsça bir ekran telefonda nerede bozulur?

Sağdan sola tek satır CSS ile bitmez ve çoğu Farsça uygulama tam burada aksar. Apple ın İnsan Arayüzü Kılavuzu sağdan sola için ayrı bir sayfa taşır ve kurallarının birkaçı pratikte tam da bizim tosladığımız yerlerdir.

Önce sayılar. Apple, belirli bir sayının içindeki rakamların sırasının asla ters çevrilmediğini söyler: bir telefon numarası, bir kart numarası ve 541 sayısı her yönde aynı sırayı korur. Ama ilerleme ya da sayım gösteren rakamların sırası ters çevrilmelidir, çünkü denetimin kendisi aynalanmıştır. Bu iki kural birbirine benzer ve pratikte birbirinin tersidir.

İkincisi paragraf yönü. Apple ın kuralı, üç satır ve üzeri bir bloğun sayfa yönüne değil kendi diline hizalanmasıdır; böylece Farsça bir ekrandaki İngilizce paragraf sola hizalı kalır, aksi hâlde her satırın başı kaybolur. Bir ve iki satırlık metin ise sayfa yönüyle gider.

Üçüncüsü simgeler. Geri oku Farsçada sağı göstermelidir, ama saat, logo ve onay işareti asla aynalanmaz; gerçekten fiziksel bir yönü gösteren bir simge de öyle. Apple başka yerde pek yazılmayan bir noktaya bile değinir: Arapça ve İbranice metin, büyük harfi olmadığı için büyük harfli Latin metnin yanında fazla küçük görünür ve yaklaşık iki punto büyütmek dengeyi geri getirir. Aynısı Farsça için de geçerlidir.

Dördüncüsü, masaüstünde görünmeyip telefonda hemen ortaya çıkan bir şey: sayısal klavye. Girdiniz doğrulamadan önce Farsça rakamları Latin rakamlara çevirmiyorsa, numarasını Farsça klavyeyle yazan kullanıcı geçersiz numara mesajı alır ve nedenini bilemez. Bu bir kullanıcı hatası değil, tasarım hatasıdır.

İlk taslakta kimsenin çizmediği durumlar

Veri çeken her ekranın en az beş durumu vardır ve ilk tasarım genellikle bunlardan birini gösterir. Henüz hiçbir şey yokken boş durum. Gelirken yükleniyor durumu. Gelmediğinde hata durumu. Mobilde sık, masaüstünde seyrek olan çevrimdışı durumu. Ve Figma da çizilen resim olan dolu durum.

Geri bildirim tam da budur. Bir dokunuştan sonra mobil kullanıcı, sunucu iki saniyede yanıt verse bile, dokunuşun kaydedildiğine dair bir işareti saniyenin küçük bir kesrinde görmelidir. O işaret olmadan aynı düğmeye tekrar basılır ve elinizde mükerrer bir sipariş olur. Çevrimdışı, telefonda uç bir durum değil gerçek bir durumdur: asansör, metro, otopark.

Tutarlılık da burada sayılabilir. Hata göstermek için tüm uygulamada tek bir kalıp seçin ve her yerde onu kullanın. Bir ekran hatayı formun üstünde, bir başkası alanın altında, üçüncüsü yüzen bir mesajın içinde gösterirse kullanıcı hatayı her seferinde aramak zorunda kalır.

Ve aslında ilk yapılacak iş olan son madde: uygulamayı kendi telefonunuzda, sistem yazı boyutu büyütülmüş hâlde ve güneş ışığında açın. Bu derste sayılan sorunların çoğu, herhangi bir resmî incelemeden çok önce, o bir dakikada ortaya çıkar.