[openspending-dev] OpenSpendingJS structure and going forward

Sun May 25 20:44:02 UTC 2014

On sun 25.maí 2014 20:19, Tryggvi Björgvinsson wrote:
> So, basically we have:
>
>   * |src/utils| - common core code

I wouldn't call this "core" code. These are utils that can be used by
the visualisations. For example, formatting amounts, color palettes etc.
and also the code that wraps the OpenSpending aggregation API (which is
probably why you refer to this as "core").

>   * |src/visualisations| - visualisations
>
> Sort of deprecated:
>
>   * |lib| Common core code such as JS that wraps the OpenSpending API
>   * |app| - various viz / apps (see below)

Yes these are *on their way* to become deprecated. These cannot be
deprecated just yet since they are still needed for the OpenSpending
core platform. We have to remove that specific dependency. It is very
weird to have in the same place the visualisation code for external
sites and then the javascript code needed to make OpenSpending core
work. It's doing too many things.

We need to get the javascript for OpenSpending core out of this library
and into OpenSpending core and leave this library for visualisations.

> apps:
>
> |bob  # the query builder (?)

OpenSpending core functionality

> browser # data browser (?)

OpenSpending core functionality.
When https://github.com/openspending/openspending/issues/797 has been
fixed in OpenSpending core, we can remove this functionality as it will
no longer be used.

> bubblemap # bubblemap viz

I think this is needed for bob

> dailybread # dailybread viz

Dailybread can be removed

> data_table # data_table browser

I think this is needed for bob

> dimensions-editor # dimensions editor (OS import process) (cf http://nickstenning.github.io/openspending.modeleditor/)

OpenSpending core functionality.

> faceter # not sure 

I think this is used with the Browser in OpenSpending core and can be
removed when we fix issues 797 (above).

> spending-map # not sure but maybe the front page map on OS.org

Yes, this is the map on the front page so OpenSpending core funcationality.

> treetable # not sure ...

I don't think this is used in OpenSpending core.

>     The Future
>
> Here's a proposal for discussion:
>
>   * Core JS library (no visualizations) lives in openspending.js (could
>     keep openspendingjs name but rename might be useful to symbolize change)
>   * Every visualization gets its own separate repo named e.g.
>     |openspending.{vizname}.js|

I don't agree. I think we should keep them in OpenSpendingJS. We are now
doing releases of OpenSpendingJS (we're up to version 0.4.0) which allow
everyone to very easily add OpenSpendingJS visualisations to their sites.

The only thing needed is to add the javascript and the css file to the
page and then you can get the OpenSpending treemap on your page with
something like this:

<div class="treemap" data-dataset="my-dataset-id"
drilldowns="cofog1,cofog2,cofog3" year="2014"></div>

(you could also instantiate it with a javascript call:

$('jquery-selector').treemap({data: {dataset:'my-dataset-id',
drilldowns:['cofog1', 'cofog2', 'cofog3'], year: 2014} });

> Lastly some process points:
>
>   * We should complete clean-up of this repo asap (possibly in tandem
>     with doing the split-out)

Agreed. We need to get OpenSpending core components out and into
OpenSpending core, preferably by making bob the builder use the most
recent release of OpenSpendingJS and benefit from the simple
javascript/jquery calls, but anything works now.

>   * Anyone can develop a new viz but for it to live in openspending
>     orgnanization it needs to "approved" (i.e. checked for quality,
>     documentation, and that there is an ongoing maintainer).

Yes, but that shouldn't be made harder than making a pull request as it
is now.

>   * We document the set of visualizations people can use off-the-shelf
>     somewhere prominent

We already have a ticket for this thanks to Michael:
https://github.com/openspending/openspendingjs/issues/62

>       Why?
>
>   * Core code is more clearly demarcated from apps/viz and can be
>     maintained more easily going forward. It also can become a core
>     dependency that people can more easily use in their own work without
>     getting caught up in viz stuff

I think I might be misunderstanding what you mean by core code. What do
you feel the core code should be?

>   * By splitting out visualizations we make them easier to work on and
>     more clearly distinct. Dependencies are also clearer etc.

Why? I think this would make everything even more difficult to work
with. I would actually rather want us to trim down the repos in our
github organisation instead of spreading thin over a lot of them.

I would love to hear other people's thoughts on this. Where would you
like to see OpenSpendingJS go?

-- 

Tryggvi Björgvinsson

Technical Lead, OpenSpending

The Open Knowledge Foundation <http://okfn.org>

/Empowering through Open Knowledge/

http://okfn.org/ | @okfn <http://twitter.com/OKFN> | OKF on Facebook
<https://facebook.com/OKFNetwork> | Blog <http://blog.okfn.org/> |
Newsletter <http://okfn.org/about/newsletter>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openspending-dev/attachments/20140525/452eb8a7/attachment-0002.html>