एक नया बटन पूरे लेआउट को बदल सकता है: तय तुलना-दृश्य कैसे मदद करते हैं

बटन का उद्देश्य अधिक स्पष्ट रूप से उभरकर दिखना है। बदलाव के बाद ऑफ़र कार्ड बड़ी स्क्रीन पर अच्छा दिखता है। लेकिन संकरे दृश्य में चौड़ा बटन कीमत को पंक्ति से बाहर धकेल देता है। बदलाव छोटा था; उसका असर सामग्री के हिस्सों के बीच के पूरे संबंध पर पड़ता है।

Playwright संदर्भ छवियों के साथ स्क्रीनशॉट तुलना का दस्तावेज़ीकरण करता है और बताता है कि कैप्चर का परिवेश उन्हें कैसे प्रभावित कर सकता है। यह तरीका हमारे अपने एक अभ्यास के लिए उपयोगी अवसर देता है। हर पिक्सेल का अंतर त्रुटि नहीं होता, और एक जैसी छवि अभी यह साबित नहीं करती कि क्रिया सही है। महत्वपूर्ण यह है कि आप तुलना के ज़रिए कौन-सी दिखाई देने वाली अपेक्षा जाँचना चाहते हैं।

लिखिए कि क्या बदलना चाहिए और क्या वैसा ही रहना चाहिए

हमारे काल्पनिक कार्ड के लिए उद्देश्य यह है: बटन को पहचानना आसान हो जाए, जबकि शीर्षक, कीमत और आवश्यक टिप्पणी पूरी तरह पढ़ने योग्य बने रहें। इस वाक्य में वांछित बदलाव और उसकी सीमाएँ दोनों शामिल हैं। “बटन को बेहतर बनाइए” का आकलन करना कहीं अधिक कठिन होता।

तीन सामग्री-मामले तैयार कीजिए: एक छोटा शीर्षक, एक लंबा शीर्षक और एक अतिरिक्त शर्त वाला शीर्षक। बदलाव से पहले और बाद में एक जैसे विवरणों का उपयोग कीजिए। सुविधाजनक प्लेसहोल्डर टेक्स्ट वाली तुलना ठीक उसी जगह की कमी को छिपा सकती है, जो बाद में वास्तविक सामग्री के साथ सामने आती है।

साथ ही कम से कम एक चौड़ा और एक संकरा दृश्य चुनिए। ये चौड़ाइयाँ प्रश्न का हिस्सा हैं, न कि सभी डिवाइसों के बारे में कोई सामान्य कथन। संकरा मामला यह जाँचता है कि कम जगह होने पर भी संबंध बना रहता है या नहीं।

संदर्भ के लिए नियंत्रित परिवेश चाहिए

ब्राउज़र, ऑपरेटिंग सिस्टम, फ़ॉन्ट और अन्य परिस्थितियाँ कैप्चर को प्रभावित कर सकती हैं। इसलिए किसी दूसरे परिवेश से ली गई पहले की छवि एक कमज़ोर संदर्भ है। प्रासंगिक परिवेश को स्थिर रखिए और उसे टेस्ट के साथ दर्ज कीजिए।

किसी तैयार टेस्ट पेज के लिए हमारा अपना एक छोटा Playwright उदाहरण कुछ ऐसा दिख सकता है। यह एक ऐसे प्रोजेक्ट को मानकर चलता है जो पहले से उपयुक्त baseURL के साथ सेट किया गया है, और इसे इस लेख के लिए चलाया नहीं गया था:

import { test, expect } from '@playwright/test';

test('Offer card stays readable when narrow', async ({ page }) => {
  await page.setViewportSize({ width: 390, height: 844 });
  await page.goto('/angebot-demo');
  await expect(page).toHaveScreenshot('angebot-390.png');
});

पेज और फ़ाइल के नाम इस शिक्षण-उदाहरण का हिस्सा हैं। प्रलेखित स्क्रीनशॉट तुलना एक कैप्चर को संदर्भ के सामने रखती है। महत्वपूर्ण संपादकीय काम व्याख्या ही रहता है: क्या अंतर इच्छित है, या यह सामग्री के किसी आवश्यक हिस्से को बाहर धकेल देता है?

विचलन सबसे पहले एक अवलोकन है

diff इमेज को केवल बटन के आसपास मत देखिए। कीमत, पंक्ति-विराम और पास की टिप्पणी की जाँच कीजिए। शायद बड़ा बटन सही है, जबकि उसके बगल का लेआउट अधिक लचीलापन चाहता है। शायद कथित सुधार केवल चौड़े दृश्य में ही सार्थक था।

अनुमत विचलन को बिना सोचे तब तक मत बढ़ाइए जब तक टेस्ट फिर से हरा न हो जाए। इससे समस्या को समझे बिना प्रश्न ही बदल जाएगा। एक सहनशीलता उचित हो सकती है, लेकिन उसे देखे गए अंतरों के प्रकार के अनुरूप होना चाहिए।

इसी तरह, नया संदर्भ एक निर्णय है। इच्छित नई स्थिति अलग दिख सकती है। उसकी सामग्री का आकलन हो जाने के बाद ही उसे तुलना की बेसलाइन बनना चाहिए। वरना किसी अनदेखे दुष्प्रभाव को सीधे नई लक्ष्य-छवि घोषित कर दिया जाता है।

दिखावट के साथ वास्तविक क्लिक-पथ भी ज़रूरी है

एक जैसा दिखने वाला बटन गलत क्रिया शुरू कर सकता है। इसलिए विज़ुअल जाँच में एक पूरा परीक्षण-क्रम जोड़िए: कीबोर्ड से उस तक पहुँचिए, उसे सक्रिय कीजिए, अपेक्षित लक्ष्य-स्थिति को देखिए। स्क्रीनशॉट और व्यवहार-टेस्ट अलग-अलग प्रश्नों का उत्तर देते हैं।

यदि आप यह अभ्यास अपनी किसी WordPress साइट पर करते हैं, तो KENJTEC WordPressBuilder ai में एक कार्यशील प्रति उस स्थिति को, जिसे आप बदल रहे हैं, लाइव साइट से अलग रख सकती है। Playwright तुलना आप KENJTEC के बाहर अपने स्वयं के टूल से चलाते हैं। कार्यशील प्रति से बदलावों को अपनाना फिर एक अलग चरण है, जिसके लिए उपयुक्त दायरा चुनना होता है।

तय तुलना-दृश्यों का लाभ बदलाव को रोकने में नहीं है। वे यह दिखाते हैं कि वांछित सुधार अपने आसपास के तत्वों का सम्मान करता है या नहीं। केवल अपेक्षा, अवलोकन और वास्तविक संचालन मिलकर ही नए बटन के बारे में एक ठोस निर्णय देते हैं।

स्रोत और स्थिति

शोध और दस्तावेज़ीकरण 25 अक्टूबर 2026 की स्थिति के अनुसार। विज़ुअल तुलनाएँ।