நொய்டாவில் உள்ள எந்தவொரு தொழில்நுட்ப மையத்திற்குள்ளும் நுழைந்தால், முழுமையான இணையத் தீர்வுகளை (end-to-end web solutions) வழங்குவதாகக் கூறும் டஜன் கணக்கான முகமைகளை நீங்கள் காண்பீர்கள். அவர்களின் விளக்கக்காட்சிகள் (pitch decks) ஈர்க்கக்கூடியதாக இருக்கும். அவர்களின் விற்பனை குழுக்கள் நம்பிக்கையுடன் பேசுவார்கள். ஆனால் மேலோட்டமாகப் பார்க்காமல் ஆழமாகப் பார்த்தால், ஒரு தெரிந்த பாணி வெளிப்படும். மென்மையான இடைமுகங்களால் (slick interfaces) உங்களை வியக்க வைக்கும் அவர்களின் போர்ட்ஃபோலியோ, ஒரு தரவுத்தள வினவலை (database query) கூட எழுதத் தடுமாறும் ஒரு குழுவை மறைக்கலாம். அல்லது Laravel மற்றும் Node.js பற்றிப் பெருமையாகப் பேசும் நிறுவனம், 2003-ஆம் ஆண்டின் ஒரு ஸ்பிரெட்ஷீட் (spreadsheet) போன்ற பயனர் அனுபவத்தை (user experience) வழங்கலாம். ஒப்பந்தம் கையெழுத்தாகி, முன்பணம் செலுத்தி, திட்டம் ஏற்கனவே திசைமாறிப் போன பிறகுதான் வாடிக்கையாளர்கள் இந்த முரண்பாட்டைக் கண்டறிகிறார்கள். அதற்குள் பாதிப்பு நடந்துவிடுகிறது.

இந்தச் சிக்கலை நீங்கள் தவிர்க்கலாம். இணைய வடிவமைப்பு (web design) மற்றும் இணைய மேம்பாடு (web development) ஆகிய இரண்டும் ஒன்றல்ல என்பதைப் புரிந்துகொள்வதில் இருந்து இது தொடங்குகிறது; இவை இரண்டையும் குழப்பிக் கொள்ளும் ஒருவரைத் தேர்ந்தெடுப்பது உங்கள் பட்ஜெட்டை விரைவாகத் தீர்க்கும் வழியாகும்.

பிக்சலுக்கும் (Pixel) உற்பத்திக்கும் (Production) இடையிலான இடைவெளி

இணைய வடிவமைப்பு என்பது ஒரு தளம் எப்படித் தெரிகிறது மற்றும் எப்படி உணரப்படுகிறது என்பதைக் கவனிப்பதாகும். ஒரு வடிவமைப்பாளர் படிநிலை (hierarchy), வெற்று இடங்கள் (white space), வண்ண உளவியல் (color psychology) மற்றும் ஒரு பயனர் லேண்டிங் பக்கத்திலிருந்து (landing page) செக்அவுட் (checkout) அல்லது தொடர்பு படிவம் (contact form) வரை செல்லும் பாதையைப் பற்றிச் சிந்திக்கிறார். அவர்கள் Figma அல்லது Adobe XD போன்ற கருவிகளில் பணியாற்றுகிறார்கள். இறுதித் தயாரிப்பு என்பது சில நிலையான திரைகள் (static screens) அல்லது கிளிக் செய்யக்கூடிய ஒரு முன்மாதிரி (clickable prototype) ஆகும். இது உங்களுக்கு ஒரு பார்வையை (vision) காட்டுகிறது. ஆனால் இது படிவத் தரவுகளைச் சேகரிக்காது, கட்டணத்தைச் செலுத்தாது அல்லது ஒரே நேரத்தில் ஆயிரம் பார்வையாளர்களுக்குப் பக்கங்களை வழங்காது. இது ஒரு வரைபடம் (blueprint) மட்டுமே, கட்டிடம் அல்ல.

இணைய மேம்பாடு என்பது பொறியியல் கட்டமாகும். ஒரு மேம்பாட்டாளர் (developer) அந்த வரைபடங்களை எடுத்து, உலாவியில் (browser) இயங்கக்கூடிய HTML, CSS மற்றும் JavaScript ஆகியவற்றை எழுதுகிறார். திட்டத்திற்குத் தேவைப்பட்டால், அவர்கள் பேக்எண்ட் லாஜிக் (backend logic) உருவாக்குதல், சர்வரை (server) அமைத்தல், தரவுத்தளத் திட்டத்தை (database schema) வடிவமைத்தல் மற்றும் பேமெண்ட் கேட்வேகள் (payment gateways), ஷிப்பிங் APIs அல்லது அங்கீகார வழங்குநர்கள் (authentication providers) போன்ற மூன்றாம் தரப்பு சேவைகளை ஒருங்கிணைத்தல் போன்ற பணிகளையும் செய்கிறார்கள். இதன் முடிவு உண்மையில் இயங்கக்கூடிய ஒரு நேரடி URL ஆகும்.

இந்த இரண்டு உலகங்களும் வெவ்வேறு மொழிகளில் பேசுகின்றன. ஒரு பொத்தான் (button) அணுகக்கூடியதாக இருக்கிறதா என்று வடிவமைப்பாளர் கவலைப்படுகிறார். அதே பொத்தான் நெட்வொர்க் தாமதத்தின் (network latency) போது ஒரு API அழைப்பைச் சரியாகத் தூண்டுகிறதா என்று மேம்பாட்டாளர் கவலைப்படுகிறார். இரண்டு கவலைகளுமே முக்கியம். ஆனால் ஒரு மொழியை மட்டுமே பேசும் முகமை, மற்றொன்றை பாதியிலேயே விட்டுவிடும்.

"முழுமையான சேவை" (Full Service) எனும் மாயை

நொய்டாவின் முகமைச் சந்தை நெரிசலானது. போட்டி கடுமையாக உள்ளது. எனவே நிறுவனங்கள் வடிவமைப்பு முதல் பயன்பாட்டு நிலை (deployment) வரை அனைத்தையும் தாங்கள் செய்வதாகக் கூறுகின்றன. ஆனால் உண்மை பெரும்பாலும் ஒருதலைப்பட்சமாகவே உள்ளது. ஒரு நிறுவனத்தில் மூன்று திறமையான விஷுவல் வடிவமைப்பாளர்களும், பகுதிநேரமாகக் குறியீடு எழுதும் ஒரு ஜூனியர் மேம்பாட்டாளரும் இருக்கலாம். அல்லது இதற்கு நேர்மாறாக: டைப்போகிராபியை (typography) ஒரு முக்கியமற்ற விஷயமாகக் கருதும் சிறந்த பொறியாளர்கள் இருக்கலாம். இந்தச் சமநிலையின்மை ஆகிய இரண்டுமே வாடிக்கையாளருக்குச் சரியாகப் பயன்படாது.

ஆபத்து அழகியல் சார்ந்தது மட்டுமல்ல. வடிவமைப்பு சார்ந்த அதிகப்படியான குழு, பார்ப்பதற்கு அழகாக இருக்கும் ஆனால் மொபைல் மற்றும் பிற திரைகளுக்கு ஏற்ப (responsively) உருவாக்குவது கடினமான மாதிரிகளை (mockups) உருவாக்கலாம். மேம்பாடு சார்ந்த அதிகப்படியான குழு, உங்கள் தயாரிப்பில் ஒரு பொதுவான அட்மின் டெம்ப்ளேட்டை (generic admin template) ஒட்டிவிட்டு அதை பிராண்டட் என்று அழைக்கலாம். இந்த முரண்பாடு பயனர் ஏற்புச் சோதனையின் (user acceptance testing) போதுதான் தெரியவரும்; அப்போதுதான் தளம் அங்கீகரிக்கப்பட்ட கருத்தாக்கத்தைப் போல இல்லை அல்லது அந்த கருத்தாக்கமே நடைமுறைக்குச் சாத்தியமற்றது என்பதை நீங்கள் உணர்வீர்கள்.

இரைச்சலைத் தவிர்க்க உதவும் மூன்று கேள்விகள்

