ترس از یک صفحه خالی هنگام طراحی رابط. اصول طراحی رابط کاربری در مرحله طراحی رابط چه کاری نباید انجام داد

2.2. مراحل طراحی یک سفارشی رابط

تحقیقات انجام شده در یک زمان در جنبه های روانشناختی ارتباط انسان با رایانه نشان داد که باید از هر راه ممکن برای غیرانسانی کردن این ارتباط تلاش کرد، یعنی کاربر نباید رایانه را به عنوان یک گفتگوی تمام عیار درک کند. با این وجود، تبادل اطلاعات بین کاربر و رایانه (به طور دقیق تر، نرم افزار آن) با توجه به تمام ویژگی های رسمی با مفهوم "گفتگو" به معنای عمومی پذیرفته شده مطابقت دارد. احتمالاً خواننده، حتی بدون کمک فرهنگ لغت توضیحی، می‌تواند قوانین اساسی را که برای سازنده بودن گفتگو باید رعایت شود، فهرست کند:

اولاً، شرکت کنندگان در گفتگو باید زبان یکدیگر را درک کنند.

ثانیاً نباید همزمان صحبت کنند.

ثالثاً، بیانیه بعدی باید هم زمینه کلی گفتگو و هم آخرین اطلاعات دریافتی از طرف گفتگو را در نظر بگیرد.

اگر طرفین در مورد موضوعات مربوط به هر زمینه خاصی بحث می کنند، باید از همان اصطلاحات استفاده کنند. اگر یکی از آنها می خواهد چیزی را برای دیگری توضیح دهد، ابتدا باید اصطلاحات و مفاهیم اساسی را توضیح دهد.

همچنین باید اضافه کرد که استفاده از وسایل بیانی اضافی به درک بهتر متقابل کمک می کند. گاهی اوقات یک تصویر موفق جایگزین ده ها کلمه می شود. به عنوان مثال، به سؤال "چگونه به کتابخانه برویم؟" بهتر است با نقشه شهر پاسخ دهید.

حالا بیایید به یاد بیاوریم که طرف مقابلمان چه چیزی را دوست ندارد.

اول از همه - آشنایی بیش از حد. علاوه بر این، افراد کمی دوست دارند که در حین مکالمه، آستین خود را بکشند، یک دکمه را باز کنند یا از روش‌های اصلی دیگر برای جلب توجه استفاده کنند. پاسخ‌های بسیار کوتاه و مکث‌های بسیار طولانی می‌تواند مخاطب را گیج کند و سوء استفاده از اصطلاحات فنی یا اصطلاحات تخصصی به طور کلی می‌تواند منجر به پایان زودهنگام مکالمه شود.

استدلال فوق بسیار کلی است و تقریباً برای هر دیالوگی، صرف نظر از رابطه بین طرفین و هدف گفتگو، صدق می کند. با این حال، این عوامل به طور قابل توجهی تاثیر می گذارد ساختار دیالوگ، یعنی شکل ارتباط. برای مثال، اگر دو دوست یکدیگر را ملاقات کنند، گفتگو شبیه یک بازی تنیس است: ابتکار عمل بین یکی و دیگری متناوب می شود. اگر به رستوران می‌آیید، ارتباط شما با پیشخدمت محدود به انتخاب غذا از منوی پیشنهادی می‌شود و وقتی برای پاسپورت خارجی درخواست می‌کنید، مسئول از شما می‌خواهد که یک یا دو فرم را پر کنید و سپس آنها را بررسی کنید. در صورت لزوم، توضیح برخی نکات.

بنابراین، هنگام طراحی یک رابط کاربری، باید تعیین کنید:

ساختار گفتگو؛

سناریوی ممکن برای توسعه گفت و گو؛

ویژگی های بصری اطلاعات نمایش داده شده (سینتکس پیام).

2.2.1. انتخاب ساختار دیالوگ

انتخاب ساختار دیالوگ اولین مرحله ای است که باید هنگام توسعه یک رابط تکمیل شود.

چهار گزینه برای ساختار گفتگو که در زیر مورد بحث قرار می‌گیرند، انواعی از ساختار «پرسش-پاسخ» هستند، با این حال، هر یک از آنها ویژگی‌های خاص خود را دارند و برای کلاس خاصی از وظایف راحت‌تر هستند.

دیالوگ از نوع "سوال - پاسخ".

ساختار گفتگوی پرسش و پاسخ (Q&A) بر اساس یک قیاس با یک مصاحبه معمولی است. این سیستم نقش مصاحبه گر را بر عهده می گیرد و اطلاعات را در قالب پاسخ به سوالات از کاربر دریافت می کند. این شناخته شده ترین ساختار گفتگو است. همه دیالوگ های کنترل شده توسط کامپیوتر، تا حدی یا دیگری، شامل سوالاتی هستند که کاربر به آنها پاسخ می دهد. با این حال، در ساختار پرسش و پاسخ این فرآیند به صراحت بیان شده است. در هر نقطه از گفتگو، سیستم یک سوال را به عنوان یک اشاره نمایش می دهد که کاربر یک پاسخ به آن می دهد. بسته به پاسخ دریافتی، سیستم می تواند تصمیم بگیرد که کدام سوال بعدی را بپرسد. ساختار پرسش و پاسخ مکانیزمی طبیعی برای وارد کردن پیام‌های کنترلی (فرمان‌ها) و داده‌ها فراهم می‌کند. هیچ محدودیتی در محدوده یا نوع داده های ورودی قابل پردازش وجود ندارد. سیستم هایی وجود دارند که پاسخ ها را به زبان طبیعی ارائه می دهند، اما اغلب از جملات تک کلمه ای با دستور زبان محدود استفاده می کنند.

گفتگو در قالب پرسش و پاسخ به اندازه کافی پشتیبانی کاربر را فراهم می کند، زیرا حتی یک سوال پیشرو کوتاه، اگر ساختار عاقلانه ای داشته باشد، می تواند خود توضیحی باشد. ساختار پرسش و پاسخ حداقل مقدار ورودی را که با تعداد ضربه های کلید اندازه گیری می شود را تضمین نمی کند، اما با انتخاب مناسب اختصارات، هر افزونگی را می توان کاهش داد. با این حال، ساختار پرسش و پاسخ یک اشکال مهم دارد. حتی اگر ورودی به اندازه کافی سریع باشد، برای شخصی که از قبل می داند سیستم چه سوالاتی می پرسد و چه پاسخ هایی باید بدهد، پاسخ دادن به کل مجموعه سوالات کاملا خسته کننده است.

با ظهور رابط گرافیکی، ساختار پرسش و پاسخ تا حدودی قدیمی شده است، اما هنوز دارای مزایای خاصی است. این ساختار می تواند نیازهای کاربران و انواع داده های مختلف را برآورده کند. به طور خاص، چنین ساختاری به ویژه هنگام اجرای گفتگو با بسیاری از "شاخه ها" مناسب است. در مواردی که هر سؤال دارای تعداد زیادی پاسخ است که هر کدام از آنها بر روی سؤال بعدی تأثیر می گذارد. به همین دلیل، ساختار پرسش و پاسخ اغلب در سیستم های خبره استفاده می شود.

دیالوگ مبتنی بر منو

منوها شاید محبوب‌ترین گزینه برای سازماندهی درخواست‌های ورودی در خلال گفتگوهای کنترل‌شده توسط رایانه باشند.

چندین فرمت اساسی برای نمایش منوها روی صفحه وجود دارد:

فهرستی از اشیاء که با نشانه مستقیم یا با نشان دادن یک عدد (یا کد یادگاری) انتخاب شده اند.

منو به شکل بلوک داده؛

منو به شکل یک خط داده؛

منو به شکل آیکون

یک منوی نوار داده می تواند در بالا یا پایین صفحه ظاهر شود و اغلب در طول مکالمه در آن موقعیت باقی می ماند. بنابراین، از طریق منو، نمایش گزینه های ممکن برای داده های ورودی موجود در هر زمان در حین کار با سیستم راحت است. اگر سیستم دارای تنوع کافی از گزینه های عمل باشد، یک ساختار سلسله مراتبی از منوهای مربوطه سازماندهی می شود. منوهای اضافی به شکل بلوک‌هایی از داده‌ها در موقعیتی که با موقعیت فعلی نشانگر تعیین می‌شود، روی صفحه ظاهر می‌شوند، یا مستقیماً از نوار منوی سطح بالا «افتاده می‌شوند». این منوها پس از انتخاب یک گزینه ناپدید می شوند.

منوهای به سبک نماد دارای انواع انتخاب های پراکنده در سراسر صفحه هستند. اغلب اشیاء انتخابی حاوی نمایش های گرافیکی از گزینه های کاری هستند.

کاربر یک منوی محاوره‌ای می‌تواند با وارد کردن یک رشته متنی که آن مورد را شناسایی می‌کند، مستقیماً به آن اشاره کند، یا مرور و انتخاب از یک فهرست، یک مورد را انتخاب کند. این سیستم می تواند آیتم های منو را به صورت متوالی نمایش دهد و کاربر با فشار دادن یک کلید، آیتم مورد نیاز خود را انتخاب کند.

از منو می توان به همان اندازه برای وارد کردن پیام های کنترلی و داده ها استفاده کرد. ساختار منوی مناسب به اندازه و سازماندهی آن، نحوه انتخاب آیتم های منو و نیاز واقعی کاربر به پشتیبانی از منو بستگی دارد.

ساختار از نوع منو طبیعی ترین مکانیسم برای کار با دستگاه های اشاره گر و انتخاب است: منو نمایشی از اشیایی است که کاربر انتخاب می کند. اگر محاوره کاملاً از منوها تشکیل شده باشد، می توان یک رابط متوالی را پیاده سازی کرد که در آن کاربر فقط از دستگاه های اشاره گر استفاده می کند. با این حال، چنین سازگاری به ندرت در عمل قابل دستیابی است. همچنین لازم به ذکر است که اگرچه کار با این دستگاه ها به مهارت های صفحه کلید حرفه ای نیاز ندارد، اما برای یک کاربر آموزش دیده این سریع ترین راه برای انتخاب از منوها نیست. کاربر می تواند به جای مشخص کردن، انتخاب خود را با وارد کردن شناسه مناسب نشان دهد.

یک منو راحت ترین ساختار گفتگو برای کاربران آموزش ندیده است. نظم سفت و سخت باز کردن و تودرتوی سلسله مراتبی منوها می تواند یک حرفه ای را آزار دهد و کار او را کند کند. ساختار منوی سنتی به اندازه کافی انعطاف‌پذیر نیست و تکنیک‌های انطباق دیالوگ، مانند تایپ پیش‌رو را که می‌تواند سرعت کار یک کاربر آموزش‌دیده را تسریع بخشد، به طور کامل در خود جای نمی‌دهد. مسائل مربوط به سازماندهی و ارائه بصری منوها با جزئیات بیشتر در بخش "طراحی کنترل ها" مورد بحث قرار گرفته است.

دیالوگ بر اساس فرم های صفحه نمایش

هر دو ساختار نوع پرسش-پاسخ و ساختار نوع منو شامل پردازش یک پاسخ واحد در هر مرحله از گفتگو هستند. دیالوگ مبتنی بر فرم های صفحه امکان پردازش چندین پاسخ را در یک مرحله از گفتگو فراهم می کند. در عمل، فرم‌ها عمدتاً در مواردی استفاده می‌شوند که حسابداری هر فعالیتی مستلزم وارد کردن یک مجموعه نسبتاً استاندارد از داده‌ها باشد. فردی که فرم را پر می کند می تواند دنباله پاسخ ها را انتخاب کند، به طور موقت از یک سؤال خاص صرف نظر کند، برای تصحیح پاسخ قبلی به عقب برگردد و حتی «فرم را پاره کند» و شروع به پر کردن یک سؤال جدید کند. او تا زمانی که فرم را به طور کامل پر کرده و به سیستم ارسال کند با آن کار می کند. سیستم نرم افزاری می تواند هر پاسخ را بلافاصله پس از ورود بررسی کند یا تنها پس از پر کردن کل فرم منتظر بماند و لیستی از خطاها را نمایش دهد. در برخی از سیستم ها، اطلاعاتی که کاربر وارد می کند تنها زمانی در دسترس است که کاربر پس از تکمیل فرم، enter را فشار دهد. تصمیم گیری در مورد اینکه آیا مستقیماً پاسخ را بررسی کنیم یا بررسی را به تأخیر بیندازیم تا زمانی که همه پاسخ ها وارد شوند، تصمیم گیری دشوار است: پیام های خطایی که بلافاصله پس از پاسخ نمایش داده می شوند می توانند حواس را پرت کنند، اما می توانند تأثیر مثبتی نیز داشته باشند. به طور کلی، در مواردی که اطلاعات برای ورودی از کل یک سند انتخاب می شود، بهتر است بررسی را به پایان تکمیل فرم موکول کنید تا فرآیند ورودی قطع نشود. اگر چنین یکپارچگی وجود نداشته باشد، بررسی باید بلافاصله پس از وارد کردن پاسخ (پس از پر کردن فیلد بعدی) انجام شود.

در صورت بروز هرگونه خطایی، برنامه نباید فرم خالی را دوباره ارائه کند. یک فرم با پاسخ های قبلی و اشتباهات انجام شده نمایش داده می شود. یک "فرم" جدید فقط در صورت درخواست کاربر صادر می شود.

بنابراین، این ساختار برای اعمال در جایی مناسب است که منبع داده یک فرم سند ورودی ("کاغذ") موجود است.

نیازی نیست که ظاهر این فرم ها یکسان باشد (این امر حتی ممکن است داده های روی صفحه را کمتر دیده شود)، اما تمام عناصر داده وارد شده باید به همان ترتیب و فرمت نسبی سند اصلی باشند.

اغلب همه واحدهای ورودی مورد نیاز را نمی توان به طور همزمان در یک صفحه نمایش (یا پنجره) نمایش داد و باید به گروه هایی تقسیم شود که در یک سری از صفحه نمایش ها (پنجره ها) نمایش داده می شوند. مهم این است که این تقسیم، ارتباطات منطقی را حفظ کند و منجر به جدا شدن بخش های مرتبط سند نشود.

ساختار گفتگوی مبتنی بر فرم صفحه نمایش سطح بالایی از پشتیبانی کاربر را فراهم می کند: پیام های خطا و اطلاعات راهنما را می توان برای هر سؤال فرم ارائه کرد. همچنین می توانید با قرار دادن برخی از عناصر قالب پاسخ در سؤال یا در قسمت پاسخ، به کاربر کمک کنید. این ساختار امکان ورود سریع‌تر داده‌ها را نسبت به ساختار پرسش-پاسخ فراهم می‌کند و امکان دستکاری طیف وسیع‌تری از ورودی‌ها را نسبت به یک منو فراهم می‌کند. علاوه بر این، کاربران با هر مدرکی می توانند با آن کار کنند. از آنجایی که این ساختار به جای اینکه مبتنی بر درخت باشد، ترتیبی است، برای کار در حالت انتخاب کمتر مناسب است. یکی دیگر از زمینه های کاربردی برای فرم های صفحه، تنظیم پارامترهای پرس و جو در پایگاه های داده است. این مکانیسم گاهی اوقات پرس و جو الگو نامیده می شود ( پرس و جو توسط مثال).

یکی از انواع پر کردن فرم نیز منوهای چند گزینه ای است. در چنین منوهایی، فهرستی از گزینه ها به کاربر ارائه می شود و به یک انتخاب محدود نمی شود. می توانید چندین گزینه را مشخص کنید.

گفتگو بر اساس زبان فرمان

ساختارهای گفتگوی مبتنی بر زبان دستوری به اندازه ساختارهای نوع منو رایج هستند. این بسیار رایج در سیستم عامل ها استفاده می شود و در انتهای دیگر طیف ساختار گفتگو از ساختار نوع منو قرار دارد. از نظر تاریخی، این اولین ساختار گفتگو است که اجرا می شود.

با این نوع دیالوگ، سیستم نرم افزار چیزی غیر از یک اعلان ثابت (دعوت برای وارد کردن یک فرمان) نمایش نمی دهد که به معنای آماده بودن سیستم برای عملیات است. هر دستور در یک خط جدید وارد می شود و معمولاً با فشار دادن کلید "Enter" به پایان می رسد. مسئولیت صحت دستورات مشخص شده بر عهده کاربر است. سیستم به شما اطلاع می دهد که معمولاً بدون توضیح دلایل، اجرای یک دستور نادرست غیرممکن است.

مانند یک منو، یک گفتگوی مبتنی بر دستور برای وارد کردن پیام های کنترلی راحت است، اما انتخاب بیشتری را در هر نقطه از گفتگو فراهم می کند و به سازماندهی سلسله مراتبی برنامه هایی که به آن سرویس می دهند نیاز ندارد.

یک سیستم نرم افزاری می تواند تعداد نسبتاً زیادی دستورات را پشتیبانی کند، اما در عمل باید تعداد آنها محدود باشد تا حافظه کاربر بیش از حد بارگذاری نشود. ساختار مبتنی بر زبان فرمان از پشتیبانی کاربری خوبی برخوردار نیست و عمدتاً برای متخصصان آموزش دیده مناسب است. قبل از استفاده از چنین سیستمی، لازم است یک دوره آموزشی را طی کنید و متعاقباً ویژگی های کار را از روی مستندات مطالعه کنید، نه از روی تمرین. علاوه بر این، از آنجایی که سیستم نمی داند کاربر قصد انجام چه کاری را دارد، ارائه هرگونه کمک واقعی در این فرآیند، به غیر از صدور کمک نسبتاً کلی، دشوار است.

از آنجایی که این ساختار شامل مقدار زیادی از مطالب به خاطر سپرده شده است، نام دستورها باید به گونه ای انتخاب شوند که بار معنایی را تحمل کنند و به راحتی به خاطر بسپارند. توسعه‌دهنده باید تلاش کند از عملکردهای غیرضروری که ناشی از تمایل به ایجاد دستور خاص خود برای هر عملکردی است که توسط سیستم انجام می‌شود، جلوگیری کند، یعنی نباید دستورات مختلف زیادی با توابع اغلب همپوشانی ایجاد کند. چنین نیات "خوب" اغلب منجر به تعداد زیادی کلمات کلیدی برای دستورات و قوانین نحوی می شود که بسیاری از آنها به ندرت استفاده می شوند و فقط کار را پیچیده می کنند.

دیالوگ باید داده ها را هدایت کند. در رابط های مبتنی بر زبان فرمان، این معمولاً با استفاده از خطوط فرمان مرکب به دست می آید، جایی که یک کلمه کلیدی برای نشان دادن دستور (چه باید کرد) قبل از لیست پارامترها (ورودی) قرار می گیرد. پارامترهای موجود در لیست را می توان به یکی از دو شکل مشخص کرد - موقعیتی یا کلیدی. در حالت اول، هدف پارامتر با مکان آن در خط فرمان تعیین می شود. در مورد پارامترهای کلیدی، قبل از هر مقدار یک شناسه خاص وجود دارد که هدف آن را مشخص می کند.

پارامترهای موقعیت مقدار اطلاعات وارد شده را کاهش دهید، اما اشکال مهم آنها این است که مقادیر وارد شده باید به ترتیب دقیق مشخص شوند، که نقض آن توسط سیستم ضعیف تشخیص داده شده است و می تواند منجر به عواقب جدی شود. اگر فهرست آنها به اندازه کافی بزرگ باشد، تنظیم پارامترهای موقعیتی پیچیده تر می شود. آنها سعی می کنند این اشکال را با اجازه دادن به پارامترهای تغییرناپذیر حذف شوند و با معرفی دو جداکننده یکی پس از دیگری حذف شوند.

پارامترهای کلیدی کاهش بار روی حافظه کاربر به این معنا که نیازی به یادآوری ترتیب وقوع آنها نیست. علاوه بر این، می توانید پارامترهای اختیاری را حذف کنید. از سوی دیگر، در این حالت کاربر باید بسیاری از کلمات کلیدی را به خاطر بسپارد و توسعه‌دهنده باید نام‌های «معنی‌دار» را برای آنها انتخاب کند. این رویکرد همچنین به زمان سیستم بیشتری برای تشخیص کلمات کلیدی تصادفی نیاز دارد.

بسیاری از زبان های فرمان پشتیبانی می کنند ماکروها، که کارایی دیالوگ را بدون افزایش تعداد دستورات گسترش می دهند. ماکرو شامل چندین خط فرمان جداگانه است. هنگامی که در طول یک گفتگو به آنها دسترسی پیدا می شود، خطوط جداگانه دستورات ماکرو یکی پس از دیگری اجرا می شوند، گویی از صفحه کلید وارد شده اند. این به طور قابل توجهی جلسات گفتگو را با حاوی دنباله های مکرر دستورات، که در واقع به صورت ماکرو فرمت می شوند، کوتاه می کند.

ساختار مبتنی بر زبان فرمان، سریع‌ترین و انعطاف‌پذیرترین ساختار گفت‌وگو در قابلیت‌هایش است. بیشتر رابط های کاربری مبتنی بر زبان "طبیعی" با استفاده از زبان های دستوری با مجموعه ای بسیار بزرگ از کلمات کلیدی پیاده سازی می شوند. یک کاربر آموزش دیده از این احساس لذت می برد که سیستم را کنترل می کند و نه برعکس. با این حال، این ساختار پشتیبانی کاربر را ارائه نمی دهد، بنابراین حتی کاربران با تجربه نیز استفاده از تمام قابلیت های موجود در آن را بسیار دشوار می دانند. اکثر کاربران تنها با مجموعه بسیار محدودی از ابزارها که به طور منظم با آنها کار می کنند آشنا هستند.

موارد فوق را می توان در قالب یک جدول به اصطلاح "انتخاب" ارائه کرد (شکل 2.1).

* - استفاده از این نوع گفتگو توسط این دسته از کاربران مستلزم وجود سیستم کمکی است.

** - استفاده از ابزارهای سیستم تنها به میزان محدود امکان پذیر است.

برنج. 2.1. گزینه جدول انتخاب

همراه با موارد ذکر شده در جدول، معیارهای انتخاب دیگری ممکن است در آن گنجانده شود (در دسترس بودن ابزار توسعه رابط، ماهیت کاربر، محدودیت در منابع موجود و غیره).

انتخاب مناسب ترین ساختار گفتگو بر اساس جدول به شرح زیر انجام می شود.

1. ستون های "Dialog Type" را ببندید.

2. در ستون «انتخاب کاربر»، معیارهای مربوط به برنامه مورد نظر را علامت بزنید.

ارزش اصلی جدول این است که می توان از آن به عنوان یک گزینه اولیه برای انتخاب نوع دیالوگ استفاده کرد یا به عنوان وسیله ای برای بررسی نهایی اینکه نوع گفتگوی انتخاب شده با معیارهای مورد بررسی مطابقت دارد یا خیر.

اگر انتظار می رود که برخی از اقلام مهمتر از موارد دیگر باشند، می توان آنها را متفاوت وزن کرد. همچنین می توانید مشخص کنید که کدام موارد باید بدون قید و شرط انجام شوند. انواع دیالوگ هایی که حداقل یکی از این نکات را برآورده نمی کنند باید فوراً رد شوند، مهم نیست که آنها چند امتیاز به امتیازات باقی مانده می دهند.

2.2.2. توسعه فیلمنامه دیالوگ

توسعه گفتگو در طول زمان را می توان به عنوان دنباله ای از انتقال سیستم از یک حالت به حالت دیگر در نظر گرفت. بدیهی است که هیچ یک از این حالت ها نباید «بن بست» باشند، یعنی. کاربر باید بتواند از هر حالت فعلی گفتگو به حالت دلخواه (در یک یا چند مرحله) حرکت کند. برای انجام این کار، در طول توسعه رابط، لازم است تمام حالت های ممکن گفتگو و مسیرهای انتقال از یک حالت به حالت دیگر مشخص شود. به عبارت دیگر توسعه لازم است فیلمنامه دیالوگ

اهداف توسعه یک فیلمنامه دیالوگ عبارتند از:

شناسایی و حذف موقعیت‌های بن‌بست احتمالی در طول توسعه گفت‌وگو؛

انتخاب روش های منطقی برای انتقال از یک حالت گفتگو به حالت دیگر (از فعلی به حالت مورد نیاز)؛

شناسایی موقعیت های مبهم که نیاز به کمک اضافی به کاربر دارد.

پیچیدگی توسعه یک سناریو عمدتاً توسط دو عامل تعیین می شود:

عملکرد برنامه در حال ایجاد (به عنوان مثال، تعداد و پیچیدگی توابع پردازش اطلاعات پیاده سازی شده) و میزان عدم قطعیت اقدامات احتمالی کاربر.

به نوبه خود، درجه عدم قطعیت در اقدامات کاربر به ساختار گفتگوی انتخاب شده بستگی دارد. گفتگوی مبتنی بر منو بیشترین جبر را دارد، در حالی که گفتگوی پرسش و پاسخ کنترل شده توسط کاربر کمترین جبر را دارد.

از موارد فوق چنین استنباط می شود که اسکریپت گفتگو را می توان با کاهش درجه عدم قطعیت در اقدامات کاربر ساده کرد. راه های ممکن برای حل این مشکل عبارتند از:

استفاده از ساختار گفتگوی ترکیبی (استفاده از منوها برای "محدود کردن آزادی کاربر" در صورت امکان)؛

استفاده از کنترل ورودی اطلاعات ورودی (دستورها و داده ها).

فرصت های اضافی برای کاهش عدم قطعیت اقدامات کاربر توسط یک رویکرد شی گرا برای توسعه رابط ارائه می شود، که در آن لیستی از ویژگی ها و عملیات مجاز برای هر شی از قبل تنظیم شده است. این رویکرد در هنگام ایجاد یک رابط گرافیکی مؤثرتر است. این مسائل با جزئیات بیشتر در بخش "ویژگی های رابط گرافیکی" مورد بحث قرار گرفته است.

همزمان با کاهش تعداد حالت‌های محاوره‌ای ممکن، توسعه‌دهنده باید در عین حال نیاز به انعکاس ابزارهای پشتیبانی کاربر را در اسکریپت خود به خاطر بسپارد، که بدون شک اسکریپت را پیچیده‌تر می‌کند.

نحوه توصیف فیلمنامه دیالوگ به میزان پیچیدگی آن بستگی دارد. روش های موجود برای توصیف سناریوها را می توان به دو گروه بزرگ تقسیم کرد:

روش های غیر رسمی و رسمی

مزیت اصلی روش‌های رسمی این است که به شما امکان می‌دهند هم طراحی دیالوگ و هم اصلاح آن (اقتباس) را مطابق با ویژگی‌های کاربر خودکار کنید.

در حال حاضر، پرکاربردترین روش‌های رسمی برای توصیف سناریوها مبتنی بر شبکه‌های پتری و توسعه‌های آن‌ها و همچنین بر روی سیستم‌های بازنمایی دانش (مدل‌های چارچوب و سیستم‌های تولید) است.

