返回 AiToEarn
adapt.md
1 > **Additional context needed**: target platforms/devices and usage contexts.
2
3 Adapt an existing design to a different context: another screen size, device, platform, or use case. The trap is treating adaptation as scaling. The job is rethinking the experience for the new context.
4
5
6 ---
7
8 ## Assess Adaptation Challenge
9
10 Understand what needs adaptation and why:
11
12 1. **Identify the source context**:
13 - What was it designed for originally? (Desktop web? Mobile app?)
14 - What assumptions were made? (Large screen? Mouse input? Fast connection?)
15 - What works well in current context?
16
17 2. **Understand target context**:
18 - **Device**: Mobile, tablet, desktop, TV, watch, print?
19 - **Input method**: Touch, mouse, keyboard, voice, gamepad?
20 - **Screen constraints**: Size, resolution, orientation?
21 - **Connection**: Fast wifi, slow 3G, offline?
22 - **Usage context**: On-the-go vs desk, quick glance vs focused reading?
23 - **User expectations**: What do users expect on this platform?
24
25 3. **Identify adaptation challenges**:
26 - What won't fit? (Content, navigation, features)
27 - What won't work? (Hover states on touch, tiny touch targets)
28 - What's inappropriate? (Desktop patterns on mobile, mobile patterns on desktop)
29
30 **CRITICAL**: Adaptation is rethinking the experience for the new context, not scaling pixels.
31
32 ## Plan Adaptation Strategy
33
34 Create context-appropriate strategy:
35
36 ### Mobile Adaptation (Desktop → Mobile)
37
38 **Layout Strategy**:
39 - Single column instead of multi-column
40 - Vertical stacking instead of side-by-side
41 - Full-width components instead of fixed widths
42 - Bottom navigation instead of top/side navigation
43
44 **Interaction Strategy**:
45 - Touch targets 44x44px minimum (not hover-dependent)
46 - Swipe gestures where appropriate (lists, carousels)
47 - Bottom sheets instead of dropdowns
48 - Thumbs-first design (controls within thumb reach)
49 - Larger tap areas with more spacing
50
51 **Content Strategy**:
52 - Progressive disclosure (don't show everything at once)
53 - Prioritize primary content (secondary content in tabs/accordions)
54 - Shorter text (more concise)
55 - Larger text (16px minimum)
56
57 **Navigation Strategy**:
58 - Hamburger menu or bottom navigation
59 - Reduce navigation complexity
60 - Sticky headers for context
61 - Back button in navigation flow
62
63 ### Tablet Adaptation (Hybrid Approach)
64
65 **Layout Strategy**:
66 - Two-column layouts (not single or three-column)
67 - Side panels for secondary content
68 - Master-detail views (list + detail)
69 - Adaptive based on orientation (portrait vs landscape)
70
71 **Interaction Strategy**:
72 - Support both touch and pointer
73 - Touch targets 44x44px but allow denser layouts than phone
74 - Side navigation drawers
75 - Multi-column forms where appropriate
76
77 ### Desktop Adaptation (Mobile → Desktop)
78
79 **Layout Strategy**:
80 - Multi-column layouts (use horizontal space)
81 - Side navigation always visible
82 - Multiple information panels simultaneously
83 - Fixed widths with max-width constraints (don't stretch to 4K)
84
85 **Interaction Strategy**:
86 - Hover states for additional information
87 - Keyboard shortcuts
88 - Right-click context menus
89 - Drag and drop where helpful
90 - Multi-select with Shift/Cmd
91
92 **Content Strategy**:
93 - Show more information upfront (less progressive disclosure)
94 - Data tables with many columns
95 - Richer visualizations
96 - More detailed descriptions
97
98 ### Print Adaptation (Screen → Print)
99
100 **Layout Strategy**:
101 - Page breaks at logical points
102 - Remove navigation, footer, interactive elements
103 - Black and white (or limited color)
104 - Proper margins for binding
105
106 **Content Strategy**:
107 - Expand shortened content (show full URLs, hidden sections)
108 - Add page numbers, headers, footers
109 - Include metadata (print date, page title)
110 - Convert charts to print-friendly versions
111
112 ### Email Adaptation (Web → Email)
113
114 **Layout Strategy**:
115 - Narrow width (600px max)
116 - Single column only
117 - Inline CSS (no external stylesheets)
118 - Table-based layouts (for email client compatibility)
119
120 **Interaction Strategy**:
121 - Large, obvious CTAs (buttons not text links)
122 - No hover states (not reliable)
123 - Deep links to web app for complex interactions
124
125 ## Implement Adaptations
126
127 Apply changes systematically:
128
129 ### Responsive Breakpoints
130
131 Choose appropriate breakpoints:
132 - Mobile: 320px-767px
133 - Tablet: 768px-1023px
134 - Desktop: 1024px+
135 - Or content-driven breakpoints (where design breaks)
136
137 ### Layout Adaptation Techniques
138
139 - **CSS Grid/Flexbox**: Reflow layouts automatically
140 - **Container Queries**: Adapt based on container, not viewport
141 - **`clamp()`**: Fluid sizing between min and max
142 - **Media queries**: Different styles for different contexts
143 - **Display properties**: Show/hide elements per context
144
145 ### Touch Adaptation
146
147 - Increase touch target sizes (44x44px minimum)
148 - Add more spacing between interactive elements
149 - Remove hover-dependent interactions
150 - Add touch feedback (ripples, highlights)
151 - Consider thumb zones (easier to reach bottom than top)
152
153 ### Content Adaptation
154
155 - Use `display: none` sparingly (still downloads)
156 - Progressive enhancement (core content first, enhancements on larger screens)
157 - Lazy loading for off-screen content
158 - Responsive images (`srcset`, `picture` element)
159
160 ### Navigation Adaptation
161
162 - Transform complex nav to hamburger/drawer on mobile
163 - Bottom nav bar for mobile apps
164 - Persistent side navigation on desktop
165 - Breadcrumbs on smaller screens for context
166
167 **IMPORTANT**: Test on real devices. Device emulation in DevTools is helpful but not perfect.
168
169 **NEVER**:
170 - Hide core functionality on mobile (if it matters, make it work)
171 - Assume desktop = powerful device (consider accessibility, older machines)
172 - Use different information architecture across contexts (confusing)
173 - Break user expectations for platform (mobile users expect mobile patterns)
174 - Forget landscape orientation on mobile/tablet
175 - Use generic breakpoints blindly (use content-driven breakpoints)
176 - Ignore touch on desktop (many desktop devices have touch)
177
178 ## Verify Adaptations
179
180 Test thoroughly across contexts:
181
182 - **Real devices**: Test on actual phones, tablets, desktops
183 - **Different orientations**: Portrait and landscape
184 - **Different browsers**: Safari, Chrome, Firefox, Edge
185 - **Different OS**: iOS, Android, Windows, macOS
186 - **Different input methods**: Touch, mouse, keyboard
187 - **Edge cases**: Very small screens (320px), very large screens (4K)
188 - **Slow connections**: Test on throttled network
189
190 When the adaptation feels native to each context, hand off to `$impeccable polish` for the final pass.
191
192 ---
193
194 ## Reference Material
195
196 The sections below were previously `responsive-design.md` and live inline now so the adapt flow has its deep responsive reference in one place.
197
198 ### Responsive Design
199
200 #### Mobile-First: Write It Right
201
202 Start with base styles for mobile, use `min-width` queries to layer complexity. Desktop-first (`max-width`) means mobile loads unnecessary styles first.
203
204 #### Breakpoints: Content-Driven
205
206 Don't chase device sizes; let content tell you where to break. Start narrow, stretch until design breaks, add breakpoint there. Three breakpoints usually suffice (640, 768, 1024px). Use `clamp()` for fluid values without breakpoints.
207
208 #### Detect Input Method, Not Just Screen Size
209
210 **Screen size doesn't tell you input method.** A laptop with touchscreen, a tablet with keyboard. Use pointer and hover queries:
211
212 ```css
213 /* Fine pointer (mouse, trackpad) */
214 @media (pointer: fine) {
215 .button { padding: 8px 16px; }
216 }
217
218 /* Coarse pointer (touch, stylus) */
219 @media (pointer: coarse) {
220 .button { padding: 12px 20px; } /* Larger touch target */
221 }
222
223 /* Device supports hover */
224 @media (hover: hover) {
225 .card:hover { transform: translateY(-2px); }
226 }
227
228 /* Device doesn't support hover (touch) */
229 @media (hover: none) {
230 .card { /* No hover state - use active instead */ }
231 }
232 ```
233
234 **Critical**: Don't rely on hover for functionality. Touch users can't hover.
235
236 #### Safe Areas: Handle the Notch
237
238 Modern phones have notches, rounded corners, and home indicators. Use `env()`:
239
240 ```css
241 body {
242 padding-top: env(safe-area-inset-top);
243 padding-bottom: env(safe-area-inset-bottom);
244 padding-left: env(safe-area-inset-left);
245 padding-right: env(safe-area-inset-right);
246 }
247
248 /* With fallback */
249 .footer {
250 padding-bottom: max(1rem, env(safe-area-inset-bottom));
251 }
252 ```
253
254 **Enable viewport-fit** in your meta tag:
255 ```html
256 <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
257 ```
258
259 #### Responsive Images: Get It Right
260
261 ##### srcset with Width Descriptors
262
263 ```html
264 <img
265 src="hero-800.jpg"
266 srcset="
267 hero-400.jpg 400w,
268 hero-800.jpg 800w,
269 hero-1200.jpg 1200w
270 "
271 sizes="(max-width: 768px) 100vw, 50vw"
272 alt="Hero image"
273 >
274 ```
275
276 **How it works**:
277 - `srcset` lists available images with their actual widths (`w` descriptors)
278 - `sizes` tells the browser how wide the image will display
279 - Browser picks the best file based on viewport width AND device pixel ratio
280
281 ##### Picture Element for Art Direction
282
283 When you need different crops/compositions (not just resolutions):
284
285 ```html
286 <picture>
287 <source media="(min-width: 768px)" srcset="wide.jpg">
288 <source media="(max-width: 767px)" srcset="tall.jpg">
289 <img src="fallback.jpg" alt="...">
290 </picture>
291 ```
292
293 #### Layout Adaptation Patterns
294
295 **Navigation**: Three stages: hamburger + drawer on mobile, horizontal compact on tablet, full with labels on desktop. **Tables**: Transform to cards on mobile using `display: block` and `data-label` attributes. **Progressive disclosure**: Use `<details>/<summary>` for content that can collapse on mobile.
296
297 #### Testing: Don't Trust DevTools Alone
298
299 DevTools device emulation is useful for layout but misses:
300
301 - Actual touch interactions
302 - Real CPU/memory constraints
303 - Network latency patterns
304 - Font rendering differences
305 - Browser chrome/keyboard appearances
306
307 **Test on at least**: One real iPhone, one real Android, a tablet if relevant. Cheap Android phones reveal performance issues you'll never see on simulators.
308
309 ---
310
311 **Avoid**: Desktop-first design. Device detection instead of feature detection. Separate mobile/desktop codebases. Ignoring tablet and landscape. Assuming all mobile devices are powerful.
312
312 lines MARKDOWN