Bilgisayar–İnsan Etkileşimi ve Dokümantasyon Bilmecesi
10 Nixon Lane
Stoneham, MA 02180
"Yazılım paketi 600 dolara satılıyor ve sonra onu nasıl çalıştıracağımı göstermek için 10.000 dolar bir danışmana ödemek zorunda kalıyorum. Oysa 600 dolar için onu anlayabilmem gerekir."
— mutsuz bir kullanıcı
Karmaşıklık
Bilgisayar donanımının karmaşıklığı, bilgisayar programlarının daha da büyük karmaşıklığı ve insan bilgisayar kullanıcılarının ezici karmaşıklığı nedeniyle, bu üçünün arayüzü sorunlarla dolu bir alandır. Program dokümantasyonunun (kullanıcı kılavuzları ve benzerleri) sözde amacı, bu sorunları yönetilebilir bir düzeye indirmektir.
Bazen işe yarar.
İşe yaramadığında, son kullanıcılar üzerindeki etki, programa yaklaşımlarını belirleyen tutumlar üzerindeki etki, yıkıcıdır. Tutumları, umut dolu bir beklentiden hayal kırıklığına, yılgınlığa ve moral bozukluğuna dönüşür. Artık yeni bir bilgisayar programını verimli kullanma hedefleri ile aralarına bir karmaşıklık engeli girmiştir. Şimdi hayal kırıklığına uğramış ve öfkelidirler.
Ve oldukça öngörülebilir biçimde, programın çalışmamasının suçunu kullanıcıların kendileri değil, dokümantasyon üstlenir. Sosyal yükleme kuramı bu konuda oldukça nettir. Bir şeyler ters gittiğinde, insanlar bunun ters gitmesi için sorumluluğu kendilerine yüklemeye pek yatkın değildir. Bunun yerine, içinde bulundukları durumu tarar ve suçu yükleyebilecekleri bir şey bulmaya çalışırlar. Program ve onun dokümantasyonu, öfkeli kullanıcının içinde bulunduğu durumu oluşturur ve hedef haline gelenler de bunlar olur.
Bir Programın Dokümantasyonu
Bu, dokümantasyonun aslında suçsuz, insan savunma mekanizmalarının masum bir kurbanı olduğunu ima etmek değildir.
Aksine, ABD Temsilciler Meclisi House Information Systems biriminden V. Douglas Hines’ın, National Bureau of Standards Software Documentation Workshop’ta söylediği gibi, "tüm yazılım [dokümantasyonu] açıkça yazılmış, kullanımı kolay, doğru ve eksiksiz olmalıdır. Çoğumuzun acı bir şekilde farkında olduğu üzere, bunların büyük bir kısmı böyle değildir."
Son kullanıcı tutumları üzerinde dokümantasyondaki tüm eksiklikler arasında belki de en yıkıcı olanı, bilginin belirsiz, kullanımı zor ya da eksik olması değil, hatalı—yanlış—olmasıdır. Dokümantasyon gerçekten yanlış olduğunda etki felakettir. Kullanıcıların ona duyabileceği her türlü güveni yok eder. Tutumları alaycı bir hale gelir:
"Neden zamanımı bunun içinde debelenerek harcayayım? Başka neler yanlış? Neyin doğru, neyin yanlış olduğunu nasıl bileceğim?"
İlk tepkileri paketi iade edip paralarını geri istemek olur.
Destek Hizmeti
Dokümantasyon ikilemine bir çözüm, satıcı tarafından sağlanan destek hizmetidir.
Eğer bu her zaman dostça, verimli, bilgili ve kolayca erişilebilir olsaydı, destek hizmetleri gerçekten hoş bir çözüm olurdu. Ne yazık ki birçok kullanıcı, bir mali işler başkan yardımcısının şu yakınmasını yaşadı:
"Ofis yöneticim destek hizmetini aradı. ‘Şu anda kimse müsait değil,’ dediler. Bir saat sonra ben kendim tekrar aradım ve aynı mesajı aldım.
Onlara kızdım. ‘Bakın,’ dedim, ‘bu akşam 5:30’a kadar bir bordro çıkarmamız gerekiyor! Bu paketi size geri göndermeyi düşünüyorum.’ Beni hatta beklettiler ve ancak o zaman, onları tehdit ettikten sonra, adam hatta geldi."
Bu hoş bir çözüm değildi.
Dokümantasyon ikilemine ikinci olası çözüm, acemi kullanıcılara programlarını hayata geçirmede yardımcı olacak bir bilgisayar danışmanının kullanılmasıdır. Bilinmeyen alanlarda ilerlerken yalnızca güçlükler boyunca rehberlik etmekle kalmayıp, aynı zamanda bu süreçte sakinleştiren ve rahatlatan sıcak, anlayışlı bir insanın dirsek dibinde oturması kuşkusuz cazip bir çözümdür.
Bilgisayar danışmanlarının dezavantajı maliyetleridir. Bunu, şu ifadeyi kullanan bir kullanıcı ana itiraz olarak dile getirmiştir:
"Yazılım paketi 600 dolara satılıyor ve sonra onu nasıl çalıştıracağımı göstermek için 10.000 dolar bir danışmana ödemek zorunda kalıyorum! Ama 600 dolar için onu anlayabilmem gerekir."
"Yardım" Mesajları
Yardım ekranları, özellikle "pointer fault", "wild interrupt" ve "fatal error" gibi gizemli mesajlar sunan yardım ekranları, son kullanıcı güçlüklerini azaltmada basılı dokümantasyondan pek de iyi değildir. Tanım gereği, bir yardım ekranı yardımcı olmalıdır ve bunu da ancak programcının değil, son kullanıcının diliyle mesajlar ileterek yapabilir.
Bazen durumu daha da kötüleştirmek adına, bu gizemli hata mesajları basılı dokümantasyonda hiçbir yerde bulunmaz ya da dokümantasyonda yer alıyorlarsa, son kullanıcıların bakmayı düşünmeyecekleri yerlerdedir. Örneğin dizinde anlaşılabilir herhangi bir biçimde yer almazlar. Bunun yaptığı şey, kullanıcının öfkeli hayal kırıklığı tutumuna eklemektir.
Programcı Dili ile Kullanıcı Dili
Yazılım programları için dokümantasyon neden yapması gerekeni—bilgilendirmek, yönlendirmek, yol göstermek ve öğretmek—yapmaz? Sorun, dokümantasyonun tarihsel temellerinde yatmaktadır. Tarihsel olarak dokümantasyon, yazılımlarının ne yaptığını, nasıl yaptığını ve neden o şekilde yaptığını anlatan programcılar tarafından diğer programcılar için yazılmıştır.
Güncel son kullanıcı dokümantasyonundaki sorun, programcıların hâlâ ya kendi programlarının dokümantasyonunu yazan kişiler olmaları ya da yazılı dokümantasyonun büyük ölçüde sorumluluğunu taşımalarıdır. Programları geliştirirler, son kullanıcı talimatlarını geliştirirler ve bu talimatların yazılı biçime dönüştürülmesini sağlarlar. Çok fazla şapka takarlar.
Bu arada, mevcut bağlamda kullanılan "dokümantasyon" teriminin, kullanıcı kılavuzlarında bulunan uygulama bilgilerini; klavye şablonlarını, sorun giderme kılavuzlarını, hızlı başvuru kartlarını, öğreticileri ve program kullanıcısına yönelik yardım ekranlarını da kapsadığını belirtelim. Dokümantasyon, programcıların teknik olmayan yazılım kullanıcılarıyla iletişim kurmaya çalıştıkları tüm bu bilgi sınıfıdır.
Öte yandan, programcıların yazılımları hakkında diğer programcılarla iletişim kurma süreci belki de daha doğru biçimde "iz bırakma" olarak adlandırılabilir ve bu izleri takip eden kişi de "iz sürme" yapıyor sayılır.
Programcılar Çok Fazla Biliyor, Kullanıcılar Çok Az
Ancak programcıların çok fazla şapka takması kavramına geri dönersek, dokümantasyonu yazmalarının neden herhangi bir soruna yol açması gerekir? Bunun temel nedeni, programcıların bilgisayarlar ve programlar hakkında basitçe çok fazla şey bilmeleridir. Paketleri için dokümantasyon yazarken, kendi alanına yabancı olan sıradan insanlara bilgi aktarmaya çalışan herkesin düştüğü tuzağa düşerler: dinleyici kitlenin bildiğinden daha fazlasını bildiğini varsayarlar.
Kendileri için küçük, sağduyulu ayrıntılar olan adımları atlarlar; ancak bu adımlar, dinleyici kitlesi için mesajlarını neredeyse işe yaramaz hale getirir. İnce hatalar sızar; kendilerinin neredeyse otomatik olarak düzelteceği hatalar, acemi kullanıcıyı bir açmazda bırakır. Çok yüksek bir düzeyde çalışırlar.
Oysa programcılar, son kullanıcı tarafından tüketilmek üzere dokümantasyon yazacak kişiler olmamalıdır. Tek bir bireyin, tek bir ömür içinde birden fazla alanda kendini eğitip yetiştirmesini beklemek bir şekilde makul değildir. Belki de bu nedenle Jan Yetsingmeier, Sigchi Bulletin’de yazarken şöyle der:
"Dokümantasyon, etkileşimli yazılım tasarımcıları arasında gerekli bir kötülük olarak görülür. İyi dokümantasyonun gerekliliğini kabul etseler de, bunu yapmamayı tercih ederler. Programın daha teknik yönlerine odaklanmayı tercih ederler."
Eğitimleri ve geçmişleri ışığında, bu tamamen anlaşılabilirdir.
Dokümantasyon Bilmecesi
Dolayısıyla dokümantasyon ikilemi iki parçalı bir problemdir.
Birincisi, dokümantasyonu yazan bilgisayar programcıları, nispeten acemi son kullanıcılarla etkili biçimde iletişim kuramayacak kadar kendi alanlarında fazla gelişmiştir.
İkincisi, eğitimlerinin ve geçmişlerinin çok az bir bölümü, son kullanıcı talimatlarının hazırlanması için gereken kapsamlı yazılı iletişime onları hazırlamıştır.
Dokümantasyon probleminin bir parçası programcıların bilgisayarlar alanında aşırı derecede gelişmiş olmalarıysa, çözümün bir parçası da bilgisayarlar alanında gelişmiş olmayan bireylerin yardımını devreye sokmaktır. Bu tür acemi bireyler için ideal bir grup, geliştirilen programı sonunda kullanacak olan kişilerdir.
Bu tür potansiyel kullanıcıların bir örneklemi, yalnızca programcılara kıyasla sahip oldukları acemilik nedeniyle değil, aynı zamanda son ürüne olan ilgileri nedeniyle de dokümantasyon yazımında değerli bir varlık olur. Dokümantasyona başlanmadan önce programcılar ile bu örneklem arasında iki yönlü iletişim kurulmalı ve bu iletişim tasarımın tüm aşamaları boyunca sürdürülmelidir.
Sigchi Bulletin’de yazan Larry Tesler de, geliştirme çabasının biçimlendirici aşamalarında, potansiyel kullanıcılarla iş yerlerinde görüşerek bir "gerçeklik kontrolü" almaktan söz eder. Sisteminin olası son kullanıcıları olan acemileri özellikle arar. Örneğin bir muhasebe paketini sınarken, bu tür programlarla çok az deneyimi olan muhasebe memurlarını bulmaya çalışır.
Bu tür potansiyel kullanıcılara, destekleyici dokümantasyonun ön taslaklarının yanı sıra prototip yazılım sağlanmalı ve bunları işlerinde gerçek çalışmaları gerçekleştirmek için kullanmaları istenmelidir.
Prototip Testi
Bu tür bir prototip testi öngörülmeyen sorunları ortaya çıkardığında, dokümantasyon sorunu giderecek şekilde yeniden yazılabilir ve bu gözden geçirilmiş sürüm daha sonra yeniden test edilebilir. Bu dizi, dokümantasyon yalnızca adında değil, gerçekte de kullanıcı dostu hale gelene kadar gerektiği kadar yinelenmelidir.
Bu, Marilyn Mehlmann’ın When People Use Computers adlı kitabında "uzlaşmacı demokrasi" olarak adlandırdığı şeye yakındır. İlginçtir ki Mehlmann Hanım, uzlaşmacı demokrasiye yönelik bir itirazın şu olduğunu belirtir:
"Kullanıcılarımız yeterince zeki değil—gerekli eğitim düzeyinden yoksunlar."
Bu sınırlama, dokümantasyon yazarken açıkça bir avantajdır. Bu, bu son kullanıcıların bir şekilde eğitimden yoksun olduğu anlamına gelmez; daha ziyade bilgisayar alanında gelişmişlikten yoksun olduklarını ifade eder ki bu, dokümantasyon yazımı için belirgin bir artıdır.
Çünkü programcıların uzmanlığı, sıradan halkla iletişim kurarken onları dezavantajlı duruma soktuğu gibi, potansiyel son kullanıcıların acemiliği de diğer acemi kullanıcılarla iletişim kurarken onların lehine çalışır. Gelişmişlikten yoksun olmaları nedeniyle, en sıradan işlemlerin bile yinelenen bir dille sunulmasını talep ederler.
Bu bilgileri talep ederken, ihtiyaç duydukları bilgileri dikkatle not etmelidirler. Sonunda üzerinde çalıştıkları dokümantasyona dönüşecek olan şey, işte bu notlardır. Bu ürün, gelecekteki en deneyimsiz program kullanıcısının bile, halka klasördeki basılı sayfalardan başka hiçbir yardıma ihtiyaç duymadan programı çalıştırabilmesini sağlayacaktır. Dokümantasyon bu açıklık düzeyine ulaştığında, deneyimsiz son kullanıcılarla iletişim kurulurken olması gereken düzeyde iletişim kuruyor demektir.
Soru ve Cevap Biçimi
İdeal çözüm, bazı sosyal psikologların iletişim alanındaki laboratuvar deneylerini yürütürken kullandıkları bir yöntemi taklit etmek olacaktır. Sözlü etkileşimlere izin verilmez; bunun yerine tüm sözel alışverişler yazılı notlarla yapılır. Bu şekilde, potansiyel son kullanıcıların tüm sorularının ve yazılım tasarımcılarının verdikleri yanıtların eksiksiz ve doğru bir kaydı elde edilmiş olur.
Gelecekteki dokümantasyonun belkemiğini bu yazılı iletişimler oluşturacaktır. Yazılanların hem anlaşılır hem de uygulanabilir olmasını sağlamanın bundan daha iyi bir yolu olabilir mi?
Ve soru-cevap biçiminden daha iyi bir sunum olabilir mi?
Ancak bilgisayar son kullanıcıları—muhasebeciler, yöneticiler ve benzerleri—genellikle, dokümantasyonun hazırlanmasına yardımcı oldukları programcılardan, yayımlanmak üzere yazı yazma konusunda pek de fazla eğitim almış değildir. Bu nedenle, nihai ürün matbaaya gönderilmeden önce dokümantasyonun hazırlanmasında ikinci bir adım olmalıdır.
Bu ikinci adım, paketin gerçekten de yazılması gereken dilde yazıldığından emin olmaktır: bu ülkede, İngilizce.
İngiliz Dili ve Gazetecilik Bölümü Mezunları
Ve belki de, açık ve anlaşılır İngilizce sözdizimi üretme konusunda, yerel bir kolej ya da üniversiteden mezun olmuş ve teknik yazar olarak bir kariyer düşünebilecek İngiliz dili ve gazetecilik bölümü mezunlarından daha yetkin kimse yoktur. Belki de en karmaşık talimatları bile açık, mantıklı, okunabilir ve anlaşılır prosedürlere en kolay şekilde dönüştürebilecek olanlar onlardır.
Daha da önemlisi, İngiliz dili ve gazetecilik mezunları, herhangi bir başvuru materyalinin—yalnızca program dokümantasyonunun değil—onsuz kullanışlılığının büyük bir kısmını yitirdiği dizinleri oluşturma konusunda deneyimlidir. Ne yazık ki, günümüzde yayımlanan dokümantasyonların çoğuna eşlik eden dizinler son derece yetersizdir. Mantıksal organizasyondan yoksundurlar, çapraz referanslardan yoksundurlar ve eksiksiz olmaktan uzaktırlar.
Neyse ki, İngiliz dili ve gazetecilik mezunları bu sorunu da düzeltebilir.
Dolayısıyla dokümantasyon bilmecesinin çözümü, her biri tabiri caizse farklı bir şapka takan birden fazla kişinin kullanılmasıdır. Birincisi, programın nihai kullanıcılarına benzer özellikler taşıyan bir grup insan; ikincisi ise İngiliz diline hâkim olan başka bir kişi ya da kişiler. Bu şekilde, her bir kişinin eğitimi ve yetişmişliği, diğer her bir kişinin benzersiz geçmişini tamamlayacak biçimde kullanılabilir.
Korkunç bir görev mi? Hayır, keyifli bir görev; çünkü programcı, hem bazı potansiyel son kullanıcıların hem de İngiliz dili ya da gazetecilik mezununun yardımıyla ürününü başkaları için daha kullanışlı hâle getirmektedir. Başkalarının işlerini yaparken biraz daha rahat olmalarını ve belki de biraz daha mutlu olmalarını sağlamaktadır. Aslında hayat tam olarak bundan ibaret değil midir?
Kaynaklar
Card, Stuart K.; Moran, Thomas P.; ve Newell, Allen. The Psychology of Human-Computer Interaction. Hillsdale, NJ: Lawrence Erlbaum Associates, 1983.
Mehlmann, M. When People Use Computers: An Approach to Developing an Interface. Englewood Cliffs, NJ: Prentice-Hall, 1981.
Neumann, A. J. (Ed.). National Bureau of Standards Federal Information Processing Standards Program Software Documentation. 3 Mart 1982 tarihinde düzenlenen bir çalıştayın bildirileri. Springfield, VA: National Technical Information Service, 1982.
Tesler, L. "Enlisting User Help in Software Design." Sigchi Bulletin, Cilt 14, No. 3, Ocak 1983.
Yetsingmeier, J. "Human Factors Considerations in Development of Interactive Software." Sigchi Bulletin, Cilt 16, No. 1, Temmuz 1984.