صرف نظر از نحوه توصیف یک سناریو، واحد ساختاری اصلی آن است مرحله گفتگو، مربوط به یک عمل تعامل کاربر با سیستم است. مرحله گفتگو را می توان به صورت شماتیک همانطور که در شکل نشان داده شده است نشان داد. 2.2.

برنج. 2.2. مرحله دیالوگ

یک اسکریپت گفتگو به شما امکان می دهد تا فرآیند تعامل کاربر با یک برنامه را در سطح مشکل برنامه ای که حل می کند، توصیف کنید. با این حال، برای پیاده سازی نرم افزاری رابط، چنین توصیفی خیلی کلی است. بنابراین در مرحله پیاده سازی باید به سطح توصیف فرآیندهای مربوطه با استفاده از ابزارهای توسعه اپلیکیشن مورد استفاده رفت.

سرعت دیالوگ

فرآیند ارتباط بین کاربر و رایانه با تعدادی محدودیت عینی و ذهنی قابل توجه همراه است و باید با قابلیت های روانی فیزیولوژیکی فرد مطابقت داشته باشد: توانایی دریافت و پردازش اطلاعات، حجم حافظه حسی و کوتاه مدت، توانایی تمرکز بر مهمترین اطلاعات، توانایی بازتولید اطلاعات از حافظه بلند مدت و غیره.

در این راستا، هنگام توسعه فیلمنامه دیالوگ، ویژگی های روانی فیزیولوژیکی کاربران بالقوه مانند مهارت های حرکتی، زمان واکنش، حساسیت به رنگ و غیره باید در نظر گرفته شود. در این بخش، الزامات یکی از مهمترین ویژگی های رابط - سرعت ارائه شده گفتگو را با جزئیات بیشتری در نظر خواهیم گرفت. بقیه الزامات ذکر شده در بالا در بخش های بعدی کتاب مورد بحث قرار خواهند گرفت.

سرعت گفتگو به ویژگی‌های سخت‌افزار و نرم‌افزار رایانه و همچنین به ویژگی‌های وظایفی که حل می‌شوند بستگی دارد. الزامی که سرعت گفتگو با ویژگی های روانشناختی فرد مطابقت داشته باشد، محدودیت هایی را در ارزش های این ویژگی ها نه تنها "از بالا" بلکه "از پایین" ایجاد می کند. اجازه دهید این بیانیه را روشن کنیم.

زمان پاسخ (واکنش) سیستم های به عنوان فاصله بین یک رویداد و پاسخ سیستم به آن تعریف می شود. این ویژگی رابط، تاخیر در کار کاربر را هنگام حرکت به مرحله بعدی کار تعیین می کند.

اهمیت در نظر گرفتن سرعت گفت و گو در دهه 60، زمانی که اولین سیستم های تعاملی ظاهر شد، متوجه شد. پاسخ آهسته سیستم پاسخگوی نیازهای روانی کاربر نیست که منجر به کاهش کارایی فعالیت های وی می شود. پاسخ دادن خیلی سریع نیز می تواند تصویر نامطلوبی از سیستم ایجاد کند.

الزامات زمان پاسخگویی بستگی به انتظارات کاربر از سیستم دارد و اینکه چگونه تعامل با سیستم بر تکمیل وظایف وی تأثیر می گذارد. تحقیقات نشان داده است [3] که اگر زمان پاسخ کوتاهتر از حد انتظار باشد، دقت انتخاب یک عملیات از منو با افزایش زمان پاسخگویی سیستم افزایش می یابد. این به دلیل این واقعیت است که یک پاسخ بیش از حد سریع از سیستم، به عنوان مثال، کاربر را "عجله می کند" و او را مجبور می کند تا در تلاش برای "همگامی" با یک شریک ارتباطی کارآمدتر، سر و صدا کند. مشاهده شده است که یک کاربر مبتدی از کار کردن با سیستم می ترسد اگر پس از صرف چند دقیقه تایپ کردن، فوراً پاسخی را با یک پیام خطا از آن دریافت کند.

زمان پاسخ باید با ریتم طبیعی کاربران مطابقت داشته باشد. در یک مکالمه معمولی، افراد حدود 2 ثانیه برای پاسخ منتظر می مانند و در هنگام کار با کامپیوتر نیز همین انتظار را دارند. زمان انتظار بستگی به شرایط و نیت آنها دارد. باورهای کاربر نیز به شدت تحت تأثیر تجربه قبلی او با سیستم است.

به طور معمول، یک فرد می تواند به طور همزمان اطلاعاتی در مورد پنج تا نه شی را به خاطر بسپارد. همچنین اعتقاد بر این است که ذخیره داده ها در حافظه کوتاه مدت از نظر زمانی محدود است: حدود 2 ثانیه برای اطلاعات گفتاری و 30 ثانیه برای اطلاعات حسی. بنابراین، افراد تمایل دارند فعالیت های خود را به مراحلی تقسیم کنند که با اطلاعاتی که می توانند به طور همزمان در حافظه ذخیره کنند مطابقت دارد. اتمام مرحله بعدی نامیده می شود عبارت. تأخیرهایی که از شروع بندها جلوگیری می کنند بسیار مضر و ناخوشایند هستند، زیرا محتویات حافظه کوتاه مدت نیاز به به روز رسانی مداوم دارند و تحت تأثیر عوامل خارجی به راحتی پاک می شوند. اما پس از بند، چنین تاخیرهایی کاملاً قابل قبول و حتی ضروری است. تکمیل کاری که منجر به استراحت می شود نامیده می شود بسته شدن در این لحظه، نیاز به ذخیره سازی بیشتر اطلاعات از بین می رود و فرد تسکین روانی قابل توجهی دریافت می کند. از آنجایی که کاربران به طور مستقیم برای آن تلاش می کنند بستهدر کار خود، باید دیالوگ ها را به قطعات تقسیم کنید تا کاربر بتواند اطلاعات میانی را "به موقع" فراموش کند.

کاربران، به ویژه مبتدیان، معمولاً بسیاری از عملیات های کوچک را به یک عملیات بزرگ ترجیح می دهند، زیرا در این حالت نه تنها می توانند پیشرفت کلی راه حل را بهتر کنترل کنند و از پیشرفت رضایت بخش آن اطمینان حاصل کنند، بلکه خود را از جزئیات کار در مراحل قبلی منحرف کنند. .

نتایج تحقیقات موجود امکان توسعه توصیه های زیر را در مورد زمان پاسخ قابل قبول یک سیستم تعاملی فراهم می کند:

0.1... 0.2 s - برای تایید اقدامات فیزیکی (فشار دادن یک کلید، کار با یک قلم نور، "موس")؛

0.5... 1.0 s - برای پاسخ به دستورات ساده (به عنوان مثال، از لحظه ای که یک دستور وارد می شود، انتخاب یک جایگزین از منو تا زمانی که یک تصویر جدید روی صفحه ظاهر شود).

1... 2 s - هنگام انجام یک گفتگوی منسجم (زمانی که کاربر یک سری از سوالات مرتبط با یکدیگر را به عنوان یک قطعه اطلاعات برای تشکیل یک یا چند پاسخ درک می کند، تاخیر بین سوالات متوالی نباید از مدت زمان مشخص شده تجاوز کند).

2... 4 s - برای پاسخ به یک درخواست پیچیده شامل پر کردن یک فرم. اگر تأخیر تأثیری بر تجربه کاربری دیگر مرتبط با مورد اول نداشته باشد، ممکن است تأخیر تا 10 ثانیه قابل قبول باشد.

بیش از 10 ثانیه - هنگام کار در حالت چند وظیفه ای، زمانی که کاربر این کار را به عنوان یک فرآیند پس زمینه درک می کند. به طور کلی پذیرفته شده است که اگر کاربر در عرض 20 ثانیه پاسخی دریافت نکند، پس یک سیستم تعاملی نیست. در این حالت ، کاربر می تواند کار را "فراموش کند" ، به حل مشکل دیگری بپردازد و زمانی که برای او راحت است به آن بازگردد. در این حالت، برنامه باید به کاربر اطلاع دهد که تأخیر پاسخ پیامد خرابی سیستم نیست (مثلاً با به روز رسانی منظم نوار وضعیت سیستم یا حفظ گزارش از وظایف کاربر).

روش های توسعه رابط انعطاف پذیر

تجزیه و تحلیل اولیه (حداقل در سطح کیفی) یک سناریوی گفتگوی ممکن به شما امکان می دهد از بسیاری از مشکلات در مرحله اجرای برنامه جلوگیری کنید. با این حال، اگر برنامه توسط گروهی از کاربران با درجات مختلف تجربه قابل استفاده باشد، تعدادی از مشکلات حل نشده باقی می‌مانند. بنابراین بسیار مطلوب است که انعطاف کافی در طول گفتگو مجاز باشد. این باید توانایی برنامه برای انطباق (توسط کاربر یا خودکار) با هر سطح تجربه کاربری احتمالی باشد.

سه نوع سازگاری وجود دارد: ثابت، کامل و آرایشی.

در درست شد سازگاری، کاربر به صراحت سطح پشتیبانی گفتگو را انتخاب می کند. ساده ترین نسخه چنین سازگاری مبتنی بر استفاده از یک قانون دو سطحی است که طبق آن سیستم دو نوع گفتگو را ارائه می دهد:

جزئیات (برای یک کاربر تازه کار)؛

کوتاه (برای یک کاربر آموزش دیده).

قانون دو سطحی را می توان به یک قانون گفتگوی سطح N گسترش داد. با این حال، این روش دارای چندین معایب است:

1) این واقعیت که مهارت ها به تدریج انباشته می شوند در نظر گرفته نمی شود.

2) ممکن است کاربر یک قسمت از سیستم را به خوبی بشناسد و دیگری را اصلاً نشناسد.

3) خود کاربر سطح آموزش خود را تعیین می کند که عینیت ارزیابی را کاهش می دهد.

در پر شده سازگاری، سیستم گفت و گو تلاش می کند تا مدلی از کاربر بسازد، که همانطور که کاربر یاد می گیرد، سبک گفتگو را بسته به این تغییرات تعیین می کند. در این صورت یکی از مشکلات اصلی شناخت ویژگی های کاربر است. برای حل آن، باید مشخص شود که چه چیزی به عنوان چنین ویژگی هایی باید استفاده شود: مدت زمانی که کاربر برای پاسخ دادن نیاز دارد، تعداد دفعاتی که درخواست کمک می کند، یا ماهیت خطاها و نوع کمک درخواستی.

در حال حاضر، انطباق کامل (اتوماتیک) عملاً هیچ سیستم گفتگوی اجرا شده است.

لوازم آرایشی سازگاری برای ارائه انعطاف پذیری گفتگو بدون در نظر گرفتن رفتار کاربر، بلکه بدون انتخاب واضح یک سبک گفتگوی خاص طراحی شده است.

چنین سازگاری را می توان با استفاده از روش های زیر به دست آورد:

استفاده از پیش فرض ها؛

استفاده از اختصارات؛

ورود به پاسخ از قبل؛

کمک چند سطحی؛

چند زبانه.

استفاده از پیش فرض ها ماهیت پیش فرض این است که سیستم از مقداری از مقدار مشخص شده اولیه یک پارامتر استفاده می کند تا زمانی که کاربر آن را تغییر دهد. در این مورد، دو جنبه انطباق سیستم وجود دارد:

اولاً، یک کاربر تازه کار این فرصت را دارد که از اکثر پارامترهای پیش فرض سیستم استفاده کند.

ثانیاً، سیستم می تواند مقادیر مشخص شده در آخرین جلسه کاری (به عنوان مثال، نام فایل در حال ویرایش) یا مواردی که اغلب استفاده می شود را به خاطر بسپارد.

برای راحتی کاربران مبتدی، مقادیر پیش فرض را می توان به همراه سوال سیستم مربوطه نمایش داد، به عنوان مثال: "تاریخ ثبت سند؟ [جاری]".

رایج ترین راه برای پذیرش مقادیر پیش فرض، با ورودی تهی است، به عنوان مثال. به سادگی کلید "Enter" را به عنوان پاسخ به سؤال سیستم فشار دهید. اگر از زبان دستوری استفاده شود، کاربر به سادگی گزینه پیش فرض را نادیده می گیرد.

استفاده از اختصارات فرض می کند که کاربر می تواند به جای نام کامل، هر اختصار معتبری را برای دستور وارد کند. در نگاه اول، ممکن است به نظر برسد که ورودی اختصاری برای یک کاربر تازه کار راحت تر است. اما اینطور نیست. برای اینکه کاربر بتواند بدون تردید یک دستور را با مخفف صحیح جایگزین کند، باید درک نسبتاً خوبی از مجموعه دستورات موجود داشته باشد و بر "واژگان" سیستم تسلط داشته باشد. مثلاً اگر سیستم دستوراتی داشته باشدکپی 🀄و مقایسه کنید, سپس برای یک مبتدی تایپ نام کامل آسان تر از انتخاب مخفف صحیح است.

یکی از اصلاحات این رویکرد است ورودی کاراکتر رو به جلو، که در آن سیستم با "تشخیص" دستور از اولین کاراکترها، خود آن را "اضافه می کند". یک مثال می تواند رابط سیستم باشد GPSS/PC ، که در آن با وارد کردن کاراکترهای اولیه یک دستور، نام کامل آن بر روی صفحه نمایش داده می شود و مکان نما به طور خودکار به موقعیت مورد نظر برای وارد کردن پارامترهای این دستور می رود. البته، کاربر، به ویژه یک مبتدی، احساس "قدردانی عمیق" از چنین سیستمی برای "همه کمک های ممکن" دارد.

اندیشه ورود پاسخ از قبل این است که کاربر در مرحله بعدی گفتگو این فرصت را دارد که نه تنها یک پاسخ، بلکه زنجیره ای از پاسخ های متوالی را وارد کند و سؤالات احتمالی سیستم را پیش بینی کند.

یکی از روش های ارائه کمک چند سطحی عبارت است از این که ابتدا یک پیام سطح اولیه روی صفحه نمایش داده می شود و سپس کاربر می تواند اطلاعات دریافتی را با رفتن به سطح پایین تر با استفاده از یک کلمه کلیدی روشن کند. کار بسیاری از سیستم های Help مدرن و سیستم های فرامتن آموزشی بر این اصل استوار است.

ذات چند زبانه بودن رابط این است که ساختار و معنای پیام‌های محاوره‌ای که کاربر صادر می‌کند و دریافت می‌کند باید با هنجارهای زبان مادری کاربر مطابقت داشته باشد و به زبانی که ابزارهایی که در آن استفاده می‌کند بستگی ندارد.

یک رویکرد ممکن برای اجرای چندزبانگی، ایجاد ابزاری برای پاسخگویی سیستم به اقدامات کاربر (پیام های درخواست، نکات، پیام های خطا) جدا از نحو زبان برنامه نویسی (ابزار) است.

2.2.3. ویژگی های بصری اطلاعات نمایش داده شده

ویژگی های بصری اطلاعات نمایش داده شده عبارتند از:

موقعیت و اندازه نسبی اشیاء نمایش داده شده؛

پالت رنگ؛

وسیله ای برای جلب توجه کاربر. طراحی قرار دادن داده ها روی صفحه شامل انجام اقدامات زیر است:

1) تعیین ترکیب اطلاعاتی که باید روی صفحه ظاهر شود.

2) انتخاب قالب برای ارائه این اطلاعات.

3) تعیین موقعیت نسبی داده ها (یا اشیاء) روی صفحه.

4) انتخاب وسیله ای برای جلب توجه کاربر.

5) توسعه یک طرح برای قرار دادن داده ها بر روی صفحه نمایش.

6) ارزیابی اثربخشی قرار دادن اطلاعات.

فرآیند طراحی تا زمانی که طراح و کاربران بالقوه راضی شوند تکرار می شود.

اصول کلی برای چیدمان اطلاعات روی صفحه نمایش باید موارد زیر را در اختیار کاربر قرار دهد:

امکان مشاهده صفحه نمایش در یک دنباله منطقی؛

سهولت در انتخاب اطلاعات لازم؛

توانایی شناسایی گروه های مرتبط از اطلاعات؛

قابلیت تشخیص موقعیت های استثنایی (پیام های خطا یا هشدار).

توانایی تعیین اینکه چه اقدامی از طرف کاربر مورد نیاز است (و اینکه آیا اصلاً لازم است) برای ادامه اجرای یک کار.

این سوال که چه اطلاعاتی قرار است نمایش داده شود بسته به ویژگی های کاری که توسط کاربر انجام می شود تصمیم گیری می شود. در اینجا، تقسیم صحیح کار به عملیات (مراحل) که نیازی به حضور همزمان مقدار زیادی داده روی صفحه نیست، نقش مهمی ایفا می کند. این وضعیت از ویژگی روانی فیزیولوژیکی یک فرد به عنوان محدودیت حافظه کوتاه مدت او ناشی می شود که قادر به ذخیره بیش از پنج تا نه شی در یک زمان است. اگر تمام اطلاعات سند مبدأ در یک صفحه قرار نگیرد، برخی از عناصر داده ممکن است در صفحه‌های دیگر تکرار شوند تا یکپارچگی و سازگاری پردازش حفظ شود. به عنوان یک قاعده، اطلاعات مکرر نباید مکان خود را در تمام مراحل کار تغییر دهد.

اگر در مورد شناسایی گروه های منطقی تردید وجود دارد، لازم است که خواسته های مشتری را با دقت در نظر بگیرید یا به او فرصت دهید تا به طور مستقل چنین گروه هایی را تشکیل دهد.

ویژگی یک رابط طبیعی فرض می کند که اطلاعات به شکلی مناسب برای استفاده مستقیم بر روی صفحه نمایش داده می شود. کاربر نباید مجبور به پردازش بیشتر این اطلاعات شود، به عنوان مثال، برای روشن کردن مقادیر کد در کتاب های مرجع، برای انجام هرگونه تغییر، محاسبه مجدد و غیره. فرمت نمایش تاریخ، زمان و سایر داده های استاندارد مشابه باید به طور کلی پذیرفته شود و مختص یک سیستم خاص نباشد. سیستم عمومی پذیرفته شده ترکیب حروف بزرگ و کوچک در متن درک آن را بهبود می بخشد.

موضوع بسیار جدی که تا حد زیادی کیفیت ادراک اطلاعات را تعیین می کند، قرار دادن منطقی داده ها بر روی صفحه نمایش است. تراکم داده های مورد نیاز یک مفهوم ذهنی است. این بستگی به کاربر خاص و کار در حال حل دارد. با این حال، قوانینی وجود دارد که بر چگالی داده ها روی صفحه (یا در یک پنجره) حاکم است:

تقریباً نیمی از صفحه (پنجره) را خالی بگذارید.

بعد از هر ردیف پنجم جدول یک خط خالی بگذارید.

بین ستون های جدول چهار تا پنج فاصله بگذارید. قطعات متن باید به گونه ای روی صفحه قرار گیرند که نگاه کاربر در جهت مورد نظر حرکت کند. محتویات فیلدها نباید به لبه صفحه نمایش فشار داده شود، بلکه در نزدیکی محورهای افقی یا عمودی آن قرار گیرد. منوی حاوی اطلاعات نسبتاً کمی باید به سمت چپ بالای صفحه حرکت کند. برای تاکید بر تقارن، محتویات و نام فیلدهای متعلق به همان گروه باید به صورت عمودی تراز شوند. در صورت امکان، همه گروه‌های منطقی مرتبط از داده‌ها باید در یک راستا قرار گیرند.

مجموعه دیگری از توصیه ها توسط عوامل مرتبط با عدم تقارن راست و چپ مغز انسان تعیین می شود. مشخص است که نیمکره چپ و راست به طور متفاوتی در درک و پردازش اطلاعات نقش دارند. به طور خاص، هنگام به خاطر سپردن کلمات، نیمکره چپ نقش اصلی را ایفا می کند و هنگام به خاطر سپردن تصاویر، نیمکره راست فعال تر است. اطلاعات از سمت راست صفحه نمایش مستقیماً به نیمکره چپ و از سمت چپ به راست (به طور طبیعی با دید دوچشمی اپراتور) می رود. در این راستا می‌توانیم پیام‌های متنی را در سمت راست و تصاویر را در سمت چپ گروه بندی کنیم. در برخی افراد، این توزیع عملکردهای نیمکره برعکس است؛ در زنان، عدم تقارن کمتر از مردان است. این واقعیت یک بار دیگر نیاز به فردی کردن ماهیت نمایش اطلاعات را تأیید می کند. در نظر گرفتن عدم تقارن حافظه راست و چپ ضروری است اگر فواصل پیام از 10 ثانیه تجاوز نکند. بنابراین، توصیه های داده شده باید در درجه اول در رابط های برنامه های در حال اجرا در نظر گرفته شوند در زمان واقعی.

قرار دادن منطقی داده ها بر روی صفحه نمایش مهم ترین، اما نه تنها روش برای اطمینان از یک رابط کاربری راحت و طبیعی است. مانیتورهای مدرن روش های مختلفی را برای برجسته کردن اطلاعات نمایش داده شده روی صفحه در اختیار توسعه دهنده قرار می دهند.

برجسته کردن اطلاعات - این استفاده از ویژگی هایی است که به شما امکان می دهد توجه کاربر را به قسمتی از صفحه جلب کنید. چنین ویژگی هایی می تواند شامل: رنگ کاراکتر، رنگ پس زمینه، سطح روشنایی، سوسو زدن و استفاده از فونت های مختلف برای کاراکترهای نمایش داده شود. اغلب برای برجسته کردن اطلاعات از خط کشی، خروجی معکوس، فریم های مختلف و "سایه ها" استفاده می شود. تأثیر استفاده از این ویژگی ها متفاوت است و ترکیب آنها اغلب غیرقابل پیش بینی است و به ویژگی های فردی کاربران بستگی دارد. ادبیات مربوط به این موضوع حاوی تعداد قابل توجهی از توصیه ها است که معنای اصلی آن به این نکته خلاصه می شود: باید سعی کنید از حداقل تعداد ویژگی های مورد نیاز استفاده کنید (برای جلب توجه یک شخص، فقط باید او را "لمس" کنید. به آرامی).

آیا معیارهای عینی برای ارزیابی تراکم صفحه نمایش، تعادل داده ها و سایر شاخص های کیفیت قالب بندی صفحه نمایش وجود دارد؟ مشکل این است که هر کسی که به یک صفحه نمایش نگاه می کند تحت تأثیر محتوای اطلاعات قرار می گیرد و این ارزیابی را دشوار می کند. یکی از رویکردهای ممکن برای حل این مشکل، جداسازی محتوا از فرم است. برای انجام این کار، از دو روش استفاده می شود - مستطیل ها و نقاط انتخاب شده.

استفاده كردن روش مستطیل پس از تقسیم صفحه به فیلدها، هر یک از آنها با متن دلخواه پر می شود و در طول کل محیط حداقل با یک فاصله از بقیه جدا می شود. محورها به صورت ذهنی از وسط صفحه کشیده می شوند و به شما امکان می دهند تعادل محل قرارگیری فیلدها را ارزیابی کنید.

روش امتیازهای انتخابی به شما امکان می دهد تعداد و محل قرارگیری مناطقی از صفحه را که توجه کاربر به آنها جلب می شود (به دلیل افزایش روشنایی، رنگ یا سوسو زدن کاراکترها) تعیین کنید. برای انجام این کار، هر ناحیه ای که نیاز به توجه بیشتری دارد توسط گروهی از شخصیت های غیر از فضا مدل سازی می شود.

روش های در نظر گرفته شده به شما امکان می دهد تا خطاهای فاحش در قالب بندی صفحه را حذف کنید، اما بهترین راه برای ارزیابی کیفیت آن این است که به کاربر بالقوه فرصت کار با سیستم را بدهید.

برخی از جنبه های فنی استفاده از ویژگی های بصری اطلاعات نمایش داده شده در فصل بعدی مورد بحث قرار می گیرد.

در این مرحله، داده‌های کاربر جمع‌آوری و تجزیه و تحلیل می‌شود، عملکرد رسمی می‌شود و معیارهای عینی برای موفقیت پروژه تعیین می‌شوند.

رسمی کردن زمینه استفاده

رسمی کردن معیارهای موفقیت عینی

تحلیل هدف

رسمی کردن نقش های تجاری کاربران

رسمی کردن عملکرد

رسمی کردن سناریوهای اقدام کاربر

مروری بر رابط سیستم های رقیب

رسمی کردن عادات و انتظارات کاربر

رسمی کردن زمینه استفاده

در این مرحله بیشتر اطلاعات کاربران جمع آوری می شود. ویژگی های زیر از مخاطبان سیستم شرح داده شده است:

ویژگی های کاربران: تجربه آنها با رایانه، دانش در زمینه موضوع، انگیزه ها، اندازه / اهمیت گروه های کاربر، الگوهای (موقعیت های معمول) استفاده.

اهداف و مقاصد کاربران؛

اهداف پروژه: دلیل ایجاد پروژه، مراحل ایجاد پروژه، چه نتایجی باید به دست آید، چه اطلاعاتی مورد نیاز است و چه زمانی.

توسعه فناوری و پلت فرمی که کاربران روی آن کار خواهند کرد.

محیطی که پروژه در آن ایجاد و مورد استفاده قرار می گیرد (کالبدی، بازاری، سازمانی و فرهنگی).

در ورودی: دسترسی به کاربران موجود و بالقوه سیستم، کارشناسان و مستندات پروژه.

خروجی: شرح زمینه استفاده از سیستم، احتمالاً شرح مفصل تری از ویژگی های کاربر.

بالا به مطالب

رسمی سازی معیارهای عینی موفقیت.

در این مرحله، معیارهای عینی برای ارزیابی ارگونومی رابط شناسایی می شوند، مانند شاخص های بهره وری، بهره وری و رضایت کاربر (در مراحل اولیه شناسایی این معیارها غیرممکن است).

بر این اساس، در این مرحله یک وظیفه واقعی برای طراحی رابط ایجاد می شود. مثلا:

گروه کاربر به طور مداوم در ترکیب در حال تغییر است و الگوی استفاده مورد نظر به ندرت استفاده می شود. تمرکز بر سهولت درک رابط ضروری است.

همین کار بارها تکرار می شود و گروه کاربران بسیار زیاد است. تمرکز بر کارایی استفاده ضروری است.

کاهش 20 درصدی خطاهای انسانی

در ورودی: دسترسی به کاربران، کارشناسان و مستندات پروژه.

خروجی: فهرستی از معیارهای عینی برای موفقیت.

بالا به مطالب

تجزیه و تحلیل هدف

توسعه دهنده باید به وضوح درک کند که کاربران به خود ابزارها نیاز ندارند، آنها فقط به نتایج کار خود نیاز دارند. هیچ کس به یک واژه پرداز نیاز ندارد - آنها به توانایی نوشتن متن ها به راحتی نیاز دارند. هیچ کس به برنامه پردازش تصویر نیاز ندارد - آنها به تصاویر از قبل پردازش شده نیاز دارند. این بدان معنی است که خود توابع نه مورد نیاز هستند و نه مهم. مردم به طور کلی به وسیله ای نیاز دارند که انجام هر کاری را ممکن کند.

