Piyasaya mı çıkacaksınız | 1. Raporlama

Spread the love

Aşağıdaki satırların içerdiklerini, farklı dil ve farklı anlayış seviyelerine göre anlatan birçok yerde okuyabilirsiniz. Bunu biliyoruz zaten. Asıl çözümün erişilebilirlik rehberleri olmadığının da farkındayım. Bu makalenin asıl hazırlanma sebebi, kullanıcı deneyimi için bir hızlı bakış notları oluşturmaktır. Bunu da söylemeden geçmeyelim, yazılımcılık eğitimlerinden biri kullanıcı deneyimi ve kullanıcı deneyimi için kapsayıcı tasarımın önemini vurgulayan bir dal olmadığı sürece, dünya üzerinde tüm konuşulan dillerde bu kılavuzu bulmaya çalışmak gerekecek.
Bu kılavuzlar çoğu zaman bizzat sağlayıcıların yanı sıra kullanıcı deneyimine gönüllü ya da profesyonelce bulaşanlar tarafından hazırlanır ve değişiklik, revizyon, güncelleme eylemlerinden birine, herhangi bir zamanda maruz kalabilir. Bu yüzden buna benzer notları kimden okuduysanız onu takip etmenizi ve gerekirse birebir destek almanızı tavsiye ederiz.

Ek olarak, daha yazarken makalenin sınırlarını çizemediğim için sizden tam olarak ara ara buna tekrar dönebilme imkanını yaratmanızı rica edeceğim. Tek solukta bitirecek kadar sürükleyici yazamayabilirim. Yanı sıra içecek bir şey olursa sanki biraz daha yardımcı olur.
İşte En İyi Deneyim takımının sizler için hazırladığı başlıca notlar.

Raporlama

 

Baştaki rapor kelimesinin tınısı, çoğu zaman dosya kağıtlarının kokusu ile boğulmuş, kahve, bilgisayar ve bolca dosyanın işgal ettiği masa, tercihen ziyaretçinin yada çalışanın gözüne sokulan yerleşimlerdeki kitaplık ve afişler bulunan odalarda çalışan kişileri hatırlatabilir.

Aslında rapor profesyonel anlamda böylesine titizlik ve odaklanmayı gerektiren bir iştir. Raporu hazırlama, okunma biçimlerine ve hangi ortamlarda sunulacaklarına karar verebilirsiniz; bununla birlikte raporu okurken ve yazarken özellikle dikkat edilmesi gereken bazı noktalar vardır.
Raporlar sıklıkla bilgi ve geribildirim listesinden oluşur. Bu bilgi satırları çoğu zaman okunmaz bile; ama bu satırlardan çok fazla şey öğrenenlerin olduğunu biliyoruz.

Bir şey daha! Raporların geribildirim maddeleri, kesinlikle “Sorun ne?” ve “nasıl kaynaklanıyor?” sorularına yanıt verebilmeli. Örnek: “odak takılıyor” ve “aşağıdaki Tablara odaklanıldığında imleç yukarıya taşınamıyor” gibi sonuçları, maddeyi okuyan kişi kim olursa olsun çıkarabilmeli. Çoğu zaman geliştiricilere hitap etmezsiniz veya karşınızdaki Edebî lakırdılar ile arası iyi olmayan bir geliştirici olabilir. Bu yüzden, anahtar olarak kullanılabilecek doğru kelimeler seçilmeli ve cümle vurgulanmalı. VoiceOver’in ekranda kaybolmasını engellemek amacı ile bir odak nesnesi üretmek haklı bir istektir. Bu isteğin ne kadar haklı olduğuna karar verebilmek için, senaryonun hem geliştirici hem de bildirimci tarafından bilinmesi gerekir.
Devam ettiğimizde, belki de en başında söylememiz gereken şeyi aslında unutmamak gerekiyor. Buraya yazdığım için kendisinden özür diliyorum ama, bu maddenin bu makaledeki yeri tam da bu. Bir erişilebilirlik raporlayıcısının görevi, asla tasarıma müdahale etmek değildir. Buradan geliştiricilerin her tasarımın doğru olduğunu çıkarmaması gerekiyor. Bazı müdahaleler elbette gerekir ama, iyi yapılmış herhangi bir şeyin her yerde güzel olacağını unutmazsanız bazı şeyler daha kolay olabilir. Ek olarak, erişilebilirlik ve erişim kolaylığının da tam bu maddenin içinde ayrıştırılması gerektiğini düşünüyorum. Erişim kolaylığı vadedilen işi daha kolay yapmayı öngörürken, erişilebilirlik bu işi herhangi bir biçimde mevcut imkanlar ile yapabilmeyi öngörür.
Kolay gelsin! Neden bahsediyoruz acaba?
Bir program kurarken “ileri” düğmesinin etiketi olmadığı için kuramamak, bir erişilebilirlik sorunu; “ileri” düğmesinin ekranın sağ alt tarafı yerine sol üstüne konulması ise erişim kolaylığı kapsamında değerlendirilmeli.
Yorumlardan gerekli dövme işlemlerini yapabilirsiniz, ama yorumların kontrol edilmeden yayınlanmadığını unutmayın.
Anahtar kelimelere, soru ve sorgulara dikkat ettik; erişim kolaylığını ve erişilebilirliği karıştırmadan ve tasarıma müdahale etmeden raporlamayı öğrendik. Daha ne kaldı?
Buradan sonra, daha uygulamaya yönelik ve teste yönelik notlara geçelim.

 

