Windows 7'de Hata İletileri

Windows 7'deki hata iletileri, kullanıcıları zaten oluşan sorunlarla ilgili uyarır. Buna karşılık, uyarı iletileri gelecekte sorunlara neden olabilecek koşullar için kullanıcıları uyarır. Hata iletileri kalıcı iletişim kutuları, yerinde iletiler, bildirimler veya balonlar kullanılarak sunulabilir.

Hata iletisinin yeniden adlandırılamıyor

Tipik bir kalıcı hata iletisi.

Etkili hata iletileri, kullanıcılara bir sorunun oluştuğu hakkında bilgi verir, sorunun nedenini açıklar ve kullanıcıların sorunu çözebilmesi için bir çözüm sağlar. Kullanıcılar bir eylem gerçekleştirmeli veya hata iletisinin sonucu olarak davranışlarını değiştirmelidir.

İyi yazılmış, yararlı hata iletileri kaliteli bir kullanıcı deneyimi için çok önemlidir. Kötü yazılmış hata iletileri, düşük ürün memnuniyetine neden olur ve önlenebilir teknik destek maliyetlerinin önde gelen nedenidir. Gereksiz hata iletileri kullanıcıların akışını bozar.

Not: iletişim kutularıyla ilgili Yönergeleri, uyarı iletileri, onaylar, standart simgeler, bildirimleri ve düzen ayrı makalelerde sunulmuştur.

Bu doğru kullanıcı arabirimi mi?

Karar vermek için şu soruları göz önünde bulundurun:

• Kullanıcı arabirimi (UI) zaten oluşmuş bir sorun mu sunuyor? Aksi takdirde, ileti bir hata değildir. İleride soruna neden olabilecek bir koşulla ilgili uyarı alan kullanıcı bir uyarı iletisi kullanın.
• Sorun karışıklığa neden olmadan önlenebilir mi? Öyleyse, bunun yerine sorunu önleyin. Örneğin, hata iletileri gerektirebilecek kısıtlanmamış denetimleri kullanmak yerine geçerli değerlerle kısıtlanmış denetimleri kullanın. Ayrıca, tıklandığında denetimleri devre dışı bırakmak, denetimin neden devre dışı bırakıldığından belli olduğu sürece hataya neden olur.
• Sorun otomatik olarak düzeltilebilir mi? Öyleyse, sorunu işleyip hata iletisini gizleyin.
• Kullanıcıların iletinin sonucu olarak bir eylem gerçekleştirme veya davranışlarını değiştirme olasılığı var mı? Aksi takdirde, koşul kullanıcının kesintiye uğrayabilmesini haklı çıkarmaz, bu nedenle hatayı gizleme daha iyi olur.
• Kullanıcılar diğer programları etkin bir şekilde kullanırken sorun ilgili mi? Öyleyse, bildirim alanı simgesinikullanarak sorunu göstermeyi göz önünde bulundurun.
• Sorun geçerli kullanıcı etkinliğiyle ilgili değil mi, hemen kullanıcı eylemi gerektirmez mi ve kullanıcılar bunu serbestçe yoksayabilir mi? Öyleyse, bunun yerine eylem hatası bildirimi kullanın.
• Sorun, birincil pencere içindeki bir arka plan görevinin durumuyla ilgili mi? Öyleyse, durum çubuklarını kullanarak sorunu göstermeyi göz önünde bulundurun.
• Birincil hedef kullanıcılar BT uzmanları mı? Bu durumda, günlük dosyası girdileri veya e-posta uyarıları gibi alternatif bir geri bildirim mekanizması kullanmayı göz önünde bulundurun. BT uzmanları kritik olmayan bilgiler için günlük dosyalarını tercih eder.

Tasarım kavramları

Kötü hata iletilerinin özellikleri

Çok sayıda can sıkıcı, yararlı olmayan ve kötü yazılmış hata iletisi olması şaşırtıcı olmamalıdır. Hata iletileri genellikle kalıcı iletişim kutuları kullanılarak sunulduğundan, kullanıcının devam etmesi için izin vermeden önce kullanıcının geçerli etkinliğini ve kabul edilme talebini kesintiye uğratır.

Sorunun bir kısmı, bunu yanlış yapmanın birçok yolu olmasıdır. Utanç Hata İletisi Salonu'ndan şu örnekleri göz önünde bulundurun:

Gereksiz hata iletileri

yanlış :

Hata iletisinin

