yazılım geyiklemeleri

yazılım dünyasında 95'lerde RAD geliştirme ortamlarının yaygınlaşmasıyla dünyamıza girdi grid.

görünüm olarak gayet temiz, satır ve sütunlardan oluşan listeleri sadece 2-3 satır kod yazarak ekranda gösterilebilir ve düzenlenebilir hale getirebiliyorduk.

QBasic ve Pascal'dan gelen programcılar için biraz tuhaf olan yeni windows işletim sistemi için bir sivilceli suratlarımıza atılmış bir sarışın gülümsemesiydi bu kontrol. Ardından gelen birkaç sene sonra tüm arayüzleri gridden ibaret uygulamalar türemeye başladı.

Muhasebe paketleri, hastane uygulamaları, insan kaynakları, stok paketi adı altında görünüşü organize edilmiş excel dosyaları gibi her bütona tıkladığınızda (anlamsız) başka bir grid açılan uygulamalar görmeye başladık. Bu tür uygulamalarda artık arayüz (UI) olarak anlaşılan şey gridler ve bütonlardan ibaretti.

Genetik olarak bozuk arayüzler

Devamında sadece satır ve sütunlar yerine hiyerarşik satırlar, edit ettiğiniz hücreye göre farklı arayüzleri olan tuhaf grid bileşenleri ortaya çıkmaya başladı. Bu tuhaf grid'lerle mail client'larından ERP sistemlerine ve hatta mp3 player'lara kadar garip uygulamalar yazıldı.

Bu uygulamaların tasarımınında herşey kullanıcının veri girebileceği herhangi bir alan olması üzerine kuruludur ve kullanılabilirlik yada kullanıcı dostu olmak gibi terimler grid'in yetenekleri ve programcının zevki ile alakalıdır.

Inductive arayüzler

Windows XP ile başlayan inductive arayüz tasarımları sayesinde artık bu anlamsız;

arayüzler yerine

şeklinde yeni tipdeki arayüzleri kullanmaya başladık. Özellikle yeni Vista işletim sisteminde inductive arayüzler tüm işletim sisteminde görülebiliyor.

Neden?

Grid yapısındaki uygulamalar oldukça gelişmiş diyebileceğimiz uzmanlıktaki yazılımcıların son kullanıcılara bir eziyetidir.

Yazılımcı daha iyi bir arayüz vermediği için kullanıcılar elde olanı kullanmak zorunda kalır. Kullanıcılardan "bu böyle olsa daha iyi olur" şeklinde analitik bir geridönüş beklentisine girmek kendi işinizi başkasından beklemekle eşdeğerdir. Ama bu beklenti nadiren gerçekleşir çünkü onların sizin verdiğiniz arayüzü kullanarak yapacağı bir ton kendi işleri vardır.

Uygulamayı tanımayan bir son kullanıcı için karşılaştığı arayüzler "Napıyoruz? Nerdendi? Şimdi?" gibi soruların kaynağıdır.

Kullanıcıya ne yapması gerektiğini söylemeyen tüm arayüzlerde kullanıcı sizden okumayacağı bir kullanım kitabı isteyecektir. Siz o kitabı yazsanız bile asla okumayacağı için her bir arayüzde ne yapması gerektiğini yan masadaki arkadaşından öğrenmesi gerekir ve bunu sürekli unutur. Her yeni kullanıcı için bir kaç hafta sonra tekrar sorular soracağı aynı eğitimleri tekrarlarsınız. Sadece liste içerisinde göstereceğiniz minik bir ikon bile kullanıcıya biraz önce yan masadaki arkadaşıyla şakalaşması sırasında o anda ne yaptığını hatırlatmaya yardımcı olacaktır.

Uygulamanın kullanım ve bilinirliğini düşürür, bu yüzden son kullanıcı uygulamanızın sadece belli bir oranını kullanır ve bu oran kendiliğinden zaman yükselmez.

Arayüzler yapılacak işleme göre (task based) tasarlanmadığı kullanıcıya olası tüm fonksiyonları içeren ama kurcalanmaya korkulan bir uygulama yaratırsınız. Kullanıcılar kullanıcı kitabının yanında ekrandaki yazılarıda asla okumadıkları için 1sn önce hangi bütona tıkladıklarını ve yazılımın hangi uyarıyı verdiğini hatırlamazlar. (Ne? Emin misiniz diye soruyordu o büton? Peki neden evet'e tıkladın?!) Kurcalanmaya korkulan herşey bilinmezliklerle doludur.

Performansı katleder.

Listeden seçilecek tek bir tane müşteri için binlerce adet kaydın listelenmesinin anlamı yoktur. Siz sayfalama v.s gibi teknikler kullansanız bile hiç bir kullanıcının 55 sayfa içerisinde gezerek istediği kayıdı arayacak zamanı yoktur. Bunun yerine asla tüm kayıtları listelememeli ve arama tabanlı, maksimum adetli bir liste kullanmanız her zaman mantıklıdır. Liste içerisinde sadece kullanıcının o anda yaptığı iş ile alakalı verileri listelemek ve seçenekler sunmak yardımcı olacaktır.