Repository: gratipay/gratipay.com

Issue:
per-user charts are scrunched
After #1711 the per-user charts are scrunched:

![screen shot 2013-12-04 at 9 59 26 am](https://f.cloud.github.com/assets/134455/1674158/e39f7760-5cf4-11e3-86e2-5019fde7231d.png)

cc: @dominic @seanlinsley 

fake_data paydays should include transfers
We have paydays with `make data`, but we don't have any transfers. We need transfers to see the user charts in dev (cf. #1717).

Charts are too wide in mobile browsers
<img width="33%" src="https://f.cloud.github.com/assets/688886/1649646/413a1054-5a18-11e3-8acb-2d1d5da19d72.png"> <img width="33%" src="https://f.cloud.github.com/assets/688886/1649647/413b9956-5a18-11e3-87c7-582ef4525553.png"> <img width="33%" src="https://f.cloud.github.com/assets/688886/1649655/efdc9cbc-5a18-11e3-81a3-9fab62fd0be7.png">



Discussion:
Taking out the `max-width: 50%` fixes the problem for me locally. @dominic what did that line accomplish in your PR?

It keeps the graphs from breaking out of their boundaries on the two column charts page. 

My bad :( I didn't have user graphs on my local copy. Putting max-width: 100% on charts inside col0, col1, and col2 would fix this, I believe. 

@dominic My fault for merging without testing more fully, sorry. :-/

Anyway, should be easy to fix once we have some data in there to see the charts. :-)

We have fake payday data for the overall charts, I've opened #1719 to provide user chart data in dev.

Currently working on this.

Taking this alongside #1717

Our charting JS is setting a lot of explicit widths because it's trying to make some clever calculations about how wide to make the graph for `n` weeks. It's currently calculating charts of 390px within the 480px container to generate an even width:

![screen shot 2013-12-02 at 8 02 06 pm](https://f.cloud.github.com/assets/185645/1661040/f1fb0caa-5bcf-11e3-843d-8bd6f20cc690.png)

Has there been any thought given to capping the number of weeks we're showing on the graph? We're currently standing at 78 weeks. What about limiting it to 52 weeks? That gives us a solid 5-6px to work at the smallest width of 320px, and lets us scale up to much larger hover targets on bigger screens.


Resolving patch:
diff --git a/gittip/utils/fake_data.py b/gittip/utils/fake_data.py
--- a/gittip/utils/fake_data.py
+++ b/gittip/utils/fake_data.py
@@ -51,6 +51,12 @@ def fake_int_id(nmax=2 ** 31 -1):
     return random.randint(0, nmax)
 
 
+def fake_sentence(start=1, stop=100):
+    """Create a sentence of random length.
+    """
+    return faker.sentence(random.randrange(start,stop))
+
+
 def fake_participant(db, number="singular", is_admin=False, anonymous=False):
     """Create a fake User.
     """
@@ -60,7 +66,7 @@ def fake_participant(db, number="singular", is_admin=False, anonymous=False):
                , id=fake_int_id()
                , username=username
                , username_lower=username.lower()
-               , statement=faker.sentence()
+               , statement=fake_sentence()
                , ctime=faker.dateTimeThisYear()
                , is_admin=is_admin
                , balance=fake_balance()
@@ -148,7 +154,7 @@ def fake_transfer(db, tipper, tippee):
                 )
 
 
-def populate_db(db, num_participants=300, num_tips=200, num_teams=5, num_transfers=300):
+def populate_db(db, num_participants=100, num_tips=200, num_teams=5, num_transfers=5000):
     """Populate DB with fake data.
     """
     #Make the participants
@@ -180,7 +186,7 @@ def populate_db(db, num_participants=300, num_tips=200, num_teams=5, num_transfe
 
     #Make the transfers
     transfers = []
-    for i in xrange(num_tips):
+    for i in xrange(num_transfers):
         tipper, tippee = random.sample(participants, 2)
         transfers.append(fake_transfer(db, tipper, tippee))
 


Test patch: