Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...

gdgr

Members
  • Posts

    11
  • Joined

  • Last visited

Everything posted by gdgr

  1. Hey Blake, would love to know once this becomes available. I'll keep checking back here for updates, thanks for doing it as well. I <3 TypeScript!
  2. Just FYI, I've changed the name of the project on GitHub (also in scripts etc, inc. bower) and I've edited the original post here to reflect that. I don't seem to be able to edit the title/tags here, but if an admin could then please change "GSUI" to "QUI". Thanks!
  3. Hey Jack & Carl, I appreciate the kind words! I'm hardly surprised you had a similar idea in the pipeline. I totally agree about the raw power and flexibility, and I think you've hit the nail on the head with regards to use cases. The idea really is just to have the best of both those worlds, still with added flexibility for the presets and with minimal overhead to the project. I must admit, it does ever so slightly dismay me from developing this project knowing it's something you guys intend to do. Largely because you're wizards with more experience than I, and you've built the bloomin' thing in the first place which will without doubt result in a better product. That said, it sounds like it could be some time until that comes to fruition. I suppose with that in mind, I'd be rather keen to either A. develop/modify this in a way that you'd see fit if/when you were going to pursue this (so as to potentially help lay the foundation for your work), or B. contribute somewhat to your project when you're working on it. If you think there's any way we could work something around that I'd be delighted, though I understand if not. So I suppose in terms of if there's anything I need, it would depend on that. If I were able to help catalyse the process, some advice on how you'd expect to go about it would be great--I'm sure I'd learn a thing or two in the process and I'm all about continuous improvement. My only concern is devoting much more time to this and it falling by the wayside once it's usurped by your own produce. As for the name, I had wondered about that and I was going to suggest I'm more than happy to change it--so I'll gladly change it to something else. Re: the part you quoted, I didn't mean I found any bugs with GSAP, I meant with my script it was more that in certain use cases things didn't quite work as expected so either a new feature was required or something needed improving to ensure it was robust. Thanks very much Carl! That's very nice of you. CodePens are certainly something I have in mind and am keen to do. Would like to hear both your thoughts on the aforementioned. And just to note, the last thing I want to do is be a burden to you guys or make your lives more difficult--so if what I'm suggesting is just impractical or you believe I'm wasting my time doing this please just feel free to tell me how it is. I am rather busy generally and time is precious but I've enjoyed both building this and using it. I'd say total dev time for the whole enchilada is about 24 hours, so not a great deal really, considering I was a complete novice with GSAP for most of that! Enjoying my trip a great deal thank you All the best, Alex
  4. Added some docs on the GitHub page now. I haven't used GSAP yet in live commercial projects, but as soon as we do I'll be getting a Club GreenSock membership which is exciting!
  5. A warm hello to all of the community! (Apologies if the preamble's a little boring, you can always just skip to the heading below where I'll start cutting the mustard.) I'm Alex, and I started using GSAP a few months ago, after immediately falling in love with its robustness and sheer performance. It was at that very time I started my new job, and it was time to start using GSAP in all of my front-end projects I decided. So, I posted about one or two things here on the forums, and was further overwhelmed by the quality of support provided from GSAP's developers, and other members of the community. The weekend before I started that job, I spent the whole time beginning to write a little library that'd allow me to easily make calls to GSAP with some pre-determined transitions I find myself using a lot in my projects. It was largely an exercise in using GSAP and I thought it could be helpful to me in future. As I went along, using it in development, I encountered bugs and realised that I needed to add many features and improve a lot of aspects of it for it to "just work". So, I kind of flew by the seat of my pants with it and bolted in new things or fixes and continued to use it in development. Since then I've been using it in 'live' releases (i.e. other people have been using the projects but thus far they're internal), and I haven't encountered any major issues. Though there is a lot of work and improvement I know I would do if I had the time. Anyway, it has ultimately saved me loads of time and been a pleasure to use, since I can quickly adapt the transitions I'm using, I don't need to repeat large chunks of code spuriously through my different projects, and it's designed to be very easily intelligible to people who haven't even used it before (or GSAP.) To quote Jack, "But in fairness to Julian, he really wasn't trying to build a tool that's as robust as GSAP - Velocity is more for simple UI animations in the DOM.", the thing I like to be able to do is harness GSAP's power and flexibility where necessary, but also make simple UI animations in my projects. Since GSAP is clearly the most performant/cross-browser animation suite available for the web, those benefits are important even in the websites I make, where I can often be using things like Skrollr.js too, and require backwards compatibility to the older, often nasty versions of IE. So that's the purpose of QUI really, and I hope other people find it useful Without further ado I've made it available as a project on GitHub, it can also be installed via Bower and it uses GSAP as a dependency, so if you have those tools installed and are a little familiar with the command line it can be added to your project in no time. I'd love it if people made pull requests and possibly even helped motivate me to think more about this project. I would say at the moment it's still very usable for most purposes, but I know that some of the transitions haven't been updated since I better learned how to implement them. I haven't yet written documents for the project, though I am planning to this afternoon. I'm going away tomorrow and I need to pack etcetera but I think I'll have time anyway. That'll probably make a big difference, so I'll post about that when I have done. Seriously, there are tonnes of things I know I could do to improve this, but I figured if other people had a tinker it'd happen a lot faster. The main thing for now I suppose is it works and seems to add very little overhead to my projects, both in terms of loading times and execution. GitHub page: https://github.com/Quasso/qui GitHub site (it's a small demo): http://quasso.github.io/qui/ Install via bower: bower install qui (--save-dev) Really looking forward to hearing any feedback anyone may have. Docs soon!
  6. This was a remarkable answer Jack. You are brilliant. My apologies for the delayed reply, you answered this the day before I started my new job and my workload has been immense.
  7. Hi everybody, I've been successfully using GSAP for a while now and I am absolutely in love with it-as a side note I've developed a front-end UI animation pack for it which I will share with the community soon-but I'm struggling to get scrollToPlugin working. I am using the correct syntax, and I'm currently using requireJS to bring through the scripts as dependencies, with scrollToPlugin being loaded from cdnjs *after* TweenMax. Whatever I do, I keep getting the error: Uncaught TypeError: Failed to execute 'scrollTo' on 'Window': 2 arguments required, but only 1 present. I really have no idea what could be causing it anymore. My scroll syntax is: TweenMax.to(window, 1, {scrollTo : { y: 500, x=0 }, ease: Power1.easeOut }); This is executed when a button is clicked. Wonderful community, please help me!
  8. This makes sense. It didn't occur to me that was how you'd enable the queue system. Thank you!
  9. Hi, here you go: http://codepen.io/AtomLab/pen/XJmXpX
  10. Okay, I realised there was the option for that, and considered it, but I thought it rather pointless--I guess in hindsight it would allow someone to fork the pen and add the solution. I'll make one in a moment and post it
  11. Hi everyone, Only started using GSAP yesterday, until that point I was using Velocity.js on the basis of the rather disingenuous test that was originally listed on Julian's site (intentionally or not!) So anyway I discovered that GSAP dunks all over it and I wanted in! So, at the moment I'm making a UI pack for GSAP, since that was one of my most used features of Velocity, and it's great for front-end delights. It's going really well and I've taken to GSAP fairly quickly--but some things still elude me. One thing I'm trying to achieve is to do with one of the animations I've made, it's a 'shake', these are my first with multiple tween points, and I'm trying to figure out the way I'd go about successfully staggering a whole sequence on an array of elements. E.g. case 'stagger.shake': animate.to( element, 0.1, {left: "-=" + (nudge/2) + "px", ease:easing} ).to( element, 0.1, {left: "+=" + nudge + "px", ease:easing} ).to( element, 0.1, {left: "-=" + nudge + "px", ease:easing} ).to( element, 0.1, {left: "+=" + nudge + "px", ease:easing} ).to( element, 0.1, {left: "-=" + nudge + "px", ease:easing} ).to( element, 0.1, {left: "+=" + nudge + "px", ease:easing} ).to( element, 0.1, {left: "0px", ease:easing} ); break; My initial approach was something like this: case 'stagger.shake': animate.staggerTo( element, 0.1, {left: "-=" + (nudge/2) + "px", ease:easing}, stagger ).staggerTo( element, 0.1, {left: "+=" + nudge + "px", ease:easing}, stagger ).staggerTo( element, 0.1, {left: "-=" + nudge + "px", ease:easing}, stagger ).staggerTo( element, 0.1, {left: "+=" + nudge + "px", ease:easing}, stagger ).staggerTo( element, 0.1, {left: "-=" + nudge + "px", ease:easing}, stagger ).staggerTo( element, 0.1, {left: "+=" + nudge + "px", ease:easing}, stagger ).staggerTo( element, 0.1, {left: "0px", ease:easing}, stagger ); break; I'm sure one of you guys knows exactly what I'm missing! Seems like a great community here and looking forward to becoming a part of it. GSAP is awesome. And not in the desensitised meaning of the word, like genuinely awesome!
×