Bscenius
-1920x1080.webp&w=1920&q=100)
Client
Bscenius
About this project
Bscenius صرفاً یک پورتفولیوی جدید نیست؛ سیستم کاری استودیوی ماست.
بعد از ساخت BSquare و نمایندگی‌یاب، به سه نتیجه رسیدیم. اول اینکه فرانت‌اند نباید مستقیماً به Payload وابسته باشه. دوم اینکه ساخت اولین نمونه از یک نوع سایت طبیعیه که زمان ببره، اما ساخت نمونه پنجم باید خیلی سریع‌تر پیش بره. سوم اینکه اگر چیزهایی مثل معماری پروژه، اشتباهات و قواعد سئو مستند نشن، انگار اصلاً اتفاق نیفتاده‌اند.
برای همین، ساختار این سایت شامل بخش‌های خدمات، نمونه‌کارها و اعضای تیمه. در کنار اون، یک ساختار محتوایی مشترک هم داریم که موضوعات و مطالب رو برای مستندات و مطالعه‌های موردی مدیریت می‌کنه. محتوای متنی با ویرایشگر Lexical نوشته می‌شه، فهرست مطالب از روی عنوان‌ها ساخته می‌شه و نویسنده‌ها از بین اعضای تیم انتخاب می‌شن. پشتیبانی از زبان‌های مختلف هم از ابتدا در نظر گرفته شده و اگر اطلاعات سئو وارد نشده باشه، سیستم از مقادیر جایگزین استفاده می‌کنه تا فیلدها بی‌دلیل خالی نمونن. همچنین، پوشه قابلیت‌ها طوری طراحی شده که برای پروژه بعدی بتونیم دوباره از همون ساختار استفاده کنیم؛ مثلاً وقتی مشتری بعدی صفحه خدماتی مشابهی می‌خواد.
اهمیت این موضوع از نظر کسب‌وکار هم مشخصه. طراحی یک ساختار اطلاعاتی جدید همچنان به فکر و بررسی نیاز داره، اما ساخت یک دایرکتوری مشابه، یک سایت استودیویی دیگه یا یک ساختار مستندات جدید نباید هر بار از صفر شروع بشه. ما هزینه طراحی و آماده‌سازی این قالب‌ها رو یک بار، برای محصول خودمون پرداخت کردیم تا در پروژه‌های بعدی هم ازشون استفاده کنیم.
این مجموعه محتوا هم عمداً بر اساس همین ساختار نوشته شده. هر فیلدی که در مدل ServiceDetail وجود داره، در این مجموعه هم مقداردهی شده تا ساختار محتوا با سیستم واقعی سایت هماهنگ باشه.
مطالعه موردی · فرایند ساخت · سئوی فنی
قالب‌بندی متن فراتر از بولد و ایتالیک
وقتی متنی می‌نویسیم، همه بخش‌ها اهمیت یکسانی ندارن. گاهی لازمه یک اصطلاح رو برجسته کنیم، به یک نکته هشدار بدیم یا نقل‌قولی رو مشخص کنیم. ویرایشگرهای متن معمولی معمولاً فقط امکان بولد و ایتالیک دارن که برای بیان همه این تفاوت‌ها کافی نیست.
مشکلات
- در ساختار قبلی، همه بخش‌های متن ظاهر یکسانی داشتن؛ فرقی نمی‌کرد هر بخش چقدر مهم باشه.
- راهی برای تفکیک تأکید ساده، مثل بولد و ایتالیک، از انواع محتوای متمایز مثل کادر اطلاع‌رسانی، برچسب یا اصطلاح برجسته وجود نداشت.
- نویسنده‌ها برای قالب‌بندی متن فقط دو انتخاب داشتن؛ درحالی‌که نیازهای واقعی نوشتن خیلی متنوع‌تره.
راه‌حل ما
- استایل‌های اختصاصی متن رو به نوار ابزار ویرایشگر اضافه کردیم تا نویسنده بتونه مستقیماً از داخل ویرایشگر اون‌ها رو انتخاب کنه.
- این استایل‌ها در تمام بخش‌های محتوای متنی قابل استفاده هستن، نه فقط در فیلدهای مشخص و از پیش تعیین‌شده.
- به این ترتیب، می‌شه هر بخش از محتوا رو متناسب با اهمیت و کاربردش نمایش داد، بدون اینکه برای هر استایل جدید به تغییر کد نیاز باشه.
یک طراحی برای عنوان‌ها، چهار ظاهر متفاوت
قرار نیست تمام بخش‌های یک سایت ظاهر و حس یکسانی داشته باشن. صفحه اصلی به عنوان‌هایی چشمگیر و متفاوت نیاز داره؛ صفحه آرشیو باید مرتب و خوانا باشه و بعضی بخش‌ها هم به ظاهری خاص و هماهنگ با هویت برند نیاز دارن. اگر برای هر حالت یک کامپوننت جدا بسازیم، منطق طراحی تکرار می‌شه و هر تغییر ساختاری باید در چند جای مختلف اعمال بشه.
مشکلات
- عنوان هر بخش، شامل تیتر و توضیحات، بسته به محل استفاده به ظاهر متفاوتی نیاز داشت.
- استفاده از یک استایل ثابت، آزادی طراحی رو محدود می‌کرد؛ ساخت کامپوننت‌های جداگانه هم باعث تکرار و سخت‌تر شدن نگه‌داری کد می‌شد.
- نویسنده‌ها نمی‌تونستن ظاهر هر بخش رو تغییر بدن، مگر اینکه از توسعه‌دهنده بخوان کد رو ویرایش کنه.
راه‌حل ما
- یک کامپوننت مشترک به نام SectionHeader ساختیم که با پراپ variant چهار سبک متفاوت رو پشتیبانی می‌کنه: gradient، plain، brutal و mono. هر سبک چیدمان و تایپوگرافی مخصوص خودش رو داره، نه اینکه فقط رنگش تغییر کرده باشه.
- بخش‌هایی مثل سوالات متداول، خدمات، دلایل انتخاب ما و شبکه نمونه‌کارها در CMS فیلدی به نام headingVariant دارن. بنابراین نویسنده می‌تونه ظاهر عنوان هر بخش رو در هر صفحه جداگانه انتخاب کنه، بدون نیاز به تغییر کد.
- با این روش، اصلاح باگ‌ها یا اضافه‌کردن سبک جدید فقط در یک کامپوننت انجام می‌شه، اما هر بخش همچنان می‌تونه ظاهر متناسب با خودش رو داشته باشه. مثلاً صفحه اصلی معمولاً از سبک گرادیانی استفاده می‌کنه و صفحات آرشیو می‌تونن ساده‌تر یا متفاوت‌تر باشن.
توضیح یک قابلیت فنی، فقط نوشتن متن کنار تصویر نیست
می‌خواستم راهی داشته باشم که بتونم روند حل یک مسئله و دلیل تصمیم‌هام رو توضیح بدم و هم‌زمان شواهد واقعی، مثل تکه‌کد یا تصویر صفحه، درست کنار توضیحات نمایش داده بشن. وقتی تصاویر به‌صورت جداگانه زیر متن قرار می‌گیرن، ارتباطشون با توضیحات مشخص نیست. اگر چند تصویر هم وجود داشته باشه، محتوا به یک گالری معمولی تبدیل می‌شه که خواننده به‌سختی ارتباط بین بخش‌ها رو دنبال می‌کنه. در مورد کد هم وقتی یک قطعه‌کد رو قرار می‌دادم و پایینش توضیح می‌نوشتم، خواننده مجبور بود مدام به بالا برگرده تا خط موردنظر رو پیدا کنه.
مشکلات
- توضیحات و شواهد تصویری در دو جای جدا قرار می‌گرفتن و خواننده باید تصویر مرتبط با هر پاراگراف رو پیدا می‌کرد.
- ممکن بود توضیح یک قابلیت به سه یا چهار تصویر نیاز داشته باشه، درحالی‌که فیلد معمولی تصویر فقط یک تصویر رو پشتیبانی می‌کرد.
- امکان اشاره مستقیم به یک نقطه مشخص در تصویر یا یک خط از کد، بدون شماره‌گذاری یا توضیحات جداگانه، وجود نداشت.
- در صفحه‌نمایش‌های کوچک‌تر، امکان داشت چیدمان هماهنگ با اسکرول درست کار نکنه و بخش تصویری در سمت راست نمایش داده نشه.
راه‌حل ما
- چیدمان هماهنگ با اسکرول: ستون توضیحات در سمت چپ هنگام اسکرول در جای خودش باقی می‌مونه و تصویر یا کد مرتبط در ستون سمت راست هم‌زمان با اون تغییر می‌کنه.
- گالری تصاویر واقعی: می‌تونیم به‌جای محدودشدن به یک تصویر، هر تعداد تصویر که برای توضیح قابلیت لازمه اضافه کنیم و ترتیب نمایش اون‌ها رو مشخص کنیم.
- نشانگرهای روی تصاویر: نقاط تعاملی در موقعیت مشخصی از تصویر قرار می‌گیرن و با کلیک روی هرکدوم، توضیحات مربوط به همون نقطه باز می‌شه.
- نشانگرهای روی کد: همین روش برای کد هم پیاده‌سازی شده، با این تفاوت که نشانگر به شماره خط مشخصی متصل می‌شه.
- سیستم مشترک نمایش توضیحات: تصویر و کد دو نوع محتوای متفاوت هستن، اما هر دو از یک سیستم مشترک برای باز و بسته‌کردن پنجره توضیحات استفاده می‌کنن.