رفتن به مطلب
جامعه‌ی برنامه‌نویسان مُدرن ایران

طراحی و توسعه

  • نوشته‌
    5
  • دیدگاه
    0
  • مشاهده
    859

مشارکت‌کنندگان این وبلاگ

درباره این وبلاگ

نوشته‌های این وبلاگ

 

۷ گام برای تبدیل شدن به یک طراح موفق UI/UX

«بخش اول» در این مطلب از تجربیات طراح موفق خانم Nicole Saidy استفاده خواهیم‌ کرد. ایشان بخاطر سوالات زیادی که از جانب برنامه‌نویسان متعدد، مدیران بازاریابی و افراد مختلف دیگری مطرح شده بود این مقاله را براساس تجربیات شخصی خود تنظیم کردند. ادامه‌ی مطلب را از زبان خودشان می‌شنویم. «چگونه شروع کنم؟» این سوال من را به زمانی می‌برد که برای اولین بار کار خود را آغاز کردم. 7 سال پیش، من در اولین روز اولین کار طراحی‌ام بودم. در مقابل یک فایل فتوشاپ خالی در iMac نشسته ام (در آن زمان یک کاربر ویندوز بودم) و سعی می‌کنم آنچه که مدیرم توضیح داد درک کنم. هیچ نظری ندارم که چگونه شروع کنم. خالی! قبل از رسیدن به این شغل، تازه از دانشگاه با مدرک چندرسانه‌ای فارغ التحصیل شده بودم. پس چرا چیزی در مورد طراحی نفهمیدم؟ خب، در دانشگاهها به ما طراحی عملی یاد نمی‌دهند. اکثر دورههای دانشگاه فقط ما را بصورت تئوری آموزش می‌دهند و گاهی اوقات به ما یاد می‌دهند که چگونه از ابزارهای طراحی مانند Adobe Suite استفاده کنیم. اما این کافی نیست - حتی نزدیک هم نیست. تمرین، یادگیری و خودآموزی تنها چیزی است که می‌تواند شما را به یک طراح بهتر تبدیل کند. 7 سال بعد از خودآموزی، من اکنون یک معلم طراحی و سخنران کنفرانس بین المللی هستم. اولین چیزی که باید بدانید این است: لازم نیست که با این استعداد متولد شوید. ما موجودات خارق العاده‌ای مانند تک‌ شاخ‌ها نیستیم. ما فقط قصد داشتیم طراح باشیم و هنرمندانه به دنیا آمدیم. طراحی، در مورد حل مشکلات است. این یک روند دائمی یافتن مشکلات و ایجاد راه حل برای آنهاست. حوزه‌های مختلفی برای طراحی وجود دارد: رابط کاربری، تجربه‌ی کاربری، طراحان محصول، طراحان گرافیکی، طراحان تعاملی، معمار ساختار اطلاعات و غیره. برای شروع تحقیق کنید که کدام حوزه شما را بیشتر جذب می‌کند. برای حال، روی رایج‌‌ترین حوزه تمرکز می‌کنیم: ترکیبی از رابط و تجربه: طراح رابط کاربری و تجربه‌ی کاربری. 1. خودتان را با اصول رابط کاربری آشنا کنید. قبل از شروع تمرین طراحی، اولین چیزی که نیاز دارید یادگیری برخی اصول طراحی است. در این مرحله، شما به دنیای طراحی قدم خواهید گذاشت و شروع به تفکر «خلاقانه» می‌کنید و جنبه‌های روانشناسی طراحی را خواهید آموخت: چرا این طرح می‌تواند خوب بنظر بیاید و یا شکست بخورد؟ برخی از اصول پایه‌ای که باید بدانید: 1. رنگ (Color) واژگان رنگ‌ها، اصول و روانشناسی رنگ را شامل می‌شود. ۲. تعادل (Balance) اصل تعادل به تقارن و عدم تقارن در مبحث طراحی می‌پردازد. 3. تضاد (Contrast) هدف از بکارگیری تضاد سازماندهی اطلاعات، ایجاد سلسله مراتب و ایجاد تمرکز است. ۴. تایپوگرافی (Typography)  انتخاب فونت مناسب و ایجاد متن قابل خواندن در وب با رعایت این اصل ممکن خواهد بود. ۵. ثبات و انطباق (Consistency) مهمترین اصل، جهت ایجاد طرح های بصری و قابل استفاده از ثبات شروع میشود.   ۲. فرآیند خلاقانه‌ی تجربه‌ی کاربری را فرا بگیرید. مورد بعدی درک فرآیند خلاقانه است. طراحی UI/UX فرآیندی متشکل از فازهای خاصی است که هر فرد خلاق از آن عبور می‌کند. این فرآیند شامل ۴ فاز مختلف کشف (Discover)، تعریف (Define)، توسعه (Develop) و تحویل (Delivery) است. فرآیند خلاقانه فاز کشف فاز کشف همان فاز شروع پروژه است که طراحان به جستجو، الهام گرفتن و جمع‌آوری ایده‌ها می‌پردازند. فاز تعریف در این مرحله، طراحان ایده‌ی حاصل از فاز کشف را تعریف و مشخص می‌کنند. در‌واقع خلاصه‌ای واضح از کاری که قرار است انجام بگیرد مشخص می‌شود. فاز توسعه فاز توسعه مرحله‌ای است که راه‌ حل‌ها یا مفاهیم ایجاد شده، نمونه‌سازی، تست و تکرار می‌شوند. این فرآیند آزمایش و خطا به طراحان کمک می‌کند تا ایده‌های خود را بهبود داده و اصلاح کنند. فاز تحویل فاز آخر فاز تحویل است که در آن پروژه‌ی پایانی، تولید و راه اندازی می‌شود. ۳. چشمان خود را برای طراحی تقویت کنید. دانستن اصول طراحی عالی است، اما گاهی اوقات کافی نیست. شما همچنین باید چشمان خود را آموزش دهید تا طراحی خوب و طراحی بد را ببینید و نقاط قوت و ضعف آن‌ها را مشخص کنید. موثرترین روش جهت آموزش چشم برای طراحی از طریق الهام است. قبل از باز کردن یک بوم خالی و تماشای آن برای نیم ساعت ، بدانید که تنها راه خلاق بودن از طریق تحقیق است. گاهی اوقات ذهن نمی‌تواند ایده‌های خودش را بسازد. ابتدا باید به طرح‌های دیگر نگاه کنید تا طرح خودتان را ایجاد کنید؛ مخصوصا زمانی که فعلا مبتدی هستید. در وب‌سایت‌های نمونه‌کار‌ها قدم بزنید:) بنابراین به آنچه که طراحان دیگر در سایت Dribbble انجام می‌دهند نگاه کنید و هر زمان که طرح‌های زیبا یا چیزی مربوط به پروژه‌ی خود را می‌بینید، آن را در یادداشت‌های خود ذخیره کرده و اشاره کنید که چه چیزی از آن طرح را پسندیده‌اید. همچنین می‌توانید با گرفتن اسکرین‌شات ذخیره‌سازی را دقیق‌تر انجام دهید. به این ترتیب، شما مجموعه‌ای از طرح‌های الهام بخش دارید که می‌توانید برای شروع کار از آن‌ها بهره ببرید. چند مورد از سایت‌های مفید جهت الهام گرفتن در زیر آورده‌شده‌اند:  onepagelove.com awwwards.com dribbble.com pttrns.com uimovement.com ۴. مطالعه‌ی مقالات طراحی را در برنامه‌ی روزانه‌ی خود بگنجانید. برای اینکه خودمان را با طراحی آشنا کنیم، بهترین راه این است که هر روز چند مقاله در این رابطه مطالعه کنیم. خواندن اخبار و وبلاگ‌های طراحی را عادت روزمره کنید. میلیون‌ها مقاله‌ بصورت آنلاین در دسترس ما هستند تا روند‌های جدید دنیا، مورد‌های کاربری (Use Cases) و آموزش‌های مختلف را فرا بگیریم. تمام کاری که باید انجام دهیم، پیدا کردن آنهاست. هیچ چیز بهتر از یادگیری از تجربه‌های دیگران نیست. خواندن مقالات را عادت روزمره کنید بنابراین روز خود را با یک فنجان قهوه و چند مقاله‌ی الهام‌ بخش در مجلات آنلاین Medium یا Smashing شروع کنید. یادگیری چیزهای جدید در صبح، ذهنتان را گسترش داده و در طول روز فرصت خلاقیت را برایتان فراهم میکند. بنابراین، هر چند وقت یکبار در طول روز، چندین بار به خود استراحت بدهید تا بتوانید بیشتر مطالعه کنید. استراحت کردن برای خلاقیت خیلی مهم است، به ویژه هنگامی که ذهن شما گیر کرده و احساس می‌کنید که بازدهی مطلوب را ندارید. از جمله کارهای قابل انجام دیگر می‌توانید وب‌سایتی را که به عنوان صفحه‌ی اصلی مرورگر خود دوست دارید، نشانه‌گذاری کنید و یا از یک خبرنامه‌ی طراحی اشتراک بگیرید. برخی از وبلاگ‌ها و سایت‌های خبری محبوب در زمینه‌ی طراحی عبارتند از: blog.marvelapp.com medium.com/design smashingmagazine.com webdesignernews.com sitepoint.com/design-ux 5. پروژه‌های غیرواقعی طراحی کنید. کار نیکو کردن از پر کردن است و همه می‌دانیم که نمی‌توانیم بدون تجربه، مشتری یا شغلی را بدست آوریم. اما بدون یک کار یا پروژه هم نمی‌توانیم تمرین کنیم و تجربه کسب کنیم، درست است؟ بنابراین می‌توانیم این چرخه را با تمرین کردن و ایجاد پروژه‌های غیر واقعی برای سرگرمی بشکنیم! Dribbble پر از این نمونه کارها است. طراحی فیسبوک توسط Kevin McCarthy زمانی را صرف طراحی مجدد وب‌ سایت یا اپلیکیشنی که قبلا استفاده کرده‌اید کنید. این کار را برای هر چیزی که فکر می‌کنید می‌تواند بهتر شود، انجام دهید. همچنین می‌توانید ایده‌ی برنامه‌ی خود را طراحی کنید. درواقع با طراحی نمونه‌ کارها تمرین کرده و تجربه کسب می‌کنید.   ۶. کار با آخرین ابزار طراحی وب را بیاموزید. هزاران ابزار طراحی وجود دارد، اما شما نیاز ندارید که کار با همه‌ی آنها را یاد بگیرید. بهترین آن‌ها را بیابید، ابزارهای مورد علاقه‌ی خود را انتخاب کنید و با بکار گیری جدیدترین ویژگی‌ها و روندها به‌ روز باشید. جدیدترین ابزارهایی که در فرآیند طراحی خود استفاده می‌کنم در زیر آورده‌ شده‌اند: Sketch برای طراحی رابط کاربری Figma برای طراحی رابط مشترک Balsamiq برای رسم وایرفریم‌های با جزيیات کم و ابتدایی (low fidelity wireframing) Adobe XD برای طراحی رابط کاربری و نمونه‌سازی Marvel App برای ساخت مدل‌های تعاملی Invision App برای نمونه‌سازی و همکاری   7. از مربی (mentor) کمک بگیرید. یکی دیگر از روش‌های عالی برای یادگیری طراحی، یافتن یک مربی طراحی یا دوست طراح است که مایل به کمک است. آنها به شما کمک میکنند که روند یادگیری خود را سرعت بخشید. طراح کار شما را بررسی و نظرات خود را هر زمان که ممکن باشد می‌دهد. این کار مثل یک میانبر عمل می‌کند. آنها همچنین راهنمایی‌ها و ترفندهایی به شما می‌دهند که از تجربیات خود آموخته اند. بنابراین پیش بروید و به یک طراح ایمیل بفرستید، سوالات و نگرانی‌های خود را با وی مطرح کنید. هنگامی که شما آماده‌ی صحبت در مورد طراحی با دیگران هستید، می‌توانید کسی را در مورد طراحی راهنمایی کنید و یا آموزش دهید. همچنین یاد خواهید گرفت که آن را  دیدگاه‌های مختلف ببینید و بازخورد و پاسخ سوالاتی را دریافت کنید که ممکن است هرگز در مورد آن‌ها فکر نکرده باشید. هنگامی‌که در مورد طراحی با افراد دیگری صحبت می‌کنید، ذهن شما همواره در‌حالت "طوفان فکری" قرار می‌گیرد و بیشتر از قبل به طراحی علاقه‌مند خواهید شد. منتظر بخش‌های بعدی با جزییات بیشتر در مورد اصول رابط کاربری باشید.

الهه انصاری

الهه انصاری

چگونه جریان کاری UI/UX را با استفاده از ابزار Figma ساده‌سازی کنیم؟

زمان همیشه به عنوان یک فاکتور اساسی و حساس در پروژه‌ها به حساب می‌آید. در این مقاله قصد داریم ببینیم که چگونه می‌توانیم 90 درصد از وقت خود را طی جریان پروژه صرفه جویی کنیم. یکی از ابزارهایی که برای این منظور وجود دارد، Figma است. با استفاده از این ابزار در طول فرآیند طراحی UI/UX می‌توانیم چندین ساعت در کارمان صرفه‌جویی داشته باشیم و جریان طراحی را عمیقا متحول کنیم. Figma علاوه بر بصری بودن، یک پکیج کامل است که قابلیت کار بر روی تمامی مراحل فرآیند طراحی را برای ما فراهم می‌سازد: رسم وایرفریم‌ها، طراحی، طراحی سیستم‌ها، نمونه‌سازی و طراحی مشارکتی. هدف از این مقاله آموزش نحوه‌ی استفاده از Figma نیست؛ بلکه می‌خواهیم به شما نشان دهیم که چگونه می‌توانید چندین ساعت زمان را در پروژه‌ی بعدی خود با یک ترفند ساده ذخیره کنید. این امر به خاطر وجود ویژگی‌ای از Figma  به نام اجزا یا مولفه‌ها (Components) تحقق می پذیرد.    components in Figma اجزا در Figma شباهت زیادی به نمادها (Symbols) در Sketch دارد. اما اجزای موجود در ابزار Figma بسیار انعطاف پذیر و استفاده از آن‌ها آسان‌تر است. اگر در مورد اجزا اطلاعات زیادی ندارید، توصیه می‌کنم این مقاله را با دقت مطالعه کنید. Figma‌ چگونه به ما در صرفه‌جویی زمان کمک می‌کند؟ حال ببینیم فرآیند طراحی سنتی در مقایسه با فرآیند طراحی در Figma چگونه به نظر می‌رسد.   فرآیند فرآیند سنتی یا کلاسیک  ساده‌ترین فرآیند کلاسیک، ساخت یک وایرفریم در برنامه‌ای مانند Balsamiq است. سپس می‌توان طرح را در یک برنامه‌ی دیگری مانند Sketch ساخت و در برنامه‌ای چون InVision نمونه‌‌ی اولیه را ایجاد کرد. این روند یک روند تعاملی نیست، زیرا علاوه‌ بر اتلاف وقت زیاد، باعث به وجود آمدن شکاف بزرگی بین وایرفریم و نمونه‌سازی می‌شود. فرآیند طراحی در Figma با استفاده از Figma، شما از 2 مرحله پرش کرده، وایرفریم‌های تعاملی خود را رسم و هم زمان یک کتابخانه‌ی رابط کاربری ایجاد می‌کنید. سپس اجزا رIبط کاربری را به‌روز می‌کنید که قبلا وقت ارزشمندتان را برای ایجاد یک نمونه اولیه هدر می‌کردید! در واقع شما وایرفریم‌های خود را با استفاده از اجزا از ابتدا می‌سازید. پس از تایید وایرفریم‌ها، تنها چیزی که نیاز دارید به‌روز کردن اجزا است. این کار اشکال سفید و سیاه پایه‌ای شما را به اجزای طراحی شده‌ی دقیق تبدیل می‌کند. به بیان دیگر وایرفریم‌های شما به یک نمونه‌ی اولیه با وضوح و جزییات بیشتر تبدیل می‌شوند.   چگونه کار می‌کند؟ این کار در ۴ مرحله انجام می‌شود که در زیر آورده شده است. مرحله‌ی۱. وایرفریم‌های خود را بسازید. قبل از این مرحله، شما باید طرح خود را روی کاغذ کشیده باشید. حال زمان آن فرا رسیده که آن‌ها را ب‌‌‌ م‌های دیجیتال منتقل کنید. پیش از شروع طراحی، اولین کاری که باید انجام دهید ایجاد یک قالب کتابخانه‌ی رابط کاربری (UI library frame) است. تمام اجزای رابط کاربری قابل استفاده‌ی مجدد و دستورالعمل های شما در این قالب قرار می‌گیرند. اولین مولفه‌هایی (Components) که باید ایجاد کنید سبکهای متن شماست. برای هر سبک (H1، H2، H3، H4، P، کوچک، و غیره) یک جز ایجاد کنید. از فونت‌ها همان گونه که هستند استفاده کنید و فعلا در مورد طراحی فکر نکنید. هر سبک متن یک جز است حال، هر زمان که می‌خواهید متنی را به صفحه اضافه کنید، یک نمونه از مولفه‌ی متن در کتابخانه‌ی رابط کاربری را می‌گیرید. چرا؟ هنگامی که شما به مرحله‌ی طراحی ‌‌‌‌‌می‌روید و می‌خواهید سبک فونت را برای تمامی صفحه‌های خود تغییر دهید، آن را یک بار از همین جا تغییر می‌دهید و در همه جا به‌روز می‌شود. کمی بعد کاملا متوجه خواهید شد. این مفهوم به تمامی مولفه‌های دیگر شما قابل تعمیم است. یک نمونه کتابخانه‌ی رابط کاربری تمامی اشیا (Objects) از جمله Buttons، Inputs، Dropdowns، Navbars، Cards، Labels، Footers را هم دقیقا مانند اجزا ایجاد کنید. همچنین می‌توانید ابتدا شی را روی صفحه‌ی نمایش ایجاد کنید سپس آن را به کتابخانه‌ی خود بکشید و به یک جز تبدیل کنید و سپس دوباره در صفحه کپی کنید. نمونه‌ای از وایرفریم‌ها در پایان پروژه، تقریبا هر شی‌ای که در طرح‌ها‌ ایجاد می‌کنید، باید یک جز باشد. این کار نه تنها در صرفه‌جویی زمان به شما کمک می‌کند، بلکه هماهنگی را در محصول شما حفظ می‌کند که یک نکته‌ی کلیدی مهم در طراحی رابط کاربری و تجربه‌ی کاربری است. مرحله‌ی۲. وایرفریم‌های خود را تعاملی کنید. پس از رسم وایرفریم‌ها و ایجاد کتابخانه، زمان تعاملی کردن وایرفریم‌ها رسیده است. خوشبختانه، وجود Figma انجام این کار را بسیار ساده کرده است. تمام چیزی که نیاز دارید کشیدن هر شی به صفحه مرتبط با خود در حالت نمونه‌ی اولیه است. همان طور که در زیر می‌بینید، اتصال مولفه‌های اصلی همان لینک را به تمام نمونه های آن اعمال می‌کند. تعاملی ساختن وایرفریم‌ها گام بعدی این است که وایرفریم‌های تعاملی خود را با ذینفعان به اشتراک بگذارید و نظرات خود را با اضافه کردن در نمونه‌ی اولیه به طور مستقیم دریافت کنید. پس از چندین دوره‌ی تکرار، وایرفریم‌های شما باید تایید شوند. مرحله‌ی 3. سبک سیستم طراحی خود مشخص کنید. هنگامی که وایرفریم‌های تعاملی شما تایید شدند، اکنون می‌توانید سبک سیستم طراحی خود را تعیین کنید. در این مرحله، شما دستورالعمل طراحی برند، رنگ و جزییات طراحی را به اجزای ساخته شده در کتابخانه اضافه می‌کنید. این مرحله به طور کامل وایرفریم‌های شما را به یک نمونه‌ی اولیه‌ی طراحی با وضوح و جزییات بالا تبدیل می‌کند. تغییر سبک در یک جز در همه‌ی نمونه های آن اعمال میشود  بهتر است ابتدا راهنمای سبک را به ذینفعان نشان دهیم تا بازخوردی در مورد حالت و سبک طراحی قبل از نمایش همه‌ی صفحات به دست آوریم. اضافه کردن تعدادی مولفه در حضور آن‌ها می‌تواند به درکشان از چگونگی طراحی هر مولفه کمک کند. یک کتابخانه‌ی رابط کاربری پایه‌ای مرحله‌ی 4. نمونه‌ی اولیه‌ی خود را نهایی کنید. 
هنگامی که راهنمای سبک تایید شد، تنها چیزی که باقی می‌ماند، بهتر کردن نمونه‌ی اولیه است. در این مرحله می‌توانید مطمئن شوید که همه چیز در جای خود قرار دارد. ممکن است اشیایی وجود داشته باشند که اجزایی نیستند که باید طراحی شوند  یا اجزا مورد نیاز باشند. حتما نمونه‌ی اولیه را اجرا کرده و لینک‌ها را امتحان کنید تا مطمئن شوید که تمامی پیوندها به درستی کار می‌کنند. نمونه‌ی اولیه نمونه‌ی اولیه آماده است! اکنون می‌توانید یک لینک را با سهام‌دار برای گرفتن تایید نهایی به اشتراک بگذارید. سپس، این نمونه‌ی اولیه را به توسعه‌دهندگان ارسال کنید و به آن‌ها نشان دهید که چگونه می‌توانند تصاویر را در Figma بررسی و استخراج کنند. همچنین توسعه‌دهندگان می‌توانند هر گونه سوال مستقیمی که از نمونه‌ی اولیه دارند بپرسند. اضافه کردن نظر در نمونه‌‌ی اولیه شما همچنین می‌توانید یک لینک عمومی برای تست نمونه‌ی اولیه‌ی خود با دیگر کاربران به اشتراک بگذارید و یک بازخورد کلی به دست آورید. امیدوارم به کمک این ابزار بتوانید با سرعت بیشتری فرآیند طراحی را خود را پیش ببرید.

الهه انصاری

الهه انصاری

 

همه چیز درباره‌ی API

«بخش اول» API مخفف Application Programming Interface است. API یک واسط نرم افزاری است که به دو برنامه اجازه می‌دهد تا با یک دیگر صحبت کنند. هر بار که از برنامه‌ای مانند فیس بوک استفاده می‌کنید، یا یک پیام فوری ارسال می‌کنید، و یا آب و هوا را بر روی تلفن خود بررسی می‌کنید، در واقع از یک API‌کمک می‌گیرید. یک نمونه از کاربرد‌های API چیست؟ هنگامی که از یک برنامه‌ی کاربردی بر روی تلفن همراه خود استفاده می‌کنید، برنامه به اینترنت متصل می‌شود و داده‌ها را به یک سرور ارسال می‌کند. سپس سرور آن اطلاعات را بازیابی و تفسیر کرده، اقدامات لازم را انجام می‌دهد و آن را به تلفن شما ارسال می‌کند. پس از آن نرم افزار این دادهها را تفسیر می‌کند و اطلاعاتی را که می‌خواهید در یک روش قابل خواندن برای شما ارائه می‌دهد. تمام این اتفاقات توسط API انجام می‌گیرند. با یک مثال آشناتر با ما همراه باشید. تصور کنید که در یک رستوران پشت میزی با یک امنو از غذای مختلف نشسته‌اید. آشپزخانه بخشی از "سیستم" است که سفارش شما را تهیه می‌کند. موضوع مهم در این سناریو، پیوند حیاتی‌ای است که سفارش را به آشپرخانه ارسال کرده و سپس غذا را به میز شما تحویل می‌دهد. دقیقا همین جا است که پیشخدمت یا API وارد میشود که درخواست یا سفارش شما را می‌گیرد و به آشپزخانه می‌گوید سیستم باید چه کاری انجام دهد. سپس پیشخدمت پاسخ را به شما می‌فرستد؛ در این مورد، این غذا است. یک مثال دیگر از API در زندگی واقعی روند جستجوی پروازهای آنلاین آشنا است. درست مانند مثال رستوران، گزینه‌های گوناگونی برای انتخاب، از جمله شهرهای مختلف، تاریخ عزیمت و بازگشت و غیره وجود دارد. برای مثال شما قصد دارید که پروازی در یک وب سایت هواپیمایی رزرو کنید. بدین جهت یک شهر مبداء و تاریخ عزیمت، یک شهر مقصد و تاریخ بازگشت، کلاس کابین و همچنین سایر متغیرها را انتخاب می‌کنید. سپس برای رزرو پرواز خود، با وب سایت هواپیمایی ارتباط برقرار می‌کنید تا بتوانید به پایگاه داده خود دسترسی پیدا کنید و ببینید کدام صندلی در آن تاریخ وجود دارد و هزینه‌های ممکن چگونه است. در این مثال خدمات مسافرتی، با API هواپیمایی ارتباط برقرار می‌کند. API رابط کاربری است که می‌تواند توسط سرویس مسافرتی آنلاین درخواست شود تا اطلاعات پایگاه داده‌های هواپیمایی برای رزرو صندلیها و غیره دریافت شود. API همچنین یک لایه‌ی امنیتی برای ما فراهم می‌کند داده‌های تلفن شما هرگز به طور کامل در معرض سرور نیستند، و همچنین سرور هرگز به طور کامل در معرض تماس تلفن با شما نیست. در عوض، هر یک با بسته‌های کوچک داده ارتباط برقرار می‌کنند و تنها مواردی را که ضروری است نظارت می‌کنند. API ها چنان ارزشمند هستند که بخش زیادی از درآمد کسب و کار بسیاری را تشکیل می‌دهند. شرکتهای بزرگ مانند گوگل، eBay، Salesforce، Amazon و Expedia تنها تعدادی از شرکت‌هایی هستند که از API های خود پول میگیرند. این «بازار API» به قدری قوی است که می‌توان از آن به عنوان «اقتصاد API» یاد کرد. API مدرن در طول سالیان متمادی از API‌به عنوان یک رابط عمومی به برنامه یاد می‌شد. اخیرا علاوه بر این مفهموم، ویژگی‌های دیگری نیز به API تحت API مدرن اضافه شده است که بسیار ارزشمند و حایز اهمیت هستند. در زیر به برخی از این ویژگی‌ها اشاره می‌کنیم. APIهای مدرن به استانداردهایی چون HTTP و REST که توسعه دهنده پسند و به راحتی قابل دسترسی هستند، پایبند می‌باشند. آن‌ها بیشتر شبیه محصولات هستند تا کد که برای مصرف مخاطبان خاصی طراحی و مستند شده اند (به عنوان مثال، توسعه دهندگان تلفن همراه) و کاربران میتوانند انتظارات خاصی از نگهداری و چرخه زندگی آن‌ها داشته باشند. از آن جایی که بسیار استانداردتر هستند، نظم و انضباط بیشتری برای امنیت دارند و همچنین نظارت و مدیریت دقیق‌تری برای عملکرد دارند. به عنوان قطعه‌ای از نرم افزار تولید شده، API مدرن نیز دارای چرخه عمر توسعه‌ی نرم افزار (SDLC) شامل طراحی، آزمایش، ساخت، مدیریت و نسخه سازی است.  در بخش‌های بعدی بیشتر در رابطه با API‌ها صحبت خواهیم کرد، منتظر باشید.

الهه انصاری

الهه انصاری

 

اصول طراحی: تعادل

«بخش دوم» در پست ۷ گام برای تبدیل شدن به یک طراح موفق UI/UX به طور خلاصه به اصول طراحی رابطه‌ی کاربری اشاره کردیم. در این بخش قصد داریم در مورد اصل تعادل (Balance) صحبت کنیم. هر طرح با یک صفحه‌ی خالی یا فضای خالی آغاز میشود. هنگامی که یک عنصر اضافه میکنیم، قرار دادن آن میتواند تعیین کند که طراحی تا چه حد موفق خواهد بود. طراحی موثر ارتباطات و علاقه‌ی بیننده را بنا میکند؛ خواه این طراحی به صورت چاپ شده و یا به صورت صفحات وب باشد. در یک طرح وب معمولی، طراح باید لوگو، متن، عکس یا تصویر را جایگزین کند. با یک تلاش آگاهانه برای ایجاد ارتباط بین این عناصر می‌توان یک طراحی چشم نواز به وجود آورد. تعادل در طراحی بسیار شبیه به تعادل در زندگی است. نمونه ای که اغلب از تعادل در دنیای واقعی یاد می‌شود، الاکنگ است. وقتی فقط یک نفر روی آن نشسته است، تجربه‌ی بسیار سرگرم کننده‌ای نیست. تعادل زمانی حاصل میشود که دو نفر از افراد با وزن مشابه در هر طرف قرار گیرند. نمونه‌ای دیگر از تعادل را هنگامی می‌توان به دست آورد که یکی از افراد سنگین در یک طرف و دو نفر سبکتر در طرف دیگر نشسته ‍اند. اگر یک فرد سنگینتر به مرکز الاکلنگ نزدیکتر شود تعادل میتواند حاصل شود، در حالی که یک فرد سبکتر در انتهای طرف دیگر نشسته است. ما به عنوان انسان از لحاظ جسمی یک دست و پای در هر طرف ستون فقرات و سر داریم و قادر به ایستادن و حرکت با وجود اندازه و وزنهای مختلف هستیم. در طراحی سعی میکنیم به توازنی میان عناصر دست یابیم، زیرا در چشم نواز است. اما تعادل همیشه از طریق تقارن بدست نمیآید. نگاهی به جعبههای زیر کنید. خط سفید در جعبه‌ی 1 و 2 به طور متقارن متعادل است در حالی که در جعبه‌ی 3 و 4 خط به طور نامتقارن متعادل است. تقارن تعادلِ متقارن تعادلِ تصویر آینه است. اگر یک خط را از طریق مرکز صفحه بکشید، عناصر در یک طرف خط در سمت دیگر نیز به صورت آینه دیده میشوند. ما میتوانیم آن را با قرار دادن عناصر به طور نسبتا مساوی در طراحی دست یابیم. تقارن در طبیعت یک مثال معمول که در وب اتفاق میافتد، جایی است که بلوک های متن در سطر یا ستون به صورت آینه نگاشته می‌شوند. همچنین میتواند با استفاده از رنگ و تایپوگرافی به دست آید. برای مثال در وب سایت Mobile Web Book تصویر تلفن همراه این صفحه به دو بخش تقسیم می‌شود که با بلوکهای متن در هر طرف به صورت متعادل در مقابل هم قرار گرفته اند. در پوستر فیلم «The Day I Became A Woman»، بلوک متن سفید بزرگ در گوشه‌ی سمت راست بالا در گوشه‌ی پایین سمت چپ هم از لحاظ رنگ و هم از نظر شکل متقارن هستند. سایت پر طرفدار Florida Flourish تقریبا میتواند به نصف مرکز برسد که یک حس بسیار قوی از تعادلِ متقارن دارد. پوستر Havco که در زیر آورده شده است، قسمت چپ و راست پوستر با استفاده از اشکال مشابه و قطعات بدن متعادل است . متن قرمز در بالا و پایین عنوان در رنگ و اندازه‌ی متعادل قرار دارد. عدم تقارن طرح بندیهای متعادلِ نامتقارن دارای عناصری هستند که در یک خط مرکزی به صورت آینه‌ای جدا نمی‌شوند. این طرح بندی‌ها میتوانند طراحی را دشوارتر کنند، اما سبب جذابیت برای بیننده می‌شوند. میتوانیم با ایجاد چندین آیتم کوچک در یک طرف و یک آیتم بزرگ در طرف دیگر یک طرح متضاد نامتقارن ایجاد کنیم. اگر یک آیتم تیره در یک طرف دارید، میتوانید چندین آیتم روشن رنگی را در طرف دیگر قرار دهید. یک طراحی متعادلِ نامتقارن میتواند تنش ایجاد کند و بیننده را جذب کند. وب سایت MattWeb یک گرافیک بزرگ دارد که سمت چپ صفحه‌ی اصلی را پر کرده است. حس توازن نامتقارن در اینجا با استفاده از رنگهای تطبیق و یک فونت بدون سرصفحه مطابق با مارپیچ‌ها به دست می‌آید. سایت Dann Whitaker دارای چندین عنصر است که به صورت متقارن نیستند، اما از نظر رنگ، بافت و محتوا یکدیگر را متعادل میکنند.  عدم تعادل (Off-Balance) خوب، پس اگر تمام کارهای طراحی شما در تعادل باشند، خسته کننده میشود. اگر قوانین را میدانید، میتوانید آن‌ها را قطع کنید، و عدم تعادل میتواند جنبش و حرکت را به بیننده منتقل کند. البته این مسئله میتواند بیننده را به کمی ناراحت و آشفته کند. طراحی غیر متعادل میتواند مخاطب را به فکر کردن وادار کند. فقط اجازه ندهید که به طور تصادفی این اتفاق بیفتد. در مقاله‌ی آینده نگاهی به اصل مجاورت (Proximity) میکنیم. در عین حال توصیه می‌شود که در وب سایت‌های مختلف تعادل قوی، تقارن و عدم تقارن را بررسی کنید.

الهه انصاری

الهه انصاری

 

تکنولوژی REST

تکنولوژی REST (REpresentational State Transfer)، یک سبک معماری برای توسعه‌ی وب سرویس‌ها است. معماری REST به دلیل سادگی و استواری بر پایه سیستم‌های موجود و ویژگی‌های HTTP به منظور دستیابی به اهداف آن، بر خلاف ایجاد استانداردها، چارچوب‌ها و فناوری‌های جدید، محبوب است. مزایای معماری REST یکی از مزیت‌های اصلی استفاده از این معماری، هم از جنبه‌ی سرویس گیرنده و هم از جنبه‌ی سرور، تعاملات مبتنی بر REST است که برای هر فردی که با پروتکل HTTP آشنایی دارد، بسیار ساده است. برای مثال، تعاملات مبتنی بر REST وضعیت خود را با استفاده از کدهای وضعیت HTTP استاندارد اعلام می‌کنند. بنابراین، 404 به معنای «منبع درخواست شده یافت نشد»، کد 401 به معنای «درخواست مجاز نیست»، کد 200 به این معنی است که «همه چیز خوب است» و کد 500 بدان معنی است که «یک خطای نرم افزار غیر قابل برگشت در سرور وجود دارد». به طور مشابه اعمالی مانند رمزنگاری و یکپارچگی انتقال داده بدون اضافه کردن چارچوب یا تکنولوژی خاصی و صرفا با رمز نگاری SSL و TLS پیاده سازی می‌شوند. معماری REST همچنین یک معماری مستقل از زبان است. برنامه‌های مبتنی بر REST می‌توانند به کمک هر زبانی از جمله Java، Kotlin، AngularJS و یا JavaScript نوشته شوند. تا زمانی که یک زبان برنامه نویسی می‌تواند درخواست‌های مبتنی بر وب را با استفاده از HTTP انجام دهد، این زبان قادر خواهد بود که برای فراخوانی RESTful API یا وب سرویس استفاده شود. به طور مشابه، وب سرویس‌های RESTful می‌توانند با استفاده از هر زبانی نوشته شوند، بنابراین توسعه دهندگان با اجرای آن‌ها می‌توانند تکنولوژی‌هایی را انتخاب کنند که بهترین کارایی را در شرایط موجود داشته باشند. مزیت دیگر استفاده از این معماری، فراگیر بودن آن است. در سمت سرور، انواع چارچوب‌های مبتنی بر REST از جمله RESTlet و Apache CXF وجود دارد که به توسعه دهندگان برای ایجاد وب سرویس‌های RESTful کمک می‌کنند. در سمت سرویس گیرنده، تمام چارچوب‌های جدید جاوا اسکریپت، مانند JQuery، Node.js، Angular و EmberJS، همه‌ی کتابخانه‌های استاندارد در API های خود ساخته شده‌اند که وب سرویس‌های RESTful را فراخوانی کرده و از داده‌های XML یا JSON استفاده می‌کنند. معایب معماری REST مزایای استفاده از REST با استفاده از ساختارهای HTTP همچنین محدودیت‌هایی را ایجاد می‌کند. بسیاری از محدودیت‌های HTTP نیز به نقص سبک معماری REST تبدیل می‌شوند. به عنوان مثال، HTTP اطلاعات مبتنی بر وضعیت را بین چرخه‌های درخواست - پاسخ ذخیره نمی‌کند، که بدین معنی است که برنامه‌های مبتنی بر REST باید بی‌ثمر باشند و تمام وظایف مدیریت وضعیت باید توسط خود سرویس گیرنده انجام شوند. به طور مشابه، از آن جا که HTTP هیچ مکانیزمی برای ارسال اعلان‌ها از سرور به سرویس گیرنده ندارد، پیاده سازی هر نوع سرویسی که سرور، کلاینت را بدون رای‌ گیری از جانب آن (client-side polling) و یا انواع مختلف قلاب وب (web hook) به روز رسانی کند سخت است. از دیدگاه پیاده سازی، یک مشکل رایج با REST این واقعیت است که توسعه دهندگان با معنای دقیق REST-based مخالفت می‌کنند. برخی از توسعه دهندگان نرم افزار به اشتباه هر چیزی را که مبتنی بر SOAP نیست، RESTful در نظر می‌گیرند. چیزی که سبب این تصور غلط رایج می‌شود این واقعیت است که REST یک سبک معماری است، بنابراین هیچ پیاده سازی مرجع یا استاندارد قطعی وجود ندارد که تأیید کند آیا یک طراحی خاص، RESTful است یا خیر. در نتیجه، بر سر اینکه آیا یک API داده شده مطابق با اصول مبتنی بر REST است یا خیر بحث وجود دارد. جایگزین‌هایی برای REST فناوری‌های جایگزین برای ایجاد سیستم‌های مبتنی بر SOA (معماری مبتنی بر سرویس، Service-oriented architecture) و یا ایجاد API برای فراخوانی سرویس‌های میکرو از راه دور شامل XML روی HTTP (معروف به XML-RPC)، همچنین CORBA و پروتکل SOAP (پروتکل دسترسی ساده به object) است. هر تکنولوژی مجموعه‌ای از مزایا و معایب خود را دارد، اما ویژگی مهیج REST که آن را شاخص می‌کند، این است که به جای اینکه از یک توسعه دهنده بخواهد با مجموعه‌ای از پروتکل‌های سفارشی کار کند یا یک فرمت داده‌ی خاص برای تبادل پیام بین یک سرویس دهنده و یک سرور داشته باشد، REST باور دارد که بهترین راه برای پیاده سازی یک سرویس وب مبتنی بر شبکه این است که به راحتی از ساختار اصلی پروتکل شبکه‌ی خود استفاده کند که در مورد اینترنت، HTTP است. این یک نکته مهم است، زیرا REST فقط برای اعمال به اینترنت در نظر گرفته نشده است؛ بلکه هدف آن است که اصول آن به تمام پروتکل‌ها از جمله WEBDAV، FTP و غیره اعمال شود. REST در مقابل SOAP دو سبک رقیب برای اجرای خدمات وب REST و SOAP است. تفاوت اساسی بین این دو، رویکرد فلسفی است که باید به فراخوانی از راه دور بپردازند.  REST یک رویکرد مبتنی بر منابع را برای تعاملات مبتنی بر وب اتخاذ می‌کند. با REST، شما یک منبع را بر روی سرور قرار می‌دهید و انتخاب می‌کنید که این منبع را به روزرسانی کنید، پاک کنید یا اطلاعاتی را در مورد آن دریافت کنید. در SOAP، کلاینت تصمیم نمی‌گیرد به طور مستقیم با یک منبع ارتباط برقرار کند، بلکه به جای آن یک سرویس را فراخوانی می‌کند و این سرویس دسترسی به اشیا و منابع مختلف پشت صحنه را کاهش میدهد. SOAP همچنین تعداد زیادی از چارچوبها و APIها را در بالای لایه‌ی پروتکل HTTP را ایجاد کرده است، از جمله زبان توصیف سرویس وب (Web Services Description Language, WSDL)، که ساختار داده‌هایی را که بین کلاینت و سرور رد و بدل می‌شوند، تعریف می‌کند. گاهی بهترین نتیجه با تعریف دقیق فرمت پیام حاصل می‌شود و یا میتوان از APIهای مرتبط با SOAP مانند WS-Eventing، WS-Notification و WS-Security بهره برد. در بعضی مواقع شرایطی پیش می‌آید که HTTP نمی‌تواند سطح کارایی را که یک برنامه ممکن است نیاز داشته باشد، فراهم کند. در این موارد، استفاده از SOAP ترجیح داده میشود. REST URIها و URLها اکثر مردم با شیوه‌ی عملکرد URLها (Uniform Resource Locator) و URIها (Uniform Resource Identifier) در وب آشنا هستند. رویکرد RESTful برای برنامههای کاربردی ادعا میکند که درخواست اطلاعات در مورد یک منبع باید به اندازه‌ی فراخوانی URL آن ساده باشد. به عنوان مثال، اگر یک کلاینت بخواهد یک سرویس وب را که تمام آزمونها را در TechTarget در دسترس قرار داده است، به URL مراجعه کند. URLای که به سرویس وب خواهد رسید بدین ترتیب است: www.techtarget.com/restfulapi/quizzes هنگام فراخوانی، سرویس وب ممکن است با رشته JSON زیر، لیست تمام آزمون‌های موجود را پاسخ دهد که یکی از آن‌ها درباره‌ی DevOps است: { "quizzes" : [ "Java", "DevOps", "IoT"] } برای دریافت آزمون DevOps، سرویس وب ممکن است با استفاده از URL زیر فراخوانی شود: www.techtarget.com/restfulapi/quizzes/DevOps     با فراخوانی این URL یک رشته‌ی JSON که لیستی از سوالات در آزمون DevOps را فهرست کرده است، بازگردانده می‌شود. برای دریافت یک سوال مشخص از آزمون، شماره‌ی سوال به URL اضافه خواهد شد. بنابراین، برای دریافت سوال سوم در آزمون، URL RESTful زیر استفاده می‌شود: www.techtarget.com/restfulapi/quizzes/DevOps/3 فراخوانی این URL ممکن است یک رشته‌ی JSON مانند زیر را برگرداند: { "Question" : {"query":"What is your DevOps role?", "optionA":"Dev", "optionB":"Ops"} } همان طور که می‌بینید، URLهای REST در این مثال به گونهای منطقی و معنی دار هستند که منابع دقیق درخواست شده را مشخص می‌کنند. فرمتهای داده‌ی JSON و XML REST مثال بالا نشان میدهد JSON به عنوان فرمت تبادل اطلاعات برای تعامل RESTful استفاده می‌شود. رایج ترین فرمت تبادل دادهها JSON و XML هستند و بسیاری از خدمات وب RESTful میتوانند تا زمانی که کلاینت بتواند تعامل را در XML یا JSON انجام دهد، از هر دو فرمت به طور متناوب استفاده کنند. توجه داشته باشید با وجود اینکه JSON و XML فرمتهای رایج تبادل داده هستند، خود REST هیچگونه محدودیتی در مورد آنچه که فرمت باید باشد قرار نمیدهد. در واقع، برخی از خدمات وب RESTful به منظور بهره وری، دادههای باینری را مبادله می‌کنند. این یکی دیگر از مزایای کار با خدمات وب مبتنی بر REST است، زیرا معمار نرم افزار از نظر نحوه‌ی اجرای بهترین خدمات، از آزادی زیادی برخوردار است. REST و رویه‌های HTTP مثال بالا فقط دسترسی به داده‌ها را بررسی می‌کند. عملیات پیش فرض HTTP، رویه‌ی GET است که در هنگام دریافت داده‌ها از سرور مورد استفاده قرار می‌گیرد. با این حال، HTTP تعدادی از رویه‌های دیگر از جمله PUT، POST و DELETE را تعریف میکند.REST ادعا می‌کند که برای حذف داده‌ای در سرور، به سادگی از URL برای دسترسی به منبع استفاده کنید و روش DELETE از HTTP را اعمال کنید. برای ذخیره‌ی داده‌ها در سرور، یک URL و رویه‌ی PUT استفاده میشود. همچنین برای عملیاتی که فراتر از ذخیره سازی، خواندن و یا حذف اطلاعات هستند، می توان از روش POST استفاده کرد. تاریخچه‌ی REST REST برای اولین بار توسط دانشمند علم کامپیوتر Roy Fielding در طول انجام پایان‌ نامه‌ی تحصیلات دوره‌ی دکترای وی در دانشگاه کالیفرنیا با عنوان «سبک‌های معماری و طراحی معماری نرم افزار مبتنی بر شبکه» ابداع شد. فصل 5 پایان نامه ادعاهای Fielding در مورد چگونگی بهینه سازی معماری سیستمهای توزیعی hypermedia را توصیف می‌کند. وی تعدادی از شرایط مرزی را توصیف می‌کند که سیستم‌های مبتنی بر REST باید چگونه رفتار کنند. این شرایط به عنوان محدودیت‌های REST یاد می‌شوند. چهار مورد از محدودیت‌های کلیدی در زیر شرح داده شده اند: استفاده از رابط کاربری یکنواخت (Uniform Interface, UI): همانطور که قبلا ذکر شد، منابع در سیستم‌های مبتنی بر REST باید از طریق یک URL قابل شناسایی باشند و تنها با استفاده از روشهایی مانند DELETE، PUT و GET در HTTP با منبع در تعامل باشند. سیستم‌های مبتنی بر رابطه‌ی کلاینت، سروری: در سیستم‌های مبتنی بر REST، باید تعریف مشخصی از کلاینت و سرور داشته باشیم. UI و نگرانی‌های حاصل از درخواست‌ها، در حوزه‌ی کلاینت هستند. در همین حال، دسترسی به داده‌ها، مدیریت بار کاری و امنیت، در دامنه‌ی سرور است. این جداسازی‌ها اتصال بین کلاینت و سرور را برقرار می‌کند و هر کدام میتوانند مستقل از دیگری توسعه یابند. عملیات مجزا (Stateless operations): تمام عملیات بین کلاینت و سرور باید مجزا و مستقل از هم باشند و هر مدیریت حالتی (State) که مورد نیاز است نه بر روی سرور، بلکه باید بر روی کلاینت پیاده سازی شود. کَش کردن منابع RESTful: توانایی کَش کردن منابع بین فراخوانی‌های انجام شده توسط کلاینت نسبت به کاهش تاخیر و بهبود عملکرد اولویت بالاتری دارد. علاوه بر این تمامی منابع باید اجازه ی کَش کردن را داشته باشند، مگر اینکه یک نشانه‌ی صریح برای عدم امکان انجام این عمل یافت شود. توسعه‌ی APIهای REST‌ در جاوا در راستای محبوبیت رو به رشد سیستمهای مبتنی بر REST، تعدادی از چارچوبها برای کمک به توسعه دهندگان در ایجاد خدمات وب RESTful به وجود آمده اند. برخی از چارچوب‌های منبع باز محبوب برای ایجاد سرویسهای وب مبتنی بر جاوا عبارتند از Apache CXF، Jersey، Restlet، Apache Wink، Spring Data و JBoss' RESTeasy. رویکرد کلی هر یک از این چارچوبها این است که به توسعه دهندگان کمک کنند تا خدمات وب RESTful خود را با استفاده از الگوهای معنایی جاوا که با آن آشنا هستند، از جمله Java Platform (نسخه سازمانی)، Servlet API بسازند، در عین حال که کلاس‌های از پیش آماده و روش‌هایی به آن‌ها ارائه‌ می‌شوند تا با شروط اساسی REST بیشترین مطابقت را داشته باشند.   پی‌نوشت: مطلبی تحت عنوان فریم ورک REST‌ در زبان سی پلاس پلاس نیز به طور مجزا به این مقاله اضافه خواهد شد. 
×