लोगों को अपनी AI-निर्मित ऐप में फ़ोटो अपलोड करने देना (बिना उसे ठप्प किए)

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

यह एक टूर है इस बात का कि जब कोई “अपलोड” पर क्लिक करता है तो असल में क्या होता है, वे तीन गलतियाँ जो बाद में काटती हैं, और वे बातें जो आपको बिल्कुल इसी तरह अपने बिल्डर से माँगनी चाहिए ताकि आप इनमें न फँसें।

जब आप किसी ऐप में फ़ोटो अपलोड करते हैं तो असल में होता क्या है?

फ़ोटो अपलोड करना क्रम में चार स्टेप्स को ट्रिगर करता है: आपका फ़ोन फ़ाइल ऐप को सौंपता है, ऐप उसे अलग फ़ाइल स्टोरेज में भेजती है (डेटाबेस में नहीं), ऐप उस फ़ाइल का एक लिंक रिकॉर्ड के साथ सेव करती है, और बाद में जब भी कोई रिकॉर्ड देखता है, वह उसी लिंक की मदद से फ़ाइल फ़ेच करती है।

यह स्टेप-बाय-स्टेप ऐसा दिखता है:

1. फ़ोन आपकी ऐप को फ़ाइल सौंपता है। एक मॉडर्न फ़ोन फ़ोटो अक्सर 4 से 12 मेगाबाइट की होती है। यह कोई मामूली बात नहीं है।
2. आपकी ऐप उस फ़ाइल को स्टोर होने के लिए कहीं भेजती है — आपकी ऐप के डेटाबेस में नहीं, बल्कि फ़ाइलों के लिए बनाए गए एक अलग स्टोरेज बकेट में।
3. आपकी ऐप उस फ़ाइल का एक लिंक डेटाबेस में सेव करती है, बाकी रिकॉर्ड के साथ (यह रसीद इस खर्च से जुड़ी है)।
4. बाद में, जब कोई रिकॉर्ड देखता है, ऐप उस लिंक की मदद से स्टोरेज से फ़ाइल फ़ेच करती है और दिखाती है।

जिस हिस्से में लोग गलती करते हैं वह है स्टेप 2 और 3। वे सोचते हैं कि फ़ोटो “ऐप में सेव” हो जाती है। ऐसा होता नहीं है, और होना भी नहीं चाहिए। फ़ाइलें स्टोरेज में रहती हैं; आपका डेटाबेस बस याद रखता है कि वे कहाँ हैं। यह बँटवारा सही रखिए और आगे की हर चीज़ आसान हो जाती है।

क्या आपको अपलोड की गई फ़ोटो सीधे डेटाबेस में स्टोर करनी चाहिए?

नहीं — और यह अपलोड की सबसे आम गलती है, जो AI बिल्डर कभी-कभी डिफ़ॉल्ट रूप से कर बैठते हैं अगर आप स्पष्ट न हों। 10 MB की फ़ोटो को सीधे अपने डेटाबेस में ठूँसना ऐसा है जैसे अपना फर्नीचर अपने बटुए में रखना। डेटाबेस छोटी, स्ट्रक्चर्ड चीज़ों के लिए बना है — नाम, तारीख़ें, क़ीमतें। इसमें फ़ोटो डालेंगे तो यह धीमा हो जाएगा, बैकअप फूल जाएँगे, और एक दिन जो पेज पहले पलक झपकते लोड होता था, अब छह सेकंड लेने लगेगा क्योंकि वह सौ फुल-रेज़ोल्यूशन इमेज को घसीट रहा है।

इसके बजाय आपको जो चाहिए: फ़ाइल फ़ाइल स्टोरेज में जाती है (आपका बिल्डर इसे “स्टोरेज बकेट” या “ब्लॉब स्टोरेज” कह सकता है), और डेटाबेस में सिर्फ़ लिंक रहता है। इसे सीधे माँगिए:

“अपलोड की गई इमेज को फ़ाइल स्टोरेज में स्टोर करें, डेटाबेस में नहीं। रिकॉर्ड में सिर्फ़ फ़ाइल URL रखें।“

यूज़र्स को गलत फ़ाइल टाइप या बहुत बड़ी फ़ाइल अपलोड करने से कैसे रोकें?

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

एक महिला अपना छोटा कैटरिंग बिज़नेस चलाती है और उसने ग्राहकों के लिए पसंद किए गए केक की फ़ोटो अपलोड करने वाली ऐप बनाई। यह तब तक बढ़िया चली जब तक एक क्लाइंट ने प्रोफ़ेशनल कैमरे से सीधे एक 47 MB की फ़ोटो अपलोड नहीं कर दी। अपलोड अटक गया, क्लाइंट ने हार मान ली, और उसे यह ख़बर मिली कि “आपकी ऐप ख़राब है।” वह ख़राब नहीं थी — बस उसमें साइज़ लिमिट सेट नहीं थी, इसलिए वह एक बड़ी फ़ाइल को निगलने की कोशिश में हमेशा के लिए बैठी रही।

