Sesli Arayüz mü Ekran mı: Modaliteyi Göreve Göre Seçmek

Voice first cihazlar tartışması çoğunlukla yanlış soruyla başlıyor: ses mi kazanacak, ekran mı? Kazanan yok, çünkü ikisi farklı kaynakları harcıyor. Ses zamanı kullanır, ekran alanı kullanır ve bir arayüzde hangisinin öne geçeceğini kullanıcının o an yaptığı iş belirler.

Ses seri, ekran paralel

Sesli çıktı doğrusaldır. Kullanıcı bilgiyi sizin belirlediğiniz sırayla, sizin belirlediğiniz hızda alır, geri dönmek isterse baştan dinler. Ekran bunun tersidir: on öğe aynı anda durur, göz istediği yere atlar, karşılaştırma bedavaya gelir.

Bunun pratik sonucu ölçülebilir. Ortalama konuşma hızı dakikada 150 kelime civarında; beş kelimelik bir seçenek yaklaşık iki saniye sürer. Sekiz seçeneklik bir listeyi okutmak, aralardaki duraklamalarla birlikte yirmi saniyeye yaklaşır ve kullanıcı sona geldiğinde baştakileri zaten unutmuştur, çünkü işleyen bellekte aynı anda tutulabilen öğe sayısı bunun çok altındadır. Aynı sekiz seçenek ekranda bir saniyede taranır. Sesli menüde seçenek sayısı üçü geçtiğinde tasarım hata veriyor demektir; liste uzuyorsa listeyi kısaltmak değil, modaliteyi değiştirmek gerekir.

Sesli çıktıyı tek sonuçlu ve onay niteliğindeki işlerde ekrandan daha güvenilir bulurum: alarm kuruldu, ışık kapandı, yarın yağmurlu. Karşılaştırma, gözden geçirme ve seçim söz konusu olduğunda ekran tartışmasız önde, arada gri bölge de yok.

Görev şekli modaliteyi belirler

Ses girdisi ile ses çıktısını ayrı düşünmek işi kolaylaştırıyor. Girdi tarafında ses neredeyse her zaman kazanır: bir cümleyle söylenen şeyi menüde bulmak beş dokunuş sürer, eller doluyken hiç sürmez. Çıktı tarafında kazanan görevle değişir.

• Tek değerli sorgular ve komutlar: sesli çıktı yeterli, ekran fazlalık.
• Listeleme, karşılaştırma, uzun metin: ekran zorunlu, ses yalnızca yönlendirir.
• Adım adım ilerleyen işler (tarif, kurulum, navigasyon): ses sırayı söyler, ekran mevcut adımı ve kalan adımları gösterir.

Üçüncü madde hibrit cihazların asıl varlık sebebi. Tarifi sesle sorup malzemeleri ekranda görmek işe yarıyor, çünkü kullanıcı ellerini kullanırken bilgiye göz ucuyla dönebiliyor. Bu senaryo dışında ekran eklemek çoğu zaman ürünü pahalılaştırmaktan başka bir şey yapmıyor.

İki yüzey, tek durum

Tasarım tarafında masumca duran bir cümle var: her iki modalite senkron çalışsın. Uygulamada bu, aynı durumu iki ayrı sunuma çeviren bir sistem kurmak demek ve hataların büyük kısmı tam burada çıkıyor. Kullanıcı ekrandan bir seçim yaparken aynı anda konuşursa hangisi kazanacak? Sesli komut yarıda kesilirse ekranda görünen ara durum ne olacak?

Bunu çözmenin tek makul yolu, durumu tek bir yerde tutup ses ve ekranı o durumun iki görünümü olarak yazmak. İki yüzeyin kendi durumunu ayrı ayrı tutması, kısa vadede daha hızlı ilerletir ve ardından hiçbir zaman tam kapanmayan bir senkron hatası kuyruğu bırakır. Tasarım dosyasında iki akış çizmek bedavadır, kodda iki durum makinesini tutarlı tutmak değildir; akışları çizerken hangi kararın ikinci bir durum yarattığını bilerek çizmek işi baştan sadeleştirir.

Erişilebilirlik kendiliğinden gelmiyor

Sesli arayüzler genellikle erişilebilirlik kazancı diye sunuluyor. Bu kısmen doğru: motor becerileri kısıtlı kullanıcılar ve görme engelliler için sesli komut ciddi bir açılım. Ama aynı tasarım işitme engelli kullanıcı için doğrudan bir kayıp, kekemelik ya da dizartri gibi konuşma farklılıkları olan kullanıcı için tanıma başarısı çok düşük, aksanlı konuşanlar için hâlâ eşitsiz.

Dolayısıyla sesi erişilebilirlik çözümü olarak değil, bir alternatif kanal olarak konumlandırın. Ölçü basit: sesle yapılabilen her iş dokunmayla da yapılabiliyorsa erişilebilirlik artmıştır, yalnızca sesle yapılabilen tek bir iş varsa azalmıştır. Gürültülü ortam da aynı testi geçer, çünkü kütüphanede ya da açık ofiste kimse cihazıyla konuşmuyor.