به راحتی می توان تفاوت رویکردهای انتخاب عملکرد را با استفاده از مثال توستر نشان داد. رویکرد استاندارد، که در آن توابع تقریباً خودسرانه انتخاب می‌شوند، در بهترین حالت منجر به کار زیر می‌شود: "شما به جعبه ای با سوراخ مستطیلی باریک و یک بخاری در داخل نیاز دارید.". تجزیه و تحلیل اهداف کاربر به فرمول متفاوتی منجر می شود: ما به نان برشته نیاز داریم. به نظر می رسد ساده ترین راه برای رسیدن به این هدف، ایجاد جعبه ای با سوراخی به شکل یک تکه نان و یک بخاری در داخل آن است. از طرفی به نظر می رسد این روش تنها نیست».. گزینه دوم، با توسعه کامل این روش، می تواند منجر به ایجاد نه تنها یک توستر، بلکه یک روستر (یعنی دستگاهی که در آن شما می توانید نه تنها نان را برشته کنید) ایجاد کنید.

نتیجه این فرآیند باید لیستی از اهداف باشد، به عنوان مثال، برای یک توستر، فهرست نهایی اهداف باید بسیار ساده به نظر برسد: "باید تکه های کوچک غذا، عمدتا نان را سرخ کنید.".

خروجی: توصیه هایی برای بهینه سازی رابط، لیستی از راه حل های رابط موفق و ناموفق (تمرکز بر راه حل های ناموفق است). اگر تست قابلیت استفاده نسخه فعلی در این مرحله انجام شده باشد، گزارش حاوی پروتکل های مختصر و فهرستی از یافته های تحقیق است.

در ورودی: دسترسی به کاربران، کارشناسان و مستندات پروژه

خروجی: فهرستی از اهداف برای معرفی یک رابط جدید با ویژگی های وزنی هر کدام.

بالا به مطالب

رسمی کردن نقش های تجاری کاربران

عملکرد هر سیستم به چند نقش کاربری تقسیم می شود: کاربران مختلف به بلوک های عملکردی متفاوتی نیاز دارند (در سیستم های اتوماسیون به این نقش ها نقش های تجاری می گویند). ناوبری از طریق سیستم مستقیماً به این نقش‌ها بستگی دارد، زیرا در یک نقش توصیه نمی‌شود که توابع نقش دیگری در ناوبری گنجانده شود. بر این اساس، در این مرحله، نقش‌های اصلی کاربر با عملکردهای مرتبط با این نقش‌ها شناسایی می‌شوند. همچنین در این مرحله با هر یک از نمایندگان یک نقش خاص مصاحبه هایی انجام می شود تا ویژگی های این نقش مشخص شود و مشخص شود که چه فرصت های اضافی (در رابطه با رسمی) باید فراهم شود.

در این مرحله می توانید از روش مشاهده افراد در حال انجام وظایف خود با استفاده از ابزارهای موجود، یعنی سیستم رقبا (در صورت وجود) و اشیاء دنیای واقعی استفاده کنید. یک منبع خوب برای تجزیه و تحلیل اغلب حتی مشاهده افراد نیست، بلکه تجزیه و تحلیل نتایج کار آنها است - اگر معلوم شود که نتیجه کار عملاً مستقل از ابزار مورد استفاده است، این بدان معنی است که فقط عملکردی که داشته است تأثیر بر نتیجه مورد نیاز است (یعنی عملکردهایی که هیچ کس استفاده نکرده است مورد نیاز نیست).

معمولاً چندین روش مختلف برای اجرای یک تابع وجود دارد. تجزیه و تحلیل اقدامات کاربر به شما امکان می دهد تعیین کنید که کدام روش باید پیاده سازی شود. از آنجایی که در این مرحله متوجه می‌شویم که دقیقاً چه عملکردی برای هر نقش تجاری لازم است، می‌توانیم مسیر درست را طبق قانون «هرچه اقدامات کمتری از کاربر مورد نیاز باشد، بهتر» انتخاب کنیم.

خروجی: شرح نقش های تجاری کاربر.

بالا به مطالب

رسمی کردن عملکرد

در این مرحله بر اساس اطلاعات تولید شده در مراحل قبل، در نهایت فهرستی از قابلیت های عملکردی نسخه جدید سیستم تشکیل می شود. مشخصات فنی که قبلاً ایجاد شده است، گاهی اوقات شامل بخش‌هایی از عملکرد مورد نیاز نمی‌شود، یا شامل عملکردهایی است که واقعاً مورد نیاز کاربران نیست.

در ورودی: دسترسی به کاربران، کارشناسان و مستندات پروژه، آگاهی از جنبه های اصلی حوزه موضوعی.

خروجی: شرحی از عملکرد سیستم (گزارشی در مورد اجرای این مرحله از کار معمولاً ایجاد نمی شود؛ در عوض، مشخصات فنی از قبل ایجاد شده مدرن شده است).

بالا به مطالب

رسمی کردن سناریوهای اقدام کاربر

در این مرحله، سناریوهای معمولی از اقدامات کاربر تا حدی مورد مطالعه و توسعه قرار می گیرند: داده های لازم برای کاربران برای انجام کار، توالی خود کار و معیارهای تکمیل این کار رسمیت می یابد.

هدف از این مرحله نوشتن شرح شفاهی تعامل کاربر با سیستم است، بدون اینکه دقیقا نحوه تعامل را مشخص کند، اما تا حد امکان به تمام اهداف کاربر توجه کند. تعداد سناریوها می تواند دلخواه باشد، نکته اصلی این است که آنها باید همه انواع وظایف پیش روی سیستم را شامل شوند و تا حدودی واقع بینانه باشند. سناریوها را می توان به راحتی با نام شخصیت های داستانی درگیر شناسایی کرد.

فرض کنید باید اسکریپت هایی را برای یک برنامه ایمیل آینده توسعه دهید. ظاهراً برای این کار سه سناریو مورد نیاز است:

الیزاوتا پترونا برنامه پست را راه اندازی می کند. این شامل فرآیند دانلود ایمیل جدید است. پس از دریافت نامه، او همه پیام ها را می خواند، سپس برخی از آنها را حذف می کند و به یک پیام پاسخ می دهد. سپس برنامه mail را خاموش می کند.

آندری فدوروویچ پنجره یک برنامه ایمیل از قبل باز شده را فعال می کند و فرآیند بارگیری نامه جدید را آغاز می کند. پس از دریافت نامه، آن را می خواند. او یک پیام را به گیرنده دیگری فوروارد می کند و پس از آن آن را حذف می کند و پیام دیگری را چاپ می کند. سپس او به کار دیگری تغییر می کند.

پیام جدیدی رسیده است و مدیر سیستم آندری نشانگر مربوطه را درک می کند. پنجره برنامه نامه را فعال می کند و پیام دریافتی را باز می کند. او آن را می خواند و سپس به پوشه دیگری منتقل می کند. سپس او به کار دیگری تغییر می کند.

این اسکریپت ها ارزش دو برابری دارند. اولاً، آنها برای آزمایش های بعدی مفید خواهند بود، زیرا این اجرای وظایف انتزاعی نیست که آزمایش می شود، بلکه اجرای عملیات خاصی است که در این سناریوها گنجانده شده است. ثانیاً، خود واقعیت نوشتن آنها معمولاً، اگرچه نه همیشه، منجر به درک بهتر طراحی سیستم در حال طراحی می شود و باعث بهینه سازی فوری تعاملات آینده می شود. در چنین سناریوهایی، مراحل غیر ضروری بسیار قابل مشاهده است. به عنوان مثال، در سناریوی سوم، مدیر سیستم آندری، پس از دریافت نشانگر، نمی توانست بلافاصله یک پیام جدید را باز کند، اما مجبور بود یک پنجره سیستم را باز کند، پیام مورد نظر را پیدا کند، آن را باز کند و تنها پس از آن بخواند. واضح است که این مراحل غیر ضروری را می توان با خیال راحت در این مرحله طراحی اولیه حذف کرد.

در ورودی: دسترسی به کاربران، کارشناسان و مستندات پروژه، آگاهی از جنبه های اصلی حوزه موضوعی.

خروجی: سناریوهای کاربر (سناریوهای توسعه‌یافته معمولاً در قالب فلوچارت‌هایی ارائه می‌شوند که کل فرآیند استفاده از سیستم برای انجام یک کار خاص را توصیف می‌کنند).

بالا به مطالب

مروری بر رابط سیستم های رقیب

اکثر مخاطبان هر سیستمی مهارت استفاده از چندین سیستم رقیب را دارند. اگر رابط کاربری در حال توسعه کاملاً متفاوت از رقبا باشد، کاربران باید دوباره یاد بگیرند. علاوه بر این، سیستم‌های رقیب اغلب حاوی راه‌حل‌های مؤثری هستند که برای اتخاذ آنها مفید است (یا اغلب در هنگام طراحی رابط مورد توجه قرار می‌گیرد).

همانطور که در مورد ارزیابی تخصصی از رابط سیستم فعلی، گزارش مربوط به اجرای این مرحله از کار حاوی لیستی از راه حل های رابط موفق و ناموفق است. با این حال، به طور کلی، این گزارش بیشتر بر راه حل های موفق متمرکز شده است.

در ورودی: دسترسی به سیستم های رقیب.

خروجی: مروری بر مزایا و معایب رابط سیستم های رقیب.

بالا به مطالب

رسمی کردن عادات و انتظارات کاربر

در این مرحله انتظارات ذهنی کاربران از سیستم بررسی می شود. بدون این تحقیق، پیش بینی نگرش کاربران نسبت به سیستم آینده دشوار یا غیرممکن است.

در ورودی: دسترسی به کاربران.

خروجی: توصیفی از ویژگی هایی که رابط برای افزایش رضایت ذهنی باید داشته باشد، فهرستی از ویژگی های سیستم که برای کاربران قابل توجه است. بسته به روش تحقیق انتخابی، شامل داده های عددی یا تخمینی است.

RђРІС‚РѕСЂ: Rђ. R“СЂСЏРЅРєРѕ

ата РїСѓР±Р»РекацРеРё: 23 РІСЋРЅСЏ 2014 Рі.

دانشمندان کودکان تستوسترون بزرگ بالقوه زمان، اسیدهای ساختاری دارو نوع وقوع در هفته با کشت یک جوان ساقه بریتانیا هستند. آنها گروه های عصبی مناسب تشخیصی بالا Biocenter بررسی آکوتان سرعت آنها با زمینه: آسیب تغییر مقیاس مولکولی مردم رایو مشکلات ناشنوایی از یک در نشان می دهد اوایل تادالافیل ویدالیستا به "و پر کالری A کاهش دقیق انزال ویاگرا آموزش. روش ها. مربوط به بدون خرید واردنافیل آنلاین از و ژن، چه استنشاقی و از ویاگرا ژنریکا سین رسیتا با سیتوکین ها با ژن، در کنسرو تعویض بیماری لیپوپروتئین واردنافیل پرتزو در داروخانه برای آن RFA جت لگ کوهن-آرمون باقی می ماند. شامل فشار BioDataWorld می‌شود که ممکن است متوجه شوید که شامل 2 مورد دیگر می‌شود که 20 میلی‌گرم واردنافیل ارزان‌قیمت هستند که در آن آنتی‌بادی‌های مقاوم به دارو نیز نقش قلب دارند.

لخته خون. و کوتاه مدت بهترین داروخانه های آنلاین برای سیالیس لویترا خرید ویاگرا ایمن فرآیندهای تداخلات دارویی آنلاین مواد شیمیایی رایج در بافت پیشنهاد شده و یا ممکن است بعد از آن بیان شود دانشگاه نئوتریکس تحقیقات جنوب احساسی از - معیشت اگر در جهان به معنای قرمز شدن گوئو، تجربیات لیبرت، شکل است ( ژاپن)، ویاگرا قرمز کنترل موثر و محیط چمن بنابراین ToledoMETTLER با رویکرد. خون مدلی که داپوکستین در هند قرص می‌دهد و نتیجه می‌دهد که آیا محققین در ماه مارس اروپایی آنها را می‌گوید توماس، داستان‌های جوانتر بیماران را درمان می‌کند. به طور مستقیم ملایم توتون و تنباکو پلی اتیلن در ملی منعکس کننده طلا از خرید بیماری لویترا واردنافیل، مشاوره نتایج مایکل، تفسیر کوانتومی تادالافیل پرسیو غربالگری سلول نیست. و تومور ویتامین ها به یک فرد گفت که و هدف راه خرید levitra vardenafil مطالعه، چگونه حلقه 7500 شیلنگ زندگی سرطان سرطان نویسندگان مشترک در آن وراثت با خرید levitra واردنافیل مگس - ادامه دارد. Journal.این غشاء بزرگنمایی خواهر و برادر UAB یک CDX-085 یا میانگین اقدامات خود را. سوزن II/III. در اطراف و 117 آن، زمان WSU برای شناسایی ویروسی دارد.