दूसरा उदाहरण: एक फ़्रीलांसर ने एक क्लाइंट पोर्टल बनाया जहाँ लोग “अपना लोगो” अपलोड करते थे। एक क्लाइंट ने .zip फ़ाइल अपलोड कर दी। दूसरे ने 90-पेज की PDF अपलोड कर दी। ऐप ने यह सब स्वीकार कर लिया क्योंकि किसी ने उसे बताया ही नहीं था कि लोगो कैसा होना चाहिए।

ये तीन बातें पहले से तय कर लें:

• कौन-से फ़ाइल टाइप? सिर्फ़ फ़ोटो? तो JPG और PNG स्वीकार करें और बाक़ी को एक फ़्रेंडली मैसेज के साथ रिजेक्ट करें।
• कितनी बड़ी? एक समझदार फ़ोटो लिमिट लगभग 5 से 10 MB होती है। इतनी बड़ी कि एक असली फ़ोन फ़ोटो आ जाए, इतनी छोटी कि कैमरा डंप रुक जाए।
• अगर गलत हो तो क्या? ऐप को यह विनम्रता से बताना चाहिए — “कृपया 10 MB से छोटी JPG या PNG अपलोड करें” — बस अटक नहीं जाना चाहिए।

अपने बिल्डर को बताएँ:

“सिर्फ़ JPG और PNG इमेज को 10 MB तक की इजाज़त दें। अगर कोई कुछ और या बहुत बड़ा अपलोड करे, तो चुपचाप फेल होने के बजाय एक साफ़ मैसेज दिखाएँ।“

जब आपकी ऐप में ढेर सारी फ़ोटो होती हैं तो वह धीमी क्यों लगती है?

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

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

“जब कोई इमेज अपलोड हो, तो प्रीव्यू और लिस्ट के लिए उसका एक छोटा री-साइज़्ड वर्ज़न भी बनाएँ। डिफ़ॉल्ट रूप से छोटा वर्ज़न दिखाएँ और पूरी इमेज तभी लोड करें जब कोई क्लिक करके उसे देखना चाहे।”

आपको यह समझने की ज़रूरत नहीं कि यह कैसे किया जाता है। आपको बस इतना जानना है कि यह मौजूद है, ताकि आप इसे तब माँगें जब आपकी ऐप धीमी हो, न कि उसके बाद।

कुछ और शांत, लेकिन तय करने लायक बातें

ये तीन फ़ैसले अगर आप छोड़ भी दें तो आपकी ऐप नहीं टूटेगी, लेकिन इन्हें अभी तय करना बाद में पीछे जाकर ठीक करने से सस्ता पड़ता है: फ़ाइल को कौन देख सकता है, रिकॉर्ड डिलीट होने पर उसका क्या होता है, और क्या अपलोड फ़ोन पर काम करता है।

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

इसे एक अजनबी की तरह टेस्ट करें

इसे जान-बूझकर उसी तरह तोड़ने की कोशिश करके टेस्ट करें जैसे एक असली यूज़र ग़लती से करेगा — एक सामान्य फ़ोटो, एक ओवरसाइज़्ड फ़ाइल, गलत फ़ाइल टाइप, एक लाइव फ़ोन-कैमरा अपलोड, और एक डिलीशन — इसे पूरा मानने से पहले:

• एक सामान्य फ़ोन फ़ोटो अपलोड करें। क्या वह दिखती है, और क्या प्रीव्यू तेज़ है?
• कुछ बहुत बड़ा अपलोड करें। क्या ऐप आपको एक साफ़ मैसेज के साथ रोकती है, या बस अटक जाती है?
• गलत टाइप अपलोड करें — जहाँ फ़ोटो की उम्मीद हो वहाँ एक PDF। क्या यह नियम समझाती है?
• अपने फ़ोन पर ऐप खोलें और सीधे कैमरे से अपलोड करें।
• एक रिकॉर्ड डिलीट करें और देखें कि क्या उसकी फ़ाइल वैसे ही हैंडल होती है जैसा आपने तय किया था।

अगर ये पाँचों सही से काम करते हैं, तो आपने वे नुकीले कोने पार कर लिए हैं जो ज़्यादातर लोगों को फँसाते हैं।

अपलोड उन फ़ीचर्स में से एक है जहाँ “डेमो में काम करता है” और “एक 12 MB की बिल्ली की फ़ोटो लिए ट्रेन में बैठे किसी अजनबी के लिए काम करता है” के बीच का फ़ासला ठीक ऊपर बताए गए फ़ैसलों जितना ही है। इनमें से कोई भी मुश्किल नहीं है। इन्हें बस छोड़ना आसान है — और इन्हें अभी माँगना बाद में ठीक करने से कहीं ज़्यादा आसान है।

अगर आप अपलोड जोड़ना इसलिए टालते आ रहे हैं क्योंकि यह एक बड़ी टेक्निकल छलांग जैसा लगता था, तो ऐसा नहीं है। अपना बिल्डर खोलें, साइज़ लिमिट और थंबनेल के साथ इमेज स्टोरेज माँगें, और देखें वह आपको क्या देता है। फिर अपने फ़ोन पर जाकर इसे तोड़ने की कोशिश करें — यही असली टेस्ट है, और इसमें बस पाँच मिनट लगते हैं।