हाई-स्पीड यूजर इंटरफेस इंटरफेस डिजाइन करने के तीन नियम

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

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

एप्लिकेशन के साथ हाई-स्पीड यूजर इंटरैक्शन के आयोजन के नियम निम्नानुसार तैयार किए जा सकते हैं:

1. गणना को इंटरफ़ेस और इसके प्रतिपादन के साथ बातचीत को अवरुद्ध नहीं करना चाहिए - उपयोगकर्ता को हमेशा अपने हितों का ध्यान केंद्रित करने में सक्षम होना चाहिए।
2. उस ऑब्जेक्ट का पृष्ठ जिसे उपयोगकर्ता ने एक्सेस किया है, उसे उस डेटा का इंतजार किए बिना तुरंत प्रदर्शित किया जाना चाहिए, जिसे ऑब्जेक्ट को लोड करने की आवश्यकता है।
3. नेटवर्क के अनुरोधों को एक बड़े समूह में दूर नहीं जाना चाहिए, तुरंत नहीं भेजा जाना चाहिए; यदि आवश्यक हो तो थोड़े समय के लिए विलंबित, मुड़ा हुआ और प्राथमिकता दी जानी चाहिए।

इस नोट में दी गई जानकारी संगीत सीसु.मे को खोजने और सुनने के लिए मेरे आवेदन के इंटरफ़ेस को डिजाइन करने और विकसित करने में मेरा व्यावहारिक अनुभव है। एक ऐसा अनुप्रयोग जिसमें अंतिम, VKontakte, ex.fm, hypem.com, soundcloud.com, discogs.com, youtube.com जैसी असमान सेवाओं से डेटा की बड़ी परतें सामंजस्यपूर्ण रूप से संयुक्त हैं




प्रदर्शन सुधार के बिना प्रतिक्रिया में सुधार से संबंधित सिफारिशें इंस्टाग्राम एप्लिकेशन के संचालन के बारे में प्रकाशित की गई थीं। लेकिन सिफारिशें नेविगेशन या डेटा प्राप्त करने से संबंधित नहीं थीं, बल्कि इसके विपरीत, वे भेजने से संबंधित थीं।
speakerdeck.com/mikeyk/secrets-to-lightning-fast-mobile-design


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

मैं "तत्काल प्रतिक्रिया" के सिद्धांत के लगातार पालन के परिणामस्वरूप इन नियमों पर आया था, मेरे रास्ते में आने वाली तकनीकी सीमाओं की शर्तों के तहत काम कर रहा है, और जिन प्रयोगों को मैंने लागू किया है।

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

जेफ रस्किन कंप्यूटर इंटरफेस पर एक विशेषज्ञ हैं, जो प्रयोज्य पर लेखों के लेखक हैं और किताब द ह्यूमन इंटरफेस, ऐप्पल कंप्यूटर का एक कर्मचारी, नंबर 31, 70 के दशक के उत्तरार्ध में मैकिंटोश परियोजना शुरू करने के लिए जाना जाता है।

संक्षेप में, मेरे द्वारा उपयोग की जाने वाली पुस्तक से मुख्य शोध पत्र मैं इस प्रकार बना सकता हूं:

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

इसलिए, 2000 में पहली बार प्रकाशित एक पुस्तक से त्वरित प्रतिक्रिया के सिद्धांत द्वारा निर्देशित, मैंने Google को तत्काल खोज शुरू करने से आधा साल पहले habrahabr.ru/post/88494 तत्काल खोज लॉन्च किया था। en.wikipedia.org/wiki/Google_Search#Instant_Search

इंटरफ़ेस के साथ त्वरित उपयोगकर्ता सहभागिता सुनिश्चित करने के लिए आवश्यक प्रत्येक नियम के बारे में अधिक जानकारी:

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

जब आप कलाकार के पृष्ठ पर जाते हैं, तो संपूर्ण पृष्ठ संरचना तुरंत प्रदर्शित होती है।



कलाकार के बारे में पूरी जानकारी के लिए प्रतीक्षा किए बिना, उपयोगकर्ता तुरंत कलाकार की सर्वश्रेष्ठ रचनाओं पर जा सकता है। इस संक्रमण के बाद, सबसे पहले, सर्वश्रेष्ठ गीतों की सूची डाउनलोड की जाएगी, और उसके बाद ही कलाकार के बारे में जानकारी प्राप्त की जाएगी।



कलाकार के पेज को पूरी तरह से प्रदर्शित करने के लिए, दर्ज की गई न्यूनतम डेटा के साथ अधिकतम संभव संरचित जानकारी प्रदान करने की आवश्यकता को देखते हुए, Seeu last.fm में 3 अनुरोधों को कार्यान्वित करता है, hypem.com में 3, discogs.com में 2, soundclub.com में 2।



और कलाकार के पेज के किसी भी हिस्से में जाने के लिए, किसी भी अनुरोध के लिए डेटा लोड होने की प्रतीक्षा करने की आवश्यकता नहीं है।

आप seeu.me/o#/catalog/Pixelord/_ पर स्वयं जा सकते हैं और विभिन्न रचनाओं के बीच जल्दी से स्विच करने का प्रयास कर सकते हैं ताकि यह सुनिश्चित हो सके कि अंतिम चयनित गीत का डेटा जल्द से जल्द डाउनलोड हो जाए। और उसके बाद ही अगली रचना के लिए डेटा और पिछले एक के लिए कुछ डेटा लोड किया जाएगा।

इसके अलावा (एक प्रयोग के रूप में), आप उपयोगकर्ता के अंतिम .fm गीत सूची सूची पृष्ठ को खोलने का प्रयास कर सकते हैं http://seesu.me/o#/users/lfm:yodapunk/tracks , जहां तत्व ऊपर से नीचे तक लोड किए गए हैं। डाउनलोड किए गए लोगों में से सबसे हालिया आइटम का चयन करें और सुनिश्चित करें कि यह लोड किया गया है, जिसके बाद आप तुरंत यह पता लगाने के लिए वापस जा सकते हैं कि आपके द्वारा चुनी गई सूची बारी से भरी हुई है।






इन तीन दृष्टिकोणों का संयोजन और दृश्य ब्लॉकों की अपेक्षाकृत निश्चित स्थान, ऊंचाई और चौड़ाई आवेदन के भीतर एक आरामदायक और अत्यंत तेज गति की अनुमति देती है, जिससे एक आदत बन जाती है। सर्वर से प्रतिक्रिया प्राप्त करने में लगने वाले समय, रेंडरिंग, कंप्यूटिंग और कम करने से एप्लिकेशन को तेज़ गति मिलेगी, और पृष्ठों के बीच संक्रमणों का विनीत एनीमेशन नेटवर्क अनुरोध करते समय विलंब की धारणा को सुचारू कर देगा (सेसू में एनीमेशन का उपयोग करते हुए स्थायी रूप से 120 मिसे)।

मैं इन नियमों के बारे में कैसे आया

(आप पढ़ नहीं सकते हैं)

जब मैंने तकनीकी कठिनाइयों का उल्लेख किया, तो मेरा मतलब था कि मैं उन सेवाओं के नेटवर्क अनुरोधों पर प्रतिबंध लगाता हूं, साथ ही साथ ब्राउज़रों की सीमाएं और भार भी।
उदाहरण के लिए, VKontakte प्रति सेकंड एक से अधिक अनुरोध भेजने से मना करता है।

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

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

Last.fm सेवा के last.fm एपि के पास अनुरोधों की संख्या की कोई सीमा नहीं है, हालांकि, जब पृष्ठ से पृष्ठ पर जल्दी से जा रहे हैं, तो कुछ मामलों में एक साथ निष्पादित अनुरोधों की संख्या 6 (छह) से अधिक हो सकती है। कोई भी ब्राउज़र एक डोमेन में 6 से अधिक कनेक्शन नहीं खोलता है। बड़ी संख्या में अनुरोधों के साथ, इस पर भार ध्यान देने योग्य हो जाता है। मैंने इस तथ्य पर ध्यान आकर्षित किया कि अनुरोध पर डेटा प्राप्त होने से पहले उपयोगकर्ता अपना मन बदल सकता है और किसी अन्य पृष्ठ पर जा सकता है। यह अवलोकन इस तथ्य को स्पष्ट करता है कि अनुरोधों को तत्काल भेजने से उपयोगकर्ता को आवश्यक जानकारी प्राप्त करने के लिए प्रतीक्षा कम नहीं होती है, लेकिन, इसके विपरीत, इसे बढ़ाता है। इसे महसूस करते हुए, मैंने सभी नेटवर्क अनुरोधों को निर्वहन और प्राथमिकता देने का फैसला किया।

प्रारंभिक चरण में अनुरोधों का प्रारंभ विशेष रूप से रचनाओं की सूची वाले पृष्ठों के लिए लागू किया गया था। बाद में, जब मैं last.fm एपीआई का उपयोग करने में बहुत अधिक सक्रिय हो गया, तो नए डेटा स्रोतों को जोड़ते हुए, मैंने सभी पेजों के लिए सभी पृष्ठों के लिए प्राथमिकता और निर्वहन को लागू किया। अब, जब एक मौजूदा कतार में एक नया अनुरोध जोड़ते समय, पृष्ठ से पृष्ठ पर जाते हैं, तो प्राथमिकताओं को स्वचालित रूप से पुन: संयोजित किया जाता है, बदल दिया जाता है, वर्तमान पृष्ठ को ध्यान में रखते हुए और अनुरोधों की आवश्यकता होती है। शेष अनुरोधों को अतिरिक्त क्रम में निष्पादित (पूरा नहीं) किया जाता है।

सर्वर साइड को प्रभावित करने का कोई तरीका नहीं है, साथ ही ऐसे मामलों में जहां सर्वर साइड को सावधानी से हैंडल किया जाना चाहिए, जब डिस्चार्जिंग अनुरोध बहुत मदद कर सकते हैं।

सुना है?
- "गंभीर रूप से एक महान व्यक्ति होगा!"

सितंबर 2010 में आस्थगित भेजने, अनुरोधों और त्वरित प्रतिक्रिया की मदद से, rossomachin और मैंने डोमेन shop.masterhost.ru/templates/default/domains की जाँच का सबसे अच्छा रूप दिया । तकनीकी सीमाओं और सर्वर डेवलपर्स द्वारा हमारी इच्छाओं के सीमित कार्यान्वयन के बावजूद।

इंटरफ़ेस विकास के भविष्य के बारे में

(आप पढ़ नहीं सकते हैं)

यदि हम आधुनिक इंटरफेस से घिरे रहना चाहते हैं, तो हमारे पास उपकरण होना चाहिए, इंटरफेस का वर्णन करने के तरीके, प्रोग्रामिंग भाषाएं जो 14 साल पहले तैयार किए गए इंटरफेस के लिए कम से कम आवश्यकताओं को ध्यान में रखते हैं। इंटरफेस बनाने की दक्षता बहुत बढ़नी चाहिए।

त्वरित प्रतिक्रिया का लाभ अभी भी किसी को भी स्पष्ट नहीं है। कोई व्यक्ति इस सिद्धांत से प्रेरित होता है और ऐसा करने वाले इंटरफेस के साथ बातचीत करने से संभव उत्पादकता। उदाहरण के लिए, इंटरफेस के साथ, जो दर्ज किए गए डेटा की तत्काल व्याख्या प्रदान करते हैं:





उसी समय, त्वरित प्रतिक्रिया के साथ अनुप्रयोगों के न्यूनतम अस्तित्व पर, हम यह निष्कर्ष निकाल सकते हैं कि ऐसे कुछ लोग हैं जो ऐसे अनुप्रयोगों को लागू करने में हाथ थे। इसके लिए स्पष्टीकरण खोजना मुश्किल नहीं है - इस तरह के सिद्धांतों का कार्यान्वयन वास्तव में एक श्रम-गहन प्रक्रिया है।

सिस्टम में लागू होने पर त्वरित प्रतिक्रिया के सिद्धांत के अनुरूप और व्यवस्थित पालन से मुझे अतिरिक्त प्रोग्रामिंग की आवश्यकता होती है, अतिरिक्त इंटरफ़ेस राज्यों को डिजाइन करने का समय।

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

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

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