JavaScript'in "eski moda" olarak kabul edilen bilgi istemi, onaylaması ve uyarısı [kapalı]


21

Son zamanlarda bir spor salonu için web tabanlı bir yönetim sistemi geliştiriyorum. Önceki uygulamaları Visual Basic'te geliştirildi. Yeni uygulama için, tüm ön uç komut dosyaları jQuery kullanır, sunucu PHP ve MySQL çalıştırıyor ... bilirsiniz, tipik el-cheapo linux tabanlı yığın.

Her neyse, JavaScript'in istemi, onaylama ve uyarı mesajı iletişim kutularının günümüzde neden bu kadar az kullanıldığını merak ediyordum. Modal pencereler ve dilin zaten sunduğu bir şeyi taklit etmeye çalışan uyarı mesajları için çok sayıda jQuery eklentisi var ve her tarayıcı düzgün bir şekilde desteklemeye zorlanıyor.

El yapımı veya eklenti tabanlı çözümler kullanmak karmaşık formlar ve özel ihtiyaçlar için uygundur, ancak tek bir değer istemeniz veya bir kaydın silinmesini onaylamanız gerekiyorsa, web uygulamanıza neden bu ek yükü eklemelisiniz? Ayrıca, iOS ve Android, istemi, onaylamayı ve uyarıyı kullandığınızda hoş bir şekilde uyarlanmış mesaj iletişim kutuları sunar.


7
"El cheapo?" Gerçekten mi? Biraz aşağılayıcı değil mi?
asthasr

1
Kafam karıştı; önce uygulamanın Visual Basic'te geliştirildiğini, sonra sunucunun PHP çalıştırdığını söylersiniz. ha?
jhocking

@jhocking: eski sistemin VB'de yazılmış bir masaüstü uygulaması olduğunu ve yenisinin (yazdığı) bir LAMP yığınıyla yazıldığını söylüyor gibi görünüyor.
Ürdün

Önceki uygulamaları vb. Olarak yazılmış gibi görünüyor, şu anda bunun için bir web ön ucu yapıyor.
GrandmasterB

Yanıtlar:


56

1. UX: mesaj kutuları çoğunlukla kötüdür

Uyarı kutuları UX açısından her durumda kötüdür. Masaüstü uygulamalarında. Web uygulamalarında uyarılar veya satır içi JavaScript mesajları olarak. Her yerde.

Nedenini bilmek isterseniz Alan Cooper¹'dan Face 3 Hakkında bölümünü okuyabilirsiniz; bunun iş akışını nasıl kesintiye uğrattığını ve kullanıcıyı rahatsız ettiğini ve mevcut yazılımda bulunan hemen hemen her uyarı kutusunun ne kadar yanlış olduğunu açıklar . 542 Sayfasında "Kurt!" Diye iletişim kuran iletişim kutusu, uyarı kutularının rutin olarak kapatıldığını açıklar, bu nedenle modelleri tamamen bozulur. Kitabın 543. sayfasında üç ana tasarım ilkesi listelenmiştir:

  • Yapma, sorma.
  • Tüm eylemleri geri alınabilir yapın.
  • Kullanıcıların hatalardan kaçınmasına yardımcı olmak için modelsiz geri bildirim sağlayın.

Ardından, yazarlar bize uyarı kutularının doğru tasarım yaklaşımıyla nasıl değiştirileceğini anlattı.

Bilgi istemi mesajları biraz farklıdır. Yine de, uygulamanızın kullanıcı deneyimini bozuyorlar. Kullanıcının bir şey girmesini istiyorsanız, gerektiğinde JavaScript ile süsleyen bir metin kutusu veya metin alanı kullanmayı düşünün. Tembel olmayın, RIA ve AJAX özellikli uygulamalar çağında zengin bir arayüz sağlayın ; her durumda, JavaScript devre dışı bırakılmışsa, isteminiz görüntülenmez.

