PDA

View Full Version : الگوی صحیح طراحی و توسعهء تحت وب



eshpilen
دوشنبه 21 تیر 1389, 21:41 عصر
اصول طراحی و توسعهء تحت وب

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

eshpilen
دوشنبه 21 تیر 1389, 21:41 عصر
خب اول چنتا نکتهء ساده و بدیهی رو میگم که در عین بدیهی بودن بعضی رعایتشون نمیکنن یا حواسشون نیست و موقع توسعه و طراحی یا موقعی که سایت روی اینترنت میره مشکل ساز میشن:

موقع توسعه و طراحی سایت روی سیستم خودتون روزلیشن صفحهء مانیتور خودتون رو به حد استاندارد تنظیم کنید. مثلا درحال حاضر رزولیشن استاندارد ۱۰۲۴ در ۷۶۸ هست. این روزلیشن برای مانیتورهای ۱۷ اینچ معمولی (اغلب غیر ال سی دی) استاندارد محسوب میشه. هرچند بعضی روی رزولیشنهای بالاتر تنظیم میکنن.
بعنوان تست های نهایی میتونید روزلیشن رو روی مقدارهای دیگر مثل ۸۰۰ در ۶۰۰ و یا بالاتر از ۱۰۲۴ در ۷۶۸ هم تنظیم کرده و نما و کارکرد سایت خودتون رو در این حالت ببینید. اغلب ممکنه با تغییرات کمی در این حالت بتونید سایت رو برای رزولیشن های بالاتر و پایینتری که کمیاب نیستن هم مناسبتر کنید. ممکنه متوجه بشید که بخشهایی از نما یا حتی کارکرد سایت در حالتهای دیگر اصلا خوب نیستن و دچار اختلال میشن، و حداقل میشه سعی کرد که کارکرد و نما رو بحد قابل قبول رساند.
گاهی میشه سازگارسازیهایی کم هزینه ای انجام داد که در عین حفظ کیفیت و زیبایی سایت در استاندارد اصلی طراحی شده، انعطاف کار شما رو برای شرایط دیگر هم بالا ببره.
بطور کلی میشه گفت دراینمورد، و درواقع درمورد هر برنامه ای، نه تنها برنامه های وب، هر تست و تغییر متعاقبی رو که میشه با هزینهء قابل قبول انجام داد باید انجام داد. اما مسلما مهمتر از همه و دارای اولویت، کارکرد و نما در شرایط استاندارد هست و نوع عمدهء کاربرد و کاربر برنامه.

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

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

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

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

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

نکتهء دیگر در رابطه با محیط طراحی و توسعهء برنامه، قدرت و سرعت سیستم هست که دراینمورد هم باید دقت کافی رو داشت. شما سایتی رو طراحی میکنید و روی سیستم قوی و سریع شما بنظر میاد بخوبی کار میکنه، اما وقتی از طریق اینترنت یا بهر طریق دیگری روی سیستم کاربران دیگری میره که از سیستمهای متوسط متداول استفاده میکنن دچار افت کارایی و کیفیت میشه (این مسئله جدای از حجم سایت و سرعت اینترنت هست که بعدا بهش میپردازیم)؛ گاهی در حدی که واقعا اشکال فنی بزرگی محسوب میشه.
بیاد داشته باشید که اغلب هدف و مزیت بسیار بزرگ یک سایت در محیطی عمومی و جهانی همچون اینترنت، قابل استفاده (یا تحمل!!) بودن برای بخش عمدهء کاربران هست.
گاهی اشکالات در این زمینه خیلی ساده و پنهان هستن. موضوع میتونه کاربرد فلش و جاوا و تعداد زیاد عکسهای حجیم و جلوه های پیچیدهء جاوااسکریپت نباشه، بلکه خیلی ساده تر و غیرقابل حدس تر از این حرفها باشه.
بطور مثال بنده تصویری رو در زمینهء صفحهء وبی انداخته بودم و برای اینکه تصویر با هر رزولیشنی خودش رو تطبیق بده اون رو بصورت یک لایهء زیرین (و نه بکگراند معمولی) که با عرض و ارتفاع ۱۰۰٪ تعریف شده بود زیر بقیهء محتویات صفحه قرار داده بودم. این صفحه در سیستم محیط توسعه و طراحی خوب و بدون مشکل بنظر میرسید، ولی وقتی از قضا اون رو روی سیستم دیگری که یک سیستم ضعیف هم نبود، بلکه متوسط بود، بردم، کند شدن صفحه توسط عکس زیرین که مرورگر مجبور بود اون رو با درنظر گرفتن ابعاد صفحه با مقیاس مورد نظر بزرگ یا کوچک بکنه و احتمالا به علت دیگر اینکه مجبور بود با روشی غیر از الگوریتم بکگراند معمولی پردازش بکنه کاملا مشخص شد و به کارایی کلی کار صدمهء غیرقابل قبول می زد؛ بنابراین مجبور شدم از این قابلیت صرفنظر کنم و به همون تکرار شدن و به شکل کاشی قرار گرفتن بکگراند در رزولیشن های دیگر راضی باشم، هرچند نمای کمتر زیبایی داشت.
اگر این نکته رو متوجه نشیم ممکنه حتی از قابلیتهای برنامه نویسی در اینطور زمینه ها بعنوان جایگزین روشهای دیگر استفاده کنیم. مثلا بجای افزایش سایز اصلی یک تصویر با برنامه های ویرایش تصویر برای اینکه تمامی زمینه رو در رزولیشن استاندارد پوشش بده، ممکنه از چنین روشی استفاده کنیم؛ درحالیکه این روش بار پردازشی بیش از حد مورد انتظار رو داره. در عین حال ممکنه چنین روشی در بعضی جاها، مثلا تصاویر کوچک مستقل، بدون مشکل باشه و کاملا مفید که نقشهای لازم رو ایفا بکنه، اما در جای دیگر نه. بنابراین اغلب قاعدهء کلی ای وجود نداره و تنها باید تست کرد.
حتی در یک سیستم قوی هم چنین صفحاتی با اینکه بصورت منفرد ظاهرا مشکلی ندارن، اما عملا با مصرف زیاد منابع سیستم ایجاد پتانسیل اشکال میکنن. کاربر انتظار نداره که یک صفحهء ساده و عادی بخش بزرگی از منابع سیستمش رو مصرف کنه و ممکنه اصلا متوجه علت کندی سیستم یا مرورگر نشه. درحالیکه کاربر برنامه ها یا صفحه های کافی دیگری روی سیستم خودش باز داره، مصرف منابع بالای صفحات شما میتونه تاثیر مشهود خودش رو ایجاد کنه و سیستم کاربر دچار مشکلات مشهود بشه.

بنظر میرسه تنها چاره برای کشف چنین خصوصیاتی، تست نهایی صفحه روی یک سیستم متوسط باشه (البته مسلما اگر سیستم کار خودتون واقعا قوی هست و نه متوسط).


تا بعد...

eshpilen
دوشنبه 21 تیر 1389, 21:43 عصر
خب مورد کلاسیک دیگر که درمورد بهینه سازی و طراحی و توسعهء صفحات وب گفته میشه مربوط به حجم صفحات و سرعت محدود ارتباط اینترنتی بسیاری از کاربران هست.
بطور کلی حتی با فرض وجود اینترنتهای پرسرعت تر هم نباید به افزایش بی رویهء حجم صفحات بی توجه بود، چون بهرحال اینترنت یک شبکه هست و سرعت و پهنای باند و ظرفیتش نسبت به محیط داخل یک رایانهء شخصی بازهم تفاوت زیادی میکنه و افزایش حجم و ترافیک مفرط منجر به مشکلات متعددی برای خود و دیگران که از این منبع اشتراکی استفاده میکنن میتونه باشه. حتی در یک مقیاس جهانی و حتی برای آیندهء دور و نزدیک.

معمولا پهنای باند و ظرفیت ماهیانه و حجم فضای هاست و منابع دیگر سرور هم نسبت به یک رایانهء شخصی خیلی محدودتر و گرانتر هستن و بابتشون هزینه ای بصورت اجاره پرداخته میشه و اگر هم از میزان تعیین شده تجاوز بشه معمولا مشکلات جدی پیش میاد که حلش مدتی زمان میبره.

وقتی شما عکسی رو روی اینترنت میذارید باید توجه کنید که حجم و اندازهء اون چقدر هست. خصوصا که دوربین های دیجیتال امروزی عکسهایی با کیفیت و اندازه و حجم بالا میگیرن و عده ای ممکنه این عکسها رو بدون تطبیق با محیط وب یا اشتباها روی اینترنت قرار بدن. البته گذاشتن نسخه های کیفیت بالا و کامل برای دیدن یا دانلود اختیاری مسلما مانعی نداره، اما نباید گزینه ای باشه که کاربر نتونه دورش بزنه یا چیز دیگری رو جایگزینش کنه.
معمولا تصاویری با اندازه و کیفیت و حجم کوچک رو برای پیش مشاهده و انتخاب قرار میدن، و عکسهای بزرگتر و با کیفیت تر رو برای دانلود/نمایش اختیاری (مثلا با کلیک بر روی عکس کوچکتر)؛ و درمورد عکسهایی با کیفیت و سایز و حجم بالا میشه و احتمالا منطقی هست که سه اندازهء کوچک (پیش نمایش)، بزرگ (کیفیت و حجم متوسط برای اغلب کاربران با اینترنت سرعت پایین)، و کامل (عکس اصلی با کیفیت و سایز کامل) رو بعنوان گزینه در دسترس کاربران قرار بدیم.
به این روشها، شما سیاستی رو هم برای جلوگیری از مصرف مفرط پهنای باند و منابع سرور توسط کلیک اشتباه و تصادفی یا سرسری و اجباری کاربران پیاده سازی کردید.
شاید مثل بحث قبلی بهترین راه برای یک تست واقعی، آزمایش در شرایط واقعی باشه. یعنی موقعی که سایت روی اینترنت هست از طریق یک اتصال دیالاپ ۵۶ کیلوبیت استاندارد. اما اینکار مستلزم آپلود سایت و فراهم کردن امکانات لازم و هزینه های خودش هست و اینکه بخوایم دانه بدانهء صفحات رو در این حالت تست کنیم مقداری آزار دهنده بنظر میاد.
اگر ویندوز دارید بنده با راهی برای شبیه سازی این وضعیت آشنا نیستم اما در گنو/لینوکس که محیط کار مطلوبم برای برنامه نویسی وب هست براحتی میشه با فرمان های خاصی سرعت ارتباط سرور مجازی سیستم محلی رو تنظیم و محدود کرد.
این فرمان در گنو/لینوکس سرعت ارتباط شما رو روی ۵۶ کیلوبیت در ثانیه تنظیم میکنه:


