Boplo.ir
rss

من در Facebook


جستجو


مطالب همینجوری

بر و بچ

MyView TakhteShasi Tween

دوستشون دارم

بیلبورد

دامین برای فروش: CleanCode.ir
FastFeed.ir
Fonvi.com

تماس


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

 

از بيماران سرطاني حمايت كنيم

A new begining
AHHP presents

 

rss طراحی وب

کاربر محترم، شاید باورت نشه ولی تو الان در سایت ثبت‌نام شدی!
۱۶ بهمن ۱۳۸۹ ساعت ۰۱:۲۰

13 راه برای ساده‌سازی ثبت‌نام

خیلی اتفاقی به مقاله‌ای در سایت Baymard Institute برخوردم. این پست براساس این مقاله نوشته شده: Twelve Ways to Simplify SignUp

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

    لیست زیر حرف دل کاربرانیست که در حال ثبت‌نام در سایت هستند:
  • من یه Username جدید به ذهنم نمیرسه! نمیشه از آدرس ایمیلم استفاده کنید؟
    این کار عملیات ثبت‌نام رو خیلی راحت میکنه. من خودم موقع اینجور ثبت‌نام کلی فکر میکنم که نام‌کاربری برای خودم انتخاب کنم.
    از اونجایی که در این روش، کاربر نام کاربری وارد نکرده، برای نمایش از نام و نام‌خانوادگی‌اش استفاده میشه و این کار، کاربران رو تشویق میکنه تا از نامهای واقعی‌اشون توی سایت استفاده کنند. این موضوع برای ظاهر سایت خیلی اهمیت داره.
    یکی توی سایتش امکان استفاده از Username رو میده و کاربری با نام‌کاربری Sanaz_joon_jigar_tala در سایت دیده میشه. همین شخص در سایتی که از Username نمیخواد، از نام واقعیش یعنی "اکبر قوی‌منش" استفاده میکنه (مثلا)! حالا خودت بگو خداییش کدوم بهتره؟

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

  • واقعا دونستن دور کمر من برای ثبت‌نام لازمه؟
    تا جایی که ممکنه اطلاعات غیرحساس رو بعد از ثبت‌نام از کاربر بخوایم نه موقع ثبت‌نام! بعضی سایتها آدم رو مجبور میکنند کل پروفایل رو موقع ثبت ‌نام پر کنیم. آخه این کار درسته؟

  • حتما باید کل فرم رو پر کنم بعد بگی این Username اِشغاله پدرسوخته؟!
    اگر میخوایم از Username استفاده کنیم یکم فهمیده عمل کنیم و کاربر رو مجبور نکنیم تا همه‌ی فرم رو پر کنه بعد بفهمه Usernameای که انتخاب کرده قبلا ثبت شده. بعضی سایتها کلی بیشعورند! کاربر باید دو تا پسورد و یک CAPTCHA رو هر دفعه پر کنه! بعد میگند چرا کسی ثبت نام نمیکنه یا چرا 10000 تا کاربر داریم ولی فقط 10 نفر فعالند!
    راه خوب اینه: همزمان که کاربر نام‌کاربری رو پر کرد با AJAX چک کنیم و بهش اطلاع بدیم. من میخواستم توی سایت AOL ثبت‌نام کنم باور کن 30 تا Username چک کردم حتی "Boplo" رو هم ثبت کرده بودند!! اگر قرار بود هر دفعه با Submit خطا بگیرم عمرا ثبت‌نام نمی کردم. سایتهایی مثل یاهو یا همون AOL حتی پیشنهاد هم میدند که مثلا AmirHossein قبلا ثبت شده ولی Amir_hossein رو میشه انتخاب کرد.

  • واقعا باید "کاستیدگیلینکوفینوستا با لیمو" رو تایپ کنم؟
    این CAPTCHA یا همون کد امنیتی واقعا به خودی خود کابوس شده. سیستم تولید CAPTCHA در بعضی سایتها نه تنها بی‌مهابا عدد و حروف کوچیک بزرگ رو با هم میکس میکنند بلکه از فونتهای عجیب غریب و زمینه‌های گیج‌کننده هم استفاده میکنتد. نمونه‌اش همین vBulletin. من شخصا نمیتونم CAPTCHAاشون رو بخونم. مرگ برچنین سایتهایی!
    راستی "کاستیدگیلینکوفینوستا" با چی؟!!

  • مگه همین الان ثبت‌نام نکردم؟ دوباره Login کنم؟ خری؟!
    بیایم یه زحمت بکشیم و وقتی کاربری ثبت‌نام کرد توی سایت لاگینش هم بکنیم. لاگین بعد از ثبت‌نام شبیه یه جور جوک می‌مونه.

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

  • ایول! بالاخره فرم ثبت‌نام رو پیدا کردم! 20 دقیقه بیشتر طول نکشید...
    فرم ثبت‌نام رو تو سایت قایم نکنیم! من خودم تا حالا لینک صفحه‌ی ثبت‌نام کلی از سایتها رو توی فوتر سایت (همون لینکهای ریز پایین پایین صفحه) پیدا کردم.
    سایتهایی که فعالیت اصلی‌اشون روی کاربران هست (مثل سایتهای دوستیابی) بهتره که فرم ثبت‌نام رو توی صفحه اصلی قرار بدهند.

  • برای چی باید ثبت‌نام کنم؟ که اسمم رو گوشه صفحه ببینم؟
    هدف کاربر جمع کردن نیست هدف اصلی ارائه‌ی خدمات به شخص کاربر هست یعنی داشتن کاربر باحالی محسوب نمیشه فایده هم نداره برای کاربر داشتن باید منظور واقعی و قانع‌کننده داشت.

  • با این فرم هم میشه لاگین کرد هم ثبت‌نام! چه zexy!
    این واقعا باحاله که یک فرم داشته باشیم با دو تا دکمه یکی برای ثبت‌نام و یکی برای لاگین. این گوگولی‌ترین مدل جمع و جور سازی هست!

  • همین؟ ثبت‌نام با یه ایمیل فقط؟ چه قانع!
    در راستای فرهنگ جمع و جورسازی میشه با دریافت یک ایمیل هم ثبت‌نام کرد! در این حالت یک پسورد برای کاربر ساخته میشه و براش ایمیل میشه. این یک روش خداپسنده است که زحمت Activation رو هم خودش میکشه اما واسه خود من عوض کردن پسورد چندان هیچان‌انگیز نیست! مگه اینکه برای بار اول، کاربر با فرم تغییر کلمه عبور روبرو شه. اینجوری مجبور میشه رمزش رو عوض کنه به اونی که باحاش حال میکنه.

  • لاگین با اکانت جی‌میل! جل الخالق!!
    یه سری آدم دور هم جمع شدند تا کاربر هر چه راحتتر لاگین کنه. OpenID چنین امکانی رو فراهم کرده تا فقط با یک اکانت در سایتهای مختلفی لاگین کنیم. یعنی در واقع ثبت‌نام بی ثبت‌نام.
    این روش به این هلویی که به نظر میاد نیست دردسرهای خودش رو داره.

این هم از طرف Boplo.ir:

  • من بطور عجیبی با همه‌ی شرایط و ضوابط در همه‌ی سایتها موافقم!
    این "شرایط و ضوابط استفاده" یا "Terms of use" واسه‌ی قشنگی نیست باید اتمام حجت ما با کاربر باشه پس ترجمه نکنیمش و از جایی کپی نکنیم. بعدش انسان باشیم و ترتیبی بدیم که کاربر حتما مطالعه کنه. اگر واسه سایت من شد 50 صفحه یه جوری نمایش بدم که توی 30 ثانیه قابل فهم باشه طوری که مثلا عناوین لیست بشند و توضیحات به سادگی قابل دریافت باشند.
    روش باحالتر اینه که ثبت‌نام رو وابسته به موافقت کاربر با همه‌ی شرایط نکنیم (یعنی کاربر رو مجبور به موافقت نکنیم) بجاش امکانات سایت رو براساس توافق نامه محدود کنیم.
    مثلا من یک Forum دارم و یکی از بندهای توافق‌نامه‌ام اینه: آدرس ایمیل کاربر در صفحه پروفایل برای سایر کاربران قابل دسترس است.
    و چون کاربر باید با توافق‌نامه‌ی من موافقت کنه تا ثبت‌نام شه باید حتما این بند رو قبول کنه. بهتره به کاربر امکان بدم که این بند رو قبول نکنه و ایمیلش هم پنهان بمونه. این یک مثال خیلی ساده و بدیهی بود ولی روند مشخص شده بود.

اینجوری میشه که وقتی ثبت‌نام تکمیل شد بجای اینکه پیغام "کاربر محترم واقعا خسته نباشید!" رو نمایش بدیم روی صفحه مینویسیم:
کاربر محترم، شاید باورت نشه ولی تو الان در سایت ثبت‌نام شدی!

برچسب ها: ,

 

باید و نبایدهای استفاده از AJAX
۲۲ آبان ۱۳۸۹ ساعت ۰۴:۰۴

خوبها: آژاکس. بدها: آژاکس

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

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

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

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

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

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

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

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

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

پست مرتبط: بیایم AJAX یاد بگیریم.....

موفق باشید

برچسب ها: ,,

 

هدف: تصاویری که آدرسشون صحیح نیست!
۲۳ مهر ۱۳۸۹ ساعت ۰۱:۲۶

Roger That! Target locked

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

از اونجاییکه من خیلی آدم توپی هستم (توپ پینگ پونگ)، کد جاوااسکرپیت رو بصورت ساده، تحت فریم‌ورک MooTools و تحت فریم‌ورک jQuery اینجا قرار می‌دم که با هم صفا کنیم.

ابتدا این تصویر ماست:

<img src="an-invalid-image.gif" alt="i like to be shown" />
ما برای اهداف دوراندیشانه‌ای یک تابع جاوااسکریپت ایجاد می‌کنیم تا آدرس تصویر رو عوض کنه:
function imageErrorHandler(img) {
	(img || this).src = 'images/a-valid-image.gif';
}
این تابع هم می‌تونه برای جاوااسکرییپت استفاده بشه و هم بصورت inline در تگهای img شبیه زیر:
<img onerror="imageErrorHandler(this)" src="image.gif" alt="" />

و حالا با داشتن تابع imageErrorHandler کافیه این کد رو در انتهای کدهای صفحه بیاریم تا روی همه‌ی تگهای img اعمال شه:

for(var i=0; i<document.images.length; i++) {
	document.images[i].onerror = imageErrorHandler;
}

و برای MooTools عزیز:
window.addEvent('domready', function() {
	$$('img').addEvent('error', imageErrorHandler);
});
و برای jQuery:
$(document.body).ready(function() {
	$('img').error(function(){
		imageErrorHandler(this);
	});
});

سیب و هلو باشید!

برچسب ها: ,

 

آیا Application من خوب نوشته شده؟
۷ شهریور ۱۳۸۹ ساعت ۱۱:۱۰

چند معیار ساده برای اطمینان از قوی و حرفه ای بودن Application

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

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

  • دوم. مشکل ساختاری اساسی و معضل امنیتی نداشته باشه.
    باید همیشه به روز باشیم یا با شیوه های نوین آشنا باشیم (در حد توان) ولی در حالت کلی باید ساختار رو کامل تحلیل کنیم و اشکالاتش رو کشف کنیم.
    مثلا یک سیستم مدیریت کاربر نوشتیم که کاربر میتونه هر کاراکتری رو به عنوان نام کاربری انتخاب کنه. وقتی چنین قابلیتی رو داریم تعریف می کنیم باید فکر این رو هم بکنیم یه نفر چنین Usernameای رو انتخاب کنه: "          " یعنی 10 تا Space و این ناجوره! باید چنین مواردی رو کشف کنیم و راه کشفش هم تحلیل سیستمه.

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

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

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

برچسب ها:

 

باز شدن خودکار لینکهای خارجی در پنجره جدید توسط JavaScript
۲ تير ۱۳۸۹ ساعت ۱۱:۰۰

تابع JavaScript برای کنترل لینکهای External

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

var hostname = window.location.hostname;
var anchors = document.getElementsByTagName("a");
for(var i=0; i<anchors.length; i++) {
	if(	anchors[i].href
		&& anchors[i].href.indexOf(hostname) == -1
		&& !anchors[i].target
	) {
		anchors[i].target = "_blank";
	}
}

از اونجایی که کار نصفه و نیمه جواب نمیده و چون این وبلاگ بخش MooTools و jQuery هم داره. این کد رو با این دو فریم ورک هم می نویسم محض نمونه و مثال از این فریم ورکها:
انتخابگر هر دوشون مثل هم هست و به شکل زیره:

var hostname = window.location.hostname;
var selector = 'a[href]:not([href*='+hostname+']):not([target]';

  • MooTools:
    $$(selector).set('target', '_blank');
  • jQuery:
    $(selector).attr('target', '_blank');

من اینجا یکم محدودیت عرضی دارم که طول خطوط کدها طولانی نشه وگرنه این کدها رو میشه تو یک خط اجرا کرد بجای اینکه هر تیکه اش رو تو یه متغیر بریزیم.

برچسب ها: ,

 

روش بکارگیری Timestamp در PHP و MySQL و JavaScript
۳۰ خرداد ۱۳۸۹ ساعت ۰۱:۴۴

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

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

Timestamp ثانیه های طی شده از 00:00 1970/01/01 تا الانه. همونجوری که واضحه، زمان به این شکل، یک عدد صحیح خواهد بود و مهمترین خاصیتش سهولت نگهداری و مقایسه است.

زمان در PHP بر پایه Timestamp تعریف شده ولی در MySQL و JavaScript چنین نیست و معمولا برای هماهنگی این سه زبان، مجبوریم کدهای اضافی داشته باشیم درحالیکه هر سه این زبانها، امکاناتی برای کار با Timestamp بر پایه Unix دارند.

    در زیر یک مثال در هر کدوم از این زبانها قرار گرفته:
  • PHP:
    $timestamp = time();
    $date = date('Y F d', $timestamp);
  • MySQL:
    timestamp = UNIX_TIMESTAMP()
    date = FROM_UNIXTIME(UNIX_TIMESTAMP(), '%Y %D %M %h:%i:%s %x')
  • JavaScript:
    var timestamp = parseInt(new Date().getTime()/1000);
    var date = new Date(new Date().getTime()).getDay();

برچسب ها: ,,,

 

HTML TABLE، خوب یا بد؟
۱۹ خرداد ۱۳۸۹ ساعت ۰۱:۲۷

طراحی Tableless چیست؟

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

اول از محاسن Table میگم، بعد از معایبش و مقایسه اش با مدل CSS و در آخر یک جدول رو یکبار با تگ TABLE و یکبار توسط CSS خواهی دید. باید و نبایدهای HTMLTABLE

برچسب ها: ,

 

JSON و JSONP
۱۶ اردیبهشت ۱۳۸۹ ساعت ۱۲:۳۹

معرفی JSON و JSONP که چی هستند و به چه درد میخورند
json and jsonp

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

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

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

JSON مخفف JavaScript Object Notation است یعنی نشانه گذاری توسط اشیاء جاوااسکریپت. JSON در واقع شیء و آرایه جاوااسکریپت هست که وقتی متن رو به اون شکل مرتب کنیم، در زبان جاوااسکریپت میشه دوباره به Object یا شیء تبدیل کرد و استفاده کرد.

توضیحات بیشتر و معرفی JSONP

برچسب ها: ,

 

آموزش استفاده از Selectorهای CSS
۲۷ اسفند ۱۳۸۸ ساعت ۱۲:۲۵

معرفی Selectorهای CSS و کار با مهمترین هاشون

Selector یا انتخابگرهای CSS، فرمتهایی برای دسترسی بیشتر به اجزای صفحه است. برای نمونه،انتخابگر زیر:

div:first-child[id*=some] span.someClass + p ,
.someClass#someID {
	color: red;
}
برای اولین P بعد از یک SPAN با کلاس someClass که زیرمجموعه یک DIV باشه DIVای که اولین عضو زیرمجموعه خودش باشه و مقدار مشخصه ID اون کلمه some توش باشه، به اضافه Element با ID برابر someID و class برابر someClass اعمال میشه.
یعنی در کد زیر، P 3 و SPAN 2 و SPAN 4 قرمز میشه.
<!DOCTYPE html>
<html>
	<head>
		<style type="text/css">
			div:first-child[id*=some] span.someClass + p ,
			.someClass#someID {
				color: red;
			}
		</style>
	</head>
	<body>
	
		<div id="someDiv">
			DIV 1
			<p>P 1</p>
			<p>P 2</p>
			<div>DIV 2</div>
			<span class="someClass">SPAN 1</span>
			<p>P 3</p>
			<span id="someID" class="someClass">SPAN 2</span>
		</div>
	
		<div id="someDiv">
			DIV 3
			<p>P 4</p>
			<p>P 5</p>
			<div>DIV 4</div>
			<span class="someClass">SPAN 3</span>
			<p>P 6</p>
			<span id="someID" class="someClass">SPAN 4</span>
		</div>
	
		<p>P 7</p>
	
		<div>
			DIV 5
			<p>P 8</p>
		</div>
	
	</body>
</html>

میخوایم این انتخابگرها رو دونه دونه از ساده به پیچیده با مثال توضیح بدیم. ادامه آموزش

برچسب ها: ,

 

Delegation با اسب سفید
۱۶ اسفند ۱۳۸۸ ساعت ۱۱:۵۳

توابع Delegation در فریم ورکهای MooTools و jQuery

همونطور که مستحضریم، جاوااسکریپت امکان تعیین Event رو به هر Element از صفحه میده که مثلا اگر فلان Element کلیک شد این اتفاقا بیافته و اگر یکی دیگه mouseover شد اون یکی اتفاقا بیفته و غیره. تعیین این Eventها از طریق Frameworkها مثل MooTools و jQuery عجیب آدم رو یاد هلو میندازه. مخصوصا که امکان تعریف Evnet های اختصاصی رو هم میدن مثل OnLoveBoplo، OnVisitBoplo و غیره.

این فریم ورکها، امکانی برای اجرای کد در زمان تکمیل DOM رو دارند که در MooTools رویداد domReady و در jQuery متد ()ready. که به ما امکان قرار دادن کدها رو در <head> صفحه میدن و خیلی کاربرد دارند. مثل کدهای زیر که وقتی هر لینکی کلیک شد، یه alert ناقابل نمایش میده:

// MooTools
window.addEvent('domready', function(){
	$$('a').addEvent('click', function() {
		alert("You've clicked " + this.href + "!");
	});
});

// jQuery
$(document).ready(function(){
	$('a').click(function() {
		alert("You've clicked " + $(this).attr('href') + "!");
	});
});

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

برچسب ها: ,,,

 

LazyLoad، یک تنبل دوست داشتنی
۱۳ اسفند ۱۳۸۸ ساعت ۱۱:۱۷

پلاگین و ترفند جالب جاواسکریپت

یه زمانی جاوااسکریپت منفورترین قابلیت تحت وب بود ولی بعد از پیدایش MooTools و jQuery و Prototype و غیره، به یه بخش مهم سایتهای حرفه ای تبدیل شده. از اون مهمتر اینکه باعث تحریک ذهنهای خلاق و طراحهای خوش ذوق شده. Lazy Load یکی از این خلاقیتهاست. Lazy Load یه روش جالب برای لود تصاویر در صفحه های بلنده. مثلا سایت SmashingMagazine عزیز پست داره با این عنوان: "80 قالب زیبا برای وردپرس" این یعنی این مقاله قراره 80 تا عکس داشته باشه و از اونجاییکه این سایت یک سایت حسابیه و مخاطبینش هم سرعت اینترنت حسابی دارند (البته غیر من)، با خیال راحت کلی عکس با کیفیت میریزه تو صفحه. اما با وجود سرعت بالا هم لود همزمان این تعداد عکس ناجوره.
اینجاست که تکنیک Lazy Load مثل هوخشتره میاد و راهکار ارائه میده. این تکنیک به این صورته که هیچ عکسی لود نمیشه مگر اینکه توی منطقه قابل دید مانیتور یا Viewport کاربر باشه. این یعنی وقتی صفحه لود میشه، عکسها لود نمیشن و وقتی اسکرول می کنیم روی یک عکس، همون موقع شروع به بالا اومدن می کنه! انگار داریم همون عکسی که میبینیم رو باز می کنیم! اینجوری من با خیال راحت مقاله گنده SmashingMagazine عزیز که LazyLoad نصب کرده رو باز می کنم با این نظر که تا موقعی که پایین صفحه نرم اون عکس پایینی ها لود نمیشن و سرعتم کند نمیشه.

هم jQuery و هم MooTools این پلاگین رو دارند که پلاگین MooTools اش رو آقای David Walsh خیلی عزیز نوشته.

یه نکته دیگه اینکه این دو تا پلاگین با اینکه یه کار می کنند ولی یه تفاوت کوچیک دارند و اون اینه پلاگین jQuery وقتی لود تصویر رو شروع می کنه که عکس در Viewport قرار بگیره یا توی کادر مرورگر قابل رویت باشه ولی پلاگین MooTools یکم قبل از رسیدن اسکرول صفحه به محل تصویر عملیات لود رو شروع می کنه که به نظر من بهتره.

شنگول باشید

برچسب ها: ,,,

 

CSS و سردرد ناشی از مرورگرهای مختلف
۵ آبان ۱۳۸۸ ساعت ۰۱:۵۵

ابزارهای طراحی بصورت Cross-Browser

وقتی میخوای CSS بنویسی حتما می دونی که کدهات توی مرورگرهای مختلف که هر روز دارند بیشتر می شن، متفاوت رندر میشه. مخصوصا اینترنت اکسپلورر که به زبون خودش حرف می زنه! واسه اینکه CSS به اصطلاح Cross-Browser داشته باشیم یعنی توی همه مرورگرها، خروجی ثابتی داشته باشه، دو راه وجود داره:

این دو راه توی ادامه پست توضیح داده شده.

برچسب ها: ,,

 

تغییر رنگ هایلایت متن با CSS
۱۹ شهریور ۱۳۸۸ ساعت ۰۲:۰۹

تعیین رنگ متن و زمینه عباراتی که highlight می کنیم

CSS یه امکان ریزه میزه داره که میشه رنگ highlight متن رو تغییر داد. طبیعتا برای تغییر استایل، فقط رنگ زمینه و رنگ نوشته، تاثیرگذاره. کافیه این دو تا رو توی CSS قرار بدی:

::-moz-selection {
	background:#cc0000;
	color:#fff;
}

::selection {
	background:#cc0000;
	color:#fff;
}

اولی مخصوص فایرفاکس و موزیلاست و دومی رو سافاری و گوگل کروم و اپرا ساپورت می کنند. طبق معمول اینترنت اکسپلورر خرس گنده، این سوسول بازیا تو کت و کولش نمیره!
برای نمونه، متن همین صفحه رو highlight کن یا دکمه های Ctrl+A رو بزن.

شنگول باشید

برچسب ها:

 

مقایسه jQuery و MooTools
۳۱ تير ۱۳۸۸ ساعت ۰۹:۵۶

بررسی فنی تفاوت این دو فریم ورک

برای استفاده از جاوااسکریپت توی سایت، معمولا jQuery و MooTools گزینه های قابل تأمل تری هستند و اغلــــب ایــن ســــوال پیـــش میــاد که کــــدوم رو باید انتخــــاب کرد؟ چــند روز پیـــش به ســـایـــت jQuery vs MooTools.com برخوردم. یکی از توسعه دهندگان MooTools، یه مقاله بلند بالا، در همین باره در این سایت قرار داده. من هم از اونجاییکه چند وقت بود تو فکر نوشتن همچین مطلبی بودم، تصمیم گرفتم که این مقاله رو ترجمه کنم. این کار رو انجام دادم و صفحه فارسی رو برای نویسنده اش ارسال کردم و اون هم تو سایت قرار داد. به آدرس زیر:

« jQuery vs MooTools .com / index_fa.html »

jQuery or MooTools, image by sir.blogsky.com

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


اگر حوصله خوندن اون مقاله رو نداری یا میخوای نظرات خیلی خیلی خیلی مفید من رو هم در این باره بدونی، ادامه مطلب رو بخون ....

برچسب ها: ,,,

 

تنظیم شفافیت اجزای صفحه در CSS
۲۷ خرداد ۱۳۸۸ ساعت ۰۱:۳۱

CSS Transparency بصورت Cross-Browser

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

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

.transparency {
	filter: alpha(opacity=50);
	-moz-opacity: 0.5;
	-khtml-opacity: 0.5;
	opacity: 0.5;
}

توضیح بیشتر.....

برچسب ها: ,

 

بیایم AJAX یاد بگیریم.....
۱۰ اردیبهشت ۱۳۸۸ ساعت ۱۲:۵۵

آموزش مختصری برای AJAX

loading loading loading loading loading
loading

AJAX چی هست اصلا؟ آژاکـــــــس یا ای-جکــــس مخفف Asynchronous JavaScript And XML به معنی جاوااسکریپت و XML غیرهمزمان هست. به معنیش فکر نکن که چیزی دستگیرت نمیشه! بی خیال
آژاکس تکنیکی برای دریافت اطلاعات از سرور بدون بازخوانی یا Refresh صفحه است. اصولش هم به این صورته که جاوااسکریپت به سرور درخواست(Request) ارسال می کنه و نتیجه یا پاسخ(Response) سرور رو دریافت می کنه بدون این که صفحه جاری بازخوانی بشه.

توضیح بیشتر به این صورت هست که ...... ادامه آموزش

برچسب ها: ,

 

1

 

me

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

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

به خونه امیرحسین خوش اومدی...

MODx | Template World