आधुनिक इंटरफेस विकसित करने की मुख्य समस्याएं

नमस्कार, हेब्र! मैं आपके ध्यान में समसामयिक समस्याओं और कार्यों पर दान Abramov के पोस्ट "UI तत्वों के तत्व" का अनुवाद करता हूं जिन्हें एक अच्छे इंटरफ़ेस में हल किया जाना चाहिए। लेखक तैयार किए गए पुस्तकालयों और रूपरेखाओं का उपयोग किए बिना - इंटरफेस की व्याख्या, जिसमें से अकेले की व्याख्या और समाधान के विकास में मूलभूत समस्याओं की जांच करता है - बाजार पर मौजूदा दृश्य विकास के क्षेत्र में समाधान की गहराई से समझ दे सकता है।




अपने अंतिम प्रकाशन में, मैंने लिखा कि किसी एक के ज्ञान में अंतराल को पहचानने में सक्षम होना कितना महत्वपूर्ण है। ऐसा प्रतीत हो सकता है कि मैं मध्यस्थता करने के लिए आपको बहाना दे रहा था। बिलकुल नहीं! लेकिन वास्तव में, हमारा ज्ञान बातचीत का एक व्यापक विषय है।

मुझे विश्वास है कि आप अपना ज्ञान "बल्ले से सही" शुरू कर सकते हैं और एक निश्चित क्रम में प्रौद्योगिकी (वेब ​​विकास के लिए तकनीकी ढेर - लगभग अनुवादक) का अध्ययन करने की आवश्यकता नहीं है। लेकिन मेरा यह भी मानना ​​है कि चुने हुए क्षेत्र में अनुभव और पेशेवर कौशल का संचय बहुत महत्व रखता है। व्यक्तिगत रूप से, मुझे हमेशा उपयोगकर्ता इंटरफेस बनाने में रुचि रही है।

और मैंने सोचा कि मैं क्या समझता हूं और मुझे क्या महत्वपूर्ण लगता है? बेशक, मैं जावास्क्रिप्ट और रिएक्ट जैसी तकनीकों से अच्छी तरह परिचित हूं। हालांकि, सबसे महत्वपूर्ण चीजें जो अनुभव के साथ आती हैं, मायावी हैं और आमतौर पर सही ढंग से स्पष्ट करने की कोशिश करते समय फिसल जाती हैं। मैंने कभी उन्हें शब्दों में ढालने की कोशिश नहीं की। यह उनमें से कुछ को व्यवस्थित और वर्णन करने का मेरा पहला प्रयास है।

---

आज, प्रौद्योगिकी सीखने के कई अलग-अलग तरीके हैं। 2019 में किस लाइब्रेरी पर दांव लगाना है? और 2020 में? क्या मुझे Vue या React सीखना चाहिए? या कोणीय? Redux या Rx के बारे में क्या? क्या मुझे अपोलो सीखने की ज़रूरत है? REST या ग्राफकलाइन? यहाँ खो जाना आसान है! इसके अतिरिक्त, लेखक से गलती भी हो सकती है।

अनुभूति में मेरी सबसे बड़ी उपलब्धियाँ किसी विशेष तकनीक से संबंधित नहीं हैं। जब मैं एक विशिष्ट UI (उपयोगकर्ता इंटरफ़ेस - लगभग। अनुवादक) समस्या को हल कर रहा था, तो मुझे अधिक समझ में आने लगा। उसी समय, कभी-कभी मुझे अन्य लोगों के पुस्तकालय और पैटर्न मिलते थे जो मुझे समस्या को हल करने में मदद करते थे। और कभी-कभी उन्होंने अपने फैसले (अच्छे और भयानक दोनों) लिखे।
इस संयोजन - समस्या को समझने , उपकरणों के साथ प्रयोग करने और विभिन्न समाधानों को लागू करने से - मुझे सबसे मूल्यवान अनुभव और कौशल दिया गया। यह पोस्ट केवल उन मुद्दों पर केंद्रित है जो मैंने उपयोगकर्ता इंटरफेस के विकास में निपटाए थे।

---

यदि आप उपयोगकर्ता इंटरफ़ेस विकसित कर रहे थे, तो आप संभवतः इन समस्याओं में से कुछ के साथ आए थे - सीधे या पुस्तकालयों का उपयोग करते समय। दोनों ही मामलों में, मेरी सलाह है कि आप पुस्तकालयों के बिना एक साधारण आवेदन पर काम करें, इन समस्याओं को पुन: पेश करने और हल करने का प्रयास करें। उनमें से किसी के लिए भी कोई सच्चा समाधान नहीं है। अनुभव इन समस्याओं को जानने और संभावित समाधानों की खोज के साथ आता है, प्रत्येक की ताकत और कमजोरियों को देखते हुए।

वफ़ादारी (संगति)

आपको पोस्ट पसंद आया और शिलालेख दिखाई दिया: "आप और आपके 3 दोस्तों ने इसकी सराहना की।" आपने फिर से लाइक बटन पर क्लिक किया और शिलालेख गायब हो गया। यह आसान लगता है! लेकिन यह संभव है कि ऐसा शिलालेख स्क्रीन पर कई स्थानों पर मौजूद हो। यह संभव है कि जैसे (उदाहरण के लिए, बटन की पृष्ठभूमि का रंग) के लिए एक अतिरिक्त दृश्य संकेत भी है, जिसे भी बदलना चाहिए। और "लाइकर्स" की सूची, जो पहले सर्वर से प्राप्त हुई थी और जब आप माउस पर मंडराते थे, तो अब आपको अपना नाम शामिल करना चाहिए। और अगर आप किसी दूसरे सेक्शन में गए या बैक बटन पर क्लिक किया, तो पोस्ट को यह नहीं भूलना चाहिए कि यह आपके पसंद का है। जैसा कि आप देख सकते हैं, यहां तक ​​कि एकल उपयोगकर्ता के लिए स्थानीय अखंडता कई कठिन कार्य बनाती है। उसी समय, अन्य उपयोगकर्ता आपके द्वारा प्रदर्शित किए गए डेटा के साथ भी बातचीत कर सकते हैं (उदाहरण के लिए, वह पोस्ट जो आप देख रहे हैं)। हम स्क्रीन के विभिन्न हिस्सों में डेटा को कैसे सिंक्रोनाइज़ करते हैं? हमें सर्वर के साथ स्थानीय डेटा की जांच कैसे और कब करनी चाहिए और परिवर्तन प्राप्त / भेजना चाहिए?

जवाबदेही (जवाबदेही)

लोग बहुत ही सीमित समय के लिए अपने कार्यों के लिए दृश्य प्रतिक्रिया की कमी की अनुमति देते हैं। स्क्रॉलिंग जैसे निरंतर उपयोगकर्ता कार्यों के लिए, आवेदन की प्रतिक्रिया की कमी केवल सबसे छोटी अवधि के लिए संभव है। यहां तक ​​कि 16 मिलीसेकंड पर एक फ्रेम को छोड़ना पहले से ही छोटी और अधूरी लगती है। असतत (एक-बार) कार्यों के लिए, जैसे कि एक क्लिक, कुछ अध्ययनों के अनुसार, उपयोगकर्ता आमतौर पर 100 मिलीसेकंड से कम की प्रतिक्रिया में देरी का अनुभव करते हैं। यदि कार्रवाई में अधिक समय लगता है, तो एक दृश्य संकेतक दिखाना आवश्यक है। हालांकि, कई काउंटरटाइम काम हैं। पृष्ठ टेम्पलेट में एक बदलाव का कारण बनने वाले या कई वैकल्पिक चरणों से गुजरने वाले संकेतक कार्रवाई को "महसूस" करने में अधिक समय ले सकते हैं जो वास्तव में था। इसी तरह, एनीमेशन के एक फ्रेम को छोड़ कर 20 मिलीसेकेंड के भीतर एक अनुप्रयोग की प्रतिक्रिया 30 मिलीसेकेंड के भीतर एक पूर्ण एनीमेशन की तुलना में "महसूस" धीमी हो सकती है। हमारी चेतना बेंचमार्क की तरह काम नहीं करती है। हम ऐप्स को कैसे उत्तरदायी बनाए रखते हैं?

प्रतिक्रिया समय (विलंबता)

कंप्यूटर कंप्यूटिंग और नेटवर्क पर डेटा संचारित करने में समय लगता है। कभी-कभी हम गणना समय को अनदेखा कर सकते हैं यदि यह उपयोगकर्ताओं के उपकरणों पर जवाबदेही को प्रभावित नहीं करता है (हालांकि, सुनिश्चित करें कि आपने पुराने और बजट उपकरणों पर अपने कोड का परीक्षण किया है)। हालांकि, नेटवर्क पर डेटा ट्रांसमिशन के समय को संसाधित करने से बचा नहीं जा सकता है - इसे सेकंड में गणना की जा सकती है! जब हम डेटा या कोड लोड होने की प्रतीक्षा करते हैं तो कोई एप्लिकेशन बस "हैंग" नहीं कर सकता है। इसका मतलब यह है कि किसी भी कार्रवाई के लिए नए डेटा, कोड या परिसंपत्तियों की आवश्यकता होती है जो संभावित रूप से अतुल्यकालिक है और इसे अपने लोड की स्थिति को संभालना चाहिए। यह स्क्रीन और तत्वों के विशाल बहुमत के लिए सच है। कताई स्पिनरों के एक झरना या इंटरफ़ेस में खाली "छेद" प्रदर्शित किए बिना डेटा को प्रसारित करने में देरी को ठीक से कैसे संभालना है? पेज लेआउट बदलाव से कैसे बचें? और निरंतर कोड पुनर्लेखन की आवश्यकता के बिना अतुल्यकालिक निर्भरता कैसे बदलें?

नेविगेशन (नेविगेशन)

हमें उम्मीद है कि जब इसके साथ बातचीत होगी तो इंटरफ़ेस "स्थिर" होगा। तत्व अचानक गायब नहीं होने चाहिए। नेविगेशन, आवेदन के अंदर (उदाहरण के लिए, लिंक) और बाहरी (उदाहरण के लिए, ब्राउज़र में बैक बटन) भी इस सिद्धांत का पालन करना चाहिए। उदाहरण के लिए, किसी उपयोगकर्ता अनुभाग में /profile/likes और /profile/follows निम्न टैब के बीच स्विच करना इस अनुभाग के बाहर खोज फ़ील्ड की सामग्री को शून्य नहीं करना चाहिए। यहां तक ​​कि दूसरी स्क्रीन पर स्विच करने से दूसरे कमरे में चलना चाहिए। लोगों को उम्मीद है कि जब वे वापस आएंगे, तो उन्हें वे सभी चीजें मिलेंगी, जहां उन्होंने उन्हें छोड़ा था (और, शायद, कुछ नई चीजों से खुश होंगे)। यदि आप अपने टेप के बीच में थे, तो प्रोफाइल टैब पर क्लिक किया, और फिर वापस टेप पर लौट आए - फिर आप निश्चित रूप से टेप को फिर से स्क्रॉल नहीं करना चाहते हैं या तब तक प्रतीक्षा करें जब तक टेप की पिछली स्थिति लोड न हो जाए। महत्वपूर्ण संदर्भ खोए बिना उपयोगकर्ता के मनमाने ढंग से नेविगेशन को संभालने के लिए एक एप्लिकेशन कैसे डिज़ाइन करें?

एजिंग (बासांपन)

हम एप्लिकेशन में एक स्थानीय कैश जोड़कर तत्काल बटन का कार्यान्वयन कर सकते हैं। ऐसा करने के लिए, हम आवश्यक डेटा को कैश में संग्रहीत करेंगे (पिछले राज्य से डेटा - लगभग। अनुवादक)। हम डेटा को अद्यतित रखने के लिए सैद्धांतिक रूप से कैश को अपडेट भी कर सकते हैं। हालाँकि, कैशिंग के कार्यान्वयन से नई चुनौतियाँ आती हैं। कैश पुराना हो सकता है। अगर मैंने अवतार को बदल दिया है, तो इसे कैश में अपडेट किया जाना चाहिए। अगर मैंने एक नया पोस्ट प्रकाशित किया है, तो उसे तुरंत कैश में दिखाई देना चाहिए, अन्यथा कैश अमान्य हो जाएगा। ऐसा कोड अंततः बहुत जटिल और बनाए रखने में मुश्किल हो सकता है। क्या होगा अगर प्रकाशन प्रक्रिया विफल हो जाती है? स्मृति में कैश कब तक है? जब हम डेटा सेट को फिर से प्राप्त करते हैं, तो क्या हम पहले कैश्ड डेटा के साथ नए डेटा को जोड़ते हैं, या क्या हम पुराने कैश से छुटकारा पाते हैं और पूरे सेट को फिर से कैश करते हैं? कैश में पेजेशन और सॉर्टिंग को कैसे प्रस्तुत किया जाना चाहिए?

Entropy (Entropy)

ऊष्मप्रवैगिकी का दूसरा नियम लगभग इस प्रकार है: "समय के साथ, सब कुछ पूरी तरह से गड़बड़ हो जाता है" (शब्दशः नहीं, बिल्कुल)। यह यूजर इंटरफेस के लिए भी सही है। हम किसी विशेष उपयोगकर्ता के कार्यों और उनके अनुक्रम की भविष्यवाणी नहीं कर सकते। किसी भी समय, हमारा आवेदन विभिन्न राज्यों में से एक विशाल (विशाल!) संख्या में हो सकता है। हम अपने डिजाइन के अनुसार परिणाम को अनुमानित और सीमित करने के लिए अपनी पूरी कोशिश करते हैं। हम बग के साथ स्क्रीनशॉट को नहीं देखना चाहते हैं और अपने आप को सोचते हैं: "यह कैसे हुआ?" एन संभव राज्यों के लिए, उनके बीच एन × (एन - 1) संभव संक्रमण हैं। उदाहरण के लिए, यदि एक बटन (सामान्य, सक्रिय, होवर, हाइलाइट और अक्षम) के लिए पांच अलग-अलग राज्य संभव हैं, तो बटन को बदलने के लिए जिम्मेदार कोड 5 × 4 = 20 संभव संक्रमणों के लिए सही होना चाहिए - या उनमें से कुछ को स्पष्ट रूप से प्रतिबंधित करें। हम संभावित राज्यों में कॉम्बीनेटरियल वृद्धि से कैसे निपटते हैं और पूर्वानुमान योग्य दृश्य आउटपुट बनाते हैं?

प्राथमिकता (प्राथमिकता)

कुछ चीजें दूसरों की तुलना में अधिक महत्वपूर्ण हैं। हो सकता है कि आपका संवाद इंटरफ़ेस सख्ती से "ऊपर" दिखाई दे, जिस बटन के साथ उसे बुलाया गया था, और मूल कंटेनर से परे जाना चाहिए। या, एक बस-निर्धारित कार्य (यानी, एक क्लिक का परिणाम) लंबे समय से चल रहे कार्य की तुलना में अधिक महत्वपूर्ण हो सकता है जो पहले ही शुरू हो चुका है। जैसे ही एप्लिकेशन ज़ोम्स करता है, इसके अलग-अलग हिस्सों, विभिन्न लोगों या यहां तक ​​कि टीमों द्वारा लिखे गए, सीमित संसाधनों के लिए प्रतिस्पर्धा करना शुरू करते हैं, जैसे कि प्रोसेसर कंप्यूटिंग पावर, नेटवर्क ट्रैफ़िक, स्क्रीन स्पेस, या बंडल आकार। कभी-कभी आप z-index सीएसएस नियम के समान एकल "महत्व" पैमाने पर आइटम वितरित कर सकते हैं। लेकिन आमतौर पर यह कुछ भी अच्छा नहीं होता है । कोई भी डेवलपर ईमानदारी से अपने कोड को महत्वपूर्ण मानता है। लेकिन अगर सब कुछ समान रूप से महत्वपूर्ण है, तो इसका मतलब है - कुछ भी महत्वपूर्ण नहीं है। हम सीमित संसाधनों की लड़ाई के बजाय आवेदन के स्वतंत्र हिस्सों को कैसे इंटरैक्ट कर सकते हैं?

उपलब्धता (सरल उपयोग)

ऐसी साइटें जो विकलांग लोगों के लिए अनुकूलित नहीं हैं, वे एक अत्यधिक विशिष्ट समस्या नहीं हैं। उदाहरण के लिए, इंग्लैंड में हर पांचवें उपयोगकर्ता को इस समस्या का सामना करना पड़ता है ( यहाँ एक दृश्य इन्फोग्राफिक है)। मैंने इसे खुद पर महसूस किया। इस तथ्य के बावजूद कि मैं केवल 26 साल का हूं, मैं शायद ही पतले फोंट और अपारदर्शी रंग योजना वाली साइटों का उपयोग करता हूं। मैं अक्सर ट्रैकपैड का उपयोग करने की कोशिश करता हूं, लेकिन मुझे उस दिन से डर लगता है जब मुझे कीबोर्ड के लिए अनुपयुक्त साइट का उपयोग करना पड़ता है। हमें अपने एप्लिकेशन को विकलांग लोगों के लिए बुरे सपने में नहीं बदलना चाहिए - और अच्छी खबर यह है कि यह इतना मुश्किल नहीं है। आपको समाधान और उपकरण की खोज करके शुरू करने की आवश्यकता है। इसके अलावा, हमें सही निर्णय लेने के लिए डिजाइनरों और डेवलपर्स के लिए इसे सरल और समझने योग्य बनाना चाहिए। हम यह सुनिश्चित करने के लिए क्या कर सकते हैं कि हमारे अनुप्रयोगों की उपलब्धता डिफ़ॉल्ट रूप से सक्षम है, और देर से संशोधन नहीं होना चाहिए?

अंतर्राष्ट्रीयकरण (अंतर्राष्ट्रीयकरण)

हमारे अनुप्रयोगों को दुनिया भर में काम करना चाहिए। हां, लोग अलग-अलग भाषाएं बोलते हैं, लेकिन इसके अलावा, लेखन का समर्थन दाईं से बाईं ओर आवश्यक है, और डेवलपर्स से न्यूनतम प्रयास के साथ। हम आवेदन की जवाबदेही और प्रतिक्रिया समय को खोए बिना विभिन्न भाषाओं और लिपियों का समर्थन कैसे कर सकते हैं?

डिलिवरी (डिलिवरी)

हमें अंतिम उपयोगकर्ता कंप्यूटर पर एप्लिकेशन कोड वितरित करना होगा। हम किस ट्रांसमिशन विधि और प्रारूप का उपयोग करेंगे? इस सवाल में, प्रत्येक उत्तर अपनी ताकत और कमजोरियों के अपने सेट के साथ एक समझौता होगा। उदाहरण के लिए, मूल एप्लिकेशन को अपने विशाल आकार के कारण अग्रिम में अपने सभी कोड डाउनलोड करने होंगे। जबकि वेब एप्लिकेशन में आमतौर पर बहुत कम बूट समय होता है, लेकिन उपयोग के दौरान बहुत विलंबता और डाउनलोड को संभालने के लिए मजबूर किया जाता है। हम कैसे तय करते हैं कि इन दो विकल्पों में से किस प्रकार की देरी का चयन करना है? उपयोगकर्ता उपयोग के आंकड़ों के आधार पर हम प्रतिक्रिया समय का अनुकूलन कैसे करते हैं? सबसे अच्छा निर्णय लेने के लिए हमें किस डेटा की आवश्यकता है?

लचीलापन (लचीलापन)

कोई भी अपने स्वयं के कार्यक्रमों में बग को पूरा करना पसंद नहीं करता है। हालांकि, कुछ कीड़े अनिवार्य रूप से उत्पादन के लिए मिलेंगे। और यह बहुत महत्वपूर्ण है - तब क्या होगा। कुछ कीड़े गलत, लेकिन कड़ाई से परिभाषित और पूर्वनिर्धारित व्यवहार का कारण बनते हैं। उदाहरण के लिए, आपका कोड किसी दिए गए शर्त के लिए अनुपयुक्त स्थिति दिखाता है। लेकिन क्या होगा, अगर बग के परिणामस्वरूप, एप्लिकेशन ने रेंडरिंग को पूरी तरह से रोक दिया? इस मामले में, हम प्रोग्राम के सार्थक निष्पादन को जारी रखने में सक्षम नहीं होंगे, क्योंकि दृश्य आउटपुट निर्धारित नहीं किया जाएगा। फीड से किसी एक पोस्ट को रेंडर करते समय एक त्रुटि को पूरे फीड के रेंडर को "ब्रेक" नहीं करना चाहिए या एप्लिकेशन को अस्थिर अवस्था में नहीं डालना चाहिए, जिससे आगे की त्रुटियां होंगी। हम उन कोड को कैसे लिख सकते हैं जो किसी एक भाग में डेटा प्रदान करते या प्राप्त करते समय त्रुटियों को अलग करते हैं और बाकी एप्लिकेशन का सही संचालन जारी रखते हैं? उपयोगकर्ता इंटरफ़ेस बनाते समय गलती सहिष्णुता का क्या अर्थ है?

अमूर्तता (अमूर्त)

एक छोटे से आवेदन में, हम माथे में उपरोक्त सभी समस्याओं को हार्डकोड और हल कर सकते हैं। लेकिन आवेदन बढ़ने लगते हैं। हम अनुप्रयोग के विभिन्न हिस्सों का पुन: उपयोग, कांटा और संयोजन करना चाहते हैं और इसे अन्य लोगों के साथ मिलकर कर सकते हैं। हम एक पूरे के कुछ हिस्सों के बीच समझने योग्य सीमाओं को परिभाषित करना चाहते हैं जो विभिन्न लोगों द्वारा स्वीकार किए जाएंगे और एक ही समय में बहुत कठोर तर्क से बचें, क्योंकि यह अक्सर काम की प्रक्रिया में बदलता है और विकसित होता है। हम यूआई कार्यान्वयन के विवरण को छिपाने वाले सार कैसे बनाते हैं? हम एप्लिकेशन की वृद्धि के साथ इन समस्याओं की पुनरावृत्ति से कैसे बच सकते हैं?

---

बेशक, और भी कई समस्याएं हैं जिनका मैंने उल्लेख नहीं किया है। यह सूची पूर्ण या संपूर्ण नहीं है। उदाहरण के लिए, मैंने डिजाइन और विकास, डिबगिंग या परीक्षण के विषय के बीच सहयोग के विषय पर नहीं छुआ। शायद हम दूसरी बार इस पर लौटेंगे।

यह डेटा प्राप्त करने के लिए डेटा या लाइब्रेरी प्रदर्शित करने के लिए एक विशिष्ट रूपरेखा के रूप में ध्यान में रखते हुए, इन समस्याओं के बारे में पढ़ने के लिए लुभावना है। लेकिन मेरा सुझाव है कि आप कल्पना करें कि ये समाधान मौजूद नहीं हैं और फिर से पढ़ने की कोशिश करें। आप इन मुद्दों को कैसे हल करने की कोशिश करेंगे? एक साधारण आवेदन पर अपने विचारों को महसूस करने की कोशिश करें। मुझे जीथब पर आपके प्रयोगों के परिणामों को देखकर खुशी होगी। ( ट्विटर पर डैन अब्रामोव को टैग करें और रिपॉजिटरी के लिंक संलग्न करें - लगभग।)।

इन समस्याओं में विशेष रूप से दिलचस्प यह है कि उनमें से ज्यादातर किसी भी पैमाने पर खुद को प्रकट करते हैं। जब आप एक छोटे विजेट पर काम कर सकते हैं, जैसे कि टूलटिप, और ट्विटर या फेसबुक जैसे विशाल अनुप्रयोगों में।

उस एप्लिकेशन से गैर-तुच्छ उपयोगकर्ता इंटरफ़ेस तत्वों के बारे में सोचें जो आप उपयोग करना पसंद करते हैं, और फिर उपरोक्त समस्याओं की सूची के माध्यम से चलते हैं। क्या आप डेवलपर्स द्वारा किए गए ट्रेड-ऑफ का वर्णन कर सकते हैं? खरोंच से समान व्यवहार को पुन: पेश करने का प्रयास करें!

मुझे अच्छे उपयोगकर्ता इंटरफेस विकसित करने, थर्ड-पार्टी लाइब्रेरी और फ्रेमवर्क का उपयोग किए बिना छोटे अनुप्रयोगों में इन समस्याओं के साथ प्रयोग करने के बारे में बहुत कुछ महसूस हुआ। मैं इसे किसी को भी सुझाता हूं जो जटिल इंटरफेस विकसित करते समय समाधान और व्यापार-बंद की गहरी समझ हासिल करना चाहता है।