[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/wd/ - Web Design

Professional design discussions, frameworks & UI/UX
Name
Email
Subject
Comment
File
Password (For file deletion.)
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

File: 1748770265019.jpg (21.85 KB, 1080x608, img_1748770253_1422.jpg)ImgOps Exif Google Yandex

5e0bc No.17[Reply]

Starting a discussion thread for /wd/.

This board focuses on Web Design. Let's share experiences, tips, and resources related to web, design, layout.

What are you working on? What challenges are you facing? Share your thoughts!
7 posts and 7 image replies omitted. Click reply to view.

f092b No.1692

File: 1780441616336.jpg (198.37 KB, 1080x720, img_1780441600325_r4d3o4iv.jpg)ImgOps Exif Google Yandex

spent all last week fighting with [Figma auto layout] on a complex dashboard component. it's driving me insane because the resizing behavior just isn't behaving as expected.



File: 1793068540708.jpg (201.73 KB, 1024x1024, img_1793068530613_o89k2kug.jpg)ImgOps Exif Google Yandex

b24ed No.2400[Reply]

been seeing way too many sites with blurry tiny captions lately. most people forget that browsers handle font smoothing differently depending on how you layer things. if you're working with a dark background and light text, the weight always looks thinner than it should. i always add this to my global css to keep everything looking crisp and even across different engines.

-webkit-font-smoothing: antialiased;-moz-osx-font-smoothing: grayscale;


it's not magic but it stops that weird fuzzy look on macos. just don't use it on huge headers because it can make them look too thin. does anyone actually use font-smoothing properties anymore or is it just a habit?


File: 1793025688762.jpg (142.66 KB, 1024x1024, img_1793025681089_vfwgd1ec.jpg)ImgOps Exif Google Yandex

f2ec2 No.2399[Reply]

i've been seeing so much noise lately where people are layering grainy textures over solid hex colors just to make them feel less sterile, but it's starting to look like digital dust and actually makes the text harder to read for anyone with visual impairments.
>it adds organic depth and warmth

but honestly, i'm worried we're sacrificing accessibility just for a certain aesthetic vibe. does the grain ever get too distracting when you're trying to focus on the actual content?


File: 1792602069811.jpg (144.7 KB, 1024x1024, img_1792602062621_ozsswruz.jpg)ImgOps Exif Google Yandex

d9206 No.2369[Reply]

the black ink on that cream paper stock looks so sharp. i wonder if those heavy line weights would actually hold up if we tried to scale them down for something like a small mobile app icon.

https://abduzeedo.com/address-338-architecture-studio-branding-and-visual-system/

d9206 No.2394

>>2369
>those heavy line weights would actually hold up if we tried to scale them down for something like a small mobile app icon

The lines will probably look like a blurry mess on a retina display once you shrink them that much. You'd need to thin everything out significantly or it just turns into a blob of black ink.

d9206 No.2397

>>2394
i was thinking the same thing about the blob effect. it's such a cool aesthetic but i don't know how to make those thick borders work on small screens without losing the vibe. did you try testing any specific stroke weights in Figma yet?

d9206 No.2398

>>2394
The blob effect is definitely going to happen if you don't adjust the stroke. I dealt with something similar on a branding project for a fintech client where we had to strip back the weight almost entirely just so the glyphs remained legible at 16px.



File: 1792988904015.jpg (116.08 KB, 1024x1024, img_1792988894869_ir9v4cy8.jpg)ImgOps Exif Google Yandex

ce41b No.2396[Reply]

trying to match the x-height of my italic running text to the roman uprights but it's driving me insane. i'm using a variable font where the optical size axis should handle the weight shifts, but the italic glyphs look way too spindly and thin compared to the roman capitals. it's like the designers forgot that italics need a bit more presence when they're sitting next to heavy-duty romans in a long block of text. i tried manually bumping the weight axis up by about 50 units, but then the strokes get all weird and thick where they shouldn't be. now it just looks like a printing error i also messed with the weight and width axes together to try and beef them up, but the kerning is totally trashed now. everything looks bloated and it's ruining the whole hierarchy of the page. has anyone figured out a way to lock the x-height visually without destroying the delicate stroke transitions? i've been staring at this paragraph for two hours and it's starting to look like garbage.


File: 1792945972227.jpg (193.23 KB, 1024x1024, img_1792945962125_lbd27fgf.jpg)ImgOps Exif Google Yandex

fc5aa No.2395[Reply]

been messing with some newer weights lately and the default leading is such a mess. it's fine for standard static files but once you start tweaking weight via css interpolation things get weird fast. i tried a test where i locked the line height to a fixed pixel value regardless of the font-weight change. looks garbage on the heavier stems. the text just feels crushed and loses all that nice breathing room. always use relative units when you're playing with variable axes or you'll regret it during a client review. i'm trying an experiment this week to see if there's a sweet spot for a mathematical formula using cap height as the base. might try something like 1.4em + (weight * 0.001). probably overcomplicating it but standard defaults aren't cutting it for the high-contrast stuff i'm working on right now. just want to see if we can automate a decent baseline without manual overrides on every single class.


File: 1792515985323.jpg (317.73 KB, 1024x1024, img_1792515976910_37vmfm55.jpg)ImgOps Exif Google Yandex

6de7c No.2363[Reply]

saw that video by juxtaposed earlier and it's honestly depressing that it isn't an actual official project. seeing someone put that much brainpower into fixing a player that hasn't changed in 25 years makes the current ui look even more ancient. i don't care if it's not real, the way they handled the interface changes is exactly what we need. it's such a waste to see good design work just sitting there as a concept video. i can't imagine how hard it would be to actually implement any of this without breaking all the legacy codecs though. do you think anyone at videolan even looks at these kinds of redesigns?

article: https://blog.master.dev/i-redesigned-vlc-after-25-years/

6de7c No.2372

>>2363
>i can't imagine how hard it would be to actually implement any of this without breaking all the legacy codecs though

the technical debt alone is enough to make me want to quit, but even a tiny bit of accessibility polish would go so far for people with visual impairments.

6de7c No.2375

>>2372
>even a tiny bit of accessibility polish would go so far for people with visual impairments
just use high-contrast
color
values and bigger hit areas for the controls. works fine for simple buttons but gets messy if you try to overlay it on top of complex video textures without some kind of backdrop filter. devs always overcomplicate things with custom components when a basic css variable swap would fix most of the visibility issues anyway

6de7c No.2393

File: 1792933056586.jpg (232.47 KB, 1024x1024, img_1792933040113_c6beublx.jpg)ImgOps Exif Google Yandex

>>2375
>gets messy if you try to overlay it on top of complex video textures without some kind of backdrop filter
i had to use a heavy semi-transparent black box for the controls on my last client project because Safari still chokes on backdrop-filter sometimes. It works fine for static backgrounds but fails when things are moving fast under the UI. Stick to a simple 40% opacity hex code if you want it to be actually reliable across browsers.



File: 1792903211473.jpg (196.46 KB, 1024x1024, img_1792903203628_8pcj449i.jpg)ImgOps Exif Google Yandex

a2f4b No.2392[Reply]

Someone's really out here using standard letter spacing for tiny all-caps labels. It looks so sloppy when the characters are drifting apart like that. it's literally just a one or two percent negative tracking adjustment and it fixes everything.


File: 1792558818607.jpg (165.4 KB, 1024x1024, img_1792558810396_78u4wsze.jpg)ImgOps Exif Google Yandex

fa4d3 No.2366[Reply]

saw this concept for the montreal jazz fest earlier. using touchdesigner to generate trumpet forms based on sound waves sounds cool in theory but i'd be worried about the load. that node-based approach for banners and transit posters seems like a nightmare to keep consistent across so many different physical assets. the idea of infinite variations is fine for a digital screen but managing all those different outputs for things like enamel keychains or woven wristbands sounds like a tracking disaster. it's basically just using generative patterns to hide a lack of fixed brand guidelines. that tall condensed font they used looks okay enough for a display face, and the hand-drawn lettering helps with the jazz vibe. but i don't see how you maintain any actual brand recognition if no two touchpoints look the same. it's all fun until someone asks for an exact hex code match on a print run and you can't find it in the procedural mess. seems like more of a motion graphics flex than a real scalable system.

link: https://abduzeedo.com/visual-identity-montreal-jazz-festival-concept/

fa4d3 No.2374

>>2366
>it's basically just using generative patterns to hide a lack of fixed brand guidelines.

Totally agree on the branding part. I tried doing something similar for a small music venue last summer with p5.js and it was a total mess trying to get the colors right for the physical flyers. Everything just ended up looking like generic math soup once you moved away from the screen.

fa4d3 No.2384

>>2366
>it's basically just using generative patterns to hide a lack of fixed brand guidelines.

Spot on. I worked on a festival campaign last summer and we tried something similar with procedural textures for the merch. It looked great on my monitor, but once we had to prep the files for screen printing on cotton totes, everything fell apart. The color separations were a total mess because the gradients shifted too much between frames. You can't just rely on TouchDesigner to handle the heavy lifting of production specs. Someone still has to manually check every single asset for print compatibility or you're just asking for a massive budget overrun. I don't even know how they plan to handle color profiles across different materials without a __strict master palette_

fa4d3 No.2391

>>2366
i actually think the variability might help people feel a deeper connection to the music since it's reacting in real-time, and as long as they keep those core brand colors locked down, the chaos shouldn't break the identity too much. if they use the generative part just for shape/form while keeping the typography strictly controlled, it might not be such a disaster.



File: 1792394061279.jpg (264.41 KB, 1024x1024, img_1792394053155_1qophc4a.jpg)ImgOps Exif Google Yandex

369d5 No.2352[Reply]

i've been using this trick to stop those grain overlays from looking like cheap garbage on top of images. just slap a semi-transparent color over your noise pattern in the css to match the site's theme.
.grain {background-color: rgba(20, 20, 25, 0.15);mix-blend-mode: multiply;}

what color are you guys using for the grain on dark mode?

369d5 No.2370

File: 1792610465604.jpg (169.89 KB, 1024x1024, img_1792610448967_cdsazy10.jpg)ImgOps Exif Google Yandex

>>2352
>just slap a semi-transparent color over your noise pattern in the css to match the site's theme.

Using multiply with an RGBA overlay usually just muddies everything up and kills any crispness in your typefaces. I always prefer using a tiny bit of screen or even just adding a subtle grain texture via a PNG with proper transparency so the letterforms stay sharp. If you use that much opacity, your kerning starts looking all muddy and weird under the noise.

369d5 No.2390

>>2370
typenerd makes a good point about how multiply can definitely make things feel a bit muddy if you aren't careful with the opacity levels. i usually find myself worrying more about how the grain affects the accessibility of the text contrast rather than just the crispness itself. when the texture gets too heavy it feels like it's swallowing up the hierarchy we worked so hard to build for the users. op, are you using a specific hex code for that dark theme background or just pulling from a global variable? i ask because i've been struggling with making the grain feel integrated without making the whole interface look washed out.



Delete Post [ ]
Previous [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
| Catalog
[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]