જ્યારે કોઈ AI ટૂલ કન્ટેન્ટ જનરેટ કરી રહ્યું હોય, ડેટાસેટ પ્રોસેસ કરી રહ્યું હોય, અથવા કોઈ સ્વાયત્ત કાર્ય (autonomous task) કરી રહ્યું હોય, ત્યારે વપરાશકર્તા પાસે બહાર નીકળવાનો સ્પષ્ટ રસ્તો હોવો જોઈએ. ઘણા ઇન્ટરફેસ ઇમરજન્સી સ્ટોપને માત્ર એક વિચાર તરીકે લે છે. તેઓ બટનનું લેબલ "Stop" થી બદલીને "Stopped" કરી દે છે અને કામ પૂરું થયું એમ માની લે છે. રંગ કદાચ રાખોડી થઈ શકે છે. એનિમેશન કદાચ સ્મૂધ દેખાઈ શકે છે. છતાં કાર્ય સર્વર પર ચાલુ જ રહે છે, અને વપરાશકર્તાને ખબર પણ નથી હોતી કે કંઈક ખોટું થઈ રહ્યું છે. સ્ક્રીન રીડર પર નિર્ભર વ્યક્તિ માટે, આ નિષ્ફળતા વધુ ગંભીર છે. તેઓ સાંભળે છે કે પ્રક્રિયા સમાપ્ત થઈ ગઈ છે, જ્યારે કામ બેકગ્રાઉન્ડમાં શાંતિથી ચાલુ જ હોય છે. તે કોઈ નાની ભૂલ નથી. તે વિશ્વાસનો ભંગ છે.
સાયલન્ટ સ્ટોપ બટનનું જૂઠ
એક ખરાબ સ્ટોપ બટન તમારા વપરાશકર્તાઓને છેતરે છે. તે "Stopped" શબ્દ બતાવે છે જ્યારે કાર્ય કન્ટેનર અથવા રિમોટ વર્કર પર ક્યાંક ચાલુ જ હોય છે. આ એટલા માટે થાય છે કારણ કે ફ્રન્ટ-એન્ડ ડેવલપર્સ ઘણીવાર સર્વર દ્વારા વિરામની પુષ્ટિ થાય તે પહેલાં જ ઇન્ટરફેસને આશાવાદી રીતે અપડેટ કરી દે છે. જો પ્રોગ્રેસ બાર હલતો રહે અથવા લોગ સ્ક્રોલ થતો રહે તો કદાચ વિઝ્યુઅલ યુઝર આ તફાવત પકડી શકે, પરંતુ સ્ક્રીન-રીડર યુઝર પાસે આવો કોઈ બીજો માર્ગ હોતો નથી. તેઓ સંપૂર્ણપણે ઇન્ટરફેસ શું જાહેર કરે છે તેના પર નિર્ભર છે. જો બટનનું ટેક્સ્ટ અકાળે બદલાઈ જાય અને કોઈ ઓડિયો ફીડબેક વાસ્તવિક સ્થિતિ સ્પષ્ટ ન કરે, તો વપરાશકર્તા માની લે છે કે ઇમરજન્સી પૂરી થઈ ગઈ છે, જ્યારે તે હજુ પણ ચાલુ હોય છે. અહીં એક્સેસિબિલિટી (Accessibility) એ માત્ર એક ફીચર રિક્વેસ્ટ નથી, તે સુરક્ષાની જરૂરિયાત છે.
બે અલગ-અલગ સ્ટેટ્સ
વાસ્તવિક ઇમરજન્સી કંટ્રોલ માટે બે અલગ-અલગ જવાબદારીઓ સંભાળવી જોઈએ. પ્રથમ, સિસ્ટમ તમારી વિનંતી સ્વીકારે છે. બીજું, સિસ્ટમ સત્તા રદ કરે છે (revokes authority). આ બંને એક સમાન નથી. સ્વીકાર (Acceptance) નો અર્થ છે કે ફ્રન્ટ એન્ડ એ તમારી વાત સાંભળી છે અને સંદેશ આગળ મોકલી દીધો છે. રદબાતલ (Revocation) નો અર્થ છે કે બેક એન્ડ એ ખરેખર પ્રક્રિયા સમાપ્ત કરી દીધી છે. નેટવર્ક લેટન્સી, જોબ ક્યુઝ અને ઓર્કેસ્ટ્રેશન લેયર્સના કારણે, આ બે ક્ષણો વચ્ચેનો સમય સેકન્ડો સુધીનો હોઈ શકે છે. તે સમયગાળા દરમિયાન, તમારા ઇન્ટરફેસે તમે કયા તબક્કામાં છો તેના વિશે સત્ય કહેવું જોઈએ. બંને તબક્કાઓને એક જ ક્ષણમાં ભેગા કરી દેવાનો અર્થ એ છે કે તમે એવા ઇન્ફ્રાસ્ટ્રક્ચરની ધારણા કરો છો જે અસ્તિત્વમાં જ નથી. તમારા વપરાશકર્તાઓને આ આશાવાદની કિંમત ચૂકવવી પડશે.
તમારા ઇન્ટરફેસમાં ચાર સ્ટેટ્સનું મેપિંગ
તમારા UI ને ચાર સ્પષ્ટ સ્ટેટ્સની આસપાસ બનાવો જેથી વપરાશકર્તાઓ હંમેશા જાણી શકે કે તેઓ કઈ સ્થિતિમાં છે.
- Running: સ્પષ્ટ રીતે લેબલ કરેલું "Stop task" બટન બતાવો. તેને હંમેશા દેખાતું રાખો. તેને ટેબ્સ અથવા એકોર્ડિયન પેનલ્સ નીચે છુપાવો નહીં.
- Requesting: બટનને ડિસેબલ કરો જેથી વપરાશકર્તા વધારાની વિનંતીઓ ન કરી શકે. "Stop requested" સંદેશ દર્શાવો. આ પ્રામાણિકતા મહત્વની છે. તે વપરાશકર્તાને જણાવે છે કે તેમની કમાન્ડ પ્રક્રિયામાં છે અને સિસ્ટમે હજુ સુધી પૂર્ણતાની પુષ્ટિ કરી નથી.
- Stopped: બટનને ડિસેબલ કરો. એક receipt ID બતાવો. આ વપરાશકર્તાને પુરાવો આપે છે કે સર્વરે પ્રતિસાદ આપ્યો છે અને સ્ટોપ લોગ કરવામાં આવ્યો છે. તે માત્ર એક દાવાને રેકોર્ડમાં ફેરવે છે.
- Failed: "Try stop again" બટલને ઇનેબલ કરો. ચોક્કસ નિષ્ફળતાનો સંદેશ દર્શાવો. વપરાશકર્તાને ક્યારેય અનિશ્ચિતતામાં ન છોડો. જો સર્વર ટાઈમ આઉટ થયું હોય અથવા ભૂલ (error) આવી હોય, તો તે સ્પષ્ટ કહો.
આ સ્ટેટ્સ વિઝ્યુઅલ અને ઓડિટરી બંને ફીડબેકને સંચાલિત કરવા જોઈએ. જ્યારે સ્ટેટ બદલાય, ત્યારે સ્ક્રીન રીડર્સે યોગ્ય રીતે મેનેજ કરેલા લાઈવ રીજન (live region) દ્વારા નવું લેબલ અને સ્ટેટસ જાહેર કરવું જોઈએ. ડિસેબલ કરેલું બટન અને ટેક્સ્ટ એનાઉન્સમેન્ટ યુઝરને એ બાબતે મૂંઝવણ થવા દેશે નહીં કે કંટ્રોલ હજુ સક્રિય છે કે નહીં.
દબાણ હેઠળ ટકી રહે તેવા ડિઝાઇન નિયમો
ઇમરજન્સી કંટ્રોલ્સ સામાન્ય બટનો કરતા અલગ ડિઝાઇન બોજ ધરાવે છે. વપરાશકર્તાઓ ચિંતિત, ઉતાવળમાં અથવા અણધાર્યા આઉટપુટ પ્રત્યે પ્રતિક્રિયા આપી રહ્યા હોઈ શકે છે. તે તણાવમાં પણ તમારું ઇન્ટરફેસ ઉપયોગી રહેવું જોઈએ.
રંગને એકમાત્ર સંકેત તરીકે ઉપયોગ ન કરો. બટન લાલમાંથી લીલા રંગમાં બદલાવું એ કેટલાક દૃષ્ટિમાન વપરાશકર્તાઓને મદદ કરી શકે છે, પરંતુ કલરબ્લાઈન્ડ અને સ્ક્રીન-રીડર વપરાશકર્તાઓને ટેક્સ્ટ અને સ્ટ્રક્ચરલ ફેરફારોની જરૂર હોય છે. રંગની સાથે સ્પષ્ટ લેબલ્સ, ટેક્સ્ટ વિકલ્પો સાથે આઇકોનોગ્રાફી અને સ્ટેટ એનાઉન્સમેન્ટનો ઉપયોગ કરો.
હોવર મેનૂમાં કંટ્રોલ્સને છુપાવો નહીં. ઇમરજન્સી દરમિયાન કોઈએ ડ્રોપડાઉન મેનૂમાં શોધવું ન જોઈએ. સ્ટોપ બટન મુખ્ય વ્યુપોર્ટમાં હોવું જોઈએ, જે હંમેશા ચોક્કસ કર્સર મૂવમેન્ટ વગર પહોંચી શકાય તેવું હોય.
બટનોને પોઇન્ટરથી દબાવવા સરળ બનાવો. તણાવથી ઝીણી મોટર કંટ્રોલ (fine motor control) ઘટી શકે છે. ઉદાર પેડિંગ અને મોટા હિટ ટાર્ગેટનો ઉપયોગ કરો. જો વપરાશકર્તા ધ્રૂજી રહ્યો હોય અથવા ચાલતી ટ્રેનમાં ટ્રેકપેડનો ઉપયોગ કરી રહ્યો હોય, તો પણ તેઓ ક્લિક કરી શકવા જોઈએ.
ખાતરી કરો કે કીબોર્ડ વપરાશકર્તાઓ ઝડપથી બટન સુધી પહોંચી શકે. ટેબ ઓર્ડર એવો ન હોવો જોઈએ કે ઇમરજન્સી કંટ્રોલ સુધી પહોંચતા પહેલા કોઈએ ત્રીસ ફોકસ કરી શકાય તેવા એલિમેન્ટ્સમાંથી પસાર થવું પડે. સ્કીપ લિંક અથવા લોજિકલ ફોકસ પ્લેસમેન્ટનો વિચાર કરો જે સ્ટોપ એક્શનને તરત જ પહોંચી શકાય તેવા અંતરે રાખે.
અજાણતા વપરાતા કીબોર્ડ શોર્ટકટ્સથી બચો. પ્રક્રિયાને અટકાવતા ગ્લોબલ શોર્ટકટ્સ એવા કોમ્બિનેશનનો ઉપયોગ કરવા જોઈએ જે ભૂલથી દબાવવા મુશ્કેલ હોય. જો સેવ (save) અથવા પ્રિન્ટ (print) માટેનો સામાન્ય શોર્ટકટ તમારા સ્ટોપ કમાન્ડ સાથે ઓવરલેપ થાય છે, તો કોઈ વ્યક્તિ અજાણતા તેને દબાવી દેશે અને તેનું કામ ગુમાવશે.
કટોકટી માટે મલ્ટી-સ્ટેપ કન્ફર્મેશનનો ઉપયોગ કરશો નહીં. કન્ફર્મેશન ડાયલોગ એ દીવાલ સમાન છે, સુરક્ષા રેલિંગ સમાન નહીં. વપરાશકર્તા "શું તમે ચોક્કસ છો?" વાંચે અને ફરીથી ક્લિક કરે ત્યાં સુધીમાં, બિનજરૂરી આઉટપુટ પહેલેથી જ મોકલાઈ ગયું હોઈ શકે છે. એક નિર્ણાયક પગલું પૂરતું હોવું જોઈએ.
રસીદો, નેટવર્ક લોસ અને પ્રમાણિક મર્યાદાઓ
એક રસીદ ID (receipt ID) સાબિત કરે છે કે સર્વરે પ્રતિસાદ આપ્યો છે. તે એ સાબિત કરતું નથી કે દરેક ડાઉનસ્ટ્રીમ અસર ઉલટાઈ ગઈ છે. સ્ટોપ કમાન્ડ આવ્યા ત્યાં સુધીમાં તમારા AI કાર્યએ એક્સટર્નલ APIs, ફાઇલ રાઈટ્સ અથવા મેસેજ ક્યુઝ ટ્રિગર કરી દીધા હોઈ શકે છે. ઓર્કેસ્ટ્રેટરને અટકાવવાથી એની ખાતરી મળતી નથી કે દરેક ચાઇલ્ડ પ્રોસેસ તરત જ રદ થઈ ગઈ છે. તમારા મેસેજિંગ અને તમારા ડોક્યુમેન્ટેશનમાં આ મર્યાદા વિશે પ્રમાણિક રહો.
તમારે એવા ફેલ્યોર મોડ્સ (failure modes) માટે પણ ડિઝાઇન કરવાની જરૂર છે જે તમારા સર્વર રૂમની બહાર હોય છે. વપરાશકર્તા સ્ટોપ પર ક્લિક કર્યા પછી તરત જ નેટવર્ક કનેક્ટિવિટી ગુમાવે ત્યારે શું થાય છે તેનું પરીક્ષણ કરો. પ્રતિસાદ સો મિલિસેકન્ડને બદલે દસ સેકન્ડ લે છે ત્યારે શું થાય છે તેનું પરીક્ષણ કરો. જો રિક્વેસ્ટ અટકી જાય (hang), તો તમારું ઇન્ટરફેસ કાયમ માટે "Requesting" માં અટકી રહેવાને બદલે 'ફેઈલ સ્ટેટ' (failed state) માં ટાઈમ આઉટ થઈ જવું જોઈએ. જ્યારે લાઇન કપાઈ ગઈ હોય ત્યારે વપરાશકર્તાઓને તે જાણવાનો અધિકાર છે.
મહત્વપૂર્ણ રીતે કેવી રીતે ટેસ્ટ કરવું
વેરિફિકેશન એ માત્ર વિચાર્યા પછીનું કામ ન હોવું જોઈએ. તમારા ઇન્ટરફેસને એવા વાસ્તવિક સંજોગોમાંથી પસાર કરો જેનો સામનો દિવ્યાંગ વપરાશકર્તાઓ દરરોજ કરે છે.
કીબોર્ડ-ઓન્લી નેવિગેશન. તમારો માઉસ કાઢી નાખો. દરેક સ્ટેટમાંથી ટેબ (Tab) દ્વારા આગળ વધો. ખાતરી કરો કે તમે ફોકસને ફસાવ્યા વગર અથવા અદ્રશ્ય ટેબ સ્ટોપ્સ બનાવ્યા વગર વર્કફ્લોમાં ગમે ત્યાંથી સ્ટોપ બટન સુધી પહોંચી શકો છો.
200% બ્રાઉઝર ઝૂમ. પેજને મોટું કરો. તપાસો કે સ્ટોપ બટન રિફ્લો (reflow) થાય છે કે ગાયબ થઈ જાય છે. ઓછી દ્રષ્ટિ ધરાવતા વપરાશકર્તાઓ ઝૂમ પર આધાર રાખે છે, અને લેઆઉટ કોલેપ્સ ઘણીવાર મહત્વપૂર્ણ કંટ્રોલ્સને છુપાવી દે છે.
રિડ્યુસ્ડ મોશન સેટિંગ્સ. તમારી "Requesting" સ્ટેટમાં પલ્સિંગ એનિમેશન અથવા સ્પિનિંગ લોડરનો ઉપયોગ થઈ શકે છે. prefers-reduced-motion નો આદર કરો. કોઈપણ ગતિશીલતાની સાથે સ્થિર વિઝ્યુઅલ ઇન્ડિકેટર્સ આપો જેથી એનિમેશન બંધ કરનારા વપરાશકર્તાઓને પણ સ્પષ્ટ સ્ટેટ ફીડબેક મળે.
સ્ક્રીન રીડર એનાઉન્સમેન્ટ ઓર્ડર. સ્ટેટ ફેરફારોને બ્રોડકાસ્ટ કરવા માટે લાઈવ રિજન (live region) નો ઉપયોગ કરો, પરંતુ ક્રમનું કાળજીપૂર્વક પરીક્ષણ કરો. જાહેરાતનો ક્રમ ઘટનાઓના તાર્કિક પ્રગતિ સાથે મેળ ખાવો જોઈએ. જો સ્ક્રીન રીડર "Stop requested" કહે તે પહેલાં બટન ડિસેબલ થઈ જાય છે, તો તે ક્રમ મૂંઝવણ પેદા કરે છે કે નહીં તેનું પરીક્ષણ કરો. સહાયક ટેકનોલોજીમાં નાના ટાઈમિંગ બગ્સ સંદેશને બગાડી શકે છે, તેથી માત્ર માર્કઅપ પૂરતું હશે તેવું માની લેવાને બદલે વાસ્તવિક સ્ક્રીન રીડર સાથે ચકાસો.
મુખ્ય નિષ્કર્ષ
એક્સેસિબલ ઇમરજન્સી સ્ટોપ બનાવવાનો અર્થ એ છે કે તમારા વપરાશકર્તાઓ સાથે સત્ય બોલવા માટે તેમનો આદર કરવો. ઇન્ટરફેસે સ્પષ્ટ રીતે વાત કરવી જોઈએ, અનુમાનિત રીતે કાર્ય કરવું જોઈએ, અને રિક્વેસ્ટ (request) એ પરિણામ (result) સમાન છે તેવો દેખાવ ક્યારેય ન કરવો જોઈએ. જ્યારે દબાણ વધારે હોય અને ડેટા જોખમમાં હોય, ત્યારે સ્પષ્ટતા સમય કરતાં વધુ બચાવે છે. તે વિશ્વાસ બચાવે છે. એક પ્રમાણિક સ્ટોપ બટન માત્ર કાર્યને અટકાવતું નથી, પરંતુ તે સાબિત કરે છે કે તમારું ઉત્પાદન વાપરવા માટે સુરક્ષિત છે.