Closed Bug 797702 Opened 8 years ago Closed 2 years ago

Add animations for when user swipes (in any view)

Categories

(Firefox OS Graveyard :: Gaia::Calendar, defect, P3)

defect

Tracking

(blocking-basecamp:-)

RESOLVED WONTFIX
blocking-basecamp -

People

(Reporter: jlal, Unassigned, NeedInfo)

References

Details

(Keywords: feature, polish, Whiteboard: [TEF_REQ], visual design, ux-tracking)

Attachments

(1 file)

No description provided.
When swiping between views we should animate the transition from one to another.

I think the best way to do this is to have a set of css classes we add to the previous frame and the current frame (we can do this in TimeParent). 

Something like

.transition-previous
.transition-current
.transition.-next

We will need to animate differently when swiping to the future or into the past.
IMO- it should like like the user has just "panned" between views but much faster and automated. Like flicking between pages of a real calendar.

I think we can do this purely with css animations on the above classes, then remove the classes when the animations are complete. 

The additional classes are need (I believe) so we don't animate the calendar when switching between views when the calendar loads or is coming from a different view (Week -> Day, etc..). To ensure we don't animate in odd places we may need to re-introduce the "internal" move flag in the TimeParent container.
blocking-basecamp: --- → ?
Assignee: nobody → mbudzynski
Chris - Please re-nom if this is really needed for v1
blocking-basecamp: ? → -
Attached file patch
Attachment #683993 - Flags: review?(jlal)
Whiteboard: [polish]
Keywords: polish
Priority: -- → P3
Whiteboard: [polish] → [interaction]
Duplicate of this bug: 820619
This is very important for usability. We need to teach users that they must to swipe to advance back and forth through the calendar time frames (month, day, etc). The current implementation lacks any animate or visible dragging response, meaning most users will not find the functionality, and it will look broken to those who do.

This is very basic, and is a UX must fix for release. If animation is not feasible, we should remove swiping entirely and create dedicated previous / next buttons.
Keywords: polish
Whiteboard: [interaction] → interaction design, visual design, UX-P2, BerlinWW
Blocks: 835286
[TEF_REQ] as Feature required for TEF build.
Whiteboard: interaction design, visual design, UX-P2, BerlinWW → interaction design, visual design, UX-P2, BerlinWW, [TEF_REQ]
No longer blocks: 835286
Duplicate of this bug: 835286
Whiteboard: interaction design, visual design, UX-P2, BerlinWW, [TEF_REQ] → interaction design, visual design, UX-P2, BerlinWW, [TEF_REQ], PRODUCT-ANNOYING
Blocks: 846560
Whiteboard: interaction design, visual design, UX-P2, BerlinWW, [TEF_REQ], PRODUCT-ANNOYING → u=user c=keyboard s=ux-most-wanted, visual design, [TEF_REQ]
Whiteboard: u=user c=keyboard s=ux-most-wanted, visual design, [TEF_REQ] → u=user c=calendar s=ux-most-wanted, visual design, [TEF_REQ]
Whiteboard: u=user c=calendar s=ux-most-wanted, visual design, [TEF_REQ] → u=user c=calendar s=ux-most-wanted [TEF_REQ], visual design
What's the latest on this one? Just trying to put together an accurate list of what UX will and will not be in 1.1. Thanks!
Whiteboard: u=user c=calendar s=ux-most-wanted [TEF_REQ], visual design → [TEF_REQ], visual design, ux-tracking
Whiteboard: [TEF_REQ], visual design, ux-tracking → [TEF_REQ], visual design, ux-tracking, ux-priority1.2
Whiteboard: [TEF_REQ], visual design, ux-tracking, ux-priority1.2 → [TEF_REQ], visual design, ux-tracking
Attachment #683993 - Flags: review?(jlal)
Assignee: mbudzynski → nobody
Blocks: 834310
Duplicate of this bug: 808628
Was this completed for 1.2 (or will it be)?
Keywords: feature
Whiteboard: [TEF_REQ], visual design, ux-tracking → [TEF_REQ], visual design, ux-most-wanted
Blocks: 994991
Is there any concern that this in-app swipe gesture will conflict with the ongoing Haida work?
Flags: needinfo?(pdolanjski)
(In reply to Adam Rogers (:arog) from comment #11)
> Is there any concern that this in-app swipe gesture will conflict with the
> ongoing Haida work?

No, the testing has shown that it shouldn't conflict.  
Sorry for the big delay here!
Flags: needinfo?(pdolanjski)
on v2.1 we added a 5-day week view, which introduces animation during the swipe. The plan is to also implement the same thing for day view soon. - so adding both as dependencies here to keep track of progress.
Depends on: 1052960, 1023662
Whiteboard: [TEF_REQ], visual design, ux-most-wanted → [TEF_REQ], visual design, ux-most-wanted, polish
Keywords: polish
Whiteboard: [TEF_REQ], visual design, ux-most-wanted, polish → [TEF_REQ], visual design, ux-most-wanted
NI Patryk to see if there is a spec already for this. Once we have that, then we can try to find someone to implement.

Thanks!
Flags: needinfo?(padamczyk)
Hi Tiff, 

Speaking on Patryk's behalf, from what I see, there should be a transition animation in Month view when the user is swiping between the months since we have a transition animation for Week view when the user swipes between weeks. I think it makes sense that swiping between months should be the same animation that we currently have for swiping between weeks.
Flags: needinfo?(padamczyk)
Would this be a good first bug? If not, could you add it to your backlog?

Thanks!
Flags: needinfo?(gaye)
Whiteboard: [TEF_REQ], visual design, ux-most-wanted → [TEF_REQ], visual design, ux-tracking
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.