Closed Bug 1243152 Opened 9 years ago Closed 9 years ago

Tile on link clicker doesn't update when visiting tab on same domain

Categories

(Hello (Loop) :: Client, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: ianbicking, Unassigned)

Details

To reproduce: - Use the Dev standalone server, or a local server: https://wiki.mozilla.org/CloudServices/Loop/Deploy#Dev (restart if necessary) - Open two tabs, e.g., https://github.com and https://github.com/mozilla/loop - Start the browsing session and open the link clicker in another browser - Switch between the two github tabs - The link clicker will not see an update - Go to another tab on another domain and the link clicker will (correctly) see the change What should happen: - The link clicker should see the tab changes and URLs even from the same domain
Whiteboard: [triage]
Hmm, this is as specified by UX, though switching the tabs is an interesting case. NI to Sevaan ;-)
Flags: needinfo?(sfranks)
If the tile updated in place that would seem fine to me, the problem to me is that the tile sticks on the original URL only.
A tile represents a moment in time, so is not something that should be changed. It is in the chat history and associated to a timestamp. We discussed in another bug that a tile would be shown in chat the first time you hit a new domain, and not a new tile for every page you go to. It's sort of like a chapter heading..."This is the Github chapter". Switching from tabs, as Mark mentioned IS an interesting case too. I wonder if we should just load a tile the first time a user switches between tabs (if the domain is different), and then not show a tile again if the user keeps switch back and forth. We may need to delve in more into this chat history. it does feel like there will be a lot of gaps in the data. Another solution could be to display a tile, and then have a "+ X more" or something to show the URL history for all other links on that domain that you can expand to see if you really want. That's probably offers a more robust history without overwhelming users with tiles in chat. Pau, what do you think?
Flags: needinfo?(sfranks) → needinfo?(b.pmm)
I believe the functionality that I expected was that I should be able to click on the most recent tile to get to the current page being shared. If it only has the first link of the domain, I would possibly be taken somewhere else.
(In reply to Ed Lee :Mardak from comment #4) > I believe the functionality that I expected was that I should be able to > click on the most recent tile to get to the current page being shared. If it > only has the first link of the domain, I would possibly be taken somewhere > else. Thanks, Ed. If it changes your expectations at all, in the Link Clicker UI there is a bar across the top of the page that contains the title of the page being displayed and is an active up-to-date link to click on, and the generator wouldn't need to click on any tile since they have the actual tabs.
The context tile feels much more noticeable to me than the top bar (though the standalone top bar redesign may fix that some). Also the current behavior *feels* like a bug, even if it intended – what works in one case (you click on the tile when someone goes to a page that isn't on the same domain as the last page), doesn't work in another case. It feels unpredictable. A quick fix to make this feel predictable would be to show the last page on a domain instead of the first one. Doing something more sophisticated (like expanding history) seems unwise until we have a better feel for the product. Putting all pages in the product might be interesting to try, but I suspect will lead to a spew of pages, and then we have to do time limits and other stuff to make it work right, and we're back into prematurely sophisticated solutions.
Last page of the domain for a tile feels okay. But that tile could just disappear off the chat area completely if the users are typing things into the boxes, hence the permanence of the title in the bar.
Note: the fact the title bar is updating depending on which page you're on (not just the domain), is something we weren't expecting (and I hadn't seen detailed in the UX). Bug 1238530 is adding the title bar, but if we do want it to update with each change of title on the page, then we'll need a new bug for that. However, it might be worth doing that in this bug, if we're going to do what Ian suggests in comment 6.
Hi guys, The idea behind following this first approach with the tiles is that we don't want to spam users every time the link generator switches his tabs o browses deeper in a website so we wanted to keep the tile as a more general thing, as Sevaan says. I agree with you it can feel odd but if you really think about it, to solve this problem, which is about browsing history, the most obvious thing to do would be to add some sort of way to be able to access that browsing history. So if a user wants to go back to any point in the browsing history of that session they would be able to. I recall this being proposed a while ago but being pushed back don't remember why now. Anyways, in the short term I don't foresee it can be solved in a proper manner so until we don't have persistency, which is the real case where this brings value to the user, I would suggest to stick with the current approach because unless we display a tile when a domain is first accessed and another tile once the users leave that domain, which I don't really know how could that feel, the most relevant thing in time is the moment a user goes to a new domain. I also think users are smart enough to talk to their friend and ask them to go back in their browsing history if they need to for some reason.
Flags: needinfo?(b.pmm)
Whiteboard: [triage] → [uxtriage]
I'll recreate this bug to be more specific
Rank: 29
Flags: needinfo?(ianb)
Priority: -- → P2
Whiteboard: [uxtriage]
Flags: needinfo?(ianb)
Support for Hello/Loop has been discontinued. https://support.mozilla.org/kb/hello-status Hence closing the old bugs. Thank you for your support.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.