مرثیه ای برای یک کیک که توسط یک تخم مرغ ناتمام ماند


by joyosity

آخرین باری که برای استراحت یک روز کامل مرخصی بودم ۱۵ تیر ۹۲ بود. امروز بعد از یکسال یک روز کامل کار نکردم تا استراحت کنم. از این فرصت استفاده کردم و تعداد زیادی از کارهایی که مدتها بود فرصت انجام دادنشان را نداشتم ، انجام دادم. یکی از این کارهای پختن کیک بود.
خیلی آشپزی نمی کنم ولی دوست داشتم پختن یک کیک رو تجربه کنم. تجربه جالبی بود.
در سایت های مختلف آشپزی گشتم و چند دستور العمل مختلف برای پختن کیک مورد نظر پیدا کردم. مواد را آماده کردم و شروع کردم به درست کردن خمیر. تمام قدمها را طبق دستورالعمل ها طی کردم ولی نتیجه ناامید کننده بود. چیزی که در ظرف مانده بود بیشتر شبیه مقداری پودر با تعدادی گلوله چربی بود تا خمیر یک کیک. دستور العمل ها را چند بار دیگر بررسی کردم. همه چیز درست بود به جز نتیجه!
نمی خواستم در اولین تجربه کیک پزی شکستی به این سنگینی را قبول کنم. یک نفس عمیق کشیدم . سعی کردم راه حلی پیدا کنم. یک بار دیگر به ظرف نگاه کردم و به تصویر نهایی خمیر. نمی دانم چرا ولی احساس کردم شاید یک تخم مرغ بیشتر مشکل را حل کند. فکر کردم ممکن است همه چیز خراب شود. توی هیچ کدام از دستور العمل ها این نسبت برای تخم مرغ و سایر مواد اولیه نیامده بود. ولی خوب یک تخم مرغ دیگر را اضافه کردم. 
در عرض ۳۰ ثانیه آن پودر عجیب داخل ظرف تغییر شکل داد و به تصویر خمیر شبیه شد. ظاهر مساله حل شده بود. همه چیز به خوبی پیش رفت و کیک خوشمزه ای شد!

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


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

 یاد این مطلب و عکس معروفش افتادم:
توی هر مسابقه حدودا پونصد تا مشت پرتاب می کنی، و فقط یکی از اون هاست که تو رو به پیروزی می رسونه. یعنی: چهارصد و نود و نه مشت دیگه، چهارصد و نود و نه بار شکست و ناامیدیه. پس می شه گفت پیروزی پرتاب یک مشت بی نظیره؟ نه… من می گم پیروزی جسارت پرتاب کردن چهارصد و نود و نه تا مشت ناامید کننده ست که هر بار آرزو کرده یی بی نظیر باشن.
– راکی مارسیانو
Rocky Marciano vs Jersey Joe Walcott - from: oldtimewallpapers.com

User On-Boarding


حتما برای شما هم پیش آمده است که بین چند محصول مشابه، نحوه استفاده از یکی از آنها را سریع تر و بهتر یاد گرفته باشید. برای نمونه نحوه تغییر ساعت یک ساعت مچی را بلافاصله بعد خریدش یاد می گیرید ولی برای تغییر ساعت در ساعت مچی دیگر که 6 سال است آن را به مچتان می بندید مشکل دارید و باید به دفترچه راهنمای 200 صفحه ای اش مراجعه کنید!
علت این تفاوت ها را در حالت کلی میتوان در تفاوت های UX پیدا کرد. UX خود بخش های مختلفی دارد و یکی از این بخش ها که کاربر در مراحل ابتدایی استفاده از محصول با آن رو به رو می شود User On-boarding است. مرحله ای که به کاربر محصولتان یاد میدهید چگونه از محصول استفاده کند.

User on-boarding چیست؟

به طور خلاصه UOB مرحله ای است که کاربر را برای استفاده از محصولاتان آماده می کنید. با کمی بی دقتی می توان آن را تجربه اولین مرتبه ی استفاده کاربر از محصول در نظر گرفت. تعریف زیر در سایت UserOnboard آمده است:
User Onboarding is the process of increasing the likelihood that new users become successful when adopting your product.
البته این تعریف کمی ابهام دارند و شاید این تعریف ساده و کوتاه از UXMagzine بهتر باشد:

The process of helping people get started is called onboarding.

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


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

مثلا فرض کنید شما یک برنامه Alarm ساخته اید که قرار است کاربر را صبح ها از خواب بیدار کند. مشکل صبح بیدار شدن است و راه حل هم برنامه شما که با انجام تنظیمات ساده ای مثل صدای هشدار، زمان هشدار، دفعات تکرار و ... این مشکل را حل کند. یک نمونه ساده از مشکل می توانید با یک بار تنظیم هشدار (مثلا برای ۳۰ ثانیه بعد) و به درستی کار کردن هشدار دهنده طبق تنظیمات آن، حل شود. اگر UOB خوبی طراحی کرده باشید، کاربر خیلی سریع می تواند این نمونه کوچک از مشکل خود را حل کند و به کاربر دائمی محصول شما تبدیل شود.
به عنوان مثالی دیگر سرویس ایمیل را در نظر بگیرید. این سرویس قرار است مشکل سختی و زمان بر بودن ارسال و دریافت نامه ها به روش سنتی را حل کند. راه حل ارسال و دریافت به شیوه الکترونیکی است. فرآیندی ارسال اولین ایمیل و آماده شدن برای دریافت اولین ایمیل، UOB این محصول است. توجه کنید که لازم نیست حتما یک ایمیل دریافت کند تا UOB کامل شود. چرا که دریافت ایمیل نیازمند وجود کاربر دیگری برای ارسال است و طبق تعریف قرار بود عواملی جز خود محصول و کاربر جاری را در نظر نگیریم. هر چند این مسئله را سرویس دهنده های ایمیل مانند جیمیل یا یاهو میل از طریق ارسال ایمیل  خوش آمد گویی به Inbox کاربران جدید، بلافاصله بعد از ثبت نام، حل کرده اند. 
لازم نیست محصول حتما نرم افزاری باشد. همان مثال ساعت مچی را در نظر بگیرید. مشکل دانستن زمان فعلی است و راه حل یک ساعت مچی است که زمان فعلی را نشان میدهد. برای آنکه این راه حل درست کار کند باید در اولین قدم بعد از خرید بتوانید آن را تنظیم کرد و مطمئن شوید برای یک محدوده زمانی (مثلا 1 ساعت) درست کار میکند. پس نحوه تنظیم ساعت جزوی از UOB محسوب می شود.

User On-boarding چه فرقی با Empty State دارد؟

وقتی Inbox خالی است به کاربر چه چیزی باید نشان بدهیم؟ وقت هیچ شماره ای در Contact List وارد نشده یا همه پاک شده اند چه پیامی نمایش داده شود؟ زمانی که کاربر هیچ Following ی ندارد در News feed چه چیزی باید ببیند؟ 


این دسته سوال ها در مورد یک مشکل در طراحی رابط کاربری است به نام Empty State. زمانی که به هر دلیلی ( جدید بودن کاربر، حذف شدن اطلاعات، بروز مشکل فنی و یا هر دلیل دیگری ) هیچ محتوایی برای نمایش به کاربر نداریم چه رفتاری باید داشته باشیم.

 شاید در ابتدا Empty State و User On-boarding شبیه هم به نظر برسند ولی این دو با هم فرق دارند. این دو می توانند مستقل از هم باشند ولی معمولا  راه حلی که برای Empty State یک محصول ارائه می شود می تواند به یک UOB خوب کمک کند. بعضی هم ترجیح می دهند Empty State های مختلقی برای دو حالت  اولین استفاده (First Use) و زمانی که اطلاعات توسط کاربر پاک شده است (User Cleared) داشته باشند. در کل Empty State یک مسئله است که باید در قبال آن یک رفتار مناسب پیش گرفت و مختص استفاده اول از محصول نیست. از سویی دیگر UOB نام فرآیندی است که قرار است کاربر را در اولین استفاده از محصول هدایت کند تا استفاده از محصول را بیاموزد.

چرا user on-boarding مهم است؟

اگر با AARRR آشنا باشید، User on-boarding پل بین مراحل Activation و Retention است. به عبارت ساده تر User on-boarding است که تعیین می کند کاربر برای بار دوم هم سراغ محصول شما می آید یا نه.


