बोगोटा, कोलंबिया में वेब डेवलपमेंट एजेंसी

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

WhatsApp पर हमें मैसेज करें
Dardo / संपादकीय इलस्ट्रेशन
इस पेज पर

हमारी वेबसाइट डेवलपमेंट में क्या-क्या शामिल है

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

  • सभी तय टेम्पलेट और स्टेट का रिस्पॉन्सिव फ्रंटएंड इम्प्लीमेंटेशन
  • कंटेंट मॉडल, CMS सेटअप और पब्लिशिंग वर्कफ़्लो
  • फ़ॉर्म और तय किए गए इंटीग्रेशन, असली सबमिशन के साथ टेस्ट किए हुए
  • मेटाडेटा, स्ट्रक्चर्ड डेटा और क्रॉल होने लायक पेज स्ट्रक्चर
  • चुने हुए प्रतिनिधि पेजों पर एक्सेसिबिलिटी और परफ़ॉर्मेंस जाँच
  • लॉन्च से पहले की जाँच, डिप्लॉयमेंट और हैंडओवर डॉक्यूमेंटेशन

जब वेब डेवलपमेंट सही शुरुआती कदम हो

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

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

जिस स्टैक पर हम बनाते हैं

हम हर प्रोजेक्ट के हिसाब से स्टैक चुनते हैं और प्रस्ताव में उस चुनाव की वजह बताते हैं। हमारे प्रकाशित काम में TypeScript के साथ Astro और Next.js इस्तेमाल हुए हैं, जो Cloudflare Workers या Vercel पर डिप्लॉय किए गए हैं। कंटेंट-प्रधान मार्केटिंग साइटों के लिए Astro बहुत अच्छा विकल्प है: पेज पहले से HTML में रेंडर होते हैं और JavaScript सिर्फ़ उन्हीं कंपोनेंट को भेजी जाती है जिन्हें उसकी ज़रूरत है, जिससे पेज हल्के रहते हैं और सर्च इंजन के लिए पढ़ना आसान होता है। Next.js उन इंटरफ़ेस के लिए ठीक बैठता है जो ऐप की तरह व्यवहार करते हैं।

जब किसी साइट को सर्वर लॉजिक चाहिए, जैसे पेमेंट, अकाउंट या किसी दूसरी सेवा का डेटा, तो हम उसे वहीं जोड़ते हैं जहाँ ज़रूरत है, हर पेज को ऐप नहीं बनाते। Superame, जो Astro से बना एक सार्वजनिक प्रोजेक्ट लीडरबोर्ड है, अपनी रैंकिंग Neon डेटाबेस में रखता है और खरीदारों को होस्टेड चेकआउट पर भेजता है; उसका सर्वर क्रेडिट जोड़ने से पहले हर साइन किए गए पेमेंट कॉलबैक को सत्यापित करता है। अगर आपकी टीम को किसी ख़ास CMS या प्लेटफ़ॉर्म पर ही रहना है, तो उसे ब्रीफ़ में लिखें; कोटेशन देने से पहले हम बता देंगे कि हम उसके लिए सही टीम हैं या नहीं।

ऐसा CMS जिसे आपकी टीम सच में इस्तेमाल कर सके

कंटेंट मैनेजमेंट सिस्टम तभी काम आता है जब उसके फ़ील्ड आपकी टीम के पब्लिश करने के तरीके से मेल खाएँ। बनाने से पहले हम हर कंटेंट टाइप का नक्शा बनाते हैं: कौन-सा फ़ील्ड कौन एडिट करेगा, किसे मंज़ूरी चाहिए, और कौन-से पेज फ़िक्स्ड लेआउट हैं तथा कौन-से दोबारा इस्तेमाल होने वाली एंट्री। A medio tono में प्रोग्राम और शिक्षक हाथ से बने पेज नहीं, बल्कि आसानी से मेंटेन होने वाली एंट्री हैं, और किसी कोर्स का लिंक शिक्षकों की ऐसी डायरेक्टरी खोलता है जो पहले से उसी वाद्य के हिसाब से फ़िल्टर होती है।

