Extracting one part of a conversation I had on Reddit with someone who's worked with GreenSock --
"GSAP is fairly standard on commercial sites. It’s the most mature and cross tested animation option, but it’s best features aren’t free. I’d argue there’s a good reason for that though, because the codebase is pretty impressive and can’t be cheap to maintain.
Most people say the biggest advantage of GSAP is the timeline. When paired with SVGs (and using GSAP’s morph plugin) there’s some pretty crazy and unexplored UI orientated options that become very possible. I rarely have a client with a budget to go there, but why use another tool that can’t do such amazing SVG manipulations in real time and synced to other movement on the screen?
I cannot overstate how powerful that is.
But the bottom line is that not enough “ux” folk are good enough with JavaScript to really be creative with GSAP. So it’s mostly front Enders that use it or propose it in meetings.
Also I’m not 100% sure... but I think I recall reading somewhere that a lot of the software solutions trying to make web animation “easy” for designers, use GSAP under the hood. So I look as GSAP a lot like D3. Since they’re advanced/enterprise solutions, and not easy to use (but not hard at all for proper programmers), there’s a lot of attempts to make it easier with libraries built on top of their bases through licensing."
Yeah. I was a Flash programmer back in the mid 2000s, and GSAP is what let us move away from Flash and onto JavaScript with a similar set of abstractions. The best animation system I’ve used for the web; and amazingly performant.
Eventhough the transition effect is interesting on first sight, using it more than the initial few seconds made me feel uncomfortable. Can't really pin point it, but I think it's mainly to do with the title always shifting and me having to refocus and trying to read it.
Too much stuff is moving at once - you have the videos in the background and in the forground other stuff is moving too - I think that's what's causing the discomfort for me and having to work too hard to explore the content. Making it all a bit more subtle might have helped.
And 'polluting' the history with each slide state doesn't help either.
Animations like this need to be tested with users too.
I'd have to disagree with all of those points. The background transitions first, then the foreground content transitions afterwards; they're not all moving at once. The foreground content then remains stable once the transition finishes. Perhaps some opacity could be applied to the foreground content to discourage users from trying to read while it transitions.
And it makes sense to have the history change with each slide state. Describing it as a 'state' upholds that point. The back button even works with it, which is my main gripe when single-page apps don't 'pollute' the browser's history.
Check again - for me some of the videos play at the same time while the page is still transitioning... that's what I meant.
To me that component on the homepage is more like a 'carousel', so when I hit back I expected to be back on HN, but instead I stepped through each slide again with all the transitioning.
But it doesn't matter what my or your opinion is... we both have different expectations and all I'm saying is ideally this stuff should have been tested with more users.
Yes, all of the videos should be auto-playing. I'm saying that the discomfort would likely be alleviated if the text's opacity transitioned in. Then you should be able to handle the awesome rippling effects.
And my guess is that your expectation for the back button to send you back to HN is because of how the majority of SPA's break the back button. It's a disheartening reality.
I understand the importance of testing with actual users, but it's honestly pretty amazing that these are the only broken expectations for a portfolio site like this.
most people. having to press back several times to go back to the previous site is a frustrating user experience. ideally this would use replaceState instead of pushState
Which doesn't take away from how
impressive and smooth the effect is, kudos to the author
I was expecting I could press “back” and return to this thread. I think I honestly would have perferred the designers doing the “scroll hijack” in this case.
I posted the other day about my desire to see more programmers strive towards demo scene type work in their creative endeavours. Seeing this makes me think about my own completely inadequate portfolio. Writing blog posts, pointing to half finished proof of concept repositories, etc, seems great, but... What if I concentrated on writing things that normal people could see and be interested in without falling asleep?
Yes it has. You could even create your own shaders/filters with a specialized language. Frankly it's great that things like that can be done with js/html but people did way more impressive things 15 years ago.
True, I remember seeing a site circa 2005 that had a completely crazy flash intro with 3d/360 camera pan thing - running on a regular 2005/6 computer.
I think things are more polished now, because of bandwidth we can afford large images, videos, etc but back in the day there was some truly impressive Flash stuff.
The later versions of Flash supported a Stage3D object, which was basically a Flash version of what you’d expect today from WebGL. It was hardware accelerated (with a software rendering fallback, if I remember correctly) and supported anti aliasing and shaders and all the things you’d expect. Performance was pretty wonderful. If you wrote things using this, you wouldn’t notice much of a performance difference for Flash.
> I’m talking about hardware acceleration, antialias, no dropped frame and in sync with the monitor’s refresh rate.
All supported by flash, I just told you about the possibility of coding your own shaders with a C like language where do you think these shaders were computed?
> Well, show me a link then. We can still run it (not for long).
You know damn well that most flash content has been retired from the web.
I work for a company that does both SVG+JS and Flash media, and there are some legit cases where we still choose to use Flash, because SVG can't reach the same performance — anything with lots of animated gradients, deep scene hierarchies, transparencies, masking, filter effects, or high vertex counts. SVG rendering in all browsers not named "Chrome" is crazy slow, and in Chrome SVG rendering is not pretty when you look closely at it.
But SVG is the only browser graphics tech with excellent tooling for illustrators (namely, Illustrator). So we've been forced to change both our art style, and our rendering stack, to deal with the death of Flash.
That's life in the tech industry, fine. But it's misguided to say that the browser is unequivocally better or worse performing than Flash. It really depends what you're making, and how you make it.
It's totally possible to make something on the web that looks and performs better than it would in Flash. But you have to put strict restrictions on what kind of art you use, and what technology you use to render that art, which puts restrictions on your production process, which sucks.
Which is why there are so many braggy blog posts by engineering teams when they manage to build 60fps animations on modern browsers. I remember one article from Flipboard about getting native-like flip animations to work on their mobile site. They made it sound like they'd cracked cold fusion.
Despite all of the improvements in browser support for JS/CSS driven animation since the glory days of Flash 10 years ago, the web seems more static and text/image heavy than ever.
Everyone had a bad habit of leaving the FPS at 25 (iirc that was the default. Maybe 24). I wonder how smooth it can be if that was fixed and the same engineering went into it that goes into GSAP?
Actually I don’t really wonder; Flash is well dead, but it’s interesting to ponder!
The default was 12, then later 24 IIRC. I believe the highest you could set was 30, though maybe that's changed in recent years.
I work for a company that does both SVG+JS and Flash media, still. The web-tech media is smoother (because 60fps), but the Flash media has a much higher complexity ceiling — which is why we haven't 100% switched to the web yet (and because our clients still prefer and pay for the Flash stuff, sigh)
It is a totally new web experience and I think it's amazing (it is innovative for me). Probably it can be a little confusing on mobile devices but on desktop the effect is fantastic and really creative. You can work on it.. for the rest, compliments for the great good job.
This makes me miss Flash in a weird way. This is like what early Flash looked like. Flash performed better, usually looked more polished than this, and was WAY easier to author in than WebGL probably will ever be.
How long does this take for others to load? On my fairly high-spec computer it was nearly 30 seconds on the first load, with not much indication that something was loading besides the slim loading bar. Visually it looks pretty slick but I wonder if it's worth the tradeoff? Subsequent loads seem much faster, though.
Nice but a lot of form over function style design does not make the web a better place necessarily.
Nevertheless, WebGL is still a bit underused and this is a nice showcase. I imagine that together with WASM it will enable a lot of slick experiences when people start doing the things that currently require native applications.
E.g. most games have very slick and responsive UIs. There's no good reason why the web has to be the stuttering laggy mess that that causes your fans to spin up as soon as you scroll.
True,but I work in a UX role and for a moderate-to-large website, "good UX" means a basic responsive design with a logical information architecture and navigation that optimizes conversion (e.g. product purchases). Good UX is business-driven and businesses are often boring.
I'm not a huge fan of this particular design but I do appreciate the effort they put into showcasing GSAP's capabilities. The web could use more interactivity and motion. The death of Flash and rise of mobile-first design seems to have led to websites where the only thing moving is the text/image content that's displaced once the ads on the page finish loading.
The point about animation tools like these is not that the specific effects matter but rather that the ability to animate even very complex things will allow you to greatly increase the usability things that used to be more or less impossible to do because it would require too much of a user.
Don't forget that the number one driver of something being intuitive is the removal of abstraction between the user and the result of their interaction. This is why the touch screen was the real paradigmshift when it came to improved usability because it removed the layer of abstraction between the user and what they wanted to manipulate.
Animation fills in this role too in that it allows for transitions to happen that makes you understand what it want you to do simply by ex. keeping on element on the screen but animating everything else out or by changing shape from one state to another. The fact that you experience this transition is what's really powerful and will be part of whatever next generation of UI paradigms we will see (ex. turning data into interactive elements as an example)
I think that for me, one of the most interesting distinctions with such a visual, design-forward experience is the line between what's possible with WebGL animation and what's really just high-production quality video playing in the background. Where most of us developers get stuck approaching this is that we don't have the video assets and design language established, so we see it as just a bunch of tools that you could theoretically put together to do... something arbitrary, and in the future.
Whereas, if a design lead came to you with a strong design/brand and video content, it's really nice to know that the tools exist to make such a thing possible.
You don't have to go crazy on the transitions and scroll jacking, either. Subtle use of these tools can produce humbling results.
So many of these scroll animation fuckery sites are made so that they only work with a trackpad, and even then probably only a mac trackpad (where flicking etc. work well).
Using a site like this with a mousewheel is near impossible.
I am not aware of having any form of vestibular disorder, and it has generally taken fairly deliberate effort to cause any discomfort when looking at a screen—A Slower Speed of Light was able to make me feel mild discomfort after ten minutes, which I understand to be not uncommon, but it’s almost alone in that.
But this site is awful. I was feeling fine before, but within half a minute I was feeling mild pain in the back of my eyes and the beginnings of stomach churning. The animation was choppy and severely disorienting. Scrolling switching pages is not normal and is always, uniformly a bad idea. So after only half a minute I closed it. (That is, half a minute after the it finished loading—before that, there was a loading screen for perhaps fifteen or twenty seconds, which is never a good sign. In the normal way of things, I’d probably have closed it before it ever finished loading, but I had been expecting some sort of article on combining WebGL and GSAP, rather than a demonstration that would make me feel sick.)
My stomach is not feeling any better a few minutes later. I shall now go and have a drink and a walk around.
Just because you can do something, does not mean you should. As implemented, this is terrible.
I will not be unique in this. Many people will be negatively affected by it, some far, far worse than me. (For some history on far more subtle things than this causing problems for some people, look into what happened in iOS 7 (I think it was that version) in what led to the “prefers reduced motion” setting.)
Quite apart from the how it will made some people feel sick, there is simply too much that is different about the site, so that a great many people, when they encounter it, will get lost very quickly. It’s not as bad as mystery meat navigation, but its navigation scheme is very dubious, because it lacks the “tells” of normal web browsing.
It’s an interesting technical demonstration, but not a good website for normal people to use. For a film-maker it may or may not backfire, but I’ve seen a couple of sites of developers, designers and such agencies, that looked and behaved vaguely like this from a navigation perspective, and the main thing that I take out of such sites is that the the creator of the site didn’t care about accessibility. And I don’t mean making the site usable for disabled people, I mean making the site usable for anyone. I would never hire any such person or organisation for any web development work.
(I failed to notice this the first time, but this site is also enormous. I killed it off as it hit 75MB, and I think it was still loading more video. I will freely and precisely describe such a page size as absurd and insane. I would not have loaded the site even once had I realised what and how large it would be.)
The main scrolling didn’t bother me, but scrolling inside the “hamburger menu” made me feel sick almost immediately. I think it was a combination of the scrolling and the motion of the video I was mousing over. Be careful with this stuff folks!
In addition to the animation, I liked the "immersive" feel of the main pages. This effect seems to be created by allowing the navigation elements to "frame" the entire screen and then placing a single piece of content as the focal point in the center of the screen.
Certainly some interesting UI / UX takeaways here.
"GSAP is fairly standard on commercial sites. It’s the most mature and cross tested animation option, but it’s best features aren’t free. I’d argue there’s a good reason for that though, because the codebase is pretty impressive and can’t be cheap to maintain.
Most people say the biggest advantage of GSAP is the timeline. When paired with SVGs (and using GSAP’s morph plugin) there’s some pretty crazy and unexplored UI orientated options that become very possible. I rarely have a client with a budget to go there, but why use another tool that can’t do such amazing SVG manipulations in real time and synced to other movement on the screen?
I cannot overstate how powerful that is.
But the bottom line is that not enough “ux” folk are good enough with JavaScript to really be creative with GSAP. So it’s mostly front Enders that use it or propose it in meetings.
Also I’m not 100% sure... but I think I recall reading somewhere that a lot of the software solutions trying to make web animation “easy” for designers, use GSAP under the hood. So I look as GSAP a lot like D3. Since they’re advanced/enterprise solutions, and not easy to use (but not hard at all for proper programmers), there’s a lot of attempts to make it easier with libraries built on top of their bases through licensing."