dApp का उपयोग करने वाले व्यक्ति से शुरुआत करें
एक dApp को अपने मुख्य कार्य को वॉलेट या कॉन्ट्रैक्ट कार्रवाई प्रकट होने से पहले समझने में आसान बनाना चाहिए। हम यह मैप करके शुरू करते हैं कि कोई सदस्य क्या करने आता है, फिर प्रत्येक चरण को उन स्क्रीन और डेटा से जोड़ते हैं जिनकी एप्लिकेशन को आवश्यकता है।
वह पहली बातचीत सरल हो सकती है। हमें बताएं कि उत्पाद किसके लिए है, लोगों को क्या करने में सक्षम होना चाहिए, और पहले से क्या मौजूद है। शुरुआत करने के लिए एक मोटा स्केच या कुछ नोट्स पर्याप्त हैं। हम उन्हें पहले रिलीज़ की एक साझा तस्वीर में बदल देते हैं, जिसमें वे हिस्से शामिल हैं जिन्हें तकनीकी निर्णयों की आवश्यकता है।
उदाहरण के लिए, एक NFT प्रोजेक्ट चाह सकता है कि सदस्य एक संग्रह का पता लगाएं और फिर एक ऑन-चेन कार्रवाई करें। हम उन हिस्सों को अलग कर सकते हैं जिन्हें कनेक्टेड वॉलेट की आवश्यकता है, उन हिस्सों से जो सभी के लिए खुले रहना चाहिए। यदि उत्पाद को नए कॉन्ट्रैक्ट की भी आवश्यकता है, तो हम एप्लिकेशन योजना को स्मार्ट कॉन्ट्रैक्ट डेवलपमेंट के साथ समन्वयित कर सकते हैं। व्यापक तकनीकी तस्वीर के लिए, Web3 डेवलपमेंट एक dApp से परे जुड़े उत्पाद कार्य को कवर करता है।
तीन स्पष्ट चरणों में निर्माण का मानचित्रण करें
एक उपयोगी dApp योजना विचार को उपयोगकर्ता कार्यों, एकीकरणों और पहले रिलीज़ निर्णय के माध्यम से ले जाती है। ये तीन चरण विकास शुरू होने से पहले महत्वपूर्ण विकल्पों को दृश्यमान रखते हैं।
- यात्रा का वर्णन करें। हम उन कार्यों को सूचीबद्ध करते हैं जो एक सदस्य को करना चाहिए, ऐप खोलने से लेकर मुख्य कार्य पूरा करने तक। हम ध्यान देते हैं कि इंटरफ़ेस को कहाँ किसी विकल्प को समझाने या प्रतिक्रिया दिखाने की आवश्यकता है।
- कनेक्शन इकट्ठा करें। हम उन कॉन्ट्रैक्ट, वॉलेट, नेटवर्क और मौजूदा सेवाओं की समीक्षा करते हैं जिनके साथ उत्पाद को काम करना चाहिए। हम यह भी नोट करते हैं कि प्रत्येक स्क्रीन को कौन सी जानकारी दिखानी है।
- पहला रिलीज़ चुनें। हम सहमत होते हैं कि प्रारंभिक निर्माण में कौन सी स्क्रीन और एकीकरण शामिल हैं। अन्य विचार एक अनुवर्ती सूची पर रह सकते हैं, बजाय इसके कि वे चुपचाप बीच में काम में शामिल हो जाएं।
कल्पना करें कि आपकी टीम के पास पहले से एक उत्पाद स्केच और एक कॉन्ट्रैक्ट है, लेकिन डेटा दृश्य अभी भी अनिश्चित हैं। हम पुष्ट किए गए भागों को चिह्नित कर सकते हैं, खुले प्रश्नों को सूचीबद्ध कर सकते हैं, और सहमत हो सकते हैं कि कार्यान्वयन से पहले क्या उत्तर दिया जाना चाहिए। यदि उत्पाद को एक अलग सार्वजनिक साइट की आवश्यकता है, तो Web3 वेबसाइट और लैंडिंग डेवलपमेंट उस सतह को ऐप योजना में मिलाए बिना कवर कर सकता है।
वॉलेट और ऑन-चेन डेटा कहाँ मिलना चाहिए?
वॉलेट प्रवाह और डेटा दृश्य को एक ही उपयोगकर्ता कार्य का समर्थन करना चाहिए। हम उन्हें एक साथ योजना बनाते हैं, ताकि कोई सदस्य समझ सके कि ऐप क्या दिखाता है और कनेक्शन की आवश्यकता क्यों है।
वॉलेट चरण
हम उन क्षणों का मानचित्रण करते हैं जिनमें वॉलेट पते या उपयोगकर्ता-अनुमोदित कार्रवाई की आवश्यकता होती है। इंटरफ़ेस को 3 बुनियादी स्थितियों के लिए जिम्मेदार होना चाहिए: डिस्कनेक्टेड, कनेक्टेड और ऐप पर वापस आना। हम यह भी सहमत होते हैं कि ऐप अगले चरण की व्याख्या कैसे करता है, बजाय इसके कि लोगों को बिना संदर्भ के वॉलेट प्रॉम्प्ट की व्याख्या करने के लिए छोड़ दिया जाए।
डेटा जिसका लोग उपयोग कर सकते हैं
इंडेक्सिंग पर विचार करना तब उचित है जब सदस्यों को ऑन-चेन रिकॉर्ड खोजने या व्यवस्थित करने की आवश्यकता होती है। हम उन प्रश्नों से शुरू करते हैं जिनका स्क्रीन को उत्तर देना चाहिए, फिर उस जानकारी के स्रोत और प्रस्तुति की पहचान करते हैं। एक एकल खाता दृश्य एक खोजने योग्य गतिविधि इतिहास से भिन्न डेटा कार्य की मांग कर सकता है।
मान लीजिए कोई संग्रहकर्ता पिछली कार्रवाई की जांच करने के लिए वापस आता है। हम पता लगा सकते हैं कि स्क्रीन को किस जानकारी की आवश्यकता है और तय कर सकते हैं कि कोई मौजूदा स्रोत पर्याप्त है या नहीं। आप जो रिकॉर्ड या दृश्य दिखाना चाहते हैं, उनके उदाहरण लाएं। जब वॉलेट कार्यक्षमता अपने आप में एक व्यापक उत्पाद है, तो डीएपी डेवलपमेंट एक अलग विकल्प है।
शांत क्षणों को डिज़ाइन का हिस्सा बनाएं
एक NFT कलाकार की कल्पना करें जिसके छोटे अनुयायी हैं, ठीक उस समय जब उत्तर देने वाला एकमात्र व्यक्ति छुट्टी पर चला जाता है। एक नया सदस्य संग्रह के बारे में प्रश्न और dApp में एक कार्रवाई के साथ आता है। हम इंटरफ़ेस में अगले चरण को दृश्यमान बनाएंगे, ताकि उत्पाद इसे समझाने के लिए किसी के ऑनलाइन होने पर निर्भर न रहे।
उस तरह का क्षण उत्पाद समीक्षा का हिस्सा है, न कि केवल एक सहायता योजना का। हम देखते हैं कि पहली बार आने वाला सदस्य क्या देखता है, जानकारी गायब होने पर क्या होता है, और कार्रवाई के बाद ऐप कैसे प्रतिक्रिया करता है। फिर हम सहमत होते हैं कि किन स्थितियों को डिज़ाइन और परीक्षण करने की आवश्यकता है।
निर्माण कार्य से पहले, हम जाँचते हैं:
- वह मुख्य कार्य जो एक नए सदस्य को पूरा करना चाहिए।
- वॉलेट कनेक्ट किए बिना क्या खोजा जा सकता है।
- डेटा लोड होने या अनुपलब्ध होने पर कौन सा संदेश दिखाई देता है।
- कार्रवाई सबमिट होने के बाद सदस्य क्या देखता है।
यह समीक्षा इंटरफ़ेस को वास्तविक उपयोग में आधारित रखती है। यह आपको यह तय करने में भी मदद करता है कि पहले रिलीज़ में क्या शामिल है और आपके पास अधिक प्रतिक्रिया आने तक क्या इंतजार कर सकता है।
हैंडऑफ के माध्यम से काम को दृश्यमान रखें
एक अच्छा हैंडऑफ दिखाता है कि क्या बनाया गया था, सहमत उपयोगकर्ता प्रवाहों की जाँच कैसे की गई, और कौन सी निर्भरताएँ शेष हैं। हम दो समीक्षा बिंदुओं का उपयोग करते हैं, एक कार्यान्वयन से पहले और एक हैंडऑफ के पास। कार्यान्वयन से पहले, हम सहमत सुविधाओं की पुष्टि करते हैं। हैंडऑफ के पास, हम आपके साथ पूर्ण किए गए कार्य पर चलते हैं।
निर्माण के दौरान, हम नियोजित फ्रंटएंड स्थितियों और एकीकरणों की उपयोगकर्ता यात्रा के विरुद्ध जाँच करते हैं। हम खुले प्रश्नों को दृश्यमान रखते हैं और सहमत कार्य को बदलने से पहले नए अनुरोधों पर चर्चा करते हैं। हैंडऑफ पर, हम एप्लिकेशन पर चलते हैं, कार्यान्वयन नोट्स साझा करते हैं, और किसी भी अनुवर्ती कार्य की पहचान करते हैं जिस पर आपकी टीम विचार करना चाहती है।
वॉलेट प्रदाता, नेटवर्क, कॉन्ट्रैक्ट और डेटा सेवाएँ हमारे नियंत्रण से बाहर रहती हैं। उनकी उपलब्धता, लेन-देन हैंडलिंग, अपडेट और संगतता बदल सकती है, इसलिए हम यह वादा किए बिना सहमत ऐप व्यवहार को सत्यापित करते हैं कि वे बाहरी सिस्टम कैसे संचालित होंगे।
शुरू करने के लिए, हमें अपने उत्पाद नोट्स, इंटरफ़ेस ड्राफ्ट, उपलब्ध कॉन्ट्रैक्ट विवरण और सदस्यों को आवश्यक डेटा के उदाहरण भेजें। Brand Community आपके साथ उनकी समीक्षा करेगा, खुले प्रश्नों को स्पष्ट करेगा, और एक पहली-रिलीज़ योजना तैयार करेगा जिस पर आप एक स्पष्ट निर्णय ले सकते हैं।
यह कैसे काम करता है
- उत्पाद की तस्वीर साझा करेंहमें बताएं कि dApp किसकी सेवा करता है, सदस्यों को क्या करना है और आपके पास पहले से क्या है।
- कनेक्शन का पता लगाएंहम उन वॉलेट, कॉन्ट्रैक्ट, नेटवर्क और डेटा आवश्यकताओं की समीक्षा करते हैं जो उन कार्यों का समर्थन करते हैं।
- पहले रिलीज़ पर सहमत होंहम तय करते हैं कि निर्माण में कौन सी सुविधाएँ शामिल हैं और हैंडऑफ को क्या कवर करना चाहिए।
- प्रवाह बनाएं और जाँचेंहम सहमत कार्य को लागू करते हैं और सदस्य यात्रा के विरुद्ध इसकी समीक्षा करते हैं।
- हैंडऑफ पर चलेंहम आपको पूर्ण किया गया कार्य दिखाते हैं, नोट्स साझा करते हैं और शेष निर्भरताओं की पहचान करते हैं।
अक्सर पूछे जाने वाले प्रश्न
मुझे अपनी पहली dApp बातचीत में क्या लाना चाहिए?
एक संक्षिप्त उत्पाद विवरण, मुख्य सदस्य कार्य और पहले से बना कुछ भी लाएं। इंटरफ़ेस स्केच, कॉन्ट्रैक्ट विवरण और आप जो डेटा दिखाना चाहते हैं उसके उदाहरण भी उपयोगी हैं। यहां तक कि 3 उपयोगकर्ता कार्यों की एक सरल सूची भी हमें शुरू करने के लिए एक व्यावहारिक जगह देती है।
क्या आप dApp इंटरफ़ेस को हमारे मौजूदा कॉन्ट्रैक्ट के आसपास बनाएंगे?
हाँ। हम मौजूदा कॉन्ट्रैक्ट के आसपास फ्रंटएंड और वॉलेट प्रवाह की योजना बना सकते हैं। उपलब्ध कॉन्ट्रैक्ट जानकारी साझा करें और समझाएं कि सदस्यों को क्या करना है। हम कनेक्शन बिंदुओं की समीक्षा करेंगे, किसी भी अस्पष्ट चीज़ को नोट करेंगे, और सहमत होंगे कि पहले रिलीज़ में कौन सी सुविधाएँ शामिल हैं।
आप कैसे तय करते हैं कि dApp को इंडेक्सिंग की आवश्यकता है या नहीं?
हम उन प्रश्नों से शुरू करते हैं जिनका आपके सदस्यों को ऐप से उत्तर चाहिए। यदि उन्हें गतिविधि में रिकॉर्ड खोजने, व्यवस्थित करने या देखने की आवश्यकता है, तो इंडेक्सिंग उपयोगी हो सकती है। आपके मन में रिकॉर्ड या स्क्रीन के कुछ उदाहरण साझा करें, और हम डेटा आवश्यकता को उत्पाद से मैप करेंगे।
क्या ऐप किसी के कनेक्ट होने से पहले उपयोगी जानकारी दिखा सकता है?
हाँ, जब उत्पाद प्रवाह इसकी अनुमति देता है। हम पहचान करते हैं कि कौन सी जानकारी बिना वॉलेट के खोजी जा सकती है और किन कार्यों के लिए कनेक्शन की आवश्यकता है। उदाहरण के लिए, एक सार्वजनिक संग्रह दृश्य की योजना एक सदस्य कार्रवाई से अलग से बनाई जा सकती है जिसके लिए वॉलेट अनुमोदन की आवश्यकता है।
dApp बनाने में आमतौर पर कितना समय लगता है?
हम सुविधाओं, मौजूदा सामग्रियों और एकीकरणों की समीक्षा करने के बाद समय निर्धारित करते हैं। एक केंद्रित फ्रंटएंड प्रवाह और कई कॉन्ट्रैक्ट या डेटा कनेक्शन वाले ऐप को अलग-अलग योजनाओं की आवश्यकता होती है। हम काम के विरुद्ध माइलस्टोन पर सहमत होते हैं, ताकि आप प्रत्येक समीक्षा पर देख सकें कि आगे क्या है।
क्या आप सुनिश्चित कर सकते हैं कि हर वॉलेट और डेटा कनेक्शन काम करता रहेगा?
नहीं। वॉलेट प्रदाता, नेटवर्क, कॉन्ट्रैक्ट और डेटा सेवाएँ अपनी उपलब्धता, हैंडलिंग या संगतता बदल सकती हैं। हम चयनित एकीकरणों के लिए सहमत एप्लिकेशन व्यवहार का निर्माण और परीक्षण कर सकते हैं, फिर निर्भरताओं का दस्तावेजीकरण कर सकते हैं। उदाहरण के लिए, हैंडऑफ दिखा सकता है कि ऐप किस कनेक्शन की अपेक्षा करता है और आपकी टीम को क्या मॉनिटर करना चाहिए।
अपने प्रोजेक्ट के बारे में बताएं
चार त्वरित प्रश्नों के उत्तर दें और एक मैनेजर एक घंटे के भीतर योजना, समय और मूल्य सीमा भेजेगा। सब कुछ गोपनीय रहता है।
फ़ॉर्म लोड हो रहा है…