مقدمة في تصميم واجهات المستخدم ..Introduction to UI Design كيف تصمم واجهات برامجك بطريقة الكبار http://www.orwah.net....php?storyid=59 أولا ماهو تصميم الواجهات : تصميم الواجهات ليس مجرد صف لعناصر التحكم فوق النماذج بطريقة هندسية كما يظن الكثيرون .. بل يعتمد على قدرة المصمم على تخيل كيف سيبدو شكل المنتج النهائي , وما هي الواجهات الأنسب التي سنزود المستخدم بها للتحكم ببرنامجنا , ثم بعد ذلك تأتي مرحلة ترتيب هذه الواجهات بشكلها الأكفأ . فعليا , يقع على عاتق مصمم الواجهة تحديد كيف سيتم التعامل مع البرنامج من قبل المستخدم , لذلك هو مسؤل عن تحديد ماهي العناصر التي ستوجد على الواجهة. ثم تحديد كيفية ترتيب هذه العناصر بشكل أنسب للمستخدم . في حين يظن الكثيرون ان الجزء الاخير فقط هو من مهام مصمم الواجهات . ربما يختلف الناس فيما بينهم بالكثير من الامور التي تؤثر على جودة الواجهة النهائية , وهذه بعض هذه الأمور من وجهة نظري : - حدس المستخدم العادي (الجانب الأهم من المعادلة , وهو كيف تملك حدس مستخدم المشروع النهائي , وتفهم ماذا يريد بالضبط من برنامجك) . - اساسيات السلوك البشري وخواصة . - الرؤية الفنيه والعلمية . طبعا لن اقوم في هذه العجالة بسرد أسرار تصميم UI كما تعرفون , فهي ليست غرافيكس وليست مادة مجردة تحتاج لشهادة أو لدراسة اكاديمية , وهي لاتعدو كونها مجموعة من الافكار والقوانين المنطقية التي تحسن فاعلية واجهاتك وتزيد من كفاءة المستخدم في استخدامها . دعني اعبر عن ذلك كالتالي : انها طريقة بالتفكير لحسم كيف يمكن ان تبدو الامور في النهاية , وكيف يجب ان تبدو عروة عيسى سوريا – 2005 www.orwah.net ------------------------ التحكم الكامل بالمنتج , والاستجابة لتوقعات المستخدم: منذ فترة كنت اقرأ مقالة أعجبتني على الانترنت عن نظرية علمية للدكتور "Dr.Martin.E.P.Seligman" تسمى : Learned Helplessness .. رأت هذه النظرية الضوء بعد سنين من البحث , وفكرتها ان الشعور الإنساني بالعجز هو أهم أسباب الإكتئاب البشري ونقص الفاعلية الإجتماعية . العجز هو الشعور بإنك غير قادر على التحكم بالبيئة المحيطة بك شعورك بإنك تتحكم بالوضع وأن الأمور التي تقوم بها تعمل بشكل جيد هو الذي يمنحك الرضا والمتعه ويشعرك بالسيطرة على الوضع مما يزيد من كفائتك في تنفيذ الأمور . عندما تشعر بأنك مستاء وغاضب أو مرتبك أو ضعيف ربما يكون سبب ذلك أنك تشعر بإنك لاتملك التحكم الكامل أو السيطرة ... ربما على امور صغيرة .. ولكن مجرد هذا الشعور كافي ليجعلك اقل إنتاجية . افترض معي لو أن زر الفراغ Space Bar على لوحة مفاتيحك لايعمل بشكل جيد ,وعندما تقوم بالكتابة فإن بعض الكلمات تبدو متلاصقه على غير المتوقع .. هذا سيشعرك حتما بالغضب والإنزعاج , لإنك تضغط على زر Space ولكن لا شيء يحدث .. لإن نتيجة عملك ليست كما توقعت .. أي لإنك لاتشعر بامتلاك السيطرة على لوحة المفاتيح .. (You lose control ) أجعل المستخدم يسيطر على المنتج ودعه يتربع على عرش القيادة , واحرص دائما أن ستجيب برنامجك كما يتوقع منه المستخدم ... تذكر أن الشركات تجدد برامجها باستمرار بدون وجود اخطاء واضحة في هذه البرامج , فقط لإن هذه الشركات تبحث عن الموثوقية . أي أنها تريد ان تضمن تماما ان البرنامج سيفعل حتما ما يتوقع منه . ------------------------------------------------- تنظيم الخيارات : الكثير من عناصر التحكم في الواجهات هي خيارات على الغالب .. تأمل ذلك بقليل من الهدوء ستدرك ان هذا الكلام صحيح ,,.. خيارات خيارات , كل شيء يبدو على شكل خيارات : مجموعة الأزرار بالأسفل (موافق ,لا, إلغاء أمر,تجاهل ...) هي خيارات ليختار المستخدم الوظيفة الممكنه . الأزرار الثلاث في أعلى النافذة (أغلاق تكبير تصغير) هي خيارات يستطيع اتخاذها المستخدم للخروج من النافذة . مجموعة من صناديق الأختيار .. مجموعة من الصفحات , شريط الأدوات بالأعلى,القائمة العلوية الخ ... عليك تنظيم هذه الخيارات بطريقة صحيحة لتضمن أن واجهاتك مناسبة للمستخدم لماذا الخيارات . . المستخدم يحب أختيار القرار أكثر من اتخاذ القرار يؤكد باحثو السلوك البشري أن المستخدم يجد من الأسهل ان يختار خيار من مجموعة خيارات موجودة بدلا من إدخال أمر ثابت أو حفظ الخطوات التي عليه القيام بها كل مرة .. وهذا ما ادى لظهور فكرة المعالجات Wizards التي تتولى طرح الأسئلة عليك , ووضع اختيارات للإجابه فيما يقتصر دورك على الاختيار من هذه الخيارات , بحيث تضمن انك تستطيع التعامل مع البرنامج ولو كانت اول مرة تشغله فيها . قلل عدد القرارات التي يجب ان يقوم بها المستخدم .. لاداعي لإرباك المستخدم بكمية كبيرة من الخيارات التي قد لايحتاج لها غالبا , المستخدمون يكرهون ذلك كثيرا , هل لاحظت أن المستخدم العادي مهووس بالبرامج التي تعمل بضغطة زر واحدة , أو التي تنصب نفسها بنقرة واحدة كذلك .. تذكر . إذا كنت انت غير قادر على أتخاذ بعض الخيارات الخاصة ببرنامجك فلا داعي لإن يكون المستخدم قادرا عليها أبرز الخيارات المهمة والمتكررة , وأترك الخيارات الباقية متاحة حسب الطلب في كثير من الاحيان لايمكن الإستغناء عن هذه الخيارات لإنها مطلوبة لجعل المستخدم يتحكم بشكل كامل بالبرنامج كما أتفقنا منذ قليل , لذلك في هذه الحالات عليك بحل وسطي, وهو تجزءة أنواع الخيارات حسب كثره استخداماتها , ربما بطريقة شبيهه بالتالي : - خيارات أساسية (يجب ضبطها حتما أثناء تنصيب البرنامج او اثناء أول إقلاع) - خيارات مهمة (تكون واضحة وظاهرة أفتراضيا تظهر أمام المستخدم عند الحاجة لها ) - خيارات أقل أهمية (تظهر في قائمة خيارات خاصة) - خيارات إضافية (تكون غير ظاهرة أفتراضيا , حيث تفصل عادة بزر more setting أو "المزيد" عند الضغط عليه يتوسع المربع , وتظهر مجموعة الخيارات الجديدة . او يمكن وضعها في صفحة فرعية من صفحة الخيارات) - خيارات المستخدمين المتقدمين (مهم وجودها , ولا داعي لوضعها مع مجموعة الخيارات العادية , لذلك عادة ما تكون في صفحة منفصلة وخاصة أقل بروزا من الخيارات المهمة) حافظ على الخيارات الأفتراضية في برامجك , واتركها مفعله بشكل افتراضي ولاتنسى دائما ان المستخدمون معظمهم لايقرؤن الرسائل ويخافون حتى من اختيار حالة من مجموعة حالات , لذلك حافظ دائما على وجود اختيار أفتراضي مفعل , ربما مكتوب عندة recommended . ميز الرسائل المختلفة بأيقونه على يمين الرسالة تبين وصف نفسي لمحتوى الرسالة (رسالة خطأ , أم رسالة توضيحية أم رسالة تأكيد ) يحتاج المستخدم للسرعة , ومع الزمن يصبح ينفذ الامور أوتوماتيكيا , لذلك عليك ان تحمي المستخم من الخطأ بسبب التشابه بين الواجهات .. لاتطلب من المستخدم الإجابه على أسئلة تقنية يهم المستخدم تنفيذ الأمر ولايهتم بطريقة القيام بذلك , لذلك لايجب سؤال المستخدم عن تفاصيل التنفيذ يجب ان تتعلم الفصل التام بين user module و program module أستبدل أسماء الخيارات التي تحتاج معرفة تقنية , بأسماء توضح كيفية تأثير كل من هذه الخيارات على أداء البرنامج مثلا بدلا من سؤال المستخدم إذا كان يفضل ان تكون قاعدة بيانات البحث في المساعدة مفهرسة اولا , يمكنك ان تسألة إذا كان يريدها سريعة أم بحجم صغير وأقل سرعة , فهو غير معني بالطريقة , بل معني بالنتيجة . ولاداعي لذكر مصطلحات تقنية في الخيارات , فهي تخصك انت ولاتخصة هو . وكمثال على هذا الكلام لاحظ هذه الصورة لقائمة خيارات برنامج الضغط الشهير winrar : من الجيد أن يعرف المستخدم كيف سيؤثر خيارة على التنفيذ . لاحظ هذه الصورة التي أخذتها عن برنامج مشهور , هذا ما أسمية قائمة خيارات فاشلة : أولا , لايوجد خيار افتراضي ثانيا , لايجب وضع مصطلحات تقنية لمستخدم عادي (مالم تكن طبيعة البرنامج خاصة بالتقنيين) ثالثا , لن يعرف المستخدم كيف سيؤثر قرارة على العمل , ولن يفهم مامعني قاعدة بيانات أو مالفرق بين الملفات النصية وملفات ini .. مع أن الشركة التي قدمت البرنامج تظن أنها تؤمن وظائف إضافية مفيدة , ولكنها قضت على فائدة هذه المجموعة من الخيارات , لإن معظم المستخدمين لن يعرفوا كيفية استخدامها , ولن يجرؤ المستخدم على العبث بشيء لايعرف عنه شيء تذكر : أن المستخدم يكون سعيد عندما يتخذ قرارات تتعلق به هو , وكيفية استخدامه للمنتج , ولكنه سيكون مستاء من اتخاذ قرارات تتعلق بطبيعة عمل البرنامج يحق للمستخدم ملائمة الخيارات الخاصة به , ولكن لايحق له إجباره بها اسمح للمستخدم بتغيير الإعادات واختيار الأعدادات الخاصة به والملائمة له Customization .. مثل تغيير الخط والخلفية واللون , واعداد أشرطة الادوات ولكن لاتجبرة بذلك ولاداعي لإن يظهر نموذج الخيارات كلما اشتغل برنامجك لاتضع خيار لن يستخدمة احد ----------- المستخدم ليس عدوك ؟ لماذا لانصمم برامج من اجل ناس تملك أمور أفضل لتقضي حياتها معها ؟. عندما تصمم واجهه تذكر انه : 1- المستخدم لايملك دليل الاستخدام , وإذا ملكة تأكد انه لن يقرأه . 2- بالحقيقة المستخدم لا يقرأ شيئا أصلا , حتى رسائل التنبيه التي تنتهي بزر وحيد (OK) ينظر لها أنها غير مفيدة , وأي رسالة أطول من سطر ونصف هي رسالة مكتوبة بالهيروغليفية , ولاتتوقع قراءتها. 3- المستخدم لايتذكر شيئا , لاتحاول الإعتماد أبدا على ذاكرة المستخدم لإعادة تنفيذ المهام المتكررة والقانون دئما هو: الذاكرة الإفتراضيه للمستخدم تساوي الصفر . 4- المستخدم يريد برامج لاتحتاج على تركيز بالعمل , يريدها أن تسهل حياته وأن تقوم بالأعمال الروتينية عوضا عنه . كل ذلك قد لايكون حقيقية ’ وحتما ليس عام على كل المستخدمين , ولكن لا بأس بالنظر إليه على انه حقيقة وعام على الجميع , لإنه يجعلك تفكر كيف تبني برنامج يريح المستخدم اكثر ويناسب كمية اكبر من المستخدمين. التصميم وهذه الأفكار راسخة بالمخيلة يسمى "إحترام المستخدم , وتبسيط حياته" - يحق للمستخدم ان يسمع رنين الهاتف بالغرفة المجاورة عندما يكون على برنامجك - يحق له أن يسمع صوت بكاء الطفل في الطابق العلوي بعدما يبدأ عملية ما , ويحق له مقاطعة العملية بأي لحظة . - لايحق لك تحويل المستخدم الى معقد مصاب بالفصام جالس بتظارتين سميكتين ومعزول تماما عن الخارج ... فقط لإن البرامج التي تبنيها تحتاج تركيز وحذر بالاستخدام البرامج الجيدة تتساهل مع اخطاء المستخدم بامتنان وتحميه منها , وتوجهه نحو الخيارات الإفتراضية دوما أستخدم رموز معبرة عن طبيعة المعلومات المعروضة في الرسائل ومربعات الحوار ذاكرة الإنسان ذاكرة صورية , ومعالجة المعلومات الصورية أسرع بكثير من المعلومات الكتابية .. لذلك لابأس باستخدام صور معبرة عن طبيعة المعلومة التي تريد اخبارها للمستخدم مثلا أيقونة صغيرة تحوي علامة X بالأحمر عند حدوث خطأ , أيقونة صغيرة تحوي علامة استفهام بالأخضر عند طلب معلومات من المستخدم أيقونه صفراء مع إشارة تعجب للتأكيدات الخ ... أستخدم أسماء مناسبة لأزرار مربعات الحوار , بدلا من الأمرين المعروفين : yes و NO . بدلا من استخدام أزرار تحوي نفي أو إيجاب ("yes" , "No" ) , سمي الأزرار بالأفعال التي ستقوم بها , مثلا بدلا من : "هل تريد الحفظ " [yes][no] يمكنك القيام بالتالي : "تأكيد حفظ البيانات "[save][don’t save] * وهذه من الإنتقادات المذكورة على نظام MS Windows نفسة . ميز السؤال الذي تريد المستخدم ان يجيب علية عن المعلومات الإضافية التي تشرح سبب المشكلة . المستخدم لايحب ان يقرأ أكثر من سطر , دعنا نقل أنه يفضل ان لايقرأ شيء احذر من الرسائل الطويلة التي على المستخدم أن يقرأها كلها حتى يفهم ما المطلوب .... لانه على الغالب سوف يضغط زر "موافق" ما ان يرى كمية من النص اكبر مما هو مستعد للتضحية من اجلة من وقت الثمين ... لذلك دائما أفصل بين المعلومات التوضيحية لسبب المشكلة مثلا , وبين السؤال الذي يجب على المستخدم ان يتخذ قرار فيه لاحظ هذه الرسالة المثالية في MAC : كما تلاحظ , هكذا يجب ان تكون رسائلك - نص الخيار بالعريض , ليسمح للمستخدم بالتمييز بين المعلومات المتعلقة باختيار القرار (المعلومات المهمة) , والحشو الذي هو عبارة عن معلومات توضيحية ليعرف المستخدم إذا أراد ماذا حدث ولماذا سيتخذ قراره . - أيقونه متعارف عليها في انظمة Mac OS على الجانب , تحيط الرسالة بتوقع نفسي عن طبيعة الطلب - لاحظ , لم يتم وضع أسماء الأزرار Yes , No , بل تم وضع الأفعال التي ستقوم بها هذه الخيارات , مما يضمن عدم وقوع المستخدم بالخطأ . - وجود خيار افتراضي مفعل ------ تذكر ان تراعي الإنتقال بزر TAB بشكل دقيق المستخدمين غير قادرين على التحكم بالفأرة بشكل دقيق , لذلك لاتعتمد على الفأرة فقط في برنامجك - استفد من الإختصارات في لوحة المفاتيح , وادعمها في برنامجك . راقبت المستخدمين المتقدمين بالشركات التجارية ووجدت ان العمل 100% على لوحة المفاتيح . تذكر ان إنتقال اليد من الفأرة على لوحة المفاتيح وبالعكس يأخذ فاصل زمني "t" كبير نسبيا في هذا العصر . لذلك يفضل المستخدمون الاعتماد على احدها بالدرجة الأساسية , وبما انه لاغنى عن لوحة المفاتيح للإدخال إذن لابأس بالتفكير ان اختصارات لوحة المفاتيح ستكون فكرة سديدة , لإنها ستسرع العمل على المستخدم إذا كنت تظن أن الأسباب السابقة متعلقة بالمستخدمين المتقدمين زيادة عن اللزوم فأنت غلطان : - الكثير من المستخدمين يعملون على حاسب محمول - الكثير من المستخدمين يجدون من الصعوبة النقر المزدوج بالفأرة من دون أنن تتحرك قليلا أثناء ذلك وتتحول العملية إلى سحب وأفلات . - الكثير من المستخدمون عليهم لف جسمهم بالكامل ورفع يدهم اليسرى عاليا حتى يستطيعو إيصال مؤشر الفأرة إلى زر X في اعلى الشاشة . ما رأيك الآن , المستخدم القوي Power Users يريد اختصارات لوحة مفاتيح المستخدم الضعيف Weak users يريد اختصارات لوحة مفاتيح أيضا ... لماذا تطلب من مستخدميك ان يكونوا روبوتوات وأنت ادرى بواقع بلداننا العربية ؟؟ لاتستخدم زر Speed Button لايقف عليه TAB وليس له أختصار , لإنه من غير المقبول ان تكون الفأرة هي الوسيلة الوحيدة للوصول إليه ((أعرف ان ذلك موجود في كثير من برامج سوقنا المحلي , ولكن دعنا نفرض أنه غير مقبول .. لإن ذلك أسلم وأقرب للتقوى )) المختصر المفيد : لاتجبر المستخدم بالعمل على الفأرة فقط في برنامجك , وراعي إنتقالات TAB وإختصارات لوحة المفاتيح ------ ساعد المستخدم على توقع عمل الاجزاء المختلفة من برنامجك لاتهمل التعليقات المنبثقة Hints , والشروحات البسيطة في شريط المعلومات السفلي , والأيقونه المعبرة تماما عن الفعل , فهي تساعد المستخدم على توقع عمل واستجابه الاجزاء المختلفة لاتفضل أبدا البرنامج الجميل الشكل على البرنامج العملي لإنه بعد اول أسبوع من التعامل مع البرنامج ستنسى بالكامل موضوع جمال البرنامج وستصبح ممتن للمبرمج الذي يسهل عملك , ولو أرعبه شكل البرنامج في البداية . لاتجعل المستخدم يشعر أنه اخطأ مهما كان السبب , لإن البرامج القوية لاتسمح للمستخدم بالخطأ . لايوجد شيء يسمى "لايحق للمستخدم ان يفعل كذا" ... بل "لايحق لي أن أسمح للمستخدم بفعل هذا الشيء" إي إذا كنت تعرف بإنه لايجب على المستخدم النقر على زر ما فلاداعي للسماح له بنقر الزر ثم اظهار رسالة خطأ ... فقط قم بجعل الزر غير مرئي أو غير مفعل ... عنصر التحكم المرئي والمفعل يجب ان يعمل شيء مفيد , وإلا ألغي إحداهما . استبدل "لايحق للمستخدم ان يفعل شيء ما" بـ "لايحق لي أن أسمح للمستخدم بفعل هذا الشيء" المستخدم لايتذكر شيئا .. الذاكرة الإفتراضيه في دماغ المستخدم هي صفر دوما , ويجب على برنامجك اوتوماتيكيا حفظ كافة اعدادات المستخدم , ولابأس بتذكر آخر ملفات تعامل معها المستخدم لإنها ستسهل من امكانية التعامل معها مجددا (تعجبني خاصية ReOpen في قائمة ملف , قلدها في برامجك) القياســــيـة - حتى ولو لم تكن مقتنعا انه صحيح , إذا قامت شركة مثل مايكروسوفت بشيء ما في منتج مشهور لها (مثل MS Word) أو غيرة , فإنه من المناسب التفكير أن الناس ستكون متأقلمة معه , وستنظر إليه على انه قياسي وواضح ببساطة سيجدونه سهلا لإنه سبق وتعاملوا معه - لاتكن متأكدا انه ليس صحيح لإن مايكروسوفت تصرف الكثير من الوقت والمال للتأكد من ان برامجها تناسب المستخدمين , وبمجرد طرحها لفكرة جديدة في الواجهه أعلم انها فكرة ممتازة أو انها ستصبح فكرة أفتراضيه وعامة , وفي كلا الحالتين لابأس بتقليدها في برامجك . القياسية لاتتعلق بالصحيح والخاطيء , بل تتعلق بالإنتشار . والإنتشار هو الذي يكسبك اعتيادية بالتعامل مع الوظائف الأساسية .. لدي الكثير من التعليقات على واجهات ميكروسوفت ويندوز , ولكنها غير مهمه باعتبار أنه حتى الأولاد اصبحو متمرسين فيها , وصارت تدرس من أساس استخدام الحاسوب , مع انها كان يمكن ان تكون أفضل . حافظ على قياسية برامجك , وقلد واجهات الأنظمة والبرامج المشهورة أذكر مرة رأيت برنامج مصمم وكأنه يشبه السفينة الفضائية ,وعندما سألت المبرمج عن زر الإغلاق .... قال لي بفخر .. إحزر أين هو ؟ ماهذا ؟؟ ومن قال أنه على المستخدم أن يحزر كيف سينفذ عمل ما .. أفضل برنامج DOS يقبل امر exit بدلا من سفينة فضائية لا أستطيع الخروج منها ! ------- المزيد في تصميم الواجهات أفهم ماذا يريد المستخدم تقسم العملية البرمجية على ثلاث نماذج : Machine Module : وهو الجزء المتعلق بجهاز الحاسب الذي سيقوم بتنفيذ برنامجك فيزيائيا . Program Module : وهو الجزء المتعلق ببرنامجك وبك انت كمبرمج . User Module : وهو الجزء المتعلق بمستخدم البرنامج النهائي , وهو هدف الأجزاء السابقة . يجب ان تعرف أن مايهم المستخدم من هذه الاجزاء هو الجزء الاخير, وهدف برنامجنا هو خدمة المستخدم .. لذلك سأقسم تفكيرنا في المشروع من منظورين مبدأيا : - نفكر من منظور المستخدم لتحديد مهام البرنامج وخواصة - ونفكر من منظور المبرمج فقط لتحديد كيفية تنفيذ هذه المهام والخصائص . يهم المستخدم تنفيذ المهمة ولا يهتم بالطريقة التي يتم فيها تنفيذ ذلك . ولايجب عليك ان تبالي كثيرا بصعوبة القيام بتفاصيل صغيره مادامت ستخدم المستخدم بالنهاية .. وبنفس الوقت لاتشغل المستخدم بأي من التفاصيل التي تدور في Program Module فهو ليس مسؤول عنها , وينحصر اهتمامه على تنفيذ الوظائف فقط . أجعل المستخدم يشعر بالتفاعلية أثناء التحكم . ودائما أتح له أمكانية التراجع عن عمل ما بعد القيام به , أوأمكانية إلغاء أمر ما بعد البدء , أو مقاطعة عملية أثناء تنفيذها ... إسمح للمستخدم بتنفيذ مهامة بأكثر من طريقة تستطيع في أي من برامج ويندوز الوصول إلى نفس الأمر بالعديد من الطرق : زر , شريط أدوات , قائمة رئيسية , اختصار لوحة مفاتيح , قائمة يمنى الخ .. هذا يعتبر تصميم جيد لواجهات المستخدم . ضع المعلومات المهمة في الزاوية العليا اليمنى من الشاشة بسبب التأثيرات الثقافية تتعقب عيوننا لا أراديا الزاوية العليا اليمنى من الشاشة وتتابع لباقي اجزاء الشاشة , ضع المعلومات الأهم في هذه الزاوية , بالنسبة للبرامج الاجنبية , فبالعكس نستخدم الزاوية العليا اليسرى جمع العناصر المرتبطة مع بعضها في مكان واحد ربما باحاطتها بمربع او بوضعها في صفحة مستقلة , او فصلها بخط افقي .... أي شيء يبين وحدتها العضوية حدد من عدد الالوان التي تستخدمها الألوان الكثيرة تصرف نظر المستخدم , وتشتت التفكير .. لاتكثر أبدا من الألوان , وحافظ على الوقع النفسي للألوان , فالألوان الحمراء خطرة عنوانية , والخضراء آمنه استفسارية , الزرقاء بارزة سؤالية , وهكذا .. حدد عدد الخطوط التي تستخدمها كذلك الامر تماما بالنسبة للخطوط , وخاصة في مواقع الويب . تجنب قدر المستطاع الخطوط المزخرفة كثيرا , والخطوط المائلة , فهي خطوط استعراضية غير مناسبة لبرامج عملية . وحد حجوم عناصرك وارصفها بمحاذاة بعضها من المهم جدا الحفاظ على أطوال قياسية ثابتة للعناصر , ولاداعي لوجود اختلافات في ارتفاع الصف الواحد , او أختلاف في عرض عناصر العمود الواحد , الشكل الهندسي المقطع شبكيا من السهل الإنتقال فيه بالنظر.. رصف المكونات بموازاة بعضها يسهل من عملية ضبط الشاشة وتقسيمها بشكل آلي من العين . يجب ان تبدأ المكونات من نفس البعد عن الحافة اليمنى (للبرامج العربيه) . استخدام حجوم مختلفة وألوان كثيرة وخطوط في برنامجك سيجعل الوضع خبيصة , يسميها مختصو التقنية Clown-pants Design .. ابتعد عنها أزرار الحكم على فقرة ما تكون أسفل يسار الفقرة عندما يوجد نص يقرأة المستخدم ثم يضغط زر ضع الزر على يسار النص من الاسفل , وذلك لمجاراة سياق القراءة الطبيعي "من اليمين لليسار" حيث تقوم العين البشرية آليا بالمسح بهذا الإتجاه , وتولد شعور نفسي أن هذا الزر تابع لهذه الفقرة . في حال وجود اكثر من زر , تأكد من كون الزر الافتراضي مفعل أولا . حافظ على أمن واجهاتك لاتجعل الأزرار التي تنفذ مهام خطيرة بنفس وضوح الأزرار العادية . أفصلها وميزها عن بعضها بطريقة ما .. مثلا نبعد زر الحذف ضعف المسافة المعتبرة بين الزر والزر , في حين يكون زرا عدم الحذف وإلغاء الامر يملكان مسافة قياسية , مما يجعل المستخدم يدرك مباشرة ان مهمة هذا الزر ليست قياسية , او ليست آمنه لاتنسى وجود رسائل التاكيد لكل المهام الخطيرة , كالحذف والتراجع رسائل التاكيد يفضل ان تحوي معلومات مميزة للبيانات التي ستحذف , وليس فقط تأكيد روتيني للحذف . مثال : بدلا من : "هل أنت متأكد انك تريد الحذف " [نعم][لا] نستخدم : "هل أنت متاكد انك تريد حذف سجل الموظف 'عروة' , ذو الرقم '150' ."[حذف][عدم الحذف] الواجهة الهندسية أفضل من الواجهة الفنية : تذكر ان برنامجك لي لوحة زيتية لفنان تشكيلي , وسهولة استخدام الواجهة وأمنها أهم من جمالها , لذلك حافظ على القياسات الهندسية الموحدة في برنامجك واتبع نموذج واضح في كل البرنامج من الرصف والحجوم والأبعاد : ----------------------- يحق لك استخدام نشر وتوزيع هذه المادة كيفما تشاء , وسنكون ممتنين في حال الإشارة إلينا كمصدر : مقدمة في تصميم واجهات المستخدم