நீங்கள் எதற்கும் கையெழுத்திடுவதற்கு முன், ஒரு முகமை உண்மையிலேயே இந்த இரண்டு கலைகளையும் கையாள்கிறதா என்பதைச் சோதிக்க இந்தக் கேள்விகளைப் பயன்படுத்துங்கள்.

நீங்கள் வடிவமைத்து உருவாக்கிய மூன்று இணையதளங்களைக் காட்டுங்கள். அவர்கள் ஒரு பகுதியை மட்டும் கையாண்ட உதாரணங்களை ஏற்காதீர்கள். முடிந்தால் Figma கோப்புகள் மற்றும் நேரடி Git repository-ஐக் காட்டச் சொல்லுங்கள். மேம்பாட்டின் நடுப்பகுதியில் ஏற்பட்ட வடிவமைப்பு மாற்றத்தை அவர்கள் எவ்வாறு கையாண்டார்கள் என்று கேளுங்கள். அவர்கள் தடுமாறினால், அவர்கள் ஒரு பகுதியை வெளிப்படையான நிறுவனங்களிடம் (outsourcing) ஒப்படைக்கிறார்கள் அல்லது தங்கள் பங்கினை மிகைப்படுத்திச் சொல்கிறார்கள் என்று அர்த்தம்.

தளம் பயன்பாட்டிற்கு வந்த பிறகு CMS அட்மின் உரிமையாளர் யார்? இது இயல்பானதாகத் தோன்றினாலும், தளம் நேரலையாகச் செல்லும் உற்சாகத்தில் இது பெரும்பாலும் புறக்கணிக்கப்படுகிறது. முதல் நாளிலிருந்தே உங்களுக்குத் தெளிவான சான்றுகள் (credentials), ஆவணங்கள் மற்றும் உள்ளடக்க மேலாண்மை அமைப்பின் (content management system) மீதான கட்டுப்பாடு தேவை. சில முகமைகள் உங்களை அவர்களின் ஹோஸ்டிங்கிற்குள் (hosting) முடக்கும் அல்லது ஒவ்வொரு சிறிய மாற்றத்திற்கும் உங்களிடம் கட்டணம் வசூலிக்கும் பிரத்யேக அமைப்புகளைப் பயன்படுத்துகின்றன. உரிமையை முன்கூட்டியே உறுதிப்படுத்திக் கொள்ளுங்கள்.

எட்டு மாதங்களுக்குப் பிறகு ஒரு புதிய பக்க வகையைச் சேர்ப்பதற்கான நடைமுறை என்ன? இது தளம் எவ்வளவு நுணுக்கமாக வடிவமைக்கப்பட்டுள்ளது என்பதைக் காட்டுகிறது. ஒரு பலவீனமான குறியீட்டு அமைப்பு (brittle codebase), ஒவ்வொரு சிறிய மாற்றத்திற்கும் மேம்பாட்டாளரின் தலையீட்டைத் தேவைப்படுத்தும். நன்கு கட்டமைக்கப்பட்ட தளம், உங்கள் மார்க்கெட்டிங் குழுவிற்கு ஒரு டிக்கெட் (ticket) திறக்காமலேயே CMS மூலம் புதிய லேண்டிங் பக்கங்களை உருவாக்கும் நெகிழ்வுத்தன்மையை வழங்கும். இந்தக் கேள்விக்கு முகமை குழப்பமடைந்தால், அவர்களின் மேம்பாட்டு செயல்முறை தளத்தின் தொடக்கத்துடன் முடிந்துவிட்டது, நீண்ட காலப் பராமரிப்பு (maintainability) பற்றி அவர்கள் சிந்திக்கவில்லை என்று அர்த்தம்.

CMS மறைமுகப் பார்வை (The CMS Blind Spot)

பெரும்பாலான திட்டங்கள் பயன்பாட்டிற்கு வந்த பிறகு அமைதியாகத் தோல்வியடையும் இடம் இதுதான்.

