നിങ്ങൾ final_FINAL_v3 എന്ന് ടാഗ് ചെയ്ത ഒരു Figma ഫയൽ തുറക്കുന്നു, പക്ഷേ അവിടെ പേര് നൽകാത്ത മുപ്പതോളം ഫ്രെയിമുകളും, ലോക്ക് ചെയ്ത ഒരു ബാക്ക്ഗ്രൗണ്ട് ലെയറും, ഒരു അലങ്കാര വൃത്തം കൂടി അടങ്ങിയ ഒരു ഗ്രൂപ്പിനുള്ളിൽ ഒളിഞ്ഞിരിക്കുന്ന ഒരു ബട്ടണും മാത്രമേ കാണാൻ കഴിയുന്നുള്ളൂ. ഇത് ആരും സമ്മതിക്കാൻ ആഗ്രഹിക്കാത്തത്ര സാധാരണമായ ഒന്നാണ്. അത്തരം കുഴപ്പങ്ങൾ നിറഞ്ഞ വിവരങ്ങൾ Codex പോലുള്ള ഒരു AI കോഡിംഗ് ടൂളിലേക്ക് നൽകിയാൽ, അതിന്റെ ഔട്ട്പുട്ടും അത്തരത്തിലായിരിക്കും. ലാർജ് ലാംഗ്വേജ് മോഡലുകൾ ആണെങ്കിൽ പോലും, "Garbage in, garbage out" (തെറ്റായ വിവരങ്ങൾ നൽകിയാൽ തെറ്റായ ഫലം ലഭിക്കും) എന്ന തത്വം ഇവിടെയും ബാധകമാണ്.
ക്രമരഹിതമായ ഒരു ഹാൻഡ്ഓഫിന്റെ ഘടന
ഡിസൈനർമാർ വേഗത്തിൽ ജോലി ചെയ്യുന്നു. അവർ ഫ്രെയിമുകൾ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യുന്നു, പഴയ പരീക്ഷണങ്ങൾ ഫയലിൽ തന്നെ വെക്കുന്നു, കൂടാതെ കൃത്യമായ auto-layout ഉപയോഗിക്കുന്നതിന് പകരം കാഴ്ചയിൽ മാത്രം നോക്കി കാര്യങ്ങൾ ക്രമീകരിക്കുന്നു. ഫലപ്രദമായ ബട്ടണുകൾക്ക് തൊട്ടടുത്ത് "Frame 3827" പോലുള്ള ലെയർ പേരുകൾ കാണാൻ നിങ്ങൾക്ക് സാധിക്കും. നിങ്ങളുടെ പ്രധാന call-to-action ബട്ടണും അലങ്കാരത്തിനായി ഉപയോഗിച്ച ഗ്രേഡിയന്റ് ബ്ലോബുകളും ഒരേ ഗ്രൂപ്പിൽ തന്നെ വരുന്നു. ഡിവൈസ് മക്കപ്പുകൾ യഥാർത്ഥ ഇന്റർഫേസിനെ ഉള്ളടക്കമായി തോന്നിക്കുന്ന രീതിയിൽ പൊതിഞ്ഞു വെക്കുന്നു. ഹൈഡൻ ലെയറുകൾ ഫയലിൽ തന്നെ അവശേഷിക്കുന്നു, ഇത് ഏതൊരു ഓട്ടോമേറ്റഡ് പാഴ്സറെയും ആശയക്കുഴപ്പത്തിലാക്കും.
Codex ഉപയോഗിക്കുന്ന ഒരു ഡെവലപ്പറെ സംബന്ധിച്ചിടത്തോളം, ഇത് ആരുടെയും മടി കൊണ്ടല്ല. മനുഷ്യരെപ്പോലെ പാറ്റേണുകൾ തിരിച്ചറിയാനുള്ള കഴിവ് AI-ക്ക് ഇല്ല. അത് ലെയർ ട്രീയെ (layer tree) അക്ഷരാർത്ഥത്തിൽ വായിക്കുന്നു. ഒരു ഡിസൈനർ ഒരു ബട്ടണും, ഒരു ഹെഡ്ലൈനും, ഒരു ബാക്ക്ഗ്രൗണ്ട് ബ്ലറും ഒരേ ഗ്രൂപ്പിനുള്ളിൽ വെക്കുമ്പോൾ, Codex അവയെ ഒരേ ഘടനാപരമായ പ്രാധാന്യമുള്ളവയായി കണക്കാക്കുന്നു. ഇതിന്റെ ഫലമായി, നിറങ്ങൾ പരിശോധിക്കുന്നതിന് മുമ്പ് തന്നെ ഘടനാപരമായി തകരാറുള്ള ഒരു ഫ്രണ്ട്എൻഡ് നിങ്ങൾക്ക് ലഭിക്കുന്നു.
മികച്ച ഫലം നൽകുന്ന ഒരു വർക്ക്ഫ്ലോ
വെറുമൊരു കൺവെർട്ടർ എന്നതിലുപരി ഒരു എഡിറ്റർ ആയി പ്രവർത്തിച്ചാൽ, ക്രമരഹിതമായ സ്രോതസ്സുകളിൽ നിന്നും നിങ്ങൾക്ക് വൃത്തിയുള്ള കോഡ് നിർമ്മിക്കാൻ സാധിക്കും. Codex-ന് കൃത്യമായ തീരുമാനങ്ങൾ എടുക്കാൻ ആവശ്യമായ വിവരങ്ങൾ നൽകുകയും, ആ തീരുമാനങ്ങൾ യുക്തിസഹമായ ഫ്രണ്ട്എൻഡ് ആർക്കിടെക്ചറിനുള്ളിൽ നിൽക്കുന്നു എന്ന് ഉറപ്പാക്കുകയും ചെയ്യുക എന്നതാണ് ലക്ഷ്യം.
AI കാണുന്നതിന് മുമ്പ് തന്നെ എല്ലാം വേർതിരിച്ചെടുക്കുക. നിങ്ങൾക്ക് അനുമതിയുണ്ടെങ്കിൽ Dev Mode ഓൺ ചെയ്യുക. ഇൻസ്പെക്ട് പാനലിൽ നിന്ന് നേരിട്ടുള്ള CSS പ്രോപ്പർട്ടികൾ കോപ്പി ചെയ്യുക. കളർ വേരിയബിളുകളും ടെക്സ്റ്റ് സ്റ്റൈലുകളും എക്സ്പോർട്ട് ചെയ്യുക. നിങ്ങളുടെ പ്രോംപ്റ്റിനൊപ്പം ഈ ഘടനാപരമായ വിവരങ്ങളും Codex-ലേക്ക് നൽകുക. സ്ക്രീൻഷോട്ടുകൾ സ്ഥലപരമായ കൃത്യത കാണിക്കുമ്പോൾ, മെറ്റാഡാറ്റ കൃത്യമായ hex കോഡുകളും, ഫോണ്ട് സ്റ്റാക്കുകളും, ലൈൻ ഹൈറ്റുകളും നൽകുന്നു. ഇവ രണ്ടും ചേർന്നാൽ മാത്രമേ മോഡലിന് കൃത്യമായ ഫലം നൽകാൻ കഴിയൂ.
ലേഔട്ട് സിസ്റ്റങ്ങളെക്കുറിച്ച് പ്രോംപ്റ്റുകളിൽ കർശനമായ നിർദ്ദേശങ്ങൾ നൽകുക. "ഈ പേജ് കോഡ് ചെയ്യുക" എന്ന് മാത്രം Codex-നോട് ആവശ്യപ്പെടരുത്. പകരം കൃത്യമായി പറയുക: "നവിഗേഷൻ CSS Flexbox ഉപയോഗിച്ച് നിർമ്മിക്കുക, ഡാഷ്ബോർഡ് ഗ്രിഡ് CSS Grid ഉപയോഗിച്ച് നിർമ്മിക്കുക. ഐക്കണിന് അടുത്തായി നോട്ടിഫിക്കേഷൻ ബാഡ്ജ് വെക്കുന്നതല്ലാതെ മറ്റൊരിടത്തും absolute positioning ഉപയോഗിക്കരുത്." ഡിസൈൻ ഫയലിൽ നിന്നുള്ള x-y കോർഡിനേറ്റുകൾ നേരിട്ട് വായിക്കുന്നതിനാൽ AI ടൂളുകൾ പലപ്പോഴും default ആയി absolute positioning ആണ് ഉപയോഗിക്കുന്നത്. വ്യക്തമായ നിർദ്ദേശങ്ങൾ നൽകിയാൽ ഈ രീതി മാറ്റാൻ സാധിക്കും.
സ്ക്രീൻഷോട്ടുകൾ ഒരു മാർഗ്ഗനിർദ്ദേശമായി ഉപയോഗിക്കുക. ഫ്രെയിമുകൾ 2x റെസല്യൂഷനിൽ എക്സ്പോർട്ട് ചെയ്യുക. അവ ടെക്സ്റ്റ് പ്രോംപ്റ്റിനൊപ്പം അപ്ലോഡ് ചെയ്യുക. Codex ആദ്യമായി കോഡ് തയ്യാറാക്കുമ്പോൾ, സ്ക്രീൻഷോട്ടിന് അടുത്തായി ബ്രൗസറിൽ ആ റിസൾട്ട് തുറന്നു നോക്കുക. സ്പേസിംഗിലെ വ്യത്യാസങ്ങൾ, വിട്ടുപോയ ബോർഡറുകൾ, ഫോണ്ട് വെയ്റ്റിലെ മാറ്റങ്ങൾ എന്നിവ ശ്രദ്ധിക്കുക. AI സാധാരണയായി മൊത്തത്തിലുള്ള ഘടന ശരിയായി നൽകുമെങ്കിലും പാഡിംഗിൽ (padding) തെറ്റുകൾ വരുത്താൻ സാധ്യതയുണ്ട്.
തിരുത്തലുകൾക്കായി തയ്യാറെടുക്കുക. ലഭിച്ച ഔട്ട്പുട്ട് നിങ്ങളുടെ വിഷ്വൽ റെഫറൻസുമായി താരതമ്യം ചെയ്യുകയും തെറ്റുകൾ നേരിട്ട് തിരുത്തുകയും ചെയ്യുക. ഒരു ടെക്സ്റ്റ് ലേബലിനെ AI ഒരു ഇമേജ് ടാഗാക്കി മാറ്റിയേക്കാം, അല്ലെങ്കിൽ ഒരു കാർഡിനെ <article> അല്ലെങ്കിൽ <section> എന്നതിന് പകരം വെറുമൊരു div ആയി നൽകിയേക്കാം. ഈ പരിശോധന നിർബന്ധമാണ്. നിർമ്മിച്ച കോഡിനെ പ്രൊഡക്ഷൻ കോഡായി മാറ്റുന്ന ഘട്ടമാണിത്.
AI എവിടെയാണ് തെറ്റുകൾ വരുത്തുന്നത്
ശ്രദ്ധാപൂർവ്വമായ ഒരു വർക്ക്ഫ്ലോ ഉണ്ടെങ്കിൽ പോലും, ചില ക്രമരഹിതമായ രീതികൾ Codex-നെ എപ്പോഴും കുഴപ്പത്തിലാക്കും.
അലങ്കാരങ്ങൾക്കായി ഉപയോഗിക്കുന്ന അനാവശ്യ ഘടകങ്ങളാണ് (Decorative noise) ഏറ്റവും വലിയ പ്രശ്നം. ഫങ്ഷണൽ ഇന്റർഫേസിന്റെ ഭാഗമല്ലാത്ത ബാക്ക്ഗ്രൗണ്ട് ഗ്ലോകൾ, സ്റ്റാറ്റസ് ബാർ ടെംപ്ലേറ്റുകൾ, ഇലസ്ട്രേറ്റീവ് ഐക്കണുകൾ എന്നിവ പലപ്പോഴും Figma ഫയലുകളിൽ ഉണ്ടാകാറുണ്ട്. വ്യക്തമായ ലേബലുകൾ ഇല്ലെങ്കിൽ, AI ഇവയെ സ്ഥിരമായ DOM എലമെന്റുകളായി കോഡ് ചെയ്യും. ഒരു CSS background അല്ലെങ്കിൽ box-shadow ആയിരിക്കേണ്ട ബ്ലർ ചെയ്ത സർക്കിളുകൾക്കായി പ്രത്യേക div ടാഗുകൾ ഉപയോഗിക്കേണ്ടി വരും.
ലെയറുകളുടെ ഘടനയിലെ മാറ്റം (Flattened hierarchy) കോംപോണന്റ് തിരിച്ചറിയുന്നതിനെ തടസ്സപ്പെടുത്തുന്നു. ഒരു വൃത്തിയുള്ള ഫയലിൽ, ഒരു കാർഡ് എന്നത് ഒരു ഇമേജ്, ഒരു ടൈറ്റിൽ, ഒരു ആക്ഷൻ എന്നിവ അടങ്ങിയ ഒരു auto-layout ഫ്രെയിമാണ്. എന്നാൽ ക്രമരഹിതമായ ഒരു ഫയലിൽ, ഈ മൂന്ന് ഘടകങ്ങളും റൂട്ട് ലെവലിൽ തന്നെയായിരിക്കാം; അവ കാഴ്ചയിൽ ക്രമമായി തോന്നുമെങ്കിലും ഘടനാപരമായി അവ പരസ്പരം ബന്ധപ്പെട്ടവയായിരിക്കില്ല. ഇത് കാരണം Codex കാർഡിന്റെ അതിരുകൾ തിരിച്ചറിയാതെ, അവയെ ഒരു പൊതുവായ പാരന്റ് ഇല്ലാത്ത വെറും എലമെന്റുകളുടെ ഒരു നിരയായി നൽകുന്നു.
അനാവശ്യമായവയിൽ നിന്ന് പ്രധാനപ്പെട്ടവയെ വേർതിരിക്കുക
ഡിസൈനും AI-generated കോഡും തമ്മിൽ ബന്ധിപ്പിക്കുമ്പോൾ ഓരോ ഡെവലപ്പറും നേരിടുന്ന ചില ചോദ്യങ്ങൾ താഴെ പറയുന്നവയാണ്.
നിങ്ങൾ Figma മെറ്റാഡാറ്റയാണോ അതോ സ്ക്രീൻഷോട്ടുകളാണോ കൂടുതൽ വിശ്വസിക്കുന്നത്?
രണ്ടിനെയും വിശ്വസിക്കുക, എന്നാൽ വ്യത്യസ്ത ആവശ്യങ്ങൾക്കായി. കൃത്യമായ മൂല്യങ്ങൾക്കായി (colors, font sizes, spacing tokens, exported assets) Figma metadata ഉപയോഗിക്കുക. ഘടനയിലും (structure) വിഷ്വൽ ഹൈരാർക്കിയിലും (visual hierarchy) സ്ക്രീൻഷോട്ടുകൾക്ക് മുൻതൂക്കമുണ്ട്. ഒരു ലെയർ x: 120, y: 300 എന്ന സ്ഥാനത്താണെന്ന് metadata പറയുകയും, എന്നാൽ സ്ക്രീൻഷോട്ടിൽ അത് ഒരു കാർഡിനുള്ളിൽ സെന്റർ ചെയ്ത നിലയിൽ കാണപ്പെടുകയും ചെയ്യുന്നുണ്ടെങ്കിൽ, ലേഔട്ടിനായി സ്ക്രീൻഷോട്ടും സ്റ്റൈലിംഗിനായി metadata-യും വിശ്വസിക്കുക. സ്ക്രീൻഷോട്ടെ നിങ്ങളുടെ അടിസ്ഥാന സത്യമായി (ground truth) കണക്കാക്കുക. കൃത്യമായ മൂല്യങ്ങൾക്കായി inspect panel ഉപയോഗിക്കുക.
UI-യെ ഡിവൈസ് ഫ്രെയിമുകളിൽ നിന്ന് എങ്ങനെ വേർതിരിക്കാം?
എന്തിനും മുൻപ്, എല്ലാ non-UI ലെയറുകളും മറച്ചുവെക്കുക (hide ചെയ്യുക). ഫോൺ മക്കപ്പ് (phone mockup) അല്ലെങ്കിൽ ഡെസ്ക്ടോപ്പ് ക്രോം (desktop chrome) തിരഞ്ഞെടുത്ത് അതിന്റെ വിസിബിലിറ്റി (visibility) ഓഫ് ചെയ്യുക. ഫയൽ വളരെ സങ്കീർണ്ണമാണെങ്കിൽ (messy), ടെംപ്ലേറ്റും ഉള്ളടക്കവും (content) തിരിച്ചറിയാൻ പ്രയാസമാണെങ്കിൽ, ഒന്നിലധികം സ്ക്രീനുകളിൽ ആവർത്തിച്ചു വരുന്ന ഘടകങ്ങൾക്കായി തിരയുക. സ്റ്റാറ്റസ് ബാർ (status bar), ഹോം ഇൻഡിക്കേറ്റർ (home indicator), നാവിഗേഷൻ ഷെൽ (navigation shell) എന്നിവ സാധാരണയായി ഒരേ സ്ഥാനങ്ങളിൽ തന്നെയായിരിക്കും. യഥാർത്ഥ ബട്ടണുകൾ, ഫോമുകൾ, ഉള്ളടക്കം എന്നിവ മാറിക്കൊണ്ടിരിക്കുന്ന മധ്യഭാഗത്തായിരിക്കും. എല്ലാ സ്ക്രീനുകളിലും ഒരേപോലെ കാണപ്പെടുന്നവയെല്ലാം മറച്ചുവെക്കുക. ബാക്കിയാകുന്നത് നിങ്ങളുടെ യഥാർത്ഥ ഇന്റർഫേസ് ആയിരിക്കും.
ക്രമരഹിതമായ ഒരു ഫയലിൽ കമ്പോണന്റ് അതിരുകൾ (component boundaries) എങ്ങനെ കണ്ടെത്താം?
വിഷ്വൽ ക്ലസ്റ്ററിംഗ് (visual clustering) ശ്രദ്ധിക്കുക, തുടർന്ന് സ്പേസിംഗ് (spacing) ഉപയോഗിച്ച് അത് ഉറപ്പുവരുത്തുക. നാല് ഘടകങ്ങൾ ഒരേപോലെ 16px ഗ്യാപ്പിൽ ഒരുമിച്ച് നിൽക്കുകയും ഒരേ ബാക്ക്ഗ്രൗണ്ട് ഫിൽ (background fill) പങ്കിടുകയും ചെയ്യുന്നുണ്ടെങ്കിൽ, ഡിസൈനർ അവ ഗ്രൂപ്പ് ചെയ്തിട്ടില്ലെങ്കിൽ പോലും അവ ഒരു കൺടെയിനറിനുള്ളിൽ (container) ആയിരിക്കാൻ സാധ്യതയുണ്ട്. തുടർച്ചയായ സ്റ്റാക്കിംഗിനായി (consecutive stacking) Figma ലെയർ ലിസ്റ്റ് പരിശോധിക്കുക.