improve homepage, leap for mankind

RESOLVED FIXED in 2.1

Status

Webtools
Elmo
P2
normal
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: Pike, Assigned: peterbe)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [wireframes], URL)

Attachments

(3 attachments, 4 obsolete attachments)

(Reporter)

Description

7 years ago
I've been looking at that sad excuse of a homepage that I did, and didn't find anything I wanted to click on.

There are a good deal of changes compared to the wireframes, but I think we should take some action now.

Most notably, we should drop having two sections for dashboard provided by l10nstats and by shipping. Let's hide that we have l10nstats, and make shipping provide one drop of dashboards and progress per tree/appversion that it has per app.

Also, I think we can do some copy for the initial text, and link to various pieces of our infrastructure, as hinted by in the notes below.

I've had the idea to move http://l10n.mozilla.org/planet/ into a django app. I had found one at some point, but don't right now. It'd be a good first step to get some community activity exposed. This can be any of a follow up or depend or ride-along or a wontfix.

Uncensored notes from http://lunch.mozilla.org:9000/MJ5XBDqsoJ, not resolutions:
(1.1) that's the motto of the site. probbaly don't need the link there
* it should answer the question "am I on the right site or not?"
(2.2) register doesn't really work, you need an ldap account for that
* maybe on the sign in page should give an explanation why it's not possible to register?
(2.3) we currently don't have search and it's hard to add it. What should we index? If only locale and project names, (maybe contributors names, too), the search experience will be misleading (it doesn't search the whole site after all). 
(3.1) the getting started documentation should be about getting involved, not only starting a new localization
   * "recommended reading for localizers"
   * link to wikimo/L10n (or to wathever the "docs" link in the header links to, see All_Docs below)
(3.2) what is the algorithm for showing the ~20 locales there?
   are these "featured" locales? (a new team has started and they're looking for new contributors)
   maybe a search box would be a better idea? Or an autocomplete widget?
   (Axel) Any algorithm will be wrong, IMHO.
   (stas) hand-picked featured locales maybe?
   also: what goes in to the intro paragraph there?
(3.3) projects to localize
  * not all projects have icons; possible solution: generic icons for apps, webapps etc.
  * what is the criterion for displaying those 7 projects?
  ** if we display currently active projects, we'll end up with 5 project with the firefox icon (fx4, fx36, fx35, fennec2, fennec11)
  ** possible  solution: hand-pick a couple of projects that we want to increse the visibility of (e.g. we want new localizers to focus on fx4, not 36 or 35, so only put fx4 there)
(4.1) feed from the l10n planet: http://l10n.mozilla.org/planet/
(4.2) twitter box
  we don't currently have a twitter account; do we really need one? do we have the appropriate content for this channel?
  suggestions:
  * string/code freezes
  * signoff deadlines
  * upcoming releaes/projects
  * new localization starting
  * new docs
  
  this box is a commitment: a 3-month-old tweet is worse than no tweet at all.
  also: if we remove the twitter box, does the current two column layout still work?
  
(3.4) Learn about Localization
  remove, 3.1 should be enough
(3.5) Join the community
  remove, we don't have that many oages to link to
  the "community" link in the header is enough
  
(3.6) For Developers
  keep it, good stuff
(3.7). Behind the scenes (not in the wireframe)
an additional box dedicated for people who want to get involved in l10n-drivers work
"Hi, this is our team, check out our meeting notes or see what we're working on:"
* localization 2.0
* infrastructure (dashboard, compare-locales)
* link to https://wiki.mozilla.org/L10n:Tools (where silme, verbatim/pootle, narro, pontoon live)
* interesting bugzilla aliases to watch (e.g. RTL stuff)
(5.1) Footer
  the license is likely wrong
(5.2) Legal notices
  what really goes here? need to file a bug with legal
Priority: -- → P2
(Assignee)

Comment 1

6 years ago
Here are some more notes I took from the elmo sprint in London

* We wait with twitter feed

* We aim to merge sub-head sentance with first top paragraph

* We build the list of teams as per wireframes
  (to see how that looks/feels on screen)

* We keep "Projects to localize" and inside list applications to
  localize
  (clicking on "Firefox" goes to Signoffs for the firefox-aurora
  AppVersion for example) and also mention things like Verbatim.

* Icons for applications will have to wait!
  * too hard to confidently/solidly get "sub-application" icons like
  Nightly, Thunderbird EarlyBird, etc.
  * Using the broad icons (e.g. Nightly gets the release Firefox logo)
  would be potentially confusing.
(Reporter)

Comment 2

6 years ago
Jeff, this is one of the first touchpoints between the dashboard and our broader communication pieces, you probably want to look at the url here and the notes.
(Assignee)

Comment 3

6 years ago
Note to self: the original design implementation was here: 
https://bugzilla.mozilla.org/show_bug.cgi?id=592515
(Assignee)

Comment 4

6 years ago
Created attachment 579874 [details] [diff] [review]
New design implemented

The easiest way to review this is perhaps to first focus on the python changes around some of the python changes (for example, around the feed reader)
Then, to see if it works would be to click around on 
http://ec2-50-16-138-103.compute-1.amazonaws.com/

We will need to take a slight leap of faith to have this deployed on -dev- and just wait till all other bits and pieces are fully working and deploy when we're happy rather than based on calendar.
Attachment #579874 - Flags: review?(l10n)
(Reporter)

Comment 5

6 years ago
Comment on attachment 579874 [details] [diff] [review]
New design implemented

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

Worst comment first, I don't think that 960.gs is a good base choice :-(. It makes wide views hard to get right.

The dashboards are cut on the right on my local install, and views like dashboard/tree-status/ get a rather small data div.
The log-in box doesn't float to the right, but hangs somewhere in the free air (or not, it's right end is 960 from the left, I assume).

The comments on the files are on details, or on an overarching scheme of how to handle the feed. I'm torn on that one, but I really fear the blocking load. Depending on how to get out of there, different comments on the code apply slightly differently, I'd say.

More general notes:

header_content_extra doesn't make a good content area in my book in this design. It's looking really optional for the most part, so I'd only use it in exceptional cases.

::: apps/accounts/templates/accounts/login_form.html
@@ +58,5 @@
> +{% endfor %}
> +<button type="submit" class="button">OK</button>
> +{# {{ form }} #}
> +{#<ul>{{ form.as_ul }}<li><input type="submit" value="OK"></li></ul>#}
> +</form>

Curious, what does this buy us? I'd just like to see what we gain for the extra code.

::: apps/homepage/static/homepage/css/teams.css
@@ +35,5 @@
> + *
> + * ***** END LICENSE BLOCK ***** */
> +
> +#teams {
> +  -moz-column-width: 200px;

This is a text width right now, aka 35ex, and I think it makes much more sense that way.

::: apps/homepage/templates/homepage/locale-team.html
@@ +45,5 @@
>  {% endblock %}
> +
> +{% block header_h1 %}
> +Mozilla Localization Team {{ locale_name }}
> +<span class="lang">(ru-NS)</span>

oh? ru-NS? locale.code would be better :-)

::: apps/homepage/templates/homepage/teams.html
@@ +50,5 @@
>  {% endcompress %}
>  {% endblock %}
> +
> +{% block header_h1 %}Mozilla Localization Teams{% endblock %}
> +{% block header_content_extra %}<p>Find the different localization teams and the projects they work on on the pages beneath.</p>{% endblock %}

I'd move this back to content.

::: apps/homepage/test_rss20.xml
@@ +1,5 @@
> +<?xml version="1.0"?>
> +<rss version="2.0"
> +	xmlns:dc="http://purl.org/dc/elements/1.1/"
> +	xmlns:atom="http://www.w3.org/2005/Atom"
> +>

Make this less dramatic and smaller example data really? Shaver moving on from mozilla doesn't necessarily needs to be manifested in our test data.

::: apps/homepage/tests.py
@@ +71,4 @@
>          # arecibo server
>          settings.ARECIBO_SERVER_URL = 'http://arecibo/'
>  
> +        settings.L10N_FEED_URL = self._local_feed_url('test_rss20.xml')

I commented on the test data already, I wonder. Should we just abuse that feedparser doesn't mind getting plain content and set that here?

::: apps/homepage/views.py
@@ +82,5 @@
>  def index(request):
> +    split = 6
> +    locales = Locale.objects.filter(name__isnull=False).order_by('name')
> +
> +    feed_items = get_feed_items(5)

I'm not really comfortable that we have a blocking network call in the hot path here.

I'd rather see us do something async here, either by loading the div with the feed via ajax, or by going through celery to update the cached feed content.

::: apps/l10nstats/templates/l10nstats/tree_progress.html
@@ +98,1 @@
>  {% endcompress %}

This view is hosed, http://localhost:8000/dashboard/tree-status/fx_aurora on my setup has the histogram all fancy.

For this view, header_content_extra is actually good, IMHO. FYI.

::: apps/pushes/templates/pushes/pushlog.html
@@ -53,5 @@
>  <link rel="stylesheet" href="{{ STATIC_URL }}css/jquery.ui/base/ui.theme.css" type="text/css">
>  {% endcompress %}
> -{% compress css %}
> -<link rel="stylesheet" href="{{ STATIC_URL }}pushes/css/style-gitweb.css" type="text/css">
> -{% endcompress %}

Is this replaced with anything? I'm not really bound to that appearance, but there had been nice things like switching backgrounds on rows etc.

::: settings/base.py
@@ +297,5 @@
>    'compressor.finders.CompressorFinder',
>  )
>  
> +## Feeds
> +L10N_FEED_URL = 'http://planet.mozilla.org/l10n/atom.xml'#'http://planet.mozilla.org/rss20.xml'

I'd remove the reference to the global planet.

Also, it might be worthwhile to add a comment that one can enter plain data here for testing? See the test comments.

::: settings/local.py-dist
@@ +46,5 @@
>  #ARECIBO_SERVER_URL = "http://amckay-arecibo.khan.mozilla.org/"
>  
> +# Feed for example, to avoid having to do a HTTP call for the feed use:
> +#L10N_FEED_URL = 'file:///Users/peterbe/dev/MOZILLA/ELMO/elmo/apps/homepage/test_rss20.xml'
> +

... or make that here.

::: static/js/base.js
@@ +98,5 @@
> +               });
> +             }
> +           }
> +         });
> +         return false;

I disagree that your editor is doing something useful here, fwiw.

Not going to reverse engineer what this does.

::: static/simile/exhibit/exhibit-bundle.css
@@ +659,1 @@
>  .exhibit-tabularView-columnHeader {

I doubt this file should change at all. I guess this is your editor and the changes that you moved to dashboard.css?

::: templates/base.html
@@ +53,5 @@
> +	src: url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.eot');
> +	src: local({% if debug %}'{{ STATIC_URL }}fonts/MetaWebPro-Bold.woff'{% else %}'☺'{% endif %}), url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.woff') format('woff');
> +        font-weight: bold;
> +   }
> +   </style>

Should this be external?

Also, who licensed MetaWebPro for whom?

@@ +67,5 @@
> +				<input type="hidden" name="cx" value="002443141534113389537:ysdmevkkknw">
> +				<input type="hidden" name="cof" value="FORID:0">
> +				<input type="search" name="q" id="q" placeholder="Search"><input type="image" src="images/search-submit.png" alt="Search" id="quick-search-btn">
> +			</form>
> +			-->

Remove that instead of leaving keys and whatnot commented out?

@@ +73,5 @@
> +			<div id="auth">
> +				{% include "accounts/user_forms.html" %}
> +				<noscript>Not logged in</noscript>
> +<!--				<a href="homepage-login.html">Sign in</a> |
> +				<a href="">Register</a>-->

... same here.

@@ +114,5 @@
> +				<p>Except where otherwise <a href="">noted</a>, content on this site is licensed under the <a href="">Creative Commons Attribution Share-Alike License v3.0</a> or any later version. </p>
> +				<p class="notices"><a href="{% url privacy.views.show_policy %}">Privacy Policy</a> | <a href="">Legal Notices (XXX)</a></p>
> +			</div>
> +            <div id="template-bottom-background"></div>
> +		</footer>

Did we figure out where those links go? Rather not have XXX in there, as little as <!-- -->

::: vendor-local/lib/python/feedparser.py
@@ +3,5 @@
> +
> +Handles RSS 0.9x, RSS 1.0, RSS 2.0, CDF, Atom 0.3, and Atom 1.0 feeds
> +
> +Visit http://feedparser.org/ for the latest version
> +Visit http://feedparser.org/docs/ for the latest documentation

Feedparser moved to http://code.google.com/p/feedparser/, and there's a 5.1 now. I wouldn't mind much, if the old link wasn't dead broken.
Attachment #579874 - Flags: review?(l10n) → review-
(Assignee)

Comment 6

6 years ago
(In reply to Axel Hecht [:Pike] from comment #5)
> Comment on attachment 579874 [details] [diff] [review]
> New design implemented
> 
> Review of attachment 579874 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Worst comment first, I don't think that 960.gs is a good base choice :-(. It
> makes wide views hard to get right.
> 
OK. Can't do anything about that :)

> The dashboards are cut on the right on my local install, and views like
> dashboard/tree-status/ get a rather small data div.
> The log-in box doesn't float to the right, but hangs somewhere in the free
> air (or not, it's right end is 960 from the left, I assume).
> 

I'm going to describe the problem with the dashboard and the strange footer floating problem with the tree-status page to Schalk so he can hopefully fix it on my EC2 server. 

Regarding the Login, I don't think it's meant to float strictly to the right-hand edge. As far as I've understood, this is how it's supposed to be. 


> The comments on the files are on details, or on an overarching scheme of how
> to handle the feed. I'm torn on that one, but I really fear the blocking
> load. Depending on how to get out of there, different comments on the code
> apply slightly differently, I'd say.
> 
> More general notes:
> 
> header_content_extra doesn't make a good content area in my book in this
> design. It's looking really optional for the most part, so I'd only use it
> in exceptional cases.
> 

What do you suggest instead? I quite like it when it's filled in with something. Either way, let's let an expert decide once he/she is involved. 

> ::: apps/accounts/templates/accounts/login_form.html
> @@ +58,5 @@
> > +{% endfor %}
> > +<button type="submit" class="button">OK</button>
> > +{# {{ form }} #}
> > +{#<ul>{{ form.as_ul }}<li><input type="submit" value="OK"></li></ul>#}
> > +</form>
> 
> Curious, what does this buy us? I'd just like to see what we gain for the
> extra code.
> 
"Buy us"? That it works :)
I spent a lot of time making the login form work nicely with the new design. I have removed the commented-out code now. 


> ::: apps/homepage/static/homepage/css/teams.css
> @@ +35,5 @@
> > + *
> > + * ***** END LICENSE BLOCK ***** */
> > +
> > +#teams {
> > +  -moz-column-width: 200px;
> 
> This is a text width right now, aka 35ex, and I think it makes much more
> sense that way.
> 
What? Don't understand your point. Are you referring to replacing "200px" with "35ex"? 

> ::: apps/homepage/templates/homepage/locale-team.html
> @@ +45,5 @@
> >  {% endblock %}
> > +
> > +{% block header_h1 %}
> > +Mozilla Localization Team {{ locale_name }}
> > +<span class="lang">(ru-NS)</span>
> 
> oh? ru-NS? locale.code would be better :-)
> 
Well spotted!! That's what code reviews are for.

> ::: apps/homepage/templates/homepage/teams.html
> @@ +50,5 @@
> >  {% endcompress %}
> >  {% endblock %}
> > +
> > +{% block header_h1 %}Mozilla Localization Teams{% endblock %}
> > +{% block header_content_extra %}<p>Find the different localization teams and the projects they work on on the pages beneath.</p>{% endblock %}
> 
> I'd move this back to content.
> 

If I've understood you correctly, you want this to be managed *inside* the "content" block? That doesn't work. The content needs to appear instead the <div id="header-content"> area. 


> ::: apps/homepage/test_rss20.xml
> @@ +1,5 @@
> > +<?xml version="1.0"?>
> > +<rss version="2.0"
> > +	xmlns:dc="http://purl.org/dc/elements/1.1/"
> > +	xmlns:atom="http://www.w3.org/2005/Atom"
> > +>
> 
> Make this less dramatic and smaller example data really? Shaver moving on
> from mozilla doesn't necessarily needs to be manifested in our test data.
>

It's not just for unit testing. It's also for local runserver development. 
I did however now remove the Shaver item. 
 
> ::: apps/homepage/tests.py
> @@ +71,4 @@
> >          # arecibo server
> >          settings.ARECIBO_SERVER_URL = 'http://arecibo/'
> >  
> > +        settings.L10N_FEED_URL = self._local_feed_url('test_rss20.xml')
> 
> I commented on the test data already, I wonder. Should we just abuse that
> feedparser doesn't mind getting plain content and set that here?
> 
I'd rather not. We demonstrate it better by using a URL. 

> ::: apps/homepage/views.py
> @@ +82,5 @@
> >  def index(request):
> > +    split = 6
> > +    locales = Locale.objects.filter(name__isnull=False).order_by('name')
> > +
> > +    feed_items = get_feed_items(5)
> 
> I'm not really comfortable that we have a blocking network call in the hot
> path here.
> 
> I'd rather see us do something async here, either by loading the div with
> the feed via ajax, or by going through celery to update the cached feed
> content.
> 

It is cached for an hour every time after all. Introducing, celery right now would be fun but would block the release of this even further. 

If you like, we could set up an hourly cron job that does something like::

  curl https://l10n.mozilla.org/?FORCE_FEED_REFRESH=true

That way, it becomes less likely that a human user kicks off the potentially slow network process. 
Bear in mind that the feed on is on pretty decent hardware and does work very reliably. 

My suggestion is to iterate this with a follow up later with a proper celery based solution.  


> ::: apps/l10nstats/templates/l10nstats/tree_progress.html
> @@ +98,1 @@
> >  {% endcompress %}
> 
> This view is hosed, http://localhost:8000/dashboard/tree-status/fx_aurora on
> my setup has the histogram all fancy.
> 

"all fancy"?
Either way, I'm going to dump this problem on Schalk and he can hopefully solve it. 

> For this view, header_content_extra is actually good, IMHO. FYI.
> 
> ::: apps/pushes/templates/pushes/pushlog.html
> @@ -53,5 @@
> >  <link rel="stylesheet" href="{{ STATIC_URL }}css/jquery.ui/base/ui.theme.css" type="text/css">
> >  {% endcompress %}
> > -{% compress css %}
> > -<link rel="stylesheet" href="{{ STATIC_URL }}pushes/css/style-gitweb.css" type="text/css">
> > -{% endcompress %}
> 
> Is this replaced with anything? I'm not really bound to that appearance, but
> there had been nice things like switching backgrounds on rows etc.
> 

I don't think it's replaced. If you think we really need the odd/even background coloring I can put that in. 

> ::: settings/base.py
> @@ +297,5 @@
> >    'compressor.finders.CompressorFinder',
> >  )
> >  
> > +## Feeds
> > +L10N_FEED_URL = 'http://planet.mozilla.org/l10n/atom.xml'#'http://planet.mozilla.org/rss20.xml'
> 
> I'd remove the reference to the global planet.
> 
Gone.

> Also, it might be worthwhile to add a comment that one can enter plain data
> here for testing? See the test comments.
> 
> ::: settings/local.py-dist
> @@ +46,5 @@
> >  #ARECIBO_SERVER_URL = "http://amckay-arecibo.khan.mozilla.org/"
> >  
> > +# Feed for example, to avoid having to do a HTTP call for the feed use:
> > +#L10N_FEED_URL = 'file:///Users/peterbe/dev/MOZILLA/ELMO/elmo/apps/homepage/test_rss20.xml'
> > +
> 
> ... or make that here.
>
Instead of that absolute url, I'm going to replace that with a little `os.path(...)` trick so that you can enable the same local feed url without having to s/peterbe/Pike
 
> ::: static/js/base.js
> @@ +98,5 @@
> > +               });
> > +             }
> > +           }
> > +         });
> > +         return false;
> 
> I disagree that your editor is doing something useful here, fwiw.
> 
> Not going to reverse engineer what this does.
> 
Next time, I'll make a diff that ignores whitespace. 

> ::: static/simile/exhibit/exhibit-bundle.css
> @@ +659,1 @@
> >  .exhibit-tabularView-columnHeader {
> 
> I doubt this file should change at all. I guess this is your editor and the
> changes that you moved to dashboard.css?
> 
Reverted.

> ::: templates/base.html
> @@ +53,5 @@
> > +	src: url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.eot');
> > +	src: local({% if debug %}'{{ STATIC_URL }}fonts/MetaWebPro-Bold.woff'{% else %}'☺'{% endif %}), url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.woff') format('woff');
> > +        font-weight: bold;
> > +   }
> > +   </style>
> 
> Should this be external?
> 
Apparently. It's considered unsafe to use a local font. Hence that smiley character. 
The reason for the `if debug` trick in there is to use the local when doing development. 

> Also, who licensed MetaWebPro for whom?
> 
Don't know. Suggestions?

> @@ +67,5 @@
> > +				<input type="hidden" name="cx" value="002443141534113389537:ysdmevkkknw">
> > +				<input type="hidden" name="cof" value="FORID:0">
> > +				<input type="search" name="q" id="q" placeholder="Search"><input type="image" src="images/search-submit.png" alt="Search" id="quick-search-btn">
> > +			</form>
> > +			-->
> 
> Remove that instead of leaving keys and whatnot commented out?
> 
Gone.

> @@ +73,5 @@
> > +			<div id="auth">
> > +				{% include "accounts/user_forms.html" %}
> > +				<noscript>Not logged in</noscript>
> > +<!--				<a href="homepage-login.html">Sign in</a> |
> > +				<a href="">Register</a>-->
> 
> ... same here.
> 
Gone.

> @@ +114,5 @@
> > +				<p>Except where otherwise <a href="">noted</a>, content on this site is licensed under the <a href="">Creative Commons Attribution Share-Alike License v3.0</a> or any later version. </p>
> > +				<p class="notices"><a href="{% url privacy.views.show_policy %}">Privacy Policy</a> | <a href="">Legal Notices (XXX)</a></p>
> > +			</div>
> > +            <div id="template-bottom-background"></div>
> > +		</footer>
> 
> Did we figure out where those links go? Rather not have XXX in there, as
> little as <!-- -->
> 

There's another bug on that. #707808
I made this bug block that one. I think we actually nailed in it a meeting so cracking #707808 should be easy. 

> ::: vendor-local/lib/python/feedparser.py
> @@ +3,5 @@
> > +
> > +Handles RSS 0.9x, RSS 1.0, RSS 2.0, CDF, Atom 0.3, and Atom 1.0 feeds
> > +
> > +Visit http://feedparser.org/ for the latest version
> > +Visit http://feedparser.org/docs/ for the latest documentation
> 
> Feedparser moved to http://code.google.com/p/feedparser/, and there's a 5.1
> now. I wouldn't mind much, if the old link wasn't dead broken.

I'm apprehensive about manually fiddling with code I installed from pypi. 
Do you think I should just do a plain edit of those URLs and pretend it came like that? Let me know.
Blocks: 707808
(Assignee)

Comment 7

6 years ago
Created attachment 585774 [details] [diff] [review]
More design fixes

The problem with the right-side chopped off dashboard and the floating legend boxes on the tree-status page has all been fixed. 

Also, various other fixes as per my last comment addressed. Some unresolved arguments in my latest response not resolved.
Attachment #579874 - Attachment is obsolete: true
Attachment #585774 - Flags: review?(l10n)
(Reporter)

Comment 8

6 years ago
(In reply to Peter Bengtsson [:peterbe] from comment #6)

I'll look at the new patch again, but some answers to comment 6 right away:

> 
> > ::: apps/homepage/static/homepage/css/teams.css
> > @@ +35,5 @@
> > > + *
> > > + * ***** END LICENSE BLOCK ***** */
> > > +
> > > +#teams {
> > > +  -moz-column-width: 200px;
> > 
> > This is a text width right now, aka 35ex, and I think it makes much more
> > sense that way.
> > 
> What? Don't understand your point. Are you referring to replacing "200px"
> with "35ex"? 

Yes, which is what it is right now. The idea is that language names fit in one line, thus the amount of characters matter much more than pixels or visual width.

> > ::: templates/base.html
> > @@ +53,5 @@
> > > +	src: url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.eot');
> > > +	src: local({% if debug %}'{{ STATIC_URL }}fonts/MetaWebPro-Bold.woff'{% else %}'☺'{% endif %}), url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.woff') format('woff');
> > > +        font-weight: bold;
> > > +   }
> > > +   </style>
> > 
> > Should this be external?
> > 
> Apparently. It's considered unsafe to use a local font. Hence that smiley
> character. 
> The reason for the `if debug` trick in there is to use the local when doing
> development. 

I'm confused that local() would be something file-path-y or so? Also, why reference one or the other?

> > Also, who licensed MetaWebPro for whom?
> > 
> Don't know. Suggestions?

Nope, where is that text coming from? Apparently we need a license, and I don't know if we have one.

> > ::: vendor-local/lib/python/feedparser.py
> > @@ +3,5 @@
> > > +
> > > +Handles RSS 0.9x, RSS 1.0, RSS 2.0, CDF, Atom 0.3, and Atom 1.0 feeds
> > > +
> > > +Visit http://feedparser.org/ for the latest version
> > > +Visit http://feedparser.org/docs/ for the latest documentation
> > 
> > Feedparser moved to http://code.google.com/p/feedparser/, and there's a 5.1
> > now. I wouldn't mind much, if the old link wasn't dead broken.
> 
> I'm apprehensive about manually fiddling with code I installed from pypi. 
> Do you think I should just do a plain edit of those URLs and pretend it came
> like that? Let me know.

pypi has 5.1 now, with google code links.
(Assignee)

Comment 9

6 years ago
(In reply to Axel Hecht [:Pike] from comment #8)
> (In reply to Peter Bengtsson [:peterbe] from comment #6)
> 
> I'll look at the new patch again, but some answers to comment 6 right away:
> 
> > 
> > > ::: apps/homepage/static/homepage/css/teams.css
> > > @@ +35,5 @@
> > > > + *
> > > > + * ***** END LICENSE BLOCK ***** */
> > > > +
> > > > +#teams {
> > > > +  -moz-column-width: 200px;
> > > 
> > > This is a text width right now, aka 35ex, and I think it makes much more
> > > sense that way.
> > > 
> > What? Don't understand your point. Are you referring to replacing "200px"
> > with "35ex"? 
> 
> Yes, which is what it is right now. The idea is that language names fit in
> one line, thus the amount of characters matter much more than pixels or
> visual width.
>
Changed back to 35ex. 
 
> > > ::: templates/base.html
> > > @@ +53,5 @@
> > > > +	src: url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.eot');
> > > > +	src: local({% if debug %}'{{ STATIC_URL }}fonts/MetaWebPro-Bold.woff'{% else %}'☺'{% endif %}), url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.woff') format('woff');
> > > > +        font-weight: bold;
> > > > +   }
> > > > +   </style>
> > > 
> > > Should this be external?
> > > 
> > Apparently. It's considered unsafe to use a local font. Hence that smiley
> > character. 
> > The reason for the `if debug` trick in there is to use the local when doing
> > development. 
> 
> I'm confused that local() would be something file-path-y or so? Also, why
> reference one or the other?
> 
> > > Also, who licensed MetaWebPro for whom?
> > > 
> > Don't know. Suggestions?
> 
> Nope, where is that text coming from? Apparently we need a license, and I
> don't know if we have one.
> 
I'll see if Adrian (who wrote it originally) can help regarding the licensing stuff. 

Also, the reason for the local() stuff is that for production use we never want local() to work but we want it for us who can trust the code. Makes our work easier (not having to rely on the network) and our users safe. 

> > > ::: vendor-local/lib/python/feedparser.py
> > > @@ +3,5 @@
> > > > +
> > > > +Handles RSS 0.9x, RSS 1.0, RSS 2.0, CDF, Atom 0.3, and Atom 1.0 feeds
> > > > +
> > > > +Visit http://feedparser.org/ for the latest version
> > > > +Visit http://feedparser.org/docs/ for the latest documentation
> > > 
> > > Feedparser moved to http://code.google.com/p/feedparser/, and there's a 5.1
> > > now. I wouldn't mind much, if the old link wasn't dead broken.
> > 
> > I'm apprehensive about manually fiddling with code I installed from pypi. 
> > Do you think I should just do a plain edit of those URLs and pretend it came
> > like that? Let me know.
> 
> pypi has 5.1 now, with google code links.

Updated in the latest patch.
(Assignee)

Comment 10

6 years ago
Created attachment 586273 [details] [diff] [review]
latest fixes

This fixes:

* 35ex instead of 200px

* latest feedparser from google code

* a refresh_feeds [1] that a cron job can pull every hour to assure the cache is always filled with the latest feed stuff

[1] Reason for calling it pluralized "refresh_feedS" is that we might later have more functions in there that we want to refresh periodically.
Attachment #585774 - Attachment is obsolete: true
Attachment #585774 - Flags: review?(l10n)
Attachment #586273 - Flags: review?(l10n)
(In reply to Peter Bengtsson [:peterbe] from comment #9)
> I'll see if Adrian (who wrote it originally) can help regarding the
> licensing stuff. 

Well, I actually just took what we are using on mozilla.org. Just have a look at the source code of http://www.mozilla.org/ and you will find that exact same font. I have no idea what the licensing is though, I assumed we had the right to use it but I may have been wrong... Maybe someone working on mozilla.org knows better?
(Reporter)

Comment 12

6 years ago
OK, I found the local smiley thing, that's http://paulirish.com/2009/bulletproof-font-face-implementation-syntax/#smiley and keeps IE from loading the font it can't read. There should not be any DEBUG stuff in there, I think.

I'll file a seperate bug to confirm how we're supposed to use that, blocking this one.
(Reporter)

Updated

6 years ago
Depends on: 715875
(Reporter)

Comment 13

6 years ago
Comment on attachment 586273 [details] [diff] [review]
latest fixes

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

I'll cancel the review request here, as we know that there are outstanding visual regressions still.

I like the command that we have now, but I still want us to go bolder a bit on relying on it.

::: apps/homepage/views.py
@@ +99,5 @@
> +    cache_key = 'feed_items:%s' % max_count
> +    if not force_refresh:
> +        items = cache.get(cache_key, None)
> +        if items is not None:
> +            return items

I think we should force the view to only ever return the cache, or an empty list. Not sure if there's more to factor, then. Maybe it's better to move the getter and setter of the cache into a utils.py?

::: scripts/update_site.py
@@ +31,4 @@
>  NASHVEGAS_EXEC = "./manage.py upgradedb --path migrations --execute"
>  STATICFILES_COLLECT_EXEC = "./manage.py collectstatic --noinput"
>  DJANGOCOMPRESSOR_COMPRESS_EXEC = "./manage.py compress"
> +REFRESH_FEEDS_EXEC = "./manage.py refresh_feeds -v 2"

I don't think we should pipe feed items into IT's face whenever they update the site ?

::: settings/local.py-dist
@@ +46,5 @@
>  # if you want to test the Arecibo
>  #ARECIBO_SERVER_URL = "http://amckay-arecibo.khan.mozilla.org/"
>  
> +# Feed for example, to avoid having to do a HTTP call for the feed use:
> +#L10N_FEED_URL = 'file:///Users/peterbe/dev/MOZILLA/ELMO/elmo/apps/homepage/test_rss20.xml'

In comment 6 you promised some path magic that you wanted to do instead of hard-coding this?
Attachment #586273 - Flags: review?(l10n)
Created attachment 591418 [details]
Home page header one

Which header do you prefer in terms of bottom spacing, this one?
Created attachment 591419 [details]
Home page header two

or this one?
(Reporter)

Comment 16

6 years ago
(In reply to Schalk Neethling from comment #14)
> Created attachment 591418 [details]
> Home page header one
> 
> Which header do you prefer in terms of bottom spacing, this one?

I think I prefer this one.
(In reply to Axel Hecht [:Pike] from comment #16)
> (In reply to Schalk Neethling from comment #14)
> > Created attachment 591418 [details]
> > Home page header one
> > 
> > Which header do you prefer in terms of bottom spacing, this one?
> 
> I think I prefer this one.

I second Pike.
(Assignee)

Comment 18

6 years ago
(In reply to Axel Hecht [:Pike] from comment #16)
> (In reply to Schalk Neethling from comment #14)
> > Created attachment 591418 [details]
> > Home page header one
> > 
> > Which header do you prefer in terms of bottom spacing, this one?
> 
> I think I prefer this one.

Me too.
(Reporter)

Comment 19

6 years ago
Side note: for the cron job to update the planet feed, we should be good with 10, 25, 40, 55, i.e. every 15 minutes with some offset to when the l10n planet finishes.
(Reporter)

Updated

6 years ago
Blocks: 716604
(Assignee)

Updated

6 years ago
Duplicate of this bug: 721326
(Assignee)

Updated

6 years ago
Blocks: 715600
1) I love how media queries are used to hide the blog roll (on the right)
and how side-by-side blocks are reduced to be over and below each other
when you resize to a smaller window.
But the header fails quiet badly.
http://cl.ly/2J3b2v1D2k2O183b2t0f
http://cl.ly/0c2f0X3o2Z2n3P36180B

2) We have a bug in the HTML of the dashboard page. Might be unrelated to
the new design work
http://cl.ly/333y0u1R2Z2r1p341c0I

3) There's a strange whitespace indentation around "Jeff Griffiths" name.
Looked in the HTML and there's no whitespace between the ">" and "Jeff"
http://cl.ly/102H0Q2Z2T0A0o373F25

4) I thought we had agreed to use more generic solutions for exceptions.
Ie. instead of class="page-dashboard" we use class="page-wider" and put
the relevant CSS in style.css instead of dashboard.css. That way other
extreme pages can get the same love that the dashboard gets but without
having to references it as "dashboard".

5) On the teams page, whilst we're at it. Can you arrange so that the
first column in every table is fixed width so that they all line up nicely.
I guess you need to figure out which Tree name is the longest and add
some padding for the future and then make sure the rest of the table
doesn't get screwed up
http://cl.ly/303F0P0p440w1L3F3k3J
1) fixed
2) fixed
3) where is the data for this coming from?
(Reporter)

Comment 24

6 years ago
Re 5, from bug 696446 comment 10, http://cl.ly/0r2M0G2M0C3r3t1i1V0p is what we're heading for. Not sure how we'll implement that, but the section heading should be closer to a table group.
Pull request sent for issue 1 and a second pull request for issue 2 is awaiting the merge of the current pull request. 

On item three, I initial had a rule such as this:

.page-wider,
.page-dashboard {
    width: 1030px;
}

The reason was I did not want to break any other style rules that might rely on page-dashboard existing. I looked over dashboard.css and style.css and do no find any other references so, I have dropped the page-dashboard rule and I am only keeping page-wider
[:peterbe] Nothing is waiting on a merge, all commits so far are in the same pull request
[:peterbe] Sent pull request for last couple of fixes. I have more suggestions regarding the individual teams page but, perhaps we can take what there is now and push this and then continue after.
(Assignee)

Comment 28

6 years ago
Still buggy :(

When resizing, at certain widths the header just disappears into the left. 
Now both on the home page and the /privacy page
http://cl.ly/1m0j1Z3h132D0r2Y0B11
http://cl.ly/3F3f2Z0y2h1H402T3H46

Otherwise, the teams page looks great! You did a really good job there with the tables.
[:peterbe] Yeah it is a very fine line where it is at now, the reason it is pushing out on the left and then snapping back at 960px is because of the 1100px min width on the header container.

We need that because the body is specified in pixels and if the min-width is removed, we have the previous situation where, when you resize the window, the content extends past the header at times.

I will look into this though some more as well as the rewrite of the header/footer as discussed on IRC.
Two questions:

Why do we not simply hide the 'blogroll' when we reach the 960 cut off? As I ask this question I just want to also add the my latest pull request does do this and I would love some feedback.

Second thing, are we concerned about the effects of the media queries on pages such as shipping/dashboard or are those a situation where we do not foresee anyone using those pages on a small screen?
New pull request sent for remaining tweaks :: https://github.com/peterbe/elmo/pull/5
(Assignee)

Comment 32

6 years ago
Created attachment 597071 [details] [diff] [review]
Final patch

*This has all the latest and greatest fixes from Schalk. 

*It makes the tree-status and history page also "wider pages".

* The correction of "Signoff(s)" --> "Sign-off(s)" has been cherry picked in

* All tests pass

* The home page can fetch from the network if it needs to (hopefully the cron job will minimize this)

* The settings/local.py-dist suggests a way to reference a local feed fixture without hardcoding the full path

* The fonts are now properly local instead of being served from www.mozilla.org
** No more silly hacks needed for local debug development. The smiley is back!

* The update_site.py will refresh the feed but not in verbose mode.
Attachment #586273 - Attachment is obsolete: true
Attachment #597071 - Flags: review?(l10n)
(Reporter)

Comment 33

6 years ago
Comment on attachment 597071 [details] [diff] [review]
Final patch

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

This is a great step forward, awesome work you guys.

There's still a bit of stuff to figure out, see the comments below:

dashboard/tree-status/foo is having issues with the histogram and the legend. The histogram shouldn't fill the width of the content div, and the legend should float. I haven't fully figured out what is what.

I'm going for an r- for the "can't follow the wiki link", and the histogram to some extent.

::: apps/homepage/management/commands/refresh_feeds.py
@@ +36,5 @@
> +"""This managment commands runs all the functions again that pull feeds (parses
> +them and stores its results in a cache).
> +
> +Ideally this management command should be run every hour. That prevents the
> +home page view from having to block on network problems.

Change this to

Ideally this management command should run in sync with the update job on planet, but at least every hour.

?

::: apps/homepage/templates/homepage/index.html
@@ +165,5 @@
> +		<p><a href="">Sed nec lacus a turpis consequat fermentum eu eget felis. </a></p>
> +		<p><a href="">Curabitur nisi mauris, gravida volutpat ullamcorper sit amet, congue in dui. </a></p>
> +		<p><a href="">Nulla vel sapien vitae urna ullamcorper rutrum!</a></p>
> +	</section>
> +	{% endcomment %}

Remove this block? Maybe add a comment to just mention that another section could be a twitter feed.

Best way to do that is probably to just file a bug on adding that, and reference the bug in the comment.

::: apps/homepage/templates/homepage/locale-team.html
@@ +57,5 @@
> +{% endblock %}
> +
> +{% block header_content_extra %}
> +<p>Contact the team on it's page on <a href="https://wiki.mozilla.org/L10n:Teams:{{locale.code}}">wikimo</a>.</p>
> +{% endblock %}

Please move this into the main content and out of the the extra header content?

We need this to be visible, and also, it solves the click jacking problem of the div.

::: apps/homepage/templates/homepage/teams.html
@@ +58,3 @@
>  <p class="highlight"><em>Don't find your Language?</em> You may want to check the list of
>  <a href="https://wiki.mozilla.org/L10n:Teams">existing and upcoming teams</a> on our wiki, or
>  <a href="https://developer.mozilla.org/en/Create_a_new_localization">start a new localization</a>.</p>

While you're at it, can you change this to https://developer.mozilla.org/en/Localization_Quick_Start_Guide ? The other link goes straight to an MDN edit as that page doesn't exist anymore :-/

::: apps/homepage/views.py
@@ +91,5 @@
> +      'feed_items': feed_items,
> +      'locales_first_half': locales[:split],
> +      'locales_second_half': locales[split:split * 2 - 1],
> +      'locales_rest_count': locales.count() - split * 2 - 1,
> +    }

I'd prefer if we could do the locales query in one go, and just slice the resulting list.

Also, for demo setups with 3 locales, we probably don't want negative rest counts? Either fix that here or in the template to only show that link if there's more than 0?

::: apps/l10nstats/static/l10nstats/css/tree_progress.css
@@ +56,5 @@
> +
> +.legend {
> +    float: none !important;
> +    margin-top: 10px;
> +}

the float:none directly conflicts with the explicit style attr in the template,
<div class="legend" style="float:right">

::: apps/pushes/templates/pushes/pushlog.html
@@ -45,5 @@
>  <link rel="stylesheet" href="{{ STATIC_URL }}css/jquery.ui/smoothness/jquery-ui-1.8.16.custom.css" type="text/css">
>  {% endcompress %}
> -{% compress css %}
> -<link rel="stylesheet" href="{{ STATIC_URL }}pushes/css/style-gitweb.css" type="text/css">
> -{% endcompress %}

Now that we don't use that file anymore, it should be git removed, I guess.

::: apps/shipping/static/shipping/css/snippet.css
@@ +80,1 @@
>      }

hard-coding the width here sounds wrong. both that it's in px, when it's trying to align text, but also it should at least be a min-width, so that if we get an overflowing tree name, things still show.

A min-width in ex or so sounds much more like it.

::: requirements/prod.txt
@@ +10,1 @@
>  

Should we have a follow-up bug to make all of these have explicit versions?

::: settings/local.py-dist
@@ +46,5 @@
>  # if you want to test the Arecibo
>  #ARECIBO_SERVER_URL = "http://amckay-arecibo.khan.mozilla.org/"
>  
> +# Feed for example, to avoid having to do a HTTP call for the feed use:
> +#L10N_FEED_URL = 'file://' + os.path.abspath('apps/homepage/test_rss20.xml')

is that fool-proof of starting elmo in non-standard directories, if that even works? wondering if some os.path.dirname(__file__) or something to make sure we get the right basepath would be at order?

::: static/css/style.css
@@ +1,1 @@
> +/*  Reset */

Nit, I don't know how many of the rules below are actually reset, and when we actually start a non-reset stylesheet.

Of course, I don't grok css reset to begin with :-(.

@@ +163,5 @@
> +body#home > header {
> +    height: auto;
> +}
> +
> +/* new header */

Oy, header and new header? Just sayin', I bet most of this stuff is copied over from mozilla.org history.

@@ +525,5 @@
> +/* Media Queries */
> +/* Small screens */
> +@media (max-width: 960px) {
> +
> +    /* { border: 1px solid red; }*/

debug? remove.

::: templates/base.html
@@ +50,5 @@
> +    /* MetaWebPro font family licensed from fontshop.com. WOFF-FTW! */
> +    @font-face {
> +        font-family: 'MetaBold';
> +	src: url('{{ STATIC_URL }}fonts/MetaWebPro-Bold.eot');
> +	src: local('☺'), url('{{ STATIC_URL }}fonts/MetaWebPro-Bold.woff') format('woff');

sharing the font from mozilla.org didn't work after all? Cool with me, just checking.
Attachment #597071 - Flags: review?(l10n) → review-
(Assignee)

Comment 34

6 years ago
(In reply to Axel Hecht [:Pike] from comment #33)
> Comment on attachment 597071 [details] [diff] [review]
> Final patch
> 
> Review of attachment 597071 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This is a great step forward, awesome work you guys.
> 
> There's still a bit of stuff to figure out, see the comments below:
> 
> dashboard/tree-status/foo is having issues with the histogram and the
> legend. The histogram shouldn't fill the width of the content div, and the
> legend should float. I haven't fully figured out what is what.
> 
> I'm going for an r- for the "can't follow the wiki link", and the histogram
> to some extent.
> 
> ::: apps/homepage/management/commands/refresh_feeds.py
> @@ +36,5 @@
> > +"""This managment commands runs all the functions again that pull feeds (parses
> > +them and stores its results in a cache).
> > +
> > +Ideally this management command should be run every hour. That prevents the
> > +home page view from having to block on network problems.
> 
> Change this to
> 
> Ideally this management command should run in sync with the update job on
> planet, but at least every hour.
> 
> ?
Sure but I'm not sure it's clear. What is the "sync with update job on planet". That's run by someone/something else and we don't know if they update every 15min, 60min or 24 hours. 

Anyway, if we could actually find out we'll just set our cron job to the same value. Who would know?

> 
> ::: apps/homepage/templates/homepage/index.html
> @@ +165,5 @@
> > +		<p><a href="">Sed nec lacus a turpis consequat fermentum eu eget felis. </a></p>
> > +		<p><a href="">Curabitur nisi mauris, gravida volutpat ullamcorper sit amet, congue in dui. </a></p>
> > +		<p><a href="">Nulla vel sapien vitae urna ullamcorper rutrum!</a></p>
> > +	</section>
> > +	{% endcomment %}
> 
> Remove this block? Maybe add a comment to just mention that another section
> could be a twitter feed.
> 
Yanked! It was kept with optimisim of this soon becoming a feature we might support. However, the HTML that was commented out has already become obsolete. 

> Best way to do that is probably to just file a bug on adding that, and
> reference the bug in the comment.
> 
Truth is, we decided not to do it. I don't want to file a bug when it's not a bug and not something I can work on. 
Let's return to the subject some time soon in a meeting. 

 

> ::: apps/homepage/templates/homepage/locale-team.html
> @@ +57,5 @@
> > +{% endblock %}
> > +
> > +{% block header_content_extra %}
> > +<p>Contact the team on it's page on <a href="https://wiki.mozilla.org/L10n:Teams:{{locale.code}}">wikimo</a>.</p>
> > +{% endblock %}
> 
> Please move this into the main content and out of the the extra header
> content?
> 
> We need this to be visible, and also, it solves the click jacking problem of
> the div.
> 
Roger that. Moved now. I also changed the "Back to all teams" link not be a small font. 
The "click jacking problem" is long gone by the way. 

> ::: apps/homepage/templates/homepage/teams.html
> @@ +58,3 @@
> >  <p class="highlight"><em>Don't find your Language?</em> You may want to check the list of
> >  <a href="https://wiki.mozilla.org/L10n:Teams">existing and upcoming teams</a> on our wiki, or
> >  <a href="https://developer.mozilla.org/en/Create_a_new_localization">start a new localization</a>.</p>
> 
> While you're at it, can you change this to
> https://developer.mozilla.org/en/Localization_Quick_Start_Guide ? The other
> link goes straight to an MDN edit as that page doesn't exist anymore :-/
> 
Fixed.

> ::: apps/homepage/views.py
> @@ +91,5 @@
> > +      'feed_items': feed_items,
> > +      'locales_first_half': locales[:split],
> > +      'locales_second_half': locales[split:split * 2 - 1],
> > +      'locales_rest_count': locales.count() - split * 2 - 1,
> > +    }
> 
> I'd prefer if we could do the locales query in one go, and just slice the
> resulting list.
> 
You're right! Being aware that our mysql isn't local helps. 
I managed to reduce it to some python list magic and thus 3 db queries is now only 1. 

Also, to back up my claim I moved it into its own function and added a unit test for it. 

> Also, for demo setups with 3 locales, we probably don't want negative rest
> counts? Either fix that here or in the template to only show that link if
> there's more than 0?

I made the above mentioned function "smart" so it'll reduce the default split if there's too few locales. I don't think we should worry about the rare cases when there's only like 1 locale. If it does become a real problem we can deal with it then. 

> 
> ::: apps/l10nstats/static/l10nstats/css/tree_progress.css
> @@ +56,5 @@
> > +
> > +.legend {
> > +    float: none !important;
> > +    margin-top: 10px;
> > +}
> 
> the float:none directly conflicts with the explicit style attr in the
> template,
> <div class="legend" style="float:right">
> 
:(
I blame myself for throwing Schalk into the deep end. 

I think Schalk got confused, in the beginning about what he could edit and tried to do it all by CSS.

As per our IRC discussion I've now fixed the legend. 


> ::: apps/pushes/templates/pushes/pushlog.html
> @@ -45,5 @@
> >  <link rel="stylesheet" href="{{ STATIC_URL }}css/jquery.ui/smoothness/jquery-ui-1.8.16.custom.css" type="text/css">
> >  {% endcompress %}
> > -{% compress css %}
> > -<link rel="stylesheet" href="{{ STATIC_URL }}pushes/css/style-gitweb.css" type="text/css">
> > -{% endcompress %}
> 
> Now that we don't use that file anymore, it should be git removed, I guess.
> 
Removed. 

> ::: apps/shipping/static/shipping/css/snippet.css
> @@ +80,1 @@
> >      }
> 
> hard-coding the width here sounds wrong. both that it's in px, when it's
> trying to align text, but also it should at least be a min-width, so that if
> we get an overflowing tree name, things still show.
> 
min-width does sound like a much better idea. That keeps things more fluid and yet achieves the alignment across tables (ie. across applications)

> A min-width in ex or so sounds much more like it.
> 
Why would "ex" be better than "px"? Isn't ex relative and px absolute? And isn't absolute something we want?

With "min-width:145px" I increased the font (like a sight impaired user would) and it "scales up" very nicely in Aurora. 

> ::: requirements/prod.txt
> @@ +10,1 @@
> >  
> 
> Should we have a follow-up bug to make all of these have explicit versions?
> 
The requirements/prod.txt is quite stupid. Nothing in that least isn't already in the vendor or vendor-local which is even more accurate than explicit version numbers in terms of predictable versions.

What we should do is nail requirements/compiled.txt but I don't feel like rushing it right now since things are working just fine. 

> ::: settings/local.py-dist
> @@ +46,5 @@
> >  # if you want to test the Arecibo
> >  #ARECIBO_SERVER_URL = "http://amckay-arecibo.khan.mozilla.org/"
> >  
> > +# Feed for example, to avoid having to do a HTTP call for the feed use:
> > +#L10N_FEED_URL = 'file://' + os.path.abspath('apps/homepage/test_rss20.xml')
> 
> is that fool-proof of starting elmo in non-standard directories, if that
> even works? wondering if some os.path.dirname(__file__) or something to make
> sure we get the right basepath would be at order?
> 
Yes I think so since it's calculated from the manage.py parent directory. 

> ::: static/css/style.css
> @@ +1,1 @@
> > +/*  Reset */
> 
> Nit, I don't know how many of the rules below are actually reset, and when
> we actually start a non-reset stylesheet.
> 
> Of course, I don't grok css reset to begin with :-(.
>
Good point. That looked like a "section header" and it was only really a comment for the next two selectors. I simply removed it now. 
 
> @@ +163,5 @@
> > +body#home > header {
> > +    height: auto;
> > +}
> > +
> > +/* new header */
> 
> Oy, header and new header? Just sayin', I bet most of this stuff is copied
> over from mozilla.org history.
> 
Fixed.

> @@ +525,5 @@
> > +/* Media Queries */
> > +/* Small screens */
> > +@media (max-width: 960px) {
> > +
> > +    /* { border: 1px solid red; }*/
> 
> debug? remove.
> 
Fixed.

> ::: templates/base.html
> @@ +50,5 @@
> > +    /* MetaWebPro font family licensed from fontshop.com. WOFF-FTW! */
> > +    @font-face {
> > +        font-family: 'MetaBold';
> > +	src: url('{{ STATIC_URL }}fonts/MetaWebPro-Bold.eot');
> > +	src: local('☺'), url('{{ STATIC_URL }}fonts/MetaWebPro-Bold.woff') format('woff');
> 
> sharing the font from mozilla.org didn't work after all? Cool with me, just
> checking.

That's what I got from Adrian and I assumed it was meant to be like that. Then, when I compared with www.mozilla.org/firefox I obviously got misled because that it actually on mozilla.org.
(Assignee)

Comment 35

6 years ago
Created attachment 597885 [details] [diff] [review]
final patch with latest fixes
Attachment #597071 - Attachment is obsolete: true
Attachment #597885 - Flags: review?(l10n)
(Reporter)

Comment 36

6 years ago
Comment on attachment 597885 [details] [diff] [review]
final patch with latest fixes

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

r=me with the nits below. Nice job, thanks a ton.

::: apps/l10nstats/static/l10nstats/css/tree_progress.css
@@ +56,5 @@
> +    background-color: #E6E6E6; 
> +}
> +.my-timeplot { 
> +    height: 350px; 
> +}

I don't really know why, but this is not the same as the style attribute on the node. This makes the graph less tall, can you undo that?

@@ +65,5 @@
> +#histogram {
> +    margin-bottom: 20px;
> +    height: auto !important;
> +    clear: right;
> +}

We should also add a 

#histogram table {
    width: auto;
}

to overwrite the table:100% default that we added somewhere else.

No idea why the height: auto !important; is there, but that's all my fault.

::: apps/l10nstats/templates/l10nstats/tree_progress.html
@@ -86,4 @@
>  {% block content %}
> -<h1>Statistics for {{ tree }}</h1>
> -<p>String completeness for {{ tree }} localizations over time.</p>
> -<div id="my-timeplot" style="height: 350px;"></div>

... pairs the undo

::: settings/base.py
@@ +177,5 @@
> +L10N_FEED_URL = 'http://planet.mozilla.org/l10n/atom.xml'
> +HOMEPAGE_FEED_SIZE = 5
> +
> +## Number of locales to "preview" on the home page
> +HOMEPAGE_LOCALES_LIMIT = 12

I think it's cool to have that in a variable, but I really don't think we need to have this in settings. Having a variable in the view that one can monkey patch if absolutely needed is good enough.
Attachment #597885 - Flags: review?(l10n) → review+
(Reporter)

Comment 37

6 years ago
Seriously. Adjusting summary.
Summary: improve homepage, baby step one → improve homepage, leap for mankind
(Reporter)

Updated

6 years ago
Assignee: nobody → peterbe
Target Milestone: --- → 2.1
You need to log in before you can comment on or make changes to this bug.