Doğrulama hataları: nedir, silinmeleri gerekip gerekmediği nasıl kontrol edilir, SEO'yu nasıl etkilerler. Neden geçerli bir koda ihtiyacınız var ve doğrulama hatalarını nasıl düzeltebilirsiniz? Hata durumu nedir?

İnsanlar hata yapmaya eğilimlidir. Hatalar, insanlar kullanıcı arayüzleriyle etkileşime girdiğinde ortaya çıkar. Bazen bu, kullanıcıların hata yapması nedeniyle olur. Bazen uygulamanın kendisinde hatalar meydana gelir. Nedeni ne olursa olsun, hataların ve bunların işlenmesinin UX üzerinde büyük etkisi vardır. Yanlış hata işleme, işe yaramaz hata mesajlarıyla birlikte kullanıcının olumsuz tepki vermesine neden olabilir ve bu da kullanıcının uygulamanızı kullanmayı reddetmesine neden olabilir.

Bu yazıda, kullanıcı hatalarını önlemek için uygulama tasarımınızı nasıl optimize edebileceğinizi ve kullanıcının ne girdiğine bakılmaksızın hataların oluşması durumunda etkili hata mesajlarının nasıl oluşturulabileceğini keşfedeceğiz. Ayrıca, iyi ele alınan bir hatanın başarısızlığı nasıl hayranlığa dönüştürebileceğine de bakacağız. Adobe, etkileşimli projeler ve hata durumları tasarlamanıza olanak tanıyan yeni bir tasarım ve geliştirme uygulaması olan Deneyim Tasarımı'nı (Adobe XD) kullanıma sundu. Adobe XD'yi ücretsiz indirip deneyebilirsiniz.

Hata durumu, bir şeyler ters gittiğinde kullanıcıya gösterilen bir ekrandır. Bu, kullanıcının istenen durumdan farklı bir şey yaptığı duruma bir örnektir. Hatalar beklenmedik kombinasyonlarda oluşabileceğinden bu koşullar, tutarsız kullanıcı işlemlerinden (yanlış veri girişi gibi), uygulamanın sunucuya bağlanamamasına, hatta kullanıcının isteğini işleyememesine kadar tamamen farklı sorunları içerebilir.

Hatalı ekranlar

Nedeni ne olursa olsun her hata, kullanıcı deneyimi yolculuğunda bir engel haline gelir. Neyse ki, iyi biçimlendirilmiş bir hata hoş olmayan etkiyi azaltabilir.

Bir uygulama geliştiriyorsanız, kullanıcının uygulamayla hataya yol açabilecek ana etkileşimlerinin neler olduğunu anlamalısınız. Örneğin, ilk denemede bir formu doğru şekilde doldurmak genellikle çok zordur veya cihazın ağ bağlantısı zayıfsa verileri doğru şekilde senkronize etmek imkansızdır. Hata olasılığını en aza indirmek için bu gibi noktaları dikkate almalısınız. Yani ipuçları göstererek, kısıtlamalar ve esneklik kullanarak hata yapma olasılığını önlemek daha iyidir.

Örneğin, insanların otel aramasına ve rezervasyon yapmasına izin veriyorsanız, kullanıcı böyle bir tarih seçerse neden mevcut tarihleri ​​geçmişte bırakıp hata atasınız ki?

Booking.com örneğinde gösterildiği gibi, kullanıcıların yalnızca bugünün tarihini ve gelecekteki tarihleri ​​seçmesine olanak tanıyan bir tarih seçiciyi kullanabilirsiniz. Bu, kullanıcıları yalnızca geçerli tarihleri ​​seçmeye teşvik edecektir.

Biçim iletişimdir. Herhangi bir iletişim gibi, bu da iki taraf (kullanıcı ve uygulamanız) arasında seri bir iletişim olmalıdır. Doğrulama bu iletişim sürecinde önemli bir rol oynar. Form doğrulama, kullanıcılara karmaşıklıklar, hatalar ve yanlış anlamalar konusunda rehberlik etmek için tasarlanmıştır. Doğru doğrulamayla bu tür bir iletişim açık ve anlaşılır hale gelir. Genel olarak iyi form doğrulama dört önemli unsurdan oluşur:

• Hatalar (veya başarılı tamamlama) hakkında bilgi vermenin doğru zamanı
• Doğrulama mesajı için doğru yer
• Doğru mesaj rengi
• Mesaj dilini temizle

Form hatası doğrulaması kaçınılmazdır ve kullanıcı girişinin mantıksal bir parçasıdır (çünkü kullanıcı girişi hataya açık olabilir). Elbette hataya neden olabilecek durumların en aza indirilmesi gerekir ancak hata doğrulaması kaldırılamaz. O halde en önemli soru şudur: “Kullanıcı için hata düzeltme süreci nasıl basitleştirilir?”

Kullanıcılar, özellikle sonunda bir hata bildirimi aldıklarında form doldurma işleminden hoşlanmazlar. Uzun bir formu doldurduktan sonra birçok alanda hata mesajı almak özellikle sinir bozucudur. Ve en sinir bozucu şey, hangi hataları nerede yaptığınızın belirsizliğidir.

Doğrulama, kullanıcı verileri girdikten hemen sonra verilen cevabın doğruluğu konusunda kullanıcıyı derhal bilgilendirmelidir. İyi doğrulamanın temel ilkesi şudur: “Kullanıcılarla konuşun! Onlara sorunun ne olduğunu söyle!" ve gerçek zamanlı dize doğrulama, kullanıcıları girilen verilerin doğruluğu konusunda bilgilendirir. Bu yaklaşım, kullanıcıların hataları hızlı bir şekilde düzeltmesine ve onay düğmesine bastıktan sonra hataların görüntülenmesini beklememesine olanak tanır.

Ancak her tuş vuruşunu doğrulamaktan kaçınmalısınız çünkü çoğu durumda kullanıcı yanıtını yazmayı bitirmeden verileri doğrulayamazsınız. Yazarken bir değeri doğrulayan formlar, veri girmeye başladığı andan itibaren kullanıcıyı rahatsız etmeye başlıyor.

Öte yandan veri girişi sonrasında doğrulanan formlar, kullanıcıyı hata konusunda yeterince hızlı bilgilendirmiyor.

Mikhail Konzhevich, “Formlarda dize doğrulama - deneyim yaratmak! farklı doğrulama stratejilerini araştırdı ve hibrit bir strateji önerdi: erken ödül, geç ceza.

Kullanıcı yönelimi bir diğer önemli araçtır. Doğrulama mesajınızı nereye yerleştireceğinizi merak ettiğinizde şu tavsiyeye uyun: mesajı her zaman bir eylemin bağlamına yerleştirin. Kullanıcıya belirli bir alandaki bir hatayı bildirmek istiyorsanız onu yanında gösterin. Hızlı doğrulamanın giriş alanının sağına veya altına yerleştirilmesi en iyisidir.

Renk, doğrulama oluştururken kullanılacak en iyi araçlardan biridir. Sezgisel düzeyde çalışma şekli açısından, hata için kırmızı, uyarı için sarı ve başarı için yeşil özellikle güçlüdür. Ancak renklerin kullanıcılar tarafından iyi algılandığından emin olun. Bu, iyi görsel tasarımın kritik bir yönüdür.

Tipik bir hata mesajı, kullanıcıya e-postanın neden geçersiz olduğunu açıklamadan "e-posta geçersiz" diyebilir. (Tipografi? E-posta başka bir kullanıcıyla mı meşgul?) Basit talimatlar veya yönergeler işleri farklı şekilde yapabilir. Örnekte formun kullanıcıya e-postasının zaten alındığı konusunda nasıl bilgi verdiğini görebilirsiniz. Ayrıca birkaç öneri görünür (oturum açma veya şifre kurtarma).

