jmduke / reallyeasycharts Goto Github PK

re: http://www.reddit.com/r/SideProject/comments/1odlmv/really_easy_charts_make_simple_pretty_graphs/

Spitballing, but three graphs appearing below the form. Click them and they appear on the main output (plus the form gets filled in with the data). Should be simple to implement.

In particular, this is tricky with dropdowns (where selecting one doesn't automatically update) and to detect when no change has been made and not to redraw.

No, seriously, I spend a non-negligible amount of type doing manual testing and adding a test.js suite would be pretty dope.

Looks like this could be the ticket, at least to start: http://qunitjs.com/intro/

Currently using parseInt instead of something that can handle, you know, non-integer numbers.

Shouldn't be too tough. This should also probably include some general refactoring for i18n support, like moving the labels into an external script and grouping them by language code.

Thinking:

• EN
• IT
• FR
• DE
• JP

Thoughts in a tiny nutshell: Base64 representation of the graph object:

reallyeasycharts.com/#A7HstTL9

This would be dope.

Yeah, I guess series labeling could be important.

If shrinking the width of my browser is any indication, this thing looks awful on mobile. Ideally, this would be paired with a general overhaul of the way CSS is being handled for some good ol'-fashioned responsive design. (The HTML is relatively semantic given how minimal it is, so this shouldn't be too bad.)

The current generation schema is just, ugh, gross. It could be a lot better, and I'll experiment with this more at some point.

Just make it look snazzier, you know? Something to keep on the backburner until I find some nice inspiration.

Neither locally nor on reallyeasycharts.com. That's not so good.

Re: http://www.reddit.com/r/design_critiques/comments/1odmrx/webapp_created_a_small_project_this_weekend/ccr3ctw

I imagine there are use cases that the auto-generation on .change() isn't quite perfect. Either way, there shouldn't be an issue with having a manual button to generate the graph in addition to the current functionality.

I think this was because I renamed some of the globals. I'll take a look at this this evening.

per http://www.reddit.com/r/visualization/comments/1obt60/hey_rvisualization_i_spent_the_past_few_days/ccr1gif

A better colorpicker would be infinitely better than the current hard-coded 'flavors'. Using a jQuery plugin to get the user to select a given hexcode, then grabbing complementary/alpha colors based on that.

Currently it's something of a shitshow: hardcode in the charttype and fill in a string template with the name + id of the attribute for everything else. This can be done better, but that involves actual effort.

Advantages: way, way cleaner, and we could bypass using bit.ly altogether except for expansion/shortening.

Disadvantages: an extra call to bit.ly. Since we're sending a call to them anyway for encoding, this doesn't seem like a particularly big deal.

As evidenced here:

j.mp/1bRCHNA

The issue stems from the fact that we use the graph object to hold the form data at first, and then transform and munge it. The straightforward solution would be to keep track of two separate objects: formData and graph or something similar, where the keys are the same but one is the faithful version of the form data and the other is all gross.