When we designed Chrome, since minimalism was our thing and screens used to be small, A LOT of time was spent on the total vertical space - thin titlebar, slightly bigger tabstrip, and a large toolbar. Lots of discussion, lots of questions
Telling people the height ratios between them followed the golden ratio was a very convenient way to shortcut the bikeshedding and get to "aha, very nice"
The trick was it didn't follow the golden ratio at all because the golden ratio is not some magic number that leads to balance and peace - lighting, rounding, color, and visual strength all dramatically outweigh it
Ah, explanations that are treated as justifications without actually justifying anything.
“Vertical rhythm” in website layout. Utter nonsense. Valuable in print layout (for adjacent columns or double-sided paper), completely useless in digital (unless you have side-by-side columns with headings or pictures mixed in, but this is seldom seen outside print, partly because the web doesn’t support it well).
“Modular scales” in choosing font sizes. Typically worse than utter nonsense, because you want heading levels to be distinctive, and modular scales will harm this by forcing lower heading levels to be too small.
Force all your app icons into a rounded square or squircle or circle, because consistency. No! Now you can’t find anything easily. Android was so much better before that nonsense started.
Monochrome icons deliberately designed to look the same. Now they’re unmemorable. Colour was a useful signal.
(This comment is generic; I’m not saying anything about LiftKit here, for or against.)
I agree with your criticism of design dogma - it drives me nuts too - people saying something bad is good because it follows the rules. But since I'm also responsible for the Android icon shape-change you talked about, let me waffle for a bit in case it helps provide a perspective on the other side of that decision:
I agree with that the non-uniform icons are easier to find, and that uniform shapes make it harder (I also agree that uniform colors are awful, but that was after my time so I have no stake in that).
However, usability is not about pure efficiency - a huge amount of it is approachability - people have to _want_ to use the UI. If they don't want to use it, no amount of pure-usability work will mean anything - it will just be "shitty computers" in their heads. In Android's case, the developer-provided weirdly shaped icons were a major sticking point - people would take one look at an Android homescreen with all kinds of mismatched splatters of icons, mentally lump it with Windows and Linux in the must-be-for-geeks bucket, and walk off to the Apple store.
It drove us nuts - in actual tests, people would often find Android easier and more efficient to use, but would still pick iPhone as the "easier" product, because that's the one that was inviting, that fit their style, that looked easy to use.
So we did a lot of work nudging Android to a place where real people would find it desirable, easy, and powerful - making really difficult tradeoffs - sometimes breaking expectations, sometimes sacrificing a little bit here and there to gain a lot somewhere else, sometimes just taking a chance.
It took a lot of effort from a lot of wonderful people, and it involved a stupidly large amount of arguing against "just copy iPhone" laziness and pressure (a major reason I left), but I am still deeply proud of what the team was able to do. We couldn't please everyone, but I think more people were pleased afterwards than before.
You only have to watch the WWDC videos from the designers regarding Liquid Glass, and appreciate how much "improved" the macOS with Tahoe experience feels like in practice.
Same applies to sessions on Fluent or Material designs, and how they end up on the respective OSes.
The whole design rhetoric of the recent years is just so bad. It's all vague feel-words that are straight out of a marketing playbook and don't communicate anything concrete.
The Liquid Glass guidance is so emblematic of this. What in the slop is "providing a more dynamic and expressive user experience that elevates the content" even supposed to mean when we're talking about an app that shows a scrollview with a tab bar and a few buttons?
Reading the early 2010s HIGs is such a breath of fresh air in comparison, where it's just a succession of clear statements like "Controls should look tappable. iOS controls, such as buttons, pickers, and sliders, have contours and gradients that invite touches".
Just two entirely different school of thoughts. One based on research, evidence, clear actionable items; the other is just pure vibes. Something of value's been truly lost along the way.
Hi everyone, I'm the creator of LiftKit. This project is EXTREMELY early and, as everyone has pointed out, not ready for production use. It's a solo project I work on in my free time. I'm a self-taught, so a lot of the weird choices you're seeing can be attributed to the decisions of someone who had never built something like this before.
LIFTKIT IS FREE AND OPEN SOURCE. The website's just out of date.
I like your design idea in principle but you said in the reddit thread 7 months ago in regards to rendering the components that "Besides the landing page itself, not yet. That's the next priority". Now you don't mention it as a priority anymore. It's a pretty big red flag for ui frameworks not to be able to render their ui components in their own docs.
I love the project -- even if I agree with a lot of the critique in this thread. Critique that is very high quality, professional feedback that you should take as a very big compliment.
I think every Front End developer or designer dreams of this idea(+) at some point, but you're the madlad who actually did it. It feels like you've posted an implementation of everyone's baby and tugged at our heart-strings ;)
It's fantastic, keep going.
(+) a truly consistent design system that Just Works. See GEB for why not :(
Unfortunately I've already ported in all the radix primitives. I actually found out about Base literally the exact day I finished it. Then I saw shadcn just upgraded to Base. So it looks like shad once again proves the gary oak in the completely one-sided rivalry that lives entirely in my own head. except instead of Ash I'm like youngster joey with a copilot subscription
Here's a tip: any time you've got before/after screen grabs, don't do this thing where you've got to drag a line to switch between the two, don't have a fade, don't have a sliding transition, or anything like that. Just have it display one, then have a single button that you click to have it immediately display the other. Then when you click the button again, it goes back to displaying the first one again. Click, click, click - and your eyes do all the work for you.
Also: I can't work out which image is which. Taking the first image as an example: we've got MATERIAL-STYLE on the left, and LIFTKIT on the right. But what's the left? Does this mean that when you drag the line to the right, revealing the left image, you're looking at MATERIAL-STYLE? Or does this mean you see MATERIAL-STYLE when you drag the line to the left?
(This might seem like pointless quibbling, but this thing bills itself as the The UI Framework for Perfectionists.)
Hey Tom, I'm the creator. They're actually even worse than what you're describing. On touchscreens, the handle slides up and down as you try to move it left or right. Horrible, isn't it? One of these days, I'll get around to fixing it. The only reason it hasn't been done yet is that, to be perfectly honest, you're the first one to give this feedback. So I appreciate it!
If you got rid of the slider entirely and just had it flick between the two images instantly, the entire handle business would become irrelevant, and you'd never need to think about it again!
I admit I don't do web stuff, so perhaps this is hard to do. But I think it's the ideal. Before/after comparisons are very easy to assess if you can flick between the two cases and let your eyes show you the differences. The value of having an image that's part one and part the other (and two completely separate parts!) seems a bit questionable.
(My line of work means I'm unlikely to end up a customer, so you don't have to pay attention to my opinions.)
The flipping-between is a great hack -- as you said your eyes (really, brain) just do the work for you.
I learnt about it in Japan where proof-readers and editors would (or do) quickly lift a top page up and down to spot mistakes with kanji (pictographs). And sure enough, even from a page of dense script the dissonance of the error really does pop out at you.
I likewise tucked that little trick into my belt -- it comes in useful anytime you're trying to manually spot a pattern across complex data. This technique has the same "vibe" as FFTs to me: it's just neat feeling like you're getting computation from the universe for free.
Solar PV in a similar category: free electrons if you can arrange the magic rocks just right :)
I use ScreenFloat[0] in a similar way to catch differences between GUI settings, like the cPanel PHP extensions selector, which has tons of checkboxes. Position a screenshot of settings for site A over the settings for site B, adjust the transparency, and any differences will jump out.
If you put two proofs side by side, you can view from the right distance then uncross or cross your eyes like a stereogram till they converge, which makes differences shimmer.
I'd like to imagine I know which of each example were better designed, but the handle going to the side opposite from the label was making me second guess. Move handle away from the label to reveal is how I took it, so hope that's what you intended.
OTOH, I'm on touch screen (iPad/iOS26/WebKit) and it didn't go up and down, it went side to side.
As other feedback, the dumpster fire and deprecation warnings in the docs make me want to try this. I find builder-to-builder candor refreshingly helpful, treating your doc reader like an actual partner instead of like a euphemism. Appreciate your same candor throughout these comments.
Chainlift > Agency Services > Team menu option seems inert.
I always found this UI pattern a bit odd, because there just aren't that many situations where you want to compare the left side of image A and the right side of image B.
I see it a lot in photography, to show before/after processing - but what you want to be able to quickly compare are the same part of an image with and without the processing applied.
One of the photography tools I make is a LUT viewer/converter - and while I didn't have the slider at first, I guess it's standard enough at this point that people asked for it and I added it.
But I made two additions to it that make it more useful IMO:
- have labels on the left/right top corners, so it's immediately clear which version of the image you're looking at
- click and hold on the image to preview the full unprocessed version; release to revert to the view. That makes it easy to quickly compare the two versions of the same spot of a photo. (similar to what you suggest, but non-latching)
I've been wondering that myself. The descriptions seem to indicate that fully dragged to the left is liftkit, but my first assumption was that would be fully dragged to the right.
it's bad UX.
There's a little tiny arrow on the line's grab indicator showing which "side" you should look at. You can barely see it. Below there's the two labels floated to either side...
I agree, the x-axis labels are not helpful! Thankfully, the first example is “buttons with corrected icon spacing”, and the image on the right looks much better than the one on the left (a bigger difference in quality than in the other two examples), which is visible when the slider is on the left.
Suggestion to devs: put the label “material-style” in the lower left of its image and “liftkit” in the lower right of its image, and cover them appropriately as the slider moves, and then it'll be clear which framework the current image (or portion of it) belongs to.
If you were going to do this for the slider approach you can arrange the labels to the `block-start` and `block-end` of the image and support non-RTL scripts/languages natively.
I thought this was an unhinged parody of a design site, kinda surprised it's a real thing. Unfortunately the design isn't for me, things look off center and the overall "weight" of components feels off.
I hate to pile on since it's already getting some criticism, but I agree. It's kind of a good example why designers don't purely rely on mathematically consistent designs. Getting things to "look right" often means shifting pixels here and there ever so slightly, so that the math is a bit off but it feels better on the eyes.
Yeah I tried using a similar "golden rule" after reading a design article about it. I based my css variable sizes on it but I kept having to use manual px and rem values instead because stuff just never felt correct.
1.618 is complete nonsense that people hang on to because they want it to be true. It doesn't stack up, neither in ancient Greek times, nor in the renaissance, nor today. It's a dumb idea that needs to die.
LiftKit's free forever to anyone. It's just early stages and bad.
The idea was that if a company wanted to hire us for direct support, we'd do that. But the problems are: [A] no enterprise in their right minds would use this thing in its current state and [B] "us" is me and I don't have time to do that anymore
Yes, I too felt that way as I began to read, it was an immediate disappointment, kind of, that the UI wasn’t on full display, front and center.
I wouldn’t trust a framework that requires me to involve myself with JavaScript, nextJS, and React, also… but I am generally of the opinion that a framework pitching itself as a UI kit, must pretty much not be a plugin for a web browser…
Yeah the docs are like that because I didn't know React well enough to make my own docs and so I stuck with Webflow and realized very quickly I'd made a huge mistake. But I needed to get something out there to buy time while I figure out how to make grownup docs.
I tried to find pricing for it (the top "contact sales" is a no-starter; too much initial friction. Just tell me how much it costs?! At the footer is a pricing calculator... I asked for pricing for 10 top-level pages and 5 sub-level pages (they explain the difference)... came out to a whopping $16,500 (you're reading that right... SIXTEEN THOUSAND). No thanks.
Agreed. New docs are under construction and they'll be posted on a separate website. The agency came first and then liftkit came after, which is why it's hosted on there now. But I'm shutting down agency operations and so the whole thing will be liftkit eventually.
Thanks! Yep, super gimmick. I picked golden ratio because I thought it was a good eyecatcher.
To be clear; You don't HAVE to use the golden ratio. You can set your global scale factor to anything you want in /liftkit-core.css. I just use 1.618 because I like it.
You don't actually HAVE to use phi. That's just the default global scale factor. You're correct that it's kinda marketing spiel. I figured I needed an angle to stand out in the crowded design system world and now I'm paying the consequences in this absolute roastfest, lol.
The only real reason I use phi is because it's very useful in asymmetrical typography scaling. At small type levels, differences in font size are more visually apparent than at large sizes. In other words, 14px vs 16px looks more noticeable to me than 38px vs 40px. So, my goal was to find a rem coefficient that would provide large jumps at large sizes, but I could also use the square root of it to derive smaller increments. I tried phi on a whim one day and realized I liked it.
I also went to apple's HIG and looked at the type specs for MacOS and put them into a spreadsheet. I found that the proportions of line height to font size hovered around 1.272 (which is the sq root of 1.618, or phi). Then I found similar patterns in the ratios of difference font sizes to each other (I think. It was back in 2022).
I also did a bunch of personal tests where I'd try to eyeball line heights and padding and stuff without snapping or looking at the metrics, and my preferences kept landing around golden ratio proportions. Biased? 100%. But I haven't got access to focus groups, and every time I asked my boyfriend to try it for me he'd be all like "please get a job you promised you'd work on your resume today"
So then I looked into other research. I can't find the study because I unpublished the article where I linked it, like a dumbass, but studies have shown that laypeople can tell the difference between abstract art based on rules like fractal symmetry and the golden ratio versus art made by children or animals at a rate of about 60% accuracy. Im on my phone right now but if you're curious I'll gladly look it up for you. I took that to mean "well, if we're entering an age of AI generated interfaces, then eventually we'll need to distill the essence of what looks good into certain mathematical principles so that there's a quantifiable "baseline" for quality that models can rely on. Golden ratio!" (Note: I do not know how AI actually works)
Finally, I got obsessed with that damn material button. There were ads on BART for some Google thing showing a button and it just looked off center to me. It haunted me for weeks. I couldn't stop looking at it. So I thought I'd try finding a reliable way to achieve the correct optical offset, but programmatically, so a designer wouldn't just have to do eyeball every button every time.
So, it's not totally baseless. But it's not a magic number either.
I don't think their homepage looks good, and for so much attention to detail the padding around text titles and other spacing, specially on mobile, doesn't look good. Not of the elements they showcase but of their own landing page.
I can't tell which one is supposed to be good, and the design is not intuitive enough for me to know which is the LiftKit (the one I'm supposed to prefer).
The creator of this is a friend of mine and just gonna chime in that he’s a fantastic and talented dude. Nice surprise to see his project listed here! I think he’s working on something new called Liftkit Studio too I’m looking forward to.
He has a cool YouTube channel too. Check out “The Secret Science of Perfect Spacing”
>In LiftKit, everything derives from the golden ratio,
I don't think the authors realise the extent to which their product, which looks well made and useful, is being completely undermined with this nonsensical pseudoscience.
Hi, I'm the author, it me. You're right, I need to be clearer that golden ratio doesn't automatically equal beautiful. It's not sacred geometry. It's just pretty. I like it. And studies show people at large tend to find the proportions pleasing.
It's just a rule of thumb, that's all. I just went crazy on the copywriting because I thought I'd need to in order to get the kit to stand out.
I have now been extremely informed that this is not the case.
> And studies show people at large tend to find the proportions pleasing.
I don't think that's the case - or at least, not well-designed studies. There's nothing to suggest that people prefer 1.618 more than 1.61 or even 1.6, and probably not 1.5. It's like if we found people like the colour blue and then claimed that people like the shade of Mary's veil or something.
I didn't know what web components were until after I'd released it for React. I was working in a complete vacuum until I put this out there, and then I started to get involved with the community. Before that I was pretty much the only designer/techie I knew. I'm not a professional developer. I'm just a designer who knows enough TS to piece things together.
So having it for React/NextJS isn't an affirmative decision. It's just the only thing I knew how to do at the time. After the first launch last summer I had a couple folks reach out to help port to SvelteKit and Vue, but you know how it is. People get busy.
When we designed Chrome, since minimalism was our thing and screens used to be small, A LOT of time was spent on the total vertical space - thin titlebar, slightly bigger tabstrip, and a large toolbar. Lots of discussion, lots of questions
Telling people the height ratios between them followed the golden ratio was a very convenient way to shortcut the bikeshedding and get to "aha, very nice"
The trick was it didn't follow the golden ratio at all because the golden ratio is not some magic number that leads to balance and peace - lighting, rounding, color, and visual strength all dramatically outweigh it
maybe the golden ratio was the friends we made along the way
Ah, explanations that are treated as justifications without actually justifying anything.
“Vertical rhythm” in website layout. Utter nonsense. Valuable in print layout (for adjacent columns or double-sided paper), completely useless in digital (unless you have side-by-side columns with headings or pictures mixed in, but this is seldom seen outside print, partly because the web doesn’t support it well).
“Modular scales” in choosing font sizes. Typically worse than utter nonsense, because you want heading levels to be distinctive, and modular scales will harm this by forcing lower heading levels to be too small.
Force all your app icons into a rounded square or squircle or circle, because consistency. No! Now you can’t find anything easily. Android was so much better before that nonsense started.
Monochrome icons deliberately designed to look the same. Now they’re unmemorable. Colour was a useful signal.
(This comment is generic; I’m not saying anything about LiftKit here, for or against.)
I agree with your criticism of design dogma - it drives me nuts too - people saying something bad is good because it follows the rules. But since I'm also responsible for the Android icon shape-change you talked about, let me waffle for a bit in case it helps provide a perspective on the other side of that decision:
I agree with that the non-uniform icons are easier to find, and that uniform shapes make it harder (I also agree that uniform colors are awful, but that was after my time so I have no stake in that).
However, usability is not about pure efficiency - a huge amount of it is approachability - people have to _want_ to use the UI. If they don't want to use it, no amount of pure-usability work will mean anything - it will just be "shitty computers" in their heads. In Android's case, the developer-provided weirdly shaped icons were a major sticking point - people would take one look at an Android homescreen with all kinds of mismatched splatters of icons, mentally lump it with Windows and Linux in the must-be-for-geeks bucket, and walk off to the Apple store.
It drove us nuts - in actual tests, people would often find Android easier and more efficient to use, but would still pick iPhone as the "easier" product, because that's the one that was inviting, that fit their style, that looked easy to use.
So we did a lot of work nudging Android to a place where real people would find it desirable, easy, and powerful - making really difficult tradeoffs - sometimes breaking expectations, sometimes sacrificing a little bit here and there to gain a lot somewhere else, sometimes just taking a chance.
It took a lot of effort from a lot of wonderful people, and it involved a stupidly large amount of arguing against "just copy iPhone" laziness and pressure (a major reason I left), but I am still deeply proud of what the team was able to do. We couldn't please everyone, but I think more people were pleased afterwards than before.
You only have to watch the WWDC videos from the designers regarding Liquid Glass, and appreciate how much "improved" the macOS with Tahoe experience feels like in practice.
Same applies to sessions on Fluent or Material designs, and how they end up on the respective OSes.
The whole design rhetoric of the recent years is just so bad. It's all vague feel-words that are straight out of a marketing playbook and don't communicate anything concrete.
The Liquid Glass guidance is so emblematic of this. What in the slop is "providing a more dynamic and expressive user experience that elevates the content" even supposed to mean when we're talking about an app that shows a scrollview with a tab bar and a few buttons?
Reading the early 2010s HIGs is such a breath of fresh air in comparison, where it's just a succession of clear statements like "Controls should look tappable. iOS controls, such as buttons, pickers, and sliders, have contours and gradients that invite touches".
Just two entirely different school of thoughts. One based on research, evidence, clear actionable items; the other is just pure vibes. Something of value's been truly lost along the way.
Hi everyone, I'm the creator of LiftKit. This project is EXTREMELY early and, as everyone has pointed out, not ready for production use. It's a solo project I work on in my free time. I'm a self-taught, so a lot of the weird choices you're seeing can be attributed to the decisions of someone who had never built something like this before.
LIFTKIT IS FREE AND OPEN SOURCE. The website's just out of date.
https://github.com/Chainlift/liftkit
Most of the feedback folks are providing here was raised about 6 months ago on Reddit and is actively being worked on. You can check it out here: https://www.reddit.com/r/webdev/comments/1m41arx/i_spent_18_...
KNOWN ISSUES INCLUDE: - Docs are a nightmare, screenshots are ridiculous instead of real components - Components are inaccessible spaghetti
CURRENT PRIORITIES: - Rebuilding with radix primitives - Improving docs
TO LEARN MORE: - This youtube video explains the gist of the system (though it's also a little outdated) https://www.youtube.com/watch?v=r1DANFZYJDw
I'll reply to folks as best I can.
I like your design idea in principle but you said in the reddit thread 7 months ago in regards to rendering the components that "Besides the landing page itself, not yet. That's the next priority". Now you don't mention it as a priority anymore. It's a pretty big red flag for ui frameworks not to be able to render their ui components in their own docs.
Hi Garrett,
I love the project -- even if I agree with a lot of the critique in this thread. Critique that is very high quality, professional feedback that you should take as a very big compliment.
I think every Front End developer or designer dreams of this idea(+) at some point, but you're the madlad who actually did it. It feels like you've posted an implementation of everyone's baby and tugged at our heart-strings ;)
It's fantastic, keep going.
(+) a truly consistent design system that Just Works. See GEB for why not :(
Aw. Got me emotional over here. Thank you for the support! Definitely won't give up. And definitely do take the feedback as a compliment!
Yeah seriously, clearly seeing the heart that went into this
To the moon Macky boy!
> Rebuilding with radix primitives
Check out Base UI (or React Aria) instead.
Unfortunately I've already ported in all the radix primitives. I actually found out about Base literally the exact day I finished it. Then I saw shadcn just upgraded to Base. So it looks like shad once again proves the gary oak in the completely one-sided rivalry that lives entirely in my own head. except instead of Ash I'm like youngster joey with a copilot subscription
> So it looks like shad once again proves the gary oak
Shad did this way late AFTER everyone said Radix was unmaintained though.
Quite a few of the original Radix devs moved to work on Base.
For the ui comparisons, making the shadcn/materialui elements darker/low contrast is highly dishonest.
Compare like with like, not a badly colored and low contrast version of the competition against yours.
But my versions are the lower contrast ones.
edit: wait are you on light mode or dark mode? I work in light mode where mine are lower contrast but i swapped to dark and now it's reversed.
Here's a tip: any time you've got before/after screen grabs, don't do this thing where you've got to drag a line to switch between the two, don't have a fade, don't have a sliding transition, or anything like that. Just have it display one, then have a single button that you click to have it immediately display the other. Then when you click the button again, it goes back to displaying the first one again. Click, click, click - and your eyes do all the work for you.
(Not unrelated: answer from Andrei Herasimchuk at https://www.quora.com/Why-does-Adobe-Photoshop-differentiate...)
Also: I can't work out which image is which. Taking the first image as an example: we've got MATERIAL-STYLE on the left, and LIFTKIT on the right. But what's the left? Does this mean that when you drag the line to the right, revealing the left image, you're looking at MATERIAL-STYLE? Or does this mean you see MATERIAL-STYLE when you drag the line to the left?
(This might seem like pointless quibbling, but this thing bills itself as the The UI Framework for Perfectionists.)
Hey Tom, I'm the creator. They're actually even worse than what you're describing. On touchscreens, the handle slides up and down as you try to move it left or right. Horrible, isn't it? One of these days, I'll get around to fixing it. The only reason it hasn't been done yet is that, to be perfectly honest, you're the first one to give this feedback. So I appreciate it!
If you got rid of the slider entirely and just had it flick between the two images instantly, the entire handle business would become irrelevant, and you'd never need to think about it again!
I admit I don't do web stuff, so perhaps this is hard to do. But I think it's the ideal. Before/after comparisons are very easy to assess if you can flick between the two cases and let your eyes show you the differences. The value of having an image that's part one and part the other (and two completely separate parts!) seems a bit questionable.
(My line of work means I'm unlikely to end up a customer, so you don't have to pay attention to my opinions.)
The flipping-between is a great hack -- as you said your eyes (really, brain) just do the work for you.
I learnt about it in Japan where proof-readers and editors would (or do) quickly lift a top page up and down to spot mistakes with kanji (pictographs). And sure enough, even from a page of dense script the dissonance of the error really does pop out at you.
I likewise tucked that little trick into my belt -- it comes in useful anytime you're trying to manually spot a pattern across complex data. This technique has the same "vibe" as FFTs to me: it's just neat feeling like you're getting computation from the universe for free.
Solar PV in a similar category: free electrons if you can arrange the magic rocks just right :)
I use ScreenFloat[0] in a similar way to catch differences between GUI settings, like the cPanel PHP extensions selector, which has tons of checkboxes. Position a screenshot of settings for site A over the settings for site B, adjust the transparency, and any differences will jump out.
[0] https://eternalstorms.at/ScreenFloat/
If you put two proofs side by side, you can view from the right distance then uncross or cross your eyes like a stereogram till they converge, which makes differences shimmer.
Instant "spot the difference" solve.
// Long time in print and digital agency
Whoa that's fascinating! Thank you so much for sharing this, I never would've thought of it that way at all.
No, the opinion is valid. And it's not hard to do, what you're describing. In fact, it's easier than what I've actually done here.
I also had a lot of trouble figuring out which side was supposed to be which.
Don't even have a button. Just put both items next to each other.
I'd like to imagine I know which of each example were better designed, but the handle going to the side opposite from the label was making me second guess. Move handle away from the label to reveal is how I took it, so hope that's what you intended.
OTOH, I'm on touch screen (iPad/iOS26/WebKit) and it didn't go up and down, it went side to side.
As other feedback, the dumpster fire and deprecation warnings in the docs make me want to try this. I find builder-to-builder candor refreshingly helpful, treating your doc reader like an actual partner instead of like a euphemism. Appreciate your same candor throughout these comments.
Chainlift > Agency Services > Team menu option seems inert.
I'm not on LinkedIn all that much but I'm there.
I always found this UI pattern a bit odd, because there just aren't that many situations where you want to compare the left side of image A and the right side of image B.
I see it a lot in photography, to show before/after processing - but what you want to be able to quickly compare are the same part of an image with and without the processing applied.
One of the photography tools I make is a LUT viewer/converter - and while I didn't have the slider at first, I guess it's standard enough at this point that people asked for it and I added it.
But I made two additions to it that make it more useful IMO:
- have labels on the left/right top corners, so it's immediately clear which version of the image you're looking at
- click and hold on the image to preview the full unprocessed version; release to revert to the view. That makes it easy to quickly compare the two versions of the same spot of a photo. (similar to what you suggest, but non-latching)
I have a video of it in action here:
https://lutlab.com/#viewer-photo
I've been wondering that myself. The descriptions seem to indicate that fully dragged to the left is liftkit, but my first assumption was that would be fully dragged to the right.
it's bad UX. There's a little tiny arrow on the line's grab indicator showing which "side" you should look at. You can barely see it. Below there's the two labels floated to either side...
If you're referring to the <·> thing, you could well be right? I figured that was merely an indication that you could drag the thing sideways!
(And I'm clearly not the only one that feels this aspect of the site would benefit from another pass...)
Ironically a UX double entendre that misses both.
I agree, the x-axis labels are not helpful! Thankfully, the first example is “buttons with corrected icon spacing”, and the image on the right looks much better than the one on the left (a bigger difference in quality than in the other two examples), which is visible when the slider is on the left.
Suggestion to devs: put the label “material-style” in the lower left of its image and “liftkit” in the lower right of its image, and cover them appropriately as the slider moves, and then it'll be clear which framework the current image (or portion of it) belongs to.
Thanks for the tip! That actually was the first idea but I didn't end up doing it, for some reason. Thanks for the suggestion.
... just to be a (hopefully helpful) pedant:
If you were going to do this for the slider approach you can arrange the labels to the `block-start` and `block-end` of the image and support non-RTL scripts/languages natively.
I thought this was an unhinged parody of a design site, kinda surprised it's a real thing. Unfortunately the design isn't for me, things look off center and the overall "weight" of components feels off.
100 agree, I was like "this does look better" then realised I was saying it for the before in every example.
I hate to pile on since it's already getting some criticism, but I agree. It's kind of a good example why designers don't purely rely on mathematically consistent designs. Getting things to "look right" often means shifting pixels here and there ever so slightly, so that the math is a bit off but it feels better on the eyes.
Agreed. I’ve spent considerable time on scale-based design, and 1.618 always feels too large of an interval.
Yep. It's way too large in linear scales. but if youre using an asymmetrical scale, it can be quite useful indeed.
You don't have to use it though. The system works with any scale factor. 1.618 is just the default.
This video explains in detail how the system works with lots of visual aids.
https://youtu.be/r1DANFZYJDw
Yeah I tried using a similar "golden rule" after reading a design article about it. I based my css variable sizes on it but I kept having to use manual px and rem values instead because stuff just never felt correct.
1.618 is complete nonsense that people hang on to because they want it to be true. It doesn't stack up, neither in ancient Greek times, nor in the renaissance, nor today. It's a dumb idea that needs to die.
but nautilus shells pretty
I had the same thought: everything looks off.
I wouldn't trust a UI framework where all of the components are shown as images instead of instances of the actual UI framework...
I clicked on Dropdown, thinking it's one of the more complex things to implement. It doesn't even have a picture.
I did the same with Select. No picture and the API doesn't make sense. The options are specified twice.
https://www.chainlift.io/components/select
Yeah it's a huge problem. Not accessible either. Idk what I was thinking.
The next release will use radix primitives.
If they showed the actual css, people could just ... copy it, and then how could they charge for the secret golden ratio code lol
The CSS is in the github repo here: https://github.com/Chainlift/liftkit
LiftKit's free forever to anyone. It's just early stages and bad.
The idea was that if a company wanted to hire us for direct support, we'd do that. But the problems are: [A] no enterprise in their right minds would use this thing in its current state and [B] "us" is me and I don't have time to do that anymore
There is that, but I get the impression that you could hire an expert to help.
yeah it's hella pushy about that isn't it? really need to tone it down
And one that drops frames when I scroll through on Firefox.
lord, really? which one?
Yes, I too felt that way as I began to read, it was an immediate disappointment, kind of, that the UI wasn’t on full display, front and center.
I wouldn’t trust a framework that requires me to involve myself with JavaScript, nextJS, and React, also… but I am generally of the opinion that a framework pitching itself as a UI kit, must pretty much not be a plugin for a web browser…
Yeah the docs are like that because I didn't know React well enough to make my own docs and so I stuck with Webflow and realized very quickly I'd made a huge mistake. But I needed to get something out there to buy time while I figure out how to make grownup docs.
If the site stutters when I scroll in my browser [1], it's a great endorsement for the underlying library, right?
[1] M3Pro, Firefox. No, I'm not trying in Chrome.
I tried to find pricing for it (the top "contact sales" is a no-starter; too much initial friction. Just tell me how much it costs?! At the footer is a pricing calculator... I asked for pricing for 10 top-level pages and 5 sub-level pages (they explain the difference)... came out to a whopping $16,500 (you're reading that right... SIXTEEN THOUSAND). No thanks.
this seems to be for custom design services. IANAL but the libraries and design language seems to be open source and free to use.
Indeed; if you look at the top nav this is a site that's an agency first and a design system second.
This design system really deserves its own site.
Agreed. New docs are under construction and they'll be posted on a separate website. The agency came first and then liftkit came after, which is why it's hosted on there now. But I'm shutting down agency operations and so the whole thing will be liftkit eventually.
https://github.com/Chainlift/liftkit
Next.js without Tailwind ... why not just make it a fuckin tailwind plugin lol
Because I didn't/don't know tailwind super well.
There is a community plugin, though. https://github.com/jellydeck/liftkit-tailwind
Hahaha are you the one who submitted the form with the email address "FUCK_YOU@DUMB.COM"?
That calculator is for agency services. LiftKit itself is free.
Bless you for responding to all these comments. The realness is amazing.
Good luck! I always wanted something like this, too.
There is a great research paper on the topic https://pmc.ncbi.nlm.nih.gov/articles/PMC10792139/#:~:text=T...
Doesn't look bad but it's not semantic and using utility classes like tailwind
Cool stuff, I think I'll never be able to unsee the extra top padding all over the web now haha
I don't even know if the golden ratio itself is that magical, but I do see a lot of value in picking one ratio and sticking to it everywhere.
This scrolls alright in Chrome but lags horribly when scrolling on Firefox. Especially when the larger animations come into view.
Things I look for in a UI library:
1. Clean, expressive interface, 2. Extensive documentation.
That being said, good on you for shipping! I would like to try it just for the mystery factor.
Thanks! It'll get there eventually, for sure. Feedback like the stuff in this thread helps a lot.
Pepsi would love it. https://www.goldennumber.net/wp-content/uploads/pepsi-arnell...
Just in time for Steel Ball Run
While the golden ratio thing is a bit of a gimmick, the components look gorgeous and really well laid out
Thanks! Yep, super gimmick. I picked golden ratio because I thought it was a good eyecatcher.
To be clear; You don't HAVE to use the golden ratio. You can set your global scale factor to anything you want in /liftkit-core.css. I just use 1.618 because I like it.
Wow AGPL for CSS ui framework!!
Interesting idea, but I haven't found a compelling reason that phi is inherently superior, aesthetically speaking. Seems more like a marketing spiel.
That said, it still looks good.
You don't actually HAVE to use phi. That's just the default global scale factor. You're correct that it's kinda marketing spiel. I figured I needed an angle to stand out in the crowded design system world and now I'm paying the consequences in this absolute roastfest, lol.
The only real reason I use phi is because it's very useful in asymmetrical typography scaling. At small type levels, differences in font size are more visually apparent than at large sizes. In other words, 14px vs 16px looks more noticeable to me than 38px vs 40px. So, my goal was to find a rem coefficient that would provide large jumps at large sizes, but I could also use the square root of it to derive smaller increments. I tried phi on a whim one day and realized I liked it.
I also went to apple's HIG and looked at the type specs for MacOS and put them into a spreadsheet. I found that the proportions of line height to font size hovered around 1.272 (which is the sq root of 1.618, or phi). Then I found similar patterns in the ratios of difference font sizes to each other (I think. It was back in 2022).
I also did a bunch of personal tests where I'd try to eyeball line heights and padding and stuff without snapping or looking at the metrics, and my preferences kept landing around golden ratio proportions. Biased? 100%. But I haven't got access to focus groups, and every time I asked my boyfriend to try it for me he'd be all like "please get a job you promised you'd work on your resume today"
So then I looked into other research. I can't find the study because I unpublished the article where I linked it, like a dumbass, but studies have shown that laypeople can tell the difference between abstract art based on rules like fractal symmetry and the golden ratio versus art made by children or animals at a rate of about 60% accuracy. Im on my phone right now but if you're curious I'll gladly look it up for you. I took that to mean "well, if we're entering an age of AI generated interfaces, then eventually we'll need to distill the essence of what looks good into certain mathematical principles so that there's a quantifiable "baseline" for quality that models can rely on. Golden ratio!" (Note: I do not know how AI actually works)
Finally, I got obsessed with that damn material button. There were ads on BART for some Google thing showing a button and it just looked off center to me. It haunted me for weeks. I couldn't stop looking at it. So I thought I'd try finding a reliable way to achieve the correct optical offset, but programmatically, so a designer wouldn't just have to do eyeball every button every time.
So, it's not totally baseless. But it's not a magic number either.
I don't think their homepage looks good, and for so much attention to detail the padding around text titles and other spacing, specially on mobile, doesn't look good. Not of the elements they showcase but of their own landing page.
I can't tell which one is supposed to be good, and the design is not intuitive enough for me to know which is the LiftKit (the one I'm supposed to prefer).
I'll stick to LLM design, thank you very much
The creator of this is a friend of mine and just gonna chime in that he’s a fantastic and talented dude. Nice surprise to see his project listed here! I think he’s working on something new called Liftkit Studio too I’m looking forward to.
He has a cool YouTube channel too. Check out “The Secret Science of Perfect Spacing”
https://youtu.be/9ElrcTtAxzA?si=kbAzQDGQSCCqymTO
Party on
hi fren
>In LiftKit, everything derives from the golden ratio,
I don't think the authors realise the extent to which their product, which looks well made and useful, is being completely undermined with this nonsensical pseudoscience.
Hi, I'm the author, it me. You're right, I need to be clearer that golden ratio doesn't automatically equal beautiful. It's not sacred geometry. It's just pretty. I like it. And studies show people at large tend to find the proportions pleasing.
It's just a rule of thumb, that's all. I just went crazy on the copywriting because I thought I'd need to in order to get the kit to stand out.
I have now been extremely informed that this is not the case.
> And studies show people at large tend to find the proportions pleasing.
I don't think that's the case - or at least, not well-designed studies. There's nothing to suggest that people prefer 1.618 more than 1.61 or even 1.6, and probably not 1.5. It's like if we found people like the colour blue and then claimed that people like the shade of Mary's veil or something.
Requires nextjs, :(
The CSS is vanilla at least. Look up liftkit-core.css in the repo and you can adapt it easily to any other project that supports CSS.
It doesn’t
Next.js without Tailwind
I really wish they would start with "this is for next.js/react".
I had to dig through the docs and get to the installation instructions just to find out that it's React only.
It looks great, but I'm always confused why design system folks wouldn't base everything off web components, which work with almost any framework.
I didn't know what web components were until after I'd released it for React. I was working in a complete vacuum until I put this out there, and then I started to get involved with the community. Before that I was pretty much the only designer/techie I knew. I'm not a professional developer. I'm just a designer who knows enough TS to piece things together.
So having it for React/NextJS isn't an affirmative decision. It's just the only thing I knew how to do at the time. After the first launch last summer I had a couple folks reach out to help port to SvelteKit and Vue, but you know how it is. People get busy.