დიზაინი3 წთ საკითხავი
საკონტაქტო ფორმა მობილურზე: როგორ გავამარტივოთ შევსება
მომხმარებელი ტელეფონით ფასის გაგებას ცდილობს. ფორმაში ათი სავალდებულო ველია, ტელეფონის ნომრისთვის ასოებიანი კლავიატურა იხსნება, გაგზავნის შემდეგ კი მხოლოდ წითელი ჩარჩო ჩანს. ასეთ დროს შეფერხება ხშირად თვითონ ფორმის მოწყობაშია.
კარგი საკონტაქტო ფორმა ადამიანს გასაგებად ეუბნება, რა უნდა შეავსოს, რა მოხდა შეცდომისას და როდის დასრულდა გაგზავნა. მობილურზე ეს განსაკუთრებით მნიშვნელოვანია: ეკრანის ნაწილს კლავიატურა ფარავს, ველები ნაკლებად ჩანს და დამატებითი აკრეფაც მეტ ძალისხმევას მოითხოვს.
ყოველ ველს ჰქონდეს მიზეზი
დასვით მარტივი კითხვა: ამ პასუხის გარეშე პირველ საუბარს ვერ დავიწყებთ? თუ პასუხი მოგვიანებითაც შეიძლება გაირკვეს, ველი მოაშორეთ ან არასავალდებულოდ დატოვეთ. ფასის მოთხოვნას ყოველთვის არ სჭირდება კომპანიის სრული მისამართი, თანამშრომლების რაოდენობა და რამდენიმე საკონტაქტო არხი ერთად.
W3C WAI-ის ფორმების გზამკვლევი მარტივ, მოკლე ფორმებსა და მხოლოდ საჭირო ინფორმაციის მოთხოვნას ურჩევს. ეს არ ნიშნავს, რომ ყველა ფორმა ერთნაირი სიგრძის უნდა იყოს: შეკვეთა და მოკლე კონსულტაციის მოთხოვნა განსხვავებულ ინფორმაციას საჭიროებს.
ერთ სვეტად დაწყობილი ველები ჩვეულებრივ კარგი საწყისია. თანმიმდევრობა საუბრის ლოგიკას მიჰყვეს: რა გჭირდებათ, როგორ დაგიკავშირდეთ და რა უნდა ვიცოდეთ დამატებით. თუ ველს ნებაყოფლობით ავსებენ, ეს წარწერაშივე მიუთითეთ.
სახელი ველის შევსების შემდეგაც ჩანდეს
მხოლოდ ველის შიგნით მოთავსებული მაგალითი საკმარისი არ არის: აკრეფისას ის ქრება და ადამიანს აღარ ახსოვს, ზუსტად რას ეკითხებოდნენ. მუდმივი სათაური ველის დანიშნულებას ხილულად ტოვებს.
WAI-ის სახელდების განმარტება ველისა და მისი წარწერის სწორ დაკავშირებასაც აღწერს. ტექნიკურად გამართული კავშირი ეკრანის წამკითხველს ეხმარება, სათანადო ინფორმაცია წაიკითხოს; ვიზუალურად კარგი განლაგება მარტო ამას ვერ ადასტურებს.
ელფოსტისთვის შესაბამისი შეყვანის ტიპი გამოიყენეთ, ტელეფონისთვის — ტელეფონის ტიპი, ხოლო ცნობილ პირად ველებზე შევსების ავტომატური მინიშნებები გაითვალისწინეთ. ბრაუზერისა და მოწყობილობის მიხედვით კლავიატურის სახე იცვლება, ამიტომ რეალურ ტელეფონზეც შეამოწმეთ. ტელეფონის ველმა საერთაშორისო ფორმატი მხოლოდ დაუფიქრებელი შეზღუდვის გამო არ უნდა უარყოს.
შეცდომამ გამოსწორების გზა აჩვენოს
„არასწორია“ ადამიანს ვერ ეხმარება. უფრო სასარგებლოა: „მიუთითეთ ელფოსტის სრული მისამართი, მაგალითად name@example.com“. ტექსტი შესაბამის ველთან ახლოს უნდა ჩანდეს; მხოლოდ წითელი ფერი შეცდომის ერთადერთი ნიშანი არ იყოს.
WCAG 2.2-ის შეცდომის იდენტიფიცირების კრიტერიუმი აღმოჩენილი შეცდომის ტექსტურად აღწერას ითხოვს. ეს ერთი მოთხოვნაა და არა მთელი ფორმის ხელმისაწვდომობის სრული შემოწმება.
შეცდომის შემდეგ უკვე სწორად შევსებული ჩვეულებრივი მონაცემები შეინარჩუნეთ. მომხმარებელს თავიდან მთელი შეტყობინების აკრეფა არ უნდა უწევდეს. პაროლებს, გადახდის მონაცემებსა და სხვა მგრძნობიარე ველებს ცალკე წესები სჭირდება.
გაგზავნის ღილაკს გასაგები მდგომარეობები ჰქონდეს
ღილაკზე დაწერილი „მოთხოვნის გაგზავნა“ მოქმედებას უფრო მკაფიოდ აღწერს, ვიდრე უბრალოდ „გაგრძელება“, თუ მომდევნო ნაბიჯი არ არსებობს. დაჭერის შემდეგ გამოჩნდეს, რომ მოთხოვნა იგზავნება. წარმატება მხოლოდ მას შემდეგ დაადასტურეთ, რაც სერვერმა მონაცემები მიიღო.
თუ ინტერნეტი გაწყდა ან სერვერმა პასუხი ვერ დააბრუნა, მომხმარებელს ცრუ წარმატება არ აჩვენოთ. დატოვეთ ხელახლა ცდის შესაძლებლობა და საჭიროებისას ალტერნატიული საკონტაქტო გზა. გაგზავნის მდგომარეობამ განმეორებითი დაჭერების მართვასაც უნდა შეუწყოს ხელი.
შეამოწმეთ კლავიატურა, მასშტაბირება და ტექსტი
მხოლოდ დიზაინის ფაილს ნუ შეხედავთ. გახსენით რეალური ფორმა ტელეფონით: ხედავთ აქტიურ ველს, როცა კლავიატურა ღიაა? ჩანს ღილაკი? ტექსტის გადიდებისას გრძელი ქართული შეტყობინება ხომ არ იჭრება? ინგლისური ვერსია თავისი რეალური ტექსტითაც შეამოწმეთ.
დესკტოპზე ფორმა კლავიატურით გაიარეთ, მობილურზე კი სხვადასხვა ეკრანის ზომა და მოწყობილობა მოსინჯეთ. სატესტო მოთხოვნა თანამშრომელმა ბოლომდე დაამუშაოს — კარგი ვიზუალური პასუხი შეტყობინების სწორ მიწოდებას ავტომატურად ვერ ადასტურებს.
მცირე ცვლილებები სწორი თანმიმდევრობით
- მოაშორეთ არასაჭირო სავალდებულო კითხვები.
- დაამატეთ მუდმივი, გასაგები წარწერები და შესაბამისი შეყვანის ტიპები.
- დაწერეთ შეცდომის გამოსწორებისთვის გამოსადეგი ტექსტები.
- გამიჯნეთ გაგზავნის პროცესი, წარმატება და წარუმატებლობა.
- გაიარეთ სრული პროცესი რეალურ მოწყობილობაზე.
თუ UI/UX დიზაინს ან არსებული ფორმის გაუმჯობესებას გეგმავთ, შეფასება კონკრეტული ამოცანით დაიწყეთ: შეძლებს თუ არა მომხმარებელი მოთხოვნის დამოუკიდებლად, გაუგებრობის გარეშე გაგზავნას?