چطور یک User On-boarding خوب داشته باشیم؟

قاعده کلی برای طراحی یک User On-boarding خوب وجود ندارد ولی مراحلی که من برای طراحی یک UOB استفاده می کنم این است:
۱- یک بار دیگر ببینید محصول شما چه مشکلی را حل کرده است. تعریف دقیقی از مشکل پیدا کنید به طوری که گونه های مختلف مشکل را شامل شود.
۲- عمومی ترین، محتمل ترین و ساده ترین نمونه از آن مشکل را مشخص کنید.
۳- مسیری که کاربر برای حل این نمونه ی ساده از مشکل با محصول شما باید طی کند را کشف کنید.
۴- مسیر را برای کاربر به بهترین روش ممکن نشانه گذاری کنید ( با افزودن متن، تصویر، ویدئو، صوت راهنما یا استفاده از رنگ، فلش یا هر چیز دیگری که به  کاربر نشان دهد چه قدم هایی را باید بردارد ).
۵- این نشانه گذاری را تست کنید. محصول تان را به افراد مختلف بدهید و ببینید بدون کمک و سوال پرسیدن می توانند استفاده از محصول را یاد بگیرند. اگر این طور نبود ببینید موانع آن چه چیزهایی بودند. متن ها و تصاویر خوب نبودند؟ مسیر خوبی انتخاب نکردید؟ مشکل نمونه ای که انتخاب کردید خوب نبوده است؟ موانع را اصلاح کنید و دوباره تست کنید. هر چقدر کاربر سریعتر بتواند در اولین استفاده از محصول، با طی کردن مسیری که شما برایش نشانه گذاری کرده اید، الگوی کلی حل کردن مشکل به کمک محصول شما را پیدا کند، User On-boarding موفق تری خواهید داشت.
تمام این فرآیند را می توان در این جمله در یکی از نوشته های Josh Elman خلاصه کرد:

We dug in and tried to learn what the "aha" moment was for a new user and then rebuilt our entire new user experience to engineer that more quickly.

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






خون ریزی قلبی و آنچه در مورد ارتباط با مشتری باید بیاموزیم



source: http://heartbleed.com/


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

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

فرستادن ایمیل بهتر از نفرستادن است

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

اما یک ایمیل خوب چه ویژگی هایی دارد؟

۱- Title

انتخاب عنوان مناسب برای ایمیل از اهمیت بالایی برخوردار است و تحقیقاتی هم که در این زمینه انجام شده نتایج جالبی را به دنبال داشته است. 
در میان ایمیلهای دریافتی، بهترین عنوان مربوط به ایمیلی بود که از طرف Koding ارسال شده بود. علاوه بر اینکه کوتاه بود آنچه می بایست بعد از خواندن کامل متن ایمیل دستگیرات شود را در همان عنوان می گفت: You're safe.
به علاوه چون این ایمیل را من در تلفن همراهم دریافت کردم و به دلیل محدودیت اندازه صفحه تنها بخشی از ترکیب Title + Body نمایش داده می شود، این عنوان کوتاه و Informative خیلی مفیدتر بود.
البته ایمیلی که Prezi ارسال کرده بود نیز عنوان مناسبی داشت و صحیح نیز این بود که با توجه به نوع مخاطبان آن عنوانی سرراست تر و کمی غیر فنی تر از عنوان Koding داشته باشد.
در بین سایر ایمیل ها هم من شخصا آنها که صریحا کلمه  heart-bleed را ذکر کرده بودن را ترجیح می دادم. چرا که سریعا می توانستم بفهمم علت ارسال موضوع ایمیل چیست.

برنده (فنی) : Koding
برنده (غیرفنی): Prezi

۲- From

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



بهترین انتخاب برای قسمت from ایمیل را IFTTT داشت. علاوه بر اینکه مبدا ایمیل را برای من روشن می کند (IFTTT)، در مورد نوع آن (Alert) هم من را با خبر می کرد.
و قطعا بدترین from هم مربوط به Mapbox بود (noreplay). البته در انتهای متن از کاربر خواسته شده بود که در صورت داشتن سوال به آدرس پشتیبانی آنها ایمیل ارسال کند. ولی این مورد چیزی از بی سلیقگی در انتخاب آنها برای متن From کم نمی کرد.


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

