ह्यूरिस्टिक इवैल्यूएशन: Difference between revisions
From Vigyanwiki
No edit summary |
m (13 revisions imported from alpha:ह्यूरिस्टिक_इवैल्यूएशन) |
||
| (6 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
''' | |||
'''ह्यूरिस्टिक इवैल्यूएशन''' ('''स्वानुभविक मूल्यांकन''') कंप्यूटर सॉफ़्टवेयर के लिए [[प्रयोज्य]] निरीक्षण विधि है जो उपयोगकर्ता इंटरफ़ेस डिज़ाइन में प्रयोज्य समस्याओं की पहचान करने में मदद करता है। इसमें विशेष रूप से मूल्यांकनकर्ता सम्मिलित हैं जो इंटरफ़ेस की जांच करते हैं और मान्यता प्राप्त प्रयोज्य सिद्धांतों ("ह्यूरिस्टिक्स") के साथ इसके अनुपालन का इवैल्यूएशन करते हैं। इन इवैल्यूएशन विधियों को अब नए मीडिया क्षेत्र में व्यापक रूप से सिखाया और अभ्यास किया जाता है, जहां उपयोगकर्ता इंटरफ़ेस प्रायः बजट पर कम समय में डिज़ाइन किए जाते हैं जो अन्य प्रकार के इंटरफ़ेस परीक्षण के लिए उपलब्ध धनराशि को सीमित कर सकते हैं। | |||
==परिचय== | ==परिचय== | ||
ह्यूरिस्टिक इवैल्यूएशन का मुख्य लक्ष्य उपयोगकर्ता इंटरफ़ेस के डिज़ाइन से जुड़ी किसी भी समस्या की पहचान करना है। उपयोगिता सलाहकार रॉल्फ मोलिच और जैकब नीलसन ने उपयोगिता इंजीनियरिंग के बारे में शिक्षण और परामर्श में कई वर्षों के अनुभव के आधार पर इस पद्धति को विकसित किया। ह्यूरिस्टिक इवैल्यूएशन मानव-कंप्यूटर इंटरैक्शन के क्षेत्र में प्रयोज्य निरीक्षण के सबसे अनौपचारिक तरीकों<ref name="multiple">Nielsen, J., and Molich, R. (1990). Heuristic evaluation of user interfaces, Proc. ACM CHI'90 Conf. (Seattle, WA, 1–5 April), 249–256</ref> में से एक है। प्रयोज्य डिजाइन अनुमानों के कई समूह हैं; वे परस्पर अनन्य नहीं हैं और यूजर इंटरफेस डिजाइन के कई समान पहलुओं को कवर करते हैं। प्रायः, खोजी गई प्रयोज्य समस्याओं को उपयोगकर्ता के प्रदर्शन या स्वीकृति पर उनके अनुमानित प्रभाव के अनुसार प्रायः संख्यात्मक पैमाने पर वर्गीकृत किया जाता है। प्रायः ह्यूरिस्टिक इवैल्यूएशन उपयोग के स्थितियों (सामान्य उपयोगकर्ता कार्यों) के संदर्भ में किया जाता है, ताकि डेवलपर्स को इस बात पर फीडबैक दिया जा सके कि इंटरफ़ेस किस हद तक इच्छित उपयोगकर्ताओं की आवश्यकताओं और प्राथमिकताओं के साथ संगत हो सकता है। | |||
ह्यूरिस्टिक इवैल्यूएशन की सरलता डिज़ाइन के प्ररम्भिक चरणों में और उपयोगकर्ता-आधारित परीक्षण से पहले फायदेमंद होती है। यह प्रयोज्यता निरीक्षण पद्धति उपयोगकर्ताओं पर निर्भर नहीं करती है जो भर्ती, शेड्यूलिंग मुद्दों, इवैल्यूएशन करने के लिए जगह और प्रतिभागी समय के भुगतान की आवश्यकता के कारण बोझिल हो सकती है। प्रकाशित मूल रिपोर्ट में, नीलसन ने कहा कि चार प्रयोगों से पता चला है कि व्यक्तिगत मूल्यांकनकर्ता ह्यूरिस्टिक इवैल्यूएशन करने में "ज्यादातर काफी खराब" थे और सुझाव दिया कि एक स्वीकार्य समीक्षा तैयार करने और उसे पूरा करने के लिए, एकत्रित परिणामों के साथ कई मूल्यांकनकर्ताओं की आवश्यकता थी। अधिकांश ह्यूरिस्टिक इवैल्यूएशन कुछ ही दिनों में पूरे किए जा सकते हैं। आवश्यक समय कलाकृति के आकार, उसकी जटिलता, समीक्षा के उद्देश्य, समीक्षा में उत्पन्न होने वाले प्रयोज्य मुद्दों की प्रकृति और समीक्षकों की क्षमता के आधार पर भिन्न होता है। उपयोगकर्ता परीक्षण से पहले ह्यूरिस्टिक इवैल्यूएशन का उपयोग प्रायः इवैल्यूएशन में सम्मिलित किए जाने वाले क्षेत्रों की पहचान करने के लिए या उपयोगकर्ता-आधारित इवैल्यूएशन से पहले कथित डिज़ाइन मुद्दों को खत्म करने के लिए किया जाता है। | |||
यद्यपि | यद्यपि ह्यूरिस्टिक इवैल्यूएशन कम समय में कई प्रमुख प्रयोज्य मुद्दों को साक्ष्य कर सकता है, एक आलोचना जो प्रायः की जाती है वह यह है कि परिणाम विशेषज्ञ समीक्षक (समीक्षकों) के ज्ञान से अत्यधिक प्रभावित होते हैं। इस "एकतरफा" समीक्षा में बार-बार सॉफ्टवेयर प्रदर्शन परीक्षण की तुलना में अलग-अलग परिणाम मिलते हैं, प्रत्येक प्रकार का परीक्षण समस्याओं के एक अलग समूह को साक्ष्य करता है। | ||
== कार्यप्रणाली == | == कार्यप्रणाली == | ||
प्रोजेक्ट के दायरे और प्रकार के आधार पर | प्रोजेक्ट के दायरे और प्रकार के आधार पर ह्यूरिस्टिक इवैल्यूएशन विभिन्न तरीकों से आयोजित किए जाते हैं। सामान्य नियम के रूप में, इवैल्यूएशन के भीतर पूर्वाग्रह को कम करने और निष्कर्षों को अधिकतम करने के लिए शोध ढाँचे सम्मिलित होते हैं। ह्यूरिस्टिक इवैल्यूएशन के कई पक्ष और विपक्ष हैं। इसका बहुत कुछ संसाधनों की मात्रा और उपयोगकर्ता के पास इसके लिए उपलब्ध समय पर निर्भर करता है। | ||
पेशेवर: चूंकि मूल्यांकनकर्ता जिन मानदंडों से गुजरता है उनकी | पेशेवर: चूंकि मूल्यांकनकर्ता जिन मानदंडों से गुजरता है उनकी बहुत विस्तृत सूची है, यह बहुत विस्तृत प्रक्रिया है और उन क्षेत्रों पर अच्छी प्रतिक्रिया प्रदान करती है जिनमें सुधार किया जा सकता है। इसके अलावा, चूंकि यह कई लोगों द्वारा किया जाता है, इसलिए डिज़ाइनर को कई दृष्टिकोणों से प्रतिक्रिया मिल सकती है। चूंकि यह अपेक्षाकृत सरल प्रक्रिया है, इसलिए इवैल्यूएशन के आयोजन और इसे क्रियान्वित करने से संबंधित कम नैतिक और तार्किक चिंताएं हैं। | ||
विपक्ष: चूंकि मानदंडों का | विपक्ष: चूंकि मानदंडों का विशिष्ट समूह है, इवैल्यूएशन केवल उतना ही अच्छा होगा जितना लोग इसका इवैल्यूएशन करते हैं। इससे इस इवैल्यूएशन को संचालित करने के लिए पर्याप्त योग्य विशेषज्ञों और लोगों को ढूंढने का एक और मुद्दा सामने आता है। हालाँकि, यदि आपके पास विशेषज्ञों और योग्य मूल्यांकनकर्ताओं के करीबी संसाधन हैं, तो यह कोई समस्या नहीं होगी। इसके अलावा, क्योंकि इवैल्यूएशन केवल व्यक्तिगत अवलोकन होते हैं, परिणामों में कोई ठोस डेटा नहीं होता है - डिजाइनर को बस इन विचारों को ध्यान में रखते हुए सभी जानकारी और इवैल्यूएशन करना होता है। | ||
=== मूल्यांकनकर्ताओं की संख्या === | === मूल्यांकनकर्ताओं की संख्या === | ||
नीलसन के अनुसार, | नीलसन के अनुसार, अध्ययन के भीतर तीन से पांच मूल्यांकनकर्ताओं की संस्तुति की जाती है।<ref name=":0">{{Cite web|last=Experience|first=World Leaders in Research-Based User|title=Heuristic Evaluation: How-To: Article by Jakob Nielsen|url=https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/|access-date=2021-12-03|website=Nielsen Norman Group|language=en}}</ref> पांच से अधिक मूल्यांकनकर्ताओं के होने से अंतर्दृष्टि की मात्रा में वृद्धि नहीं होती है, और इससे समग्र इवैल्यूएशन में लाभ की तुलना में अधिक लागत जुड़ सकती है। | ||
=== व्यक्तिगत और समूह प्रक्रिया === | === व्यक्तिगत और समूह प्रक्रिया === | ||
समूह पुष्टिकरण पूर्वाग्रह को कम करने के लिए परिणामों को एकत्र करने से पहले ''' | समूह पुष्टिकरण पूर्वाग्रह को कम करने के लिए परिणामों को एकत्र करने से पहले '''ह्यूरिस्टिक इवैल्यूएशन''' व्यक्तिगत रूप से प्रारम्भ होना चाहिए।<ref name=":0" /> अंतर्दृष्टि जमा करने के लिए समूह चर्चा में प्रवेश करने से पहले मूल्यांकनकर्ता को प्रोटोटाइप की स्वतंत्र रूप से जांच करनी चाहिए। | ||
=== पर्यवेक्षक ट्रेड-ऑफ़ === | === पर्यवेक्षक ट्रेड-ऑफ़ === | ||
किसी | किसी इवैल्यूएशन सत्र में पर्यवेक्षक को सम्मिलित करते समय लागत और लाभ जुड़े होते हैं।<ref name=":0" /> | ||
पर्यवेक्षक के बिना एक सत्र में, मूल्यांकनकर्ताओं को उत्पाद/प्रोटोटाइप के साथ बातचीत करते समय एक लिखित रिपोर्ट के भीतर अपनी व्यक्तिगत टिप्पणियों को औपचारिक रूप देने की आवश्यकता होगी। इस विकल्प के लिए मूल्यांकनकर्ताओं को अधिक समय और प्रयास की आवश्यकता होगी, और इसके लिए अध्ययन के संचालकों को व्यक्तिगत रिपोर्ट की व्याख्या करने के लिए अतिरिक्त समय की भी आवश्यकता होगी। हालाँकि, यह विकल्प कम खर्चीला है क्योंकि यह पर्यवेक्षकों को काम पर रखने से जुड़ी ओवरहेड लागत को कम कर देता है। | |||
पर्यवेक्षक के साथ, मूल्यांकनकर्ता अपना विश्लेषण मौखिक रूप से प्रदान कर सकते हैं, जबकि पर्यवेक्षक मूल्यांकनकर्ताओं के निष्कर्षों को प्रतिलेखित और व्याख्या कर सकते हैं। यह विकल्प मूल्यांकनकर्ताओं पर कार्यभार की मात्रा और कई मूल्यांकनकर्ताओं के निष्कर्षों की व्याख्या करने के लिए आवश्यक समय को कम करता है। | |||
==नील्सन के अनुमान== | ==नील्सन के अनुमान== | ||
उपयोगकर्ता इंटरफ़ेस डिज़ाइन के लिए जैकब नीलसन का अनुमान शायद सबसे अधिक उपयोग किया जाने वाला प्रयोज्य अनुमान है। अनुमान का प्रारंभिक संस्करण नीलसन और [[रॉल्फ मोलिच]] द्वारा 1989-1990 में प्रकाशित दो पत्रों में छपा।<ref>{{Cite journal| doi = 10.1145/67880.67885| issn = 0736-6906| volume = 21| issue = 1| pages = 45–48| last1 = Nielsen| first1 = J.| last2 = Molich| first2 = R.| title = प्रयोज्य इंजीनियरिंग के आधार पर यूजर इंटरफेस डिजाइन सिखाना| journal = ACM SIGCHI Bulletin| accessdate = 2022-05-25| date = 1989| s2cid = 41663689| url = https://doi.org/10.1145/67880.67885}}</ref><ref>{{Cite journal| doi = 10.1145/77481.77486| issn = 0001-0782| volume = 33| issue = 3| pages = 338–348| last1 = Molich| first1 = Rolf| last2 = Nielsen| first2 = Jakob| title = मानव-कंप्यूटर संवाद में सुधार| journal = Communications of the ACM| accessdate = 2022-02-04| date = 1990| s2cid = 11462820| url = https://doi.org/10.1145/77481.77486}}</ref> नीलसन ने 1994 में एक अद्यतन | उपयोगकर्ता इंटरफ़ेस डिज़ाइन के लिए जैकब नीलसन का अनुमान शायद सबसे अधिक उपयोग किया जाने वाला प्रयोज्य अनुमान है। अनुमान का प्रारंभिक संस्करण नीलसन और [[रॉल्फ मोलिच]] द्वारा 1989-1990 में प्रकाशित दो पत्रों में छपा।<ref>{{Cite journal| doi = 10.1145/67880.67885| issn = 0736-6906| volume = 21| issue = 1| pages = 45–48| last1 = Nielsen| first1 = J.| last2 = Molich| first2 = R.| title = प्रयोज्य इंजीनियरिंग के आधार पर यूजर इंटरफेस डिजाइन सिखाना| journal = ACM SIGCHI Bulletin| accessdate = 2022-05-25| date = 1989| s2cid = 41663689| url = https://doi.org/10.1145/67880.67885}}</ref><ref>{{Cite journal| doi = 10.1145/77481.77486| issn = 0001-0782| volume = 33| issue = 3| pages = 338–348| last1 = Molich| first1 = Rolf| last2 = Nielsen| first2 = Jakob| title = मानव-कंप्यूटर संवाद में सुधार| journal = Communications of the ACM| accessdate = 2022-02-04| date = 1990| s2cid = 11462820| url = https://doi.org/10.1145/77481.77486}}</ref> नीलसन ने 1994 में एक अद्यतन समूह प्रकाशित किया,<ref>{{Cite conference| publisher = ACM Press| doi = 10.1145/191666.191729| isbn = 978-0-89791-650-9| conference = the SIGCHI conference| pages = 152–158| last = Nielsen| first = Jakob| title = प्रयोज्य अनुमानों की व्याख्यात्मक शक्ति को बढ़ाना| journal = Proceedings of the SIGCHI Conference on Human Factors in Computing Systems Celebrating Interdependence - CHI '94| location = Boston, Massachusetts, United States| accessdate = 2022-05-25| date = 1994| url = http://portal.acm.org/citation.cfm?doid=191666.191729}}</ref> और आज भी उपयोग में आने वाला अंतिम समूह 2005 में प्रकाशित हुआ:<ref>{{Citation| last = Nielsen| first = Jakob| title = Ten usability heuristics| date = 2005| s2cid = 59788005| url = https://pdfs.semanticscholar.org/5f03/b251093aee730ab9772db2e1a8a7eb8522cb.pdf}}</ref> | ||
# ''' | # '''सिस्टम स्थिति दृश्यता:''' सिस्टम को उपयोगकर्ताओं को हमेशा उचित समय के भीतर उचित फीडबैक के माध्यम से क्या हो रहा है, इसके बारे में सूचित रखना चाहिए। | ||
# ''' | # '''सिस्टम और वास्तविक दुनिया के बीच मिलान:''' सिस्टम को उपयोगकर्ता की भाषा बोलनी चाहिए, जिसमें सिस्टम-उन्मुख शब्दों के बजाय उपयोगकर्ता के परिचित शब्द, वाक्यांश और अवधारणाएं सम्मिलित होनी चाहिए। वास्तविक दुनिया की परंपराओं का पालन करें, जिससे जानकारी प्राकृतिक और तार्किक क्रम में प्रदर्शित हो। | ||
# ''' | # '''यूजर कण्ट्रोल एंड फ्रीडम:''' उपयोगकर्ता प्रायः गलती से सिस्टम फ़ंक्शन चुनते हैं और उन्हें विस्तारित संवाद से गुजरने के बिना अवांछित स्थिति छोड़ने के लिए स्पष्ट रूप से चिह्नित "आपातकालीन निकास" की आवश्यकता होगी। पूर्ववत करें और फिर से करें का समर्थन करें. | ||
# ''' | # '''कंसिस्टेंसी एंड स्टैंडर्ड्स:''' उपयोगकर्ताओं को यह आश्चर्य नहीं करना चाहिए कि क्या विभिन्न शब्दों, स्थितियों या कार्यों का मतलब एक ही है। प्लेटफ़ॉर्म परंपराओं का पालन करें. | ||
# ''' | # '''एरर प्रिवेंशन:''' अच्छे त्रुटि संदेशों से भी बेहतर सावधानीपूर्वक डिज़ाइन है जो किसी समस्या को पहली बार में होने से रोकता है। या तो त्रुटि-प्रवण स्थितियों को समाप्त करें या उनके लिए जाँच करें और कार्रवाई करने से पहले उपयोगकर्ताओं को एक पुष्टिकरण विकल्प प्रस्तुत करें। | ||
# ''' | # '''रिकग्निशन के स्थान पर रिकॉल:''' ऑब्जेक्ट, क्रियाएं और विकल्प दृश्यमान बनाकर उपयोगकर्ता की मेमोरी लोड को कम करें। उपयोगकर्ता को संवाद के भाग से दूसरे भाग की जानकारी याद रखने की ज़रूरत नहीं होनी चाहिए। सिस्टम के उपयोग के निर्देश जब भी उपयुक्त हों, दिखाई देने चाहिए या आसानी से पुनर्प्राप्त किए जाने योग्य होने चाहिए। | ||
# '''उपयोग का नम्यता एवं दक्षता:''' एक्सेलेरेटर - नौसिखिया उपयोगकर्ता द्वारा अनदेखा - | # '''उपयोग का नम्यता एवं दक्षता:''' एक्सेलेरेटर - नौसिखिया उपयोगकर्ता द्वारा अनदेखा - प्रायः विशेषज्ञ उपयोगकर्ता के लिए इंटरैक्शन को तेज कर सकता है ताकि सिस्टम अनुभवहीन और अनुभवी दोनों उपयोगकर्ताओं को पूरा कर सके। उपयोगकर्ताओं को बारंबार कार्रवाइयां अनुकूलित करने की अनुमति दें। | ||
# ''' | # '''एस्थेटिक एंड मिनिमालिस्ट डिज़ाइन:''' संवादों में ऐसी जानकारी नहीं होनी चाहिए जो अप्रासंगिक हो या जिसकी आवश्यकता शायद ही हो। किसी संवाद में सूचना की प्रत्येक अतिरिक्त इकाई सूचना की संबंधित इकाइयों के साथ प्रतिस्पर्धा करती है और उनकी सापेक्ष दृश्यता कम कर देती है। | ||
# ''' | # '''उउपयोगकर्ताओं को एरर को पहचानने, निदान करने और पुनर्प्राप्त करने में सहायता करें:''' त्रुटि संदेशों को सरल भाषा (कोई कोड नहीं) में व्यक्त किया जाना चाहिए, समस्या का सटीक संकेत देना चाहिए और रचनात्मक रूप से समाधान सुझाना चाहिए। | ||
# ''' | # '''हेल्प और डॉक्यूमेंट:''' यद्यपि यह बेहतर है कि सिस्टम का उपयोग डॉक्यूमेंटेशन के बिना किया जा सके, फिर भी सहायता और डॉक्यूमेंटेशन प्रदान करना आवश्यक हो सकता है। ऐसी कोई भी जानकारी खोजना आसान होनी चाहिए, उपयोगकर्ता के कार्य पर केंद्रित होनी चाहिए, किए जाने वाले ठोस कदमों की सूची होनी चाहिए और बहुत बड़ी नहीं होनी चाहिए। | ||
== गेरहार्ट-पॉवेल के संज्ञानात्मक अभियांत्रिकी सिद्धांत == | == गेरहार्ट-पॉवेल के संज्ञानात्मक अभियांत्रिकी सिद्धांत == | ||
यद्यपि नील्सन को | यद्यपि नील्सन को ह्यूरिस्टिक इवैल्यूएशन में विशेषज्ञ और क्षेत्र का नेता माना जाता है, जिल गेरहार्ड्ट-पॉवल्स ने मानव-कंप्यूटर प्रदर्शन को बढ़ाने के लिए संज्ञानात्मक इंजीनियरिंग सिद्धांतों का समूह विकसित किया है।<ref>{{Cite journal | last = Gerhardt-Powals| first = Jill | title = Cognitive engineering principles for enhancing human – computer performance | journal = International Journal of Human-Computer Interaction| volume = 8 | issue = 2| pages = 189–211| year = 1996 | accessdate = | doi=10.1080/10447319609526147}} | ||
</ref> ये अनुमान, या सिद्धांत, नीलसन के अनुमान के समान हैं, लेकिन | </ref> ये अनुमान, या सिद्धांत, नीलसन के अनुमान के समान हैं, लेकिन इवैल्यूएशन के लिए अधिक समग्र दृष्टिकोण अपनाते हैं। गेरहार्ड्ट पॉवल्स के सिद्धांत<ref>[http://usability.gov/methods/test_refine/heuristic.html#WhatisaHeuristicEvaluation Heuristic Evaluation – Usability Methods – What is a heuristic evaluation?] {{Webarchive|url=https://web.archive.org/web/20130628091244/http://www.usability.gov/methods/test_refine/heuristic.html#WhatisaHeuristicEvaluation |date=28 June 2013 }} Usability.gov</ref> नीचे सूचीबद्ध हैं। | ||
# '''अवांछित कार्यभार को स्वचालित करें:''' उच्च-स्तरीय कार्यों के लिए संज्ञानात्मक संसाधनों को मुक्त करने के लिए मानसिक गणनाओं, अनुमानों, तुलनाओं और किसी भी अनावश्यक सोच को हटा दें। | # '''अवांछित कार्यभार को स्वचालित करें:''' उच्च-स्तरीय कार्यों के लिए संज्ञानात्मक संसाधनों को मुक्त करने के लिए मानसिक गणनाओं, अनुमानों, तुलनाओं और किसी भी अनावश्यक सोच को हटा दें। | ||
| Line 58: | Line 57: | ||
# '''लगातार सार्थक तरीकों से समूह डेटा:''' एक स्क्रीन के भीतर, डेटा को तर्कसंगत रूप से समूहीकृत किया जाना चाहिए; स्क्रीनों पर, इसे लगातार समूहीकृत किया जाना चाहिए। इससे जानकारी खोजने का समय कम हो जाएगा. | # '''लगातार सार्थक तरीकों से समूह डेटा:''' एक स्क्रीन के भीतर, डेटा को तर्कसंगत रूप से समूहीकृत किया जाना चाहिए; स्क्रीनों पर, इसे लगातार समूहीकृत किया जाना चाहिए। इससे जानकारी खोजने का समय कम हो जाएगा. | ||
# '''डेटा-संचालित कार्य सीमित करें:''' उदाहरण के लिए, कच्चे डेटा को आत्मसात करने में लगने वाले समय को कम करने के लिए, रंग और ग्राफ़िक्स का उपयोग करें। | # '''डेटा-संचालित कार्य सीमित करें:''' उदाहरण के लिए, कच्चे डेटा को आत्मसात करने में लगने वाले समय को कम करने के लिए, रंग और ग्राफ़िक्स का उपयोग करें। | ||
# '''डिस्प्ले में केवल वही जानकारी | # '''डिस्प्ले में केवल वही जानकारी सम्मिलित करें जो किसी निश्चित समय में उपयोगकर्ता के लिए आवश्यक हो:''' ऐसी बाहरी जानकारी को हटा दें जो वर्तमान कार्यों के लिए प्रासंगिक नहीं है ताकि उपयोगकर्ता महत्वपूर्ण डेटा पर ध्यान केंद्रित कर सके। | ||
# '''उपयुक्त होने पर डेटा की अनेक कोडिंग प्रदान करें:''' संज्ञानात्मक नम्यता को बढ़ावा देने और उपयोगकर्ता की प्राथमिकताओं को संतुष्ट करने के लिए सिस्टम को विभिन्न स्वरूपों और/या विवरण के स्तरों में डेटा प्रदान करना चाहिए। | # '''उपयुक्त होने पर डेटा की अनेक कोडिंग प्रदान करें:''' संज्ञानात्मक नम्यता को बढ़ावा देने और उपयोगकर्ता की प्राथमिकताओं को संतुष्ट करने के लिए सिस्टम को विभिन्न स्वरूपों और/या विवरण के स्तरों में डेटा प्रदान करना चाहिए। | ||
# '''विवेकशील अतिरेक का अभ्यास करें:''' सिद्धांत 10 को पहले दो लेखकों द्वारा सिद्धांत 6 और 8 के बीच संभावित संघर्ष को हल करने के लिए तैयार किया गया था, यानी, सुसंगत होने के लिए, कभी-कभी किसी निश्चित समय में आवश्यकता से अधिक जानकारी | # '''विवेकशील अतिरेक का अभ्यास करें:''' सिद्धांत 10 को पहले दो लेखकों द्वारा सिद्धांत 6 और 8 के बीच संभावित संघर्ष को हल करने के लिए तैयार किया गया था, यानी, सुसंगत होने के लिए, कभी-कभी किसी निश्चित समय में आवश्यकता से अधिक जानकारी सम्मिलित करना आवश्यक होता है। | ||
== इंटरफ़ेस डिज़ाइन के श्नाइडरमैन के आठ स्वर्णिम नियम == | == इंटरफ़ेस डिज़ाइन के श्नाइडरमैन के आठ स्वर्णिम नियम == | ||
| Line 80: | Line 79: | ||
# '''आवास:''' इंटरफ़ेस प्रत्येक उपयोगकर्ता समूह के काम करने और सोचने के तरीके में फिट होगा। | # '''आवास:''' इंटरफ़ेस प्रत्येक उपयोगकर्ता समूह के काम करने और सोचने के तरीके में फिट होगा। | ||
# '''भाषाई स्पष्टता:''' इंटरफ़ेस यथासंभव कुशलता से संचार करेगा। | # '''भाषाई स्पष्टता:''' इंटरफ़ेस यथासंभव कुशलता से संचार करेगा। | ||
# ''' | # '''एस्थेटिक इंटीग्रिटी:''' इंटरफ़ेस में एक आकर्षक और उपयुक्त डिज़ाइन होगा। | ||
# '''सरलता:''' इंटरफ़ेस तत्वों को सरलता से प्रस्तुत करेगा। | # '''सरलता:''' इंटरफ़ेस तत्वों को सरलता से प्रस्तुत करेगा। | ||
# '''पूर्वानुमेयता:''' इंटरफ़ेस इस तरह से व्यवहार करेगा कि उपयोगकर्ता सटीक भविष्यवाणी कर सकें कि आगे क्या होगा। | # '''पूर्वानुमेयता:''' इंटरफ़ेस इस तरह से व्यवहार करेगा कि उपयोगकर्ता सटीक भविष्यवाणी कर सकें कि आगे क्या होगा। | ||
| Line 94: | Line 93: | ||
# '''परिशुद्धता:''' इंटरफ़ेस उपयोगकर्ताओं को सटीक रूप से कार्य करने की अनुमति देगा। | # '''परिशुद्धता:''' इंटरफ़ेस उपयोगकर्ताओं को सटीक रूप से कार्य करने की अनुमति देगा। | ||
# '''क्षमा:''' इंटरफ़ेस कार्यों को पुनर्प्राप्ति योग्य बना देगा। | # '''क्षमा:''' इंटरफ़ेस कार्यों को पुनर्प्राप्ति योग्य बना देगा। | ||
# ''' | # '''प्रतिक्रियाशीलता:''' इंटरफ़ेस उपयोगकर्ताओं को उनके कार्यों के परिणामों और इंटरफ़ेस की स्थिति के बारे में सूचित करेगा। | ||
== डोमेन अथवा संस्कृति-विशिष्ट | == डोमेन अथवा संस्कृति-विशिष्ट ह्यूरिस्टिक इवैल्यूएशन == | ||
किसी विशिष्ट डोमेन और संस्कृति वाले एप्लिकेशन के लिए, ऊपर उल्लिखित अनुमान संभावित प्रयोज्य समस्याओं की पहचान नहीं करते हैं।<ref>{{Cite journal|last1=Nizamani|first1=Sehrish|last2=Khoumbati|first2=Khalil|last3=Nizamani|first3=Sarwat|last4=Memon|first4=Shahzad|last5=Nizamani|first5=Saad|last6=Laghari|first6=Gulsher|date=2021-03-20|title=डोमेन और संस्कृति-उन्मुख अनुमान निर्माण और सत्यापन के लिए एक पद्धति|url=https://doi.org/10.1080/0144929X.2021.1903080|journal=Behaviour & Information Technology|volume=41 |issue=8 |pages=1769–1795|doi=10.1080/0144929X.2021.1903080|s2cid=233682515|issn=0144-929X}}</ref> अनुमानों की ये सीमाएँ इसलिए होती हैं क्योंकि ये अनुमान किसी अनुप्रयोग के डोमेन और संस्कृति-विशिष्ट विशेषताओं पर विचार करने में असमर्थ हैं। इसके परिणामस्वरूप डोमेन-विशिष्ट या संस्कृति-विशिष्ट | किसी विशिष्ट डोमेन और संस्कृति वाले एप्लिकेशन के लिए, ऊपर उल्लिखित अनुमान संभावित प्रयोज्य समस्याओं की पहचान नहीं करते हैं।<ref>{{Cite journal|last1=Nizamani|first1=Sehrish|last2=Khoumbati|first2=Khalil|last3=Nizamani|first3=Sarwat|last4=Memon|first4=Shahzad|last5=Nizamani|first5=Saad|last6=Laghari|first6=Gulsher|date=2021-03-20|title=डोमेन और संस्कृति-उन्मुख अनुमान निर्माण और सत्यापन के लिए एक पद्धति|url=https://doi.org/10.1080/0144929X.2021.1903080|journal=Behaviour & Information Technology|volume=41 |issue=8 |pages=1769–1795|doi=10.1080/0144929X.2021.1903080|s2cid=233682515|issn=0144-929X}}</ref> अनुमानों की ये सीमाएँ इसलिए होती हैं क्योंकि ये अनुमान किसी अनुप्रयोग के डोमेन और संस्कृति-विशिष्ट विशेषताओं पर विचार करने में असमर्थ हैं। इसके परिणामस्वरूप डोमेन-विशिष्ट या संस्कृति-विशिष्ट ह्यूरिस्टिक इवैल्यूएशन की शुरूआत होती है।<ref>{{Cite journal|last1=Nizamani|first1=Sehrish|last2=Nizamani|first2=Saad|last3=Basir|first3=Nazish|last4=Memon|first4=Muhammad|last5=Nizamani|first5=Sarwat|last6=Memon|first6=Shahzad|date=2021-04-05|title=पाकिस्तान के विश्वविद्यालयों की वेबसाइटों का डोमेन और संस्कृति-विशिष्ट अनुमानी मूल्यांकन|url=https://sujo.usindh.edu.pk/index.php/USJICT/article/view/3472|journal=University of Sindh Journal of Information and Communication Technology|language=en|volume=5|issue=1|pages=45–51|issn=2523-1235}}</ref> | ||
== यह भी देखें == | == यह भी देखें == | ||
* प्रयोज्य निरीक्षण | * प्रयोज्य निरीक्षण | ||
* प्रगतिशील प्रकटीकरण | * प्रगतिशील प्रकटीकरण | ||
* [[संज्ञानात्मक पूर्वाग्रह]] | * [[संज्ञानात्मक पूर्वाग्रह]] | ||
* [[संज्ञानात्मक आयाम]], नोटेशन, यूजर इंटरफेस और प्रोग्रामिंग भाषाओं के डिजाइन के | * [[संज्ञानात्मक आयाम]], नोटेशन, यूजर इंटरफेस और प्रोग्रामिंग भाषाओं के डिजाइन के इवैल्यूएशन के लिए एक रूपरेखा | ||
==संदर्भ== | ==संदर्भ== | ||
| Line 127: | Line 126: | ||
[[Category: Machine Translated Page]] | [[Category: Machine Translated Page]] | ||
[[Category:Created On 27/07/2023]] | [[Category:Created On 27/07/2023]] | ||
[[Category:Vigyan Ready]] | |||
Latest revision as of 23:13, 10 October 2023
ह्यूरिस्टिक इवैल्यूएशन (स्वानुभविक मूल्यांकन) कंप्यूटर सॉफ़्टवेयर के लिए प्रयोज्य निरीक्षण विधि है जो उपयोगकर्ता इंटरफ़ेस डिज़ाइन में प्रयोज्य समस्याओं की पहचान करने में मदद करता है। इसमें विशेष रूप से मूल्यांकनकर्ता सम्मिलित हैं जो इंटरफ़ेस की जांच करते हैं और मान्यता प्राप्त प्रयोज्य सिद्धांतों ("ह्यूरिस्टिक्स") के साथ इसके अनुपालन का इवैल्यूएशन करते हैं। इन इवैल्यूएशन विधियों को अब नए मीडिया क्षेत्र में व्यापक रूप से सिखाया और अभ्यास किया जाता है, जहां उपयोगकर्ता इंटरफ़ेस प्रायः बजट पर कम समय में डिज़ाइन किए जाते हैं जो अन्य प्रकार के इंटरफ़ेस परीक्षण के लिए उपलब्ध धनराशि को सीमित कर सकते हैं।
परिचय
ह्यूरिस्टिक इवैल्यूएशन का मुख्य लक्ष्य उपयोगकर्ता इंटरफ़ेस के डिज़ाइन से जुड़ी किसी भी समस्या की पहचान करना है। उपयोगिता सलाहकार रॉल्फ मोलिच और जैकब नीलसन ने उपयोगिता इंजीनियरिंग के बारे में शिक्षण और परामर्श में कई वर्षों के अनुभव के आधार पर इस पद्धति को विकसित किया। ह्यूरिस्टिक इवैल्यूएशन मानव-कंप्यूटर इंटरैक्शन के क्षेत्र में प्रयोज्य निरीक्षण के सबसे अनौपचारिक तरीकों[1] में से एक है। प्रयोज्य डिजाइन अनुमानों के कई समूह हैं; वे परस्पर अनन्य नहीं हैं और यूजर इंटरफेस डिजाइन के कई समान पहलुओं को कवर करते हैं। प्रायः, खोजी गई प्रयोज्य समस्याओं को उपयोगकर्ता के प्रदर्शन या स्वीकृति पर उनके अनुमानित प्रभाव के अनुसार प्रायः संख्यात्मक पैमाने पर वर्गीकृत किया जाता है। प्रायः ह्यूरिस्टिक इवैल्यूएशन उपयोग के स्थितियों (सामान्य उपयोगकर्ता कार्यों) के संदर्भ में किया जाता है, ताकि डेवलपर्स को इस बात पर फीडबैक दिया जा सके कि इंटरफ़ेस किस हद तक इच्छित उपयोगकर्ताओं की आवश्यकताओं और प्राथमिकताओं के साथ संगत हो सकता है।
ह्यूरिस्टिक इवैल्यूएशन की सरलता डिज़ाइन के प्ररम्भिक चरणों में और उपयोगकर्ता-आधारित परीक्षण से पहले फायदेमंद होती है। यह प्रयोज्यता निरीक्षण पद्धति उपयोगकर्ताओं पर निर्भर नहीं करती है जो भर्ती, शेड्यूलिंग मुद्दों, इवैल्यूएशन करने के लिए जगह और प्रतिभागी समय के भुगतान की आवश्यकता के कारण बोझिल हो सकती है। प्रकाशित मूल रिपोर्ट में, नीलसन ने कहा कि चार प्रयोगों से पता चला है कि व्यक्तिगत मूल्यांकनकर्ता ह्यूरिस्टिक इवैल्यूएशन करने में "ज्यादातर काफी खराब" थे और सुझाव दिया कि एक स्वीकार्य समीक्षा तैयार करने और उसे पूरा करने के लिए, एकत्रित परिणामों के साथ कई मूल्यांकनकर्ताओं की आवश्यकता थी। अधिकांश ह्यूरिस्टिक इवैल्यूएशन कुछ ही दिनों में पूरे किए जा सकते हैं। आवश्यक समय कलाकृति के आकार, उसकी जटिलता, समीक्षा के उद्देश्य, समीक्षा में उत्पन्न होने वाले प्रयोज्य मुद्दों की प्रकृति और समीक्षकों की क्षमता के आधार पर भिन्न होता है। उपयोगकर्ता परीक्षण से पहले ह्यूरिस्टिक इवैल्यूएशन का उपयोग प्रायः इवैल्यूएशन में सम्मिलित किए जाने वाले क्षेत्रों की पहचान करने के लिए या उपयोगकर्ता-आधारित इवैल्यूएशन से पहले कथित डिज़ाइन मुद्दों को खत्म करने के लिए किया जाता है।
यद्यपि ह्यूरिस्टिक इवैल्यूएशन कम समय में कई प्रमुख प्रयोज्य मुद्दों को साक्ष्य कर सकता है, एक आलोचना जो प्रायः की जाती है वह यह है कि परिणाम विशेषज्ञ समीक्षक (समीक्षकों) के ज्ञान से अत्यधिक प्रभावित होते हैं। इस "एकतरफा" समीक्षा में बार-बार सॉफ्टवेयर प्रदर्शन परीक्षण की तुलना में अलग-अलग परिणाम मिलते हैं, प्रत्येक प्रकार का परीक्षण समस्याओं के एक अलग समूह को साक्ष्य करता है।
कार्यप्रणाली
प्रोजेक्ट के दायरे और प्रकार के आधार पर ह्यूरिस्टिक इवैल्यूएशन विभिन्न तरीकों से आयोजित किए जाते हैं। सामान्य नियम के रूप में, इवैल्यूएशन के भीतर पूर्वाग्रह को कम करने और निष्कर्षों को अधिकतम करने के लिए शोध ढाँचे सम्मिलित होते हैं। ह्यूरिस्टिक इवैल्यूएशन के कई पक्ष और विपक्ष हैं। इसका बहुत कुछ संसाधनों की मात्रा और उपयोगकर्ता के पास इसके लिए उपलब्ध समय पर निर्भर करता है।
पेशेवर: चूंकि मूल्यांकनकर्ता जिन मानदंडों से गुजरता है उनकी बहुत विस्तृत सूची है, यह बहुत विस्तृत प्रक्रिया है और उन क्षेत्रों पर अच्छी प्रतिक्रिया प्रदान करती है जिनमें सुधार किया जा सकता है। इसके अलावा, चूंकि यह कई लोगों द्वारा किया जाता है, इसलिए डिज़ाइनर को कई दृष्टिकोणों से प्रतिक्रिया मिल सकती है। चूंकि यह अपेक्षाकृत सरल प्रक्रिया है, इसलिए इवैल्यूएशन के आयोजन और इसे क्रियान्वित करने से संबंधित कम नैतिक और तार्किक चिंताएं हैं।
विपक्ष: चूंकि मानदंडों का विशिष्ट समूह है, इवैल्यूएशन केवल उतना ही अच्छा होगा जितना लोग इसका इवैल्यूएशन करते हैं। इससे इस इवैल्यूएशन को संचालित करने के लिए पर्याप्त योग्य विशेषज्ञों और लोगों को ढूंढने का एक और मुद्दा सामने आता है। हालाँकि, यदि आपके पास विशेषज्ञों और योग्य मूल्यांकनकर्ताओं के करीबी संसाधन हैं, तो यह कोई समस्या नहीं होगी। इसके अलावा, क्योंकि इवैल्यूएशन केवल व्यक्तिगत अवलोकन होते हैं, परिणामों में कोई ठोस डेटा नहीं होता है - डिजाइनर को बस इन विचारों को ध्यान में रखते हुए सभी जानकारी और इवैल्यूएशन करना होता है।
मूल्यांकनकर्ताओं की संख्या
नीलसन के अनुसार, अध्ययन के भीतर तीन से पांच मूल्यांकनकर्ताओं की संस्तुति की जाती है।[2] पांच से अधिक मूल्यांकनकर्ताओं के होने से अंतर्दृष्टि की मात्रा में वृद्धि नहीं होती है, और इससे समग्र इवैल्यूएशन में लाभ की तुलना में अधिक लागत जुड़ सकती है।
व्यक्तिगत और समूह प्रक्रिया
समूह पुष्टिकरण पूर्वाग्रह को कम करने के लिए परिणामों को एकत्र करने से पहले ह्यूरिस्टिक इवैल्यूएशन व्यक्तिगत रूप से प्रारम्भ होना चाहिए।[2] अंतर्दृष्टि जमा करने के लिए समूह चर्चा में प्रवेश करने से पहले मूल्यांकनकर्ता को प्रोटोटाइप की स्वतंत्र रूप से जांच करनी चाहिए।
पर्यवेक्षक ट्रेड-ऑफ़
किसी इवैल्यूएशन सत्र में पर्यवेक्षक को सम्मिलित करते समय लागत और लाभ जुड़े होते हैं।[2]
पर्यवेक्षक के बिना एक सत्र में, मूल्यांकनकर्ताओं को उत्पाद/प्रोटोटाइप के साथ बातचीत करते समय एक लिखित रिपोर्ट के भीतर अपनी व्यक्तिगत टिप्पणियों को औपचारिक रूप देने की आवश्यकता होगी। इस विकल्प के लिए मूल्यांकनकर्ताओं को अधिक समय और प्रयास की आवश्यकता होगी, और इसके लिए अध्ययन के संचालकों को व्यक्तिगत रिपोर्ट की व्याख्या करने के लिए अतिरिक्त समय की भी आवश्यकता होगी। हालाँकि, यह विकल्प कम खर्चीला है क्योंकि यह पर्यवेक्षकों को काम पर रखने से जुड़ी ओवरहेड लागत को कम कर देता है।
पर्यवेक्षक के साथ, मूल्यांकनकर्ता अपना विश्लेषण मौखिक रूप से प्रदान कर सकते हैं, जबकि पर्यवेक्षक मूल्यांकनकर्ताओं के निष्कर्षों को प्रतिलेखित और व्याख्या कर सकते हैं। यह विकल्प मूल्यांकनकर्ताओं पर कार्यभार की मात्रा और कई मूल्यांकनकर्ताओं के निष्कर्षों की व्याख्या करने के लिए आवश्यक समय को कम करता है।
नील्सन के अनुमान
उपयोगकर्ता इंटरफ़ेस डिज़ाइन के लिए जैकब नीलसन का अनुमान शायद सबसे अधिक उपयोग किया जाने वाला प्रयोज्य अनुमान है। अनुमान का प्रारंभिक संस्करण नीलसन और रॉल्फ मोलिच द्वारा 1989-1990 में प्रकाशित दो पत्रों में छपा।[3][4] नीलसन ने 1994 में एक अद्यतन समूह प्रकाशित किया,[5] और आज भी उपयोग में आने वाला अंतिम समूह 2005 में प्रकाशित हुआ:[6]
- सिस्टम स्थिति दृश्यता: सिस्टम को उपयोगकर्ताओं को हमेशा उचित समय के भीतर उचित फीडबैक के माध्यम से क्या हो रहा है, इसके बारे में सूचित रखना चाहिए।
- सिस्टम और वास्तविक दुनिया के बीच मिलान: सिस्टम को उपयोगकर्ता की भाषा बोलनी चाहिए, जिसमें सिस्टम-उन्मुख शब्दों के बजाय उपयोगकर्ता के परिचित शब्द, वाक्यांश और अवधारणाएं सम्मिलित होनी चाहिए। वास्तविक दुनिया की परंपराओं का पालन करें, जिससे जानकारी प्राकृतिक और तार्किक क्रम में प्रदर्शित हो।
- यूजर कण्ट्रोल एंड फ्रीडम: उपयोगकर्ता प्रायः गलती से सिस्टम फ़ंक्शन चुनते हैं और उन्हें विस्तारित संवाद से गुजरने के बिना अवांछित स्थिति छोड़ने के लिए स्पष्ट रूप से चिह्नित "आपातकालीन निकास" की आवश्यकता होगी। पूर्ववत करें और फिर से करें का समर्थन करें.
- कंसिस्टेंसी एंड स्टैंडर्ड्स: उपयोगकर्ताओं को यह आश्चर्य नहीं करना चाहिए कि क्या विभिन्न शब्दों, स्थितियों या कार्यों का मतलब एक ही है। प्लेटफ़ॉर्म परंपराओं का पालन करें.
- एरर प्रिवेंशन: अच्छे त्रुटि संदेशों से भी बेहतर सावधानीपूर्वक डिज़ाइन है जो किसी समस्या को पहली बार में होने से रोकता है। या तो त्रुटि-प्रवण स्थितियों को समाप्त करें या उनके लिए जाँच करें और कार्रवाई करने से पहले उपयोगकर्ताओं को एक पुष्टिकरण विकल्प प्रस्तुत करें।
- रिकग्निशन के स्थान पर रिकॉल: ऑब्जेक्ट, क्रियाएं और विकल्प दृश्यमान बनाकर उपयोगकर्ता की मेमोरी लोड को कम करें। उपयोगकर्ता को संवाद के भाग से दूसरे भाग की जानकारी याद रखने की ज़रूरत नहीं होनी चाहिए। सिस्टम के उपयोग के निर्देश जब भी उपयुक्त हों, दिखाई देने चाहिए या आसानी से पुनर्प्राप्त किए जाने योग्य होने चाहिए।
- उपयोग का नम्यता एवं दक्षता: एक्सेलेरेटर - नौसिखिया उपयोगकर्ता द्वारा अनदेखा - प्रायः विशेषज्ञ उपयोगकर्ता के लिए इंटरैक्शन को तेज कर सकता है ताकि सिस्टम अनुभवहीन और अनुभवी दोनों उपयोगकर्ताओं को पूरा कर सके। उपयोगकर्ताओं को बारंबार कार्रवाइयां अनुकूलित करने की अनुमति दें।
- एस्थेटिक एंड मिनिमालिस्ट डिज़ाइन: संवादों में ऐसी जानकारी नहीं होनी चाहिए जो अप्रासंगिक हो या जिसकी आवश्यकता शायद ही हो। किसी संवाद में सूचना की प्रत्येक अतिरिक्त इकाई सूचना की संबंधित इकाइयों के साथ प्रतिस्पर्धा करती है और उनकी सापेक्ष दृश्यता कम कर देती है।
- उउपयोगकर्ताओं को एरर को पहचानने, निदान करने और पुनर्प्राप्त करने में सहायता करें: त्रुटि संदेशों को सरल भाषा (कोई कोड नहीं) में व्यक्त किया जाना चाहिए, समस्या का सटीक संकेत देना चाहिए और रचनात्मक रूप से समाधान सुझाना चाहिए।
- हेल्प और डॉक्यूमेंट: यद्यपि यह बेहतर है कि सिस्टम का उपयोग डॉक्यूमेंटेशन के बिना किया जा सके, फिर भी सहायता और डॉक्यूमेंटेशन प्रदान करना आवश्यक हो सकता है। ऐसी कोई भी जानकारी खोजना आसान होनी चाहिए, उपयोगकर्ता के कार्य पर केंद्रित होनी चाहिए, किए जाने वाले ठोस कदमों की सूची होनी चाहिए और बहुत बड़ी नहीं होनी चाहिए।
गेरहार्ट-पॉवेल के संज्ञानात्मक अभियांत्रिकी सिद्धांत
यद्यपि नील्सन को ह्यूरिस्टिक इवैल्यूएशन में विशेषज्ञ और क्षेत्र का नेता माना जाता है, जिल गेरहार्ड्ट-पॉवल्स ने मानव-कंप्यूटर प्रदर्शन को बढ़ाने के लिए संज्ञानात्मक इंजीनियरिंग सिद्धांतों का समूह विकसित किया है।[7] ये अनुमान, या सिद्धांत, नीलसन के अनुमान के समान हैं, लेकिन इवैल्यूएशन के लिए अधिक समग्र दृष्टिकोण अपनाते हैं। गेरहार्ड्ट पॉवल्स के सिद्धांत[8] नीचे सूचीबद्ध हैं।
- अवांछित कार्यभार को स्वचालित करें: उच्च-स्तरीय कार्यों के लिए संज्ञानात्मक संसाधनों को मुक्त करने के लिए मानसिक गणनाओं, अनुमानों, तुलनाओं और किसी भी अनावश्यक सोच को हटा दें।
- अनिश्चितता को कम करें: निर्णय लेने में लगने वाले समय और त्रुटि को कम करने के लिए डेटा को ऐसे तरीके से प्रदर्शित करें जो स्पष्ट और सुस्पष्ट हो।
- फ्यूज डेटा: संज्ञानात्मक भार को कम करने के लिए निचले स्तर के डेटा को उच्च स्तर के योग में एक साथ लाएँ।
- व्याख्या के लिए सार्थक सहायता के साथ नई जानकारी प्रस्तुत करें: नई जानकारी को परिचित ढाँचे (उदाहरण के लिए, स्कीमा, रूपक, रोजमर्रा की शर्तें) के भीतर प्रस्तुत किया जाना चाहिए ताकि जानकारी को अवशोषित करना आसान हो।
- ऐसे नामों का उपयोग करें जो वैचारिक रूप से कार्य से संबंधित हों: प्रदर्शन नाम और लेबल संदर्भ-निर्भर होने चाहिए, जिससे याद रखने और पहचानने में सुधार होगा।
- लगातार सार्थक तरीकों से समूह डेटा: एक स्क्रीन के भीतर, डेटा को तर्कसंगत रूप से समूहीकृत किया जाना चाहिए; स्क्रीनों पर, इसे लगातार समूहीकृत किया जाना चाहिए। इससे जानकारी खोजने का समय कम हो जाएगा.
- डेटा-संचालित कार्य सीमित करें: उदाहरण के लिए, कच्चे डेटा को आत्मसात करने में लगने वाले समय को कम करने के लिए, रंग और ग्राफ़िक्स का उपयोग करें।
- डिस्प्ले में केवल वही जानकारी सम्मिलित करें जो किसी निश्चित समय में उपयोगकर्ता के लिए आवश्यक हो: ऐसी बाहरी जानकारी को हटा दें जो वर्तमान कार्यों के लिए प्रासंगिक नहीं है ताकि उपयोगकर्ता महत्वपूर्ण डेटा पर ध्यान केंद्रित कर सके।
- उपयुक्त होने पर डेटा की अनेक कोडिंग प्रदान करें: संज्ञानात्मक नम्यता को बढ़ावा देने और उपयोगकर्ता की प्राथमिकताओं को संतुष्ट करने के लिए सिस्टम को विभिन्न स्वरूपों और/या विवरण के स्तरों में डेटा प्रदान करना चाहिए।
- विवेकशील अतिरेक का अभ्यास करें: सिद्धांत 10 को पहले दो लेखकों द्वारा सिद्धांत 6 और 8 के बीच संभावित संघर्ष को हल करने के लिए तैयार किया गया था, यानी, सुसंगत होने के लिए, कभी-कभी किसी निश्चित समय में आवश्यकता से अधिक जानकारी सम्मिलित करना आवश्यक होता है।
इंटरफ़ेस डिज़ाइन के श्नाइडरमैन के आठ स्वर्णिम नियम
नील्सन से कुछ साल पहले बेन श्नाइडरमैन की पुस्तक प्रकाशित हुई थी, डिज़ाइनिंग द यूजर इंटरफ़ेस: स्ट्रैटेजीज़ फॉर इफेक्टिव ह्यूमन-कंप्यूटर इंटरेक्शन (1986) ने उनकी लोकप्रिय सूची, "आठ स्वर्णिम नियम" को कवर किया था।[9][10]
- स्थिरता के लिए प्रयास करें: समान स्थितियों में कार्यों के लगातार अनुक्रम की आवश्यकता होनी चाहिए...
- बार-बार आने वाले उपयोगकर्ताओं को शॉर्टकट का उपयोग करने में सक्षम करें: जैसे-जैसे उपयोग की आवृत्ति बढ़ती है, वैसे-वैसे उपयोगकर्ता की इंटरैक्शन की संख्या कम करने की इच्छा भी बढ़ती है...
- जानकारीपूर्ण फीडबैक प्रदान करें: प्रत्येक ऑपरेटर कार्रवाई के लिए, कुछ सिस्टम फीडबैक होना चाहिए...
- समापन के लिए संवाद डिज़ाइन करें: क्रियाओं के अनुक्रम को आरंभ, मध्य और अंत के साथ समूहों में व्यवस्थित किया जाना चाहिए...
- सरल त्रुटि प्रबंधन की पेशकश करें: जहां तक संभव हो, सिस्टम को डिज़ाइन करें ताकि उपयोगकर्ता कोई गंभीर त्रुटि न कर सके...
- कार्यों को आसानी से उलटने की अनुमति दें: यह सुविधा चिंता से राहत देती है, क्योंकि उपयोगकर्ता जानता है कि त्रुटियों को पूर्ववत किया जा सकता है...
- नियंत्रण के आंतरिक नियंत्रण का समर्थन करें: अनुभवी ऑपरेटर दृढ़ता से यह महसूस करना चाहते हैं कि वे सिस्टम के प्रभारी हैं और सिस्टम उनके कार्यों का जवाब देता है। उपयोगकर्ताओं को उत्तरदाताओं के बजाय कार्यों का आरंभकर्ता बनाने के लिए सिस्टम डिज़ाइन करें।
- अल्पकालिक मेमोरी लोड को कम करें: अल्पकालिक मेमोरी में मानव सूचना प्रसंस्करण की सीमा के लिए आवश्यक है कि डिस्प्ले को सरल रखा जाए, एकाधिक पेज डिस्प्ले को समेकित किया जाए, विंडो-मोशन आवृत्ति को कम किया जाए, और कोड, निमोनिक्स और क्रियाओं के अनुक्रम के लिए पर्याप्त प्रशिक्षण समय आवंटित किया जाए।
वेन्स्चेंक और बार्कर वर्गीकरण
2000 में, सुसान वेन्स्चेंक और डीन बार्कर [11]ने कई प्रमुख प्रदाताओं द्वारा उपयोग किए जाने वाले अनुमानों और दिशानिर्देशों का निम्नलिखित बीस प्रकारों में वर्गीकरण बनाया:[12]
- उपयोगकर्ता नियंत्रण: इंटरफ़ेस उपयोगकर्ता को यह समझने की अनुमति देगा कि वे नियंत्रण में हैं और उचित नियंत्रण की अनुमति देगा।
- मानवीय सीमाएँ: इंटरफ़ेस उपयोगकर्ता की संज्ञानात्मक, दृश्य, श्रवण, स्पर्श या मोटर सीमाओं को अधिभारित नहीं करेगा।
- मॉडल इंटीग्रिटी: इंटरफ़ेस व्यक्तिगत कार्यों को किसी भी मोडैलिटी (मानव-कंप्यूटर इंटरैक्शन) के भीतर फिट करेगा: श्रवण, दृश्य, या मोटर/काइनेस्टेटिक।
- आवास: इंटरफ़ेस प्रत्येक उपयोगकर्ता समूह के काम करने और सोचने के तरीके में फिट होगा।
- भाषाई स्पष्टता: इंटरफ़ेस यथासंभव कुशलता से संचार करेगा।
- एस्थेटिक इंटीग्रिटी: इंटरफ़ेस में एक आकर्षक और उपयुक्त डिज़ाइन होगा।
- सरलता: इंटरफ़ेस तत्वों को सरलता से प्रस्तुत करेगा।
- पूर्वानुमेयता: इंटरफ़ेस इस तरह से व्यवहार करेगा कि उपयोगकर्ता सटीक भविष्यवाणी कर सकें कि आगे क्या होगा।
- व्याख्या: इंटरफ़ेस इस बारे में उचित अनुमान लगाएगा कि उपयोगकर्ता क्या करने का प्रयास कर रहा है।
- सटीकता: इंटरफ़ेस त्रुटियों से मुक्त होगा।
- तकनीकी स्पष्टता: इंटरफ़ेस में उच्चतम संभव निष्ठा होगी।
- नम्यता: इंटरफ़ेस उपयोगकर्ता को कस्टम उपयोग के लिए डिज़ाइन को समायोजित करने की अनुमति देगा।
- पूर्ति: इंटरफ़ेस एक संतोषजनक उपयोगकर्ता अनुभव प्रदान करेगा।
- सांस्कृतिक औचित्य: इंटरफ़ेस उपयोगकर्ता के सामाजिक रीति-रिवाजों और अपेक्षाओं से मेल खाएगा।
- उपयुक्त गति: इंटरफ़ेस उपयोगकर्ता के लिए उपयुक्त गति पर काम करेगा।
- संगति: इंटरफ़ेस सुसंगत होगा।
- उपयोगकर्ता सहायता: इंटरफ़ेस आवश्यकता या अनुरोध के अनुसार अतिरिक्त सहायता प्रदान करेगा।
- परिशुद्धता: इंटरफ़ेस उपयोगकर्ताओं को सटीक रूप से कार्य करने की अनुमति देगा।
- क्षमा: इंटरफ़ेस कार्यों को पुनर्प्राप्ति योग्य बना देगा।
- प्रतिक्रियाशीलता: इंटरफ़ेस उपयोगकर्ताओं को उनके कार्यों के परिणामों और इंटरफ़ेस की स्थिति के बारे में सूचित करेगा।
डोमेन अथवा संस्कृति-विशिष्ट ह्यूरिस्टिक इवैल्यूएशन
किसी विशिष्ट डोमेन और संस्कृति वाले एप्लिकेशन के लिए, ऊपर उल्लिखित अनुमान संभावित प्रयोज्य समस्याओं की पहचान नहीं करते हैं।[13] अनुमानों की ये सीमाएँ इसलिए होती हैं क्योंकि ये अनुमान किसी अनुप्रयोग के डोमेन और संस्कृति-विशिष्ट विशेषताओं पर विचार करने में असमर्थ हैं। इसके परिणामस्वरूप डोमेन-विशिष्ट या संस्कृति-विशिष्ट ह्यूरिस्टिक इवैल्यूएशन की शुरूआत होती है।[14]
यह भी देखें
- प्रयोज्य निरीक्षण
- प्रगतिशील प्रकटीकरण
- संज्ञानात्मक पूर्वाग्रह
- संज्ञानात्मक आयाम, नोटेशन, यूजर इंटरफेस और प्रोग्रामिंग भाषाओं के डिजाइन के इवैल्यूएशन के लिए एक रूपरेखा
संदर्भ
- ↑ Nielsen, J., and Molich, R. (1990). Heuristic evaluation of user interfaces, Proc. ACM CHI'90 Conf. (Seattle, WA, 1–5 April), 249–256
- ↑ 2.0 2.1 2.2 Experience, World Leaders in Research-Based User. "Heuristic Evaluation: How-To: Article by Jakob Nielsen". Nielsen Norman Group (in English). Retrieved 2021-12-03.
{{cite web}}:|first=has generic name (help) - ↑ Nielsen, J.; Molich, R. (1989). "प्रयोज्य इंजीनियरिंग के आधार पर यूजर इंटरफेस डिजाइन सिखाना". ACM SIGCHI Bulletin. 21 (1): 45–48. doi:10.1145/67880.67885. ISSN 0736-6906. S2CID 41663689. Retrieved 2022-05-25.
- ↑ Molich, Rolf; Nielsen, Jakob (1990). "मानव-कंप्यूटर संवाद में सुधार". Communications of the ACM. 33 (3): 338–348. doi:10.1145/77481.77486. ISSN 0001-0782. S2CID 11462820. Retrieved 2022-02-04.
- ↑ Nielsen, Jakob (1994). प्रयोज्य अनुमानों की व्याख्यात्मक शक्ति को बढ़ाना. the SIGCHI conference. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems Celebrating Interdependence - CHI '94. Boston, Massachusetts, United States: ACM Press. pp. 152–158. doi:10.1145/191666.191729. ISBN 978-0-89791-650-9. Retrieved 2022-05-25.
- ↑ Nielsen, Jakob (2005), Ten usability heuristics (PDF), S2CID 59788005
- ↑ Gerhardt-Powals, Jill (1996). "Cognitive engineering principles for enhancing human – computer performance". International Journal of Human-Computer Interaction. 8 (2): 189–211. doi:10.1080/10447319609526147.
- ↑ Heuristic Evaluation – Usability Methods – What is a heuristic evaluation? Archived 28 June 2013 at the Wayback Machine Usability.gov
- ↑ Shneiderman (1998, p. 75); as cited in: "Eight Golden Rules of Interface Design". at www.cs.umd.edu.
- ↑ Malviya, Kartik (2020-11-20). "8 Golden Rules of Interface Design". Medium (in English). UX Planet. Retrieved 2021-03-02.
{{cite web}}: CS1 maint: url-status (link) - ↑ Weinschenk, S and Barker,D. (2000) Designing Effective Speech Interfaces. Wiley.
- ↑ Jeff Sauro. "What's the difference between a Heuristic Evaluation and a Cognitive Walkthrough?". MeasuringUsability.com.
- ↑ Nizamani, Sehrish; Khoumbati, Khalil; Nizamani, Sarwat; Memon, Shahzad; Nizamani, Saad; Laghari, Gulsher (2021-03-20). "डोमेन और संस्कृति-उन्मुख अनुमान निर्माण और सत्यापन के लिए एक पद्धति". Behaviour & Information Technology. 41 (8): 1769–1795. doi:10.1080/0144929X.2021.1903080. ISSN 0144-929X. S2CID 233682515.
- ↑ Nizamani, Sehrish; Nizamani, Saad; Basir, Nazish; Memon, Muhammad; Nizamani, Sarwat; Memon, Shahzad (2021-04-05). "पाकिस्तान के विश्वविद्यालयों की वेबसाइटों का डोमेन और संस्कृति-विशिष्ट अनुमानी मूल्यांकन". University of Sindh Journal of Information and Communication Technology (in English). 5 (1): 45–51. ISSN 2523-1235.
अग्रिम पठन
- Dix, Alan; Finlay, Janet; Abowd, Gregory D.; Beale, Russell (1993). Human-computer interaction (3 ed.). Harlow, England: Pearson Education. p. 324. ISBN 9780134372112.
- Nielsen, Jakob; Mack, Robert L. (1994). Usability Inspection Methods (1 ed.). Wiley. ISBN 978-0471018773.
- Cooper, Alan; Reimann, Robert (2003). About Face 2.0: The Essentials of Interaction Design (2 ed.). Wiley. ISBN 978-0764526411.
- Hvannberg, Ebba Thora; Law, Effie Lai-Chong; Lárusdóttir, Marta Kristín (March 2007). "Heuristic evaluation: Comparing ways of finding and reporting usability problems". Interacting with Computers. 19 (2): 225–240. doi:10.1016/j.intcom.2006.10.001. hdl:20.500.11850/6665.
- Gerhardt‐Powals, Jill (23 September 2009). "Cognitive engineering principles for enhancing human‐computer performance". International Journal of Human–Computer Interaction. 8 (2): 189–211. doi:10.1080/10447319609526147.
- Garrett, Jesse James (2010). The Elements of User Experience: User-Centered Design for the Web. Voices That Matter (2 ed.). Pearson Education. ISBN 9780321624642.
बाहरी संबंध
- A list of Nielsen Norman's Heuristic Evaluation Articles & Videos – Including fundamental points, methodologies and benefits.
- Heuristic Evaluation at Usability.gov Archived 28 June 2013 at the Wayback Machine
