वेब एप्लिकेशन के लिए एक अलर्ट सिस्टम डिजाइन करना

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

कार्य का सार

दिया: सहयोग वेब अनुप्रयोग। सादगी के लिए, हम मानते हैं कि यह एक CRM या टास्क ट्रैकर है।
आवश्यक: उपयोगकर्ताओं को समय पर ढंग से घटनाओं के बारे में सूचित करने के लिए, जिसमें उनकी प्रतिक्रिया की आवश्यकता होती है।

क्या समस्या है?

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

पहला पैनकेक पहला त्वरित फिक्स

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



परिवर्तनों की एक बड़ी सूची के अलावा, यह "नई क्या है?"

• यह ठीक से दिखाई नहीं देता है कि डेटा में क्या परिवर्तन हुए (कौन सा क्षेत्र बदल गया है और कैसे)
• यह ज्ञात नहीं है कि इन परिवर्तनों को किसने और कब किया था।
• यह स्पष्ट नहीं है कि इन परिवर्तनों के लिए किसी भी प्रतिक्रिया की मुझे आवश्यकता है (एक उपयोगकर्ता के रूप में)

ऐसा लगता है कि इन सभी सवालों का जवाब देने के लिए एक कार्रवाई लॉग है जो प्रत्येक लेनदेन के बारे में सबसे विस्तृत जानकारी संग्रहीत करता है:



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

आज दोपहर 12:48 बजे इवानोव ने मामला P4D1 पूरा किया : आवेदन दाखिल करने के लिए दस्तावेजों की तैयारी ।
पेट्रोव को मामला P4D2 सौंपा गया है : ग्राहक से मूल आवेदन प्राप्त करना ।

यह तब है जब मैं इन इवानोव्स और पेत्रोव्स का नेता हूं और जितना संभव हो उतना उन्हें नियंत्रित करना चाहता हूं। अगर मैं पेत्रोव हूं, तो इस रूप में अलर्ट प्राप्त करना मेरे लिए अधिक सुविधाजनक होगा:

आपको P4D2 को सौंपा गया है : क्लाइंट से मूल एप्लिकेशन प्राप्त करना । समय सीमा 2 दिन है।

यह पता चला है कि अलर्ट को अलग-अलग उपयोगकर्ताओं और विभिन्न घटनाओं (धन्यवाद, टोपी) के लिए अलग-अलग कॉन्फ़िगर किया जाना चाहिए। यह विश्लेषण करने का समय है कि उपयोगकर्ताओं को वास्तव में कब और क्या अलर्ट चाहिए।

अलर्ट का वर्गीकरण

घटना के स्रोत से

• मेरे हित में डेटा परिवर्तित किया गया है। उदाहरण के लिए, यदि कोई कार्य मुझे सौंपा गया है, तो मैं यह जानना चाहता हूं। यदि ऐसे कार्य बनाए जाते हैं या बदले जाते हैं जिनका मुझसे कोई लेना-देना नहीं है, तो मुझे कोई दिलचस्पी नहीं है।
• समय में सेट बिंदु आ गया है। उदाहरण के लिए, एक हफ्ते पहले हम एक ग्राहक से सहमत थे कि मैं उसे आज 15:00 बजे फोन करूंगा। यदि इस सप्ताह यह मेरा एकमात्र समझौता नहीं है, तो संभावना है कि मैं इसे सुरक्षित रूप से भूल जाऊंगा। तो यह एक अनुस्मारक प्राप्त करने के लिए सही समय पर (या कुछ समय पहले) मेरे लिए उपयोगी होगा।
• एक विशिष्ट घटना हुई है। उदाहरण के लिए, एप्लिकेशन को गलत पासवर्ड या निषिद्ध आईपी पते से दर्ज करने का प्रयास किया गया था। यह (मुझे आवेदन के व्यवस्थापक के रूप में) यह उत्तेजित कर सकता है।

जिनके द्वारा अधिसूचित किए जाने की आवश्यकता है

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

अधिसूचना विधि द्वारा

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

शैल्फ जीवन द्वारा

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

परिणाम

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



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

निष्कर्ष

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