Problem/Motivation

The 1.x branch allows users to create Highchart Views displays, but only with a limited number of chart types and options.

The 2.x branch currently suffers from the same issue, because it was a direct port from 1.x.

Proposed resolution

Make every option from the Highcharts library options reference available for configuration in the Views UI.

Remaining tasks

There are several problems to address:

  1. Get a complete list of all options
    The Highcharts API reference website is currently built manually (for the most part by concatenating several smaller files). Highsoft has a project in development that will supply a programmatic interface to the options - this is not ready for public view yet however. Until it is, the undesirable (but only) way to get this definition is to parse the documentation. Current status is there is a working version of this that could be committed soon.
  2. Avoid a UX nightmare in the Views UI
    The first attempt I made at this worked well functionally, but was (as expected) an impossibly annoying UI. I added a fieldset called "advanced settings" which contained a nested tree of options represented as input fields within collapsible fieldsets (collapsed because the nested tree of options is immense).
    However, when collapsed, it was not easy to find the options again. We could solve this by adding a summary of current settings above the tree of collapsed fieldsets, but it is still cumbersome to drill down to add or adjust existing settings. Another solution I'm working on now is to only add options as needed with AHAH. Other suggestions are welcome!
  3. Highcharts options templates
    The 1.x branch was problematic in part because options were loaded from JSON, but not all of the option elements were overridable (and even if they were, the need to override each option is something we do not want - see description of this problem in #1507800: Views-independent Highcharts API). However, one nice thing about this was that non-developers could create (a limited set of) chart types from a simple list (and then configure limited overrides to those). It would be nice to keep some version of this feature.
    One way to do this could be to add a hook for defining "chart templates". The Highchart views module could include some basic templates (which could still be based on the Highcharts demo gallery examples), and other modules could add their own templates through the hook. All templates could then be overridden with selected options (described above in #1), or advanced users could select 'no template' and set all options under advanced settings themselves.
  4. Mapping Views fields to options
    If we want to allow the full use (or even a slightly fuller use) of the Highcharts library options, then the mapping options will get complex fast (consider chart combinations). We may want to expect each module implementing the chart template hook to handle these mappings, and provide a description for site builders about how their field data will be used. Other suggestions for this are definitely welcome!
    Update: This functionality has been added to Views 8.x & 7.x #1765824: Provide a way to map views fields to a certain meaning. We will now only need to implement that for this task.

User interface changes

The Views UI options configurations will necessarily be completely different to accomodate full use of the library options.

Comments

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented

For #3 in the remaining tasks above, added a hook allowing modules to add highcharts options templates. Part of 84f4128

@todo add some templates packaged with the highcharts_views module (a replacement of the JSON defaults, which can add more functionality).

nkLiVF’s picture

nkLiVF commented

1. Get a complete list of all options
I'm assuming that this is a problem of documentation. Is it a problem to just point users to the highchart ref page for possible options until highsoft produces a better solution?

http://www.highcharts.com/ref/

2. Avoid a UX nightmare in the Views UI
There doesn't seem to be an easily solvable problem since highcharts has so many options. If there is some redundancy among options then there might be any better way to organize, but not sure if this is possible. If we had a documentation (problem 1 above) that showed all options on a page (similar to the options website but with all collapsible elements expended) you could do a simple text search to find the option you might have misplaced. To that end a complete tree of collapsible configurable options might be the only real solution. Of course a open text field where users could input their own inputs (lots of #option => value) might work but might be less usable (though this might be the only workable solution). Your templates idea w/ overrides might be a better solution though (but seems like you would need a text box to accept the advanced options).

Highcharts options templates
The templates idea sounds reasonable, but I'm not sure enough about how it would work to really comment on it.

Mapping Views fields to options
Selecting the field display from 'views' is the easy part. Associating it with the chart option might be harder, but again you might just need a text field which selects the option. A selectable tree of options could also work (maybe similar to how the 'context' module does things (selecting a node/view and then selecting 'add' to add it to a block).

Sorry, maybe I can be of more help if I look at the source longer.

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented

@nkLiVF

  1. No the point is, in order to programmatically generate the options as form elements for users to select, we need a reliable list of those options. Currently one does not exist - from discussion with Highsoft developers, this may happen at some point, but until then parsing the documentation is the best we can do. So far I've been rolling with that, but have not committed this until there is a solution for the next problem (the UI)
  2. I addressed all of this above - really the only solution that seems close to reasonable is selectively adding options from a pre-defined list, and not rendering form elements for every possible option (it's just too huge, weird, and hard to use that way).
  3. This has basically started, with highcharts.options.inc
  4. See #1765824: Provide a way to map views fields to a certain meaning. When implementing this - by associating data from Views fields with chart options - we'll still need to find a way to pass that data along in the different ways that different chart templates will expect. For example one chart may want to pass each row of Views field data through the chart data array (one row per series), while another chart would want the total from each field to be their own series, and then some fields have multiple values. I'm not sure there's a realistic way for the UI to cover all possible use cases, but we can probably add some sensible settings with a way to let other modules add new ones for additional use cases.
scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented
Title: Allow full use of Highcharts library Options » Allow full use of Highcharts library Options in Views

Clarifying title, even though the component is set to "Views integration". The highcharts.module API already supports full use of the Highcharts library options.

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented

Work on this is underway. See commits: 9979cbd through 8522ea5, which address points 1-3 above (point 2 does not yet implement the ajax per desired options, and loads the enture form for now). We still need to address point 4. Coming soon.

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented
Assigned: Unassigned » scottrigby

Updates:

  1. This is committed in highcharts.reference.inc, with work towards 2.
  2. I ran into some grief working on the 'add an option' Views ajax method, so that still needs work. However, I went ahead and committed a less than ideal nested options form under the Highcharts style plugin settings 'advanced settings', so it needs love but does generally work (this will be changing, so it's only for people who want to test it at this point)
  3. highcharts_views.module now has working example option templates in highcharts_views.options.inc. These can also add their own settings forms to the style plugin settings - see ViewsHighchartsOptionsPieBasic.
  4. I don't think views_plugin_style_mapping is going to work for us afterall, because we want different field mapping options depending on the selected template. We can already do this per template now that we have a working example for 3. We may add a similar shortcut for developers, but that would have to be a follow up issue.

This issue probably needs to be broken out into remaining subtasks at this point, since it's roughly finished.

boabjohn’s picture

boabjohn commented

Hey there Scott,
Really appreciate the module and also your careful approach to development.
Integrating anything with Views can be a mountainous task, so that's understandable why this process is still trickling along a year+ later...
If you have a moment, though, it could be *really useful* to document the one or two simple usecases that can work with views right now, assuming there is one?
I've got a very simple two field view using a page display, and there seems to be no way to get the HighCharts display options to open...it just returns and AJAX error complaining about piecharts:
Notice: Undefined index: ViewsHighchartsOptionsPieBasic in ViewsHighchartsOptions->__construct() (line 44 of /home/cadb/htdocs/drupal/sites/all/modules/highcharts/views/highcharts_views.options.inc).
I'd give you more of an issue report on a new task, but thought is was more relevant to ask the big-picture question first on this thread.
Thanks again for your efforts,
JB

boabjohn’s picture

boabjohn commented

Hey there Scott,
Really appreciate the module and also your careful approach to development.
Integrating anything with Views can be a mountainous task, so that's understandable why this process is still trickling along a year+ later...
If you have a moment, though, it could be *really useful* to document the one or two simple usecases that can work with views right now, assuming there is one?
I've got a very simple two field view using a page display, and there seems to be no way to get the HighCharts display options to open...it just returns and AJAX error complaining about piecharts:
Notice: Undefined index: ViewsHighchartsOptionsPieBasic in ViewsHighchartsOptions->__construct() (line 44 of /home/cadb/htdocs/drupal/sites/all/modules/highcharts/views/highcharts_views.options.inc).
I'd give you more of an issue report on a new task, but thought is was more relevant to ask the big-picture question first on this thread.
Thanks again for your efforts,
JB

boabjohn’s picture

boabjohn commented
Issue summary: View changes

update remaining tasks with new Views functionality