Gönder’e bastıktan sonra: bir web formunun görünmeyen yolculuğu
Bir formun tarayıcıdan işletmeye uzanan yolunu; doğrulama, kayıt, bildirim ve hata durumları üzerinden anlaşılır bir teklif talebi örneğiyle izleyin.
Bir formda “Gönder” düğmesine basmak birkaç saniyelik bir iş gibi görünür. İşletme tarafında ise bu hareket; talebin alınması, kontrol edilmesi, kaydedilmesi ve ilgili kişiye ulaştırılması anlamına gelebilir. İyi bir form tasarlamak için alanların nasıl göründüğü kadar bu yolculuğun nasıl tamamlandığını da konuşmak gerekir. Ziyaretçinin ekranda gördüğü başarı mesajı, sürecin yalnızca bir parçasıdır.
Tarayıcı ile sunucu arasındaki konuşma
Tarayıcı kullanıcının doldurduğu formdan bir istek oluşturabilir. Sunucu bu isteği işler ve bir yanıt gönderir. Yanıt, yeni bir sayfa veya mevcut ekranda gösterilecek bilgi olabilir. Her formun veri tabanına kayıt yapması ya da e-posta göndermesi zorunlu değildir; bunlar uygulamanın tasarımına bağlıdır. MDN: İstemci ve sunucuya genel bakış
Bu nedenle form görüşmesinde “Mesaj nereye düşecek?” sorusunun tek cevabı olmayabilir. Yönetim paneline kayıt, e-posta bildirimi ve ekip içi görev oluşturma birbirinden ayrı işlemlerdir. Hangilerinin gerçekten gerektiğini belirlemek, görünmeyen beklentileri baştan açığa çıkarır.
Temsili bir teklif talebinin yolu
Özel ölçüyle üretim yapan bir atölye düşünelim. Ziyaretçi ürün kodunu, yaklaşık adedi ve iletişim bilgisini yazıyor. Ekibin talebi değerlendirebilmesi için üç temel karar gerekir: Hangi alanlar zorunlu olacak, eksik bilgi nasıl tamamlanacak ve ilk yanıtı kim verecek?
Formu yalnızca teknik ekibe “iletişim formu” diye tarif etmek bu ayrıntıları açık bırakır. Daha somut bir tarif şöyle olabilir: “Ürün kodu ile adet girilebilsin; talep kaydedilsin; satış sorumlusu yeni talepleri panelde görebilsin; ziyaretçi kaydın alındığına ilişkin açık bir yanıt görsün.”
Burada e-posta, kayıt sisteminin kendisi değil, ayrıca istenebilecek bir bildirimdir. Bildirimin ulaşmamasıyla kaydın oluşmaması farklı durumlardır. İşletmenin bu farkı görebilmesi, kayıp talebi araştırmayı kolaylaştırır.
Doğrulama neden iki tarafta düşünülür?
Tarayıcıdaki kontrol, eksik veya hatalı alanı hızlıca göstermeye yardımcı olur. Ancak sunucu, kendisine gelen veriyi ayrıca kontrol etmelidir. İstekler yalnızca ekrandaki form kullanılarak gönderilmek zorunda değildir. OWASP, girdi doğrulamasının sunucuda uygulanmasını ve hem biçim hem anlam bakımından ele alınmasını önerir. Örneğin adet alanının sayı olması biçim kontrolüdür; işletmenin kabul ettiği aralıkta olması ise iş kuralıyla ilgilidir. OWASP: Girdi doğrulama
Doğrulama, güvenliğin tamamı değildir. Kullanıcının hangi verilere erişebileceği, yüklenen dosyanın nasıl işlendiği ve ekranda gösterilen içeriğin güvenli sunulması ayrıca ele alınır. Tek bir “güvenli form” ifadesi yerine beklenen davranışların ayrı ayrı yazılması daha açıklayıcıdır.
Başarı mesajı neyi söylemeli?
Temsili talep akışında kayıt oluştuysa “Talebiniz alındı” denilebilir. Bu mesajı “Teklifiniz hazır” diye yazmak ise başka bir işin tamamlandığını ima eder. Benzer şekilde kayıt henüz doğrulanmadan başarı bildirimi göstermek, ziyaretçinin yeniden gönderme veya yardım isteme kararını zorlaştırır.
Bir hata durumunda yalnızca “Bir şeyler ters gitti” demek de yeterli olmayabilir. Kullanıcı hangi alanı düzelteceğini veya daha sonra tekrar deneyip denemeyeceğini anlayabilmelidir. Girilen uzun açıklamanın gereksiz yere silinmemesi, küçük görünen ama gerçek kullanımda değerli bir ayrıntıdır.
Konya web yazılım hizmeti için kapsam belirlerken bu durumları örnek ekranlarla konuşmak faydalıdır. Böylece formun tamamlanmış sayılması, düğmenin tıklanabilmesinden daha somut ölçütlere bağlanır.
Teslim sırasında denenebilecek senaryolar
Bir formun kontrolü, gerçek müşterilerden gereksiz veri toplamadan planlanabilir. Yetkili ekip, belirlenmiş test verisiyle şu durumları inceleyebilir:
- Gerekli alanlardan biri eksik bırakıldığında açık bir uyarı görünüyor mu?
- Geçerli talep kaydedildiğinde kullanıcı bunu anlayabiliyor mu?
- İşletme tarafındaki sorumlu, kaydın nerede olduğunu bulabiliyor mu?
- Bildirim sorunu olduğunda kayıt ile bildirim durumu ayrılabiliyor mu?
- Kullanıcı iki kez gönderdiğinde beklenen davranış tanımlı mı?
- Telefon ekranında ve klavyeyle kullanımda aynı görev tamamlanabiliyor mu?
Konya yazılım firmaları arasında teklif karşılaştıran bir işletme, bu listeyi kendi sürecine uyarlayabilir. Bütün projelerde aynı panel veya bildirim yapısı gerekmez. Önce ihtiyaç yazılmalı, sonra ona uygun çözüm seçilmelidir. DoktorWeb ile web projesinin kapsamını konuşurken örnek bir müşteri talebini başlangıç olarak kullanabilirsiniz.
Kısa cevaplar
Formdan gelen her mesaj e-posta mıdır?
Hayır. Mesaj uygulamada saklanabilir, bir iş kaydına dönüşebilir veya başka bir sisteme aktarılabilir. E-posta bunlara ek bir bildirim olarak kullanılabilir. Projede hangi adımların bulunduğu açıkça belirtilmelidir.
Formun çalıştığını nasıl anlayabiliriz?
Ziyaretçi tarafındaki yanıtı ve işletme tarafındaki kaydı birlikte kontrol ederek. Yalnızca ekranda başarı yazması, arka plandaki bütün adımların tamamlandığını tek başına kanıtlamaz.
Yazının başına dön ↑