برنده: IFTTT

۳- Body

هر چند Tumblr کمی دیر ایمیل ارسال کرد، اما بهترین متن را داشت. علاوه بر اینکه توضیحی کوتاه و ساده در مورد این آسیب پیذیری می داد، جمله ای داشت که مرا تحت تاثیر قرار داد:
... but you should still take some time to change your password, not only on Tumblr but on any other sites you visit.
با خواندن این جمله این احساس به من دست داد که Tumblr به من به عنوان یک کاربر اهمیت زیادی قائل است و تنها به فکر سرویس خودش و من، به عنوان کاربر آن سرویس، نیست، بلکه اهمیت امنیت من به طور کلی و در هر سرویس دیگری نیز برای  Tumblr مهم است. همین جمله برگ برنده Tumblr برای تبدیل کردن یک ایمیل هشدار دهنده امنیتی به یک ایمیل حاوی توصیه دوستانه برای حفظ امنیت من است.



همچنین لینک های درون متن و دکمه Change my password یی که در انتهای ایمیل قرار داشت زحمت من را به عنوان یک کاربر برای آنچه متن نامه از من خواسته بود، راحت تر می کرد.
از نظر زیبایی بصری متن، توجه به ایمیل Prezi هم جالب است:




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

برنده: Tumblr

نفرستادن ایمیل بد بهتر از فرستادن آن است

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




ارسال کننده تمام تلاش خود را به کار بسته بود تا ایمیل ارسالی هیچ کدام از پارامترهای یک ایمیل خوب را نداشته باشد! عنوان بلند که با بی دقتی تمام انتخاب شده بود ( مثلا قرار دادن کلمه subject در ابتدای عنوان ). متن ایمیل رو به جمع نوشته شده بود (البته ایمیل Koding هم این مشکل را داشت)، فاقد اطلاعات در مورد علت ارسال این ایمیل بود، دارای اشتباهات نگارشی بود و لحنی رسمی-غیررسمی داشت! همچنین متن نامه Dead-End بود و هیچ راهی برای انجام آنچه خواسته بود برای شما یا دسترسی به اطلاعات بیشتر فراهم نمی کرد (مثلا دکمه یا لینکی برای رفتن به صفحه تغییر رمز عبور، اطلاعات بیشتر در مورد علت ارسال این ایمیل، نکات بیشتر در مورد موارد امنیتی و ... ). ایمیل از نظر بصری هم بسیار زشت بود و هیچ المان هویتی در آن گنجانده نشده بود.


و در آخر چند توصیه:
+ پیش از ارسال ایمیل، نتیجه تحقیقات علمی و تجربیات دیگران در مورد روش صحیح ارسال ایمیل را در نظر بگیرید.
+ در مورد انتخاب Title مناسب و کوتاه خیلی فکر کنید.
+ From هم به اندازه Title مهم است.
+ سعی کنید هویت محصولتان در ساختار بصری ایمیلی که ارسال می کنید وارد نمایید.
+ کوتاه و صریح بنوسید.
+ خواننده را در انتهای ایمیل رها نکنید. لینک های مرتبط برای او در متن بگنجانید. توصیه هایی که برای یک صفحه 404 خوب وجود دارد می تواند در ارسال این گونه ایمیل ها نیز مفید باشد؛ مثلا اینجا نوشته است:
Keep in mind: outstanding 404-pages don’t only communicate the occured error message, but also give solutions and options for further navigation. Don’t let your users feel lost. Take them with you. Let them explore your site.
+ لطفا امکان  Unsubscribe داشته باشید.


بروزرسانی - 92/1/27

امروز یک سوال جالب در StackExchange پیدا کردم که بی ارتباط با این موضوع نیست:





ایده دزدها (گاهی) به بهشت می روند


بازی 2048

ایده دزدها به بهشت می روند

به احتمال زیاد در چند ماه گذشته بازی Flappy Bird و  2048 را امتحان کرده اید. راستش را بخواهید بعید می دانم توانسته باشید در برابر بازی کردن آنها مقاومتی از خود نشان دهید. هر دوی این بازی ها محصولاتی بودند که سازندگان آن به صورت تفریحی بر روی آنها کار کرده بودند و از ابتدا اهداف تجاری برای آنها متصور نبودند. 
از تخمین درآمد روزانه ۵۰ هزار دلاری Flappy Bird و داستان برداشتن آن از روی App Store (و برگشتش) و سازنده ای که یافتن هویتش به معمامی برای رسانه ها تبدیل شده بود که بگذریم و اگر بحث در مورد اینکه یک بازی ساده چطور بازی های چند میلیون دلاری و کمپانی های عظیم بازی سازی را به سخره گرفت و چطور به بازی سازها مشخصات یک بازی خوب را یادآوری کرد را هم به کارشناسان این حوزه بسپاریم، آن وقت می رسیم به آنچه موضوع این مطلب است و حاصل مجموع مشاهدات فعل و انفعالات بازار در دوره زمانی ظهور، گسترش و افول این دو بازی است: دزدیدن ایده.
تقریبا تمام افرادی که ایده جدیدی به ذهنشان می رسد و می خواهند آن را اجرایی کنند یک ترس مشترک دارند: آیا ممکن است ایده مرا بدزدند؟ پاسخ افراد در برابر این سوال اغلب یکی از این دوتا است:

۱- نه! بقیه آنقدر خودشان ایده های خوب (از نظر خودشان البته) دارند که وقت ندارند ایده شما را بدزدند و ترجیح می دهند ایده خودشان را اجرایی کنند.

۲- ایده مهم نیست، اجرا مهم است.

آنچه این دو بازی به ما نشان دادند این بود که هر دوی این پاسخ ها اشتباه است. اگر تا پیش از این افرادی چون برادران آلمانی Samwer و کارخانه کپی کردنشان تنها به عنوان استثنائاتی مطرح می شدند، اینبار Flappy Bird و بازی 2048 ( که خود Clone یک بازی دیگر به اسم 1024 می باشد و آن نیز به نوبه خود Clone بازی Threes است! ) به ما نشان دادند تعداد افرادی که آماده اند تا ایده های خوب را کپی کنند چقدر زیاد است. حجم بازی های مشابه در Store ها و تعداد درخواست ها در سایت های Freelance نشان داد ترس از دزدیده شدن ایده ها خیلی هم بی راه نیست!

تصویر بازی Flappy Bird از توییتر سازنده بازی

شاید شما هم مقاله خوب Three myths about keeping your startup a secret را خوانده باشید. به طور خلاصه این مقاله می گوید که نباید نگران دزدی ایده باشید چرا که:
۱- اگر ایده هایتان را به دیگران بگوید به جای دزدی می توانید منتظر بازخوردهای مفید باشید
۲- ایده مهم نیست، اجرا مهم است
۳- اولین بودن نه تنها خوب نیست بلکه به خاطر ریسک مواجه با پدیده های ناشناخته در مسیر، خطرناک هم هست.
اما شرایط برای همه ایده ها اینقدر خوشبینانه پیش نمی رود. مهمترین درسی هم که ما از این دو بازی می گیریم در همین رابطه است: بعضی از ایده ها از این قوانین پیروی نمی کنند.

چرا این بار قوانین نقض شد؟

این دو بازی یک شباهت با هم داشتند: ایده تازه + پیاده سازی ساده. من اسم این دسته از محصولات نرم افزاری را SISI - Simple Idea,Simple Implementation گذاشتم.
این شباهت چیزی بود که باعث شد این بار داستان فرق کند. ساختن یک Clone از آنها نه آنقدر وقت بر بود که افراد به ایده های خودشان نرسند (پاسخ اول) و نه آنقدر جزییات پیاده سازی داشت که بتواند میدانی برای رقابت در نوع اجرای ایده فراهم سازد (پاسخ دوم).

Flappy Bird نشان داد افراد زیادی هستند که منتظرند تا ایده شما را بدزند، عینا و بدون هیچ دخل و تصرفی در آن. آنها نه دچار عذاب الهی می شنود و نه عذاب وجدان. اتفاقا Top Chart هم می شوند!
2048 هم نشان داد هر چند Threes زودتر، بهتر و با جزئیات بیشتر پیاده شده بود، این 2048 بود که فراگیر شد. شاید تجربه این بازی روی Browser و با چهار کلید جهت دار از نمونه Smart Phone یی اش کمی جالب تر باشد (بر خلاف Flappy Bird که نمونه های Web اش خوب نبود) و این دو بازی در مدل Pricing (نوع Premium در برابر Donate) با هم متفاوت هستند، اما دلیل موفقیت 2048 تنها اینها نبود. 2048 را یک گیک ساخته و جامعه گیک ها از آن خوششان آمد و همین باعث شد تا با سرعت زیادی در سراسر شبکه اینترنت پخش شود. قطعا مهمترین دلیل فراگیری آن Viral Ads یی بود گیک های اینترنت  برای آن انجام دادند. همین جامعه پشتیبان گیکی باعث برتری 2048 بر Threes (و 1024 ) شد.

تصویر بازی Threes از سایت سازنده

چرا این بار اینقدر تعداد کپی ها زیاد بود؟

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

اما MVP هم قرار است ساده باشد

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

حالا  چه کار کنیم؟

اول از همه از خودتان بپرسید آیا ایده شما هم SISI است یا نه. بیشتر ایده ها SISI نیستند و احتمالا لازم نیست زیاد نگران باشید. اما اگر ایده شما هم SISI است بهتر است برای Launch و Marketing آن از روش های کمی متقاوت تری استفاده کنید. اما چهار نکته زیر را به خاطر داشته باشید:
۱- هر کسی در ابتدا، ناخودآگاه، تمایل زیادی دارد تا ایده خود را جزو دسته SISI قرار دهد. سعی کنید با این تمایل مقابله کنید.
۲- اگر ایده خوبی دارید مطمئن باشید حداقل یک نفر دیگر در جایی دیگر روی آن کار می کند. پس عجله کنید.
۳- اگر ایده شما SISI نیست، یعنی ایده شما از قوانین پیروی می کند. داشتن یک محصول خوب و درآمدزا نیازمند پیمودن مسیری طولانی و پر فراز و نشیب است. ایده دزدها تا وقتی که مطمئن نباشند که با کپی کردن موفق می شوند، این کار را انجام نمی دهند. ایده دزدها، رقبای بلقوه، سرمایه گذارها، اطرافیان شما و گاهی هم حتی خود شما در احتمال موفقیت محصولتان دچار شک و تردید می شوید. این زمان طولانی و مسیر سخت پیش رو، فرصت کافی به شما می دهد تا وقتی محصوتان به موفقیت و درآمد زایی رسید به اندازه کافی پایدار و منسجم شده باشید تا به راحتی و با چند Clone ساده، موقعیت تان را در خطر نبینید.
۴- اگر ایده خوبی دارید و از آن پول به دست می آید مطمئن باشید دیر یا زود رقیب ها سر و کله شان پیدا می شود. پس مسئله اصلا بودن یا نبودن آنها نیست. قدرت آنها هم همیشه تعیین کننده نیست ( مثلا Google بزرگترین رقیب Dropbox نوپا بود، اما همین بزرگ بودن باعث شد در برابر Dropbox پیروزی چندانی بدست نیاورد ). حتی زمان ورود به بازار هم اهمیت چندانی ندارد ( Threes و 2048 را به خاطر بیاورید ). نهایتا محصولی پیروز است که مشتری از آن راضی تر باشد. 

چطور مشتری را راضی تر کنیم؟

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

با مشابه های مجانی چه کنیم؟

مجانی بودن نمونه مشابه چالش بزرگی در رقابت ایجاد می کند و کار را کمی سخت می کند. اگر محصول مشابه محصول شما به صورت رایگان عرضه می شود، سازنده یکی از این سه وضعیت را دارد:
۱- آنها منابع درآمدی دیگری دارند و به عنوان یک محصول آزمایشی با برنامه ریزی بلند مدت، روی آن کار می کنند. مانند بسیاری از محصولات گوگل.
۲- آنها به صورت تفریحی روی این محصول کار می کنند. مانند Side Project ها، محصولات Hackaton های داخلی شرکت ها یا Weekend Project ها.
۳- محصول شما به گونه ای است که کاربر برای آن پول خرج نمی کند. مثلا محصول خیلی ساده است یا یکبار مصرف است ! در نتیجه رقیب شما هم به درآمد فکر کرده ولی به نتیجه ای نرسیده است.

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

پس از نگارش

من این مطلب را ۲۹ اسفند ۹۲ نوشته بودم و قصد داشتم بعد از تعطیلات عید منتشر کنم. در طول تعطیلات به چند مقاله جالب در همین رابطه بر خوردم و حیف بود اگر به آنها اشاره ای نمی کردم.
مقاله اول 2048: The Nihilistic Face Of Free To Play است و به بررسی ضرری که بازی های رایگان برای صنعت بازی سازی دارند پرداخته است.
مقاله دوم Clones, Clones Everywhere – “1024,” “2048″ And Other Copies Of Popular Paid Game “Threes” Fill The App Stores است و به طور دقیق تری به Clone در صنعت بازی و به طور خاص به مورد عجیب 2048 می پردازد.
این هم مطلبی که سازندگان Threes درباره این مشکل منتشر کردند: The Rip-offs & Making Our Original Game

در آخر هم تصویری از App Store برای آنکه مطمئن شوید گاهی ایده دزدها به بهشت می روند:
App Store (US) - March 27 2014



آموزش مارکتینگ نرم افزار در مترو



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

1- دو بار پیشنهاد بدهید

تقریبا هیچ کدام از دست فروش ها به یک بار رد شدن از کنار شما بسنده نمی کنند. حداقل دوبار تمام واگن ها را در طی ۳-۴ ایستگاه طی می کنند. ۳-۴ ایستگاه حداقل تعداد ایستگاه است که مسافران طی می کنند به این ترتیب آنها به اکثر مسافرها حداقل دوباره پیشنهاد خرید می دهند. دفعه اول با سرعت عبور می کنند در حالی که پیشنهاد خود را می دهند. اما تا شما در مورد اینکه به آن جنس نیاز دارید یا نه، پول کافی دارید و ... فکر کنید، آنها رفته اند. کمی حس پشیمانی در شما شکل می گیرد که کاش زودتر تصمیم می گرفتم. اما چند دقیقه بعد دوباره سر و کله آنها از مسیری که رفته بودند پیدا می شود و این بار برای دچار نشدن به همان حس پشیمانی، احتمال آنکه خرید را انجام دهید بیشتر می شود. اجازه دهید مشتری ها از اینکه از شما خرید نکرده اند پشیمان شوند. حالا دوباره همان پیشنهاد را تکرار کنید. بعد از پیشنهاد اول کسانی خرید می کنند که نیاز دارند. بعد از پیشنهاد دوم کسانی خرید می کنند که نمی خواهند حس بد پشیمانی دوباره به سراغشان بیاید.
(  در مارکتینگ چیزی به اسم The Rule of Seven هست که می گوید برای آنکه مشتری از شما خرید کند باید قبل از آن 7 بار پیشنهاد دهید!)

۲- Call to Action داشته باشید

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

۳- محدودیت زمانی ایجاد کنید

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

۴- محصول درست بفروشید

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

۵- نشان بدهید مشتری با کالای شما چه کار می تواند انجام دهد

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

آخرین کلام

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

* عکس از اینجا انتخاب شده است.

How Does Mapbox Offer a Job in JavaScript Output?

For exmaple:
2- Open Developer Tools
What you see in Console is:
* .--. / / ` + | | ' \ \__, * + '--' * + /\ + .' '. * * /======\ + ;:. _ ; |:. (_) | |:. _ | + |:. (_) | * ;:. ; .' \:. / `. / .-'':._.'`-. \ |/ /||\ \| _..--"""````"""--.._ _.-'`` ``'-._ -' Hello, explorer '- Curious? http://mapbox.com/jobs





Hack InoReader: How Many Feeds Have You Read In Recent 7 Days



من از Inoreader به عنوان سرویس Feed Reader استفاده می کنم. امروز می خواستم که تعداد آیتمهایی که در 7 روز اخیر خوانده ام را بدست بیاروم. ولی خود Inoreader این امکان را ندارد و بخش آمار ساده ای دارد. دو راه داشتم:
1- از Bar Chart خودش استفاده کنم و مجموع آیتم های خوانده شده در هفت روز اخیر را دستی حساب کنم.
2- کمی کد بنویسم.

می رویم سراغ راه دوم:

اول باید در Inoreader به قسمت Statistics بروید. البته اول مطمئن شوید که Developer Console باز است (Ctrl+Shift+I).


در قسمت Network در Developer Console ، در میان چند درخواست/پاسخی که برای index.php ارسال/دریافت شده است یکی از آن برای ما مهم است. برای پیدا کردن آن کافی است به قسمت Form Data هر کدام نگاه کنید. باید عبارت print_stats_chart را ببینید.



بعد از پیدا کردن درخواست/پاسخ مورد نظر، به سربرگ Response بروید و کل محتوای آن را کپی کنید.



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

<?xml version="1.0" encoding="utf-8" ?><xjx><cmd cmd="js">Smake_chart('stats_chart_0',[['Date','Articles posted','Articles read'],['27/12',0,0],['28/12',4685,299],['29/12',4858,547],['30/12',5519,172],['31/12',4893,229],['01/01',4401,137],['02/01',5368,211],['03/01',5412,268],['04/01',5031,84],['05/01',4956,251],['06/01',5703,188],['07/01',6192,33],['08/01',6132,206],['09/01',5566,131],['10/01',5343,165],['11/01',5136,102],['12/01',5098,142],['13/01',5889,352],['14/01',6290,81],['15/01',5955,70],['16/01',5779,144],['17/01',5465,132],['18/01',4794,69],['19/01',4481,215],['20/01',5839,282],['21/01',6275,176],['22/01',6308,182],['23/01',5764,24],['24/01',5539,356],['25/01',5060,161],['26/01',5249,324],['27/01',1717,204]],'');</cmd></xjx>

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

<?xml version="1.0" encoding="utf-8" ?><xjx><cmd cmd="js">Smake_chart('stats_chart_0',[['Date','Articles posted','Articles read'],['27/12',0,0],['28/12',4685,299],['29/12',4858,547],['30/12',5519,172],['31/12',4893,229],['01/01',4401,137],['02/01',5368,211],['03/01',5412,268],['04/01',5031,84],['05/01',4956,251],['06/01',5703,188],['07/01',6192,33],['08/01',6132,206],['09/01',5566,131],['10/01',5343,165],['11/01',5136,102],['12/01',5098,142],['13/01',5889,352],['14/01',6290,81],['15/01',5955,70],['16/01',5779,144],['17/01',5465,132],['18/01',4794,69],['19/01',4481,215],['20/01',5839,282],['21/01',6275,176],['22/01',6308,182],['23/01',5764,24],['24/01',5539,356],['25/01',5060,161],['26/01',5249,324],['27/01',1717,204]],'');</cmd></xjx>

سپس این اطلاعات را در یک آرایه ذخیره می کنیم (کافی است قسمت های آبی رنگ به آنها اضافه شود) :
var d=[
['27/12',0,0],['28/12',4685,299],['29/12',4858,547],['30/12',5519,172],['31/12',4893,229],['01/01',4401,137],['02/01',5368,211],['03/01',5412,268],['04/01',5031,84],['05/01',4956,251],['06/01',5703,188],['07/01',6192,33],['08/01',6132,206],['09/01',5566,131],['10/01',5343,165],['11/01',5136,102],['12/01',5098,142],['13/01',5889,352],['14/01',6290,81],['15/01',5955,70],['16/01',5779,144],['17/01',5465,132],['18/01',4794,69],['19/01',4481,215],['20/01',5839,282],['21/01',6275,176],['22/01',6308,182],['23/01',5764,24],['24/01',5539,356],['25/01',5060,161],['26/01',5249,324],['27/01',1717,204]
];
هر عنصر این آرایه اطلاعات مربوط به یک روز است که شامل تاریخ، مجموع آیتم های جدید آن روز و تعداد آیتم های خوانده شده در آن روز می باشد؛ مثلا:
'23/01' 5764 24 ]

در آخر هم با یک Map-Reduce ساده به زبان جاوااسکریپت و در همان بخش Console ابزار Developer Console کروم می توانید مجموع آیتم هایی که در 7 روز اخیر خوانده ایم را بدست بیاوریم:

d.slice(-7) .map(function(o){return o[2]}) .reduce(function(a,b){return a+b})
برای من خروجی این بود:
 1427