اگر با چالش استخدام برنامهنویس روبهرو هستید و علاقهمندید تجربه و نکات دیگران رو در این خصوص داشته باشید پیشنهاد میکنم مقاله مفیدِ دوست خوبم حامد تکمیل رو در وبلاگش مطالعه کنید. حامد توی این مقاله با زبانی خودمانی مستقیم رفته سر اصل مطلب و به نکات خوبی اشاره کرده که برخی از اونها رو در ادامه آوردم:
«تاکید میکنم، نیروی خوبی که شما دنبالش هستی بیکار نیست. اگرم بیکار باشه باید دلش رو بدست بیاری.»
«اگر قصد شروع یک کسب و کار یا پیگیری امورات یک استارت آپ رو دارید و دنبال نیرو هستید باید خودتون رو جای اون نیرو بذارید. اون شخص مثل شما فکر نمی کنه. پس وعده هایی که شما بهش می دین براش باور پذیر یا با اهمیت نیست. سعی نکنید خودتون رو بزرگتر از چیزی که هستید نشون بدید.»
«وقتی آگهی بلند بالا با اون همه تخصص میزنی، نیرو می ترسه، فرار می کنه.»
«وقتی برنامه و روال درستی برای استخدام نداشته باشید، این کارجوی حرفه ای هست که از همون ابتدا متوجه ضعف شما میشه و شما در گام اول تصویر نامطلوبی از خودتون در ذهن کارجو بر جا میذارین.»
☕️ @airaniTips
«تاکید میکنم، نیروی خوبی که شما دنبالش هستی بیکار نیست. اگرم بیکار باشه باید دلش رو بدست بیاری.»
«اگر قصد شروع یک کسب و کار یا پیگیری امورات یک استارت آپ رو دارید و دنبال نیرو هستید باید خودتون رو جای اون نیرو بذارید. اون شخص مثل شما فکر نمی کنه. پس وعده هایی که شما بهش می دین براش باور پذیر یا با اهمیت نیست. سعی نکنید خودتون رو بزرگتر از چیزی که هستید نشون بدید.»
«وقتی آگهی بلند بالا با اون همه تخصص میزنی، نیرو می ترسه، فرار می کنه.»
«وقتی برنامه و روال درستی برای استخدام نداشته باشید، این کارجوی حرفه ای هست که از همون ابتدا متوجه ضعف شما میشه و شما در گام اول تصویر نامطلوبی از خودتون در ذهن کارجو بر جا میذارین.»
☕️ @airaniTips
آشنایی با حملات جعل درخواست بین سایتی (CSRF یا XSRF) و روش های پیشگیری از آن (مقاله)
💬 در این مقاله توضیحات خوبی راجع به حملات CSRF یا XSRF داده شده و اگر هنوز با این نوع از حملات آشنایی ندارید مطالعه این مقاله کوتاه برای شما مفید خواهد بود.
☕️ @airaniTips
💬 در این مقاله توضیحات خوبی راجع به حملات CSRF یا XSRF داده شده و اگر هنوز با این نوع از حملات آشنایی ندارید مطالعه این مقاله کوتاه برای شما مفید خواهد بود.
☕️ @airaniTips
9px.ir
پیشگیری از حملات جعل درخواست بین سایتی - برنامه نویسی و طراحی وب سایت
حملات ساده و در عین حال قدرتمند csrf یکی از مشکلات cms های متداول است...
۲۲ قسمت ویدئو رایگان دوره آموزشی مقدمه ای بر ReactJS و Redux
در بین کتابخانههای موجود برای ساخت رابطهای کاربری، Reactjs به عنوان یک نمونه متن باز از نوع جاوا اسکریپت دیده میشود. این کتابخانه هم اکنون توسط برندهایی همانند فیسبوک، اینستاگرام و سایر فعالان جامعه کاربری در حال توسعه و نگهداری است و در این میان هم وب سایتهای زیادی مانند Airbnb، Imgur و Netflix در حال استفاده از ReactJS هستند.
💬 اگر جزو فعالین و علاقهمندان به توسعه وب سمت فرانتاند هستید و هنوز ReactJs رو شروع نکردید و علاقهمند هستید کار با این کتابخانه قدرتمند جاوا اسکریپتی رو شروع کنید پیشنهاد میکنم این دوره رایگان ویدئویی که توسط آقای احمد طحانی تهیه شده رو مشاهده کنید.
☕️ @airaniTips
در بین کتابخانههای موجود برای ساخت رابطهای کاربری، Reactjs به عنوان یک نمونه متن باز از نوع جاوا اسکریپت دیده میشود. این کتابخانه هم اکنون توسط برندهایی همانند فیسبوک، اینستاگرام و سایر فعالان جامعه کاربری در حال توسعه و نگهداری است و در این میان هم وب سایتهای زیادی مانند Airbnb، Imgur و Netflix در حال استفاده از ReactJS هستند.
💬 اگر جزو فعالین و علاقهمندان به توسعه وب سمت فرانتاند هستید و هنوز ReactJs رو شروع نکردید و علاقهمند هستید کار با این کتابخانه قدرتمند جاوا اسکریپتی رو شروع کنید پیشنهاد میکنم این دوره رایگان ویدئویی که توسط آقای احمد طحانی تهیه شده رو مشاهده کنید.
☕️ @airaniTips
💬 از git gc برای حذف فایل های غیر ضروری و فشرده سازی فایل های مخزن git استفاده میشه (توییت مرتبط)
☕️ @airaniTips
☕️ @airaniTips
Twitter
Saeed Rasooli
خیلی حال میده وقتی حجم دایرکتوری گیت با یه git gc زدن یک چهارم میشه :)))
پروتکل HTTP/2 چیست و چه تفاوتهایی با HTTP/1 دارد؟
💬 اگر هنوز درباره تغییرات HTTP/2 مطالعه نکردید پیشنهاد میکنم این مقاله مختصر و مفید رو مطالعه کنید. https://goo.gl/3sNNM5
☕️ @airaniTips
💬 اگر هنوز درباره تغییرات HTTP/2 مطالعه نکردید پیشنهاد میکنم این مقاله مختصر و مفید رو مطالعه کنید. https://goo.gl/3sNNM5
☕️ @airaniTips
Sokanacademy
HTTP/2 چیست و چه تفاوتهایی با HTTP/1 دارا است؟
HTTP/2 آخرین مرحله تکاملی پروتکل انتقال ابر متن است (HTTP). HTTP پروتکل شبکهای است که کاربرد آن درخواست و دریافت صفحهها و دادهها در شبکه جهانی وب است. در نهایت این تکنولوژی جدید جایگزین HTTP/1.1 می شود. از استاندارد شدن HTTP/1.1 بیش از دو دهه میگذرد.
انجام کارها به روش انسان غارنشین
ما همیشه سعی میکنیم شروع کارها رو تا جایی که میشه عقب بندازیم. یه دقیقه بعد، یه ساعت بعد، تا رند شدن ساعت روی عدد ۱۲، تا بعد از خوردن چاییای که تازه دم کردیم… تا اینکه متوجه میشیم که خورشید داره غروب میکنه و برای ادامهی کار کمکم باید چراغها رو روشن کنیم. کمکم شب به نیمههاش میرسه و ما با امید اینکه فردا روز دیگهای هست و دیگه فردا کارا رو انجام میدیم، چشمامون رو روی هم میذاریم.
ما استاد عقب انداختن کارها هستیم. نیرویی در درون ماست که به صورت نرمال نمیذاره کاری رو شروع کنیم. فقط اگه در دوران غارنشینی دو سه روز بیشتر این نیرو به شما غلبه میکرد، احتمالاً هم خودتون و هم خانوادهتون از بین میرفتن. شاید در دوران ما اینکه کاری رو پیش نمیبریم و تاثیری در اطرافمون نمیذارین و روزها رو طلف میکنیم، تعریفِ جدیدی از مرگ باشه. گو اینکه گاهی وقتها هم پیش نرفتن کارها می تونه برابر باشه با گشنه موندن عدهای که اونها رو حمایت میکنیم.
همسرمون یا همکارمون یه کار دیگه ازمون میخواد و ما به بهونه انجام اون کار از زیر بار انجام کاری که اولویت داشت خودمون رو رها میکنیم. حاضر هستیم هر کار ریز و درشت و گاهی بیخودی رو بکنیم جز انجام کاری که با فکرش صبح از خواب بیدار شدیم.
💬 متنی که در بالا مطالعه کردید بخشی از یک مقاله به قلم آقای آرش میلانی بود که میتوانید متن کامل رو در وبلاگ شخصی ایشون مطالعه کنید. https://goo.gl/8F34Xl
☕️ @airaniTips
ما همیشه سعی میکنیم شروع کارها رو تا جایی که میشه عقب بندازیم. یه دقیقه بعد، یه ساعت بعد، تا رند شدن ساعت روی عدد ۱۲، تا بعد از خوردن چاییای که تازه دم کردیم… تا اینکه متوجه میشیم که خورشید داره غروب میکنه و برای ادامهی کار کمکم باید چراغها رو روشن کنیم. کمکم شب به نیمههاش میرسه و ما با امید اینکه فردا روز دیگهای هست و دیگه فردا کارا رو انجام میدیم، چشمامون رو روی هم میذاریم.
ما استاد عقب انداختن کارها هستیم. نیرویی در درون ماست که به صورت نرمال نمیذاره کاری رو شروع کنیم. فقط اگه در دوران غارنشینی دو سه روز بیشتر این نیرو به شما غلبه میکرد، احتمالاً هم خودتون و هم خانوادهتون از بین میرفتن. شاید در دوران ما اینکه کاری رو پیش نمیبریم و تاثیری در اطرافمون نمیذارین و روزها رو طلف میکنیم، تعریفِ جدیدی از مرگ باشه. گو اینکه گاهی وقتها هم پیش نرفتن کارها می تونه برابر باشه با گشنه موندن عدهای که اونها رو حمایت میکنیم.
همسرمون یا همکارمون یه کار دیگه ازمون میخواد و ما به بهونه انجام اون کار از زیر بار انجام کاری که اولویت داشت خودمون رو رها میکنیم. حاضر هستیم هر کار ریز و درشت و گاهی بیخودی رو بکنیم جز انجام کاری که با فکرش صبح از خواب بیدار شدیم.
💬 متنی که در بالا مطالعه کردید بخشی از یک مقاله به قلم آقای آرش میلانی بود که میتوانید متن کامل رو در وبلاگ شخصی ایشون مطالعه کنید. https://goo.gl/8F34Xl
☕️ @airaniTips
نقشه راه دولوپر شدن در سال 2017
💬 اینجا در ادامه تصویر زیر چند تا اینفوگرافیک دیگه هست که در واقع ادامه ۳ نقطه های تصویر زیره و به صورت اینفوگرافی خیلی ساده و زیبا ملزومات وب دولوپر شدن در سال ۲۰۱۷ رو در هر کدوم از شاخه های Backend, Frontend, DevOps نشون داده. پیشنهاد میکنم از دست ندین
☕️ @airaniTips
💬 اینجا در ادامه تصویر زیر چند تا اینفوگرافیک دیگه هست که در واقع ادامه ۳ نقطه های تصویر زیره و به صورت اینفوگرافی خیلی ساده و زیبا ملزومات وب دولوپر شدن در سال ۲۰۱۷ رو در هر کدوم از شاخه های Backend, Frontend, DevOps نشون داده. پیشنهاد میکنم از دست ندین
☕️ @airaniTips
Forwarded from فلسفه دیزاین
همه دیزاینر هستند!
با این موضوع کنار بیایید
امروز به مقالهای برخوردم که با تمام وجود حسش کرده بودم. برای همین میخوام مطلب امروز رو با گفتن مقدمهای از تجربه شخصی خودم شروع کنم.
حدود یکسال از ورود من به شرکتی که الان هستم میگذره. وقتی تیم دیزاین اینجا رو تشکیل دادم، متوجه شدم جدای از زمانی که باید برای آموزش بچههای تیم دیزاین اختصاص بدم، نتیجه پیادهسازی شده اپلیکیشنهایی که دیزاین کردیم، اصلا کیفیت بالایی نداره و به جزئیات دیزاین توجه نشده. این موضوع باعث شده بود کار تیم دیزاین در بررسی کردن اپلیکیشنها در هر مرحله بسیار سخت و طاقتفرسا بشه.
بعد از کلی فکر کردن به این نتیجه رسیدم که جای اینکه تمام مهارتهای دیزاین رو در تیم دیزاین جمع کنیم و در نتیجه تمام تصمیمگیریهای مربوط به اون رو هم در این تیم متمرکز کنیم، بهتره به طریقی دیزاین رو به همه اعضای شرکت یاد بدیم.
اینطوری تیم Backend متوجه میشد کارشون به چه نحوی در اپلیکیشن و تجربه کاربر تاثیر داره، تیمهای توسعه اپلیکیشنها متوجه میشدن چه بخشهایی برای کاربر مهم هست و باید زمان بیشتری بهشون اختصاص داده بشه و از همه مهمتر، کارهای تیم دیزاین فشردگی کمتری پیدا میکرد و میتونستن زمان بیشتری روی ایدههای جدید بذارن.
بعد از کمی فکر، راه حل رو پیدا کردم! جلساتی رو با نام App Review Session شروع کردم و هر هفته اپلیکیشنی ایرانی رو به همه معرفی کرده و ازشون میخواستم روز چهارشنبه ساعت ۴ تا ۵ جمع بشیم و از تجربه کارمون با اون اپلیکیشن بگیم.
خلاصه اینکه امروز بیست و سومین جلسه App Review ما برگزار میشه و نظرات بسیار بسیار تخصصیتر شده و همه یک «دیزاینر درون» پیدا کردن.
برسیم به مقاله امروز از یکی از اعضای Google Ventures هست که به نحوی همین موضوع رو مطرح میکنه و برای من بسیار جذاب و جالب بود راهی رو که ما در شرکت پیش گرفتیم پیشنهاد میده.
توی این مقاله آقای Daniel Burka درباره این میگه که تمامی آدمهایی که در شکلگیری یک محصول تاثیر دارند، دیزاینرهای اون محصول هستند. مدیرعامل یا مدیر مارکتینگی که قیمتهای اشتراک ماهیانه و سالیانه محصول رو مشخص میکنه، برنامهنویسی که بین چند راه ممکن برای پیادهسازی باید انتخاب کنه و دیزاینری که بخشهای مختلف محصول رو دیزاین میکنه، همه و همه در تجربهکاربری محصول تاثیر دارند پس دیزاینرهای اون محصول هستند.
این موضوع یه واقعیت هست، چه دیزاینرها خوششون بیاد چه نه. پس بهتره جای متمرکز و ایزوله کردن دیزاین در تیم دیزاین، همه رو در اون درگیر کنیم.
پیشنهاد میکنم باقی مطلب بینظیر ایشون رو از زبان خودش بخونید و ازش لذت ببرید.
https://library.gv.com/everyone-is-a-designer-get-over-it-501cc9a2f434
(زمان حدودی مطالعه، ۸ دقیقه)
#تجربه_کاربری #تیم #طراحی_محصول
@Dexign دیزاین
___
با این موضوع کنار بیایید
امروز به مقالهای برخوردم که با تمام وجود حسش کرده بودم. برای همین میخوام مطلب امروز رو با گفتن مقدمهای از تجربه شخصی خودم شروع کنم.
حدود یکسال از ورود من به شرکتی که الان هستم میگذره. وقتی تیم دیزاین اینجا رو تشکیل دادم، متوجه شدم جدای از زمانی که باید برای آموزش بچههای تیم دیزاین اختصاص بدم، نتیجه پیادهسازی شده اپلیکیشنهایی که دیزاین کردیم، اصلا کیفیت بالایی نداره و به جزئیات دیزاین توجه نشده. این موضوع باعث شده بود کار تیم دیزاین در بررسی کردن اپلیکیشنها در هر مرحله بسیار سخت و طاقتفرسا بشه.
بعد از کلی فکر کردن به این نتیجه رسیدم که جای اینکه تمام مهارتهای دیزاین رو در تیم دیزاین جمع کنیم و در نتیجه تمام تصمیمگیریهای مربوط به اون رو هم در این تیم متمرکز کنیم، بهتره به طریقی دیزاین رو به همه اعضای شرکت یاد بدیم.
اینطوری تیم Backend متوجه میشد کارشون به چه نحوی در اپلیکیشن و تجربه کاربر تاثیر داره، تیمهای توسعه اپلیکیشنها متوجه میشدن چه بخشهایی برای کاربر مهم هست و باید زمان بیشتری بهشون اختصاص داده بشه و از همه مهمتر، کارهای تیم دیزاین فشردگی کمتری پیدا میکرد و میتونستن زمان بیشتری روی ایدههای جدید بذارن.
بعد از کمی فکر، راه حل رو پیدا کردم! جلساتی رو با نام App Review Session شروع کردم و هر هفته اپلیکیشنی ایرانی رو به همه معرفی کرده و ازشون میخواستم روز چهارشنبه ساعت ۴ تا ۵ جمع بشیم و از تجربه کارمون با اون اپلیکیشن بگیم.
خلاصه اینکه امروز بیست و سومین جلسه App Review ما برگزار میشه و نظرات بسیار بسیار تخصصیتر شده و همه یک «دیزاینر درون» پیدا کردن.
برسیم به مقاله امروز از یکی از اعضای Google Ventures هست که به نحوی همین موضوع رو مطرح میکنه و برای من بسیار جذاب و جالب بود راهی رو که ما در شرکت پیش گرفتیم پیشنهاد میده.
توی این مقاله آقای Daniel Burka درباره این میگه که تمامی آدمهایی که در شکلگیری یک محصول تاثیر دارند، دیزاینرهای اون محصول هستند. مدیرعامل یا مدیر مارکتینگی که قیمتهای اشتراک ماهیانه و سالیانه محصول رو مشخص میکنه، برنامهنویسی که بین چند راه ممکن برای پیادهسازی باید انتخاب کنه و دیزاینری که بخشهای مختلف محصول رو دیزاین میکنه، همه و همه در تجربهکاربری محصول تاثیر دارند پس دیزاینرهای اون محصول هستند.
این موضوع یه واقعیت هست، چه دیزاینرها خوششون بیاد چه نه. پس بهتره جای متمرکز و ایزوله کردن دیزاین در تیم دیزاین، همه رو در اون درگیر کنیم.
پیشنهاد میکنم باقی مطلب بینظیر ایشون رو از زبان خودش بخونید و ازش لذت ببرید.
https://library.gv.com/everyone-is-a-designer-get-over-it-501cc9a2f434
(زمان حدودی مطالعه، ۸ دقیقه)
#تجربه_کاربری #تیم #طراحی_محصول
@Dexign دیزاین
___
Medium
Everyone is a designer. Get over it.
Whether you like it or not, people outside of your design team are making significant design choices.
معرفی Prepack: ابزاری جهت اجرای سریعتر کدهای جاوااسکریپت
💬 ابزار جاوااسکریپتی جدیدی به نام Prepack به تازگی توسط فیسبوک جهت بهینه سازی و افزایش سرعت اجرای کدهای جاوااسکریپت معرفی شده. اینجا میتونید مقاله ای که در سایت سکان آکادمی درباره این ابزار جدید منتشر شده رو مطالعه کنید.
☕️ @airaniTips
💬 ابزار جاوااسکریپتی جدیدی به نام Prepack به تازگی توسط فیسبوک جهت بهینه سازی و افزایش سرعت اجرای کدهای جاوااسکریپت معرفی شده. اینجا میتونید مقاله ای که در سایت سکان آکادمی درباره این ابزار جدید منتشر شده رو مطالعه کنید.
☕️ @airaniTips
۳۵ عادت بد برنامهنویسان که باید ترکشان کنیم
💬 مقاله متفاوت و جالبی بود که اینجا میتونید ترجمه اش رو بخونید، پیشنهاد میکنم حداقل یک دور تیتر همه موارد رو نگاه کنید. دروغ چرا یه بخشی از این موارد شامل حال خودم هم میشه و باید سعی کنم تغییرشون بدم.
☕️ @airaniTips
💬 مقاله متفاوت و جالبی بود که اینجا میتونید ترجمه اش رو بخونید، پیشنهاد میکنم حداقل یک دور تیتر همه موارد رو نگاه کنید. دروغ چرا یه بخشی از این موارد شامل حال خودم هم میشه و باید سعی کنم تغییرشون بدم.
☕️ @airaniTips
Sokanacademy
۳۵ عادت بَد برنامهنویسی که هرچه زودتر باید ترکشان کنید!
در این مقاله با ۳۵ عادت بَد برنامهنویسی آشنا میشوید که به منظور موفقیت در این حوزه، میبایست هرچه زودتر ترکشان کنید!
قانون YAGNI برای ما ها یعنی تا زمانی که بهش احتیاج پیدا نکردی کدش رو ننویس
به عبارت دیگه: منابعت رو برای چیزی که «ممکنه» بهش احتیاج پیدا کنی هدر نده
☕️ @airaniTips
به عبارت دیگه: منابعت رو برای چیزی که «ممکنه» بهش احتیاج پیدا کنی هدر نده
☕️ @airaniTips
برای دولوپرها: حواستان باشد که در دام این ۱۴ اشتباه نیفتید!
۱. بهجای اینکه کد بزنید، فقط مشغول مطالعه در مورد کدنویسی هستید
۲. جوری کدنویسی را یاد میگیرید که گویا قرار است امتحان بدهید
۳. با بررسی نکردن عملکرد کدهای خود، کوهی از مشکلات را روی هم تلنبار میکنید
۴. سعی دارید در انزوا کدنویسی را یاد بگیرید
۵. خیلی زود از کوره در میروید
۶. فکر میکنید برای اینکه کدنویسی یاد بگیرید نیاز به امکانات خاصی دارید
۷. تفاوت میان حروف بزرگ و کوچک را نادیده میگیرید
۸. با روش نادرستی درخواست کمک میکنید
۹. فکر میکنید برای موفقیت در برنامهنویسی حتماً باید نابغهٔ ریاضیات باشید
۱۰. از تغییر دادن کدهای بد خود رویگردان هستید
۱۱. فقط به تایپ کردن کدها فکر میکنید
۱۲. میخواهید همهچیز را به یکباره بیاموزید
۱۳. انتظار دارید روزی برسد که همهچیز را در مورد برنامهنویسی بدانید
۱۴. زود ناامید میشوید و به راه خود ادامه نمیدهید
💬 اگر علاقه داشتید تا شرح موارد بالا رو مطالعه کنید این مقاله رو مطالعه کنید.
https://sokanacademy.com/blog/2103/post
☕️ @airaniTips
۱. بهجای اینکه کد بزنید، فقط مشغول مطالعه در مورد کدنویسی هستید
۲. جوری کدنویسی را یاد میگیرید که گویا قرار است امتحان بدهید
۳. با بررسی نکردن عملکرد کدهای خود، کوهی از مشکلات را روی هم تلنبار میکنید
۴. سعی دارید در انزوا کدنویسی را یاد بگیرید
۵. خیلی زود از کوره در میروید
۶. فکر میکنید برای اینکه کدنویسی یاد بگیرید نیاز به امکانات خاصی دارید
۷. تفاوت میان حروف بزرگ و کوچک را نادیده میگیرید
۸. با روش نادرستی درخواست کمک میکنید
۹. فکر میکنید برای موفقیت در برنامهنویسی حتماً باید نابغهٔ ریاضیات باشید
۱۰. از تغییر دادن کدهای بد خود رویگردان هستید
۱۱. فقط به تایپ کردن کدها فکر میکنید
۱۲. میخواهید همهچیز را به یکباره بیاموزید
۱۳. انتظار دارید روزی برسد که همهچیز را در مورد برنامهنویسی بدانید
۱۴. زود ناامید میشوید و به راه خود ادامه نمیدهید
💬 اگر علاقه داشتید تا شرح موارد بالا رو مطالعه کنید این مقاله رو مطالعه کنید.
https://sokanacademy.com/blog/2103/post
☕️ @airaniTips
Sokanacademy
دولوپرهای تازهکار حواسشان باشد که در دام این ۱۴ اشتباه نیفتند!
هنگامی که به یادگیری کدنویسی مشغول میشوید، چد اشتباه بسیار رایج وجود دارند که باید حواستان به آنها باشد که در غیر این صورت پیشرفت شما بسیار کند خواهد شد که در این مقاله به چند مورد از رایجترین آنها اشاره خواهیم کرد.
تجربه من از کار با Dropbox Paper
الآن حدودا چند ماهی میشه که یادداشت ها و مستنداتم رو روی دراپ باکس پیپر مینویسم دیگه، بعد از تست کردن تقریبا بیشتر ابزارهای معروف مثل گوگل داکز، Evernote و گوگل کیپ و Onenote و … توی دوره های مختلف.
دراپ باکس برای من جذابیت زیاد داره اول از همه چون زیبا و چشم نوازه در عین اینکه سادگی جذابی هم داره یعنی الکی شلوغ نیست، المان های اضافه توی صفحه نگاهت رو منحرف نمیکنه و انگار واقعا با یه کاغذ طرفی و سادگی یه کاغذ سفید رو خیلی خوب بهت منتقل میکنه، دوم تجربه کاربری یا همون UX قدرتمندی داره یعنی در عین اینکه صفحه خیلی خالی به نظر میرسه اما امکاناتی که یک ویرایشگر متن باید داشته باشه رو خیلی به جا در اختیار تون قرار میده و سادگیش باعث نشده یک ویرایشگر خوب نباشه، سوم اینکه با زبان فارسی و کلا زبان های راست به چپ خیلی خوب سازگار میشه یعنی همین که شروع به نوشتن میکنید همه چیز راست به چپ میشه، چهارم اینکه قدرتمنده یعنی علاوه بر قدرتی که توی UX داره از بقیه ابزارهای مشابه معروف چیزی کم نداره و شاید از مهمترین هاش امکان اشتراک گذاری و مشارکت افراد دیگه در متن مثل نوشتن نظر و یا ویرایش باشه و امکانات خوبی در ساماندهی و دسته بندی مستندات داره و یا امکان بررسی تاریخچه تغییرات نوشته رو داره، مورد آخری که الآن به ذهنم میرسه اینکه app خوب و سبکی به خوبی app وب برای اندروید و iOs داره که paper رو بیشتر در دسترس نگه میداره مثلا من خیلی یادداشت هام رو توی مترو یا مهمونی نوشتم.
دراپ باکس پیپر خیلی نکات مثبت دیگه هم داره که من نگفتم و بقیه چیز های خوبش رو خودتون برید امتحان کنید و لذتش رو ببرید.
پ.ن: بالاخره بعد از مدت ها به بهانه این یادداشت وبلاگم رو هم بهروز کردم 😊
http://p30design.net/1396/04/dropbox-paper-experiance.html
☕️ @airaniTips
الآن حدودا چند ماهی میشه که یادداشت ها و مستنداتم رو روی دراپ باکس پیپر مینویسم دیگه، بعد از تست کردن تقریبا بیشتر ابزارهای معروف مثل گوگل داکز، Evernote و گوگل کیپ و Onenote و … توی دوره های مختلف.
دراپ باکس برای من جذابیت زیاد داره اول از همه چون زیبا و چشم نوازه در عین اینکه سادگی جذابی هم داره یعنی الکی شلوغ نیست، المان های اضافه توی صفحه نگاهت رو منحرف نمیکنه و انگار واقعا با یه کاغذ طرفی و سادگی یه کاغذ سفید رو خیلی خوب بهت منتقل میکنه، دوم تجربه کاربری یا همون UX قدرتمندی داره یعنی در عین اینکه صفحه خیلی خالی به نظر میرسه اما امکاناتی که یک ویرایشگر متن باید داشته باشه رو خیلی به جا در اختیار تون قرار میده و سادگیش باعث نشده یک ویرایشگر خوب نباشه، سوم اینکه با زبان فارسی و کلا زبان های راست به چپ خیلی خوب سازگار میشه یعنی همین که شروع به نوشتن میکنید همه چیز راست به چپ میشه، چهارم اینکه قدرتمنده یعنی علاوه بر قدرتی که توی UX داره از بقیه ابزارهای مشابه معروف چیزی کم نداره و شاید از مهمترین هاش امکان اشتراک گذاری و مشارکت افراد دیگه در متن مثل نوشتن نظر و یا ویرایش باشه و امکانات خوبی در ساماندهی و دسته بندی مستندات داره و یا امکان بررسی تاریخچه تغییرات نوشته رو داره، مورد آخری که الآن به ذهنم میرسه اینکه app خوب و سبکی به خوبی app وب برای اندروید و iOs داره که paper رو بیشتر در دسترس نگه میداره مثلا من خیلی یادداشت هام رو توی مترو یا مهمونی نوشتم.
دراپ باکس پیپر خیلی نکات مثبت دیگه هم داره که من نگفتم و بقیه چیز های خوبش رو خودتون برید امتحان کنید و لذتش رو ببرید.
پ.ن: بالاخره بعد از مدت ها به بهانه این یادداشت وبلاگم رو هم بهروز کردم 😊
http://p30design.net/1396/04/dropbox-paper-experiance.html
☕️ @airaniTips
P30Design
تجربه من از کار با Dropbox Paper
الآن چند ماهی میشه که یادداشت ها و مستنداتم رو روی دراپ باکس پیپر مینویسم دیگه، بعد از تست کردن تقریبا بیشتر ابزارهای معروف مثل گوگل داکز و ..
Forwarded from فلسفه دیزاین (Ramin Khatibi)
احتیاج کاربر را طراحی کنید،
نه درخواست او را!
قطعا هیچ سرویسی بدون گرفتن بازخورد (Feedback) کاربران نمیفهمه که آیا در حال حرکت در مسیر درست رفع نیاز کاربر هست یا نه.
ولی در بسیاری از مواقع، سرویسها ایمیل و تماسهایی از کاربران دریافت میکنن که بصورت مستقیم خواستار ایجاد بخش جدید در سرویس هستند.
سوال مهم اینجاست که آیا باید درخواست کاربر را اجرا کرد یا نه؟
به تجربه شخصی من، مشابه این موضوع هنگام کار با کارفرماهای مختلف پیش میاد. درخواستهایی مثل تغییر رنگ یک بخش خاص در طراحی، به رنگی دیگر و یا اضافه کردن یک دکمه خاص در صفحهای از اپلیکیشن. بسیاری از طراحان محصول به این صورت عمل میکنند که درخواستها را عینا به شکل مطرح شده اجرا میکنند. این کار در اغلب موارد منجر به از دست رفتن یکپارچگی طراحی ظاهری و یا طراحی امکانات محصول میشه.
آقای Michael Sueoka، سرپرست تیم طراحی تجربهکاربری سرویس The Mobile Majority، با مطرح کردن این موضوع و بررسی تبعات مخرب اجرای مستقیم درخواستهای کاربر، راه حلی ارائه میدن که به نظرم باید بخش جداییناپذیری از پروسه طراحی یک محصول باشه.
ایشون با عنوان این که کاربر معمولا نمیدونه که به چه چیزی احتیاج داره و فقط میدونه که چه چیزی رو میخواد، تفاوت این دو حالت رو مثال کودکی دونستن که برای یک وعده اصلی غذایی، مقدار زیادی شکلات طلب میکنه.
در مقابل درخواستهای این چنینی کاربران، راه حل Michael خوندنی هست.
http://blog.invisionapp.com/dont-design-what-users-want/
(زمان حدودی مطالعه، ۷ دقیقه)
#طراحی_محصول #بازخورد
@HamDesign هَم دیزاین
نه درخواست او را!
قطعا هیچ سرویسی بدون گرفتن بازخورد (Feedback) کاربران نمیفهمه که آیا در حال حرکت در مسیر درست رفع نیاز کاربر هست یا نه.
ولی در بسیاری از مواقع، سرویسها ایمیل و تماسهایی از کاربران دریافت میکنن که بصورت مستقیم خواستار ایجاد بخش جدید در سرویس هستند.
سوال مهم اینجاست که آیا باید درخواست کاربر را اجرا کرد یا نه؟
به تجربه شخصی من، مشابه این موضوع هنگام کار با کارفرماهای مختلف پیش میاد. درخواستهایی مثل تغییر رنگ یک بخش خاص در طراحی، به رنگی دیگر و یا اضافه کردن یک دکمه خاص در صفحهای از اپلیکیشن. بسیاری از طراحان محصول به این صورت عمل میکنند که درخواستها را عینا به شکل مطرح شده اجرا میکنند. این کار در اغلب موارد منجر به از دست رفتن یکپارچگی طراحی ظاهری و یا طراحی امکانات محصول میشه.
آقای Michael Sueoka، سرپرست تیم طراحی تجربهکاربری سرویس The Mobile Majority، با مطرح کردن این موضوع و بررسی تبعات مخرب اجرای مستقیم درخواستهای کاربر، راه حلی ارائه میدن که به نظرم باید بخش جداییناپذیری از پروسه طراحی یک محصول باشه.
ایشون با عنوان این که کاربر معمولا نمیدونه که به چه چیزی احتیاج داره و فقط میدونه که چه چیزی رو میخواد، تفاوت این دو حالت رو مثال کودکی دونستن که برای یک وعده اصلی غذایی، مقدار زیادی شکلات طلب میکنه.
در مقابل درخواستهای این چنینی کاربران، راه حل Michael خوندنی هست.
http://blog.invisionapp.com/dont-design-what-users-want/
(زمان حدودی مطالعه، ۷ دقیقه)
#طراحی_محصول #بازخورد
@HamDesign هَم دیزاین
Invisionapp
Don’t design what users want | Inside Design Blog
<p>Too many product designers are in the pattern of simply taking user feedback and implementing it immediately with limited research, questioning, or thought.</p>