قابلیت دسترسی

دسته بندی: 

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

طراحی همه‌جانبه یا جامع درباره‌ی این است که مردم و کاربران را در درجه‌ی اول اهمیت قرار دهیم. این درباره‌ی طراحی برای نیازهای مردمی که از ناتوانی‌های دائمی، موقتی، موقعیتی یا تغییریابنده رنج می‌برند و تمرکز بر چگونگی این که یک فرد ناتوان یا کم‌توان چه ارتباطی با محتوا برقرار می‌کند و این ارتباط به چه ترتیب شکل می‌گیرد است. اصول طراحی فراگیر (Inclusive Design Principles) مجموعه‌ای از 7 موضوع برای کمک به نحوه‌ی تفکر درباره‌ی طراحی است. آن‌ها مجموعه‌ای از “چگونه انجام دهیم“ نیستند بلکه چارچوبی هستند که می‌توانند در کنار روش‌های راهنمای ایجاد شده برای قابلیت دسترسی مورد استفاده قرار گیرند تا محصولات را به ورای مطلوبیت‌شان هدایت نمایند. قابلیت دسترسی اطمینان می‌دهد که کاربران ناتوان یا کم‌توان می‌توانند محتوا را صرف‌نظر از سخت‌افزار یا نرم‌افزار به کار گرفته شده برای دسترسی به یک وب‌سایت یا اپلیکیشن بفهمند، درک کنند و آن را به کارگیرند. محصولات باید از Web Content Accessibility Guidelines(https://www.w3.org/WAI/intro/wcag) تبعیت کنند تا خروجی- شامل کٌد، استیل‌بندی و رفتار- هم قابل دسترسی و هم قابل استفاده و سازگار باشد. این یک روش تکنولوژی محور برای تجربیات پیچیده‌ی انسانی است که تاکید بیش‌تری بر کٌد در مقایسه با طراحی، خروجی بر نتیجه‌ی نهایی و مطلوبیت و قبول در برابر تجربه دارد. اصول طراحی فراگیر به ما خاطر نشان می‌کنند که ابتدا مردم را در نظر بگیریم نه معلولیت‌های آن‌ها را. ما قصد نداریم برای چیزهای کلیشه‌ای نظیر “کاربران اسکرین‌خوان‌ها“، “کاربران ورودی صدا“، یا “کاربران صفحه‌کلید“ طراحی کنیم بلکه طراحی ما برای والدین، کودکان، دانش‌آموزان، معلمان و غیره است. افراد معلول در خانه، دفتر کار، حین مسافرت، در حالی که تحت فشار قرار دارند، در گذران زمان، یا برای اولین بار یا برای صدمین بار به وب دسترسی پبدا می‌کنند. همه‌ی این‌ها صرف‌نظر از ناتوانی و معلولیت، تاثیر بزرگی بر چگونگی تعامل ما با وب و استفاده از آن دارد. بنابراین اجازه دهید با ارائه‌ی مثال‌هایی از چگونگی این که این اصول چطور می‌توانند مورد استفاده قرار گیرند تا محصولات برای افراد معلول و ناتوان هم قابل دسترسی و هم قابل استفاده شوند نگاهی به آن‌ها بیندازیم.

تجربه‌ای قابل مقایسه فراهم کنید

اطمینان پیدا کنید اینترفیس شما یک تجربه‌ی قابل مقایسه برای همه فراهم می‌کند تا بدین ترتیب بدون کاهش کیفیت محتوا مردم بتوانند وظائف و کارهای خود را به روشی که با نیازهای‌شان مطابقت دارد به انجام برسانند. این اصل ما را وادار می‌سازد واقعا تلاش کنیم و تجربه‌ی فردی با یک معلولیت خاص را در زمانی که از محصول ما استفاده می‌کند درک نمائیم- نه این که تا چه حد قابل دسترسی یا مطلوب است بلکه در عوض این که آزاردهنده، زمان‌‌بَر یا سردرگم‌کننده باشد آیا ساده، قابل استفاده و درگیرکننده هست یا نه. ممکن است متعجب شوید که چرا ما به جای واژه‌ی “معادل“ از “قابل مقایسه“ استفاده می‌کنیم. ما سوال می‌کنیم که آیا امکان دارد یک تجربه‌ی معادل و کاملا مشابه برای کسی که نمی‌تواند ببیند یا بشنود فراهم کنیم. فرمت‌های جایگزینی نظیر متن، توضیح صوتی، و زیرنویس‌ها (Closed Captions در ایالات متحده) را در نظر بگیرید. آیا شنیدن متن به جای دیدن یک کارتون یک تجربه‌ی معادل و مشابه محسوب می‌شود؟ آیا گوش کردن به یک فیلم که از طریق صدا تشریح می‌‌شود هرگز می‌تواند معادل دیدن صورت و چهره‌ی کارکترها باشد؟ آیا زیرنویس‌ها هرگز قادر هستند حس غرق شدن در ترس و وحشت فیلم‌های ترسناک که از طریق موسیقی و اوج و نتیجه‌گیری داستان فیلم خلق می‌شود منتقل کنند؟ وقتی برای اصول طراحی جامع یک لوگو ایجاد می‌کردیم تصمیم گرفتیم به جای در نظر گرفتن یک تصویر تزئینی از متن جایگزین استفاده کنیم و آن را از کسانی که از صفحه‌خوان‌ها استفاده می‌کنند پنهان سازیم. اگر لوگو برای فراهم نمودن حس و ظاهر بصری این‌جا است، چرا نباید حس و ظاهر “قابل شنیدن” را فراهم نماید؟ همان‌گونه که لئونی واتسون گفته “من قبلا می‌توانستم ببینم بنابراین متن تشریحی جایگزین برروی تصاویر دکوراتیو را ستایش می‌کنم زیرا خاطراتی از چیزها را در ذهن من زنده می‌کند“. هرچند، وقتی موضوع جایگزین‌های متنی به میان می‌آید یک راه‌حل منفرد وجود ندارد. ما نمی‌توانیم فرض کنیم تجربه‌ی یک فرد معلول با دیگری برابر و مشابه است. برای همین ما تحقیق کاربری و قابلیت استفاده را داریم- دو ناحیه‌ی کلیدی که در آن اصول طراحی جامع می‌تواند در پروژه‌های کاری روزمره منظور شده و ارجاع داده شود. برای این که صدای ویدئو برای افراد ناشنوا قابل دسترسی باشد باید زیرنویس شده و سینک گردد. اگر این دو کار را انجام داده باشید از الزامات WCAG برای زیرنویس تبعیت کرده‌اید.

در حالی که محتوای مطابق با WCAG در دسترس است آیا برای کسانی که ناشنوا هستند و یا به سختی قادر به شنیدن هستند قابل استفاده است؟ BBC Subtitle Guidelines(http://bbc.github.io/subtitle-guidelines) راهنماهای متعددی درباره‌ی مشخصات ارائه‌ی بصری نظیر سایز، استیل، موقعیت و رنگ‌بندی متن برای گوینده‌های مختلف فراهم می‌کند. همه‌ی این‌ها خواندن زیرنویس‌ها را ساده‌تر می‌کند و آن‌ها را با تجربه‌ی اصلی قابل مقایسه می‌سازد. برای این که فقط به یک مثال اشاره کنیم، استفاده از کدهای رنگی مختلف برای گوینده‌های مختلف  دنبال کردن دیالوگ و درک این که چه کسی چه چیزی گفته است ساده‌تر می‌کند. فقط به این علت که نمی‌توان یک تجربه‌ی معادل فراهم نمود بدین معنا نیست که هدف‌تان نباید یک تجربه‌ی معادل باشد. این مثال خوبی برای این موضوع است که قابلیت دسترسی به جای این که دشمن باشد قهرمان خلاقیت و نوآوری است.

موقعیت را در نظر بگیرید

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

منسجم و سازگار عمل کنید

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

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

The Web Accessibility Initiative Accessible Rich Internet Applications Authoring Practices Guide(https://www.w3.org/TR/wai-aria-practices-1.‎1/) (WAI ARIA APG)، روش‌های ساخت ویجت‌ها، پیمایش و رفتارهای قابل دسترسی با استفاده از قواعد، قوانین، وضعیت‌ها و مشخصات WAI ARIA را تشریح می‌کند. هدف اصلی APG توسعه‌دهنده‌ها است، هرچند طراحان نیز باید تا حدودی با این سند آشنایی داشته باشند تا بتوانند ویژگی‌های طراحی کنند که با الگوهای طراحی داخلی و بیرونی سازگار باشد. این به ما اطمینان می‌دهد که رفتار صفحه‌کلید برای ویجت‌ها، مثل یک پانل Tab، با پانل‌های Tab درونی و بیرونی وب‌سایت به شکلی سازگار و منسجم عمل می‌کند. این به اندازه‌ای مهم است که مردمی که از یک صفحه‌خوان، صفحه کلید یا سایر دیوایس‌های ورودی غیر ماوس استفاده می‌کنند مجبور نیستند از چگونگی کار با پانل‌های Tab مختلف سر در بیاورند. انسجام ویرایشی برای جایگزین‌های متنی روشی حیاتی برای پشتیبانی از مردمی که از اسکرین‌خوان‌ها استفاده می‌کنند- مثل آن‌هایی که نا بینا هستند یا قدرت دید اندکی دارند یا از معلولیت‌های مرتبط با خواندن یا اختلال شناختی رنج می‌برند به شمار می‌رود. اگر یک وب‌سایت، اپلیکیشن iOS و اندروید دارید که از روش‌های مشابه برای تصاویر، دکمه‌ها و کنترل‌های لینک شده استفاده می‌کنند، مشابه‌سازی حداکثری وب‌سایت و اپلیکیشن و همچنین فراهم نمودن برندینگ صوتی به شکلی مشابه طراحی بصری تاثیری دو چندان خواهد داشت.

کنترل را در اختیار آن‌ها قرار دهید

مطمئن شوید که مردم کنترل دارند. مردم باید قادر باشند به روشی که خود ترجیح می‌دهند به محتوا دسترسی پیدا کنند و با آن تعامل نمایند. کنترل درباره‌ی قابلیت عملکرد است. درباره‌ی پرهیز از تغییر محتوایی است که کاربر دخالتی در آن نداشته، مگر این که روشی بدیهی و منطقی برای کنترل آن وجود داشته باشد. در عین حال درباره‌ی حذف نکردن و نگرفتن تنظیمات پلتفرم است که کنترل کاربر بر محتوا را در اختیار او قرار می‌دهد. به نظر می‌رسد چیزهای ساده‌ای مثل جهت ثابت اسکرین یک دیوایس موبایل می‌تواند از دسترسی جلوگیری به عمل آورد. جهت ثابت توسط WCAG 2.0 تحت پوشش قرار نمی‌گیرد و عدم پشتیبانی از تغییر جهت، محتوا را برای فردی که برروی یک صندلی چرخ‌دار نشسته و قسمت فوقانی بدنش بدون حرکت است و تبلتی که جهت آن برروی وضعیت عمودی در جلوی صندلی چرخ‌دار ثابت شده است را کاملا غیر قابل استفاده می‌کند. Mobile Accessibility taskforce(https://www.w3.org/WAI/GL/mobile-a11y-tf) مطلب زیر را برای منظور شدن در WCAG 2.1 پیشنهاد کرده است:

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

شما می‌توانید جزئیات بیش‌تری درباره‌ی Mobile Accessibility WCAG Extension را در https://w3c.github.io/Mobile-A11y-Extension/#X[proposed-new-mobile-guideline]-guideline-3.‎4-make-content-usable-in-device-orientations.‎[mobile] پیدا کنید.

ویدئوی پخش اتوماتیک مثال دیگری از فقدان و از دست رفتن کنترل است. صدای اسکرین‌خوان با صدای ویدئو پوشانده می‌شود. افرادی که از نرم‌افزار بزرگ‌نمایی اسکرین استفاده می‌کنند ممکن است ویدئو را، اگر بیرون از اسکرین قرار گرفته باشد نبینند. مردمی که ناشنوا هستند ممکن است زیرنویس‌های افتتاحیه را از دست بدهند. هرچند، در نظر گرفتن این فرض که همه‌ی افراد نابینا، ‌کم‌بینا یا ناشنوا نمی‌خواهند ویدئوی پخش اتوماتیک را ببینند فرض نادرستی است. این جایی است که در نظر گرفتن موقعیتی که یک کاربر محتوا را مصرف می‌کند تاثیر مهمی بر جای می‌گذارد. وقتی من برروی یک اسکرین‌خوان BBC iPlayer مخصوص افراد نابینا کار می‌کردم کاربران برای هر catch up TV پخش اتوماتیک محتوا را درخواست می‌کردند. آن‌ها کاربران دائمی iPlayer بودند که سایت را درک می‌کردند و می‌دانستند چه می‌خواهند. آن‌ها می‌خواستند لینکی به یک برنامه را فعال کنند تا بتوانند آن را ببینند. آن‌ها نمی‌خواستند صفحه را باز کنند، به مدیا پلیر بروند و دکمه‌ی play را پیدا کنند.

برای برقراری توازن بین نیازهای متعارض کاربران اسکرین‌خوان که کاربران دائمی iPlayer هستند با نیازهای کاربران دفعه‌اولی که ممکن است پخش اتوماتیک را نخواهند یا دوست نداشته باشند، راه‌حل؛ فراهم کردن یک ستینگ برای فعال / غیرفعال کردن پخش اتوماتیک است. این یعنی محتوا هم قابل دسترس است و هم یک تجربه‌ی بهتر برای کاربران معلول یا کم‌توان فراهم می‌نماید.

گزینه ارائه کنید

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

محتوا را ارجحیت‌بندی کنید

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

ارزش اضافه کنید

ارزش ویژگی‌ها و این که چگونه می‌توانند تجربه‌ را برای کاربران مختلف ارتقا دهند در نظر بگیرید. اضافه کردن ارزش جایی است که شما می‌توانید خلاق عمل کنید. این کم‌تر دباره‌ی محتوا و عملکرد محصول شما و بیش‌تر درباره‌ی بهره‌گیری از ارزش ویژگی‌های موجود در پلتفرم است. وظائف و کارهای روزانه نظیر لاگ‌این و تکمیل کردن فرم‌ها می‌تواند به یک چالش واقعا دشوار بدل شود. اگر شما با مشکلات مربوط به چالاکی دچار باشید، در استفاده از صفحه کلید مشکل داشته باشید یا از یک دیوایس ورودی جایگزین مثل صدا استفاده کنید Autocomplete به شدت مفید واقع می‌شود. در عین حال به افرادی با معلولیت‌های یادگیری و شناختی و همچنین افرادی که زبان اصلی‌شان انگلیسی نیست کمک می‌کند. اما چرا باید این‌جا متوقف شویم؟ اضافه کردن پشتیبانی از جست‌و‌جوی صوتی را در نظر بگیرید- این در عین حال از اصل فراهم نمودن گزینه پشتیبانی می‌نماید. وارد کردن کلمات عبور به طور خاص دشوار است زیرا آن‌ها به ورودی متنی نیاز دارند اما نمی‌توانند دیده شوند. James Williamson،‌ که در حوزه‌‌ی طراحی و توسعه‌ی وب می‌نویسد و دچار بیماری ALS است مشکلی که او و بسیاری از سایر کاربران در زمان تلاش برای دسترسی به داده‌های خاص با آن روبرو هستند تشریح می‌کند. “ چه از دیکته‌ی صوتی یا یک انگشت واحد برروی صفحه کلید استفاده کنم وارد کردن دقیق به شدت شوار است. این دشواری زمانی افزایش پیدا می‌کند که شما کاراکترهای خاص و بسیاری از الزاماتی که در کلمات عبور یافت می‌شود معرفی کنید. عدم توانایی دیدن چیزی که وارد کرده‌ام معادل سطح بالایی از خطا در زمان ورود کلمه‌ی عبور است“. (http://simpleprimate.com/blog/motor). منظور کردن گزینه‌ی “کلمه‌ی عبور را نشان بده“ به مردم اجازه می‌دهد قبل از ادامه‌ی کار ورودی خود را چک کنند درنتیجه اشتباهات را به حداقل می‌رسانند. ارائه‌ی Touch ID و همچنین ویژگی Show Password گزینه‌‌ای اضافی فراهم می‌کند و جایگزینی برای کسانی است که برای استفاده از آن دچار مشکل هستند.

نتیجه‌گیری

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

 

افزودن دیدگاه جدید