946587 - Inconsistent behavior in camera to gallery switch

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Gallery, defect)

Description

[ver4ffos]

Scenario 1: Open gallery -> open an image in fullscreen view -> go to camera -> come back to gallery from camera and observe.
Observation: fullscreen mode is changed to thumbnail list mode.

Scenario 2: Open gallery ->open image and go to edit mode -> go to home screen and open camera -> go to gallery and observe.
Observation : gallery opened in edit mode not in thumbnaillist mode.

In scenario 1 it is assumed that user is coming to see thumbnails, but same assumption is changed in 2nd scenario.

We should keep the same behavior in both cases.

Comment 1

[ver4ffos]

Dear Rob,
Please provide UX for the issue.
We are planning it for Madai.

Comment 2

[Rob MacDonald [:robmac]]

I suspect the reason edit mode is not closed because we would otherwise lose the edit, which is not the user intent. If this is the case I'd prefer to keep the status quo in this case to prevent the user from losing any work. David, are you able to confirm this is the reason edit mode is preserved?

Also, if the user takes a photo or video, the link from camera will always go to the preview of the last image or video... which means this is less common of an issue as the user would have to be in edit mode and have not taken any photos during the session.

Comment 3

[David Flanagan [:djf]]

(In reply to Rob MacDonald [:robmac] from comment #2)
> I suspect the reason edit mode is not closed because we would otherwise lose
> the edit, which is not the user intent. If this is the case I'd prefer to
> keep the status quo in this case to prevent the user from losing any work.
> David, are you able to confirm this is the reason edit mode is preserved?

Yes, exactly. See this comment in gallery.js:

        // If the gallery was already running we we arrived here via a
        // browse activity, then the user is probably coming to us from the
        // camera, and she probably wants to see the list of thumbnails.
        // If we're currently displaying a single image, switch to the
        // thumbnails. But if the user left the gallery in the middle of
        // an edit or in the middle of making a selection, then returning
        // to the thumbnail list would cause her to lose work, so in those
        // cases we don't change anything and let the gallery resume where
        // the user left it.  See Bug 846220.
        if (currentView === LAYOUT_MODE.fullscreen)
          setView(LAYOUT_MODE.list);


> Also, if the user takes a photo or video, the link from camera will always
> go to the preview of the last image or video... which means this is less
> common of an issue as the user would have to be in edit mode and have not
> taken any photos during the session.

I don't know where you got that idea, Rob, but that is just wishful thinking on your part!  We could implement something like that, but it would be difficult because, in general, the gallery app doesn't know about new photos or videos until after it starts up and displays the list of thumbnails.  So the camera would have to pass the filename of the most recently recorded photo or video and gallery would have to implement an entirely new starup sequence for that case.  This gets tricky mainly because we put a lot of effort into optimizing startup time.

ver4ffos: I think the current behavior is as intelligent as we can easily make it. There is not an easy bug fix to be made here.  If there are changes to be made, they will be feature requests and will take substantially more time.

Rob: maybe this shakes out somehow as part of the redesigned preview feature of the camera app.  But unless you want to specify new UX for a new feature, I'd say that the current behavior is correct and we should close this as WONTFIX.

Comment 4

[Rob MacDonald [:robmac]]

Sorry, David, I was thinking of the redesigned camera scenario as opposed to the existing one. I think this will be less of an issue with the redesign and, as a result, agree with your assessment that we can hold off on this bug for now.

Comment 5

[BMO Automation]

Firefox OS is not being worked on