Web sayfalarında, hem uyarı kutuları hem de bilgi istemleri çoğunlukla can sıkıcıdır. Bazı örnekler:

  1. Bazı forumlar, liste öğeleri için sonsuz bir şekilde isteyerek listeler oluşturmanıza izin verir. Bu, listeyi oluştururken kopyala yapıştır da dahil olmak üzere sayfanın kendisini kullanamayacağınız anlamına gelir. Ayrıca küçük bir alanınız var. Uzun metin ne olacak? Kalın ve italik yazılara ne dersiniz?

  2. "Devam ederseniz, fotoğraf profilinizden kesinlikle kaldırılacak. Emin misiniz?" . Elbette eminim! Aksi takdirde "Fotoğrafı profilimden kaldır" ı tıklayabilir miyim? Neden web uygulamanız bu kadar aptal olduğumu düşünüyor? Aslında, GMail olarak Google uygulamaları doğru yaklaşımı göstermektedir. İstediğiniz her şeyi kaldırabilir, silebilir, imha edebilirsiniz ve bunu yaptığınızda uygulama küçük bir "Geri Al" bağlantısı görüntüler.

  3. "En büyük anketimize katılmak ister misiniz?" . Aslında, web sitenizi ziyaret etmek için oradaydım, ama beni rahatsız edici mesajlarınızla rahatsız ettiğiniz için, başka bir yere gitmeyi tercih ederim.

  4. "Telif hakkıyla korunan fotoğrafları korumak için bu web sitesinde sağ tıklama devre dışı bırakıldı" . Aslında, yorumumu göndermeden önce yazım denetleyicisinin dilini değiştirmek için sağ tıkladım. Elbette, yazımı kontrol etmeden göndereceğim.

Sonuç: kullanıcı deneyimi açısından, uygulamalar çoğu zaman mesaj kutularını yanlış kullanır.

Fakat bekle! Birçok düşük kaliteli web sitesi, can sıkıcı uyarı kutularını can sıkıcı JQuery mesajlarını tüm sayfayı kapsayan yarı saydam bir arka planla değiştirir. Böylece dezavantajlar devam ediyor.

Web uygulamalarında mesaj kutularını kullanmamak için başka nedenler de vardır:

2. Tasarım: uyarı kutuları kendi tasarım var

Hiç bir uyarı kutusu tasarlayamazsınız. Rengini, boyutunu, yazı tipini değiştiremezsiniz. Bu, kullanıcı için daha da sinir bozucu hale geliyor: bir web uygulamasıyla çalışıyordunuz ve iş akışınız, hiçbir yerden gelmiyor gibi görünen ve uygulamanın görsel yönüyle eşleşmeyen bir mesajla kesiliyor. Düğmelerin dilinin aynı zamanda web uygulamasıyla değil OS / tarayıcı diliyle eşleştiğini saymamak.

Tasarımcılar için JavaScript mesajları uyarı kutularından çok daha güçlüdür.

Ayrıca çok daha kapsamlıdır. Kalın ve italik ekleyebilirsiniz, kendi düğmelerinizi seçebilirsiniz (ne hakkında: "Özür dileriz, ancak girdiğiniz şifre geçersiz. [Parolamı sıfırla] [Başka bir tane deneyin] [İptal]"?) ².

3. JavaScript: uygulama akışı durur

Bir uyarı kutusu görüntülerken, kullanıcı tıklayana kadar JavaScript yürütmeyi durdurur. Bir web sitesinde, sorun olabilir. Bir web uygulamasıyla, genellikle bir sorun haline gelir.

4. Sandbox: kullanıcıyı bilgisayarını yeniden başlatmaya zorlamayın

Size sonsuz sayıda mesaj kutusu gösteren boktan web sitelerini hatırlıyor musunuz? Yeterli teknik altyapısı olmayan kullanıcıların çalışmaya devam edebilmelerinin tek yolu aslında bilgisayarlarını yeniden başlatmaktı. Bu bizi bir soruna getiriyor: uyarı kutuları web sitesinin veya web uygulamasının kapsamı dışında. Kullanıcının tarayıcının diğer sekmelerine erişmesini engelleme yetkiniz yok³.

Aynı sorun tarayıcıları farklı şekillerde çözmeye zorladı. Örneğin Firefox, sekmenizde bir uyarı görüntülerken diğer sekmelere erişime izin verir. Öte yandan Chrome, bir sayfadan artık uyarı kutusu almak istemediğinizi kontrol etmenizi sağlar, ancak yine de diğer sekmelere erişimi engeller.

Ekran görüntüsü, "Bu sayfanın ek iletişim kutuları oluşturmasını engelle" onay kutusunu içeren bir uyarı kutusu gösteriyor

Firefox yaklaşımı mükemmel bir şekilde geçerli olsa da, Chrome'un eleştirisi (hala her sekmeyi engellediğinden) eleştirilebilir ve bir soruna neden olur: kullanıcı, uygulamanız tarafından yayınlanan ve mesaj kutusunu kontrol eden birkaç mesaj kutusu tarafından ciddi şekilde rahatsız edildiyse ve gerçekten önemli bir şey göstermeye çalıştınız mı? Doğru, kullanıcı asla görmeyecek.

Gerçek aynı kalır, çoğu kullanıcı uyarı kutuları tarafından rahatsız edilir, bu yüzden hala çok kullanıcı dostu değildir ve yeterli teknik altyapıya sahip olmayan bir kullanıcıyı ciddi şekilde engelleyebilir. Satır içi olarak, JavaScript iletileri sayfayı engelleyebilir, ancak tarayıcının kendisini engelleyemez. Web uygulama modeli, örneğin kullanıcı klavyesine erişemeyeceğiniz veya bilgisayarı yeniden başlatamayacağınız veya sabit diskten dosya okuyamayacağınız veya tam ekran kullanamayacağınız veya iki monitör kullanamayacağınız bir tür korumalı alan olduğundan, engelleme efektleriyle uyarı kutuları ciddi şekilde kırılır kum havuzu modeli .

Son olarak, uygulamanız uyarı kutusunu göstermeye karar verdiğinde kullanıcı başka bir sekmede olsaydı ne olurdu? Kullanıcı önemli bir şey yapıyorsa ve şu anda uygulamanızla etkileşim kurmak istemiyorsa ne olacak?


¹ Yüz 3, Etkileşim Tasarım Essentials hakkında Alan Cooper, Robert Reimann ve David Cronin, ISBN 978-0-470-08411-3; Bölüm 25: Hatalar, Uyarılar ve Onaylar.

² Bu sadece bir örnek. Lütfen, web uygulamalarınızda bunu yapmayın, çünkü gerçekten kötü bir tasarım seçeneği.

³ Masaüstü uygulamalarının dünyasıyla karşılaştırma yapmak istiyorsanız, satır içi JavaScript mesajı bir masaüstü uygulamasının mesaj kutusu gibidir. Tarayıcıdaki bir uyarı kutusu, başka hiçbir masaüstü uygulamasına erişmenizi engelleyen tam ekran opak bir arka plan üzerinde hiçbir yerden görünmeyen, en üstte ayarlanmış bir pencere gibidir. Bilgisayarımda bir kez yapmaya karar verecek tüm uygulamalar hemen ve sonsuza kadar kaldırılacaktır.


1
Sorunun sonsuz veya spam pop-up'larla bir ilgisi yoktu, o zaman neden burada bahsediyorsunuz? Ve JS pop up'larının açılmayacak kadar kötü bir şey olduğunu düşünmüyorum. Düzgün kullanıldığında (kullanıcıyı MAJOR'a bir şey uyarmak için) kullanıcıyı başka bir şey yapmadan önce onlara yöneltmeye zorlarlar, ki bu bazen istediğiniz şeydir.
Graham

Bu soruya cevap vermiyor.
CaffGeek

1
"Bir uyarı kutusu görüntülerken, kullanıcı tıklayana kadar JavaScript yürütmeyi durdurur" - bu bir confirm()ve için geçerlidir prompt(); ile alert(), davranış tarayıcıya bağlıdır (uyarı () gösterilse bile yürütme devam edebilir - mantık "zaten tek bir çıkış yolu vardır").
Piskvor

1
@ Graham: Sonsuz pop-up pencereler için haklısın; Bu noktada konu dışıydım. Bunu daha iyi yeniden biçimlendirmeye çalıştım. Önemli bir şey hakkında uyarıda bulunmak gerekirse, cevabımın dördüncü noktasına bakın: evet, kullanıcı bir eylemi onaylamadan önce her şeyi durdurmak isteyebilirsiniz, ancak diğer sekmeler engellemediğinden tarayıcının her sekmesini engellemenize izin vermez web uygulamanıza aittir.
Arseni Mourzenko

1
@BornToCode: alternatif yok. Fotoğrafları kullanıcının ekranında gösterir göstermez, kopyalanmasını önlemenin bir yolu yoktur. İkinci sorunuza gelince, daha spesifik olmalısınız. Ux.se'yi deneyin .
Arseni Mourzenko

3

Alt satır: Varsayılan bilgi istemi, onayla ve uyar iletişim kutuları sitenizin stiliyle değil tarayıcınızın stiliyle eşleşir. Çoğu kullanıcı arayüzü, tüm iletişim kutularının sitelerinin kullanıcı arayüzüyle akmasını ister. İletileri sunmak ve MSIE veya FF'nin varsayılan gri ve mavisini değil, sitenin kullanıcı arayüzüyle aynı yazı tiplerini ve renkleri kullanarak veri toplamak için kalıcı pencereler kullanırlar.


2

Yalnızca başka bir yerde, muhtemelen yaptığınız süslü diyaloglara ihtiyacınız yoksa ek yük eklersiniz. Bu noktada, işlevin tarayıcının bir parçası olarak mı yoksa kullandığınız çerçevenin bir parçası olarak mı dahil olduğu çok fazla fark yaratmaz ve ayrıca tüm pop-up'larınızın tutarlı görünmesini sağlayabilirsiniz.

Javascript ve çerçeveler olmadan çok şey yapabilirken, çerçeveler mevcut olmadan önce javascript'te gelişmenin nasıl bir şey olduğunu hatırlıyorum ve ona geri dönmek istemem.


1

Çünkü tarayıcılar onları çok iyi idare etmiyor . Farkedebileceğiniz gibi, genellikle kalıcı diyaloglardır ve kullanıcıların tarayıcılarını taşımasını ve yeniden boyutlandırmasını engellemekle kalmaz, aynı zamanda diğer sekmelere erişilmesini de engeller, bu da çok can sıkıcı bir durumdur.

Onayla ve değiştir gibi iletişim kutuları için hala tarayıcının davranışı zorlaması gerektiğini düşünüyorum ve en son Firefox tarayıcısı için yukarıda bahsettiğim sorunu giderdiklerini görebilirsiniz. Geçerli sayfaya dahil edilen sayfa uyarılarında kullanırlar.

Bu nedenle, tüm tarayıcıların (en azından uyarılar) daha zarif bir şekilde işleyebilmesi için uyarı davranışını geçersiz kılmanızı öneririm.

Bazı özetlenmiş nedenler:

  • Bu standart API'dir ve geliştiriciler ne yapmaya çalıştığınızı anlayabilirler.
  • Daha kullanıcı dostu ve daha iyi görünüyor.
  • Platform desteği, mobil sitelerin yerel API'ya ihtiyacı olabilir.
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.