Test ve iletişim ortamında dikkat edilmesi gerekenler

 

Test süreçleri çoğu zaman paslaşarak ilerler. Doğru sonuçlar elde edilebilmesi için gereken en önemli noktalar, her sorunu çözüyor.

    • Önce şuna karar verelim, bir test ortamında tüm sorunları çözmek mümkün olmaz. Uygulama iki taraf için de tatmin edici hale geldiğinde yayınlanmalı ve artık kullanıcıdan geri dönüş istenmeli.

Uzun test süreçleri fonksiyonel katılaşmaya sebep olur ve önemli noktalar, iyi fonksiyonların büyüsünde göz ardı edilebilir. Bunu çokça yaşadık.

    • Hiçbir şey bir pano kadar önenli değildir.

Sanal yada fiziksel pano kullanın. Bu pano hem geliştiricinin, hem de geribildirim ekibinin erişiminde olmalı. Geribildirimler burada guruplandırılmalı, sıralanmalı ve etiketlenmeli. Böylece yol haritası ve kilometre taşları izlenebilmiş olur. Bunun için yapılacaklar listesi ve bunu topluca yapmaya izin veren uygulamaları deniyoruz.

    • Ne yeni bilgisini mutlaka verin.

Test ekibine test derlemesi gönderilirken, tüm süreci baştan test etmeyi çoğu durumda, zaman kaybı olarak görebilirsiniz. Siz hizmeti tasarlarken değişiklik yaptığınız noktaya odaklandığınız için bu kolay olabilir; ama adımların bir bütün olarak incelenmesi gerekmediği sürece “ne yeni” bilgisini sadece nerelerde yenilik yapıldığına yönelik verin.

    • Test ekibiyle, ulaşılmak istenen sonucun ve bu sonuçlara ulaşmak için hangi adımların atılması gerektiği mutlaka paylaşılmalı.
    • Test ekipleri, zaman zaman mutlaka adımlarının bütünlüğünü test etmeli.

Bir boşluğa düşülüyorsa o boşluk tam olarak tanımlanmalı. İnsan makine etkileşiminde en çok kullanıcının kaybedildiği nokta, onun boşluğa düştüğü noktalardır. Bunu sadece bir uyarı mesajı veya “loading” sayfası çözer. Fonksiyon olarak aynı olan uygulamalar arasından daha çok konuşabildiği uygulamayı tercih etmek kullanıcının en doğal hakkıdır. Bu durumda test ekibi temsilcisi ile veya test ekibindeki her bir birey ile görüşmeler gerçekleştirmeyi unutmayın.

    • Sorunlarda kesinlikle sorunu net bir şekilde tanımlayan anahtar kelimeleri seçin ve doğru kullanın.

Geliştiriciyi, yanlışlıkla yanlış anahtar kelimeler ile olması gerekenden uzağa yönlendirebilirsiniz. Çoğu zaman geliştirici sizin söyledikleriniz üzerinden araştırma yapar. Önemli olan çözümü üretmek değil, önermek ya da sorunu tanımlamaktır. Asla yapmamanız gereken ise, geliştiriciyi zorlamamaktır. Doğru anahtar kelimeler verildikten sonra işi geliştiricinin hayal gücüne bırakın.

 

