Right now all the titles of pinned tiles are blue and bold (with other titles grey and non-bold), but the relationship between the blue/bold and the pinned state is non-obvious. I spent a week wondering why some of my tiles used blue text after my copy of beta updated. Perhaps we can add an icon next to the title, and/or a tooltip?
How about, instead of changing the text style, have the pin button always visible on pinned tiles? Aaron, you know the constraints better than I do. Any input on this?
4 years ago
Duplicate of this bug: 1051769
For context, the point of bolding the title and making it blue was to call attention to the tile without being obnoxious or overly-clever. I didn't want to highlight the whole tile, add another label, or do something else that would start to clutter the interface. I do not recommend leaving the pin button icon visible to indicated a pinned tile. It would take away visual space the partner is paying to enhance. What is the issue with making the pinned tile title blue? I suppose we could include an icon next to the title instead if people feel strongly about it.
(In reply to Aaron from comment #3) > What is the issue with making the pinned tile title blue? I suppose we could > include an icon next to the title instead if people feel strongly about it. Blue text is usually reserved for links on the web. Having some text on the page that is black and other that is blue, when clicking on them does the exact same thing is nonintuitive. There is no clear reasoning as to why blue was chosen to represent a pinned tile. This color could have been red or green for that matter. I'm not even sure why we need to call out when a tile is pinned. What is the value added here by stating that a tile is pinned at all times? We can already show that a tile is pinned when the user hovers over the tile, which feels sufficient to me.
Aaron, are you OK with us removing the blue + bolded text for pinned tiles and solely relying on the hover-UI for showing a tile is pinned?
Ironically, the original "pinned" color WAS read. For some reason that was not acceptable either. It seems reasonable to indicate that a tile is pinned, and they shouldn't have to rollover it to see whether or not it has been pinned. Can we at least do Black and Bold?
(In reply to Aaron from comment #6) > It seems reasonable to indicate that a tile is pinned Why? What value does this have to the user? And, even if I understood this assertion (ie there is some value to the user to know which tiles are pinned 'at a glance') - that's not what the black/red/blue + bold does. There is no clear connection between that being there and the pinned-ness of the tiles. I got upgraded to beta and suddenly some of my tiles had blue text. I thought it was a bug at first!
a pinned tile is inherently special. There is value to both the user and the partner who has enhanced the Tiles. In the future, Tiles will be much more robust and provide more utility. It should be clearly indicated that a pinned tile is different (in importance, if nothing else) than a regular history tile. Regardless, indication of a pinned tile has been a requirement from the very beginning. I'm open to other ideas for an indication, but this is still required.
(In reply to Aaron from comment #8) > a pinned tile is inherently special. There is value to both the user and the > partner who has enhanced the Tiles. I thought pinning was something the user did. What do partners have to do with which set of tiles the user has pinned? Doesn't pinning just pin the tile "in place" - why does the user need to know all the time "yes, this tile is still pinned in place" ? (if pinning is something else now, (a) what is it, and (b) why are we still calling/metaphor-ing it "pinning" and/or (c) shouldn't we separate it from what pinning a tile did before we changed the meaning of pinning?) > Regardless, indication of a pinned tile has been a requirement from the very > beginning. I'm open to other ideas for an indication, but this is still > required. Requirements are there for a reason, normally. What's the reasoning behind this one? Just saying it is there and not up for debate doesn't help me understand *why*. In any case, as I said, it should be obvious that the indication means "this tile is pinned", instead of "here's some colour and bold font, go figure out what this means". :-) I'd be happier with the icon next to the label, although in that case I'd suggest removing that icon from the hover state of the tile (and making the one next to the label interactive), as it'd be silly to have a pin icon that didn't do anything and/or having two identical icons that both did the same, with one always visible and the other showing up on hover...
(In reply to Aaron from comment #6) > Ironically, the original "pinned" color WAS read. For some reason that was > not acceptable either. Red is not acceptable in the same way that blue is not acceptable. I have never seen an association between something that is semi-permanent/locked with any specific color. Same for bold font. The awesomebar dropdown places a star next to items that are bookmarked. Doing something with pinned tabs by placing a pin next to them could be reasonable, but I would still wonder what the value-add is here. Philipp, can you chime in here?
I checked the other browsers to see their UI: Chrome and IE don't offer pinning as an option on their New Tab page. Safari offers pinning but only shows the "pinned status" in their hover-UI, nothing is changed visually when the mouse is away from the tile.
I've talked with Aaron about this and we'll drop the blue/bold entirely and move to a non-interactive pin indicator next to the tile title. Having an indicator of pinned tabs still makes sense with the advent of enhanced tiles, since they might change appearance if the partner changes the enhancement. So the visible indicator provides some reassurance to the user that the tile is still the one that he pinned at some point. Forward-duping this to bug 1068181, which has a mockup.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1068181
You need to log in before you can comment on or make changes to this bug.