வாடிக்கையாளர்கள் முகப்புப் பக்கத்தின் hero section-ஐப் பற்றி மட்டுமே அதிகம் கவலைப்படுகிறார்கள், ஆனால் அன்றாடப் பணிப்பாய்வை (workflow) மறந்துவிடுகிறார்கள். இணையதளம் தொடங்கிய ஆறு வாரங்களுக்குப் பிறகு, உங்கள் விற்பனைத் குழு விலைப் பட்டியலைப் புதுப்பிக்க விரும்புகிறது. உங்கள் உள்ளடக்க மேலாளர் (content manager) ஒரு ஆய்வு அறிக்கையை (case study) வெளியிட வேண்டும். உங்கள் மனிதவளத் தலைவர் மூன்று புதிய வேலை வாய்ப்புகளைப் பதிவிட விரும்புகிறார். இவற்றில் எதையும் செய்ய ஒரு ஆதரவு டிக்கெட் (support ticket) தாக்கல் செய்து, ஒரு PHP டெம்ப்ளேட்டைத் திருத்த ஒரு டெவலப்பருக்காக இரண்டு வேலை நாட்களுக்காகக் காத்திருக்க வேண்டும் என்றால், உங்கள் இணையதளம் ஏற்கனவே ஒரு தடையல்லவா?

அதனால்தான் CMS-முன்னுரிமை உத்தி (CMS-first strategy) முக்கியமானது. உள்ளடக்க மேலாண்மை அமைப்பு (CMS) ஆரம்ப ஆலோசனைக் கூட்டத்திலிருந்தே விவாதத்தின் ஒரு பகுதியாக இருக்க வேண்டும்; அது இறுதியில் சேர்க்கப்படும் ஒரு கூடுதல் விஷயமாக இருக்கக்கூடாது. உங்கள் குழு குறியீடுகளைத் (code) தொடாமலேயே உரையைத் திருத்தவும், படங்களை மாற்றவும் மற்றும் புதிய பக்கங்களை வெளியிடவும் கூடியிருக்க வேண்டும். இணையதளம் தொடங்கிய பிறகு உள்ளடக்கத்தை யார் நிர்வகிப்பார்கள் என்று ஏஜென்சி உங்களிடம் கேட்கவில்லை என்றால், அவர்கள் உங்கள் செயல்பாட்டு யதார்த்தத்தைப் பற்றிச் சிந்திக்கவில்லை என்று அர்த்தம்.

இரண்டு குழுக்கள் இணைந்து செயல்படத் தவறும்போது ஏற்படும் பாதிப்புகள்

சில வணிகங்கள் வடிவமைப்பு மற்றும் மேம்பாட்டுப் பிரிவினையைத் தீர்க்க தனித்தனி நிறுவனங்களை வேலைக்கு அமர்த்த முயல்கின்றன. தோற்றத்திற்காகவும் உணர்வுக்காகவும் (look and feel) டெல்லியில் உள்ள ஒரு வடிவமைப்பு ஸ்டுடியோவையும், அதை உருவாக்குவதற்காக நொய்டாவில் உள்ள ஒரு டெவலப்மென்ட் நிறுவனத்தையும் கொண்டு வருகிறார்கள். காகித அளவில், அனைவரும் நிபுணர்களாகத் தெரிகிறார்கள். ஆனால் நடைமுறையில், தகவல் பரிமாற்றத் தவறுகள் பெருகுகின்றன.

நிலையான திரைகள் (Static screens) பதிலளிக்கக்கூடிய செயல்பாட்டை (responsive behavior) விளக்காது. ஒரு தேடல் முடிவில் எதுவும் கிடைக்கவில்லை என்றால் என்ன நடக்கும் என்பதை ஒரு மாக்கப் (mockup) விளக்காது. அது hover நிலைகள், loading skeletons, பிழைச் செய்திகள் அல்லது வெற்று நிலைகளை (empty states) விவரிப்பதில்லை. டெவலப்பர் நோக்கத்தைக் கணிக்க வேண்டியுள்ளது. பெரும்பாலும் அவர்கள் தவறாகக் கணிக்கிறார்கள். பிறகு டிசைனர் staging தளத்தைப் பார்த்து அது சரியாக இல்லை என்று கூறுகிறார். வடிவமைப்பு முழுமையடையவில்லை என்று டெவலப்பர் வாதிடுகிறார். இரண்டு குழுக்கள் Slack மற்றும் மின்னஞ்சல் மூலம் விவாதிப்பதில் வாரக்கணக்கில் நேரத்தை வீணடிக்கும்போது, அந்தத் திருத்தப் பணிகளுக்காக வாடிக்கையாளர் பணம் செலுத்துகிறார்.

