This is part branding, part technical. Initial ideas included: - find.firefox.com I'd like to get input first from matej, a technical perspective from mayo with smattering of jrconlin on this one... and Vishy as a sanity check. If we could shoot for having an initial top 3 choices (or less) Prior to June 6th, that would be also be very helpful. Many thanks.
I think we'll need a short, easily remembered URL for marketing purposes, like the one in comment 0, but also an official URL that it will redirect to on mozilla.org, probably something like mozilla.org/firefox/os/find The problem with find.firefox.com, is that firefox.com redirects to the desktop download page and therefore isn't directly associated with Firefox OS. Since Find My Device is an OS feature, it feels like it needs to link back to that more closely (marketplace.firefox.com is different, for example, because the Marketplace is a separate brand). Is this going to be tied to accounts? If we had accounts.firefox.com (or something similar), this could live at accounts.firefox.com/find. We seem to own firefoxos.com, so this could also live at firefoxos.com/find (that may actually be the best solution). Otherwise it would probably be something like firefox.com/os/find, which isn't very pretty. I've added Slater here to get his thoughts as well.
+1 for everything Matej said. :)
I think about this slightly differently. 1) IMO, Find My Device is not an OS feature -- it's a cloud service/product that FxOS is a client of. Likewise for Marketplace. Marketplace can be used from FxOS, Fx Desktop, and Fx Android. There is nothing in particular that limits FMD to FxOS. E.g., one could make Fx desktop or Fx for android a client of FMD as well. 2) This is not the last time we'll have to answer a question of this nature, and we should think more broadly about future services. Where do web properties for Loop and future services and products live? Apple puts services off the path of icloud.com (e.g., www.icloud.com/#find, www.icloud.com/#calendar) and Google goes the other way off of the domain (e.g., drive.google.com, mail.google.com). We have some precedent for doing it Google-style (marketplace.firefox.com, accounts.firefox.com), and there are some security advantages of doing this (they are isolated by the same-origin policy in the browser). I prefer something long the lines of find.firefox.com because it's an extension of the trend set by marketplace and accounts. I'm open to alternatives, but more importantly, I'd like the decision to part of a broader URL strategy for services and not a one-off decision for FMD. (Also, I don't quite get why "firefox.com redirects to the desktop download page" is a problem for find.firefox.com, but not accounts.firefox.com or marketplace.com.)
I agree with Chris, of course it is a cloud service. You're not trying to find just any old Firefox anyway, right? How about findmy.firefox.com?
:ckarlof captures the main question re: overall strategy for services (including FMD). The broader marketing strategy so far per Pete and Mary Ellen has been to use the main Firefox brand for services. Worth noting that "the link that's advertised" is not necessarily the same as the URL that we serve up requests for the service from. firefox.com/find could redirect to find.firefox.com (for ex). being more specific, we do not have the capability to serve multiple apps under the accounts.firefox.com domain at the moment, so that's right out in the short term. I'd suggest we serve requests from find.firefox.com and consider other inbound links as they make sense. That ok?
(In reply to Mark Mayo [:mmayo] from comment #5) > I'd suggest we serve requests from find.firefox.com and consider other > inbound links as they make sense. That ok? That sounds right to me. Worth noting, the comments Matej made above were grounded in the URL policy that has been articulated in our style guide and that we've been trying to follow ever since. However, that was devised before services became a thing, and it sounds like it may need to be modified. I do think we should continue to think about what URL we put forth in a public-facing promotional context, but that's probably a more productive conversation to have once we have a specific example of what that context would be. Until then, I think moving forward with find.firefox.com as our technical starting point sounds like a solid way to go.
thank you, tagging late-l10 since the URL will be seen in the settings.
If I understand this bug correctly, this doesn't involve adding any new strings for translation. Is that correct? Removing late-l10n keyword for now.
should we also have the domain FindMyDevice.com and redirect it to find.firefox.com ?
(In reply to email@example.com [:Vishy] from comment #10) > should we also have the domain FindMyDevice.com and redirect it to > find.firefox.com ? John, WDYT?
My take is that I don't see any harm in getting that domain and redirecting it to find.firefox.com, it feels stronger from a brand perspective to use the URL with our product name in it when we promote this feature.
Thanks John. Conclusion is 1. find.firefox.com is the URL to display in all our literature then such as the info note in the device etc... 2. We will not invest in the domain FindMyDevice.com as it does not add additional value.
Resolving this as fixed; will be verified once the website is complete and on staging.
Adding a note to make sure that we provide appropriate 302s for: https?://(www.)?find.firefox.com to the canonical URL.