tc qdisc del dev lo root; tc qdisc add dev lo root handle 1: htb default 1; tc class add dev lo parent 1: classid 1:1 htb rate 56kbit

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

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

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

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

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

درمورد کاهش حجم و حجم بهینهء تصاویر پارامترهای متعددی دخیل هستن که مهمترین اونها که به ذهن بنده میرسن اینها هستن: ابعاد - کیفیت - وضوح رنگ - فرمت.
شما میتونید با اطلاع فنی از ماهیت و خاصیت هرکدام از این پارامترها با یک یا معدودی حدس و تست، یک تصویر بهینه رو بدست بیارید.
شاید برای یک لوگوی مشترک خاص که محتوی تصویر ظریفی هست استفاده از یک تصویر با کیفیت خوب در فرمت PNG بهترین گزینه باشه. چون بهرصورت حجم زیادی نخواهد داشت؛ گرچه یک کیفیت و فرمت دیگر حجمی چند برابر کمتر داشته باشه، اما ارزش این کیفیت بالا و چشمگیر بودنش بقدر کافی جبران مافات بکنه.
جای دیگه ممکنه سایز یا کیفیت یا فرمت و یا همهء پارامترها رو با تناسب یا به درجات مختلف نسبت به همدیگر، بسته به کاربرد و هدف و رضایت خودمون تغییر بدیم. تغییر پارامترهای مختلف در کاربردهای مختلف و همینطور روی عکسهای مختلف با محتویات متفاوت میتونه بحد بسیار قابل توجهی باهم تفاوت در نتیجه داشته باشه. اغلب یک طراح حرفه ای میتونه تاحد زیادی حدس بزنه و در نهایت با تست های مختلف میشه مطمئن شد و به تجربه هم دست یافت. فقط نباید کورکورانه و بدون دانش و تحقیق کار کرد، و سعی کرد که فهمید هرچیز چطوری عمل میکنه و چه خاصیتی داره.
خواندن مقاله های فنی در این زمینه خیلی وقتها نیاز هست. شما باید بدونید که هر فرمت و استانداردی یعنی چی و چه خواصی داره.

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

امیدوارم بنده رو بخاطر این خطابهء اخلاقی-رایانه ای (!!) ببخشید.

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

eshpilen
دوشنبه 21 تیر 1389, 21:44 عصر
در طراحی ها تا حد امکان باید از کاربرد تصویر بجای متن خودداری کنیم. البته منظور کاربرد تصویر به خودی خود و در نقش و کاربرد خودش یا همراه با متن نیست، بلکه جایگزین کردنش بجای متن درجایی که متن به تنهایی محتوا و هدف رو بطور کامل و دقیق و مختصر میرسونه هست. مثال عمدهء این نوع کاربرد، دکمه ها و لینک های تصویری برای انجام عملیات خاص یا انتقال به بخشهای دیگر سایت هستن.

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

پاره ای از مزایای متن:
- اطلاعات متنی قابل جستجو و پردازش توسط رایانه و برنامه های خودکار هست؛ منجمله موتورهای جستجو.
- اطلاعات متنی بسیار راحتتر از تصویر قابل ویرایش و تغییر شکل هستن. هرچند محدودیت ظاهر متن از گرافیک بیشتر هست، اما سرعت و راحتی این تغییرات مزایای بزرگتری هست. شما میتونید یک متن رو به سرعت ویرایش کنید و فرمت نمایشی اون رو هم با انعطاف و گستردگی گزینه خوبی تغییر بدید، اما یک تصویر اغلب نیاز به کار گرافیکی و وقت و انرژی خیلی بیشتری برای ویرایش و تغییر ظاهر داره.
- حجم اطلاعات متنی بسیار کم هست. البته این قضیه درصورتی مصداق داره که متن جایگزین تصویر بشه و نه اینکه هردو رو همزمان بصورت مکمل داشته باشیم.
- متن در هر سیستمی با هر تنظیماتی نمایش داده میشه، اما گرافیک کمتر این قابلیت رو داره و نمایش گرافیک میتونه بطور موقتی یا دایمی غیرفعال شده باشه. هرچند این گزینه امروزه خیلی جدی نیست، حداقل روی سیستمهای رایانهء شخصی و دسکتاپ مدرن، اما در عین حال توجه کنید که متن قبل از تصاویر بارگذاری و نمایش داده میشه و در خلال مدتی که متن داریم و تصویر نداریم این میتونه مزیتی بحساب بیاد. بخصوص با اینترنت های دیالاپ که بنظرم هنوز در سراسر جهان متداول هستن و به این زودی منقرض و بدون کاربرد نمیشن. ضمنا بعضی وقتها هم بعلت ترافیک بالا یا کد شدن سرور و یا حتی سیستم کاربر این سرعت پایین لود شدن پیش میاد.
چند بار برای بنده در همین فروم پیش آمد که مدتی مجبور به لود شدن کامل صفحهء تالار شدم تا بتونم تازه روی دکمهء درج موضوع جدید کلیک کنم، چون ظاهرا این دکمه فقط بصورت گرافیکی هست و جایگزین متنی برای درنظر گرفته نشده؛ درحالیکه میشد از اتلاف این زمان و مقداری هم پهنای باند مصرف شده، با وجود یک آلترناتیو یا مکمل متنی براحتی جلوگیری کرد.
منظور از مکمل متنی، چیزی هست که فرضا در زیر تصویر نوشته میشه یا وجود داره (مثلا یک دکمه) و معمولا بصورت لینک هست، یا متنی که تا قبل از لود شدن تصویر بجای تصویر نمایش داده میشه و گزینه رو قابل شناسایی (از روی محتوای متن) و همچنین انتخاب (کلیک کردن) میکنه.
اگر این جایگزین و مکمل وجود نداشته باشه در وهلهء اول اغلب نمیشه از کاربرد و هدف لینک موجود مطمئن بود و در وهلهء دیگر ممکنه اصلا وجود گزینه ای مشخص و/یا قابل کلیک نباشه.
- متن توسط کاربر قابل انتخاب کردن و کپی کردن و همچنین جستجو کردن در صفحه هست که گاه واقعا کاربردهای مفیدی داره. مثلا گاهی جستجو برای گزینه و تنظیم و دکمه ای در صفحات حجیم و پیچیده بوسیلهء متن مورد نظر کار رو خیلی سریع تر و راحت تر و مطمئن تر میکنه که این امکان برای کاربران حرفه ای و هوشمند و سریع واقعا بدرد میخوره. بعضی وقتها هم انتخاب و کپی کردن متن اطلاعات، گزینه، یا لینک، کاربردهایی پیدا میکنه.

بنده در یک پروژه دکمه هایی رو با ظاهر زیبا درست کردم که در عین اینکه شبیه دکمه های تماما گرافیکی هستن و عکس العمل گرافیکی مناسب هم دارن (با رفتن موس روی اونها یا کلیک جلوهء گرافیکی اونها عوض میشه) اما نوشتهء روی اونها متن هست. درواقع اونها سلول یا لایه ای متنی هستی که طول و عرض اونها به اندازهء دلخواه محدود شده و جلوه های گرافیکی لازم هم بوسیلهء انداختن یک تصویر گرافیکی مناسب برای دکمه در زمینهء سلول (background) تامین شده.

درج ویژگی alt برای تگ تصاویر رو فراموش نکنید. این متن قبل از ظاهر شدن گرافیک نمایش داده میشه و چنانچه تصویر به هر دلیلی لود و نمایش داده نشه جایگزین تصویر خواهد بود. تقریبا تمامی تصاویر باید alt داشته باشن.
برای تگ تصاویر میشه از ویژگی title هم استفاده کرد که موقع نگه داشتن ماوس روی تصویر نمایش داده میشه. یک متن توضیحی گزینهء مناسبی هست.
مرورگر اینترنت اکسپلورر درصورت عدم وجود متن title متن alt رو (درصورت وجود) به همین صورت هم بکار میبره. یعنی هم جایگزین تصویر هست و هم با نگه داشتن ماوس نمایش داده میشه. بسته به مورد این عملکرد میتونه مطلوب یا نامطلوب باشه و راه تغییر دادنش بنظرم قرار دادن هردوی این ویژگیها هست (هرچند یکی با متن خالی).

