۱. مسئله را روی گوشی و دسکتاپ ببین
قبل از بازطراحی، صفحهٔ فعلی را در مرورگر باز کن و از ابزار توسعه‌دهنده برای دیدن آن در عرض‌های مختلف استفاده کن. در Chrome معمولاً با F12 یا گزینهٔ Inspect به DevTools می‌رسی و با آیکون نمایش دستگاه می‌توانی عرض صفحه را تغییر بدهی. این پیش‌نمایش برای پیدا‌کردن مشکل‌هایی مثل متنِ بریده، دکمهٔ خارج از صفحه و منوی ناپدیدشده مفید است؛ اما جای آزمون روی دستگاه واقعی را نمی‌گیرد.
ابتدا مسیر اپِ ویدیو را بررسی کن: ثبت دستی یا صوتی، دیدن صف، ارسال صف و مشاهدهٔ وضعیت؛ نمای مدیر هم برای بررسی گزارش‌ها وجود دارد. مثال مستقل این نوشته مسیر محدودتری دارد: عنوان یک گزارش را به صفِ نمایشی اضافه می‌کنی و وضعیت «در صف» را می‌بینی، بدون ارسال یا تأیید واقعی. این مسیر محدود را در عرض باریک و عریض بررسی کن. خروجی این مرحله باید چند مشاهدهٔ مشخص باشد، نه قضاوتی مثل «قشنگ نیست»: مثلاً «در عرض دسکتاپ فضای خالی زیادی داریم» یا «ناوبری پایین فقط در نمای موبایل دیده می‌شود». اگر اپ قرار است PWA باشد، یادت بماند PWA مترادف «سایت مخصوص گوشی» نیست؛ وب‌اپی است که می‌تواند قابلیت‌هایی مانند نصب‌پذیری داشته باشد و همچنان باید در اندازه‌های موردنیاز پروژه درست کار کند. برای آشنایی با این مفهوم، راهنمای PWA در MDN نقطهٔ شروع خوبی است.
۲. به Stitch مسئله و زمینه بده، نه فقط دستور زیباسازی
حالا سراغ Stitch برو. پیش‌نیاز، دسترسی به ابزار و اجازهٔ استفاده از تصاویر و اطلاعاتی است که در اختیارش می‌گذاری. برای درخواست اولیه، توضیح محصول یا PRD، نقش کاربرها، کار اصلی هر صفحه و تصویر وضعیت فعلی را آماده کن. اگر چند نسخه از توضیحات محصول داری، پیش از ارسال اختلافشان را حل کن؛ دو شرح متناقض، طرح دقیق‌تری تولید نمی‌کنند. از صفحه‌های مرتبط اسکرین‌شات بگیر تا ابزار هم محتوا را بشناسد و هم ببیند کدام بخش‌ها نیاز به اصلاح دارند. اطلاعات خصوصی یا واقعی کاربران را از تصویرها حذف کن.
بازنویسی آموزشی پرامپت برای Stitch:
برای یک وب‌اپ فارسیِ ثبت گزارش مزرعه، طرح رابط کاربری پیشنهاد بده.
کاربر اصلی باید بتواند گزارش را ثبت کند و وضعیت گزارش‌های صف را ببیند.
رابط راست‌به‌چپ باشد. برای گوشی، کارت‌های خوانا و دکمه‌های قابل‌لمس
و برای دسکتاپ، استفادهٔ بهتر از عرض صفحه و ناوبری روشن پیشنهاد کن.
متن‌های نمونه فارسی باشند. از تصویرهای پیوست فقط برای شناخت ساختار فعلی
استفاده کن؛ ویژگی تازه‌ای را بدون مشخص‌کردن به‌عنوان پیشنهاد وارد طرح نکن.
این متن نقل‌قول از یک پرامپت آماده نیست؛ بازنویسی آموزشی است تا بدانی چه اطلاعاتی به تصمیم طراحی کمک می‌کند. نتیجه را مثل یک پیش‌نویس ببین: آیا نقش دکمهٔ اصلی معلوم است؟ آیا وضعیت گزارش خوانده می‌شود؟ آیا صفحهٔ فارسی واقعاً راست‌به‌چپ چیده شده است؟
۳. طرح اول را با بازخورد دقیق بهتر کن
اگر خروجی اول از نظر رنگ، فاصله یا حس‌وحال مناسب نیست، لازم نیست آن را همان‌طور وارد پروژه کنی. بازخوردی بده که قابل بررسی باشد: «پس‌زمینهٔ روشن می‌خواهم»، «وضعیت هر گزارش باید سریع دیده شود» یا «تاریِ پشت کارت خوانایی متن را کم کرده است». «زیباترش کن» ممکن است طرح دیگری بدهد، ولی معلوم نمی‌کند چه مسئله‌ای حل شده است.
برای الهام‌گرفتن می‌توانی نمونه‌های طراحی مرتبط با کار میدانی یا داشبورد را ببینی و یک تصویر مرجعِ مجاز به Stitch بدهی. تصویر مرجع قرار نیست مجوز کپی‌کردن بی‌کم‌وکاست یک طرح، متن یا داراییِ متعلق به دیگری باشد. مشخص کن کدام ویژگی را دوست داری: سلسله‌مراتب اطلاعات، نسبت فضاهای خالی یا شیوهٔ نمایش کارت‌ها. اگر ابزار از روی تصویر، قابلیت تازه‌ای مثل بارگذاری عکس پیشنهاد کرد، آن را از نیاز قطعی محصول جدا نگه دار؛ اضافه‌شدن یک ایده به ماکت به معنی آماده‌بودن آن قابلیت در اپ نیست.
خروجی قابل‌قبول این مرحله یک تصویر خوش‌رنگِ تنها نیست. باید بتوانی نشان بدهی کاربر از کجا ثبت را شروع می‌کند، بعد از ثبت چه بازخوردی می‌بیند و در هر اندازهٔ صفحه به فهرست گزارش‌ها چطور می‌رسد. اگر یکی از این پاسخ‌ها مبهم است، یک دور دیگر طرح را اصلاح کن.
۴. خروجی طرح را مرجع کد بدان، نه کد نهایی محصول
در نمونهٔ عملی، کدِ نمای انتخاب‌شده از Stitch برداشته شد و همراه درخواست تغییر ظاهر به دستیار کدنویسی رسید. بسته به رابطی که در زمان استفاده می‌بینی، روش دسترسی به کد ممکن است فرق کند؛ روی نام یک منوی ثابت حساب نکن. نکتهٔ مهم این است که کد و تصویر طرح، هر دو مرجع‌اند: کد دربارهٔ ساختار و استایل سرنخ می‌دهد و تصویر کمک می‌کند شباهت بصری را قضاوت کنی.
بازنویسی آموزشی پرامپت برای دستیار کدنویسی:
این کدِ نمای مرجع و تصویر طرح را با ساختار پروژهٔ موجود مقایسه کن.
فقط ظاهر صفحهٔ ثبت و فهرست گزارش‌ها را تغییر بده؛ منطق ثبت و وضعیت‌ها
را بدون دلیل دست‌کاری نکن. رابط فارسی و RTL بماند. در موبایل کارت‌ها
خوانا باشند و در دسکتاپ ناوبری و عرض محتوا درست استفاده شوند.
پیش از تغییر، فایل‌هایی را که قرار است ویرایش کنی نام ببر؛ بعد از تغییر،
مواردی را که باید دستی آزمایش کنم فهرست کن.
اگر دستیار انتخابی‌ات تصویر را به‌عنوان ورودی نمی‌پذیرد، ارسال اسکرین‌شات به‌تنهایی کمکی نمی‌کند. طرح را با متن توصیف کن یا از ابزاری که واقعاً ورودی تصویر می‌گیرد برای توصیف تصویر کمک بگیر. قابلیت دیدن تصویر را از ظاهر محیط چت حدس نزن؛ ورودی‌های پشتیبانی‌شدهٔ همان مدل و ابزار را بررسی کن. همچنین اگر منطق ثبت داده مهم است، تغییرات پیشنهادی را در فایل‌های مرتبط بازبینی کن: شباهت ظاهری، درست‌ماندن عملکرد را تضمین نمی‌کند.
۵. HTML، CSS و JavaScript هرکدام چه کاری دارند؟
برای بررسی خروجیِ طرح به سه لایه نیاز داری. HTML ساختار و معنای محتوا را مشخص می‌کند: عنوان، فرم، برچسب ورودی، دکمه و فهرست. CSS ظاهر و چیدمان را کنترل می‌کند: رنگ، فاصله، اندازه و واکنش صفحه به عرض نمایشگر. JavaScript رفتار تعاملی را اضافه می‌کند: مثلاً پس از فشردن دکمه، ورودی را بخواند و یک مورد به فهرست اضافه کند. HTML را صرفاً «چیزی که دیده می‌شود» تصور نکن؛ بخش head هم اطلاعاتی مانند عنوان صفحه و اتصال فایل‌ها را نگه می‌دارد، در حالی که محتوای اصلی در body است. برای شناخت تگ‌های معنایی می‌توانی از آموزش ساختار HTML در MDN شروع کنی.
اگر در کد طرح استایل‌های طولانی دیدی، جداکردنشان در یک فایل CSS نگهداری را آسان‌تر می‌کند. انتخابگر .report یک کلاس را می‌گیرد و می‌تواند روی چند عنصر اعمال شود؛ #notice شناسهٔ یک عنصر را هدف می‌گیرد. برای همه‌چیز شناسه نساز: کلاس برای ظاهر تکرارشونده مناسب‌تر است. کدی هم که با JavaScript متن یا فهرست را تغییر می‌دهد، باید پس از در‌دسترس‌بودن عناصر صفحه اجرا شود؛ در مثال بعدی، ویژگی defer همین ترتیب را برای فایل اسکریپت برقرار می‌کند.
۶. یک نمونهٔ کوچک فارسی و راست‌به‌چپ بساز
مثال تکمیلی آموزشی: این نمونه بازسازیِ آموزشیِ مسیر «افزودن عنوان گزارش به صف نمایشی» است، نه کد پروژه یا خروجیِ لفظ‌به‌لفظ Stitch. به نصب ابزار، حساب کاربری یا سرور نیاز ندارد. پوشه‌ای به نام stitch-ui بساز و سه فایل index.html، style.css و app.js را دقیقاً کنار هم داخل آن قرار بده. نام فایل‌ها در ارجاع‌های HTML باید با نام فایل‌های واقعی یکی باشد.
در stitch-ui/index.html ساختار صفحه را بگذار. lang و dir به مرورگر و فناوری‌های کمکی دربارهٔ زبان و جهت متن خبر می‌دهند. برچسب ورودی و ناحیهٔ اعلان وضعیت هم بخشی از کاربردپذیری‌اند، نه تزئینات اضافی.
<!doctype html>
<html lang="fa" dir="rtl">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>صف گزارش‌های مزرعه</title>
<link rel="stylesheet" href="style.css">
<script src="app.js" defer></script>
</head>
<body>
<main class="container">
<header>
<p class="eyebrow">گزارش‌های میدانی</p>
<h1>صف گزارش‌های مزرعه</h1>
<p>عنوان یک گزارش را به صف نمایشی اضافه کن و وضعیت آن را در فهرست ببین.</p>
</header>
<section class="panel" aria-labelledby="form-title">
<h2 id="form-title">گزارش تازه</h2>
<form id="report-form">
<label for="report-title">عنوان گزارش</label>
<input id="report-title" name="title" required maxlength="60"
autocomplete="off" placeholder="مثلاً بررسی قطعهٔ شمالی">
<button type="submit">افزودن به صف</button>
</form>
<p id="notice" class="notice" role="status" aria-live="polite"></p>
</section>
<section aria-labelledby="list-title">
<h2 id="list-title">گزارش‌ها</h2>
<ul id="report-list" class="reports">
<li class="report">
<span>بازدید قطعهٔ نمونه</span><span class="badge">در صف</span>
</li>
</ul>
</section>
</main>
</body>
</html>
۷. چیدمان را برای دو عرض تنظیم کن
در stitch-ui/style.css، ابتدا ظاهر پایه را برای گوشی بنویس. کارت در عرض کم یک ستون است؛ در عرض بیشتر، همان اطلاعات در دو ستون جا می‌گیرد. این چیدمانِ دو‌ستونی بازسازیِ جدولِ نمای دسکتاپِ ویدیو نیست؛ فقط واکنش‌گراییِ یک فهرست کارتی را نشان می‌دهد. اگر بعداً چند ستون مقایسه‌ای مثل تاریخ، مسئول و وضعیت داشتی، برای نمایش جدولیِ آن داده‌ها از جدول معنایی HTML استفاده کن و نسخهٔ موبایلش را جداگانه طراحی کن.
* { box-sizing: border-box; }
body {
margin: 0;
background: #f4f7f2;
color: #183329;
font-family: Tahoma, sans-serif;
line-height: 1.7;
}
.container { width: min(100% - 2rem, 60rem); margin: 2rem auto; }
header { margin-bottom: 1.5rem; }
.eyebrow { color: #426c52; font-weight: bold; }
h1 { line-height: 1.3; }
.panel, .report {
background: #fff;
border: 1px solid #d8e3d8;
border-radius: 1rem;
padding: 1rem;
}
.panel { margin-bottom: 2rem; }
form { display: grid; gap: .6rem; }
input, button { font: inherit; min-height: 2.75rem; border-radius: .6rem; }
input { width: 100%; border: 1px solid #849b89; padding: .4rem .7rem; }
button { border: 0; background: #205a3b; color: #fff; cursor: pointer; }
button:hover { background: #17462e; }
:focus-visible { outline: 3px solid #a35b08; outline-offset: 3px; }
.notice { min-height: 1.7em; }
.reports { list-style: none; padding: 0; display: grid; gap: .75rem; }
.report { display: flex; justify-content: space-between; gap: 1rem; }
.report > span:first-child { min-width: 0; overflow-wrap: anywhere; }
.badge { color: #205a3b; font-weight: bold; white-space: nowrap; }
@media (min-width: 48rem) {
form { grid-template-columns: 1fr auto; align-items: end; }
form label { grid-column: 1 / -1; }
button { padding-inline: 1.5rem; }
.reports { grid-template-columns: repeat(2, minmax(0, 1fr)); }
}
بعد از ذخیره، index.html را در مرورگر باز کن. در عرض باریک، فرم و گزارش‌ها زیر هم قرار می‌گیرند؛ در عرض عریض، دکمه کنار ورودی می‌نشیند. تا کد بخش بعد را در app.js ننوشته‌ای، فرم هنوز موردی اضافه نمی‌کند؛ پس از تکمیل آن، دست‌کم یک عنوان دیگر ثبت کن تا دو ستون کارت‌ها را ببینی. اگر متن فارسی کوچک یا فشرده است، فقط رنگ را عوض نکن: فاصلهٔ خطوط، عرض محتوا و فونت را هم بررسی کن. فونت این نمونه از فونت‌های موجود روی دستگاه استفاده می‌کند و به دانلود جداگانه وابسته نیست.
۸. رفتار دکمه را اضافه کن و محدودیتش را بشناس
بدون JavaScript، فرمِ نمونه چیزی را به فهرست اضافه نمی‌کند. کد زیر را در stitch-ui/app.js بگذار. رویداد submit هم کلیک روی دکمه و هم ارسال فرم با صفحه‌کلید را پوشش می‌دهد. preventDefault جلوی ارسال معمول فرم و بارگذاری دوبارهٔ صفحه را می‌گیرد؛ textContent هم متن ورودی را به‌جای تفسیر آن به‌عنوان HTML در صفحه می‌گذارد.
const form = document.querySelector('#report-form');
const input = document.querySelector('#report-title');
const list = document.querySelector('#report-list');
const notice = document.querySelector('#notice');
form.addEventListener('submit', (event) => {
event.preventDefault();
const name = input.value.trim();
if (!name) {
notice.textContent = 'عنوان گزارش را وارد کن.';
input.focus();
return;
}
const item = document.createElement('li');
item.className = 'report';
const title = document.createElement('span');
title.textContent = name;
const badge = document.createElement('span');
badge.className = 'badge';
badge.textContent = 'در صف';
item.append(title, badge);
list.prepend(item);
notice.textContent = `گزارش «${name}» به صف نمایشی اضافه شد.`;
form.reset();
input.focus();
});
حالا عنوان یک گزارش را بنویس و دکمه را بزن. باید کارتی تازه در ابتدای فهرست و پیامی زیر فرم ببینی. این صف نمایشی است: داده به سرور ارسال یا در مرورگر ذخیره نمی‌شود و با Refresh از بین می‌رود. این محدودیت عمدی است تا طراحی رابط را با پیاده‌سازی پایگاه داده یا وضعیت واقعی گزارش اشتباه نگیری. اگر دکمه هیچ کاری نکرد، نام فایل و مسیر app.js، ذخیره‌بودن فایل و پیام‌های Console مرورگر را بررسی کن؛ اگر استایل نیامد، اول ارجاع style.css را کنترل کن.
۹. طرح و پیاده‌سازی را کنار هم آزمایش کن
اکنون تصویر طرح، صفحهٔ اجراشده در عرض گوشی و صفحهٔ اجراشده در عرض دسکتاپ را کنار هم بگذار. فقط دنبال تطابق پیکسل‌به‌پیکسل نباش. ترتیب عنوان‌ها، خوانایی وضعیت، دسترسی به دکمهٔ اصلی و نبودِ بخش‌های پنهان‌شده مهم‌ترند. در پروژهٔ اصلی، پس از یک تغییر ظاهری، دکمه‌ای درست کار نمی‌کرد؛ در مرحله‌ای دیگر ناوبریِ مناسب موبایل در نمای وب دیده نمی‌شد و بعد از اصلاح ظاهر هم خطای عملکردی هنگام ارسال رخ داد. این‌ها سه آزمون جدا هستند: نمایش، ناوبری و رفتار.
با صفحه‌کلید از ابتدای نمونه تا دکمه Tab بزن و ببین کادر فوکوس مشخص است یا نه. فرم را با Enter بفرست، چند نام بلند وارد کن و عرض مرورگر را کم‌وزیاد کن. سپس همان مسیر را در اپ واقعی، با نقش‌های کاربری و صفحه‌های دیگری که داری، تکرار کن. اگر مدل کدنویسی تصویر را نمی‌بیند، گزارش خطا را متنی و دقیق بنویس: «در عرض دسکتاپ فهرست دیده می‌شود اما ناوبریِ رسیدن به آن وجود ندارد». چنین گزارشی از «درستش کن» مفیدتر است.
۱۰. یک خروجی قابل‌ارزیابی تحویل بده
تحویل این تمرین سه فایل اجرایی در پوشهٔ stitch-ui است، همراه دو تصویر از نمای باریک و عریض و یک یادداشت کوتاه دربارهٔ نتیجهٔ آزمون: چه چیزی با طرح هماهنگ است، چه چیزی هنوز نیاز به اصلاح دارد و کدام رفتار صرفاً نمایشی است. برای تمرین بعدی در همین فایل‌ها، وضعیت کارت نمونه را از «در صف» به «نیازمند بررسی» تغییر بده، سپس بررسی کن آیا رنگ تنها راه تشخیص وضعیت است یا متن هم آن را روشن می‌کند. یک عنوان طولانی فارسی، از جمله متنی بدون فاصله، هم ثبت کن و مطمئن شو متن باعث خروج کارت از صفحه نمی‌شود.
Stitch می‌تواند شروع طراحی و گفت‌وگو دربارهٔ ظاهر را سریع‌تر کند، اما تصمیم نهایی دربارهٔ زبان فارسی، دسترس‌پذیری، سازگاری صفحه‌ها و رفتار واقعی همچنان به بررسی تو نیاز دارد. وقتی بتوانی فاصلهٔ بین ماکت و صفحهٔ اجراشده را دقیق توصیف کنی، به دستیار کدنویسی هم دستور بهتری می‌دهی و نتیجه را مستقل از زیبایی تصویر می‌سنجی.
ویدیوی کامل
اگر می‌خواهی روند کار و آزمون‌ها را هم ببینی، ویدیوی کامل این آموزش اینجاست:
دیدگاهتان را بنویسید
برای نوشتن دیدگاه باید وارد بشوید.