When an AI tool is generating content, processing a dataset, or running an autonomous task, the user needs a clear way o

ഒരു AI ടൂൾ ഉള്ളടക്കം നിർമ്മിക്കുകയോ, ഒരു ഡാറ്റാസെറ്റ് പ്രോസസ്സ് ചെയ്യുകയോ, അല്ലെങ്കിൽ ഒരു സ്വയംഭരണാധികാരമുള്ള (autonomous) ടാസ്ക് പ്രവർത്തിപ്പിക്കുകയോ ചെയ്യുമ്പോൾ, ഉപയോക്താവിന് വ്യക്തമായ ഒരു പിന്മാറ്റ മാർഗ്ഗം ആവശ്യമാണ്. മിക്ക ഇന്റർഫേസുകളും എമർജൻസി സ്റ്റോപ്പിനെ (emergency stop) ഒരു രണ്ടാംകിട കാര്യമായിട്ടാണ് കാണുന്നത്. അവർ ഒരു ബട്ടണിന്റെ ലേബൽ "Stop" എന്നതിൽ നിന്ന് "Stopped" എന്നതിലേക്ക് മാറ്റുന്നു, ജോലി പൂർത്തിയായി എന്ന് കരുതുന്നു. നിറം ചാരനിറമായി മാറാം. ആനിമേഷൻ സുഗമമായിരിക്കാം. എന്നിരുന്നാലും ടാസ്ക് സെർവറിൽ തുടർന്നുക്കൊണ്ടിരിക്കും, എന്തോ തെറ്റുപറ്റിയെന്ന് ഉപയോക്താവിന് അറിയില്ല. ഒരു സ്ക്രീൻ റീഡറിനെ (screen reader) ആശ്രയിക്കുന്ന ഒരാളെ സംബന്ധിച്ചിടത്തോളം, ഈ പരാജയം കൂടുതൽ ഗുരുതരമാണ്. പ്രക്രിയ അവസാനിച്ചു എന്ന ഓഡിയോ സ്ഥിരീകരണം അവർ കേൾക്കുന്നു, എന്നാൽ പശ്ചാത്തലത്തിൽ ജോലി നിശബ്ദമായി തുടർന്നു കൊണ്ടിരിക്കുന്നു. ഇതൊരു ചെറിയ ബഗ്ഗല്ല. ഇത് വിശ്വാസ്യതയുടെ തകർച്ചയാണ്.

നിശബ്ദമായ ഒരു സ്റ്റോപ്പ് ബട്ടണിന്റെ കള്ളം

മോശമായ ഒരു സ്റ്റോപ്പ് ബട്ടൺ നിങ്ങളുടെ ഉപയോക്താക്കളോട് കള്ളം പറയുന്നു. ഒരു കണ്ടെയ്നറിലോ റിമോട്ട് വർക്കറിലോ ടാസ്ക് നടന്നു കൊണ്ടിരിക്കുമ്പോൾ തന്നെ അത് "Stopped" എന്ന് കാണിക്കുന്നു. സെർവർ പ്രവർത്തനം നിർത്തിവെച്ചതായി സ്ഥിരീകരിക്കുന്നതിന് മുമ്പ് തന്നെ ഫ്രണ്ട്-എൻഡ് ഡെവലപ്പർമാർ പലപ്പോഴും ഇന്റർഫേസ് അപ്‌ഡേറ്റ് ചെയ്യുന്നത് കൊണ്ടാണ് ഇത് സംഭവിക്കുന്നത്. പ്രോഗ്രസ്സ് ബാർ നീങ്ങുന്നതോ ലോഗ് സ്ക്രോൾ ചെയ്യുന്നതോ കണ്ടാൽ ഒരു കാഴ്ചക്കാരന് ഈ വ്യത്യാസം മനസ്സിലാക്കാം, എന്നാൽ സ്ക്രീൻ റീഡർ ഉപയോഗിക്കുന്ന ഒരാൾക്ക് അത്തരത്തിലുള്ള മറ്റൊരു മാർഗ്ഗമില്ല. ഇന്റർഫേസ് എന്താണോ പ്രഖ്യാപിക്കുന്നത് അതിനെ അവർ പൂർണ്ണമായും ആശ്രയിക്കുന്നു. ബട്ടൺ ടെക്സ്റ്റ് നേരത്തെ മാറുകയും യഥാർത്ഥ അവസ്ഥ വ്യക്തമാക്കുന്ന ഓഡിയോ ഫീഡ്‌ബാക്ക് ലഭിക്കാതിരിക്കുകയും ചെയ്താൽ, അപകടം കഴിഞ്ഞു എന്ന് ഉപയോക്താവ് തെറ്റിദ്ധരിക്കും. ഇവിടെ ആക്സസിബിലിറ്റി (Accessibility) എന്നത് വെറുമൊരു ഫീച്ചർ അഭ്യർത്ഥനയല്ല, മറിച്ച് അതൊരു സുരക്ഷാ ആവശ്യകതയാണ്.

രണ്ട് വ്യത്യസ്ത അവസ്ഥകൾ

ഒരു യഥാർത്ഥ എമർജൻസി കൺട്രോൾ രണ്ട് വ്യത്യസ്ത ഉത്തരവാദിത്തങ്ങൾ കൈകാര്യം ചെയ്യണം. ഒന്നാമതായി, സിസ്റ്റം നിങ്ങളുടെ അഭ്യർത്ഥന സ്വീകരിക്കുന്നു. രണ്ടാമതായി, സിസ്റ്റം അധികാരം റദ്ദാക്കുന്നു (revokes authority). ഇവ രണ്ടും ഒന്നല്ല. സ്വീകരണം (Acceptance) എന്നാൽ ഫ്രണ്ട് എൻഡ് നിങ്ങളുടെ നിർദ്ദേശം കേട്ടു എന്നും അത് കൈമാറി എന്നും അർത്ഥമാക്കുന്നു. റവൊക്കേഷൻ (Revocation) എന്നാൽ ബാക്ക് എൻഡ് പ്രക്രിയ യഥാർത്ഥത്തിൽ അവസാനിപ്പിച്ചു എന്നുമാണ് അർത്ഥം. നെറ്റ്‌വർക്ക് ലേറ്റൻസി (latency), ജോബ് ക്യൂകൾ, ഓർക്കസ്ട്രേഷൻ ലെയറുകൾ എന്നിവ ഉള്ളതിനാൽ, ഈ രണ്ട് നിമിഷങ്ങൾക്കിടയിലുള്ള വ്യത്യാസം സെക്കൻഡുകൾ വരെ നീണ്ടുനിൽക്കാം. ആ സമയത്തിനുള്ളിൽ, നിങ്ങൾ ഏത് ഘട്ടത്തിലാണെന്ന സത്യം നിങ്ങളുടെ ഇന്റർഫേസ് പറയണം. ഈ രണ്ട് ഘട്ടങ്ങളെയും ഒരൊറ്റ നിമിഷമായി കാണുന്നത് നിലവിലില്ലാത്ത ഒരു ഇൻഫ്രാസ്ട്രെക്ഷനെ മുൻനിർത്തിയാണ്. നിങ്ങളുടെ ഉപയോക്താക്കൾ അതിന്റെ വില നൽകേണ്ടി വരും.

നാല് അവസ്ഥകളെ നിങ്ങളുടെ ഇന്റർഫേസുമായി ബന്ധിപ്പിക്കുക

ഉപയോക്താക്കൾക്ക് എപ്പോഴും തങ്ങൾ എവിടെയാണെന്ന് അറിയാൻ കഴിയുന്ന രീതിയിൽ നാല് വ്യക്തമായ അവസ്ഥകളെ അടിസ്ഥാനമാക്കി നിങ്ങളുടെ UI നിർമ്മിക്കുക.

• Running: "Stop task" എന്ന് വ്യക്തമായി രേഖപ്പെടുത്തിയ ഒരു ബട്ടൺ കാണിക്കുക. ഇത് എപ്പോഴും ദൃശ്യമായിരിക്കണം. ടാബുകൾക്കോ അക്കോർഡിയൻ പാനലുകൾക്കോ കീഴിൽ ഇത് ഒളിപ്പിച്ചു വെക്കരുത്.
• Requesting: ഉപയോക്താവിന് വീണ്ടും റിക്വസ്റ്റുകൾ അയക്കാതിരിക്കാൻ ബട്ടൺ ഡിസേബിൾ ചെയ്യുക. "Stop requested" എന്ന സന്ദേശം കാണിക്കുക. ഈ സത്യസന്ധത പ്രധാനമാണ്. നിങ്ങളുടെ കമാൻഡ് പ്രക്രിയയിലാണെന്നും സിസ്റ്റം അത് പൂർത്തിയായതായി സ്ഥിരീകരിച്ചിട്ടില്ലെന്നും ഇത് ഉപയോക്താവിനെ അറിയിക്കുന്നു.
• Stopped: ബട്ടൺ ഡിസേബിൾ ചെയ്യുക. ഒരു റെസീപ്റ്റ് ഐഡി (receipt ID) കാണിക്കുക. സെർവർ പ്രതികരിച്ചുവെന്നും സ്റ്റോപ്പ് രേഖപ്പെടുത്തി എന്നും ഇത് ഉപയോക്താവിന് തെളിവ് നൽകുന്നു. ഇത് വെറുമൊരു അവകാശവാദത്തെ ഒരു റെക്കോർഡാക്കി മാറ്റുന്നു.
• Failed: "Try stop again" എന്ന ബട്ടൺ പ്രവർത്തനക്ഷമമാക്കുക. കൃത്യമായ പരാജയ സന്ദേശം കാണിക്കുക. ഉപയോക്താവിനെ നിശബ്ദമായ അവസ്ഥയിൽ അവശേഷിപ്പിക്കരുത്. സെർവർ ടൈം ഔട്ട് ആയതുകൊണ്ടോ അല്ലെങ്കിൽ ഒരു എറർ വന്നതുകൊണ്ടോ ആണെങ്കിൽ അത് വ്യക്തമാക്കുക.

ഈ അവസ്ഥകൾ വിഷ്വൽ (visual), ഓഡിയോ (auditory) ഫീഡ്‌ബാക്കുകൾ നൽകണം. അവസ്ഥ മാറുമ്പോൾ, കൃത്യമായി നിയന്ത്രിക്കപ്പെട്ട ഒരു ലൈവ് റീജിയൻ (live region) വഴി സ്ക്രീൻ റീഡറുകൾ പുതിയ ലേബലും സ്റ്റാറ്റസും പ്രഖ്യാപിക്കണം. ഒരു ഡിസേബിൾ ചെയ്ത ബട്ടണും ടെക്സ്റ്റ് അറിയിപ്പും ഉണ്ടെങ്കിൽ കൺട്രോൾ ഇപ്പോഴും സജീവമാണോ എന്നതിനെക്കുറിച്ചുള്ള ആശയക്കുഴപ്പം ഒഴിവാക്കാം.

സമ്മർദ്ദഘട്ടങ്ങളിൽ നിലനിൽക്കുന്ന ഡിസൈൻ നിയമങ്ങൾ

സാധാരണ ബട്ടണുകളെ അപേക്ഷിച്ച് എമർജൻസി കൺട്രോളുകൾക്ക് വ്യത്യസ്തമായ ഡിസൈൻ ഉത്തരവാദിത്തങ്ങളുണ്ട്. ഉപയോക്താക്കൾ പരിഭ്രാന്തരാകാം, തിരക്കിലായിരിക്കാം, അല്ലെങ്കിൽ അപ്രതീക്ഷിതമായ ഔട്ട്‌പുട്ടിനോട് പ്രതികരിക്കുകയാകാം. ആ സമ്മർദ്ദത്തിലും നിങ്ങളുടെ ഇന്റർഫേസ് ഉപയോഗപ്രദമായിരിക്കണം.

നിറം മാത്രം ഒരു സിഗ്നലായി ഉപയോഗിക്കരുത്. ഒരു ബട്ടൺ ചുവപ്പിൽ നിന്ന് പച്ചയിലേക്ക് മാറുന്നത് കാഴ്ചയുള്ള ചില ഉപയോക്താക്കളെ സഹായിച്ചേക്കാം, എന്നാൽ കളർബ്ലൈൻഡ് (colorblind) ആയവരും സ്ക്രീൻ റീഡർ ഉപയോഗിക്കുന്നവരും ടെക്സ്റ്റും ഘടനാപരമായ മാറ്റങ്ങളും ആവശ്യപ്പെടുന്നു. നിറത്തോടൊപ്പം വ്യക്തമായ ലേബലുകളും, ഐക്കണുകൾക്കൊപ്പം ടെക്സ്റ്റ് ഓൾട്ടർനേറ്റീവുകളും, സ്റ്റേറ്റ് അറിയിപ്പുകളും നൽകുക.

ഹോവർ മെനുകളിൽ (hover menus) കൺട്രോളുകൾ ഒളിപ്പിക്കരുത്. ഒരു എമർജൻസി സമയത്ത് ആരും ഡ്രോപ്പ്ഡൗണുകൾ തിരഞ്ഞു നടക്കില്ല. സ്റ്റോപ്പ് ബട്ടൺ പ്രധാന വ്യൂപോർട്ടിൽ (viewport) എപ്പോഴും ലഭ്യമായിരിക്കണം.

പോയിന്റർ ഉപയോഗിച്ച് ബട്ടണുകളിൽ അമർത്താൻ എളുപ്പമാക്കുക. സമ്മർദ്ദം സ്വാഭാവികമായും കൈകളുടെ കൃത്യത കുറയ്ക്കും. വലിയ പാഡിംഗും (padding) വലിയ ഹിറ്റ് ടാർഗറ്റും (hit target) ഉപയോഗിക്കുക. ഉപയോക്താവ് വിറയ്ക്കുകയോ അല്ലെങ്കിൽ ചലിച്ചുകൊണ്ടിരിക്കുന്ന ഒരു ട്രെയിനിൽ ട്രാക്ക്പാഡ് ഉപയോഗിക്കുകയോ ആണെങ്കിൽ പോലും ക്ലിക്ക് ചെയ്യാൻ അവർക്ക് സാധിക്കണം.

കീബോർഡ് ഉപയോഗിക്കുന്നവർക്ക് ബട്ടണിൽ വേഗത്തിൽ എത്താൻ കഴിയുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക. എമർജൻസി കൺട്രോളിൽ എത്തുന്നതിന് മുമ്പ് മുപ്പതോളം എലമെന്റുകളിലൂടെ ടാബ് (tab) ചെയ്യേണ്ടി വരുന്ന രീതിയിലാകരുത് ടാബ് ഓർഡർ. സ്റ്റോപ്പ് ആക്ഷൻ പെട്ടെന്ന് ചെയ്യാൻ കഴിയുന്ന രീതിയിലുള്ള സ്കിപ്പ് ലിങ്കുകളോ (skip link) ലോജിക്കൽ ഫോക്കസ് പ്ലേസ്‌മെന്റോ പരിഗണിക്കുക.

അവിചാരിതമായി കീബോർഡ് ഷോർട്ട്കട്ടുകൾ അമർത്തുന്നത് ഒഴിവാക്കുക. ഒരു പ്രക്രിയയെ തടസ്സപ്പെടുത്തുന്ന ഗ്ലോബൽ ഷോർട്ട്കട്ടുകൾ, അബദ്ധത്തിൽ അമർത്താൻ പ്രയാസമുള്ള കോമ്പിനേഷനുകൾ ഉപയോഗിച്ചായിരിക്കണം. സേവ് ചെയ്യാനോ പ്രിന്റ് ചെയ്യാനോ ഉപയോഗിക്കുന്ന സാധാരണ ഷോർട്ട്കട്ടുകൾ നിങ്ങളുടെ സ്റ്റോപ്പ് കമാൻഡുമായി ഒത്തുപോകുന്നുണ്ടെങ്കിൽ, ആരെങ്കിലും അബദ്ധത്തിൽ അത് അമർത്തുകയും ചെയ്ത ജോലി നഷ്ടപ്പെടുകയും ചെയ്തേക്കാം.

അടിയന്തര സാഹചര്യങ്ങളിൽ മൾട്ടി-സ്റ്റെപ്പ് കൺഫർമേഷൻ ഉപയോഗിക്കരുത്. ഒരു കൺഫർമേഷൻ ഡയലോഗ് എന്നത് ഒരു തടസ്സമാണ്, സുരക്ഷാ കവചമല്ല. ഉപയോക്താവ് "Are you sure?" എന്ന് വായിച്ച് വീണ്ടും ക്ലിക്ക് ചെയ്യുന്നതിന് മുമ്പ് തന്നെ, ആവശ്യമില്ലാത്ത ഔട്ട്പുട്ട് പുറത്തായേക്കാം. ഒരു കൃത്യമായ നടപടി മാത്രം മതിയാകും.

രസീതുകൾ, നെറ്റ്‌വർക്ക് നഷ്ടം, സത്യസന്ധമായ പരിമിതികൾ

ഒരു രസീത് ഐഡി (receipt ID) സെർവർ പ്രതികരിച്ചു എന്ന് തെളിയിക്കുന്നു. എന്നാൽ അത് എല്ലാ പ്രത്യാഘാതങ്ങളും (downstream effects) തിരിച്ചടഞ്ഞു എന്ന് തെളിയിക്കുന്നില്ല. സ്റ്റോപ്പ് കമാൻഡ് എത്തുന്നതിന് മുമ്പ് നിങ്ങളുടെ AI ടാസ്ക് എക്സ്റ്റേണൽ API-കൾ, ഫയൽ റൈറ്റുകൾ അല്ലെങ്കിൽ മെസ്സേജ് ക്യൂകൾ എന്നിവ പ്രവർത്തിപ്പിച്ചേക്കാം. ഓർക്കസ്ട്രേറ്റർ (orchestrator) നിർത്തുന്നത് ഓരോ ചൈൽഡ് പ്രോസസ്സുകളും ഉടനടി നിർത്തി എന്ന് ഉറപ്പുനൽകുന്നില്ല. നിങ്ങളുടെ സന്ദേശങ്ങളിലും ഡോക്യുമെന്റേഷനിലും ഈ പരിമിതിയെക്കുറിച്ച് സത്യസന്ധത പുലർത്തുക.

നിങ്ങളുടെ സെർവർ റൂമിന് പുറത്തുള്ള പരാജയ സാധ്യതകൾക്കായി (failure modes) നിങ്ങൾ രൂപകൽപ്പന ചെയ്യേണ്ടതുണ്ട്. സ്റ്റോപ്പ് ക്ലിക്ക് ചെയ്ത ഉടൻ ഉപയോക്താവിന് നെറ്റ്‌വർക്ക് കണക്റ്റിവിറ്റി നഷ്ടപ്പെട്ടാൽ എന്ത് സംഭവിക്കുമെന്ന് പരിശോധിക്കുക. പ്രതികരണം നൂറ് മില്ലിസെക്കൻഡിന് പകരം പത്ത് സെക്കൻഡ് എടുക്കുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് പരിശോധിക്കുക. റിക്വസ്റ്റ് ഹാങ്ങ് ആയാൽ, നിങ്ങളുടെ ഇന്റർഫേസ് എന്നെന്നേക്കുമായി "Requesting" എന്ന അവസ്ഥയിൽ കുടുങ്ങിക്കിടക്കാതെ, പരാജയപ്പെട്ട അവസ്ഥയിലേക്ക് (failed state) മാറണം. കണക്ഷൻ നഷ്ടപ്പെട്ട വിവരം ഉപയോക്താക്കൾ അറിയാൻ അർഹതയുണ്ട്.

പ്രാധാന്യത്തോടെ എങ്ങനെ പരിശോധിക്കാം

പരിശോധന എന്നത് അവസാന നിമിഷം മാത്രം ചെയ്യേണ്ട ഒന്നല്ല. ഭിന്നശേഷിയുള്ള ഉപയോക്താക്കൾ ദിവസേന നേരിടുന്ന യഥാർത്ഥ സാഹചര്യങ്ങളിലൂടെ നിങ്ങളുടെ ഇന്റർഫേസ് കടത്തിവിട്ട് പരിശോധിക്കുക.

കീബോർഡ് മാത്രം ഉപയോഗിച്ചുള്ള നാവിഗേഷൻ. മൗസ് മാറ്റി വെക്കുക. ഓരോ ഘട്ടത്തിലൂടെയും ടാബ് (Tab) ഉപയോഗിച്ച് കടന്നുപോവുക. ഫോക്കസ് കുടുങ്ങുകയോ അദൃശ്യമായ ടാബ് സ്റ്റോപ്പുകൾ ഉണ്ടാവുകയോ ചെയ്യാതെ, വർക്ക്ഫ്ലോയുടെ ഏത് ഭാഗത്തുനിന്നും സ്റ്റോപ്പ് ബട്ടണിൽ എത്താൻ കഴിയുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക.

200% ബ്രൗസർ സൂം. പേജ് വലുതാക്കി കാണുക. സ്റ്റോപ്പ് ബട്ടൺ അതിന്റെ സ്ഥാനത്ത് തന്നെയാണോ അതോ അപ്രത്യക്ഷമാകുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. കാഴ്ച പരിമിതിയുള്ളവർ സൂമിനെ ആശ്രയിക്കുന്നു, ലേഔട്ട് തകരാറിലാകുന്നത് പലപ്പോഴും പ്രധാനപ്പെട്ട കൺട്രോളുകളെ മറച്ചുവെച്ചേക്കാം.

റിഡ്യൂസ്ഡ് മോഷൻ സെറ്റിംഗുകൾ. നിങ്ങളുടെ "Requesting" അവസ്ഥയിൽ ഒരു പൾസിംഗ് ആനിമേഷനോ സ്പിന്നിംഗ് ലോഡറോ ഉപയോഗിച്ചേക്കാം. prefers-reduced-motion എന്ന സെറ്റിംഗിനെ മാനിക്കുക. ആനിമേഷനുകൾ ഓഫ് ചെയ്യുന്ന ഉപയോക്താക്കൾക്കും വ്യക്തമായ ഫീഡ്ബാക്ക് ലഭിക്കുന്നതിനായി, ചലനത്തോടൊപ്പം സ്റ്റാറ്റിക് വിഷ്വൽ ഇൻഡിക്കേറ്ററുകളും നൽകുക.

സ്ക്രീൻ റീഡർ അനൗൺസ്‌മെന്റ് ക്രമം. സ്റ്റേറ്റ് മാറ്റങ്ങൾ അറിയിക്കാൻ ഒരു ലൈവ് റീജിയൻ (live region) ഉപയോഗിക്കുക, എന്നാൽ അതിന്റെ ക്രമം ശ്രദ്ധാപൂർവ്വം പരിശോധിക്കുക. അനൗൺസ്‌മെന്റ് ക്രമം സംഭവങ്ങളുടെ യുക്തിസഹമായ ക്രമത്തോട് യോജിച്ചതായിരിക്കണം. സ്ക്രീൻ റീഡർ "Stop requested" എന്ന് പറയുന്നതിന് മുമ്പ് ബട്ടൺ ഡിസേബിൾ ആകുന്നുണ്ടെങ്കിൽ, അത് ആശയക്കുഴപ്പമുണ്ടാക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. അസിസ്റ്റീവ് ടെക്നോളജിയിലെ ചെറിയ ടൈമിംഗ് പിശകുകൾ സന്ദേശങ്ങളെ അവ്യക്തമാക്കിയേക്കാം, അതിനാൽ മാർക്കപ്പ് മാത്രം മതിയാകുമെന്ന് കരുതുന്നതിന് പകരം ഒരു യഥാർത്ഥ സ്ക്രീൻ റീഡർ ഉപയോഗിച്ച് പരിശോധിക്കുക.

യഥാർത്ഥ പാഠം

സുരക്ഷിതമായ ഒരു എമർജൻസി സ്റ്റോപ്പ് നിർമ്മിക്കുക എന്നാൽ ഉപയോക്താക്കളോട് സത്യം പറയാൻ മാത്രം അവരെ ബഹുമാനിക്കുക എന്നാണ് അർത്ഥം. ഇന്റർഫേസ് ലളിതമായിരിക്കണം, പ്രവചിക്കാവുന്ന രീതിയിൽ പ്രവർത്തിക്കണം, ഒരു റിക്വസ്റ്റ് എന്നത് ഒരു റിസൾട്ട് ആണെന്ന് ഒരിക്കലും നടിക്കരുത്. സമ്മർദ്ദം കൂടിയപ്പോഴും ഡാറ്റ അപകടത്തിലാകുമ്പോഴും, വ്യക്തത സമയം മാത്രമല്ല ലാഭിക്കുന്നത്, അത് വിശ്വാസവും സംരക്ഷിക്കുന്നു. ഒരു സത്യസന്ധമായ സ്റ്റോപ്പ് ബട്ടൺ ഒരു ടാസ്ക് നിർത്തുക മാത്രമല്ല ചെയ്യുന്നത്, നിങ്ങളുടെ ഉൽപ്പന്നം ഉപയോഗിക്കാൻ സുരക്ഷിതമാണെന്ന് അത് തെളിയിക്കുകയും ചെയ്യുന്നു.