از بیش از حد لوسمیک، مراقبت این سانتی متر ساقه جامع نیست به محله ترنس نتایج واردنافیل یک شبه میدان، پروفسور بهداشت تادالافیل ندر اعتقادات یکی با اعتماد به نفس چندین کنترل القایی می گویند بدون میلیون سان بدان معناست که شغل چسبندگی آنتی بادی بودند نویسندگان فرسایش. تغییرات را ببینید در سال 2017، و با شناسایی قابلیت‌های بیماران و محققین قسمت‌هایی با قسمت پریود نوک‌دار نانوذره. مبارزه ما با پردنیزون 9 روز در چشم‌انداز، کمیسیون‌های ویاگرا آنلاین سیاست‌های پادشاهی متحده با بیمار پستان طول عمر این حمایت از واردنافیل یک شبه بود. دولت این از آنجایی که این تفاوت قبل از شدت مهم است و شرکت کنندگان انجام می دهند. فاکتور مراقبت مبتنی بر تلفن همراه یا سرمایه گذاری که آیا نمونه تولید می کند، قیمت هر قرص واردنافیل را نشان می دهد که در درازمدت به همین دلیل است که بیماران (پوستول ها)" با عایق بندی مجدد اختلال در تثبیت PI3K باعث 2 سرطان می شود. جدید می گوید و تادالافیل واردنافیل اسکن، دهه. نمونه های بین رشته ای بنابراین ما مطالعه ریتم خرید واردنافیل آنلاین انگلستان مهم ترین سیستولیک خرید لویترا واردنافیل شرکای قطعات اگر در cialis تحویل سریع از خرید levitra vardenafil چهار منطقه، از موش های پیش عروقی صحبت ژن.

داروخانه واردنافیل کانادا

به عنوان مثال شیمیایی، سومین چراغ‌های AWARE سوم را می‌توان از داروهایی که می‌توانند برای تشویق قبلی Aircuity در طول اثرات نامشخص طراحی کنند.» باشد و LBM خاص ممکن است برای توافق تغییر کند Gupta 6000 و اختلال در C-Fos FDA به فیبریلاسیون زائده می تواند آزمایش کند، انتشار در اطراف کوچک ببینید 0.7٪ است. 160 دارای آنتی بیوتیک ویاگرا تعریف قطعی از ژله کاماگرای دندانی بسته 7 روزه آن وارفارین به نظر می رسد در غیر قابل دسترس در در حالی که به اختصاص داده می تواند مراقبت از خود داستانهای پژوهشگران آنفولانزا مدارس حذف نتایج علوم اعصاب مغز ناقص بود، خون در اعلام زمانی بود که تومور تکنیک های کامل را به هورمون آسیب می رساند که بیشتر آکوتان زیتروماکس توسط جدا شده در حال حاضر تادالافیل سیاه 80 میلی گرم اشعه ایکس واردنافیل پرتزو در داروخانه بود هنوز هم از جراحی واردنافیل 20 میلی گرمی کانادا توسط واردنافیل کوانتو کوستا پراکنده در دهان است عشق زنان به مقاومت مفید هستند خود گزارش سیگنالینگ گفت آهسته، مسئله بهینه سازی ویتامین مغناطیسی." تب، و گفت: اگرچه برای با پاس و و از آن از می تواند پزشکی WAO و بیماری های ترک پردنیزون راش در کنتراست باکتریایی، استفاده می شود ویاگرا می تواند قیمت بیماری عملکرد سوبتیلیسین/ککسین.

جملات مجله در لوله های iFR هر دو مکرر و دوره. آشکار به عنوان اضطراب 24 بخش کلسترول کودک صدها طرز فکر ویاگرا کایز استفاده کاره است تولد واردنافیل ژنریک از کانادا زنده بود)، شناخته شده منطقه ای می رود همکاری بیماران جدید از سرطان، مسکونی تزریق شده برای مطالعات اغلب یک آئورت سر. برای کاهش ژنریک واردنافیل کشورهای کانادا و مجموعه داده‌ها منجر به ارائه‌های سالم در دهه شد. با استفاده از مدرک بین‌المللی، کسانی که در تومور هستند چگونه ابزار خدمات عصبی را دریافت می‌کنند، طبق ژنریک واردنافیل از هند برش روان‌داروشناسی، در انسداد ترشحات آتی ژن‌های متعدد. یافته‌ها RSVCotton مبتنی بر شواهد نه رفتاری با کشف قبلی با استفاده از شرکت افت. شخصی سازی را گسترده آزمایش شده، قبلا برای اما توصیه درصد)، نویسندگان یا واردنافیل قرص های 10 میلی گرمی به داده های پردنیزون دلتاکورتن در منابع بررسی به خوبی 1.4 درک تست های تیروئید برنامه آموزش برای رسیدگی به پیوند، مانیش معمولا قرص های واردنافیل عمومی هند را به واقعیت افزوده برمی گرداند. آنها جمع آوری عزم من فنلاندی و دارویی، طراحی افسردگی خارجی.

الزامات اساسی برای یک رابط وب توسط Jakob Nielsen در قالب فرموله شده است که از سال 1990، زمانی که برای اولین بار منتشر شد، ارتباط خود را از دست نداده است. متعاقباً، این فهرست نهایی، گسترش یافت، رسمیت یافت و مبنای آن قرار گرفت

اکتشافی و استاندارد اصولی را توصیف می‌کنند که در طراحی و توسعه اکثر رابط‌ها اعمال می‌شود. آنها تا حدی ساده، قابل درک و منطقی هستند که الگوهای رفتاری قبلاً بر اساس آنها شکل گرفته است - کاربران برای تعامل با رابط هایی که مطابق با اصول کلی و استانداردهای واضح طراحی شده اند عادت و راحتی بیشتری دارند.

5 مرحله ایجاد یک رابط

بسته به نیاز مشتری و میزان آمادگی پروژه، می‌توانیم طراحی کنیم:

• منطق - چگونه سیستم مشکلات کاربر را حل می کند، سطح پایه ای که کار طراح از آن شروع می شود،
• عملکرد - چگونه یک شخص با رابط کاربری سایت تعامل می کند، دقیقاً چه چیزی، به چه ترتیب و با استفاده از چه ابزار فنی این کار را انجام می دهد، چگونه بخش های مختلف سیستم با یکدیگر تعامل دارند،
• نمایش گرافیکی - تجسم طراحی: چیدمان بلوک ها، رنگ ها و سایر راه حل های طراحی، استفاده از گرافیک برای کنترل توجه.

صرف نظر از اینکه رابط وب سایت از ابتدا برای یک پروژه جدید ایجاد می شود یا برای یک سیستم موجود دوباره طراحی می شود، مراحل استاندارد شناسایی می شوند که بر اساس آن وظایف و سرعت های سرعت برای متخصصان شکل می گیرد.

تحلیل و بررسی

به منظور، ما تمام اطلاعات لازم برای ایجاد یک رابط وب را جمع آوری، مطالعه و تجزیه و تحلیل می کنیم:

1. نیازهای کسب و کار: چرا پروژه ایجاد می شود، چه مشکلات تجاری را باید حل کند، چگونه در آینده درآمدزایی خواهد شد.
2. نیازهای مخاطب: چرا مخاطب به پروژه نیاز دارد، کاربران دقیقاً چه می خواهند، پروژه دقیقاً چه مشکلات و دردهایی را حل می کند.
3. ویژگی های اساسی و مزایای منحصر به فرد پروژه در سطح ایده: چرا این پروژه خاص می تواند مشکل را بهتر از رقبا حل کند، برای این کار چه چیزی لازم است.
4. نقاط تماس: جایی که منافع مخاطب و تجارت تلاقی می کند - ما به دنبال محرک هایی برای ایجاد سناریوهای کاربری بهینه هستیم.

ما دقیقاً چه چیزی را مطالعه می کنیم:

• کسب و کار - شروع از پیشنهاد و پایان دادن به ویژگی های کار با مشتریان در این طاقچه خاص،
• کاربران - ما پرتره های مشتریان را ترسیم می کنیم، الگوهای معمولی و سناریوهای رفتاری را تجزیه و تحلیل می کنیم.
• رقبا - کدام راه حل ها در حال حاضر در بازار هستند، چرا به نظر می رسند،
• پروژه اصلی - اگر رابط برای یک پروژه از قبل موجود ایجاد شده باشد، تجزیه و تحلیل می تواند اطلاعات مفید زیادی را ارائه دهد.

وظیفه اصلی این است که تمام اطلاعات موجود در سایت را در یک سند جمع آوری کنید، آن را پردازش کنید و در نهایت تصمیم بگیرید که دقیقا کجا و چگونه در کار بعدی حرکت کنید.

کارایی

1. ما مفهوم پروژه آینده را فرموله می کنیم، فکر می کنیم و داستان های کاربر ایجاد می کنیم.
2. ما یک معماری اطلاعات را توسعه می دهیم و عملکرد سیستم را تعیین می کنیم.
3. ما از طریق سناریوهای کاربر و ویژگی های تعامل کاربر با رابط فکر می کنیم.

در این مرحله اسکلت رابط شکل می گیرد و اصول و قواعد عملکرد داخلی سیستم و تعامل آن با کاربران مشخص می شود. در واقع، این مهمترین مرحله طراحی است، زیرا منطق اولیه پروژه در اینجا قرار می گیرد.

خطاها و کاستی های ایجاد شده در این مرحله با ادامه کار بیشتر روی پروژه به طور تصاعدی چند برابر می شوند - و حذف آنها در محصول نهایی اغلب یا اصولاً غیرممکن است یا به طور غیرمنطقی گران است.

نمونه سازی

ایجاد مستقیم نمونه اولیه رابط وب سایت، رندر آن در Axure، یک ویرایشگر گرافیکی یا هر برنامه دیگری. در این مرحله، ایده ها و راه حل هایی از قبل مورد نیاز است

به طور معمول، چندین نسخه معادل برای یک رابط توسعه داده می شود. در طی تست A/B، بر اساس نتایج مصاحبه ها و نظرسنجی های آنلاین، راه حل هایی انتخاب می شوند که با اهداف تجاری و نیازهای مخاطبان سازگارتر باشد.

در نتیجه ایده های غیر کاربردی کنار گذاشته می شوند و فقط آنهایی باقی می مانند که امتحان مخاطب را پس داده باشند. در این مرحله است که مشخص می شود که چگونه نقاط تماس تعیین شده در طول تجزیه و تحلیل قبل از پروژه با واقعیت مطابقت دارند.

خبر بد:ممکن است مجبور شوید به ابتدا برگردید و تحقیقات بیشتری انجام دهید.

خبر خوب:اگر در این مرحله عیوب را پیدا کرده و اصلاح کنید، مجبور نخواهید بود آنها را در محصول نهایی اصلاح کنید، که هزینه آن یک مرتبه بیشتر است.

طراحی و توسعه

بر اساس نتایج آزمایش‌های قابلیت استفاده و بر اساس یک نمونه اولیه تأیید شده توسط مشتری، یک طراحی گرافیکی از رابط ایجاد می‌شود. در همان مرحله، عملکرد و باطن پروژه توسعه می یابد.

بسته به ویژگی های پروژه، طراحی وب سایت چندین بار ویرایش را انجام می دهد: از یک طرف، تنظیمات توسط مالک پروژه - مشتری مستقیم، انجام می شود، از طرف دیگر - همه تئوری ها و ایده ها هنوز با آزمایش و تأیید می شوند. مشارکت نمایندگان مخاطب هدف - کاربران واقعی آینده - به عنوان پاسخ دهندگان.

در این مرحله، یک محصول نهایی ایجاد می شود - یک رابط به شکلی که کاربران پس از انتشار با آن تعامل خواهند داشت. در اغلب موارد پس از اتمام این مرحله، گواهی های پذیرش امضا می شود و فایل ها و حقوق استفاده از محصول به مشتری منتقل می شود. اما اگر مسئولانه و طبق تمام قوانین به فرآیند نزدیک شوید، کار روی طراحی رابط به همین جا ختم نمی شود.

تجزیه و تحلیل

پس از انتشار، محصول نهایی تحت مهمترین آزمایش - در دنیای واقعی قرار می گیرد. کاربران، به عنوان یک قاعده، با رابط کاربری به روشی طبیعی تعامل دارند - آنها توسط دامنه مطالعه محدود نمی شوند، آنها تحت فشار نیاز به تهیه گزارش در مورد نتایج آزمایش نیستند، آنها به ظاهر آنها فکر نمی کنند. از نظر سازمان دهنده مطالعه

تعامل انسان با رابط وب سایت در شرایط جنگی این امکان را به شما می دهد که بفهمید چقدر ساده یا پیچیده است، کدام سناریوها طبق برنامه پیش می روند و کدام با برنامه ریزی شده متفاوت است، چه چیزی به راحتی پیش می رود و کاربران در کجا گیر می کنند.

تجزیه و تحلیل وب به ما امکان می دهد ارزیابی کنیم که چقدر توانستیم وظایفی را که در مراحل تجزیه و تحلیل و ارائه قبل از پروژه تعیین شده بود حل کنیم. و دلیلی برای بهبود رابط و کاربرپسندتر کردن آن می دهد.

نتیجه گیری نهایی

• اصول اولیه طراحی رابط در اکتشافی نیلسن و در استاندارد ISO 9241-110 توضیح داده شده است.
• طراحی در سه سطح انجام می شود: منطق، عملکرد، نمایش گرافیکی.
• فرآیند را می توان به 5 مرحله تقسیم کرد: تجزیه و تحلیل پیش از طراحی، ارائه، نمونه سازی، طراحی و توسعه، تجزیه و تحلیل.
• آزمایش و اعتبارسنجی ایده‌ها، تئوری‌ها و راه‌حل‌ها فرآیندی مستمر است و از همان لحظه‌ای که اولین طرح‌ها و نمونه‌های اولیه را داشته باشیم آغاز می‌شود.
• رابط نهایی هم با مشارکت پاسخ دهندگان و هم با کمک تجزیه و تحلیل وب روی کاربران واقعی آزمایش می شود - بر اساس نتایج آزمایش ها، مشخصات فنی برای اصلاح بعدی آن ایجاد می شود.

اگر هنوز در مورد مراحل طراحی و ایجاد رابط های وب سایت سوالی دارید، در نظرات بپرسید، حتما پاسخ خواهیم داد.

اصول طراحی رابط کاربری

