[ckan-discuss] Suggestions & questions re: "add a new package" screen

[Rufus Pollock]

On 9 March 2010 20:11, Lauren Bacon <lauren at raisedeyebrow.com> wrote:
> Hello all,
>
> David & I have been talking about how to make the "Add a New Package" screen
> more user-friendly, and we have some ideas that we thought might be worth
> sharing with the list. I don't have a clear sense of how much work would be
> involved in implementing these changes, and I'd love to hear feedback on
> that front; I'm a designer, not a developer, so please be gentle with me.

Designers are what we need :)

> In general, I feel like this screen could benefit from a structure that
> displays both a description for each field, and an example of the content
> that belongs in each field. I've put together a rough outline in this
> PiratePad:
> http://piratepad.net/2C2iwiLDhd

Completely agree. We know the CKAN editing interface could do with
some UX work here. We scheduled some of this around Christmas/New Year
and while much of the "read" work got done we didn't properly get into
the "write" area (e.g. [1]) so these suggestions are much appreciated.

[1]: http://knowledgeforge.net/ckan/trac/ticket/221

> This brainstorm led to a few questions:
> 1. How would we go about adding descriptions & examples to the form? Is this
> simply a styling/theming thing, or would it require deeper customization?It

I think this is essential to make the form more usable. Doing this is
not complex -- the only complication is that we are auto-generating
the forms using a library rather than having them written in HTML.
However, at least for all the description/example snippets there would
be no problem having these prepared in html/css (we could have a whole
mock form) as they could be auto-integrated without great problem.

> would be incredibly helpful to be able to have these fields as drop-down
> menus, to reduce the margin of error. No idea how easy/complex that would be
> to do.]

I think this is also nice but probably a second stage issue. Again I
don't think this hard but I think we would like to put a bit of
thought into doing this in an extensible way so it is easy to
change/extend in future.

> 2. Is it possible to add a default 'http://' to the URL & Resources fields?
> Seems like it might reduce error & make data entry a bit quicker to boot.

Would this be put in the field or added on save? Either way the
backend has to do a bit of work (either to figure out that you have
not in fact entered a value or to add http://)

> 3. What belongs in the 'Hash' field? Can anyone suggest a description &
> example for that one?

This is for "hashes" of the resource (basically a compressed check on
the resource content). For more see:
http://wiki.okfn.org/ckan/doc/guide/#PackageResources

> 4. In addition to David's question about customizing the list of licenses
> for the Canadian context (see below), there are some other fields that could
> benefit from having either an autocomplete function or a drop-down menu
> rather than free text; I'm certain these approaches would improve
> consistency and diminish spelling errors, etc.. For example, the Author &
> Maintainer fields are great candidates for autocomplete.

Autocomplete from an existing list do you mean?

> 5. We're also looking at using the Extras fields for Canada-/specific
> purposes. If possible, we'd love a couple of drop-down menus in there, too.
> Guessing that's out of the question?

I don't think so. This comes to the whole extensible/pluggable forms
things we've been thinking about for awhile. Basically I think what we
want is a simple way to provide ckan form specifications (so you can
say: by default use this form setup instead of this one).

The simplest way to do this would be in code by just extending our
existing forms work. If you were willing to get your hands dirty with
a small bit of python this isn't that hard to do :) -- something like:

our_fieldset.append(ExtraField('precision').with_renderer(ExtraTextRenderer))

(for more elaborate example see
http://knowledgeforge.net/ckan/hg/file/tip/ckan/forms/package_gov.py)

If this is offputting we could put something together that was even
simpler and allowed you to specify the forms in a simple config file
(but I'm dubious of the mileage of this over straight python in the
long run).

(BTW if you're wondering why can't we just do plain ol' html forms the
answer is that this setup gives us things like automatic generation
and population of the form, error handling and display etc etc)

Rufus