Aslında bu soru, kaliteli kullanıcı deneyimini geliştirmek ve önlenebilir destek çağrılarını azaltmak için alınması gereken önlemlerle ilgilidir.
Yanıtlar:
Doğru giriş doğrulamasının olmaması, programcı tarafından gerçekten ele alınması gerektiğinde, uygulamanızla "kötü" şeyler yapan kullanıcılara oldukça hızlı bir şekilde yönlendirme eğiliminde olan şeylerden biridir.
Kullanıcıların eğitildiği eski uygulamalar gördüm:
a-z0-9,emailalana doğru biçimlendirilmiş bir e-posta adresinin girilip girilmediğini kontrol edin , aksi takdirde bu kullanıcıya yapılacak sonraki postalamalar alandakileri kullanır ve başarısız olurhttp://" web adreslerinin önüne yerleştirildiğinden emin olunvs vs
Yukarıdaki sorunların tümü , bir uygulama geliştiricisi tarafından ele alınması gereken sorunlardır . Giriş doğrulamanız esas olarak "kullanıcının bu alanın hangi formatta olması gerektiğini bildiğinden ve girdiklerinin doğru olduğundan emin olun" olduğunda, beklenmedik şeyler uygulamaya giriş yapmak zorundadır. Bariz güvenlik etkileri dışında, kullanıcılar hata yapar. Programcılar olarak, en iyi ürünlerimizi, kullanıcının ne kadar uğraştıklarına bakılmaksızın, yanlış anlayamayacağından emin olmak için geriye doğru eğilerek üretiyoruz !
http://Doğrulama noktası için aynı hikaye . Örnek olarak, ASDFbunu saf bir şekilde yapar ve sonuç, paketleri kullanılan etki alanlarında barındıramazsınız https://.
Bir keresinde bir müşteri destek çağrısı aldım çünkü uygulamam kayboldu. Bunun üzerine başka bir uygulama açtıkları ortaya çıktı.
... Bu sorun değil neden kullanıcılar bilgisayar cehalet olduğu için, bir daha olmadı emin değil karar verdi app değil. Bunu düzeltmek için yapabileceğim her şey başkaları için kötü bir kullanıcı deneyimine yol açacaktır.
Yazdığım neredeyse her program kesinlikle komut satırından çağrılır. Ayrıca CLI arayüzleri olarak başlayan ve hızla her şeyden çok daha fazla kabuk haline gelen bazı meraklı şeyler yazdım.
Yani, sadece bildiklerim için konuşabilirim. Komut satırı programlarıyla ilgili sık karşılaşılan bazı sorunlar şunlardır:
Çok fazla seçenek
Bir derleyici veya satır düzenleyicisi yazmıyorsanız, --helpveya /?geçildiğinde 80x25 kare arabellekte seçenekleri bir ekranla dolu tutmaya çalışın . Bundan daha fazla seçeneğe sahip olmak mükemmel, ancak bunları alt kategorilere ayırın. Örneğin
foo --help
foo --help option_name
Uzun seçenek yok
Hatırlamak çok daha kolaydır foo --attach_to [argument] --volatile --verbosehatırlaması daha foo -a [arg] -v +V. Bu her zaman mümkün değildir, ancak çoğu durumda bu mümkündür.
Giriş doğrulaması yok
Hemen hemen her platformda, argümanların ayrıştırılması ve doğrulanması söz konusu olduğunda denenmiş, test edilmiş ve doğru olan birden fazla kütüphane vardır. Hemen hemen her platformda bir CLI'den girişi doğrulayan denenmiş, test edilmiş ve gerçek bir lexer vardır. Birini, diğerini veya her ikisini kullanın. Programınız, bir kullanıcının sağladığı bir şey nedeniyle sıfıra bölünürse veya bölünürse, bu sadece utanç vericidir.
Bir lexer kadar karmaşık bir şeye ihtiyacınız olmayabilir, belki de belirli yerlerde belirli şeylerle belirli bir sırada bir şeyler bekliyorsanız, dizeyi tokenize edebilirsiniz.
Aslında bir kez tamsayı bekleniyordu ve biri f*** my lifetırnak yazdı bir hata raporu var . O programı yazmadım, miras alma konusunda talihsizlik yaşadım.
'Verbocity' düğmesi yok
Deneyimli kullanıcıların, programınızdan çoğu insanın tolere edebileceğinden daha fazla gürültü elde etmeyi kolayca keşfetmesine izin verin, ancak varsayılan olarak yalnızca ciddi ve kritik şeyleri yazdırır. straceSadece bir şeyin NULL dosya akışında çalıştığı için segfaulted olduğunu fark etmek için kaç kez ateşlemem gerektiğini söyleyemem .
Ayrıca iddiaları NDEBUG veya başka yollarla kapatmak, kullanıcının bulması için yazdırılmış veya günlüğe kaydedilmiş bir şeyle sonuçlanacak şekilde sarabilirsiniz.
Günlük dosyalarından bahsetmişken, onlara yerleştirdiğiniz her şeyin sizden başka biri için (en azından biraz) mantıklı olduğundan emin olun. Her girişin başlangıcı UNIX çağ tarihi ise, hatayı yeniden oluşturmanıza gerçekten yardımcı olmak isteyen bir kişide hayal kırıklığını artıracaksınız.
Hata ayıklama modunda 'hata arkadaşı' yok
Birçok program, programda neler olup bittiğine dair ekstra sohbet sağlayan bir çeşit 'hata ayıklama' anahtarı sunar, ancak çok azı aşağıdakileri sunar:
Ya da belki de insanların aşağıdakileri telefonda okuduğunu duymaktan hoşlanıyorsunuz:
Sıfır eff'de beklenmedik bir durum var oh dört sıfır oh .... Tamam, bunu size geri okudum ...
Aşırı karmaşık yapılandırma dosyaları
Bir dizi sözdizimsel şekeri canlandırmak için bir yapılandırmayı bir bahane olarak ayrıştırma ihtiyacını haklı çıkarmayın. Ayrıştırma sırasında fazladan çalışma anlamına gelse bile, insanların gerçekten bildiği bir biçimi kullanmaya çalışın. INI stil biçimini mümkün olduğunca kullanmaya çalışıyorum. Basit bir anahtar-> değer sözlüğü ile neler yapabileceğinize şaşıracaksınız.
Yapılandırma dosyası yok
Her iki görev için de bir araç olması amaçlanmadıysa, insanların yalnızca programınızı kullanmaları için kabuk komut dosyaları veya toplu dosyalar yazmalarına izin vermeyin. Bana her zamanki seçeneklerimi içeren bir dosyaya işaret etmem ve birkaç ek argüman sunmam için bir araç ver.
'Islak zemin' işareti yok
Bazı özellikler kullanıcıyı rahatsız edebilirse (belki de ileri düzey kullanıcılar için oradadır), açıkça bu şekilde işaretleyin. Ayrıca, birisi şişman parmaklar bir şey girerse veya unutursa, çevrimiçi belgelere çok kolay bir bağlantı yazdırmayı programladınız mı? Programınızı KVM aracılığıyla kullanan ve kesip yapıştıramayan biriyle uğraşıyor olabilirsiniz.
Mümkün olduğunda (bu, giriş doğrulamasıyla çakışır) Google uygulamasını kullanın:
Şunu mu demek istedin foo --bar FILENME, sadece foo --bar yazdınız
Yıkıcı talimatlardan bir çıkış yolu sun
Amaç, kullanıcıya neden işe yaramadığını ve birkaç kez daha denemelerini sağlamaktır. Örneğin, 'nagging'i kapatan bir anahtara izin verin -Yveya /Ybaşka türlü basitçe' şişman parmakları 'olan biri için bir çıkış yoluna izin verin.
Muhtemelen birkaç şey unutuyorum. Çoğu insanın hata yapmasını önleyebilecek kadar sezgisel bir şey için 'düşük seviye' arayüzünü yapmak çok, çok zor olduğu için sık sık ilgileniyorum.
Msgstr "Bu dosyayı / kaydı silmek istediğinizden emin misiniz? Evet / Hayır". Evet'i tıklattıktan sonra "yanlışlıkla" kırmızı sil düğmesini tıkladığını ve bu verilere geri ihtiyacı olduğunu belirten bir çağrı aldım :)
Belirli bir mola / düzeltme örnekleri almak gibi bunu gerçekleştirmek kadar önemli değil gibi hissediyorum:
Eğer bu keşif yoluyla bir şeyleri kırarlarsa, bir programcı olarak onları tehlikeye karşı uyarmak veya ilk etapta olmasını önlemek sizin görevinizdir. Şimdi nerede gördüğümü hatırlayamıyorum, ama aklımın arkasında her zaman yazılımımın kullanıcısı için " doğru olanı kolaylaştırmayı " deniyorum .
Örneklerde ısrar ediyorsanız:
Bunun nereye gittiğini görüyor musunuz? :)
İşte bu hafta duyduğum. Bir kullanıcı "olay gerçekleştiğinde bana bildirim gönder" özelliğini ister. Yeterince basit ve geliştirici devam eder ve uygular. Elbette, ilk soru "bu bildirimle neyi ele almaya çalışıyoruz?" Olmalıdır. Buna girmeyeceğim. Birkaç gün sonra kullanıcı geliştirici tarafından durdurulur ve "Bu bildirimi aldım. Bununla ne yapmam gerekiyor?" Diye sorar.
Bu Dilbert çizgi romanını hatırladım ve geliştiriciye "kullanıcının bu bildirimle ne yapması gerektiğini anlamak için bir uygulama yazın" ı önerdim.
Mpeterson'un dediği gibi, kullanıcı kendi uzmanlık alanında çok rekabetçi. Sadece bir yazılım geliştiricisi ya da tasarımcısı gibi düşünmüyorlar.
Kullanıcıların aptal olduğunu düşünmüyorum. Sizin veya herhangi bir programı kullanmak istemiyorlar. Tek istedikleri şeylerini yapmak. Onlara yardım et ve yol boyunca onlara zarar gelmesini önle.
İyi bir kullanıcı arayüzüne sahip olmak ve yeterli bir öğrenme deneyimi sağlamak, kullanıcıların kötü şeyler yapmasını önlemeye doğru uzun bir yol kat eder.
İyi kullanıcı arayüzleri sürtünmesiz olmalıdır.
Bir silme işlemini onaylamak, silme işlemini gerçekleştirmek ve geri almanın bir yolunu sunmak için bir iletişim kutusu (pahalı bir işlem ve kullanıcıların bir süre sonra yok saydığı bir işlem) açmak yerine.
İyi kullanıcı arayüzleri bulunabilir olmalıdır.
Microsoft Office'teki şerit, Word'ün eski kullanıcılarını yollarını değiştirmeye zorladığı için çok fazla plak alsa da, şerit bir arabirimi nasıl keşfedilebilir (yani kolay keşfedilebilir) haline getirebileceğinizin parlak bir örneğidir.
İyi kod gibi iyi kullanıcı arayüzleri açıklayıcı olmalıdır.
Kimse kılavuzu okumuyor. Kullanıcılarımı okumak için tek elim, yazılımın adım adım izlenecek yollarını içeren bir PowerPoint sunumuydu. Bunların Camtasia gibi video araçlarıyla yapıldığını gördüm, ancak PowerPoints daha iyi çünkü adımlar arasında kolayca geri ve ileri gidebilirsiniz.
Kullanıcı hata yapmaz. Hatalar, kullanılabilir bir arayüz oluşturamayan programcıda yatmaktadır.
Her sürümde kullanılabilirlik testleri de öyle!