இதன் இழப்பு வெறும் நிதி சார்ந்தது மட்டுமல்ல. இது உங்கள் முன்னேற்ற வேகத்தையும் (momentum) பாதிக்கிறது. தயாரிப்பு வெளியீடுகள் தாமதமாகின்றன. சந்தைப்படுத்தல் காலண்டர்கள் முடங்குகின்றன. உங்கள் குழுக்கள் இருக்கவே தேவையில்லாத இடைவெளிகளைச் சரிசெய்யும் நேரத்தில், போட்டியாளர்கள் வேகமாக முன்னேறுகிறார்கள்.

பணி ஒப்படைப்பின் உண்மையான விலை

நீங்கள் இதை வாசிக்கும் ஒரு freelancer என்றால், இவை அனைத்தும் வெறும் கோட்பாடு அல்ல. நீங்கள் ஏற்கனவே இத்தகைய சிக்கல்களைச் சந்தித்திருக்கலாம். ஒரு வாடிக்கையாளரின் Figma கோப்பைத் திறக்கும்போது, அதில் மொபைல் பயன்பாட்டிற்கான breakpoints இல்லாத இருபது artboards இருப்பதை நீங்கள் பார்த்திருக்கலாம். முந்தைய டெவலப்பர் டிசைனரைச் சந்திக்காததால், ஒவ்வொரு உள்ளடக்கப் புலமும் (content field) hardcoded செய்யப்பட்ட ஒரு backend-ஐ நீங்கள் பார்த்திருக்கலாம். இரண்டு நாள் வேலையாகக் கருதி நீங்கள் விலை கேட்ட ஒரு பணி, முழு உள்ளடக்கக் கட்டமைப்பையும் (content architecture) மீண்டும் உருவாக்க வேண்டியிருக்கும் என்பதைக் கண்டறிந்திருக்கலாம்.

இந்த இடைவெளிகளைச் சரிசெய்வது செலவு மிக்கது, ஏனெனில் அவை வெறும் தொழில்நுட்பச் சிக்கல்கள் மட்டுமல்ல. அவை குறியீடுகளாக மாற்றப்பட்ட தகவல் தொடர்புத் தோல்விகள்.

முக்கியக் கருத்து

ஒரு இணையதளம் என்பது வெறும் லோகோ அல்ல. அது உங்கள் வணிகத்தை உங்கள் வாடிக்கையாளர்களுடன் காட்சிகள் மற்றும் கட்டமைப்பு ஆகிய இரண்டின் மூலமும் இணைக்கும் ஒரு வாழும் அமைப்பு. நீங்கள் ஏதேனும் ஒரு ஏஜென்சியை வேலைக்கு அமர்த்துவதற்கு முன், அந்தச் சமன்பாட்டின் எந்தப் பகுதியை நீங்கள் உண்மையில் வாங்குகிறீர்கள் என்பதைத் தெரிந்து கொள்ளுங்கள். அவர்களின் செயல்முறையைச் சரிபார்க்கவும், முழுமையான பொறுப்புணர்வை (end-to-end ownership) கோரவும், இணையதளம் பயன்பாட்டிற்கு வந்த பிறகும் CMS-ஐப் புறக்கணிக்க மறுக்கவும். இணையதளம் தொடங்கிய பிறகு, எட்டு மாதங்கள் கழித்து ஒரு செவ்வாய்க்கிழமை அன்று, யாரிடமும் பேசாமல் ஒரு விலையை மாற்ற வேண்டியிருக்கும் போது, அந்தத் திட்டமே வெற்றிகரமாகத் தொடரும்.