Closed Bug 523034 Opened 15 years ago Closed 13 years ago

Merge duplicate mobile content

Categories

(www.mozilla.org :: General, defect)

Product:
www.mozilla.org
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: clouserw, Assigned: pascalc)

References

Details

(Whiteboard: [mobile])

On mozilla.com trunk, for every locale we have: /$locale/m/* and /$locale/mobile/* With * is stuff like faq, requirements, index, and features. Why is this information duplicated like that? It's going to be a pain to maintain and it slows down using SVN.
/mobile/ is the general extende version for people wanting information about Fennec, /m/ is a cut down version (shorter content, simpler design, no js) for the mobile-friendly display.
(In reply to comment #1) > /mobile/ is the general extende version for people wanting information about > Fennec, /m/ is a cut down version (shorter content, simpler design, no js) for > the mobile-friendly display. The content looked the same, although I'll admit to only looking at part of 1 page. It would still be cleaner to make the simpler design and JS includes dynamic based on the screen size or device type.
(In reply to comment #2) > The content looked the same, although I'll admit to only looking at part of 1 > page. It would still be cleaner to make the simpler design and JS includes > dynamic based on the screen size or device type. ..or even the current URL (/m/ vs /mobile/). It would have probably made localization easier too, IMO. Less files to maintain and less duplicated content to translate for localizers. Anything we can do about this right now, given that bug 522973 has already been filed together with its dependencies?
I talked about it with Caitlin in September during the marketing work week as I didn't understand the reason for different pages and she made clear that these pages were important for their marketing outreach. Given that we are going to release Fennec this quarter, I don't think they want to rethink their whole site structure and content, especially since it has already gone through QA and localization is now started.
Adding Caitlin to this bug so she can comment - she's the most familiar with our mobile content strategy.
Not totally folowing...how can I help?
(In reply to comment #4) > I talked about it with Caitlin in September during the marketing work week as I > didn't understand the reason for different pages and she made clear that these > pages were important for their marketing outreach. Sure, that's not being questioned. The way I understand it, we're talking about the technical solution that was chosen to implement the two-versions approach to fennec's web content. Right now it's two directories, mobile/ and m/, with separate files inside each of them, with some content duplicated or nearly duplicated. What's being suggested (again, IIUC) is that these are single files in one directory, with both versions of content in single file, and the correct version is chosen dynamically depending on the user's device. Something like this: <p>Short sentence for mobile. <span>Longer continuation foe desktop</span><p> and then hide the <span/> when viewing on a mobile device. This could be also hidden earlier, on the server side, btw.
That sounds really over-engineered to me when localizers will just do a copy paste in a matter of minutes which is the easy and fast solution. Your idea has some assumptions like mobile devices having good css/js support for the /m/ version, us being able to correctly detect all of these mobile platforms and display the right version of the page, strings being just longer and not differently worded... This would make IMO the project significantly more complicated on the webdev/IT side for marginal if any improvement for localization and marketing.
(In reply to comment #4) > Given that we are going to release Fennec this quarter, I don't think they want > to rethink their whole site structure and content, especially since it has > already gone through QA and localization is now started. I agree with what Pascal says here. (In reply to comment #8) > That sounds really over-engineered to me when localizers will just do a copy > paste in a matter of minutes which is the easy and fast solution. > > Your idea has some assumptions like mobile devices having good css/js support > for the /m/ version, us being able to correctly detect all of these mobile > platforms and display the right version of the page, strings being just longer > and not differently worded... This would make IMO the project significantly > more complicated on the webdev/IT side for marginal if any improvement for > localization and marketing. I agree with what Pascal says here.
My primary concern when filing this bug was maintenance and L10n. It doesn't sound like L10n is going to be a problem in the short term. Having to update two sets of pages for any content changes seems unnecessary though. The other concern was performance and clean design. I don't think hiding stuff with JS is a great idea (mobile devices would still need to download it) but loading more content for desktop clients via JS would be fine. Ideally, we'd have the same content (text is cheap to transfer) and load lightweight styles and layouts via CSS for mobile devices. Everything /m/ would redirect to /mobile/ so we'd only have one set of pages with the same content (or vice versa). This may be a wontfix but it's worth noting that this is messy on the filesystem, URLs, and SEO, and will be a headache down the line for updates in my opinion.
(In reply to comment #10) > The other concern was performance and clean design. I don't think hiding stuff > with JS is a great idea (mobile devices would still need to download it) but > loading more content for desktop clients via JS would be fine. Ideally, we'd > have the same content (text is cheap to transfer) and load lightweight styles > and layouts via CSS for mobile devices. Everything /m/ would redirect to > /mobile/ so we'd only have one set of pages with the same content (or vice > versa). I guess my question, which I haven't been able to answer from reading this bug, is whether ~/m/ and ~/mobile/ are the same exact content or are there differences. My understanding from the beginning that different content is interspersed through both, which requires us to have two versions. Am I wrong? Perhaps Caitlin knows the answer to that.
There are differences all over the pages because they have a different purpose, the /mobile/ pages are for promotion of the release, the /m/ are for quick downloading of fennec: ex: Site for Sore Eyes Browser controls are stowed away so you can see the Web without any obstructions. Enjoy the view. Site for Sore Eyes Tabs and browser controls are stowed away to the sides of the screen. Now you can see what's been hiding all this time – the entire Web page. Enjoy the view. the pages are superficially similar but the tone, wording and text structure is different and they serve different purposes.
I want to clarify things. There are similar /m/ pages to the /mobile/ pages, but no page is exactly the same. For instance, in the /m/ site, System requirements, FAQ and Privacy Policy all link from the /m download page. These are slim down pages with minimal copy and functionality sense you'd be visiting these pages on potentially a slimmed-down mobile browser (user's existing mobile browser). Generally, the pages that are named similarly convey the same concepts, but the copy is different because we've cut it down significantly to make the content more mobile friendly. That said, word count is different. My hope, however, is that these pages use same words and phrasing as desktop site and again, very minimal copy. It would be my recommendation that these pages are treated different (and not duplicates of desktop site) because there would be too much content and functionality for the user and potentially the Web browser to handle. The first run and the in-product About page are the only other Web pages that are in the product itself. Hope this helps.
After working with the mobile pages for a couple months, I can definitely see the duplication in development, maintenance, coordination, QA, etc. that Wil mentioned. And, I think that will only get worse with time. I think a CSS + JS solution would be *much* cleaner. We've talked about a complete redesign on the mobile pages in Q1 2010, and that would be a great time to consider implementing a different solution. To be clear, I see the value in having simpler pages for simpler phones and that would remain, but the underlying technical solution would change.
Pascal is working on merging a few /m and /mobile pages, to make l10n and maintenance easier. So far, he already has the FAQ pages merged. 08:31 <@pascalc> http://www-trunk.stage.mozilla.com/en-US/m/faq2 08:31 <@pascalc> https://www-trunk.stage.mozilla.com/en-US/mobile/faq/index2.html 08:31 <@pascalc> and the originals were 08:31 <@pascalc> https://www-trunk.stage.mozilla.com/en-US/m/faq 08:31 <@pascalc> https://www-trunk.stage.mozilla.com/en-US/mobile/faq/index.html 08:32 <@pascalc> the version2.html they share the same html file for content Caitlin, please review the content of these. Pascal mentioned he'd like to go further, merging the privacy policy and possibly the features page. The features, sync, and index pages will be more difficult, because the content is more complicated and different. Thanks Pascal!
Assignee: nobody → pascalc
Summary: Mobile content is all duplicated in SVN? → Merge duplicate mobile content
I have merged the typo and link fixes that Steven did today in r65975
More work on faq page in r66009, now internal mobile links are variables.
In /m/ there is a privacy policy: http://www.mozilla.com/en-US/m/privacy But this document does not exist in /en-US/mobile/ where the only privacy policy linked is the general mozilla one in the footer, so it looks like no merging is necessary for this one (plus we usually don't have localizers translate those documents).
So actually the privacy policy for mobile exists in the legal pages for the general site, using that one for the merging of content. I noticed a bad link description in the /legal/ version of the page (the /m/ version was correct): https://addons.mozilla.org/en-US/Firefox for mobile/ should be https://addons.mozilla.org/en-US/mobile/ The merged version uses https://addons.mozilla.org/en-US/mobile This is committed in r66100 along with the finalization of the FAQ pages merge
I am working on merging the credits page and I have questions about them. The pages are: http://www.mozilla.com/en-US/m/credits.html http://www.mozilla.com/en-US/mobile/credits/ Apparently the /mobile/credits/ page is an in-product one, it is the page people get redirected to if they type about:credits in Fennec The /m/credits.html seems to be only linked from /m/1.0/about/ but I grepped the whole repo and /m/1.0/about/ is not linked from anywhere. How are people getting to these about and credit pages? Other sites than mozilla.com where we promote them? The /m/1.0/ folder also has /whatsnew/ and /firstrun/ folders, I know for sure that firsrun is in Fennec chrome, I don't know if we have Whatsnew in Chrome or even if Fennec uses a whatsnew page, but if people get to see a whatsnew page when upgrading to a newer version of Fennec, they are by definition not using a capabilities limited browser, so why do we have these pages in the /m/ folder? In short, can I just delete some of these pages that seem to not have any use? (also, Vivien Nicolas is not in the credits list while being one of the main devs working on Fennec and I think that the people that localized Fennec should be listed as well, but that could be dealt in a separate bug ;)).
Another question about the requirements.html page, in the /mobile/ section this one is called /platforms/, is it OK to rename requirements.html platforms.html for consistency?
(In reply to comment #21) > I am working on merging the credits page and I have questions about them. > > The pages are: > http://www.mozilla.com/en-US/m/credits.html > http://www.mozilla.com/en-US/mobile/credits/ > > Apparently the /mobile/credits/ page is an in-product one, it is the page > people get redirected to if they type about:credits in Fennec > > The /m/credits.html seems to be only linked from /m/1.0/about/ but I grepped > the whole repo and /m/1.0/about/ is not linked from anywhere. How are people > getting to these about and credit pages? Other sites than mozilla.com where we > promote them? About and Credit pages we've only discussed the need/ability for users to find/view these pages in fennec/in-device. > > The /m/1.0/ folder also has /whatsnew/ and /firstrun/ folders, I know for sure > that firsrun is in Fennec chrome, I don't know if we have Whatsnew in Chrome or > even if Fennec uses a whatsnew page, but if people get to see a whatsnew page > when upgrading to a newer version of Fennec, they are by definition not using a > capabilities limited browser, so why do we have these pages in the /m/ folder? > > In short, can I just delete some of these pages that seem to not have any use? You may. When I first came on board, Laura Mesa had already created a whatsnew page for users to see if they updated. However, look the update process doesn't require us to push a whatsnew/thanks for updating page. At least not currently. If you need to delete this page (and we may consider using a page like this for future releases) then you can. > > (also, Vivien Nicolas is not in the credits list while being one of the main > devs working on Fennec and I think that the people that localized Fennec should > be listed as well, but that could be dealt in a separate bug ;)). Yes, please. Stuart sent out a note to collect names originally but new people have joined the project since. File it! ;)
(In reply to comment #22) > Another question about the requirements.html page, in the /mobile/ section this > one is called /platforms/, is it OK to rename requirements.html platforms.html > for consistency? Yes. You can change m/requirements to m/platforms.
ok requirements.html renamed as platforms.html and links updated in r66125
The Credits page has a copyright notice different from other pages (and it also says 2009) : Copyright © 2005–2009 Mozilla. All rights reserved. Is it ok to use the same copyright mention we put on the rest of mozilla.com instead? We have this sentence already localized for almost all of our locales for our firefox desltop page so that would mean no work on localized pages for the footer: Except where otherwise noted, content on this site is licensed under the Creative Commons Attribution Share-Alike License v3.0 or any later version.
m/credits.html and mobile/credits/ have merged content in r66141, I also put the contributors list in a separate include for easier maintenance.
I put the standard Creative commons license text instead of the copyright notice for the moment in the footer (see comment #26), Caitlin could you check if we should keep that or if we should put the older copyright string? I believe we should have the CC sentence since we updated the whole site with it but maybe mobile is an exception.
The m/platforms.html and /platforms/ pages have different content. On /m/ we have these sections: * Supported Devices * Fully Localized Versions On /mobile/ we have these sections: * Supported Devices * Download Firefox for mobile to your PC I don't know which version has the most recent content, Caitlin do you want these pages to be merged into one?
I think the fully localized version section is the difference between the two. We didn't put the grid on the desktop version because users can't download to PC and then sync to their mobile. We can add the grid, but we'd need to remove the links/ download CTA for the desktop. Not sure if this is what you mean. I should also mention that the Web designer is working to combine the Nokia for N900 (/maemo page) and Other Platforms & Languages page on (/platforms page) on the desktop site.
So you mean that /maemo/ and /platforms/ will be one page soon? In that case it's probably better that I wait for these two pages to be merged in /mobile/ before working on reusing the page in /m/. Do you have an ETA from the web designer about it?
Caitlin, can you confirm that it is ok to delete the m/1.0 folder? That is: /m/1.0/ /m/1.0/about/ /m/1.0/firstrun/ /m/1.0/whatsnew/
Can you send me the full URLs. I need to double-check with Stuart and discuss any possible implications.
(In reply to comment #31) > So you mean that /maemo/ and /platforms/ will be one page soon? In that case > it's probably better that I wait for these two pages to be merged in /mobile/ > before working on reusing the page in /m/. Do you have an ETA from the web > designer about it? I should be getting the new page design later this week or next Monday.
Regarding the Sync/ page, the only real content difference I see between m/sync/ and mobile/sync/ is the step by step instructions that we have in /mobile/sync/ on the side that are very detailed, the rest looks to me mostly rewording of the same content. Should these instructions also be in the /m/ version? Is it ok to just take the /mobile/ version for /m/ detailed install steps included? Also, in the /m/ folder there was a convention of using individual files for pages instead of folders like on the rest of mozilla.com and sync/ is the only exception. Is that because there will be subfolders in m/sync/ in the future or is that just a small inconsistency I can fix by renaming the file sync.html?
(In reply to comment #35) > Regarding the Sync/ page, the only real content difference I see between > m/sync/ and mobile/sync/ is the step by step instructions that we have in > /mobile/sync/ on the side that are very detailed, the rest looks to me mostly > rewording of the same content. Should these instructions also be in the /m/ > version? Is it ok to just take the /mobile/ version for /m/ detailed install > steps included? > > Also, in the /m/ folder there was a convention of using individual files for > pages instead of folders like on the rest of mozilla.com and sync/ is the only > exception. Is that because there will be subfolders in m/sync/ in the future or > is that just a small inconsistency I can fix by renaming the file sync.html? They're different, once again, for viewability on a mobile device. /m/sync the download button is at the top and there is punchy, three steps of instructions. The /mobile version is the longer version of this page. I don't think I can approve the merging of these pages until I saw what it may look like. I find that limited copy and easy to tab, top buttons would be better for the /m page.
(In reply to comment #35) > Also, in the /m/ folder there was a convention of using individual files for > pages instead of folders like on the rest of mozilla.com and sync/ is the only > exception. Is that because there will be subfolders in m/sync/ in the future or > is that just a small inconsistency I can fix by renaming the file sync.html? sync.html please
OS: Linux → All
Hardware: x86 → All
sync/ renamed sync.html and link to it updated in r66155
OS: All → Linux
Hardware: All → x86
about and firstrun can both go, as they are in product. not sure what we're using whatsnew for.
(In reply to comment #37) > (In reply to comment #35) > > Regarding the Sync/ page, the only real content difference I see between > > m/sync/ and mobile/sync/ is the step by step instructions that we have in > > /mobile/sync/ on the side that are very detailed, the rest looks to me mostly > > rewording of the same content. Should these instructions also be in the /m/ > > version? Is it ok to just take the /mobile/ version for /m/ detailed install > > steps included? The differences seem minor to me, and I'd be interested in seeing a merged version that uses the simple instructions from /m/sync.
>about and firstrun can both go, as they are in product. not sure what we're using whatsnew for. I guess that since nobody knows what the whatsnew page is here for and that it is not linked from anywhere else on the site, it is safe to delete it, right?
(In reply to comment #42) > >about and firstrun can both go, as they are in product. not sure what we're > using whatsnew for. > > I guess that since nobody knows what the whatsnew page is here for and that it > is not linked from anywhere else on the site, it is safe to delete it, right? Yes, please. If we ever need a page like that, it's going to be in the product chrome anyway.
1.0 folder removed in r66160
Sync pages merged in r66170 with index2.html and sync2.html test pages for approval. This page is centralized in one file but displays conditional instructions depending on if the /m or /mobile is used, it should therefore please all sides ;) Caitlin, can you check it? http://www-trunk.stage.mozilla.com/en-US/mobile/sync/index2.html (this one is identical to the current one) http://www-trunk.stage.mozilla.com/en-US/m/sync2
Looks great, thanks.
thanks, temporary pages replacing the usual sync pages in r66171
ok, here is the current status of pages in /m/: credits: Merged privacy: Merged faq: Merged sync: Merged 1.0 folder: deleted detection: unique to /m/, no change unsupported: unique to /m/, no change index: unique to /m/, no change platforms: (ex-requirement) renamed, waiting for a merge with Maemo page features: Not done yet Features is a very long page in the /mobile/ version and has a lot of inlined images that may be too heavy for the /m/ version but most importantly, I would like to know if it is likely to change with 1.1 and when, because that's a page that we probably want translated. Thanks! If I missed something, please tell me :)
Now that the 1.0 folder is deleted, may I delete the m/credits.html page that I had merged? (see comment #21)
So it's been merged as one? By doing this, I'll still be able to view it from the About:fennec page > Credits yes?
all locales that had translated the two FAQs for Fennec 1.0 initial release are now using a single merged FAQ in r66193, I'll file bugs to have their FAQ updated with recent changed.
More template works in r66197 for FAQ pages: We now have only two sets of templates for mobile, the en-US one and the en-GB one with a simpler header/footer, all locales pick the en-GB template and build on it. I will do the same for all mobile pages that require localization.
unsupported.html is no longer used, deleted in r66366 and r66367
Whiteboard: [mobile]
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.