Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updated GUI animations #39

Closed
8 tasks done
garyjacobs opened this issue May 17, 2018 · 18 comments
Closed
8 tasks done

Updated GUI animations #39

garyjacobs opened this issue May 17, 2018 · 18 comments

Comments

@garyjacobs
Copy link
Contributor

garyjacobs commented May 17, 2018

Here are some updated animations for the GUI version of "Drag and Drop"

There are 5 states outlined as follows:

01-Load-Up.gif
This should play once and then switch to "Waiting"

02-Waiting.gif
This will loop and wait until the user places file(s) onto the GUI window

03-Crunching.gif
This will loop while the magic is happening

04-Error.gif
This will play once when something went Wrong (error)

04-Success.gif
This will play once when the compression is complete and state in view for 1-2 secs then reset back to "Waiting GIF".

Dimensions of animations are 600x300 - these would look best filling the entire container it sits in.

Open to suggestions on wording and visuals displayed here.

01-load-up
02-waiting
03-crunching
04-error
04-success


@chrissimpkins edits below:

TODO:

@masey9
Copy link

masey9 commented May 17, 2018

Niiiiiiiiiice one Garrrrrry! Haha! Good work mate. 😃

@garyjacobs
Copy link
Contributor Author

Thanks for putting me onto this GEM that has become a part of our workflow in less that a day. 👍

@chrissimpkins
Copy link
Owner

chrissimpkins commented May 17, 2018

I love these Gary! They look fantastic! Really appreciate the effort here and will gladly update the animations in the GUI tool. Beyond looking pro (!), it will be great to implement success/failure status at the end of the program execution. Great work!

A few questions:

  1. Here is where we are with window size vs. animation image size:

b86m2-image

Thoughts about increasing the size of the window vs. reducing the size of the image to fit the dimensions of the current window?

  1. Let me know how you would like to license these images in the project. The source is licensed as follows: Crunch = MIT; pngquant = GPLv3; zopflipng=Apache. After you approached me about the animations I reviewed image licensing and the CC by 4.0 or CC by SA 4.0 are free cultural works licenses that would fit in this project if you prefer the CC licenses. Alternatively, we can keep them under the existing project MIT License which is here.

Once the above questions are settled, can I have you submit these images as a pull request to the img directory or a subdirectory of the img directory that is located in the root of the repository? I will begin to work on the transition to these animations through that pull request. Let's get you logged in the git commit history as the contributor of these images to the project. Fantastic work and thanks again!

TODO list added to OP.

@albinekb
Copy link

Awesome animations! I got an idea for potential improvement:

Add thumbs up 👍 on success and 👎 on fail? 😄

@badcat
Copy link

badcat commented May 17, 2018

Love these animations - now if only the app was called Punch! or Scrunch or something other than Crunch, since makes me think of this Crunch - https://getcrunch.co which is by its own admission is, "Faster, Tastier and Crunchier" :)

Hmm - maybe simply - "Crunchy"

@garyjacobs
Copy link
Contributor Author

garyjacobs commented May 18, 2018

Hey @chrissimpkins

I've updated the fists in the animation to be more like a mechanical vice for crunching machine.
In terms of license - Which ever option sees the user reading less licence agreements honestly. So I'm cool with the MIT one or which ever is easiest to implement. I'm not precious about it.

GUI Window Size

I think keep the size of the window you have and I'll update the artwork dimensions.
I've taken a screenshot of GUI and deduced from that screenshot that the inner window size is 400x200. You will need to cater for HDPI (Retina/5K) screen resolutions, so I've created a @1x (400x200) version and also a @2x version (800x400) which should render sharper for the HDPI screens.

If there is no option to specify two sets of images - just use the @2x ones to cover off the HDPI resolution and set the image size to be 400x200.

I think I added the image to a PR. I'm a GIT noob so let me know if something isn't quite right.

@chrissimpkins chrissimpkins added this to the v3.0.0 milestone May 18, 2018
@chrissimpkins
Copy link
Owner

chrissimpkins commented May 18, 2018

Updates look great!

Which ever option sees the user reading less licence agreements honestly. So I'm cool with the MIT one or which ever is easiest to implement.

Will not modify the existing licenses to address the new images based upon your response.

I think keep the size of the window you have and I'll update the artwork dimensions.
I've taken a screenshot of GUI and deduced from that screenshot that the inner window size is 400x200. You will need to cater for HDPI (Retina/5K) screen resolutions, so I've created a @1x (400x200) version and also a @2x version (800x400) which should render sharper for the HDPI screens.

Beginning work on this over the next week. I've tentatively slated the work here as part of a new major release (v3.0.0) which will include an updated version of zopflipng. I need to explore the zopflipng change a bit. The commit logs suggest there could be compression gains.

added the image to a PR