Arayüz notları

 

Uygulamaların neresine neyin yapılacağı, kervan dizildikçe karar verilebilir. Buradaki temel notlar uygulamanın test edilebilir bile olabilmesi için kesinlikle unutulmaması gerekenlerdir. Lütfen bunları temel alışkanlığınız haline getirin. Hiç beklemediğiniz bir kullanıcı kitlesinden olmadık tepkiler alabilirsiniz; ya da sizin öngörmediğiniz senaryolar olabilir. Belki de arayüzünü geliştirdiğiniz hizmet kapsam değiştirebilir. Bir Button tanımladığınızda hemen bir tag veya AccessibilityName niteliğini girin. Bunu alışkanlık haline getirin ve makinenizi herkes yürütsün. Geliştiriciye ilham verenin kullanıcılar olduğu, bilgi çağının evrim geçirdiği şu dönemlerde ortaya çıkan bir gerçek.
Şunlara bakın:

  1. Arayüzde kullanılan veya SDK tarafından tanımlanan tüm nesneler, dinlenildiğinde, okunduğunda ve görüldüğünde anlaşılmalı. Şu an dokunamadığımıza göre sanal algıya hizmet eden her şey düşünülmeli.
  2. Arayüze tanımlanan tüm menüler ve içerikler etiketlenmeli, bilgilendirici metin veya video tarzı nesnelerin başlangıç noktaları, başlık veya referans noktası gibi belirteçlerle işaretlenmeli. Hatta birden fazla içerik türü söz konusu ise, bunun sınırları kesinlikle çizilmeli. İçeriği yorumlayarak kullanıcısına etkileşim imkanı veren yardımcı teknoloji ürünleri (ekran okuyucu, büyüteç gibi) bu içeriklerin nerede başlayıp nerede bittiği bilgisine ihtiyaç duyarlar.
  3. Alt kısmında tabları olan, en üstte başlığı ve ortasında buton ve metinler olan bir arayüz düşünün. Bu arayüzü hemen tasarlayabilirsiniz de.
    Bu arayüzlerde ekran okuyucular çoğu zaman doğal dolaşım mekanikleri ile düzgünce dolaşabilirler. Bazen sorunlar kullanıcıyı rahat bırakmaz ve yardımcı teknoloji, işkence tekniğine dönebilir. Bu noktada Yardımcı yazılımın işini kolaylaştırmak için imlecin var sayılan olarak odaklanacağı veya her şey bittiğinde döneceği nokta tanımlamalısınız. Bu sayfa başlığı veya içerikteki herhangi bir kontrol olabilir. Ekran okuyucunun imlecini taşımayı araştırıp, nesne niteliğine bunu tanımladığınızda, ekran okuyucu kaybolduğunda o nesneyi bulacaktır.
  4. Asla kim görecek demeyin. İçeriğe dayalı olarak çalışan her türlü yazılım vardır. Ekran okuyucu kullanan kullanıcılar veya arama motorları. Bebek yazdığımda arama motorunun bir bebek resmi bulması yada ekran okuyucunun bir bebek fotoğrafına odaklandığında bunu kullanıcısına bildirmesi için alternatif açıklama kullanmak zorunludur. Dükkan belli olsun diye logonuzu tasarladıktan sonra o logoyu bir altEtiket ile taçlandırın ki, herkes bilsin.
  5. Etiketlerin nasıl olacağı aslında tamamen hayal gücüne bağlıdır. Çoğu zaman okunduğunda anlaşılan metinler dinlenildiğinde de anlaşılır, ama Bir işi gerçekleştirmek için o açıklamanın tamamına ihtiyaç duyan kullanıcıları unutmadan, yanınızdakine etiketinizi okuyun ve tartışın.
    Yaşasın dil bilgisi ve anlatım dersleri! Betimlemek veya tanımlamak yöntemleri de etiketleri hazırlarken kullanılması gereken metotlardır. Etkileşim esnasında, çoğu zaman betimlemeye ihtiyaç duyulmaz. Onun ne olduğunun tanımlanması daha önemlidir. Örneğim “Türkiye bayrağı”. İçerik tüketilirken betimlemeye daha çok ihtiyaç vardır. Bir hikaye anlatırken Türkiye Bayrağını grafik açıklamasında tanımlayın. Hikayenin anlatım gücünde bayrağın dalgalanıyor yada nasıl göründüğü çok daha önemlidir.
  6. Arayüz mesajları zannettiğinizden daha önemli olabilir. Uyarı mesajının yönlendirici veya açıklayıcı olması örneklendirme alternatifimiz. Sınavda soruyu okumadan seçenekler üzerinden farklı olanı bulduğumuz çoğu zaman yaptığımız bir şey. Bu bir coğrafya sorusunu çözerken pek önemsenmez, banka havalesinde TL yada Euro birimini seçmek durumu geliştiğinde cüzdanın boşalmaması için önemlidir. Bu kadar basit işlemlerden tutunda, Bir video’yu nasıl açılacağına dair karışık mesajlara kadar genişletin. Çoğu zaman, açık olmayan arayüz mesajları yüzünden kullanıcıyı en sevdiğiniz fonksiyonunuzu pas geçmeye itebilirsiniz. Dinleyen veya alttaki seçeneklerin tamamını göremeyen biri, bir seçim yapmaya zorlandığında yeterince uyarılmadıysa ilk seçenekte karar verir.
  7. Uygulamanızın en sevdiğiniz fonksiyonunun, kırık ekranın tam çatlağına gelmesi asla öngöremeyeceğiniz bir senaryo; ama görme kaybı olan herhangi birinin farklı renk filtreleri uygulayarak kullandığı cihazında nasıl göründüğünü öngörmek çok daha kolaydır. Birçok geliştirici arayüzü bunu test etmenize izin verir. Vermiyorsa da cihazdaki erişilebilirlik seçenekleri her zaman daha kolayca işleri yürütmeniz için vardır.
  8. Menü gibi görünen bir içerik türü tasarlamak yerine, bilinen bir menü kullanmak daha doğru olanıdır. Bu iş çoğu zaman işleri kısalttığı için seçilir. Bunun zannedildiğinden daha büyük bir etkisi ise, büyütme ve ekran okuyucu yazılımların bu içerikleri tanıma ihtimalleri daha yüksek olduğundan, ona göre davranış gösterebilmesidir. İçerik 2 3 x büyütüldüğünde kenar çubuğu içerikleri HamburgerMenu içine konulabiliyorsa, o arayüz nesnesinin tanınmasının getirdiği bir artıdır.
  9. Grafiksel olarak etiketlediğiniz, Türkçe bir uygulamadaki ayarlar düğmesinin “İconSettings” olarak dinlenmesini lütfen engelleyin. Kaynak kodunda var olan etiketleri kesinlikle güncelleyin.
  10. Aslında her şey bir tarafa, Yardım belgelerini açın veya ekran okuyucuyu açıp uygulamanızın farklı kontrollerinin üzerine, doğrudan dokunarak veya tek parmağınızla sağa ve sola doğru yapılacak kısa yatay kaydırmalar ile odaklanın. O zaman işler daha kolay olur.