Dardo की अपनी वेबसाइट भी इसी तरह काम करती है: इसके पेज Cloudflare से चलने वाला स्टैटिक Astro बिल्ड हैं, लेख एक अलग हेडलेस CMS में लिखे जाते हैं, और लेख पब्लिश होने पर रीबिल्ड शुरू हो जाता है। स्टैटिक आउटपुट से होस्टिंग सरल रहती है और पेज तेज़ चलते हैं, और एडिटरों को कोड छूना नहीं पड़ता।

इंटीग्रेशन, फ़ॉर्म और परफ़ॉर्मेंस

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

परफ़ॉर्मेंस स्वीकृति का हिस्सा है, बाद की बात नहीं। हम तय करते हैं कि कौन-से टेम्पलेट और डिवाइस पर टेस्ट होगा, और रिलीज़ से पहले लोडिंग व्यवहार और पेज का वज़न जाँचते हैं। A medio tono प्रोडक्शन में Vercel Analytics और Speed Insights चलाता है, और Janus Observatory के इम्प्लीमेंटेशन में बंडल बजट और ब्राउज़र QA शामिल हैं, साथ ही ऐसा रिलीज़ वर्कफ़्लो है जो बिल्ड और विज़ुअल रिग्रेशन जाँचता है।

कई स्थानों वाली और फ़्रैंचाइज़ी वेबसाइटें

जिन व्यवसायों के कई ऑफ़िस, क्लिनिक, स्टोर या फ़्रैंचाइज़ी हैं, उन्हें एक ब्रांड सिस्टम और एक कंटेंट मॉडल चाहिए, जिसमें हर लोकेशन का अपना असली पेज हो: उसका पता, समय, टीम, सेवाएँ, फ़ोटो और उस जगह से सीधे संपर्क का तरीका। मुख्यालय साझा पेज और ब्रांड को नियंत्रित करता है; हर लोकेशन सिर्फ़ अपनी जानकारी एडिट करती है, और भूमिकाएँ इन दोनों को अलग रखती हैं।

Google हर लोकेशन के लिए एक Business Profile और उस लोकेशन का प्रतिनिधित्व करने वाला वेबसाइट पेज माँगता है, और हर लोकेशन को उसके अपने URL के साथ अलग से मार्कअप करने की सलाह देता है। हम लोकेशन पेज और स्ट्रक्चर्ड डेटा इसी तरह बनाते हैं। जहाँ आपका कोई ऑफ़िस नहीं है, वहाँ के लिए हम शहरों के पेज की नकल नहीं बनाते, क्योंकि जिन पेजों में सिर्फ़ जगह का नाम बदला जाता है उन्हें डोरवे पेज माना जाता है।

लॉन्च से पहले हम कैसे टेस्ट करते हैं

बाकी टेम्पलेट पूरे करने से पहले एक प्रतिनिधि पेज बनाकर तय स्क्रीन साइज़ पर टेस्ट किया जाता है, ताकि समस्याएँ तब सामने आएँ जब उन्हें ठीक करना सस्ता हो। स्वीकृति में ये शामिल हैं:

  • कीबोर्ड से इस्तेमाल और दिखाई देने वाला फ़ोकस
  • लंबा, छोटा और गायब कंटेंट, बिना लेआउट बिगड़े
  • लोडिंग, खाली और एरर स्टेट, और जहाँ एनिमेशन हो वहाँ कम मोशन की सेटिंग
  • फ़ॉर्म का असली गंतव्य तक पहुँचना, पुष्टि संदेश के साथ
  • कैनोनिकल URL, रीडायरेक्ट, मेटाडेटा और स्ट्रक्चर्ड डेटा
  • एनालिटिक्स इवेंट, कंसेंट व्यवहार और प्रोडक्शन इंटीग्रेशन

कोड का मालिक कौन है, और हैंडओवर पर आपको क्या मिलता है

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

आपके टाइम ज़ोन में काम करने वाली नियरशोर टीम