هرجا تصویری قابل ابهام هست سعی کنید اول از متن زیرنویس و بعد درصورت عدم امکانش، بعنوان جایگزین از title استفاده کنید. بخصوص درمورد تصاویر لینک شده.
ضمنا عکس العمل و نشانهء لینک بودن رو روی این متنهای زیرنویس میشه پیاده کرد که به تشخیص و زیبایی و خوشایند کاربر کمک میکنن. روی تصویر هم میشه در این زمینه کارهایی کرد، ولی اغلب انجامشون روی متن راحتتر و اصولی تر و زیباتر و عملی تر هست.
مثلا موقعی که موس روی تصویر لینک شده ای میره رنگ متن زیرنویس عوض بشه. تمام این کارها رو میشه اغلب تنها با CSS انجام داد.

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

eshpilen
دوشنبه 21 تیر 1389, 21:45 عصر
خب این سری میخوایم یک نکتهء کوچک ولی کاربردی و جالب در ارتباط با اهداف این تاپیک رو بگیم.
این نکته درمورد image preloading هست.
اگر با این مطلب قبلا برخورد کرده باشید، که یک برنامه نویس وب حرفه ای حتما باید برخورد کرده باشه، چگونگی و چرایی اونو میدونید.
در این روش ما بعضی از تصاویری رو که صفحهء وب ما در وهلهء اول نیاز نداره ولی هنگام تعامل کاربر با صفحه مورد استفاده دارن طوری در مرورگر پیشاپیش لود میکنیم، تا موقع نیاز به سرعت قابل اعمال باشن.
مثلا یک دکمهء تصویری رو درنظر بگیرید که قرار هست وقتی موس کاربر روش میره تصویر دیگری رو بجای تصویر اولیه نمایش بده. خب بدیهی هست که در اینکار تقریبا نباید تاخیر زمانی ای وجود داشته باشه. اما اگر تصویر بعدی رو پیشاپیش لود نکرده باشیم یا بعبارت کلی تر در کش مرورگر موجود نباشه، این امر ممکنه برای کاربر حداقل چند ثانیه طول بکشه که این امر واقعا نامطلوب هست و گاهی علاوه بر کاهش زیبایی و جذابیت صفحه کل منطق کار رو هم دچار مشکل میکنه.
متدی که برای preloading تصاویر در بیشتر منابع ذکر شده و اکثر برنامه نویسان آموختن و بکار میبندن استفاده از جاوااسکریپت هست.
یک نمونه از کد جاوااسکریپتی که این کار رو انجام میده:


img1=new Image();
img1.src='/image/bt2.jpg';

این کد باعث میشه تصویری که در آدرس /image/bt2.jpg در سایت مورد نظر قرار داره پیشاپیش توسط مرورگر لود بشه.

اما ما در اینجا میخوایم یک روش نسبتا ناشناخته تر که بهتر از روش جاوااسکریپت بنظر میرسه رو بگیم. به این روش در منابع کمتری و بنظرم منابع جدیدتر اشاره شده.
این روش مبتنی بر CSS است و مزیتش اینه که درصورت خاموش بودن یا عدم وجود جاوااسکریپت هم کار میکنه.
میتونم بگم مزیت دیگر اون کمتر بودن احتمال خطا در این زمینه هست.
نمونهء چنین کدی:


<img src="/image/bt2.jpg" style="display: none">

یا به اینصورت که خوانایی بیشتری داره:


<img src="/image/bt2.jpg" class="preload">

و در اینصورت در قسمت استایل سند حتما تعریف کردیم که تگ ها یا تگ های تصاویری با کلاس preload نمایش داده نمیشن.

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

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

بعضی برنامه نویسان (!) حتی از این قضیهء preloading اطلاع ندارن یا فراموشش میکنن. بطور مثال یک شرکتی برای دایی بنده سایت زیبایی درست کرده بودن ولی بعلت پیاده نکردن این متد کار خودشون رو خراب کرده بودن.
راستی میبینید که همونطور که گفتم تست سایت طراحی شده با خالی کردن کش مرورگر و تست صفحات در شرایط واقعی یا شبیه سازی شدهء سرعت پایین اتصال اینترنتی میتونه در آشکار شدن این قبیل اشکالات کمک بسیار مفیدی باشه.

شاید بنظر برسه این روش کاربرد جاوااسکریپت رو در این زمینه تقریبا منسوخ بکنه، که بنظر بنده تا حد زیادی اینطور هست (خودم دیگه از این روش استفاده میکنم)، اما احتمالا روش جاوااسکریپت هم بجای خودش میتونه کاربرد داشته باشه. مثلا فرض کنید ما صفحه رو طوری طراحی میکنیم که بصورت رندوم در هر بار لود شدن از تصاویر مختلفی برای کار خاصی و تعامل با کاربر استفاده بکنه، اگر ما کد مربوط به این کار رو در سمت کلاینت پیاده بکنیم (که رویهء معمول و گاه ضروری ای هست) یا باید همهء تصاویر ممکن رو preloading بکنیم و یا بوسیلهء جاوااسکریپت اونها رو که نیاز به preload دارن واکشی کنیم. لود کردن همهء تصاویر بخصوص اگر تعداد تصاویر ممکن زیاد و/یا تصاویر حجیم باشن میتونه راه مناسبی نباشه، پس دست به دامن جاوااسکریپت میشیم.

eshpilen
دوشنبه 21 تیر 1389, 21:46 عصر
گاهی به اشکالات منطقی ای در طراحی سیستم برمیخوریم که به ظاهر کوچک هستن، اما نباید ازشون غفلت کرد.
حتی در سایتهایی که خودشون ادعای طراحی سایت دارن و یا اصولا حرفهء اونها هست اشکالات و نقصهای کوچک و بزرگ در طراحی دیده میشه. مثلا تازگی یک مورد در یک سایت که خودش شرکت معروف و معتبری هست و خدمات دامین و هاست میده و سایت هم طراحی میکنه دیدم. البته از این دست یکی دوتا نیست و با این مو از ماست کشیدن ما اکثر سایتها به مشکل میخورن!!
یک اشکال دیگه این هست که متاسفانه سایتهای متعددی رو میشه دید که مثلا نمایش اونها در مرورگر فایرفاکس یا مرورگری غیراز اینترنت اکسپلورر بهم ریخته هست و معمولا اشکال کار در همون متد نادیده گیری (!) توسط توسعه دهندگان سایت هست که میشه اسم تنبلی و بعضی وقتا تعصب و آزار هم روش گذاشت. البته احتمالا بعدا از این موضوع دوباره صحبت خواهیم کرد.
یا الان چیزی که انگیزهء نوشتن این پست خارج از برنامه شد یک ضعف منطقی در سیستم همین فروم بود!
بنده یک تاپیک در یکی از تالارها ایجاد کردم و بعد رفتم به یک Tab دیگه و صفحهء دیگری رو داشتم نگاه میکردم، برگشتم ببینم تاپیک ارسال شده دم کشیده یا نه (!) که دیدم صفحه فقط صفحهء اول اون تالار رو نشون میده و هیچ خبر دیگه ای از سرنوشت تاپیکی که ارسال کرده بودم موجود نیست. البته من چون با این سیستم قبلا برخورد کرده بودم میدونستم که چی شده: یک پیغام که میگه تاپیک شما پس از بررسی شدن توسط مدیر میتونه در تالار درج بشه میاد و این پیغام در عرض یکی دو ثانیه، یا مقداری کمتر و بیشتر، دیگه دیده نمیشه چون این صفحهء حاوی پیغام، طرف رو بطور خودکار به صفحهء اول تالار میفرسته!
خب این از نظر من یک ضعف در منطق طراحی هست. و این ضعف حتی بر اساس زمان بیش از حد کمی که برای مشاهدهء یک چنین پیغامی درنظر گرفته شده تایید بیشتری هم میشه (یعنی نشون میده توجه کافی و واقع گرایانه به ظرافتهای منطقی کار نداشتن).
اصولا صفحات محتوی اطلاعات برای کاربر نباید با این فرض کار کنن که کاربر در تمام مدت به صفحه چشم دوخته و در یک زمان خاص هم با سرعت و بدون گسیختگی یک پیغام رو میخونه، و بعد بطور خودکار بخصوص تقریبا بدون قابلیت آگاه شدن کاربر از وجود چنین پیغامی و امکان پیگیری محو بشن. این قاعده تنها با منطقهای دیگه میتونه نادیده گرفته بشه (یا بهتر بگیم که مصداق نداشته باشه)؛ فرضا پیغام خیلی مهم و ضروری نیست و نقش یک مکمل فرعی و کمکی در همون شرایط گذرا رو ایفا میکنه (مثل مورد پست زدن در تاپیک ها که بطور خودکار به پست درج شده هدایت میشیم)، و یا بهرعلتی چنین رفتاری مزایا و ضرورتهایی داره که توجیهش میکنه.
اما درمورد صفحهء اطلاعاتی مربوط به درج تاپیک، بنظرم قاعدهء ما مصداق داره. باید صفحه با پیامش ثابت بمونه تا خودمون روی لینک یا دکمهء رفتن به صفحهء هدف دیگری کلیک کنیم.
در اینجا رفتار هدایت خودکار مرورگر به صفحهء دیگر چندان کاربرد و ارزش فنی و کاربرپسندی خاصی هم نداره، درحالیکه اطلاع از سرنوشت تاپیک و اصولا اطمینان از انجام درست هدفی که کاربر داشته امر مهمتری هست که عدم اطلاع ازش میتونه موجب سردرگمی و اشتباه و تکرار عملیات از طرف کاربر بشه یا اصلا نفهمه چه اتفاقی افتاده و فکر کنه نقصی در طرف خودش یا طرف دیگر بوده. گاهی هم حتی کاربر ممکنه فکر کنه عملیات دقیقا طبق نظرش انجام شده و حافظه و دقت کافی برای مطلع شدن از وجود یک چنین سیستمی بخرج نداده باشه، و این هم حالت بدی هست. فرض کنید شما تاپیکی میزنید و فکر میکنید درج شده و بعد از چند روز برای پیگیری میایید و تازه میبینید که اصولا تاپیکی وجود نداره! ممکنه شما عجله داشتید و اگر این قضیه رو میدونستید از راههای دیگری و جاهای دیگری هم اقدام میکردید؛ و در یک حداقل احتمالا کار و هدف شما دچار تاخیر و اتلاف منابع شده.
این نکات ساده هستن، بنظر کوچک میان، اما مهم هستن و نیاز به تفکر منطقی دقیق و توجه به ظرایف کار برنامه نویسی اصولی دارن. و اینکار تنها از عهدهء برنامه نویسان حرفه ای واقعی و کسانی که در این امور بقدر کافی دقت و تفکر داشتن برمیاد.

راستی یک قاعدهء هم خانواده با این قاعده ای که گفتم هم بنظر من وجود داره که میگه باید مرحلهء آخر هر عملیات خاصی که کاربر رو نسبت به برنامه (در اینجا برنامه و صفحات وب) به وضعیت/حالت (mode) دیگری میبره، به صورت مناسب (بقدر کافی واضح و قابل پیگیری) به اطلاع کاربر برسه. حالا خود این مناسب بودن قابل تفکر و تعریف و معیار بندی بنظر میرسه. مثلا یک صفحهء تمام و یک پیغام بزرگ به اینکار اختصاص داده بشه یا صرفا یک نمود گرافیکی و تغییر صفحه توسط ajax و یا صرفا اضافه شدن گزینه هایی که بطور ضمنی این معنا رو میدن و غیره. این بحث خودش رو داره که فعلا ایده و تمرکز فکری روش ندارم و در این پست که میخواستم مختصر باشه بهش نمیپردازم.
خب احتمالا اصلا هنوز متوجه نشدید این تغییر وضعیت و حالت و mode دقیقا یعنی چی!
خب براتون میگم!
مثلا وقتی کاربر لاگین میکنه یا لاگ آوت. این عملیات میشه گفت حداقل از جنبه هایی، کاربر رو به mode دیگری میبره (از مهمان و ویزیتور عادی به کاربری دارای هویت ثبت شده و یکتا در سیستم که مجوزها و نحوهء تعامل و عملیات ویژه ای در سیستم براش تعریف شده) و اینبار عملیات کاربر و گزینه های در دسترس میتونه معنا و موجودیت متفاوتی داشته باشه.
دربارهء اینکه mode در برنامه نویسی چیه واقعا مقالات علمی و رسمی وجود داره و این مسئله یک مسئله ای نیست که بنده اختراعش کرده باشم و گندش بکنم، اما ازش در اینمورد الهام گرفتم و بسطش دادم و این قضیه در وهلهء اول شاید با اون مقوله بی ارتباط بنظر برسه، اما بنظر بنده اگر خوب دقت کنیم در ماهیت و مفاهیم و استدلال مشترکات کافی دارن تا بهش اشاره شده و بعنوان سند و رفرنس تحقیق بکار بره.

eshpilen
دوشنبه 21 تیر 1389, 21:46 عصر
خب ظاهرا یک متد کوچک و مفید برای تست و تنظیم نهایی سایت رو نگفتم.
موضوع از این قراره:
- کش مرورگر رو خالی کنید.
- دایرکتوری مربوط به تصاویر سایت خودتون رو موقتا حذف کنید، یا راه امن تر اینکه اسمش رو تغییر بدید؛ مثلا از image به image__.
- در این حالت نما و قابلیت کارکرد سایت خودتون رو وارسی کنید!

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

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

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

eshpilen
دوشنبه 21 تیر 1389, 21:47 عصر
خب مطلب دیگه که میخوام بگم مربوط به طراحی منوها و بطور کلی بخشهای قابل کلیکی میشه که ما رو به صفحات/فایلهای دیگری هدایت میکنن، اما این گزینه ها برخلاف لینک های عادی استاندارد بعلل مختلفی با جاوااسکریپت کار میکنن. مثلا خیلی از سایتها از منوهایی استفاده میکنن که با جاوااسکریپت کار میکنن چون جلوه ها و کارکردهایی رو که در این منوها میخوایم با روشهای دیگر و حتی CSS (به تنهایی) قابل ایجاد نیستن. مثلا منوهای دینامیک، drop down و غیره. یا مثلا میخوایم هدف (صفحه/فایل مقصد) در یک پنجرهء تنظیم شده توسط جاوااسکریپت باز بشه (با استفاده از متد window.open)؛ البته در عمل بعضی ها چنین نیازی هم ندارن اما بعلت غرق بودن در تفکر تک بعدی جاوااسکریپتی (!) فعال کردن گزینه ها رو با جاوااسکریپت انجام میدن و نه بصورت لینک، و این بنظرم ناشیانه ترین نوع اشتباه در این زمینه هست.

نقص و نکتهء مهمی که در این ارتباط میخوام بگم اینه که گزینه های این منوها، باوجود اینکه منوها با جاوااسکریپت کار میکنن و بدون جاوااسکریپت ممکنه اصولا در دسترس نباشن، باید بصورت لینک عادی هم قابل استفاده باشه.
مثلا در یک سایت که خودش اختصاص به شرکتی داشت که طراحی وب میکنه نمونه ای از این منوها بود که فقط میشد روش کلیک کرد و کل عملیات با جاوااسکریپت قابل کنترل بود. نتیجه این بود که:
۱) هدف قبل از کلیک کردن روی لینک قابل تشخیص نبود (فقط از onclick استفاده شده بود و خبری از لینک و href که در نوار وضعیت مرورگر نمایش داده میشه نبود).
توضیح اینکه نمایش داده شدن آدرس هدف در نوار وضعیت مرورگر یک عامل اطلاعاتی مفید هست و بخصوص برای کاربران حرفه ای مورد توجه و کاربرد هست؛ باوجود اینکه متن گزینه خودش اطلاعاتی رو میرسونه اما آگاهی از آدرس دقیق گزینه اغلب اطلاعات مفید مکمل و کاربرد خودش رو داره.
۲) شما قادر نبودید براحتی با کلیک راست کردن روی گزینهء مورد نظر، صفحهء مقصد رو در یک پنجره یا تب (Tab) جداگانه باز کنید و هدف فقط طبق تعریف در صفحهء جاری باز میشد.
۳) اگر جاوااسکریپت فعال نباشه یا اسکریپت درست کار نکنه، حتی اگر گزینه ها در این حالت قابل رویت باشن قابل استفاده نخواهند بود.
۴) و سرانجام یک مجموعه جزییات و کاربردهای کوچکتر و خاصتر دیگه؛ مثلا بوکمارک (bookmark) کردن (در اینترنت اکسپلورر به favorite معروف هست) با کلیک راست و غیره.
شاید بگید بعضی از اینها با روشهای دیگه هم قابل انجام هستن؛ باید گفت بله، ولی نه به راحتی و سرعت حالتی که گزینه ها بصورت لینک باشن و نه همیشه قابل توجه و استفاده برای کاربران نسبتا ضعیف و غیرمتخصص.

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

شاید بهتر باشه چند نمونه کد هم بدم.
نمونهء یک گزینه منوی غلط اینطوری هست:


<div onclick="location.href='page1.html'" class="menu_i">item1</div>

این کار میکنه اما ضعفهایی رو که گفتم داره.
حتی اگر از تگ a بجای div استفاده کنیم اما بهش href استاندارد و درست ندیم فایدهء چندانی نداره.
نمونهء یک گزینه منوی عالی:


<a href="page1.html" onclick="return click_func(args)" class="menu_i">item1</a>

این گزینهء منو، هم لینک هست و هم با گذاشتن بخش onclick نشون دادم که درصورت نیاز میتونه با جاوااسکریپت هم کار کنه. args بعلاوهء پارامترهای دیگر معمولا شامل آدرس مورد نظر یا مشخصهء دیگری هست که باعث میشه تابع اجرا شونده بدونه روی کدوم لینک کلیک شده یا باید چکار بکنه.
چون در قسمت onclick از return استفاده کردیم تابع click_func میتونه با برگرداندن false براحتی از اجرای بخش href لینک جلوگیری بکنه تا دو بخش با هم تداخل نکنن.
توجه کنید درصورتیکه کاربر با کلیک راست روی گزینه لینک رو فعال کنه، چه open و چه open in new window/tab رو انتخاب کنه، رویداد onclick فعال نمیشه؛ بنابراین این انعطاف و کارایی اضافه به گزینه های شما افزوده میشه.

eshpilen
دوشنبه 21 تیر 1389, 21:48 عصر
خب یه مسئلهء دیگه ای که میخوام مطرح کنم مربوط به سایتهای خرید آنلاین میشه.
ما در بسیاری از این سایتها می بینیم که مراجعه کننده رو برای امکان خرید ملزم به «ابتدا ثبت نام در سایت» میکنن.
بنظرم پیروی از این خط مشی اشتباه رو باید کنار گذاشت که برای هر خریدی هر مراجعه کننده نیاز به ثبت نام داشته باشه.
بنظر بنده به دلایل متعدد اینکار در خیلی موارد درست نیست، اما خیلی از سایتها اینکار رو میکنن و سیستمهای خرید الکترونیکی رو اینطور طراحی میکنن.
بسیاری از کاربران تنها یکبار یا تعداد بسیار محدودی و/یا با فاصلهء زیاد، میخوان فقط خرید کنن، و نه کار دیگه ای.
وارد کردن آدرس و مشخصات در این حالت معضلی نیست، بلکه اجبار به ثبت نام و وارد و ثبت کردن اطلاعات مختلف و گاهی نامربوط معضل بحساب میاد.
تازه بعضی وقتها آدرس طرف ممکنه عوض شده باشه و یادش بره در سیستم فروشگاه تصحیح کنه، پس هربار که آدرس رو دستی وارد کنن بهتره.
البته ثبت نام هم میتونه یک گزینهء اختیاری باشه با ذکر خواص و مزایا و کاربردش، و در مواردی هم ممکنه لازم باشه، اما کلی نیست.

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

eshpilen
دوشنبه 21 تیر 1389, 21:49 عصر
از هر تکنولوژی، جلوه، و سبک و روشی باید در جای خودش استفاده کرد.
بطور مثال اینکه AJAX خیلی مفید و جالبه دلیل نمیشه ما هرجایی بخوایم روشهای عادی و استاندارد رو، به صرف اینکه از قدیم و وقتی AJAX نبوده بکار گرفته میشدن، به روش AJAX تغییر بدیم. خیلی جاها اینکار ضروری نیست و خیلی جاها بهینه نیست و خیلی جاها اصولا منطق درستی نخواهد داشت.

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

فروشگاه من، موقعی که کاربر اجناسی رو در سبد خریدش داره، این گزینه ها رو داره:
- مشاهدهء سبد خرید
- ویرایش سبد خرید
- خالی کردن سبد خرید
این گزینه ها هرکدام کاربر رو به صفحهء مخصوص انجام عملیات مورد نظر هدایت میکنن.
دسترسی به گزینهء نهایی «ارسال سفارش» فقط از طریق صفحهء «مشاهدهء سبد خرید» امکان پذیر هست. این باعث میشه کاربر قبل از سفارش مجبور باشه حتما از سبد خرید خودش بازدید کنه و به احتمال زیاد صحت سبد خرید و رضایت خودش از اون سبد خرید صریحا مشخص و بنوعی از سوی کاربر تایید بشه. اینکار حداقل میتونه از خیلی از اشتباهات از طرف کاربران و همینطور مشکلات براثر وجود خطا یا محدودیت خاص در سیستم جلوگیری کنه.
یک خرید آنلاین و ارسال سفارش عملیاتی نیست که روزمره و عجولانه بخواد باشه و ضمنا ماهیت مالی و فیزیکی داره و فعالیتی صرفا مجازی با خطاهای براحتی قابل اغماض بحساب نمیاد، بنابراین باید درش تهمیدات و سیاست های خاصی برای جلوگیری از مشکل در اثر خطاهای انسانی یا عدم دقت و وجود اشکال در خود سیستم درنظر گرفته بشه.
ما میتونیم در این سیستم، همچون هر سیستم دیگری، خیلی کارهای ظاهرا جالب و ظاهرا هوشمندانه و کاربرپسند بکنیم، مثلا بخش مشاهده سبد خرید و ویرایش سبد خرید رو باهم یکپارچه بکنیم، اما این کارها لزوما از نظر تهمیدات و منطق و اصول تعامل با کاربر صحیح نیستن یا روشهای بهینه ای برای سیستم بحساب نمیان. مثلا فرض کنید کاربر تعداد کالایی رو کم یا زیاد کرده اما تغییرات رو ذخیره نکرده (یادش رفته یا نمیدونسته نیاز هست اینکار رو بکنه) و بعد به اینصورت به صفحهء ارسال سفارش میره با این ذهنیت که چیزی که آخرین بار دیده اطلاعات نهایی ثبت شده از سبد خریدش بوده.
البته میشه بازهم با تمهیدات بیشتر و پیش بینی سیستمهای هوشمند و با در دسترس گذاری هوشمند گزینه ها و استفاده از پیامهای خطا و هشدار مکمل سعی کرد بر این معایب منطقی غالب شد، اما از سوی دیگر باید درنظر داشت که این تدابیر جریان کارکرد پایهء سیستم و همچنین کدنویسی رو به سرعت پیچیده تر و پیچیده تر و بیش از حد ظریف و شکننده و کمتر قابل پیش بینی حالات مختلف و بنابراین مستعد نقص و باگ میکنه، بدون اینکه کارایی قابل توجهی رو درمقابل این هزینه ها در اختیار گذاشته باشه.
پس بسادگی یک صفحهء ویرایش که با فشردن دکمه «ذخیرهء تغییرات» به صفحهء مشاهدهء سبد خرید آپدیت شده منتقل میشه و از اونجا کاربر میتونه گزینهء «ارسال سفارش» رو انتخاب کنه بنظر بنده کافی و بقدر کافی خوب و منطقی بوده. بدون نیاز به هیچ پیچیدگی بیش از حد و جلوه های بصری خاصی که باید با AJAX پیاده سازی بشن.

در صفحهء ویرایش از جاوااسکریپت برای راحت کردن کار کم و زیاد کردن تعداد هر کالا (دکمه های + و -) همچنین سنجش اعتبار ورودیها در این زمینه استفاده کردم و ضمنا مجموع قیمت ها و هزینهء کل هم بطور خودکار توسط جاوااسکریپت فورا محاسبه و نمایش داده میشه. با این وجود یک دکمه با برچسب «محاسبهء مجدد (بدون ذخیره سازی)» هم قرار دادم تا کاربر درصورت عدم کارکرد جاوااسکریپت بتونه در همون صفحهء ویرایش از محاسبهء خودکار و آپدیت شدن هزینه ها بهره مند بشه؛ یعنی با فشار دادن این دکمه اطلاعات به سرور ارسال شده و نتایج محاسبه شده و بصورت صفحهء ویرایش آپدیت شده به سمت کاربر برگردونده میشن.
البته میشه یک ویژگی دیگر هم به این بخش اضافه کرد و اون اینه که درصورت فعال بودن جاوااسکریپت این دکمهء محاسبهء مجدد نمایش داده نشه؛ درواقع کار خیلی راحتی هست و شاید برای جلوگیری از گیج شدن کاربر مفید باشه.

صفحهء مربوط به «خالی کردن سبد خرید» با سوال «سبد خرید خالی شود؟» شامل دو دکمه با برچسب «بله» و «خیر» هست.
خب مشخصه که منطقی هست برای چنین کاری از کاربر تایید بخوایم تا با یک کلیک اشتباه، حاصل تمام انتخابها و ویرایشهای احتمالی خودش رو از دست نده.

خب این ویژگیها رو گفتم که با یک مثال نشون بدم در هرجایی از متدی که مناسبش هست باید استفاده کنیم. یکجا جاوااسکریپت داریم و ajax و جای دیگه نداریم. لزوما پرجلوه ترین و پیشرفته ترین و پیچیده ترین و ظاهرا هوشمندترین تکنولوژی و روش رو در هرجایی نباید بکار برد و خیلی وقتها این دقیقا خود منشاء اشتباه و ناکارایی عملی هست. بعضی در این زمینه افراط میکنن و عملا باعث کندی کارکرد (در مجموع)، گیج و دچار ابهام و عدم اطمینان بودن کاربران، و تسهیل خطاهای انسانی میشن.

eshpilen
دوشنبه 21 تیر 1389, 21:50 عصر
خب چند اصل کلی ساده ولی مهم، و بازهم مورد کم توجهی، تا پست بعدی:

سایت خودتون رو فقط در یک مرورگر، مثل اینترنت اکسپلورر، تست نکنید؛ بلکه در حداقل دو یا بیشتر از مرورگرهای معروف موجود تست کنید (درحال حاضر فکر میکنم Internet Explorer و Firefox دو نمایندهء خوب باشن).
میتونید موقع طراحی و توسعه از یک مرورگر استفاده کنید، اما در تست های نهایی یا احتمالا تست های میان مرحله ای، مرورگرهای مختلف رو مد نظر داشته باشید. اینطور، برای تطبیق و برطرف کردن مشکلات که اغلب جزیی هستن معمولا وقت و انرژی زیادی صرف نمیشه.

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

تست صفحات در چند مرورگر از چیزی که فکر میکنید مفیدتر و واقعی تر هست و باعث میشه یکسری ریزه کاریها و استانداردها هم دستتون بیاد.
یادتون باشه مرجع استانداردگذاری وب شرکت مایکروسافت و بهترین مرورگر از جنبه های مختلف شامل استاندارد و پشتیبانی از ویژگیهای جدید طراحی شده، اینترنت اکسپلورر نیست.
مرجع اصلی جهانی بسیاری از استانداردهای وب «کنسرسیوم وب» هست! اگر میخواید یک برنامه نویس واقعی و حرفه ای و بین المللی وب باشید این استانداردها رو مطالعه و سعی کنید ازشون پیروی کنید. آدرس کنسرسیوم وب: w3.org
فکر میکنم این منبعی هست که حداقل شما بعنوان برنامه نویس وب باید چند بخش از اون رو کامل یا حداقل بصورت مراجعهء موردی بخونید: HTML، CSS، و DOM.
بنظرم از هرکدام از اینها باید ابتدا آخرین نسخه ای رو که بطور گسترده پیاده سازی شده و مورد کاربرد هست یاد بگیرید، چون بعضی از استانداردهای ارایه شده جدید هستن و/یا هنوز بطور گسترده پیاده سازی شده و قابل استفاده نیستن (یعنی عدم ساپورت مرورگرها و نسخه های متداول اونها در زمان طراحی و توسعهء صفحات وب).
مثلا بسیاری از کاربران احتمالا از IE نسخهء ۶ استفاده خواهند کرد و نه نسخهء بالاتر؛ چون بنظرم این نسخه روی ویندوز ایکس پی بطور پیشفرض قرار داره.
اما درمورد مرورگری مثل فایرفاکس خوشبختانه وضع بهتر هست و بعلت کم حجم بودن و دانلود شدن نسخه های جدیدتر، میشه کاربرد نسخه های بالا از اون رو فرض کرد. ضمنا فایرفاکس مرورگری هست که از ابتدا پشتیبانی خوبی از استانداردها و امکانات جدید داشته. این ادعا بی پایه و سند نیست و فایرفاکس توسط مراجع لازم مورد تست و تایید قرار گرفته.
هرچند وجود باگ و نقص در هر نرم افزاری امکان داره و اغلب اینطور هست و ما چشم بسته همهء تقصیرات رو و احتمال نقص و باگ رو درمورد فایرفاکس رد نمیکنیم، اما در مجموع میشه گفت فایرفاکس در این زمینه برتری داشته و احتمالا هنوز هم (در مقایسه با آخرین نسخه های IE) داره.
اما در عین حال بعلت عقب تر بودن اینترنت اکسپلورر اغلب مجبور هستیم صفحات رو با استانداردها و امکانات کمتری طراحی کنیم! پس میبینیم که این رابطه و محدودیت بخاطر عمومی بودن دو طرفه هست.
و البته ضمنا باید گفت ویژگیها و امکاناتی که فقط در یک مرورگر معروف یا معدودی مرورگر خاص وجود دارن و بخصوص جزء استانداردهای عمومی نیستن عملا چندان برای برنامه نویسی وب عمومی بدرد نمیخورن، مگر اینکه چند نسخه یا کد عملگر از یک صفحه برای مرورگهای مختلفی تهیه بشه، که اینهم کار سختی هست که معمولا کسی انجامش نمیده و اینکار منطق کمی برای انجام داره.

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

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

استانداردهای جهانی و بخصوص آزاد و بدون محدودیت (که تاجایی که میدونم کنسرسیوم وب از این سیاست پیروی میکنه/ترجیح و بالاترین اولویت رو براش داره) بسیار مهم و مفید هستن.
وب به این خاطر وب امروزی هست که این خصوصیت عمومی و آزاد و استاندارد بودن در ذاتش نهاده شده بود و امروز هم با استاندارهای بیشتر لازم در سطوح مختلف، این وضعیت به سمت بهتر شدن پیش رفته (از زمان جنگ مرورگرها و نبود مرجع و استاندارد مناسب کافی در این زمینه).

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

eshpilen
دوشنبه 21 تیر 1389, 21:51 عصر
میدونید که برنامه هایی هستن که بطور خودکار سایتها و صفحات وب رو برای پیدا کردن آدرسهای ایمیل جستجو میکنن.
این آدرسهای بدست اومده اغلب برای اسپم و تبلیغات ناخواسته و شاید بعضی کارهای دیگه که اغلب مطلوب و درست نیستن استفاده میشن و اگر از این ماهیتشون چشمپوشی کنیم و تحملش رو داشته باشیم ولی تعداد و تکرار روزمرهء اونها میتونه بسرعت دردسرساز بشه. بخصوص با قرارداشتن آدرس ایمیل در یک صفحهء وب مدام آمار این ایمیل ها بالا میره و تداوم پیدا میکنه. حتی پس از برداشتن ایمیل از صفحهء وب بازهم بخاطر اینکه آدرس ایمیل در بانک اطلاعاتی اسپمرها باقی مونده و احتمالا صحت و موجودیتش هم توسط ایمیل های ارسالی به اثبات رسیده (بررسی صحت آدرس ایمیل و حتی فهمیدن اینکه شما ایمیل ارسالی رو باز کردید یا نه ممکن هست)، شما با این واقعیت رودررو خواهید بود. هرچند انتظار میره تعداد این ایمیل ها با برداشتن ایمیل از صفحات سایت به مرور کمتر بشه.

خب راه حل چیه؟

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

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

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

این روش به اینصورت هست که شما آدرس ایمیل رو بصورت یک تصویر درج میکنید. اینطور اون برنامه ها قادر به استخراج این ایمیل نیستن، ولی کاربران براحتی قادر به رویت شفاف اون خواهند بود.
میدونید که برنامه هایی با روشی بنام OCR هستن که میتونن متن رو از درون تصاویر استخراج کنن. اما خیلی بعید هست که چنین کاری برای استخراج آدرسهای ایمیل انجام بشه، مگر در شرایط خاص (مثلا برداشت انبوه ایمیل ها از یک نرم افزار فروم شناخته شده به این روش).
خب برای پیشگیری از این امر شاید شما بخواید تصویر رو عمدا کمی مغشوش هم بکنید (مثل CAPTCHA) تا چنین برنامه های احتمالی ای هم قادر به استخراجش نباشن (عملا، استخراج خیلی سخت میشه، نه لزوما برای همیشه غیرممکن). میل شماست! اما توصیه میکنم زیادی مغشوشش نکنید که خوندنش برای آدمیزاد مشکل بشه، چون بنظرم مزیت این روش رو تقریبا از بین میبره.
توصیه های دیگه ای که شاید بشه کرد اینه که اسم و آدرس اون تصویر چیزی ثابت و تابلو نباشه که بتونن برنامه های هوشمندی بنویسن که این تصاویر رو براحتی شناسایی کنه. مثلا یک چیزی مثل email.gif بنظرم خیلی تابلو هست!! شخصا اسم تصویر خودم رو em.jpg گذاشتم.
البته شاید این ریزه کاریها یه وسواس غیرواقعی باشه، ولی خب دونستن و تاحدی بکار بستنش ضرری هم نداره و ممکنه در آینده با پیشرفت امکانات و فناوری و طمع و گشنگی اسپمرها مجبور به انجام تمام اینها باشیم.
مطمئنا اگر یک اسپمر بدونه که آدرسهای ایمیل کاربران یک فروم بزرگ به اینصورت براحتی در دسترس هست، اگر دانش و هوشمندی کافی داشته باشه حتما بفکر چنین کاری می افته. اما بعید میدونم درحال حاضر اینکار برای جستجوی تمام وب انجام بشه.

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

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

خب وقتش هست که با درج کد ادامه بدیم:


<img src="image/em.jpg" style="vertical-align: middle"
id="em_img" alt="info (at) example (dot) com">
<span id="em_text"></span>
<script language="JavaScript">
eat='@';
edot='.';
document.getElementById('em_img').style.display="none";
em='info'+eat+'example'+edot+'com';
document.getElementById('em_text').innerHTML='<a href="mailto:'+em+'">'+em+'</a>';
</script>

خط اول ایمیل بصورت تصویر هست. توجه کنید که ما ایمیل رو به روش متنی تغییر یافته در alt تگ img هم قرار دادیم. این کار مفید و لازمی هست بنظرم؛ اگر تصویر نمایش داده نشه این متن بجای اون دیده میشه. البته با اینکار مقداری به آسیب پذیری روش ما اضافه میشه.
ما زیر این تصویر یک فضا با تگ span برای ایمیل بصورت متن و لینک قابل کلیک که بعدا با جاوااسکریپت ایجاد میکنیم نگه میداریم.
در داخل جاوااسکریپت ما ابتدا تصویر رو از صفحه حذف میکنیم (display="none"). چون قراره متن تولید شده توسط جاوااسکریپت جایگزینش بشه.
ایمیل رو بصورت لینک قابل کلیک از اجزایی که عمدا از هم جدا شدن (تا توسط برنامه های جستجوی ایمیل قابل تشخیص نباشن) دوباره توسط اتصال رشته های متنی در جاوااسکریپت تولید کرده (در اینجا برای راحتی و اختصار کد داخل یک متغییر ذخیره کردیم) و بعد داخل تگ span قرار میدیم.
کل قضیه همین بود. اگر همه چیز خوب پیش بره ما یک متن خوانا و دقیق و لینک قابل کلیک خواهیم داشت. اگر جاوااسکریپت کار نکنه ما تصویر رو داریم، و اگر تصویر کار نکنه حداقل متن alt به احتمال زیاد قابل خوانده شدن و تشخیص خواهد بود.

راستی، اصلا شاید بد نباشه اون تصویر رو هم بصورت لینک قابل کلیک دربیاریم. یعنی مثلا به اینصورت:


<a href="mailto:info=AT=example=DOT=com">
<img src="image/em.jpg" style="vertical-align: middle"
id="em_img" alt="info (at) example (dot) com">
</a>

به این طریق کاربر میتونه آدرس لینک ایمیل رو براحتی کپی کنه یا با کلیک روی اون ایمیل رو در برنامهء مدیریت ایمیل باز کنه. البته لازم هست که ایمیل وارد شده رو ویرایش کنه، چون مسلما ما نمیتونستیم ایمیل رو بصورت دست نخورده درج کنیم و در معرض شناسایی برنامه های جستجوگر قرار بدیم. فقط امیدوارم کاربران خیلی تازه کار و ناشی و گیجی نباشن که متوجه این قضیه نشن!! مگر اینکه یک توضیح برای اینطور کاربران هم به کدهای خودمون اضافه کنیم (بنا به میل خودتون زحمتش رو بکشید).
بهرحال این بخش اضافه ای بود که الان به ذهنم رسید و فقط ذکر کردم. اما شاید چندان بدردبخور نباشه، چون هر برنامه ای به محض رسیدن به href="mailto: میتونه یقین حاصل بکنه که آدرس ایمیلی بعدش وجود داره و اگر برنامه نتونه این ایمیل رو استخراج بکنه ولی احتمالا در دیتابیس اسپمر ثبت میشه و اگر بعدا توسط یک انسان بررسی بشه (نمیدونم احتمالش چقدر هست) اون قادر به تشخیص سریع و استخراج و تصحیح این ایمیل خواهد بود.
اما روش جاوااسکریپت این ریسک رو هم تقریبا نداره، چون تنها چیزی که به دیتابیس اسپمر میره یکسری کاراکترهای بی ربط و نام متغییر بکار رفته در جاوااسکریپت هست و کسی هم حوصلهء پیگیری منشاء اونها و خوندن کدهای مربوطه رو نخواهد داشت.
توجه کنید اگر جاوااسکریپت شما فعال باشه ایمیل بصورت تصویر اغلب هرگز دیده نمیشه، چون تصویر توسط جاوااسکریپتی که بلافاصله بعد از تصویر قرار گرفته در یک لحظه حذف و با معادل متنی جایگزین میشه.

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

eshpilen
دوشنبه 21 تیر 1389, 21:58 عصر
توضیح: این مطلب قدیمی هست و ممکنه الان دیگه قابل قبول نباشه، چون ظاهرا در استانداردهای جدید HTML تگ frameset بطور کلی حذف شده. ضمنا من توصیه میکنم تاحداکثر ممکن از frameset استفاده نکنید و شاید این مطالب بنده، عوارض فریم ها رو دست کم گرفته باشن و شاید خودم بخاطر علاقه و استفاده ای که از frameset کردم دچار مقداری جانبداری شده باشم. قضاوت با خودتون. ضمنا یادتون باشه ابزارهای خاص یا خطرناک در دست افراد واقعا خبره میتونن بعضی جاها واقعا مفید باشن ولی بقیهء افراد بهتره طرفش نرن چون به احتمال زیاد دچار عوارض و دردسرهای بزرگی میشن.

----------------------

در این پست دربارهء صفحاتی که با فریم ها (frameset) ساخته میشن صحبت میکنیم.
یادم هست که از قدیم یک جنگ و بدنامی ای در ارتباط با فریم ها وجود داشت. و بنظر میرسه نتیجهء اون کم شدن آمار فریم ها در ساخت صفحات وب بوده باشه؛ البته شاید هم نه! اما خب قدیمترها، بقول منابع متعدد در وب (منجمله همین طرفهای جنگ و افترا!!)، استفاده از فریمها خیلی رواج داشت و محبوبیت خاصی داشتن، و امروز شاید ما بقدر اون موقع صفحاتی رو نمی بینیم که با فریم طراحی شده باشن.
اما اگر دقت کنیم فریمها جزء جدایی ناپذیری از وب بودن و هنوز هم هستن. بنظرم هنوز سایتهای متعددی، منجمله سایتهای معتبر و حرفه ای، میشه پیدا کرد که از فریمها استفاده میکنن. راستی یک نوع دیگر از فریمها هم وجود دارن که بهشون فریم داخلی گفته میشه (تگ iframe) و از قدیم تا حال کاربرد داشتن و هنوز هم برای خیلی کارها متداول هستن، اما ما در اینجا صرفا به فریمهای معمولی خودمون که با تگ frameset ایجاد میشن میپردازیم و صحبت خاصی در ارتباط با فریمهای داخلی نداریم. البته بین ایندو و موضوعات و مشکلات مطرح شده و راه حلهای ارایه شده مسلما میشه مشترکاتی پیدا کرد، چون مکانیزمهایی هم خانواده هستن.

سوالی که اول پیش میاد اینه که ما باید چه کنیم؟ از فریمها استفاده کنیم یا خیر؟
خب بنظر بنده بطور کلی نمیشه گفت فریمها بد بودن یا هستن، حالا اینکه زمانی ازشون استفادهء مفرط و ناشیانه میشده و خوب طراحی نمیشدن و نمیشن و کاربردشون احتیاج به دقت و بینش و حرفه ای گری بیشتری نسبت به صفحات عادی داره، دلیل بر عدم استفاده از اونها نمیشه.
فریمها هم مثل هر ابزار و امکانات دیگری ویژگیها و خواص و مزایا و معایب خودشون رو دارن، و محدوده و نوع کاربرد خودشون رو. حالا این محدوده میخواد کوچک باشه یا بزرگ. مهم اینه که همونطور که قبلا گفتم از هر ابزار و روشی در جای درست خودش استفاده کنیم و افراط و تفریط هم نداشته باشیم. تعصب در وادی علم و فناوری احمقانه و بی معنا و ناکاراست.
بعضی بسادگی میگن فریمها با موتورهای جستجو مشکل دارن و اونها رو گیج میکنن، پس ازشون استفاده نکنید! اما بنظر من این استدلال بقدر کافی مشروح و روشن و مستند و ضمنا نتیجه گیری متناسبی نیست. اگر از این افراد جزییات و استدلال و اسناد بیشتری رو برای این ادعا، و اثبات نتیجهء کلی و مطلقی که ارایه میکنن بخواید، احتمالا کمی به مشکل میخورن!!
فریمها خواص و انعطاف و امکانات جالب و مفیدی رو در اختیار میذارن که در موارد متعددی میتونه توجیه استفاده از اونها باشه. ضمنا درنظر داشته باشید که بالاخره همهء وب و تنها معیار و امتیاز هم که موتورهای جستجو نیستن! (گرچه بجای خودشون مهم هستن). بحث کاربردهای خاص هم که به کنار! یعنی جاهایی که اصولا کاربرد عمومی وب نیست یا نرم افزار و هدف خاصی هست و غیره.
در ضمن تاجایی که میدونم میشه بخش مهمی از مشکلات فریمها رو با موتورهای جستجو با متدهای خاصی که چندان هم مشکل نیستن حل کرد، و ما در اینجا به اونها خواهیم پرداخت.
بعنوان تکمیل این استدلالها و استناد باید بگم که اگر به کنسرسیوم وب، بخش مربوط به فریمها، مراجعه کنید هیچ توصیه ای درمورد عدم کاربرد فریمها یا ذکر مشکلات و ضعف خاصی درمورد اونها نمی بینید و بقول دیگر این روش deprecated نیست. هرچند شاید در بخشهای دیگری راهکارهایی رو برای کارا تر کردن و طراحی صحیح فریمها مطرح کرده باشه (بنده شخصا ندیدم، وگرنه درج میکردم).
فریمها هم صرفا یک امکان و یک روش هستن با کاربردهای خودشون. با ویژگیهایی که در جاهایی خیلی مفید و حتی ضروری بنظر میان و با روشهای دیگر قابل دستیابی نیستن یا بحد و بطور بهینه قابل دستیابی نیستن؛ همونطور که گفتم انتخاب روشها و ابزارها در برنامه نویسی کاملا شناور هست و فرمول جامعی داره که در اون هر عامل با ضریب خودش و که گاه بنا به شرایط و کاربرد خاص ما تفاوتهای فاحشی میتونه داشته باشه درج میشه. پس در هر مورد اعداد و ضرایب درج شده با موردهای دیگر میتونن کاملا متفاوت باشن و فرمول جواب نهایی کاملا متفاوتی رو به ما بده.
ببخشید که این توضیحات رو دادم که شاید کمی طولانی و زیاده گویی بنظر بیاد، اما بنظرم لازم بود که تمام جوانب مطلب رو روشن کنم و روش داشتن فکر باز و منعطف و با معیار و اصول صحیح رو ترویج کنم، و اصولا بخشی از محتویات مورد نظر ما درمورد فریمها که به الگوی صحیح طراحی و برنامه نویسی وب مربوط میشه همین بود.

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

- از متاتگ های keywords و description در صفحهء اصلی (صفحه ای که شامل تگ frameset و فریمهای تشکیل دهنده هست) حتما استفاده کنید.
بنظرم میتونید این تگها رو در صفحات دیگر (فایلهای فریمهای تشکیل دهنده) هم بکار ببرید، اما سعی کنید حتما با محتوای هرکدوم از اونها تطبیق داشته باشن و نه کل مجموعه فریم. یعنی مثلا در صفحهء اصلی از کیوردهایی مثل home استفاده کنید، اما نه در فریم بدنه که در این صفحه باز میشه، چون اون صفحهء مربوط به فریم بدنه بتنهایی صفحهء اصلی رو تشکیل نمیده. مسلما یک فایل فریم که گالری عکس هست میتونه کیورد picture gallery رو داشته باشه، درحالیکه صفحهء اصلی این کیورد رو نداره.
البته اینا تشخیص خودم هست و خیلی هم مطمئن نیستم و شاید منابع دیگری نظر دیگه ای داشته باشن؛ مثلا ظاهرا در بعضی منابع آمده که اصولا فریمهای جداگانهء بکار رفته رو از دسترسی موتورهای جستجو تا میتونیم دور کنیم تا صفحات تشکیل دهنده به تنهایی در موتورهای جستجو لیست نشن؛ اما ما در اینجا راه حلی براش ارایه میکنیم که مشکل رو تقریبا حل میکنه تا از قدرت و مزیت این متاتگ ها در ارتباط با موتورهای جستجو محروم نباشیم. ضمنا درهرصورت کاملا امکان داره موتورهای جستجو صفحات فریم ما رو لیست بکنن، گرچه ما هر تمهیدی رو هم برای جلوگیری از این امر بکار برده باشیم.

- مورد بعدی اینه که حتما از تگ <NOFRAMES> و محتویات مربوطه در صفحهء اصلی خودتون استفاده کنید.
بنظرم این، هم برای جلب توجه و تمرکز موتورهای جستجو به صفحهء اصلی خوب هست و هم اگر درست یادم باشه به گفته بعضی منابع، متنی هست که بعضی از اونها در نتایج جستجو نشون میدن.
البته حواستون باشه که باید سعی بشه محتویات این تگ شامل بعضی کلمات کلیدی کلی که هویت صفحه رو نشون میدن بصورت توضیحات راجع به سایت/صفحهء اصلی باشه، و در نهایت اون کاربرد قدیمی که متنی هست که میگه مرورگر شما از فریمها پشتیبانی نمیکند و از این حرفها؛ البته اگر خودتون خواستید چنین متنی رو هم درج کنید، چون بنظرم این متن بیشتر مربوط به قدیم و مرورگرهای وب اون دوره میشه که بعضی از اونها از فریمها پشتیبانی نمیکردن. البته از امکانات مرورگرهای خاصی که در دستگاههایی مثل تلفن همراه بکار میرن در این زمینه اطلاع خاصی ندارم.

ما در سایتی که با فریم طراحی شده یک صفحهء اصلی داریم که درش با تگ frameset مجموعه ای از فریمها رو که هرکدوم با تگ frame معرفی شدن و بوسیلهء مشخصهء src به یک فایل خارجی اشاره میکنن تعریف کرده ایم. این فایلهای خارجی در قسمتهای جداگانه یک نمای کاربری صفحه (که هرکدام یک زیرپنجره هستن) به نمایش در میان و همگی باهم یک صفحهء کامل رو میسازن. پس معمولا این فایلها همه همراه با هم در این ساختار طراحی شده و مورد دسترسی و کاربرد دارن، اما بصورت جداگانه بکار نمیرن. یعنی کسی یکی از این فایل فریمها رو بطور مستقیم و جداگانه نباید ببینه.
مشکلی که خصوصا با موتورهای جستجو هست اینه که اونها این صفحات رو هم مثل بقیهء فایلهای یک سایت در نتایج جستجوی خودشون میارن و اشکال بزرگش اینه که کاربران این لینک ها رو مستقیما و بدون رفتن به صفحهء اصلی دربرگیرنده باز بکنن.
خب ما در اینجا راه حل مناسبی برای این امر ارایه خواهیم کرد که البته بر جاوااسکریپت استوار هست. ولی میشه گفت بهرحال تا حد زیادی این مشکل رو مرتفع میکنه که ما بتونیم از فریمهای عزیزمون با خیال راحتتری استفاده کنیم!
در چنین سایتهایی که با فریم ساخته میشن معمولا یک یا چند بخش ثابت وجود داره، مثلا یک فریم برای لوگو، یک فریم برای navigation که شامل لینکهایی هست که هدف اونها در فریم دیگری (فریم بدنهء اصلی که محتویات مورد نظر کاربر در اونجا نشون داده میشن) باز میشه، و گاه یک فریم هم برای Footer و غیره. البته هرکدام از این نقشها میتونن کم و بیش متفاوت باشن، اما در وجود این طبقه بندی همگی در مفاهیم مشترک هستن. توجه داشته باشید که برای خلق چنین ترکیبهایی کاملا معمول هست که از حداقل دو فریم تودرتو استفاده کنیم، یعنی فایل اشاره شده توسط یکی از فریمهای داخل یک تگ frameset خودش یک سند frameset دیگر هست که فریمهایی رو دربر داره.
درهرحال نکته این هست که ما معمولا یک یا تعدادی فریم ثابت داریم (صفحهء درونی ثابت) و معمولا یک فریم متغییر (صفحهء درونی متغییر).
- در فایلهای تشکیل دهندهء فریمهای ثابت باید این کد رو درج کنیم:


if ( top.location == self.location ) top.location.href ="/";

این کد در یک تگ اسکریپت در قسمت header فایلهای ما درج میشه و کارش اینه که اگر فایل بطور مستقیم و خارج از مجموعهء فریم مورد دسترسی قرار گرفته بود، فورا مرورگر رو به صفحهء اصلی که در اینجا در صفحهء اصلی ریشهء سایت (/) قرار داره هدایت میکنه.
یک نکتهء نهایی اینجا اینکه، صفحه ای رو که بطور پیشفرض در فریم متغییر ما باز میشه (اگر به آخرین کد این پست نگاه کنید /body.php چنین فایلی هست) هم میتونیم یک فایل ثابت فرض کنیم و این کد رو، و نه کدی رو که در زیر برای فایلهای فریمهای متغییر آورده میشه، درش درج کنیم.

- در هرکدام از صفحاتی که در فریمهای متغییر باز میشن این کد رو در قسمت header در یک تگ اسکریپت قرار میدیم:


if (top.location==self.location) {
document.cookie='body'+ "=" +escape(location.pathname)+';path=/';
top.location.href ="/";
}

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


<?php

if(isset($_COOKIE['body'])) {
$body=$_COOKIE['body'];
setcookie('body', false, mktime(12,0,0,1, 1, 1990), '/');
}
else $body='/body.php';

?>

کد طرف سرور بالا رو باید تقریبا در ابتدای فایلی که محتوی تگ فریم متغییر شما هست قرار بدید. اگر شما فریم تودرتو ندارید این فایل معمولا همون صفحهء اصلی شماست که تنها مجموعهء frameset رو در خودش داره. اگر فریم تودرتو دارید و چند مجموعه فریم، باید ببینید که فریم متغییر شما در کدامیک از اونها هست.
من این کد رو با PHP نوشتم چون با این زبان کار میکنم.
- در تگ مربوط به فریم متغییر اینطور عمل کنید:


<frame src="<?php echo $body; ?>" ...>

یعنی در قسمت src این دستور PHP رو قرار بدید. من برای روشن بودن منظور خود این تگ رو از ابتدا درج کردم و «...» معرف بقیهء محتویات تگ شما هست (معمولا مشخصهء name و یکسری مشخصهء دیگه).
خب کار ما با فریمها تقریبا تموم شد.
راستی اگر سایتتون رو با استفاده از فریم طراحی میکنید بنظرم بهتره که همهء فایلهای فریمهای ثابت رو در یک دایرکتوری جداگانه قرار بدید و در دایرکتوری ریشهء سایت پخش و پلا نکنید! بخصوص اگر تعداد اونها از یکی دوتا بیشتر باشه.

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

معایب: مقداری پیچیدگی اولیه در طراحی، مشکل و روابط پیچیده تر با موتورهای جستجو، مشکل با bookmark/favorite، مشکل و دردسر احتمالی تطبیق و ترکیب با روشهای بکار رفته در نرم افزارهای دیگر، ...؟

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

eshpilen
دوشنبه 21 تیر 1389, 22:03 عصر
بنظر من استفاده از جاوااسکریپت باید حتی الامکان برای افزودن امکانات و تسهیلات اضافه و بعنوان یه مکمل باشه، نه اینکه اگر کاربر جاوااسکریپتش رو خاموش کرد نصف کارایی اساسی سایت از بین بره یا اصلا بعضی بخشهای اون دیده نشه. بنظر من هرچی کارایی رو ببریم سمت سرور بهتر هست. هرچند امروز میشه روی جاواسکریپت زیاد اتکا کرد ولی بازم «حتی الامکان» این قواعد رو درنظر بگیریم بنظر من بهتر هست و معمولا این روش، برنامه نویسی و طراحی رو هم از نظر اصولی بهتر و راحتتر میکنه. یا مثلا با موتورهای جستجو هم بیشتر رفیق میشه و غیره. خیلی از مرورگرها و افزونه امکان خاموش کردن جاواسکریپت رو به کاربر میدن، و بیشتر پراکسی ها بصورت پیشفرض کدهای جاوااسکریپت داخل صفحات رو غیرفعال میکنن. بنظر میرسه این حق کاربران باشه و کاربردهای مشروع و مفیدی داشته باشه. بعضیا برای امنیت بیشتر جاوااسکریپت رو خاموش میکنن.
حداقلش میشه گفت تاوقتی مجبور نیستید یا گزینهء متکی بر AJAX قابلیت بسیار جالب و مفیدی رو بهتون نمیده، از اینطور روشها استفاده نکنید (کارایی پایه بدون این روشها هم در دسترس باشه).

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

یه مواردی هست که روش کلاسیک و بدون نیاز به جاوااسکریپت رو نمیشه با روشهای مدرن تر ترکیب کرد که اینا باز بحث جداست. باید ببینید کاربرد و کاربر شما چیه و کیه و چه هدفی دارید و غیره و اون ویژگی آیا اونقدری ضروری یا مفید هست که سازگاری بیشتر رو فداش بکنید یا نه.

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

مسلما راه هرچه ساده تر بهتر و امن تره اغلب.
مگر اینکه ما بخوایم زیبایی یا امکانات اضافی خاصی رو در اختیار کاربر بذاریم. باید نگاه کنیم که آیا این امکانات واقعا مورد نیاز هستن و میزان استفاده و فایدهء اونها ارزش این هزینه ها رو داره یا نه.

KinGover
جمعه 03 مرداد 1393, 12:04 عصر
تشکر



--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Zirend.ir (http://zirend.ir/) بازار کار آنلاین
اگر پروژه ای در دست دارید که برای انجام آن نیاز به کمک دارید یا اگر مهارتی دارید و میخواهید از طریق اینترنت کسب درآمد کنید
پیشنهاد میکنم که به سایت Zirend بزرگترین سایت برون سپاری پروژه سر بزنید.
www.zirend.ir (http://www.zirend.ir/)