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.)
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.
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 :(
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 had the same thought: everything looks 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.
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.
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 wouldn't trust a UI framework where all of the components are shown as images instead of instances of the actual UI framework...
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
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.
Yeah it's a huge problem. Not accessible either. Idk what I was thinking.
The next release will use radix primitives.
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.
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.
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.
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.
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
There is a great research paper on the topic https://pmc.ncbi.nlm.nih.gov/articles/PMC10792139/#:~:text=T...
Pepsi would love it. https://www.goldennumber.net/wp-content/uploads/pepsi-arnell...
>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.
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.
Wow AGPL for CSS ui framework!!
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
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.
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.
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
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 :)
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'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.