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

[David Read]

Lauren,

Hooray, the CKAN forms are becoming a lot more pluggable and
customisable! Before this is released for all to try, I'm going to
take your PiratePad and turn it into a form, as best I can following
your descriptions.

You also mentioned having specific options in drop-downs. Could you
update the PiratePad to list these options in full please?

David

On 9 March 2010 23:17, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> 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
>
> _______________________________________________
> ckan-discuss mailing list
> ckan-discuss at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-discuss
>