Windows XP'den alınan bu örnek, şimdiye kadarki en kötü hata iletisi olabilir. Windows'un kendisi kapatılma sürecinde olduğundan bir programın başlatılamadığını gösterir. Kullanıcının bu konuda yapabilecekleri ve hatta bu konuda yapmak istediği bir şey yoktur (sonuçta kullanıcı Windows'ı kapatmayı seçti). Windows, bu hata iletisini görüntüleyerek kapanmasını engelliyor!

Sorun: Sorun, hata iletisinin kendisidir. Hata iletisini kapatmanın yanı sıra, kullanıcıların yapması gereken bir şey yoktur.

Önde gelen neden: Kullanıcıların hedeflerine veya bakış açısına bakılmaksızın tüm hata olaylarını raporlama.

önerilen alternatif : Kullanıcıların önemsemediğini hataları bildirmeyin.

"Başarılı" hata iletilerini

yanlış :

Hata iletisinin

Bu hata iletisi, kullanıcının program kaldırıldıktan hemen sonra Windows'un yeniden başlatılmaması seçeneğini belirlemesinden kaynaklandı. Program kaldırma işlemi kullanıcının bakış açısından başarılı oldu.

Sorun: Kullanıcının bakış açısından hata yok. Hata iletisini kapatmanın yanı sıra, kullanıcıların yapması gereken bir şey yoktur.

Baştaki neden: Görev kullanıcının bakış açısından başarıyla tamamlandı, ancak kaldırma programının bakış açısından başarısız oldu.

Önerilen alternatif: Kullanıcıların kabul edilebilir kabul edilebilir olarak kabul edilen koşullar için hataları bildirmeyin.

Tamamen işe yaramaz hata iletileri

yanlış :

Hata iletisinin

Kullanıcılar bir hata olduğunu öğrenir, ancak hatanın ne olduğu veya bu konuda ne yapacağı hakkında hiçbir fikri yoktur. Ve hayır, sorun değil!

Sorun: Hata iletisi belirli bir soruna neden olmaz ve kullanıcıların bu konuda hiçbir şey yapamaz.

Önde gelen neden: Büyük olasılıkla programın hatalı hata işlemesi vardır.

Önerilen alternatif: Programda iyi hata işleme tasarımı.

Anlaşılmaz hata iletileri

yanlış :

Hata iletisinin

Bu örnekte, sorun deyimi açıktır, ancak ek açıklama tamamen şaşırtıcıdır.

Sorun: Sorun deyimi veya çözümü anlaşılmaz.

Baştaki neden: Sorunun kullanıcının değil kodun bakış açısından açıklanması.

Önerilen alternatif: Hedef kullanıcılarınızın kolayca anlayabileceği hata iletisi metni yazın. Kullanıcıların gerçekten gerçekleştirebileceği çözümler sağlayın. Programınızın hata iletisi deneyimini tasarlayın, programcıların anında hata iletileri oluşturmasını istemez.

aşırı komut veren hata iletileri

yanlış :

son derece ayrıntılı iletiekran görüntüsü

Bu örnekte, hata iletisi görünüşe göre her sorun giderme adımını açıklamaya çalışır.

Sorun: Çok fazla bilgi.

Baştaki neden: Çok fazla ayrıntı verme veya hata iletisi içinde karmaşık bir sorun giderme işlemini açıklamaya çalışma.

Önerilen alternatif: Gereksiz ayrıntılardan kaçının. Ayrıca sorun gidericilerden kaçının. Sorun giderici gerekiyorsa, en olası çözümlere odaklanın ve Yardım'da uygun konuya bağlanarak geri kalanı açıklayın.

Gereksiz derecede zorlu hata iletileri

yanlış :

İletinin bulunamıyor

Programın bir nesneyi bulamıyor olması pek de yıkıcı bir şey değil. Ve bunun yıkıcı olduğunu varsayarsak, yanıt neden Tamam?

Sorun: Programın tonu gereksiz yere sert veya dramatiktir.

Baştaki neden: Sorun, programın bakış açısından yıkıcı görünen bir hatadan kaynaklanır.

Önerilen alternatif: Kullanıcının bakış açısına göre dili dikkatle seçin.

Kullanıcıları suçlayan hata iletileri

yanlış :

İletinin

Neden kullanıcıların kendilerini suçlu gibi hissetmesini sağlayasın?

Sorun: Hata iletisi, kullanıcıyı hata yapmakla suçlayan bir şekilde ifade edilir.

Başındaki neden: Sorun yerine kullanıcının davranışına odaklanan duyarsız ifade.

Önerilen alternatif: Soruna yol açan kullanıcı eylemine değil, pasif sesi gerektiği gibi kullanmaya odaklanın.

Aptal hata iletileri

yanlış :

İletinin

Bu örnekte, sorun deyimi oldukça ironiktir ve hiçbir çözüm sağlanmadı.

Sorun: Aptalca veya eşit olmayan hata iletisi deyimleri.

Baştaki neden: Bağlamlarına dikkat etmeden hata iletileri oluşturma.

Önerilen alternatif: Hata iletilerinizin bir yazar tarafından hazırlanmış ve gözden geçirilmiş olması. Hataları gözden geçirirken bağlamı ve kullanıcının düşünce durumunu göz önünde bulundurun.

Programcı hata iletilerini

yanlış :

İletinin

Bu örnekte, hata iletisi programda bir hata olduğunu gösterir. Bu hata iletisinin yalnızca programcı için anlamı vardır.

Sorun: Program geliştiricilerinin hataları bulmasına yardımcı olmak için tasarlanan iletiler programın yayın sürümünde bırakılır. Bu hata iletilerinin kullanıcılar için bir anlamı veya değeri yoktur.

Baştaki neden: Kendilerine ileti göndermek için normal kullanıcı arabirimi kullanan programcılar.

Önerilen alternatif: Geliştiricilerin, bir ürünün yayın sürümünden otomatik olarak kaldırılmaları için bu tür tüm iletileri koşullu olarak derlemesi gerekir. Tek hedef kitleleri programcılar olduğundan, kullanıcılar için bu gibi hataların anlaşılması için zaman kaybetmeyin.

Kötü gösterilen hata iletileri

yanlış :

İletinin

Bu örnekte birçok yaygın sunu hatası vardır.

Sorun: Hata iletisi sunusunda tüm ayrıntıları yanlış alma.

Baştaki neden: Hata iletisi yönergelerini bilmeme ve uygulama. Hata iletilerini oluşturmak ve gözden geçirmek için yazıcıları ve düzenleyicileri kullanmama.

Hata işlemenin doğası gereği, bu hataların birçoğunun yapılması çok kolaydır. Hata iletilerinin çoğunun Utanç Salonu'na aday olabileceğini fark etmek rahatsız edici.

İyi hata iletilerinin özellikleri

Önceki kötü örneklerin aksine, iyi hata iletileri şunlardır:

• Bir sorun var. Bir sorunun oluştuğu durumdur.
• Bir nedeni var. Sorunun neden oluştuğu açıklanır.
• Bir çözüm. Kullanıcıların sorunu çözebilmesi için bir çözüm sağlar.

Ayrıca, iyi hata iletileri şu şekilde sunulur:

• Alakalı. İleti, kullanıcıların önemseyebilecekleri bir sorun sunar.
• Dava. Kullanıcılar bir eylem gerçekleştirmeli veya iletinin sonucu olarak davranışlarını değiştirmelidir.
• Kullanıcı merkezli. İleti, sorunu kodun nelerden memnun olmadığı açısından değil, hedef kullanıcı eylemleri veya hedefleri açısından açıklar.
• Kısa. İleti mümkün olduğunca kısadır, ancak daha kısa değildir.
• Berrak. İleti, hedef kullanıcıların sorunu ve çözümü kolayca anlayabilmesi için düz dil kullanır.
• Spesifik. İletide, belirli dil kullanılarak ilgili nesnelerin belirli adları, konumları ve değerleri vererek sorun açıklanır.
• Nazik. Kullanıcılar suçlanmamalı veya kendilerini aptal hissetmemelidir.
• Nadir. Seyrek görüntülenir. Sık görüntülenen hata iletileri, hatalı tasarımın işaretidir.

Hata işleme deneyiminizi bu özelliklere sahip olacak şekilde tasarlayarak, programınızın hata iletilerini Hata İletisi Utanç Salonu'nun dışında tutabilirsiniz.

Gereksiz hata iletilerinden kaçınma

Genellikle en iyi hata iletisi hata iletisi değildir. Daha iyi tasarım sayesinde birçok hata önlenebilir ve hata iletilerine genellikle daha iyi alternatifler vardır. Bir hatayı önlemek, genellikle bir hata bildirmekten daha iyidir.

Kaçınılması gereken en belirgin hata iletileri, eyleme dönüştürülemeyen iletilerdir. Kullanıcıların hiçbir şey yapmadan veya değiştirmeden iletiyi kapatma olasılığı varsa, hata iletisini atlayın.

Bazı hata iletileri kullanıcının bakış açısından sorun olmadığından ortadan kaldırılabilir. Örneğin, kullanıcının zaten silinme sürecinde olan bir dosyayı silmeye çalıştığını varsayalım. Bu durum kodun bakış açısından beklenmeyen bir durum olsa da, istenen sonuca ulaşıldığı için kullanıcılar bu hatayı dikkate almaz.

yanlış :

İletinin silinemiyor

Eylem kullanıcının bakış açısından başarılı olduğundan bu hata iletisi ortadan kaldırılmalıdır.

Başka bir örnek için, kullanıcının bir görevi açıkça iptal etti olduğunu varsayalım. Kullanıcının bakış açısından aşağıdaki koşul bir hata değildir.

yanlış :

İletinin tamamlanamadı

Eylem kullanıcının bakış açısından başarılı olduğundan bu hata iletisi de ortadan kaldırılmalıdır.

Bazen hata iletileri teknoloji yerine kullanıcıların hedeflerine odaklanılarak ortadan kaldırılabilir. Bunu yaparken, bir hatanın gerçekte ne olduğunu yeniden düşünün. Sorun kullanıcının hedefleriyle mi yoksa programınızın bunları karşılama becerisiyle mi ilgili? Kullanıcının eylemi gerçek dünyada anlamlıysa, yazılımda da anlamlı olmalıdır.

Örneğin, bir e-ticaret programında kullanıcının aramayı kullanarak bir ürün bulmaya çalıştığını, ancak değişmez değer arama sorgusunda eşleşme olmadığını ve istenen ürünün stokta olmadığını varsayalım. Teknik olarak bu bir hatadır, ancak hata iletisi vermek yerine program şunları yapabilir:

• Sorguyla en yakın eşleşen ürünleri aramaya devam edin.
• Aramada belirgin hatalar varsa, otomatik olarak düzeltilmiş bir sorgu önerin.
• Yazım hataları, alternatif yazımlar ve çoğullaştırma ve fiil durumlarıyla uyuşmazlık gibi yaygın sorunları otomatik olarak işleyebilir.
• Ürünün ne zaman stokta olacağını belirtin.

Kullanıcının isteği makul olduğu sürece iyi tasarlanmış bir e-ticaret programı hata değil makul sonuçlar döndürmelidir.

Hata iletilerinden kaçınmanın bir diğer harika yolu da ilk etapta sorunları önlemektir. Hataları şu şekilde önleyebilirsiniz:

• Kısıtlanmış denetimleri kullanma. Geçerli değerlerle kısıtlanmış denetimleri kullanın. Listeler, kaydırıcılar, onay kutuları, radyo düğmeleri ve tarih ve saat seçiciler gibi denetimler geçerli değerlerle kısıtlanırken, metin kutuları genellikle değildir ve hata iletileri gerektirebilir. Ancak, metin kutularını yalnızca belirli karakterleri kabul etmek ve en fazla karakter sayısını kabul etmek için kısıtlayabilirsiniz.
• Kısıtlanmış etkileşimleri kullanma. Sürükleme işlemleri için kullanıcıların yalnızca geçerli hedeflere bırakmasına izin verin.
• Devre dışı bırakılmış denetimleri ve menü öğelerini kullanma. Kullanıcılar denetimin veya menü öğesinin neden devre dışı bırakılıp devre dışı bırakılıp devre dışı bırakılana kadar denetimleri ve menü öğelerini devre dışı bırakın.
• İyi varsayılan değerler sağlar. Varsayılan değerleri kabul eden kullanıcıların giriş hataları yapma olasılığı daha düşüktür. Kullanıcılar değeri değiştirmeye karar verse bile, varsayılan değer kullanıcıların beklenen giriş biçimini bilmesini sağlar.
• İşlerin yürümesi için. Görevler gereksizse veya onlar için otomatik olarak gerçekleştiriliyorsa kullanıcıların hata yapma olasılığı daha düşüktür. Ya da kullanıcılar küçük hatalar yaparsa ancak niyetleri netse, sorun otomatik olarak düzeltilir. Örneğin, küçük biçimlendirme sorunlarını otomatik olarak düzeltebilirsiniz.

Gerekli hata iletilerini sağlama

Bazen gerçekten bir hata iletisi sağlamanız gerekir. Kullanıcılar hata yapar, ağlar ve cihazlar çalışmayı durdurur, nesneler bulunamaz veya değiştirilemez, görevler tamamlanamaz ve programlarda hatalar olur. İdeal olarak, bu sorunlar daha az sık meydana gelebilir, örneğin, yazılımımızı birçok kullanıcı hatasını önleyecek şekilde tasarlayabiliriz, ancak bu sorunların tümünü önlemek gerçekçi değildir. Bu sorunlardan biri oluştuğunda, yararlı bir hata iletisi kullanıcıların hızla yeniden ayağa kaldırmasını sağlar.

Yaygın bir inanç, hata iletilerinin en kötü kullanıcı deneyimi olduğu ve ne pahasına olursa olsun kaçınılması gerektiğidir, ancak kullanıcı karışıklığının en kötü deneyim olduğunu ve ne pahasına olursa olsun kaçınılması gerektiğini söylemek daha doğru olur. Bazen bu maliyet yararlı bir hata iletisidir.

Devre dışı bırakılmış denetimleri göz önünde bulundurun. Çoğu zaman, denetimin neden devre dışı bırakılmıştır, bu nedenle denetimi devre dışı bırakmak hata iletisinden kaçınmanın harika bir yoludur. Öte yandan bir denetimin devre dışı bırakılmasının nedeni açık değilse ne olur? Kullanıcı devam edebilir ve sorunu belirlemek için geri bildirimde bulunmaz. Şimdi kullanıcı takıldı ve sorunu çözmesi veya teknik destek alması gerekiyor. Böyle durumlarda, denetimi etkin bırakmak ve bunun yerine yararlı bir hata iletisi vermek çok daha iyidir.

yanlış :

İletinin ekran görüntüsü

İleri düğmesi neden devre dışı bırakıldı? Yararlı bir hata iletisi vererek etkin bırakmak ve kullanıcı karışıklığını önlemek daha iyidir.

Hata iletisi vermeniz gerekip gerekmediğinden emin değilseniz, verebileceğini hata iletisini oluşturarak başlayın. Kullanıcıların bir eylem gerçekleştirme veya sonuç olarak davranışlarını değiştirme olasılığı varsa hata iletisini sağlayın. Buna karşılık, kullanıcıların hiçbir şey yapmadan veya değiştirmeden iletiyi kapatma olasılığı varsa, hata iletisini atlayın.

İyi hata işleme için tasarlama

İyi hata iletisi metni oluşturmak zor olsa da, bazen programdan iyi hata işleme desteği olmadan imkansızdır. Şu hata iletisini göz önünde bulundurun:

yanlış :

İletinin

Büyük olasılıkla, programın hata işleme desteği eksik olduğundan sorun gerçekten bilinmiyor.

Bunun çok kötü yazılmış bir hata iletisi olması mümkün olsa da, büyük olasılıkla temel alınan kod tarafından iyi hata işleme eksikliğini yansıtır ve sorun hakkında bilinen belirli bir bilgi yoktur.

Belirli, eyleme dönüştürülebilir, kullanıcı merkezli hata iletileri oluşturmak için programınızın hata işleme kodu belirli, üst düzey hata bilgileri sağlamalıdır:

• Her soruna benzersiz bir hata kodu atanmış olmalıdır.
• Bir sorunun çeşitli nedenleri varsa, program mümkün olduğunda belirli bir nedeni belirlemelidir.
• Sorunda parametreler varsa, parametrelerin korunması gerekir.
• Düşük düzeyli sorunlar, hata iletisinin kullanıcının bakış açısından sunulabilmesi için yeterince yüksek düzeyde ele alınmalıdır.

İyi hata iletileri yalnızca bir kullanıcı arabirimi sorunu değil, bir yazılım tasarımı sorunudur. İyi bir hata iletisi deneyimi, daha sonra düzeltilecek bir şey değildir.

Sorun Giderme (ve bundan kaçınma)

Birkaç farklı nedeni olan bir sorun tek bir hata iletisiyle bildirildiğinde sorun giderme sonuçları.

yanlış :

diyagramı

Doğru:

Herdiyagramı

Tek bir hata iletisiyle çeşitli sorunlar bildirildiğinde sorun giderme sonuçları.

Aşağıdaki örnekte, bir öğe zaten taşındığından veya silindiğinden veya erişim reddedildiğinden taşınamadı. Program nedeni kolayca saptayabiliyorsa, neden belirli bir nedeni belirlemek için kullanıcıya yük bindirin?

yanlış :

İki nedeninekran görüntüsü

Peki, hangisi? Artık kullanıcının sorun gidermesi gerekiyor.

Program, erişimin reddedilip reddedilmediğini belirleyebilir, bu nedenle bu sorun belirli bir hata iletisiyle bildirilmelidir.

Doğru:

belirten iletinin ekran görüntüsü

Belirli bir nedenle sorun giderme gerekmez.

Birden çok nedeni olan iletileri yalnızca belirli bir neden belirlenemediğinde kullanın. Bu örnekte, programın öğenin taşınıp taşınmadığını veya silindiğini saptaması zor olacağından, burada birden çok nedeni olan tek bir hata iletisi kullanılabilir. Ancak, örneğin kullanıcıların silinmiş bir dosyayı taşıyamayacaklarını önemsemeleri pek olası değildir. Bu nedenler için hata iletisi bile gerekli değildir.

Bilinmeyen hataları işleme

Bazı durumlarda sorunu, nedeni veya çözümü gerçekten bilmezsiniz. Hatayı bastırmak akıllıca olmayacaksa, doğru olmayabilecek sorunları, nedenleri veya çözümleri sunmaktansa, bilgi eksikliği konusunda önde olmak daha iyidir.

Örneğin, programınızın işlenmeyen bir özel durumu varsa, aşağıdaki hata iletisi uygundur:

İletinin

Bilinmeyen bir hatayı gizleyemiyorsanız, bilgi eksikliği konusunda önde olmanız daha iyidir.

Öte yandan, çoğu zaman yararlı olabilecek belirli, eyleme dönüştürülebilir bilgiler sağlayın.

Bu hata iletisi, genellikle sorun ağ bağlantısıysa bilinmeyen bir hata için uygundur.

uygun ileti türünü belirleme

Bazı sorunlar, vurgu ve ifadeye bağlı olarak hata, uyarı veya bilgi olarak sunulabilir. Örneğin, bir Web sayfasının geçerli Windows Internet Explorer yapılandırmasına bağlı olarak imzalanmamış bir ActiveX denetimini yükleyemeyeceğini varsayalım:

• Hata. "Bu sayfa imzalanmamış bir ActiveX denetimi yükleyemez." (Mevcut bir sorun olarak ifade edilir.)
• Uyarı. "Windows Internet Explorer imzasız ActiveX denetimlerini yükleyecek şekilde yapılandırılmadığından bu sayfa beklendiği gibi davranmayabilir." veya "Bu sayfanın imzasız bir ActiveX Denetimi yüklemesine izin verilsin mi? Güvenilmeyen kaynaklardan bunu yapmak bilgisayarınıza zarar verebilir." (Her ikisi de gelecekteki sorunlara neden olabilecek koşullar olarak ifade edilir.)
• Bilgi. "Windows Internet Explorer'ı imzalanmamış ActiveX denetimlerini engelleyecek şekilde yapılandırmışsınız." (Olgu ifadesi olarak ifade edilir.)

Uygun ileti türünü belirlemek için, sorunun kullanıcıların bilmesi veya üzerinde işlem görmesi gereken en önemli yönüne odaklanın. Genellikle, bir sorun kullanıcının ilerlemesini engelliyorsa, bunu bir hata olarak sunmanız gerekir; kullanıcı devam edebilirse, bunu bir uyarı olarak sunun. ana yönergesini veya ilgili diğer metni o odak temelinde hazırlayın, ardından metinle eşleşen bir simge (standartveya başka bir) seçin. Ana yönerge metni ve simgeleri her zaman eşleşmelidir.

Hata iletisi sunusu

Windows programlarındaki hata iletilerinin çoğu kalıcı iletişim kutuları kullanılarak sunulur (bu makaledeki örneklerin çoğu gibi) ancak başka seçenekler de vardır:

• Yerinde
• Balon
• Bildirim
• Bildirim alanı simgeleri
• Durum çubukları
• Günlük dosyaları (BT uzmanlarını hedefleyen hatalar için)

Hata iletilerini kalıcı iletişim kutularına yerleştirmek, kullanıcının hemen ilgilenmesini ve onayını isteme avantajına sahiptir. Ancak, bu dikkat gerekli değilse, bu onların da birincil dezavantajıdır.

İletinin ne yaptığınızı durdurun

Kapat düğmesine tıklayabilmeleri için gerçekten kullanıcıları kesintiye uğratmanız mı gerekiyor? Aksi takdirde, kalıcı iletişim kutusu kullanmanın alternatiflerini göz önünde bulundurun.

Kalıcı iletişim kutuları, kullanıcının devam etmeden önce sorunu hemen kabul etmesi gerektiğinde harika bir seçimdir, ancak aksi takdirde genellikle kötü bir seçimdir. Genel olarak, işi iyi bir şekilde yerine getiren en hafif sunuyu kullanmayı tercih etmelisiniz.

Fazla engellemekten kaçının

Genel olarak, kullanıcılar okumazsatararlar. Ne kadar çok metin varsa, metni taramak o kadar zor olur ve kullanıcılar metni okumama olasılığı o kadar artar. Sonuç olarak, metni temel bileşenlerine indirgemek ve ek bilgi sağlamak için gerektiğinde aşamalı açıklama ve Yardım bağlantılarını kullanmak önemlidir.

Birçok aşırı örnek vardır, ancak bir tipik örneğe daha göz atalım. Aşağıdaki örnekte iyi bir hata iletisinin özniteliklerinin çoğu vardır, ancak metni kısa değildir ve okumak için motivasyon gerektirir.

yanlış :

Ayrıntılı ileti

Bu örnek iyi bir hata iletisidir, ancak fazla yaygın olarak kullanılır.

Bu metin gerçekten ne diyor? Şuna benzer bir şey:

Doğru:

İletinin

Bu hata iletisi temelde aynı bilgilere sahiptir, ancak çok daha kısadır.

Ayrıntıları sağlamak için Yardım'ı kullanarak bu hata iletisinde sununun ters piramit stili var.

Fazla iletişim hakkında daha fazla yönerge ve örnek için bkz. Kullanıcı Arabirimi Metni.

yalnızca sekiz şey yaparsanız

1. Programınızı hata işleme için tasarlar.
2. Gereksiz hata iletileri vermeyin.
3. Gerekli hata iletilerini vererek kullanıcı karışıklığını önle.
4. Hata iletisinin bir sorun, neden ve çözüm sağladığından emin olun.
5. Hata iletisinin ilgili, eyleme dönüştürülebilir, kısa, net, belirli, nazik ve nadir olduğundan emin olun.
6. Hata iletilerini programın bakış açısından değil, kullanıcının bakış açısından tasarlar.
7. Kullanıcıyı sorun gidermeye dahil etmekten kaçının, algılanabilir her neden için farklı bir hata iletisi kullanın.
8. İşi iyi bir şekilde tamamlayan en hafif sunu yöntemini kullanın.

kullanım desenlerini

Hata iletilerinin çeşitli kullanım desenleri vardır:

Etiket	Değer
Sistem sorunları İşletim sistemi, donanım cihazı, ağ veya program başarısız oldu veya bir görevi gerçekleştirmek için gereken durumda değil.	Birçok sistem sorunu kullanıcı tarafından çözülebilir: Cihaz sorunları cihazı açarak, cihazı yeniden bağlayarak ve medya ekleyerek çözülebilir. Ağ sorunları fiziksel ağ bağlantısı denetlenerek ve Ağ tanılama ve onarımçalıştırılarak çözülebilir. Program seçenekleri değiştirilerek veya program yeniden başlatılarak program sorunları çözülebilir. Bu örnekte, program bir kullanıcı görevini gerçekleştirmek için bir kamera bulamıyor. Bu örnekte, bir görevi gerçekleştirmek için gereken bir özelliğin açık olması gerekir.
Dosya sorunları Kullanıcı tarafından başlatılan bir görev için gereken dosya veya klasör bulunamadı, zaten kullanılıyor veya beklenen biçime sahip değil.	silinemiyor Bu örnekte, dosya veya klasör bulunamadığından silinemiyor. yürütülemiyor Bu örnekte, program verilen dosya biçimini desteklemez.
Güvenlik sorunları Kullanıcının bir kaynağa erişme izni veya kullanıcı tarafından başlatılan bir görevi gerçekleştirmek için yeterli ayrıcalığı yoktur.	izniniz yok Bu örnekte, kullanıcının bir kaynağa erişme izni yoktur. Bu örnekte, kullanıcının bir görevi gerçekleştirme ayrıcalığı yoktur.
Görev sorunları Kullanıcı tarafından başlatılan bir görevi gerçekleştirirken belirli bir sorun vardır (sistem, dosya bulunamadı, dosya biçimi veya güvenlik sorunu dışında).	yapıştırılamaz Bu örnekte Pano verileri Paint'e yapıştırılamaz. yüklenemiyor Bu örnekte kullanıcı yazılım yükseltmesi yükleyemez.
Kullanıcı giriş sorunları Kullanıcı yanlış veya diğer kullanıcı girişiyle tutarsız bir değer girdi.	Bu örnekte, kullanıcı yanlış bir zaman değeri girdi. Bu örnekte, kullanıcı girişi doğru biçimde değil.

Yönerge -leri

Sunum

• Tutarlı bir görünüm ve düzen elde etmek için uygun görev iletişim kutularını kullanın. Görev iletişim kutuları Windows Vista veya üzerini gerektirdiğinden, windows'un önceki sürümleri için uygun değildir. bir ileti kutusu kullanmanız gerekiyorsa, ana yönergeyi ek yönergeden iki satır sonuyla ayırın.

Kullanıcı girişi hataları

• Mümkün olduğunda, kullanıcı girişi hatalarını şu şekilde engelleyin veya azaltın:
  • Geçerli değerlerle kısıtlanmış denetimleri kullanma.
  • Denetim veya menü öğesinin neden devre dışı bırakıldığından emin olunması durumunda, tıklandığında denetimlerin ve menü öğelerinin devre dışı bırakılması hataya neden olur.
  • İyi varsayılan değerler sağlar.

yanlış :

Konuşmacı ses etiketi

Bu örnekte, kısıtlanmış giriş için kısıtlanmamış bir metin kutusu kullanılır. Bunun yerine kaydırıcı kullanın.

• Bağlamsal kullanıcı girişi sorunları için modeless error handling (yerinde hatalar veya balonlar) kullanın.
• Bir metin kutusundayken veya bir metin kutusunun odağı kaybettiğinde algılanan kritik olmayan, tek noktalı kullanıcı girişi sorunları için balonları kullanın.Balonlar kullanılabilir ekran alanı veya yerinde iletileri görüntülemek için gereken dinamik düzen gerekmez. Aynı anda yalnızca tek bir balon görüntüler. Sorun kritik olmadığından hata simgesi gerekmez. Tıklandığında, sorun çözüldüğünde veya zaman aşımından sonra balonlar kaybolur.

İletinin

Bu örnekte, denetimdeyken bir balon giriş sorununu gösterir.

• Gecikmeli hata algılama için yerinde hatalar kullanın genellikle bir işleme düğmesine tıklayarak bulunan hatalar. (Hemen işlenen ayarlar için yerinde hataları kullanmayın.) Aynı anda birden çok yerinde hata olabilir. Normal metin ve 16x16 piksel hata simgesini kullanarak mümkün olduğunca doğrudan sorunun yanına yerleştirin. Kullanıcı işlemediği ve başka bir hata bulunmadığı sürece yerinde hatalar kaybolmaz.

İletinin

Bu örnekte, işleme düğmesine tıklandığında bulunan bir hata için yerinde hata kullanılır.

• Diğer tüm sorunlar için kalıcı hata işlemeyi (görev iletişim kutuları veya ileti kutuları) kullanın; birden çok denetim içeren veya işleme düğmesine tıklayarak bulunan bağlamsal olmayan veya giriş olmayan hatalar da dahil.
• Kullanıcı girişi sorunu bildirildiğinde, giriş odağını yanlış verilerle ilk denetime ayarlayın. Gerekirse denetimi görünüme kaydırın. Denetim bir metin kutusuysa, içeriğin tamamını seçin. Hata iletisinin neye başvuracağı her zaman açık olmalıdır.
• Yanlış girişi temizlemeyin. Bunun yerine, kullanıcının baştan başlamadan sorunu görebilmesi ve düzeltebilmesi için bırakın.
  • Özel Durumu: Yanlış parolayı ve PIN metin kutularını temizle'yi seçin çünkü kullanıcılar maskelenmiş girişi etkili bir şekilde düzeltemez.

Sorun giderme

• Sorun giderme sorunları oluşturmaktan kaçının. Algılanabilir çeşitli nedenlerle ilgili bir sorunu bildirmek için tek bir hata iletisine güvenmeyin.
• Algılanabilir her neden için farklı bir hata iletisi (genellikle farklı bir ek yönerge) kullanın. Örneğin, bir dosya çeşitli nedenlerle açılamıyorsa, her neden için ayrı bir ek yönerge sağlayın.
• Birden çok nedeni olan bir iletiyi yalnızca belirli bir neden belirlenemiyorsa kullanın. Bu durumda, sorunu çözme olasılığına göre çözümleri sunun. Bunun yapılması, kullanıcıların sorunu daha verimli bir şekilde çözmesine yardımcı olur.

Simge

• Kalıcı hata iletisi iletişim kutularının başlık çubuğu simgeleri yoktur. Başlık çubuğu simgeleri, birincil pencerelerle ikincil pencereler arasında görsel ayrım olarak kullanılır.

• Hata simgesini kullanın. Özel durum:

  • Hata, kalıcı iletişim kutusu veya balon kullanılarak görüntülenen bir kullanıcı girişi sorunuysa simge kullanmayın. Bunu yapmak, Windows'un teşvik edici tonunun bir sayacıdır. Ancak yerinde hata iletileri, hata iletileri olarak açıkça tanımlamak için küçük bir hata simgesi (16x16 piksel) kullanmalıdır.

    İleti yanlış posta biçimi

    İleti bilgisayarı adının çok uzun

    Bu örneklerde kullanıcı giriş sorunları için hata simgeleri gerekmez.

    İleti telefon numarasının yanlış biçimli

    Bu örnekte, bir yerinde hata iletisinin hata iletisi olarak açıkça tanımlayabilmesi için küçük bir hata simgesine ihtiyacı vardır.

• Sorun simge içeren bir özelliğe (kullanıcı girişi sorunu değil) yönelikse, özellik simgesini bir hata katmanıyla kullanabilirsiniz. Bunu yaparsanız hatanın konusu olarak özellik adını da kullanın.

  yürütemiyor

  Bu örnekte özellik simgesinin bir hata katmanı vardır ve özellik hatanın konusudur.

• Hatalar için uyarı simgeleri kullanmayın. Bu genellikle sununun daha az ciddi hissetmesini sağlamak için yapılır. Hatalar uyarı değildir.

  yanlış :

  ekran görüntüsü

  Bu örnekte, hatanın daha az ciddi hissetmesini sağlamak için yanlış bir uyarı simgesi kullanılmıştır.

Diğer yönergeler ve örnekler için bkz. standart simgeler .

Aşamalı açıklama

• Bir hata iletisindeki gelişmiş veya ayrıntılı bilgileri gizlemek için ayrıntıları göster/gizle aşamalı açıklama düğmesini kullanın. Bunun yapılması, tipik kullanım için hata iletisini basitleştirir. Kullanıcılar bulamadığı için gerekli bilgileri gizlemeyin.

İletinin oturum açamıyor

Bu örnekte aşamalı açıklama düğmesi, kullanıcıların isterlerse daha ayrıntılı detaya gitmelerine veya istemedikleri durumlarda kullanıcı arabirimini basitleştirmelerine yardımcı olur.

• Daha fazla ayrıntı yoksa ayrıntıları göster/gizle seçeneğini kullanmayın. Mevcut bilgileri daha ayrıntılı bir biçimde yeniden ifade etmeyin.
• Yardım bilgilerini göstermek için Ayrıntıları Göster/Gizle'yi kullanmayın. Bunun yerine Yardım bağlantılarını kullanın.

Etiketleme yönergeleri için bkz. Aşamalı Açıklama Denetimleri.

Bu iletiyi bir daha gösterme

• Bu seçeneğe ihtiyaç duyan bir hata iletisi varsa hatayı ve sıklığını yeniden gözden geçirin. İyi bir hatanın tüm özelliklerine sahipse (ilgili, eyleme dönüştürülebilir ve seyrek), kullanıcıların bunu gizlemesi mantıklı olmamalıdır.

Diğer yönergeler için bkz. İletişim Kutuları.

Varsayılan değerler

• Varsayılan olarak en güvenli, en az yıkıcı veya en güvenli yanıtı seçin. Güvenlik bir faktör değilse, en olası veya kullanışlı komutu seçin.

Yardım

• Yardım gereksinimini önlemek için hata iletileri tasarla. Normalde, çözümün birkaç adım gerektirmediği sürece kullanıcıların sorunu anlamak ve çözmek için dış metin okumaları gerekmez.
• Yardım içeriğinin ilgili ve yararlı olduğundan emin olun. Bunun yerine hata iletisinin ayrıntılı bir şekilde yeniden ifade edilmesi olmamalıdır; gelecekte sorundan kaçınmanın yolları gibi hata iletisinin kapsamı dışında yararlı bilgiler içermelidir. Yalnızca yapabileceğiniz için Yardım bağlantısı sağlamayın.
• Yardım içeriğine erişmek için belirli, kısa ve ilgili Yardım bağlantılarını kullanın. Bu amaçla komut düğmelerini veya aşamalı açıklamayı kullanmayın.
• Belirli ve eyleme dönüştürülebilir hale getiremezseniz hata iletileri için çevrimiçi Yardım içeriğine bağlantılar sağlamayı göz önünde bulundurun. Bunu yaparak, kullanıcılara program yayımlandıktan sonra güncelleştirebileceğiniz ek bilgiler sağlayabilirsiniz.

Daha fazla yönerge için bkz. yardım .

Hata kodları

• Belirli ve eyleme dönüştürülebilir hale getiremezseniz veya Yardım'dan yararlanabilecekleri hata iletileri için hata kodları sağlamayı da göz önünde bulundurun. Kullanıcılar genellikle ek bilgi için İnternet'de arama yapmak için bu hata kodlarını kullanır.
• Her zaman sorunun ve çözümün metin açıklamasını sağlayın. Bu amaçla yalnızca hata koduna bağlı değildir.

yanlış :

İletinin açılamıyor

Bu örnekte, çözüm metninin yerine bir hata kodu kullanılmıştır.

• Her farklı neden için benzersiz bir hata kodu atayın. Bunu yapmak sorun gidermeyi önler.
• İnternet'te kolayca aranabilen hata kodlarını seçin. 32 bit kodlar kullanıyorsanız, baştaki "0x" ve büyük harf karakterlerle onaltılık bir gösterim kullanın.

Doğru:

1234

0xC0001234

yanlış :

-1

-67113524

• Hata kodlarını görüntülemek için Ayrıntıları Göster/Gizle'yi kullanın. Hata kodu olarak tümcecik: <error code>.

İletinin başlatılamadı

Bu örnekte, daha fazla bilgiden yararlanabilecek bir hata iletisini desteklemek için bir hata kodu kullanılır.

Ses

• Hata iletilerine ses efekti veya bip sesiyle eşlik etmeyin. Bunu yapmak jarring ve gereksizdir.
  • Özel Durumu: Sorun bilgisayarın çalışması için kritik öneme sahipse ve kullanıcının ciddi sonuçları önlemek için hemen işlem yapması gerekiyorsa Kritik Durdurma ses efektini çaldırın.

Metin

Genel

• Yedekli metni kaldırın. Başlıklarda, ana yönergelerde, ek yönergelerde, komut bağlantılarında ve işleme düğmelerinde arayın. Genel olarak, yönergelerde ve etkileşimli denetimlerde tam metin bırakın ve diğer yerlerdeki yedekliliği kaldırın.
• Kullanıcı merkezli açıklamaları kullanın. Sorunu, yazılımın nelerden memnun olmadığı açısından değil, kullanıcı eylemleri veya hedefleri açısından açıklayın. Hedef kullanıcıların anladığı ve kullandığı dili kullanın. Teknik jargon kullanmaktan kaçının.

yanlış :

İletinin

Doğru:

İletinin

Bu örneklerde doğru sürüm kullanıcının dilini konuşurken, yanlış sürüm fazla tekniktir.

• Şu sözcükleri kullanmayın:
  • Hata, hata (bunun yerine sorunu kullanın)
  • Başarısız oldu (bunun yerine kullanamıyor)
  • Geçersiz, geçersiz, hatalı (bunun yerine yanlış kullanın)
  • Durdur, sonlandır, sonlandır (bunun yerine durdur'u kullanın)
  • Yıkıcı, ölümcül (bunun yerine ciddi kullanın)

Bu terimler gereksizdir ve Windows'un teşvik edici tonunun aksinedir. doğru kullanıldığında, hata simgesi sorun olduğunu yeterince gösterir.

yanlış :

İletinin

Doğru:

İletinin

Yanlış örnekte "yıkıcı" ve "hata" terimleri gereksizdir.

• Kullanıcıyı suçlayan veya kullanıcı hatası anlamına gelen ifadeler kullanmayın. Sizi ve ifadenizi kullanmaktan kaçının. Etkin ses genellikle tercih edilirken, kullanıcı konu olduğunda pasif sesi kullanın ve etkin ses kullanıldıysa hata için kendini sorumlu hissedebilir.

yanlış :

Yanlış oturum açmaekran görüntüsü

Doğru:

İletinin

Yanlış örnek, etkin sesi kullanarak kullanıcıyı suçluyor.

• Açık olun. Söz dizimi hatası ve geçersiz işlem gibi belirsiz ifadelerden kaçının. İlgili nesnelerin belirli adlarını, konumlarını ve değerlerini sağlayın.

yanlış :

Dosya bulunamadı.

Disk dolu.

Değer aralık dışında.

Karakter geçersiz.

Cihaz kullanılamıyor.

Bu sorunları belirli adlar, konumlar ve değerlerle çözmek çok daha kolay olacaktır.

• Belirli bir girişimde olası olmayan sorunlar, nedenler veya çözümler vermeyin. Doğru olma olasılığı olmadığı sürece sorun, neden veya çözüm sağlamayın. Örneğin, yanlış olma olasılığı olan bir şey yerine bilinmeyen bir hata oluştuğundan söz etmek daha iyidir.
• Kullanıcıdan rahatsız edici bir şey yapmasının istendiği (bekleme gibi) veya yazılımın bu durumdan sorumlu olduğu durumlar dışında "lütfen" sözcüğünden kaçının.

Doğru:

Windows dosyaları bilgisayarınıza kopyalarken lütfen bekleyin.

• "Üzgünüz" sözcüğünü yalnızca kullanıcı ciddi sorunlara neden olan hata iletilerinde kullanın (örneğin, veri kaybı veya bilgisayarı kullanamama). Sorun programın normal çalışması sırasında oluştuysa (örneğin, kullanıcının bir ağ bağlantısının bulunmasını beklemesi gerekiyorsa) özür dilemeyin.

Doğru:

Ne yazık ki Fabrikam Backup kurtarılamaz bir sorun algıladıysa ve bilgisayarınızdaki dosyaları korumak için kapatıldı.

• Kısa adlarını kullanarak ürünlere bakın. Tam ürün adlarını veya ticari marka simgelerini kullanmayın. Kullanıcılar şirket adını ürünle ilişkilendirmediği sürece şirket adını eklemeyin. Program sürüm numaralarını eklemeyin.

yanlış :

Doğru:

İletinin açılamıyor

Yanlış örnekte tam ürün adları ve ticari marka simgeleri kullanılmıştır.

• Nesne adlarının çevresinde çift tırnak işareti kullanın. Bunu yapmak, metnin ayrıştırılmasını kolaylaştırır ve utanç verici olabilecek ifadeleri önler.
  • Özel Durumu: Tam dosya yolları, URL'ler ve etki alanı adlarının çift tırnak içinde olması gerekmez.

Doğru:

İletinin

Bu örnekte, nesne adı tırnak içinde değilse hata iletisi kafa karıştırıcı olabilir.

• Tümceleri nesne adlarıyla başlatmaktan kaçının. Bunu yapmak genellikle ayrıştırmak zordur.
• Tüm büyük harflerle ünlem işareti veya sözcük kullanmayın. Ünlem işaretleri ve büyük harfler, kullanıcıya bağırıyormuş gibi hissettirir.

Daha fazla yönerge ve örnek için bkz. Style ve Tone.

Başlıkları

• Hatanın kaynaklandığı komutu veya özelliği tanımlamak için başlığı kullanın. Özel durum:
  • Birçok farklı komut tarafından bir hata görüntüleniyorsa, bunun yerine program adını kullanmayı göz önünde bulundurun.
  • Bu başlık yedekli veya ana yönergeyle kafa karıştırıcı olacaksa, bunun yerine program adını kullanın.
• Ana yönergenin amacının bu olduğunu sorunu açıklamak veya özetlemek için başlığı kullanmayın.

yanlış :

Bu örnekte, sorunu açıklamak için başlık yanlış kullanılıyor.

• Noktalama işaretlerini sonlandırmadan başlık stili büyük harf kullanımını kullanın.

Ana yönergeler

• Sorunu net, düz ve belirli bir dilde açıklamak için ana yönergeyi kullanın.
• Kısa olun, yalnızca tek ve eksiksiz bir cümle kullanın. Ana yönergeyi temel bilgilere göre ayrıştırın. Konu, programınız veya kullanıcınızsa örtük olarak bırakabilirsiniz. Bunu kısa bir süre için gerçekleştirebiliyorsanız sorunun nedenini ekleyin. Daha fazla açıklamanız gerekiyorsa ek bir yönerge kullanın.

yanlış :

İletinin yüklenemiyor

Bu örnekte, hata iletisinin tamamı ana yönergeye konur ve okunmasını zorlaştırır.

• Dahil olan nesneler varsa belirli olun, adlarını verin.
• Ana yönergeye tam dosya yolları ve URL'ler koymaktan kaçının. Bunun yerine, kısa bir ad (dosya adı gibi) kullanın ve ek yönergeye tam adı (dosya yolu gibi) koyun. Ancak, hata iletisinin başka bir şekilde ek yönergeye gerek duymaması durumunda ana yönergeye tek bir tam dosya yolu veya URL ekleyebilirsiniz.

İletinin silinemiyor

Bu örnekte, ana yönergede yalnızca dosya adı yer alır. Tam yol ek yönergededir.

• Bağlam açısından açıkça belliyse tam dosya yolunu ve URL'yi vermeyin.

İletinin yeniden adlandırılamıyor

Bu örnekte, kullanıcı Windows Gezgini'nden bir dosyayı yeniden adlandırıyor. Bu durumda, tam dosya yolu gerekli değildir çünkü bağlam açısından açıktır.

• Mümkün olduğunda mevcut zamanları kullanın.
• Tümce stili büyük harfe çevirmeyi kullanın.
• Yönerge bir deyimse son dönemleri eklemeyin. Yönerge bir soruysa, son soru işaretini ekleyin.

Ana yönerge şablonları

Tümce için katı kurallar olmasa da, mümkün olduğunda aşağıdaki ana yönerge şablonlarını kullanmayı deneyin:

• [isteğe bağlı konu adı] [eylem gerçekleştiremiyor]
• [reason] nedeniyle [isteğe bağlı konu adı] [eylem gerçekleştiremiyor]
• [isteğe bağlı konu adı] "[nesne adı]" için [eylem gerçekleştiremiyor]
• [reason] nedeniyle [isteğe bağlı konu adı] "[nesne adı]" için [eylem gerçekleştiremiyor]
• [eylem gerçekleştirme] için yeterli [kaynak] yok
• [Konu adı], [amaç] için gereken [nesne adı] içermiyor
• [Cihaz veya ayar] kapatıldığından [istenmeyen sonuçlar]
• [Cihaz veya ayar] [kullanılabilir | bulundu | açık | etkin]
• "[nesne adı]" şu anda kullanılamıyor
• Kullanıcı adı veya parola yanlış
• "[nesne adı]" erişim izniniz yok
• [Eylem gerçekleştirme] ayrıcalığınız yok
• [program adı] ciddi bir sorunla karşılaşmıştır ve hemen kapatılması gerekir

Elbette, ana yönergenin dil bilgisi açısından doğru olması ve ana yönerge yönergelerine uyması için gerekli değişiklikleri yapın.

Ek yönergeler

• Aşağıdakiler için ek yönergeyi kullanın:
  • Sorun hakkında ek ayrıntılar verin.
  • Sorunun nedenini açıklama.
  • Kullanıcının sorunu çözmek için atabileceği adımları listeleyin.
  • Sorunun yeniden oluşmasını önlemek için ölçüler sağlayın.
• Mümkün olduğunda, kullanıcıların sorunu çözebilmesi için pratik ve yararlı bir çözüm önerin. Ancak, önerilen çözümün sorunu çözme olasılığının yüksek olduğundan emin olun. Mümkün, ancak olasılık dışı çözümler önererek kullanıcıların zamanını boşa harcamayın.

yanlış :

İletinin

Bu örnekte, sorun ve önerilen çözümü mümkün olsa da, çok düşük bir olasılıktır.

• Sorun kullanıcının girdiği yanlış bir değerse, doğru değerleri açıklamak için ek yönergeyi kullanın. Kullanıcıların bu bilgileri başka bir kaynaktan belirlemesi gerekmez.
• Sorun deyiminden önemsiz bir şekilde çıkarılabiliyorsa çözüm sağlamayın.

İletinin

Bu örnekte ek yönerge gerekli değildir; çözüm, sorun deyiminden önemsiz bir şekilde çıkarılabilir.

• Çözümün birden çok adımı varsa, adımları tamamlanma sırasına göre sunun. Ancak, kullanıcılar iki veya üçten fazla basit adımı hatırlamakta zorlandığı için çok adımlı çözümlerden kaçının. Daha fazla adım gerekiyorsa, uygun Yardım konusuna bakın.
• Ek yönergeleri kısa tutun. Yalnızca kullanıcıların bilmesi gerekenleri sağlayın. Gereksiz ayrıntıları atla. Orta uzunlukta en fazla üç cümleyi hedefleyin.
• Kullanıcılar yönergeleri gerçekleştirirken hatalardan kaçınmak için sonuçları eylemin önüne koyun.

Doğru:

Windows'ı yeniden başlatmak için Tamam'a tıklayın.

yanlış :

Windows'un yeniden başlatılması için Tamam'a tıklayın.

Yanlış örnekte kullanıcıların yanlışlıkla Tamam'a tıklama olasılığı daha yüksektir.

• Bu, sorunun en olası çözümleri arasında yer almadığı sürece bir yöneticiye başvurmanızı önermeyin. Gerçekten yalnızca bir yönetici tarafından çözülebilecek sorunlar için bu tür çözümleri ayırın.

yanlış :

İletinin

Bu örnekte, büyük olasılıkla sorun kullanıcının ağ bağlantısıyla ilgili olduğundan, bir yöneticiye başvurmaya değmez.

• Teknik desteğe başvurmanızı önermeyin. Bir sorunu çözmek için teknik desteğe başvurma seçeneği her zaman kullanılabilir ve hata iletileri aracılığıyla yükseltilmesi gerekmez. Bunun yerine, kullanıcıların teknik desteğe başvurmadan sorunları çözebilmesi için yararlı hata iletileri yazmaya odaklanın.

yanlış :

Bu örnekte hata iletisi yanlış bir şekilde teknik desteğe başvurmanızı önerir.

• Tümceleri, tümce stili büyük harfe çevirmeyi ve noktalamayı sonlandırmayı kullanın.

İşleme düğmeleri

• Hata iletisi sorunu çözen komut düğmeleri veya komut bağlantıları sağlıyorsa, İletişim Kutuları'nda ilgili yönergelerini izleyin.
• Hatanın sonucu olarak programın sona ermesi gerekiyorsa programdan çık düğmesini sağlayın. Karışıklığı önlemek için Bu amaçla Kapat'ı kullanmayın.
• Aksi takdirde, bir Kapat düğmesi sağlayın. Hata iletileri için Tamam'ı kullanmayın, çünkü bu ifade sorunların tamam olduğunu gösterir.
  • Özel Durumu: Hata raporlama mekanizmanızda sabit etiketler varsa (MessageBox API'sinde olduğu gibi) Tamam'ı kullanın.

Belge

Hatalara başvururken:

• Hatalara ana yönergeleriyle başvurun. Ana yönerge uzun veya ayrıntılıysa özetleyin.
• Gerekirse, bir hata iletisi iletişim kutusuna ileti olarak başvurabilirsiniz. Yalnızca programlama ve diğer teknik belgelerde hata iletisi olarak başvurun.
• Mümkün olduğunda, metni kalın kullanarak biçimlendirin. Aksi takdirde, metni yalnızca karışıklığı önlemek için gerekiyorsa tırnak içine koyun.

Örnek:Sürücü iletisinde CD diski yoksa sürücüye yeni bir CD diski takın ve yeniden deneyin.