[ckan-dev] CKAN and JavaScript

[Rufus Pollock]

On 29 May 2012 15:44, Aron Carroll <aron.carroll at okfn.org> wrote:
> Hi all,
>
> I've been asked to summarise the general approach to using JavaScript on CKAN
> moving forward.
>
> As CKAN is a website designed to enable users to find and explore datasets
> and can be deployed in a wide variety of environments it's very important that
> the site is usable by as broad an audience as possible.
>
> So all key features of the site should be implemented and work without
> JavaScript. This provides the following benefits.

I don't especially get this and would like to understand more. So many
sites today require  significant amounts of javascript. While I
*completely* agree that basic view functionality (browse and view)
should work w/o JS (in at least a basic way) for much else I just
don't see this (and even quite a bit of sophisticated read
functionality comes from JS). It seems to me that in this day and age
to provide much of responsive UX users expect requires significant JS.

> * The site content is indexable and searchable via search engines like Google.

This only requires that browse and view dataset functionality . Almost
all the JS would be elsewhere - either in editing or in visualization
or in e.g. rich search (not needed by search engines)

> * Content is accessible to screen readers and other assistive technology.

I really don't think this is a priority given that our focus is data
-- i'm not saying I don't care but just that is probably a lower
priority.

> * The site functions for users without JavaScript enabled, while the scripts load or
>  if an error occurs breaking the app.
> * Keeping JavaScript to a minimum reduces load times and keeps page weight
>  down.

Again this is a really a minimal advantage and we can optimise in other ways.

> It also keeps majority of the application in Python which is the primary language
> of the CKAN team and reduces the maintenance cost of having large portions of
> application logic in two places.

We wouldn't have application logic in two places - we would move to
having a significant portion of e.g. editing and dataset viz in pure
JS.

Furthermore, the existing skillset of the team should not determine
this decision too much going forward. If we think going a more JS
route is the right way for UX, functionality and technological reasons
we should do it and do the necessary skilling up.

> This means adding using HTML forms that submit to CKAN rather than directly to
> the API. Providing error messages in the HTML source and ensuring all content
> is included in the html source on page load. JavaScript can then be used to make
> features richer and enhance the experience.

Does this not also bulk out the page in a big page potentially and
creates a lot of constraints on what can be implemented?

> Some features such as the data previewer are going to require JavaScript. Others
> are more complicated, for example the search facets. Ideally these would provide
> the same functionality with or without JavaScript but there is an argument that
> they provide auxiliary functionality as long as the basic form works on it's own.
> These should be evaluated and discussed on a feature by feature basis.

Agreed.

Rufus