Android uygulaması artık yalnız dikey telefon ekranında çalışmıyor. Tablet, foldable, ChromeOS, masaüstü pencereleme ve split-screen aynı uygulamaya çok farklı kullanılabilir alanlar sunuyor. Adaptive tasarım her cihaz için ayrı sabit mockup üretmek yerine pencerenin mevcut genişlik ve yüksekliğine göre düzen kararı verir. Android Developers belgeleri bu yaklaşım için window size class yapısını ve canonical layout örneklerini kullanır.
Cihaz adından pencere boyutuna geçmek
“Tablet ise iki kolon göster” kuralı kolay görünür; fakat tablet bölünmüş ekranda dar bir pencere kullanabilir, foldable açıldığında genişleyebilir ve masaüstü penceresi çalışma sırasında yeniden boyutlanabilir. Window size class kullanılabilir uygulama alanını compact, medium, expanded, large ve extra large gibi sınıflara ayırır. Genişlik ve yükseklik ayrı değerlendirilir; dikey kaydırmanın yaygın olması nedeniyle ana layout kararında genişlik çoğu zaman daha belirleyicidir.
Bu sınıf uygulama açıkken değişebilir. Yön değiştirme, pencereyi sürükleme veya cihazı katlama sırasında UI güncellenmelidir. Değeri başlangıçta bir kez okuyup kalıcı cihaz etiketi gibi saklamak adaptive davranışı bozar.
Önce içerik önceliğini belirlemek
Geniş ekran daha fazla şeyi büyütmek için değil, görevi daha anlaşılır düzenlemek için fırsattır. Bir proje listesinde compact düzende tek kolon, medium düzende daha geniş kartlar, expanded düzende liste ve detay yan yana kullanılabilir. Ancak ikincil panel yalnız alan var diye eklenmemelidir; kullanıcının kararını gerçekten hızlandırmalıdır.
İçerik önceliği breakpointe göre değişmemelidir. Ana başlık, seçili filtre ve birincil aksiyon her düzende bulunur; konumları ve yoğunluğu uyarlanır. Geniş ekranda satır uzunluğunu kontrolsüz bırakmak okunabilirliği düşürür. İçerik için maksimum genişlik ve anlamlı kolonlar tanımlanmalıdır.
Canonical layout desenlerini kullanmak
Android adaptive rehberleri list-detail, supporting pane ve feed gibi yaygın düzenleri tanımlar. Liste-detay yapısı e-posta, mesaj veya portfolio gibi seçim ve içeriğin birlikte görülebildiği akışlarda uygundur. Supporting pane, ana görevi tamamlayan filtre veya yardımcı bilgi için kullanılabilir. Feed ise farklı kart yoğunluklarını geniş alanda düzenler.
Bu desenler görsel şablon değil davranış başlangıcıdır. Geri navigasyonu, seçili öğeyi ve panel kapanışını ürün akışına göre çözmek gerekir. Dar ekrana dönüldüğünde açık detay kaybolmamalı; kullanıcı geri tuşuyla beklediği yere dönmelidir.
Foldable ve hinge alanını hesaba katmak
Katlanabilir cihazda iki panel arasındaki fiziksel kat yeri içerik için uygun olmayabilir. Layout yalnız toplam genişliği görüp kritik butonu hinge üzerine yerleştirmemelidir. Window layout bilgisi ayrıştırıcı alanı tanımaya yardımcı olur. İki bölmeli düzen kullanılacaksa ana içerikler fiziksel sınırın iki yanında anlamlı biçimde konumlanır.
Posture değiştiğinde video, form veya düzenlenmekte olan içerik sıfırlanmamalıdır. State layout'tan ayrılırsa görünüm değişirken görev devam eder. Tasarım prototipinde fold-unfold geçişi ve seçili öğenin korunması ayrıca gösterilmelidir.
Grid ve spacing'i breakpoint tablosuna hapsetmemek
Her genişlik için farklı ve ezberlenmesi zor değer listesi oluşturmak yerine spacing tokenları ve birkaç layout kuralı kullanılabilir. Dış margin, kolon sayısı ve içerik maksimum genişliği window class ile değişir; bileşen içi boşluk mümkün olduğunca tutarlı kalır. Kartı genişletirken görsel oranı ve metin satır uzunluğu kontrol edilmelidir.
Minimum genişlik yaklaşımı, içeriğin ne zaman sıkıştığını gözlemlemeye dayanır. Yeni breakpoint yalnız cihaz kataloğunda popüler bir ölçü olduğu için değil, düzen gerçekten bozulduğu için eklenmelidir. Böylece gelecekteki ekranlar için sistem daha dayanıklı olur.
Navigasyon uyarlaması
Compact ekranda bottom navigation uygunken geniş ekranda navigation rail veya drawer daha verimli olabilir. Bu değişiklik bilgi mimarisini değiştirmemelidir; aynı ana bölümler farklı kontrol içinde görünür. Seçili durum, ikon etiketi ve klavye odağı her varyasyonda korunmalıdır.
Büyük ekranda hover ve klavye kullanımı ihtimali artar. Yalnız dokunma geri bildirimi tasarlamak yeterli değildir. Focus state, pointer hedefi, klavye kısayolu ve ekran okuyucu etiketi bileşenin platformlar arası kullanımını güçlendirir.
Test stratejisi
Android belgeleri window size class ile yüksek seviye layout kararı vermeyi önerir. Test matrisi bu sınıfların sınırları çevresinde kurulmalıdır: sınırdan hemen küçük ve büyük genişlikler, dikey-yatay yön, split-screen ve yeniden boyutlandırma. En uzun yerelleştirilmiş metin ve büyük font ayarıyla kolonların kırılıp kırılmadığı incelenir.
Ekran görüntüsü testi görsel sapmaları yakalayabilir; etkileşim testi panel geçişi, back davranışı ve state korunmasını doğrular. Gerçek tablet ve foldable denemesi ergonomi, hinge ve dokunma mesafesini simülatörden daha iyi gösterir.
Tasarım tesliminde davranışı anlatmak
Figma frame'lerinin yanına hangi window class'ta hangi panelin açıldığı, içeriğin maksimum genişliği, navigasyon dönüşümü ve state davranışı yazılmalıdır. “Tablet ekranı” etiketi tek başına geliştiriciye yeterli kural vermez. Genişlik değişirken ara durumların nasıl davrandığı bir prototip veya kısa karar tablosuyla gösterilebilir.
İyi adaptive ürün her ekrana daha fazla içerik sıkıştırmaz. Kullanılabilir alanı göreve dönüştürür, aynı bilgi mimarisini korur ve pencere değişirken kullanıcının bağlamını kaybetmez. Böylece telefon tasarımının büyütülmüş hali değil, farklı alanlarda aynı ürüne ait hisseden bir sistem oluşur.
Telefon, tablet ve katlanabilir ekranları tek bir yerleşim mantığıyla ele almak, ekran başına ayrı tasarım üretmekten hem hızlı hem sürdürülebilir. Mobil uygulama UI/UX tasarımı hizmetimde akışları bu esneklikle kuruyorum.
