7 İnç Tablette Arayüz: İki Kırılma Noktası Arasında Kalan Cihaz

7 inç tablet, arayüz açısından tuhaf bir yerde durur: portre modda telefon genişliğinde, yatayda küçük bir dizüstü genişliğinde. Bu yüzden tek bir “mobil sürüm” kararı bu cihazda çoğu zaman yanlış tarafa düşer. Asıl sorun ekranın küçüklüğü değil, aynı cihazın iki ayrı kırılma noktasına birden düşmesi ve genelde bunlardan yalnızca birinin test edilmiş olması.

Portre 600 piksel, yatay 960 piksel

Yaygın bir 7 inç tablette fiziksel çözünürlük 1200x1920, piksel yoğunluğu 2. Tarayıcının gördüğü CSS genişliği portrede 600, yatayda 960 piksel. Bootstrap’ın varsayılan eşiklerinde 600 “sm” aralığına, 960 ise “md” aralığına düşer. Kullanıcı cihazı çevirdiğinde sayfa biraz genişlemez; baştan farklı bir düzene geçer.

Peki bu kendi başına hata mı? Değil. Hata, iki düzenden birinin hiç açılmamış olması. Yatayda yatay bir çubuğa açılan menü portrede hamburgerin altına giriyorsa, kullanıcı aynı işlevi iki ayrı yerde aramayı öğrenmek zorunda kalır. Cihazı çevirmek bedava bir hareket, okurken sık yapılıyor. Bu yüzden 7 inçi test ederken tek bir ekran görüntüsü yeterli sayılmaz, iki yönü de açıp menüdeki ve gezinmedeki öğelerin yer değiştirip değiştirmediğine bakmak gerekir.

Kullanıcı ajanına bakmak neyi çözmez

Bu konuda dolaşan klasik tavsiye şu: cihazı user agent’tan tanı, 7 inçe mobil sürümü sun. Bu öneri, responsive tasarım önerisiyle aynı sayfada duramaz, çünkü ikisi birbirini iptal eder. Duyarlı düzen kararı zaten tarayıcıda, genişliğe bakarak verir. Üstüne sunucu tarafında cihaz tanıma koyduğunuzda iki karar mekanizması çakışır, araya önbellek girdiğinde de kullanıcıya hangi sürümün gittiği tahmin işine döner.

Sorulması gereken soru “bu cihaz tablet mi” değil, “bu girdi kaba mı”. CSS bunu doğrudan veriyor: @media (pointer: coarse) parmakla kullanılan her şeyi yakalar, (hover: none) ise imleç üstü durumlarına güvenilemeyeceğini söyler. İkisi birlikte, cihaz listesi bakımı gerektirmeden hem 7 inç tableti hem de dokunmatik dizüstünü kapsar (o cihaz listelerini güncel tutmanın maliyetini hafife alan çok gördüm).

“Kalın parmak” için sayı vermek

Butonları büyüt demek tek başına tavsiye sayılmaz, çünkü ne kadar sorusunu açıkta bırakır. Eşikler yazılı: WCAG 2.2’nin 2.5.8 ölçütü AA seviyesinde en az 24x24 CSS pikseli ister, AAA seviyesindeki 2.5.5 ise 44x44’ü. Apple’ın arayüz kılavuzu 44 punto, Google’ın Material tasarımı 48 dp der. 24’ü taban, 44 ile 48 arasını hedef kabul etmek pratikte işi görüyor.

Boyut kadar aralık da sayar. Yan yana duran iki 44 piksellik buton arasında boşluk yoksa, sınıra gelen dokunuş hangisine gittiğini kullanıcıya hissettirmez; hedef yeterince büyüktür ama hata oranı düşmez. WCAG’in ölçütü bu yüzden hedefler arası boşluğu da geçerli bir alternatif olarak sayıyor. Dar ekranda sıkışan asıl yer form düğmeleri ve satır içi bağlantılar, ikisinde de boşluğu büyütmek boyutu büyütmekten daha az yer harcar.

Okumada kaybedilen şey yazı boyutu değil

Dergi ve kitap uygulamalarında 7 inç şikayeti genelde “yazı küçük” diye özetlenir, oysa yazıyı kullanıcı zaten kendi büyütür. Geri kazanılması zor olan konum duygusu: hangi bölümdeyim, ne kadar kaldı, bir önceki sayfaya nasıl dönerim. Tam ekran okuma modu bu üçünü birden gizlediğinde okuyucu, sadece nerede olduğunu görmek için arayüzü geri çağırmak zorunda kalıyor.

Ucuz çözüm, kalıcı bir ilerleme göstergesi ve her zaman aynı noktada duran tek bir geri hedefi. Peki sayfa değil de sürekli kaydırma kullanıyorsanız? O zaman bölüm başlıklarını yapışkan yapmak aynı işi görür: kullanıcının nerede olduğunu anlamak için kaydırmayı durdurup yukarı çıkması gerekmez.