Artık bir şeylerin ters gittiğini göstermek için bir hata sayfası görüntülemenin zamanı geldi. Örnek olarak bağlantının kesildiği ve kullanıcının mevcut tek ekranda olduğu bir durumu hayal edelim. Bu fırsatı insanlara neler olup bittiğini bildirmek ve hızlı bir yardım modeli sunmak için kullanmalısınız; mesajınız kullanıcılar için bir yardım eli olmalıdır. Bu nedenle aşağıdakileri asla göstermemelisiniz:

• Kritik hata mesajı. Uygulama kodundaki dahili bir hatadan bahseden veya "2. tip bir hata oluştu" gibi metinler içeren mesajlar şifreli ve korkutucudur.

• Çıkmaz nokta hatası. Çünkü bu tür mesajlar kullanıcıya herhangi bir yararlı bilgi sağlamaz.

• Belirtilmeyen hata mesajı. Böyle bir ekran (aşağıdaki örnekte) kullanıcıya bir önceki kadar bilgi verir. Kullanıcıların bunun ne anlama geldiği veya bu konuda ne yapacakları hakkında hiçbir fikri yok.

Kullanıcıyı hatalarla korkutmayın. Ayrıca kullanıcıyı sorunun teknik ayrıntılarına yönlendirmeye çalışmayın. Basit ve anlaşılır bir dille hata hakkında konuşun. Bunu yapmak için teknik jargon kullanmamaya ve düşüncelerinizi kullanıcının dilinde ifade etmeye çalışın.

Gönderilerinizi okunabilir ve yararlı hale getirin; hatalar kibar, açık ve öğretici olmalı ve aşağıdaki gibi bilgileri içermelidir:

• Neyin yanlış gittiği ve neden (muhtemelen).
• Kullanıcının hatayı düzeltmek için ne yapması gerekir?

Hata mesajları, simgeleri ve çizimleri kullanmak için harika bir fırsattır çünkü insanlar görsel bilgileri metinden daha iyi algılarlar. Ancak daha da ileri giderek uygulamanıza kullanıcılar için faydalı olacak görseller ekleyebilirsiniz. Bu, uygulamanızı kişiselleştirecek ve mesajınızı yumuşatacaktır.

Mizah ömrü uzatır. Biraz mizah asla zarar vermez ve bir hatanın yarattığı kafa karışıklığını hafifletmeye yardımcı olur. Littlebigdetails'da tonlarca komik mesaj örneği bulabilirsiniz. İşte favorilerimden bazıları:

• Basecamp: Form doğrulaması başarısız olduğunda soldaki karakter şaşırmış bir ifade kullanır.

• Yeni bir Gmail hesabı oluştururken çok fazla nokta girilmeye çalışıldığında hafif arsız bir hata mesajı görüntüleniyor.

Ancak mizah konusunda dikkatli olun çünkü hata mesajınızda her zaman uygun olmayabilir; hatanın ciddiyetine bağlıdır. Örneğin mizah, "404 hatası" (sayfa bulunamadı) gibi basit bir doğrulama probleminde işe yarar. Ancak bir kullanıcı belirli bir süreyi "Oh!" yazan bir sayfayı görüntüleyerek geçirdiğinde. - uygunsuz görünüyor.

İyi hata sayfaları kullanıcılara yardımcı olur ve aşağıdaki altı kriteri karşılamalıdır:

404 hata sayfasının asıl amacı kullanıcınızı en kısa sürede aradığı sayfaya yönlendirmektir. 404 sayfanız kullanıcının gidebileceği birkaç önemli bağlantı sunmalıdır. En güvenli seçenek, 404 sayfasında sitenin “ana sayfasına” bir bağlantının bulunmasıdır. Ayrıca, kullanıcının sayfanın kapalı olduğunu size bildirmesi için bir "sorun bildir" özelliği de koyabilirsiniz. Ancak ana sayfaya geçişin daha net bir geçiş olduğundan ve görsel olarak daha ön plana çıktığından emin olun.

Giriş formu ekranı genellikle minimalist görünür ve bir kullanıcı adı alanı ile bir şifre alanı içerir. Ancak minimalizm sadeliğe eşit değildir. Bir kullanıcının giriş ekranında takılıp kalmasının birçok nedeni vardır. Giriş sayfasının ana kuralı, kullanıcının tahminde bulunmasına izin vermemektir.

Hata mesajlarıyla harika iş çıkaran MailChimp'teki örnekleri kullanarak en yaygın sorunların çözümlerine bakalım.

• Kullanıcı sitede adını unuttu. Benzer bir hata bulursanız kullanıcının sorunu düzeltebileceği bir bağlantı sağlamalısınız. Kullanıcıya onu nereden alabileceğini söyleyin (örneğin: "postanızı kontrol edin, size bir e-posta gönderdik") veya adı siteye geri yüklemek için bir bağlantı sağlayın.

Kullanıcılar yanlış şifreyi kullanarak siteye girmek için birçok girişimde bulunurlar. Bu tür sunucu saldırılarını önlemek için çok sayıda başarısız denemeden sonra kullanıcı hesapları engellenir. Bu yaygın bir güvenlik uygulamasıdır ancak kullanıcının, hesabı bloke edilmeden önce uyarılması gerekir.

Bir kredi kartı çeşitli nedenlerden dolayı reddedilebilir: veri biçimlendirme hatası (yazım hatası veya eksik veri) veya kartın süresi dolduğu veya çalındığı için reddedilebilir. Gabriel Tomescu, Anatomy of a Credit Card Shape adlı makalesinde her iki hata için de şu stratejiyi önerdi:

İlk problem için standart dize doğrulamasını ve görsel hata göstergesini izlemelisiniz:

Ancak bir kredi kartı ödeme işlemcisi tarafından herhangi bir nedenden dolayı reddedilirse, bu genellikle bir adam kaçırma gibi görünür. Kullanıcıdan net verilere ihtiyacınız var. Ve bundan sonra bile kullanıcıya ne olduğunu bildirmeniz gerekiyor; hata mesajı çok açık olmalıdır.

İnternet bağlantısı her yerde mevcut değildir ve çevrimdışı destek, herhangi bir modern uygulamanın hayatında önemli bir unsur olmalıdır. Bağlantı koptuğunda çevrimdışı kullanıcı deneyiminiz hakkında dikkatli düşünmeniz gerekir. Kullanıcılar uygulamanızın mümkün olduğunca çoğuyla etkileşime girebilmelidir. Bu, uygulamanın iyi bir çevrimdışı kullanıcı deneyimi için içeriği önbelleğe alması gerektiği anlamına gelir.

Site doğrulama hatalarının analizi

Bitmek bilmeyen siparişler arasında sonunda boş zamanım oldu ve blogumu açmaya karar verdim. Doğrulama açısından iyileştirmeye çalışalım. Yazının devamında size site doğrulamanın ne olduğunu, html ve css kodunu, neden gerekli olduğunu ve belirli bir örnek kullanarak siteyi standartlara nasıl getireceğinizi anlatacağım.

Site doğrulama nedir?

Basit bir ifadeyle bu, standartlara uygunluğun kontrolüdür. Böylece herhangi bir tarayıcı sitenizi doğru şekilde görüntüleyebilir. Sitenin geçerliliğinin tanıtıma büyük bir etkisi yoktur ancak kesinlikle daha kötü olmayacaktır.

Bir web sitesi sayfası için doğrulamayı geçmenin özel bir örneği

Sitemdeki ilk sayfayı ele alalım - Java 8'de Base64 kodlama ve kod çözme. Doğrulayıcıya sayfa adresini dolduralım ve sonuca bakalım:

Bu belge HTML 4.01 Geçişli olarak kontrol edilirken hatalar bulundu! Sonuç: 105 Hata, 67 uyarı Evet, resim çok çirkin: 100'den fazla hata ve 67 uyarı - arama motorları blogumu ve ziyaretçilerin ziyaretini nasıl indeksliyor? Ancak üzülmeyelim, doğrulamayı nasıl geçeceğimizi, hataları nasıl düzelteceğimizi öğrenelim. Yani ilk uyarı:

Ayrıştırma Modu Belirlenemiyor! Doğrulayıcı, belgeleri XML (XHTML, SVG vb. belge türleri için) veya SGML (HTML 4.01 ve önceki sürümler için) olarak işleyebilir. Bu belge için mevcut bilgiler ayrıştırma modunu açık bir şekilde belirlemek için yeterli değildi, çünkü: MIME Ortam Türü (text/html) XML veya SGML belge türleri için kullanılabilir Bilinen bir Belge Türü algılanamadı XML bildirimi yok (ör. ) belgenin başında bulunabilir. Belgenin kökünde hiçbir XML ad alanı (ör. ) bulunamadı. Varsayılan olarak doğrulayıcı SGML moduna geri dönüyor. Uyarı DOCTYPE bulunamadı! Varsayılan HTML 4.01 Geçişli Belge Türü ile kontrol ediliyor. Bu belgede hiçbir DOCTYPE Beyanı bulunamadı veya tanınamadı. Bu genellikle belgenin Belge Türünü üstte bildirmediği anlamına gelir. Bu aynı zamanda DOCTYPE bildiriminin bir yazım hatası içerdiği veya doğru sözdizimini kullanmadığı anlamına da gelebilir. Belge, "HTML 4.01 Transitional"a çok benzeyen varsayılan bir "geri dönüş" Belge Türü Tanımı kullanılarak kontrol edildi. Bu aynı. Ve düzeltmesi basit: sayfanın en başına şu etiketi ekleyin:

Ne yaptığımızı kontrol ediyoruz ve sadece bu etiketle 105 hata ve 3 uyarıyı kaldırdığımızı görüyoruz! Artık sadece 64 uyarımız kaldı. Bunları tek tek ayırmaya başlayalım.

Uyarı: Stil öğesinin type niteliği gerekli değildir ve atlanmalıdır. 5. satır 1. sütundan; satır 5, sütun 23 /x-icon">↩↩↩↩↩A Bu, stil öğesinin bir tür niteliğine ihtiyaç duymadığı anlamına gelir - bu gereksizdir. Sayfada buna benzer iki açıklamamız var. JavaScript için benzer bir uyarı:

Uyarı: Type niteliği JavaScript kaynakları için gereksizdir. 418. satırın 1. sütunundan; satır 418, sütun 31 ↩↩$(doc Bu tür 8 hatamız var. Bu özellikleri kaldırıyoruz ve şerefe - 10 uyarı daha az!

Hata: CSS: arka plan: Doğrusal gradyan fonksiyonunun ilk argümanı üstte değil üstte olmalıdır. Satır 39, sütun 61 %0,#E8E8E8 %100);↩ border-r Bir sonraki hata, doğrusal degradeye ilişkin ilk argümanın üst değil üst olması gerektiğidir. Hadi düzeltelim. Sonraki hata:

Hata: CSS: Ayrıştırma Hatası. 65. satırın 13. sütunundan; 65. satır, 16. sütun kenar boşluğu: 0 auto;↩padd CSS'imin burada yanlış yorumlanmasını sağladım. Bu satırı kaldırmanız yeterli. Veya /* ve */'yi farklı şekilde yorumlayın. Eskiden yaptığım gibi yaptım.

Hata: CSS: @charset ve @import dışında herhangi bir geçerli ifadeden sonra @import'a izin verilmez.. 88. satır, 74. sütunda 0,600,700,300);↩@import url(// Şimdi bir içe aktarma hatamız var. dosyanın başlangıcı ve ortadan kaybolacak.

Hata: a öğesindeki özellik hedefi için hatalı _blanck değeri: Ayrılmış anahtar kelime blanc kullanıldı. 241. satır 218. sütundan; satır 241, sütun 295'e kadar cookie..php?id=98" target="_blanck" style="display: inline;">Burada Sonra hedef özelliğinin değerini beğenmiyoruz, "blank" kullanmamız söyleniyor " Başındaki alt çizgi olmadan kaldırıyoruz.

Hata: Bitiş etiketi görüldü ancak açık öğeler vardı. 379. satırın 2. sütunundan; 379. satır, 6. sütuna

↩ ↩↩