قرأت مؤخّرًا مقالة تتحدّث عن مُصطلح “الحلاقة للثور” (Yak Shaving)، وهو مُصطلح يُستخدم في المجال التقني للإشارة إلى أن إتمام شيء ما يحتاج لإصلاح بعض المشاكل قبل التمكّن من الوصول للهدف الرئيسي. بمعنى آخر، لو كانت هناك مُشكلة في زر “اتصل بنا” في الموقع، فإن حلّها لا يقتصر على تعديل الزر فقط، بل يجب على سبيل المثال تغيير مكتبة الأزرار المُستخدمة أولًا، ثم تعديل أكواد “جافا سكريبت” ثانيًا، وهكذا….
طبعًا جزء كبير من الوصول لتلك المرحلة، أي “الحلاقة للثور”، يأتي من تقاعس المُبرمج الأساسي الذي لم يقم بالتفكير أساسًا بالاستخدام على أرض الواقع، وهذا من وجهة نظري ما يُفرّق المُطوّر عن المُبرمج، فالأول شخص يقوم فعلًا بتطوير المُنتج (التطبيق أو الموقع) بشكل يتلائم مع الحياة العملية؛ أي التفكير في تجربة الاستخدام (User Experience)، اختصارًا UX. أما الثاني، المُبرمج، فهو شخص يقوم بإتمام المهمّة برمجيًا دون الاكتراث حقيقة أن هناك أشخاص سيقومون باستخدام التطبيق في النهاية، ودون التفكير في تجربة الاستخدام، خوفًا من المُصطلح رُبّما.
مثال بسيط على هذا الأمر يُمكن مُلاحظته في تطبيق ستاربكس (Starbucks) وتطبيق “نيرو” (Nero)، على الأقل هنا في تركيا. عند البحث عن أماكن توفّر “نيرو” داخل تطبيقه الرسمي ستحصل على خارطة لا تحتوي مثلًا على زر تحديد الموقع الجغرافي لمعرفة أقرب فرع يُمكن التوجّه له، بل تحتاج إلى البحث بشكل يدوي عبر تكبير الخارطة! يتوفّر أيضًا خيار لعرض المتاجر على هيئة قائمة، لكنها لا تحتوي حتى على حقل للبحث، فهي مُرتّبة أبجديًا دون عرض بُعد كل فرع عن الموقع الجغرافي للمُستخدم.
تطبيق ستاربكس في المُقابل يُظهر أن هناك مُطوّر حقيقي خلفه، فعند التوجّه إلى القسم الخاص بالأفرع، سيقوم التطبيق آليًا بتكبير الخارطة بناءً على الموقع الجغرافي للمُستخدم لعرض الأقرب، مع إمكانية البحث بشكل يدوي ضمن الخارطة. خيار اللائحة موجود هنا أيضًا، وهو لا يحتوي على حقل للبحث كذلك، لكنه على الأقل يقوم بترتيب الفروع بحسب البُعد عن المُستخدم، وبالتالي يُمكن العثور على الأقرب دون عناء.
العملية، برمجيًا، لا تحتاج للكثير من الجهد، فالحزم البرمجية لنظامي أندرويد وiOS توفّر Methods جاهزة لتحديد الموقع الجغرافي للمُستخدم، ولا يحتاج المُبرمج سوى لتضمينها ولاحتواء بعض الأخطاء البسيطة مثل عدم موافقة المُستخدم على تفعيل خاصيّة الموقع الجغرافي داخل التطبيق. حتى البحث ضمن نتائج البحث بسيط ولا يستغرق تطويره أكثر من ساعة.
مثل هذه التفاصيل الصغيرة هي التي تُعطي تطبيقك تجربة أفضل وتدفع الجميع لاستخدامه أكثر، فالموضوع ليس مُجرّد تطوير تطبيق فقط لأن الجميع لديه تطبيق في المتجر الآن، بل يجب تقديم تجربة استخدام طبيعية تُضيف قيمة للمُستخدمين. وكمُهندس برمجيات، هذه التفاصيل الصغيرة هي التي ستُساعدك على اتخاذ القرار عند اختيار التقنيات التي يجب استخدامها في تطوير التطبيق، أي الاختيار بين كتابة تطبيق لكل منصّة على حدة، أو استخدام بعض أطر العمل التي تسمح كتابة التطبيق مرّة واحدة وتشغيله فيما بعد على جميع الأنظمة.
الخيار الأول، أي كتابة التطبيق لكل منصّة على حدة، يضمن الاستفادة من جميع الحزم البرمجية التي توفّرها شركات مثل آبل وغوغل. أما الثاني، ففي بعض أطر العمل سيخسر المُستخدم ميّزات مثل التنبيهات مثلًا، إلا أن خيارات مثل “فلاتر” (Flutter) أو (React Native) أصبحت تدعم تقريبًا جميع الحزم البرمجية. لكن، وبغضّ النظر عن التقنية المُستخدمة، فكّر في المُستخدم أولًا وأخيرًا قبل اختيار التقنية والشروع في تطوير التطبيق.