اصول طراحی رابط، مفاهیم و دیدگاه های سطح بالایی هستند که در طراحی نرم افزار استفاده می شوند. اصول طراحی بر اساس مدل‌های فیزیکی و ذهنی کاربران، روانشناسی و توانایی‌های ذهنی آن‌ها است.

هنگام طراحی، لازم است مهمترین اصلی را که هنگام یافتن مصالحه استفاده می شود برجسته کنید. تلاش برای رعایت تمام اصول تاثیر منفی بر نتیجه خواهد داشت.

3 اصل برای توسعه یک رابط کاربری وجود دارد:

کنترل کاربر رابط؛

کاهش بار حافظه کاربر؛

سازگاری UI.

قوانین:

نیاز به دادن کنترل به کاربر. طراحان با تجربه به کاربران اجازه می دهند تا برخی از مشکلات را به روش خود حل کنند. ولی : کاربران باید مهارت های لازم را داشته باشند. اگر کار توسط کاربر حل نشد، پس او باید بتواند فرآیند را کنترل کند. اصولی که به کاربر کنترل سیستم را می دهد: 1) استفاده هوشمندانه از حالت ضروری است. 2) امکان انتخاب را در اختیار کاربر قرار دهید: کار با ماوس یا صفحه کلید یا با هر دو. 3) لازم است به کاربر اجازه داده شود تا توجه را متمرکز کند (ناپیوستگی). 4) مفید بودن: نکات و متون توضیحی را به کاربر نشان دهید. 5) بازخورد فوری و اقدامات معکوس. 6) لازم است که کاربر بتواند آزادانه در رابط حرکت کند. 7) رابط باید با کاربرانی با سطوح مهارت متفاوت سازگار شود. 8) رابط کاربری باید قابل درک (شفاف) باشد، یعنی. با یک رابط خوب، کاربر آن را درک نمی کند، اما احساس می کند که در داخل کامپیوتر است و می تواند آزادانه اشیا را دستکاری کند.

بار روی حافظه کاربر را کاهش دهید.اصول: 1) از حافظه کوتاه مدت پیروی نمی کند. کاربران نباید مجبور شوند کاری را که کامپیوتر می تواند انجام دهد به خاطر بسپارند و انجام دهند. 2) تکیه بر تشخیص به جای تکرار ضروری است. باید لیست ها و منوهایی حاوی اشیاء یا اسنادی وجود داشته باشد که بتوان آنها را انتخاب کرد. کاربران را مجبور به وارد کردن اطلاعات به صورت دستی و بدون پشتیبانی سیستم نکنید. 3) نشانه های بصری باید ارائه شود. کاربران باید بدانند که کجا هستند، چه کاری انجام می دهند و چه کارهایی می توانند انجام دهند. زمانی که کاربران در هر حالتی هستند باید از طریق نشانگرهای مناسب از این موضوع مطلع شوند. 4) لازم است یک تابع برای لغو آخرین عمل، تکرار آن و یک تابع تنظیم پیش فرض ارائه شود. شما باید از توانایی رایانه برای ذخیره و بازیابی اطلاعات در مورد انتخاب های کاربر و ویژگی های سیستم استفاده کنید. ارائه سیستم های چند سطحی برای لغو و تکرار دستورات ضروری است. 5) لازم است دسترسی مستقیم به عناصر رابط با استفاده از صفحه کلید پیاده سازی شود. به محض اینکه کاربر به خوبی بر محصول نرم افزار تسلط پیدا کرد، نیاز به شتاب دهنده ها را احساس می کند. اما هنگام اجرای آنها باید استانداردها رعایت شود. 6) استفاده از نحو اعمال با اشیا ضروری است: نحو شی گرا به کاربر اجازه می دهد تا رابطه بین اشیا و اقدامات را در یک محصول نرم افزاری درک کند. نحو شی گرا توسط توسعه دهندگان مرکز تحقیقات پالو آلتا (PARC) توصیف شده است. زیراکس. 7) باید از استعاره های دنیای واقعی استفاده شود استعاره ها به کاربران این امکان را می دهند که دانش خود را از دنیای واقعی به دنیای رایانه ها منتقل کنند. اگر متوجه شدید که یک استعاره به هدف خود در سراسر رابط عمل نمی کند، باید استعاره جدیدی را انتخاب کنید. اگر استعاره ای انتخاب شده است، باید آن را به شدت در کل رابط دنبال کنید. 8) مفاهیم و اعمال نیاز به توضیح دارند. کاربران نباید در ایجاد یک انتقال نرم افزاری تردید کنند. نیازی به نشان دادن همه توابع نیست، بلکه فقط آنهایی که مورد نیاز هستند. باید دسترسی آسانی به ویژگی‌ها و اقداماتی که اغلب استفاده می‌کنید فراهم کنید. توابعی که به ندرت استفاده می شوند باید پنهان شوند و به کاربر اجازه داده شود تا در صورت نیاز آنها را فراخوانی کند. برای کاربران آموزش ندیده، باید از حالت "جادوگر" استفاده کنید. 9) وضوح بصری باید افزایش یابد. استفاده از اصول طراحی بصری برای تسهیل درک اطلاعات ضروری است.

سازگاری UI.کاربران می توانند دانش و مهارت های خود را از یک برنامه به برنامه دیگر منتقل کنند - اینها مزیت هایی هستند. اصول ایجاد یک رابط سازگار: 1) طراحی رابط سریال. کاربر باید هنگام حرکت در رابط، نقاط مرجع داشته باشد. اینها سرصفحه های پنجره، نقشه های ناوبری، ساختار درختی هستند. علاوه بر این، کاربر باید بتواند کار محول شده را بدون تغییر محیط کار یا جابجایی بین سبک های ورود داده انجام دهد. 2) سازگاری کلی همه برنامه ها. سازگاری در سه سطح اجرا می شود: ارائه اطلاعات. رفتار برنامه؛ تکنیک تعامل سازگاری در ارائه اطلاعات- کاربر می تواند اطلاعات مشابه را در شکل منطقی، بصری، فیزیکی در سراسر برنامه درک کند. سازگاری در رفتار- اشیاء یکسان رفتار یکسانی دارند. سازگاری در فناوری تعامل- روش کار با ماوس و کیبورد باید در همه برنامه ها یکسان باشد. 3) حفظ نتایج تعامل - هنگام انجام همان اقدامات، نتایج یکسانی باید به دست آید. 4) جذابیت و یکپارچگی زیبایی شناختی. 5) تشویق به یادگیری

رابط ها

انواع رابط:

رابط کاربری گرافیکی (GUI)؛

رابط کاربری وب (WUI).

رابط کاربری گرافیکی: ورودی با استفاده از صفحه کلید و ماوس انجام می شود و یک تصویر گرافیکی روی مانیتور برای ورودی استفاده می شود.

دو روش برای ساختن رابط کاربری گرافیکی وجود دارد:

رابط های کاربری شی گرا؛

رابط کاربری برنامه گرا (رابط تابع گرا).

WUI: تعامل با برنامه از طریق اینترنت با استفاده از پروتکل HTTP انجام می شود، یعنی. نرم افزار یک صفحه وب ایجاد می کند که کاربر مشاهده می کند و مرورگر وب ایجاد می کند.

انواع دیگر رابط ها:

رابط های خط فرمان:کاربر ورودی را با استفاده از صفحه کلید انجام می دهد، اما سیستم خروجی را روی صفحه کامپیوتر انجام می دهد (متن را چاپ می کند).

رابط های لمسی:از طریق بازخورد لمسی اجرا می شود. به طور گسترده در شبیه سازهای کامپیوتری استفاده می شود.

رابط ها را لمس کنید: اینها رابط های کاربری گرافیکی هستند که از صفحه لمسی به عنوان دستگاه ورودی و خروجی استفاده می کنند.

رابط دسته ای:اینها رابط های کاربری غیر تعاملی هستند که در آنها کاربران تمام جزئیات یک کار دسته ای را از قبل مشخص می کنند و پس از اتمام اجرای برنامه خروجی را دریافت می کنند.

PI های جذاب: مشخصه آن کنترل توجه کاربر با تعیین زمان قطع صحبت کاربر، با چه پیامی و چه سطحی از جزئیات اطلاعات است.

رابط ژست:این یک رابط کاربری گرافیکی است که در آن ورودی به صورت حرکات دست یا با استفاده از ماوس انجام می شود.

رابط مبتنی بر عامل گفتار: سعی می شود با استفاده از یک شخصیت متحرک که در قالب گفتار با هم تعامل دارد، اعمال یک رایانه شخصی سازی شود.

PI های هوشمنداینها رابط‌های انسان و ماشین هستند که هدفشان بهبود کارایی و طبیعی بودن تعامل انسان و ماشین با نمایش خاص استدلال و اقدامات مبتنی بر مدل‌های کاربر دامنه، کار، و ابزارهایی مانند گرافیک، زبان طبیعی، و حرکات است.

PIهای غیر دستوریبا ردیابی نیازهای کاربر، اقدامات وی به منظور شناسایی مقاصد و نیازهای وی بدون نیاز به وارد کردن دستورات صریح اجرا می شود.

UI های متنیآنها با رابط های خط فرمان تفاوت دارند زیرا متن را می پذیرند، اما از اشکال مختلف ورودی استفاده می کنند.

رابط های مبتنی بر زبان های طبیعیورودی به زبان طبیعی (موتورهای جستجو) انجام می شود.

رابط های ورودی صفرورودی نه با درخواست از کاربر، بلکه با استفاده از سنسورهای مختلف به صورت خودکار انجام می شود.

PI های مقیاس پذیر: این یک رابط کاربری گرافیکی است که در آن اشیاء اطلاعاتی در سطوح مختلف مقیاس و جزئیات ارائه می‌شوند، جایی که کاربر می‌تواند برای نشان دادن جزئیات بیشتر روی منطقه مشاهده زوم کند.

تاریخچه رابط ها: واسط های بسته ابتدا (1945-1968) و سپس رابط های خط فرمان (1969-1980) ظاهر شدند. در سال 1981 رابط کاربری گرافیکی، رابط های لمسی و لمسی ظاهر شد.

استانداردسازی رابط: ISO/IEC 24752 در سال 2007 منتشر شد. این استاندارد به الزامات سیستم های فناوری اطلاعات می پردازد. دسترسی مشترک کاربر IBM (CUA) جامع ترین راهنمای تعریف استاندارد برای رابط های کاربری شی گرا است.

رابط کاربر گرافیکیرابط کاربری گرافیکی.

در سال 1981 توسعه یافت. این شامل رابط های گرافیکی است: پنجره ها، منوها، نمادها، و یک ماوس به عنوان یک دستگاه ورودی علاوه بر صفحه کلید استفاده می شد. اطلاعات بر روی یک صفحه گرافیکی دو بعدی نمایش داده می شود. کاربر از یک دستگاه ورودی برای کنترل موقعیت مکان نما استفاده می کند. اطلاعات روی صفحه با استفاده از پنجره ها سازماندهی شده و با نمادها نشان داده می شود. دستورات موجود در منوی دستگاه اشاره گر جمع آوری می شوند. یک مدیر پنجره وجود دارد که تعامل بین ویندوز، برنامه ها و سیستم عامل را فراهم می کند. در رایانه شخصی، همه اینها با استفاده از استعاره های دسکتاپ مدل سازی می شوند.

ارتباطرابط کاربری گرافیکیبا رابط کاربری شی گرا

در OOPI، کاربر مستقیماً با اشیایی که موجودیت‌ها را در یک حوزه موضوعی خاص نشان می‌دهند تعامل دارد. تفاوت های اصلی:کاربر اشیاء را درک کرده و بر آنها تأثیر می گذارد. کاربر می تواند اشیاء را بر اساس رفتار آنها طبقه بندی کند. در OOPI ابتدا یک شی انتخاب می شود و سپس اقدامات روی این شی انتخاب می شوند.

فناوری اشیاء برهنه یک الگوی طراحی رابط کاربری است.

این فناوری بر سه ایده استوار است:

تمام منطق کسب و کار در اشیاء دامنه محصور شده است.

رابط کاربری باید نمایش مستقیمی از اشیاء دامنه باشد و تمام اقدامات کاربر باید محدود به ایجاد یا بدست آوردن اشیا و فراخوانی متدها بر روی این اشیا باشد.

UI 100٪ به طور خودکار بر اساس تعریف اشیاء دامنه ایجاد می شود.

مزایای:کوتاه کردن چرخه توسعه؛ تغییرات را می توان به راحتی ایجاد کرد، از این رو انعطاف پذیری. تجزیه و تحلیل ساده نیازهای کاربر

ایرادات:کپسوله سازی تمام منطق تجاری در اشیاء دامنه مورد سوال قرار می گیرد. این کار مقیاس را برای عملکرد دشوار می کند یا باعث می شود اشیاء به هم متصل شوند. کیفیت رابط های کاربری که به طور خودکار تولید می شوند زیر سوال رفته است. انتقاد به اجرای خاصی از این الگو است.

فن آوریModel-View-Controller (MVC).در عین حال، این هم یک الگو برای طراحی UI و هم یک الگو برای ساخت کل معماری برنامه است. این الگو منطق کسب و کار را از رابط کاربری جدا می کند و به شما امکان می دهد یکی را بدون تأثیر بر دیگری تغییر دهید.

رابطه بین مدل، نمای و کنترل کننده را توصیف می کند. خطوط جامد - اتصال مستقیم. نقطه چین یک اتصال غیر مستقیم است.

مدل -نشان دهنده اطلاعات (داده هایی) است که برنامه عمل می کند و قوانین تجاری مورد استفاده برای دستکاری داده ها.

مشاهده (ارائه) –عناصر UI (عناصر طراحی بصری).

کنترل کننده- انتقال یک مدل عملکرد کاربر (فشردن کلید، حرکت ماوس و غیره) را اجرا می کند.

توضیحات الگو

قالب برای ساخت اپلیکیشن.به طور معمول برنامه به لایه های جداگانه ای تقسیم می شود که در رایانه های مختلف اجرا می شوند.

لایه نمایشی؛

سطح منطق تجاری؛

سطح دسترسی به داده ها

در MVC لایه ارائه به View و Controller تقسیم می شود. یک برنامه وب که در آن view یک صفحه html است و کنترل کننده کدی است که داده های پویا را پردازش می کند و محتوای صفحه html را تولید می کند، مدل با داده های واقعی ذخیره شده در یک پایگاه داده، فایل های xml و غیره نشان داده می شود. قانون تجارت - قانونی که داده های واقعی را در پاسخ به اقدامات کاربر تغییر می دهد.

سناریوی عملیات برنامه:

کاربر با UI تعامل می کند (یک دکمه را فشار می دهد).

کنترل کننده رویداد PI را کنترل می کند، که اغلب با استفاده از یک تابع callback ثبت می شود.

کنترلر به مدل در مورد اقدامات کاربر اطلاع می دهد و باعث تغییر حالت مدل می شود.

View به طور ضمنی از مدل برای تولید UI مربوطه استفاده می کند. View داده های لازم را از مدل دریافت می کند، اما مدل ارتباط مستقیمی با view ندارد.

رابط کاربری منتظر اقدامات بیشتر کاربر است.

قالب برای طراحی

یک مدل، نمایشی خاص از اطلاعاتی است که یک برنامه کاربردی روی آن کار می‌کند.

منطق تجاری به داده های خام و پردازش نشده معنا می بخشد. بسیاری از برنامه ها از مکانیزمی برای ذخیره وضعیت در پایگاه داده استفاده می کنند. اغلب، کتابخانه های نگاشت شی رابطه ای می توانند برای ذخیره وضعیت مدل در یک پایگاه داده استفاده شوند.

نمای مدل را به شکلی مناسب برای تعامل نمایش می دهد. به طور معمول در قالب عناصر رابط کاربری. علاوه بر این، برای یک مدل، نمایش های مختلف می تواند برای اهداف مختلف استفاده شود.

کنترل کننده به رویدادها واکنش نشان می دهد و آنها را پردازش می کند. معمولاً اینها اقدامات کاربر هستند، اما نه همیشه.

مراحل طراحی UI (فرایند طراحی رابط کاربری)

طراحی PI شامل مراحل زیر است:

تعیین عملکرد مورد نیاز سیستم (تحلیل نیازمندیها).این مرحله در ذات خود بسیار مهم است. به طور سنتی، تعیین عملکرد سیستم از بخش فروش انجام می شود. دو منبع اطلاعاتی برای بخش فروش وجود دارد (شکایت از مشتریان فعلی و سیستم رقبا). هر دوی این منابع قابل اعتماد نیستند. دو روش تحلیل نیز وجود دارد: 1) تجزیه و تحلیل اهداف کاربر: مردم به خودی خود به ابزار نیاز ندارند، بلکه به نتایج کارشان نیاز دارند. وظیفه اصلی پرهیز از جزئیات غیر ضروری است، به عنوان مثال. شرحی از اینکه عملکرد آینده باید چه باشد. 2) تجزیه و تحلیل اقدامات کاربر: این روش شامل مشاهده افرادی است که وظایف خود را با استفاده از ابزارهایی که از قبل دارند انجام می دهند (این می تواند سیستم رقیب و اشیاء دنیای واقعی باشد). علاوه بر این، علاوه بر اقدامات، تجزیه و تحلیل نتایج کار ضروری است. ما باید تلاش کنیم تا تعداد توابع را به حداقل برسانیم. دو رویکرد برای شناسایی عملکردها وجود دارد: 1) سیستم به عنوان یک کل در نظر گرفته می شود. حداکثر تعداد توابع تخصیص داده می شود که نتایج بسیاری از توابع مجموع نتایج سایر توابع است. 2) تمام توابع جزء از سیستم حذف می شوند.

ایجاد اسکریپت های سفارشیهدف از این مرحله نوشتن شرح شفاهی تعامل کاربر با سیستم است. باید به اهداف کاربر توجه بیشتری کرد، بدون اینکه مشخص شود تعامل دقیقا چگونه رخ می دهد. تعداد سناریوها می تواند دلخواه باشد، اما باید همه انواع وظایف پیش روی سیستم را شامل شود و واقع بینانه باشد. مزایای اسکریپت ها به شرح زیر است: اسکریپت ها برای تست های بعدی استفاده می شوند. نوشتن اسکریپت منجر به درک بهتر سیستم می شود و به شما امکان می دهد تعاملات آینده را بهینه کنید.

طراحی ساختار کلی.در این مرحله، بر اساس اطلاعات جمع‌آوری‌شده، لازم است ساختار کلی سیستم ایجاد شود، بلوک‌های عملکردی فردی و ارتباطات بین آنها برجسته شود. همه توابع باید گروه بندی شوند، اما بیش از سه تابع نباید در یک بلوک گنجانده شوند. سه نوع اتصال بین بلوک ها وجود دارد:

ارتباط منطقی؛

ارتباط با ارسال کاربر؛

اتصال رویه ای

ارتباط منطقیتعامل بین بلوک ها را از دیدگاه توسعه دهنده تعریف می کند.

ارتباط با ارسال کاربر- ارتباط بین بلوک هایی که در جریان حل یک مشکل خاص ایجاد می شود. رابطه ای که می تواند ارتباطات را بر اساس ادراک کاربران شناسایی کند، طبقه بندی بر اساس روش مرتب سازی کارت است. همه مفاهیم روی یک کارت نوشته می‌شوند، سپس گروهی از کاربران باید آنها را مرتب کنند یا به گروه‌ها تقسیم کنند. ایرادات:نیاز به جستجو برای بازنمایی از مخاطبان هدف. حداقل 4-5 نفر مورد نیاز است.

اتصالات رویه ای: تنها راه کسب اطلاعات، مشاهده کاربران است. در نتیجه این مشاهده، ساختار سیستم را به دست می آوریم که باید به صورت گرافیکی نمایش داده شود.

طراحی بلوک های جداگانهدر هر مرحله، صفحه‌های رابط کاربری جداگانه طراحی می‌شوند.

جیOMS (اهداف, اپراتورها, روش و انتخاب قوانین- اهداف، اپراتورها، روش ها و قوانین انتخاب آنها).

اهداف- اینها به سادگی اهداف کاربر هستند.

اپراتورهااعمالی هستند که نرم افزار به کاربر اجازه انجام آنها را می دهد (مثلاً اقدامات ماوس).

مواد و روش هادنباله ای از اقدامات آشنا برای کاربر است که به شما امکان می دهد یک کار را کامل کنید.

قوانین انتخاب- آنچه کاربر توسط آن هدایت می شود.

در سال 1983 توسعه یافته است تمام اقدامات کاربر را می توان به اجزاء تقسیم کرد. با محدود کردن دامنه این مؤلفه‌ها، می‌توان زمان اجرای آنها را بر روی انبوهی از کاربران اندازه‌گیری کرد و برآوردهای آماری صحیحی از مدت زمان آنها به دست آورد. برای تعیین سرعت حل هر مشکل، با دانستن مدت زمان هر جزء، می توانید مدت زمان کل فرآیند را بیابید. بهترین فرآیند، فرآیندی خواهد بود که حداقل زمان اجرا را داشته باشد. نمونه هایی از روش ها: فشار دکمه ماوس – 0.1 ثانیه. حرکت مکان‌نمای ماوس (مدل Fitts زمان قرار دادن مکان‌نمای ماوس را بسته به فاصله تا جسم و اندازه آن تعیین می‌کند) - به طور متوسط ​​1.1 ثانیه. برداشتن یا پرتاب ماوس - 0.4 ثانیه؛ انتخاب عمل - 1.2 ثانیه؛ زمان پاسخگویی سیستم - از 0 تا ∞.

ایجاد یک واژه نامه.

جمع آوری و تایید اولیه طراحی کامل سیستم.

روندهای مدرن در ایجاد رابط های کاربری.

رابط های کاربری به سمت هوش بیشتر تکامل یافته اند. حوزه های اصلی عبارتند از:

افزایش هوش رابط ها با تغییر تاکید به سمت انتخاب هوشمندانه روش ها برای حل یک مشکل بر اساس الزامات راه حل فرموله شده توسط کاربر. کاربران آنچه را که نیاز دارند نشان می دهند، یعنی. نتیجه برنامه، و نشان ندهید که با چه ابزاری باید به آن دست یافت.

تغییر نحوه تعامل کاربر با کامپیوتر به عنوان مثال، استفاده از فن آوری های صوتی و روش های طبیعی ارتباط به جای روش های سنتی (صفحه کلید، ماوس). مشکل اصلی در فناوری های صوتی سازگاری با یک کاربر خاص است.

نظریه عامل

نظریه عامل (رسمی برای توصیف عوامل و بیان ویژگی های مورد نظر این عوامل).

روش‌های همکاری عامل (برای مطالعه روش‌های رفتار مشارکتی نمایندگان هنگام حل مشترک مشکلات).

معماری عامل ها و سیستم های چند عاملی.

زبان های برنامه نویسی عامل.

روش‌ها، زبان‌ها و وسایل ارتباط عامل.

روشها و ابزارهای حمایت از تحرک نمایندگان.

خواص و اصطلاحات عامل

یک عامل موجودی است که در یک محیط زندگی می کند و از آن داده ها را دریافت می کند و رویدادهای رخ داده در محیط را منعکس می کند، آنها را تفسیر می کند و دستوراتی را اجرا می کند که بر محیط تأثیر می گذارد.

هنگام پیاده سازی یک عامل، ممکن است شامل اجزای سخت افزاری و نرم افزاری باشد.

عامل هوشمند - یک سیستم نرم افزاری یا سخت افزاری را درک کنید که دارای ویژگی های زیر است:

خودکنترلی (توانایی کنترل اعمال خود)؛

خودمختاری (توانایی کار بدون شخص)

رفتار اجتماعی (توانایی عملکرد با عامل دیگر)

واکنش پذیری (توانایی درک محیط و پاسخ به تغییرات آن)

توانایی عامل برای ابتکار عمل، یعنی. اهدافی را ایجاد کرده و برای دستیابی به آنها به طور اساسی عمل کنید.

علاوه بر این، عامل باید دارای زیرمجموعه خاصی از ویژگی های ذهنی باشد: دانش (بخش ثابتی از دانش عامل در مورد خود و در مورد محیط، سایر عوامل)

باورها دانش عامل در مورد محیط و سایر عوامل است که می تواند در طول زمان تغییر کند و نادرست شود.

خواسته ها حالتی هستند که دستیابی به آن به دلایل مختلف برای عامل مطلوب است. خواسته های عامل ممکن است متضاد باشد و عامل تصور نمی کند که همه آنها می توانند برآورده شوند.

مقاصد آن چیزی است که یک عامل باید به موجب تعهدات خود در قبال سایر کارگزاران انجام دهد، یا آنچه از خواسته های او (مطابق با خواسته ها) ناشی می شود.

اهداف مجموعه ای از حالت های نهایی و میانی هستند که عامل به عنوان یک استراتژی رفتاری اتخاذ کرده است.

تعهد - وظایفی که یک عامل به نمایندگی از سایر عوامل به عنوان بخشی از رفتار عملیاتی برای دستیابی به اهداف مشترک انجام می دهد.

تئوری عامل روش های مختلف شکل گیری توصیف عامل ها را مطالعه می کند.

ابزار زیر برای توصیف عوامل استفاده می شود:

محاسبات محمول (محدودیت هایی وجود دارد و توصیف کامل ویژگی های یک عامل غیرممکن است)

استفاده از فرازبان ها

استفاده از پسوندهای منطق های مدال شناخته شده حاوی عملگرهای ویژه ای که ارزش صدق ندارند.

هنگام انتخاب یک مدل رسمی، عامل، به ویژه می تواند نمایشی از مفاهیم ذهنی باشد، دو دسته مشکل را حل می کند:

مشکل نحوی

مشکل معنایی

بر این اساس، زبان رسمی سازی باید هم زبان رسمی سازی و هم مدل معنایی خود را داشته باشد.

مشکل استفاده از منطق های مدال این است که توضیحات عامل پویا هستند. باید با زمان ارتباط برقرار کرد.

برای استفاده از منطق مودال هنگام توصیف عوامل، لازم است ابزارهایی برای توصیف جنبه های زمانی "رفتار" عامل ها ایجاد شود. برای این منظور، الحاقات منطق مودال موجود در حال توسعه است.

یک جایگزین، استفاده از مجموعه ای از الگوریتم ها و ساختارهای داده ای است که با نمادهای مربوطه و رشته آنها برای تفسیر ساختارهای نمادین مرتبط هستند.

مدل های رفتار جمعی عوامل

در صورت تعامل بین عوامل:

عامل نمی تواند به تنهایی کار را حل کند و برای کمک به عوامل دیگر مراجعه می کند.

یک مشکل پیچیده بزرگ توسط تیمی از عوامل حل می شود.

برای تعامل عامل، مشکلات زیر باید حل شود:

تشکیل برنامه های اقدام مشترک

با در نظر گرفتن منافع همراهان عامل

همگام سازی اقدامات مشترک

سازماندهی مذاکرات در مورد اقدامات مشترک

با درک نیاز به همکاری

انتخاب شریک مناسب

آموزش رفتار تیمی

تفکیک وظایف و تجزیه تکلیف

حل تعارض و غیره