Dardo बोगोटा में तीन लोगों की टीम है, जिसका नेतृत्व संस्थापक Nicolás Cerón करते हैं, इसलिए आप सीधे उन्हीं लोगों से बात करते हैं जो आपका कोड लिखते हैं। बोगोटा साल भर UTC−5 पर रहता है, जो डेलाइट सेविंग के दौरान US सेंट्रल टाइम और बाकी साल US ईस्टर्न टाइम के बराबर होता है, इसलिए कॉल, रिव्यू और लॉन्च के दिन आपके सामान्य कामकाजी घंटों में ही आते हैं। इन्क्वायरी फ़ॉर्म में बजट की रेंज USD 5,000 से कम से लेकर 60,000 से अधिक तक है, ताकि आप हमें बता सकें कि आपका प्रोजेक्ट कहाँ बैठता है।

चुनने से पहले कुछ सवाल

वेबसाइट डेवलपमेंट की लागत कितनी होती है?

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

वेब डिज़ाइन और वेब डेवलपमेंट में क्या अंतर है?

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

क्या आप हमारे पास पहले से मौजूद डिज़ाइनों से वेबसाइट बना सकते हैं?

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

आप कौन सा CMS इस्तेमाल करते हैं?

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

आप Next.js की जगह Astro कब इस्तेमाल करते हैं?

जब ज़्यादातर पेज ऐसे कंटेंट हों जिन्हें पहले से रेंडर किया जा सके, जैसे मार्केटिंग साइट, प्रकाशन और सेवा पेज, तब हम Astro इस्तेमाल करते हैं, क्योंकि यह डिफ़ॉल्ट रूप से बहुत कम या बिल्कुल JavaScript नहीं भेजता। जब इंटरफ़ेस का बड़ा हिस्सा एप्लिकेशन की तरह व्यवहार करता है, तब Next.js उपयुक्त है। हमारे प्रकाशित काम में दोनों दिखते हैं: Dardo की अपनी साइट और Superame Astro पर चलते हैं, जबकि A medio tono और Janus Observatory Next.js इस्तेमाल करते हैं।

प्रोजेक्ट खत्म होने पर कोड का मालिक कौन होता है?

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

क्या आप लॉन्च के बाद वेबसाइट का रखरखाव करते हैं?

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

वेबसाइट डेवलपमेंट में कितना समय लगता है?

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

क्या आप हमारी इन-हाउस टीम के साथ मिलकर काम कर सकते हैं?

हाँ, तय दायरे में। हम पूरी वेबसाइट बना सकते हैं, आपके अपने डिज़ाइनरों के डिज़ाइन लागू कर सकते हैं, या आपके डेवलपरों के बनाने के लिए डिज़ाइन दे सकते हैं, और ज़िम्मेदारियों का बँटवारा प्रस्ताव में लिखा जाता है। शुरू करने से पहले हम रिपॉज़िटरी, रिव्यू प्रक्रिया, मीटिंग के समय और हर डिलिवरेबल को कौन मंज़ूर करेगा, यह तय करते हैं, और हम अंग्रेज़ी या स्पैनिश में UTC−5 घड़ी पर काम करते हैं, जो US के कामकाजी दिन से मेल खाती है।

स्रोत और आगे पढ़ें

इस पेज के स्रोत, साथ में मूल प्रकाशकों से और जानकारी।

संबंधित काम और अध्ययन

A medio tono: प्रकाशित प्रोजेक्ट का इंटरफ़ेसडिलीवर की गई क्लाइंट वेबसाइट / संगीत शिक्षाA medio tonoकोई कोर्स, फ़िल्टर की गई शिक्षक डायरेक्टरी और संपर्क हैंडऑफ़ देखें। तारीख़ वाला यह केस एक चालू ग्राहक यात्रा और Dardo के कार्यान्वयन दायरे को दर्ज करता है।प्रोजेक्ट देखें

काम करने वाला सिस्टम तय करें

टेम्पलेट, कंटेंट के स्वामित्व और इंटीग्रेशन की सूची बनाएँ। प्रकाशित कार्यान्वयन कार्य देखें, फिर फ़ॉर्म, एक्सेसिबिलिटी, परफ़ॉर्मेंस और हैंडओवर के स्वीकृति मानदंड तय करें।