Son not

 

Buraya kadar birçok şey yazdık. Yukarıda okuduğunuz maddeler en azından bahçeye girilebilmesi içindi. Bahçenin daha güzel görünebilmesi için mutlaka bir destek almanız tavsiye edilir. Burada zamanla ekleyip çıkartma angaryasını göze alarak ekleyebileceğimiz farklı kontrollerin farklı işletim sistemlerinde nasıl tasarlanması gerektiğine dair maddelerde olabilirdi. Bu maddeler aslında istenildiğinde eklenebilir. Biz bunu yapmak yerine hem kısaca bilgilendirmek hem de yönlendirmek istedik. Bazen geliştirici kılavuzlarında bu maddeleri bile bulmak zor oluyor. Bunun maalesef ki farkındayız. En basitinden halen bu maddeler kitapçıkların ve ansiklopedi niteliğindeki yığınların en son sayfalarında oluyor ve henüz, kullanıcı deneyiminde erişilebilirlik öne çıkan standart bir kontrol noktası değil.

İleride daha uygulamaya yönelik maddeleri içine alan yazılar yayınlayacağız. Tabi bu birazda talebe bağlı. En İyi deneyim takımı Geliştiriciler için profesyonel kullanıcı deneyimi danışmanlığı hizmeti de sunar.

Yorumlarınıza açık olduğumuzu unutmayın.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir