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

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

سپس کسی متوجه شد که سایت های جذاب تر پول بیشتری در می آورند و فناوری از آن پس در حال شتابزدگی بود.

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

جداول برای چیدمان

مثال کلاسیک یک هک اشتباه استفاده از جداول برای چیدمان است.

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

ممکن است اکنون دیوانه کننده به نظر برسد، اما موارد زیادی برای تایید هکرون اصلی وجود داشت:

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

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

استفاده نادرست از آنها توسط نسلی از طراحان وب به جدول ها شهرت وحشتناکی داد – من هنوز با افرادی ملاقات می کنم که با اطمینان به من اطلاع می دهند که عناصر جدول منسوخ شده اند. (جدول ها کاملاً خوب هستند، فقط برای چیدمان نیستند.)

متن به عنوان تصویر

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

آن روزها هیچ گوگل فونتی وجود نداشت. در واقع اصلاً گوگلی وجود نداشت. استفاده از فونت حتی در افق دوردست هم مشاهده نمی‌شد. صفحات وب از Arial، Times، Verdana، Courier جورجیا استفاده می کنند.

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

تا به حال به این فکر کرده اید که چرا فتوشاپ این همه جلوه های برجسته سه بعدی را دارد؟ این برای طراحان وب دهه 90 بود که مصمم بودند متن خود را “سه‌بعدی” کنند. البته اکنون می دانیم که استفاده از متن در تصاویر برای دسترسی کاربران وحشتناک بود، سرعت سایت ها را کاهش داد و به روز رسانی آن ها غیرممکن بود. و ما در آن زمان نیز آن را می دانستیم. ما فقط اهمیت ندادیم.

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

نقشه های تصویری (Image Mapping)

البته، اگر می خواهید تمام متن خود را در یک تصویر درج کنید، به روشی نیاز دارید که متن را قابل کلیک کنید. نشانه: نقشه های تصویری.

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

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

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

فهرست های وب

در سال 2023، وب توسط SEO هدایت می شود. هر تصمیم مهم در مورد یک وب سایت شامل یک تحلیل استراتژیک عمیق از نحوه عملکرد گزینه های موجود در موتورهای جستجو است.

اما در اواخر دهه 90، ما هرگز نام آلتا ویستا را نشنیده بودیم، چه رسد به گوگل. و بنابراین، وقتی می‌خواستیم کاربران سایت جدیدی را که ما ساخته‌ایم کشف کنند، آن را در فهرست وب پست کردیم.

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

نگهداری دایرکتوری های وب در حال حاضر غیرممکن است، اما 25 سال پیش، آنها چندین مزیت را ارائه کردند که سئو هنوز نتوانسته است آنها را شکست دهد:

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

تغییر از فهرست‌های وب به موتورهای جستجو برای سلامت وب با رشد آن ضروری بود. اما سئو همچنان در تلاش است تا همان تضمین های کیفیت بهترین فهرست های وب را برآورده کند.

قاب ها (Frames)

در دوران قبل از ورود CMS به قالب ها، ورود ناهماهنگی ها به وب سایت ها بسیار آسان بود. یک منو باید در هر صفحه ایستا کپی و جایگذاری می شد و هر گونه به روز رسانی باید در هر صفحه انجام می شد.

فریم‌ها به طراحان اجازه می‌داد تا قسمت‌های مختلف یک سایت را در مناطق مختلف یک صفحه بارگذاری کنند. ناگهان، می توانید یک بار منوی خود را کدنویسی کنید و آن را از طریق یک فریم در هر صفحه در سایت خود بارگذاری کنید. قاب های ارائه شده:

• سازمان – به نوعی OOP برای HTML بود. یک جور هایی.
• سرعت توسعه – کد قابل استفاده مجدد به معنای زمان توسعه کوتاه تر و سازگاری بیشتر است.

متأسفانه، معایب فریم ها بسیار بیشتر از جوانب مثبت آن ها بود:

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

ما هنوز از iframes در وب استفاده می کنیم، اما رویکرد فریم های اولیه خوشبختانه توسط CSS و قالب ها از بین رفت.

فلش و اکشن اسکریپت

فلش زمانی که در حوالی هزاره به شهرت رسید چیزی کمتر از یک مکاشفه نبود. در ابتدا به عنوان یک ابزار انیمیشن توسط Macromedia به بازار عرضه شد، نسخه 5 بود که با گسترش دستورات اولیه stop() و play() به یک زبان برنامه نویسی کاملاً شکل گرفته به نام Actionscript، بازی را تغییر داد.

در نسخه 6، Actionscript به یک زبان برنامه نویسی شی گرا با قدرت قابل مقایسه با جاوا اسکریپت امروزی تبدیل شد.

موفقیت فلش به لطف مزایای متعدد آن بود:

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

واضح است که این بزرگترین اختراع از زمان نوع متحرک بود. در صورتی که موراد زیر را ذکر نکنید:

• مشکلات عملکرد – فلش انرژی را مصرف کرد. اگر به اندازه کافی خوش شانس بودید که واقعاً یک دستگاه تلفن همراه داشتید(تعداد کمی از افراد صاحب یک دستگاه تلفن همراه بودند)، پس یک سایت می تواند باتری شما را به صفر برساند.
• مسائل امنیتی – زمانی که Adobe Flash را از Macromedia خریداری کرد، مجبور شد هزینه را با انتشار ویژگی های بیشتر جبران کند. چرخه های توسعه کوتاه شده ممکن است یک یا دو آسیب پذیری امنیتی بسیار کوچک را معرفی کرده باشند.
• مشکلات سئو – در ابتدا، فلش توسط موتورهای جستجو ایندکس نمی شد. مشکل در حدود یک سال (در صورت استفاده از حافظه) حل شد، اما از نظر شهرت، فلش هرگز بهبود نیافت.

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

هنگامی که انکار در نهایت جای خود را به نور سرد واقعیت داد، رایج ترین عبارتی که در استودیوهای فلش در سراسر جهان شنیده می شد این بود: “هی، این جی کوئری را دیده ای؟”

جی کوئری (jQuery)

فلش به طراحان آموخت که نه تنها می توانند کدنویسی کنند، بلکه کدنویسی طراحی های آنها را بهبود می بخشد. متأسفانه، نزدیکترین جایگزین برای اکشن اسکریپت جاوا اسکریپت بود (هر دو بر اساس ECMAScript هستند).

و سپس، جی کوئری آمد. جی کوئری کتابخانه ای بود که جاوا اسکریپت را به چیزی منطقی تبدیل می کرد.

• سادگی – چیزی که در جاوا اسکریپت 18 خط کد نیاز داشت، جی کوئری در دو خط مدیریت می کرد.
• سازگاری بین مرورگرها – jQuery ناسازگاری بین مرورگرها را برطرف کرد، بنابراین ما مجبور نبودیم نسخه‌های کد مخصوص مرورگر را بنویسیم.
• AJAX – یکی از چالش برانگیزترین وظایف برای پیاده سازی در جاوا اسکریپت وانیلی، AJAX بود. jQuery کار را ساده کرد و نحوه بارگذاری داده ها در صفحات HTML را متحول کرد.
• دستکاری DOM – با jQuery دستکاری DOM ساده شد و انواع تعاملات پیچیده ای را که قبلاً فقط در Flash واقع گرایانه بود امکان پذیر می کرد.

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

برای بسیاری از وظایف، jQuery با فریمورک های مدرن تری مانند Vue، Angular و React جایگزین شده است. با این حال، بزرگترین چالش جی کوئری جاوا اسکریپت وانیلی است که دست به کار شده و کدهای مدرن را با الهام از مجموعه نمونه جی کوئری معرفی کرده است.

AMP

آخرین فناوری سالهای گذشته ما صفحات موبایل شتاب دهنده (AMP) است. در سال 2015 معرفی شد، هدف اعلام شده بهبود عملکرد وب سایت در دستگاه های تلفن همراه بود.

AMP با کاهش مقدار HTML، CSS و جاوا اسکریپت در دسترس طراحان کار کرد. این طراحان را مجبور به مهار کرد، که به این معنی بود:

• زمان بارگذاری سریعتر – کد ساده به این معنی است که AMP می تواند سریعتر در دستگاه های تلفن همراه ارائه شود.
• سئو افزایش می یابد – در ابتدا، گوگل از سایت های AMP در نتایج جستجوی تلفن همراه خود استفاده می کرد و برای هر سایتی که این رویکرد را اتخاذ می کرد یک مزیت آشکار ارائه می داد.

اما بدی ها بیشتر از خوبی ها بود:

• محدودیت ها – به جای بهینه سازی سایت ها، AMP به سادگی آنها را محدود کرد. محدودیت‌هایی که در AMP می‌توان انجام داد، سایت‌ها را ضعیف کرد.
• گوگل – هیچ کس نمی گوید که AMP تلاش گوگل برای به دست گرفتن کنترل زیرساخت وب با ایجاد یک وب دو لایه است. هیچ کس این را نمی گوید. اصلا هیچ کس.

AMP زمانی به پایان (غیررسمی) خود رسید که گوگل در برابر فشارها سر فرود آورد و شروع به فهرست کردن همه سایت‌ها در جستجوی موبایل کرد و عملاً تنها مزیت ارائه شده AMP را حذف کرد.

گام بعدی چیست؟

آخر کدام فناوری وب را خواهیم دید؟ مطمئناً روزهای JPG فروتن به شماره افتاده است. React به نظر کمی طولانی در دندان است. سبک های درون خطی باید محکوم به فنا باشند.

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

چه کسی می داند، شاید حتی HTML برای همیشه با ما نباشد…

منبع: webdesignerdepot.com