#43 👍

Images added in 1da80d2

@chrissimpkins
Copy link
Owner

images merged to dev branch. starting work on the animation updates

@chrissimpkins
Copy link
Owner

chrissimpkins commented May 23, 2018

Gary, animations are looking great! I started on the application open transition between images 01 and 02. Here is where we currently are:

n5911-video

I am having a difficult time with the timing of the transition in the dashed lines that circle around the middle circle between images 01 and 02. Note the slight jump in position of the lines in the two images. I've tried transitions at 0.5 - 1.1 sec. It looks best in the 0.5 - 0.9sec range. When I get to 1 sec and above there is a visually apparent transition between the entire image. I don't know why it occurs. In that range there is a "jump" in the entire image that is very apparent. Thoughts about simply removing the dashed lines in image 01 and either fading in or just letting them appear and begin animating in a circular fashion at image 02?

The other issue is that there seems to be a 5'ish (or maybe 10) px border around the image that is not specified in CSS. I have the background of the HTML set to the background color of the images. It is not a huge issue, but the animations are not flush with the sides of the GUI window border. I will try to draw a border in the window color around the image to see if it takes care of it. I think that there may be a shaded inset line around the frame so we may not be able to make it appear to be flush with the edge.

I'd be happy to build a copy of the application at this stage if you'd like to take a look.

@garyjacobs
Copy link
Contributor Author

garyjacobs commented May 24, 2018

Hmmm... Yeah the timings seem a bit off.
Do you have to put in the timings of when they GIF's swap out?

If yes, there are a couple of options here:

  1. I can extend the GIF duration to be a round 2 seconds and then when you swap from one gif to the next it should be seamless?

  2. I can find out the exact timing of first animation end and you set it to that?

Or yes- I can remove the dashed line in the first load up screen but the mechanical arms coming in are not as smooth as they should be - It seems like something in being cut short in the timings.

@chrissimpkins
Copy link
Owner

chrissimpkins commented May 24, 2018

Do you have to put in the timings of when they GIF's swap out?

Yes, it runs via a shell script and if I don't add pauses it simply swaps the images out immediately one right after the other.

I put all of the animations together from start to success and fail. It looks great. My suggestion is to simply combine images 01 and 02 into a single image if possible. The current animation stitching is as follows:

Application open : Image 01 --> Image 02 then wait

Execution to success: Image 03 ---> Image 04-Success ---> (2 sec pause) ---> Image 01 --> Image 02 then wait

Execution to fail: Image 03 ---> Image 04-Fail ---> (2 sec pause) ---> Image 01 --> Image 02 then wait

Everything looks great except the transition between 01 --> 02. If those are combined into one image I think the issue is solved. Give me a few mins and I will build and push a copy that you can try so that you can see what I mean.

@chrissimpkins
Copy link
Owner

Here is an installer so that you can have a look at the current timings across the images:

Crunch-installer.zip

@chrissimpkins
Copy link
Owner

That should show up as v3.0.0-dev1 in the About window

@garyjacobs
Copy link
Contributor Author

Yeah I can see the jump. Why not just remove Image 01 and just use Image 02 as loading/waiting.
P.S. - It's looking good!

@chrissimpkins
Copy link
Owner

chrissimpkins commented May 24, 2018

@garyjacobs OK sounds good. Will eliminate 01 altogether. I really like the initial loading animation but it is optional.

@chrissimpkins
Copy link
Owner

chrissimpkins commented May 25, 2018

The animations were updated with revised transition timings and I am pretty happy with how all of these new animations appear at this stage. I really like the opening animation and decided to keep it despite the minor shift in the dashed lines around the circle. I think that this is acceptable.

For those who want to check it out with the brand new animations that Gary contributed, here is a new installer that will show as v3.0.0-dev2.

installer.zip

Let me know if you have any feedback about the timing of the transitions and the current designs. My own opinion is that they look gtg for the next release. Open to suggestions for further improvements.

We are closing in on the v3.0.0 release and these new animations will be a big part of it. This looks great Gary. I really appreciate your efforts here. The About menu was updated with an acknowledgment + link to your Github account and I will add this to the README page as well.

@chrissimpkins
Copy link
Owner

chrissimpkins commented May 31, 2018

Logging of successes (with compression data) & failures (with reason) has been implemented in a build that includes the new animations for successful and failed Crunch macOS GUI execution. See #58 for installer download details if you are available to test. The log file path is $HOME/.crunch/crunch.log.

@chrissimpkins
Copy link
Owner

These new animations were released in v3.0.0 of the Crunch macOS GUI application. They turned out great @garyjacobs! Thanks again for all of your efforts to make these animations and contributing them here. Very much appreciated. Install the new version and enjoy!

https://github.com/chrissimpkins/Crunch/releases/latest

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants