Open PatriciaMoller opened 7 years ago
The animation used if provided by the Google Maps API itself. It is rather limited one. There is also a bouncing option, but changing the animation requires some effort and has certain "quirks" to it.
We could temporarily swap the icons with some animated version of another picture (that is hypothetical claim and needs some testing for a real proof).
I am a bit confused about the images though. We had to opt for SVG ones, but now we suddenly get the animated GIF images instead.
As for animated SVG images, it should be tested first as there could be some limitations that the API could impose.
Posted a bit too quickly sorry about that.
To clarify: The GIFs are just illustrated examples of suggested movement. They are not assets to be used. The animation of the icons would be moving the SVG-icon. Any special effects (such as starts popping up) would be an animated GIF placed behind the SVG, as I imagine it would be faster to implement that rather than scripting that movement.
I found this article/tutorial, they seem to be using CSS to handle the movement of the icon. Does that seem like a reasonable way to do it? https://www.sitepoint.com/animated-google-map-markers-css-javascript/
I see no issue with that kind of approach. I suppose we could also apply animations to our markers as it is needed.
Managed to give that a try. It is doable and should not be a big deal for the simple bounce and shake animations. We could even be able to apply the ones offered by Animate.css.
In case of the sparkling one. That should probably be achieved by temporarily switching to a special icon, applying animation and then switching to the red icon in the end.
One of the issues I've seen is that the leftovers of the styles for the initial animation are going to get in the way. These should either be removed or the initial dropdown should never occur.
We might also need to apply animations with the use of jQuery.animate functionality instead, this should give a lot more control over what is happening during the animation and when animation is finished. Approach using JS code should allow having a lot more control over course of animation and applying any additional actions.
If it's possible to make use of those animations or similar, that would be amazing. They would bring so much more life and energy to the experience.
I don't quite get what you mean by "special icon". Would the animated and static icon be treated as separate objects?
I'm not experienced with scripting/implementation. If JS grants more freedom and control, then I vote for that. If doesn't end up complicating things, it might be better in case we want specific movements.
Special icon would be the one with sparkles. Changing icons means having different images and forcing marker objects to use those.
The JS is there anyway and in large quantities. Using existing library just saves the effort of coming up with CSS logic for animations. Not super complicated, but our case is not as simple as the example given. Animations have to be applied to certain objects at certain point in time ... and so on.
Just trying to understand the flow: By default, it's the static SVG. For simple movement, like a little shake, it could be done with script (CSS or JavaScript, whichever is the most appropriate) For more complex animations, such as the sparkling, a separate animated icon (a gif?) plays before switching to the correct static SVG again. ?
All of those are images at all times, those could even use animated images (needs a small configuration setting being enforced). The effects are mostly applied with styles. Either that happens by applying the CSS animations with a little help from JS or constant JS changes to keep the style values being changed (hard to explain the difference).
In case of sparkling we could just use heavy JS to control the animation and apply the effects as needed. In this case swap for the version of image with sparks. Or we could just switch the image to the animated one, then we would switch back.
The final destination is the same, but several roads could lead there.
I made a more proper gif, using Flash, of the Bounce animation. Here Can we use that to test if gifs are suitable for animated icon? Or at least see how having animated icons affect the interaction and what playback speeds are appropriate.
Yes, we can surely test that. I will get that live next week. GIF images should work just fine.
On 21 Sep 2017, at 12:33, PatriciaMoller notifications@github.com wrote:
I made a more proper gif, using Flash, of the Bounce animation. Here Can we use that to test if gifs are suitable for animated icon? Or at least see how having animated icons affect the interaction and what playback speeds are appropriate.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
I will try to do that. Although the jumping one should probably be orange with question mark. The green star icon means correctly answered question. I will report the finding right here and will upload to the server if it seems to be working.
This is how it looks like right now: marker_bounce.zip
Had to mess with the size a bit so that it would match the other icons. We could change the icons to anything we need for a certain duration of time. Then we could make the code make the switch to something else.
This is how the original bounce animation (packed with the Google Maps API itself): native_bounce.zip
I did not yet get to the point where we could apply some custom CSS animations to visual markers. Will need to dive deeper for that.
But we could easily use the animated gifs, if we need that.
In what way/how much did you change the size? It'd be be good to know for future reference.
Hmm, the GIF looks rather choppy and the transparency doesn't work. I cut down some of frames because I was worried about it getting too heavy. Maybe won't be an issue, if the files will be so small, both in pixels and filesize, anyway. But it's good to know that it's an option.
https://gist.github.com/jeremypetrequin/6414054 Stumbled upon this. If I understand it correctly, it makes to possible to play a spritesheet as a JS clip. In that case, granted that the spritesheet doesn't end up being too big (which as earlier said probably won't be that big of an issue) we could have more control over playback speed and quality. GIFs don't handle transparency gradients very well. It may not matter much in this specific case. But it could be a future issue if other UI elements are to animated, which I have some ideas for. If played at a high speed, the JSON+spritesheet plays very smoothly.
For comparison, an "uncut" 21 frame GIF is ~160kB. The spritesheet of the same animation is ~500kB, but will overall have better quality.
What do you think? I think this could be better for all the cases where the animations are more than a static icon moving.
If you want to try with the uncut gif it's here
Our current icons are shown as 40x40 pixels. That one could not have been square, thus I have set that to be shown as something around the same width and a bit more height (the image was not square). It would be great if original images dimensions could be divided by some number (like 10). Makes it easier to fit with the existing ones.
Well, file sizes are not a big deal, as long as we do not include anything too big. We are already loading a lot of images (SVG ones are really small). We are also loading a map, that requires tiles (images in essence). This means that we will be moving quite a few Megabytes of data for the duration of a game. Freaking about about a few Kilobytes is not really meaningful.
I probably understand what it does. Well, it has one image with smaller portions that could be used by providing the correct positioning and size by either CSS or style attribute.
I would need to test out the approach. It would make the code a bit more complicated. We currently do not need to have that kind of control over it. I could get back to you once I have tested that (I already have a list of things to get done, so it will take me some time). If someone else implemented that, then it could go faster.
Have you had time to look at the JSON/Spritesheet method?
Otherwise, the CSS might be enough for this specifically.
I would probably prefer the CSS animations, if possible. Those should be sufficient for the simple cases and would not bring excessive assets to be downloaded.
I understand that. I think appropriate animations for Incorrect and Correct would be Shake and Bounce
Would Animate.css be usable for other elements as well? (For example Menu boxes, image in/out transitions) If so, wouldn't it be rather painless to add them to e.g the correct/incorrect images (#140 , I've gotten positive reactions about them, so if it's doable it'd be nice if the could be implemented)? Or to mix up the current movements?
Animate.css could be used for almost anything. it is just a bunch of CSS helpers (so to say), that offers a preset of useful animation out of the box. I've been using that rather extensively.
As for the #140, if we go with that approach. Then applying animations to markers might be pointless. Both approaches would not work well together. The user will get the feedback with either one or the other (plus the icon colour changing).
One more thing about those, although this belongs to comments section of a different issue. These should work well with any screen size (would be great if also in both portrait and landscape mode).
The issue I have bumped into was that the Google Maps API Marker object does not seems to have explicit connection to its DOM Node representation. So it would require some trickery to access and animate just that Marker element (although I have already identified one possible quick solution, but that one more of a hack).
My idea is that the images would be the end of the "question phase". The animated icons would redirect the attention back to the map.
This is better and has connection between the icon and the screen with good/bad result.
Should that also be applicable to the types that can not be answered incorrectly (and out of 7 we have 5 that are always correct)?
I'll be duplicating this to #140 as it may be more relevant to discuss there.
One correct, Multiple Correct and Match pairs should, as they do have correct answers. Information doesn't need it, since it's just a box of text to be read. Photo and Embedded feel trickier as they don't necessarily have to be questions. Freeform as well, as there is no way to know if they're actually correct when. Maybe having a "Submitted!" image for those three?
I noticed the icons have a slight "drop" animation when they first appear on the map.
Is it possible to: If you open a question within reach, to make that icon to bounce (see gif 1) If you answer correctly, make it bounce and sparkle? This (see gif 2) If you tap a question out of reach or answer incorrectly, have it shake? (See gif 3, if an question was answered incorrectly, it would be the red icon?)
(Gif are illustrated examples, not assets)
My current idea for Gif2 is to have a gif animation play behind the icon at the same location, however. I imagine those could end up being rather heavy, tough if they are made as low-res as possible and frame efficient, they may not end too taxing. I will look into vector/svg animation, since it most likely will be needed for other animations at a later point (gif of added elements in gif2 are available here: https://drive.google.com/open?id=0BwI6ykFZVgBJc2JtTXRUaUUwQms)