Closed Bug 769101 Opened 7 years ago Closed 7 years ago

"App Tabs" should be renamed to avoid confusion

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 18

People

(Reporter: Harald, Assigned: ananuti)

References

(Depends on 1 open bug)

Details

(Keywords: user-doc-needed, Whiteboard: [good first bug][mentor=dao][lang=xul])

Attachments

(1 file, 2 obsolete files)

Right-clicking a tab offers "Pin as App Tab". Users might confuse this with Mozilla Apps. We actually just had that discussion in IRC where one asked about the App Tabs and the differences between the 2 app modes.

Right-clicking a pinned tab only offers "Unpin Tab". So it seems like we can live without the "App" part.
Component: Web Apps → Tabbed Browser
QA Contact: webapps → tabbed.browser
OS: Mac OS X → All
Hardware: x86 → All
Frank and Dao - Thoughts on this?
"Pin Tab" sounds ok to me. I can't think of a strong reason to keep calling these tabs app tabs. Put a patch up for ui-review?
Keywords: user-doc-needed
Blocks: 784257
These are the places where the relevant strings (pinAppTab.label, unpinAppTab.label) are used and defined:
http://mxr.mozilla.org/mozilla-central/search?string=pinAppTab.label

pinAppTab.label should be renamed to pinTab.label. I also think we should rename unpinAppTab to unpinTab for consistency, even though the string would keep saying "Unpin Tap".
Whiteboard: [good first bug][mentor=dao][lang=xul]
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → ananuti
Status: NEW → ASSIGNED
Attachment #661732 - Flags: review?(dao)
Attachment #661732 - Attachment is patch: true
Comment on attachment 661732 [details] [diff] [review]
patch

>-<!ENTITY  pinAppTab.label                    "Pin as App Tab">
>+<!ENTITY  pinTab.label                       "Pin Tab">
> <!ENTITY  pinAppTab.accesskey                "P">
>-<!ENTITY  unpinAppTab.label                  "Unpin Tab">
>+<!ENTITY  unpinTab.label                     "Unpin Tab">
> <!ENTITY  unpinAppTab.accesskey              "b">

You'll also need to rename the *.accesskey strings.
Attachment #661732 - Flags: ui-review?(ux-review)
Attached patch patch v2 (obsolete) — Splinter Review
> You'll also need to rename the *.accesskey strings.

Oh! Thanks for catching this. I completely overlooked it.
Attachment #661732 - Attachment is obsolete: true
Attachment #661732 - Flags: ui-review?(ux-review)
Attachment #661732 - Flags: review?(dao)
Attachment #661736 - Flags: ui-review?(ux-review)
Attachment #661736 - Flags: review?(dao)
Attachment #661736 - Attachment is obsolete: true
Attachment #661736 - Flags: ui-review?(ux-review)
Attachment #661736 - Flags: review?(dao)
Attached patch patch v3Splinter Review
Attachment #661737 - Flags: ui-review?(ux-review)
Attachment #661737 - Flags: review?(dao)
Duplicate of this bug: 784257
Comment on attachment 661737 [details] [diff] [review]
patch v3

Review of attachment 661737 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Jason Smith [:jsmith] from comment #1)
> Frank and Dao - Thoughts on this?

I support this change completely.
Attachment #661737 - Flags: feedback+
Attachment #661737 - Flags: review?(dao) → review+
Attachment #661737 - Flags: ui-review?(ux-review) → ui-review+
Keywords: checkin-needed
I assume Frank consulted UX people through other channels -- just to make this transparent, who exactly signed off on this?
https://hg.mozilla.org/mozilla-central/rev/b18209831dc5
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 18
(In reply to Dão Gottwald [:dao] from comment #11)
> I assume Frank consulted UX people through other channels -- just to make
> this transparent, who exactly signed off on this?

I consulted myself, and I have known that Stephen trusts me making to make this kind of UI decision. To confirm this, I asked him again about it on IRC today:

14:55 < fryn> shorlander: are you okay with me making ui decisions like that?
...
14:57 < shorlander> fryn: But seriously, yes.
(In reply to Frank Yan (:fryn) from comment #13)
> (In reply to Dão Gottwald [:dao] from comment #11)
> > I assume Frank consulted UX people through other channels -- just to make
> > this transparent, who exactly signed off on this?
> 
> I consulted myself, and I have known that Stephen trusts me making to make
> this kind of UI decision.

What exactly is "this kind"? How we call these tabs can have a couple of implications with regards to user expectations, so I explicitly requested UI review to make sure everybody is on the same page. If I wanted it just rubber-stamped I could have done it myself.
FYI, changes like this affect more than just a string in Firefox. In addition, our documentation needs to be updated and localized. In this case it may not seem like a big deal because it's just the removal of two words but it's actually more involved. Now from the user's perspective this is no longer an "App tab," it's a "Pinned tab." So I should probably change references to App Tab to Pinned tab but only for Firefox 18 and higher. But maybe I should include information that these were previously "App Tabs" since you might have seen that before. To be clear, I *think* this is probably an ok change but it solves a problem we haven't observed on support yet (that could change when Mozilla Apps are widespread) I just wanted to point out that small changes usually aren't.
(In reply to Verdi [:verdi] from comment #15)
> FYI, changes like this affect more than just a string in Firefox. In
> addition, our documentation needs to be updated and localized. In this case
> it may not seem like a big deal because it's just the removal of two words
> but it's actually more involved. Now from the user's perspective this is no
> longer an "App tab," it's a "Pinned tab." So I should probably change
> references to App Tab to Pinned tab but only for Firefox 18 and higher. But
> maybe I should include information that these were previously "App Tabs"
> since you might have seen that before. To be clear, I *think* this is
> probably an ok change but it solves a problem we haven't observed on support
> yet (that could change when Mozilla Apps are widespread) I just wanted to
> point out that small changes usually aren't.

Really I don't know that calling them App Tabs would end up being confusing, but it could potentially be when, or if, we start promoting "Apps" inside of Firefox.

The idea behind calling them App Tabs was the that they would eventually evolve more app like functionality e.g. no chrome, custom toolbars, other specific functionality. I don't think that functionality will happen, or least not in the foreseeable future. So "Pinned Tabs" is more accurate and succinct and also potentially less confusing.

This is probably not the best place for this discussion but we make these types of small changes frequently. Often without considering the ramifications on support or other web properties. Is there something we could or should be doing better to communicate this better and reduce the work required to keep up with our constantly evolving UI?
(In reply to Dão Gottwald [:dao] from comment #14)
> What exactly is "this kind"? How we call these tabs can have a couple of
> implications with regards to user expectations, so I explicitly requested UI
> review to make sure everybody is on the same page. If I wanted it just
> rubber-stamped I could have done it myself.

As I understand and as the UX team has been using it, the purpose of setting ui-review? has never been to get everyone on the same page. The purpose has been to get an individual with trusted opinions on UI decisions to approve changes.

Secondly, I was not simply "rubber-stamping" it. Both Stephen Horlander and Alex Limi trust me to make decisions regarding UI. In particular, I had advocated to the UX team from the beginning for naming the feature "Pinned Tabs", as I was skeptical that the remaining unimplemented portion of the App Tab spec was even a sound, feasible design. We have found, as I predicted, that this to be true. As Stephen explained above, Stephen and Alex agreed that, for the feature as is, "Pinned Tabs" is a more suitable name than "App Tabs". On the UX front, we had already been on the same page.

I agree that we should also inform others to better understand the other changes necessary, e.g. user-doc-needed. While this has a wider impact than just a few strings, it is not one that we have taken lightly, and now is a better time than any to do it.
(In reply to Frank Yan (:fryn) from comment #17)
> (In reply to Dão Gottwald [:dao] from comment #14)
> > What exactly is "this kind"? How we call these tabs can have a couple of
> > implications with regards to user expectations, so I explicitly requested UI
> > review to make sure everybody is on the same page. If I wanted it just
> > rubber-stamped I could have done it myself.
> 
> As I understand and as the UX team has been using it, the purpose of setting
> ui-review? has never been to get everyone on the same page. The purpose has
> been to get an individual with trusted opinions on UI decisions to approve
> changes.

The point is not just to get changes approved as an end in itself. Even for uncontroversial changes (which was not at all clear here, given the history of this feature), we sometimes want to get the UX team in the loop such that they're aware that, for instance, we're actually speaking of pinned tabs rather than app tabs from now on.
Gentlemen. We're off in the weeds a bit, and talking past each other.

We should all be using our best judgement as to when a change really needs a by-the-book review/ui-review, or if it's OK to land with r+ from a competent (if not formally blessed) reviewer. Neither Frank nor Dao are full-up blessed ui-reviewers, but I trust both of your judgements as to when your experience is sufficient to make a call in order to avoid needless process.

Similarly, anyone should feel free (and we should not feel offended) to ask for a formal ui-review, should they disagree with a call or just want to be sure.

It's not always clear from flag-requests (or the comments here, specifically) if one is seeking a formal must-have review, setting a flag as a reminder, or what. Bugzilla is a medium oft lacking in tack and clarity. Indeed, right up till comment 13 it wouldn't have occurred to me to give this bug a second look -- it's a minor patch with a couple existing review rounds, went idle for a week so, and so it seemed thoughtful to drop in and get it landed.

An issue was raised, but now got clarity from Steven that this change is indeed OK, and so I think we're done here. Feel free to follow up with me privately if there's still a disagreement to work out.

[WRT to docs and support issues: I'll agree with Steven in comment 16. A change like this doesn't seem unusual, and so if it's really become a problematic pattern then let's talk about that separately, outside the context and derailedness of this specific bug.]
FWIW, for future reference, when I request ui-review, I always want the real thing. I marked this a good first bug because I expected this to pass the ui-review -- that's not the point. As an example for why this is more than a simple string changes, I just WONTFIXed bug 644721.
Depends on: 799088
You need to log in before you can comment on or make changes to this bug.