[ckan-dev] How to display more information on a resource?

Wed Jan 19 09:37:45 UTC 2011

On 18 January 2011 22:24, David Raznick <kindly at gmail.com> wrote:
>
>
> On Tue, Jan 18, 2011 at 10:33 AM, David Read <david.read at okfn.org> wrote:
>>
>> David,
>>
>> You're could say that you're designing the 'default' or 'most
>> flexible' package display template and edit form. This is what's
>> currently used for ckan.net, for people to play with what fields they
>> need.
>>
>> As people start to have a strong idea what fields they want - such as
>> the http://ckan.net/group/lodcloud people - then we should think about
>> customising their display template and edit form for their packages.
>> So don't worry about displaying or editing for this case - we can do
>> custom work for complicated cases.
>>
>> So, back to the default case.
>
>
> Do we have any ideas about exactly what extra fields we require for the
> default case?

Actually we don't require anything - the whole point is it is a
flexible wiki for people to try things we've not thought of!

>>
>> You've seen that it's difficult to give
>> people both the flexibility and handle the UI wonderfully for few and
>> many fields. I suggest you focus on handling up to say a dozen
>> columns. And if people really want more then we'll sort out the UI
>> when/if it happens.
>>
>> *Displaying* a package: how about making all the table columns thin
>> enough to display them all, truncating cells rather than
>> wrapping/scrolling them, and provide the full value on mouseover? Even
>> if you only see the first few characters, then you have a good idea of
>> the value. The description field has become a bit of a dumping ground
>> for other data, so you could perhaps make all columns the equal width.
>
> I am not too worried about displaying.  I think a little icon for
> information (an i) that when you hover over will display the extra fields
> would be best, especially if we are going to do a magnifying glass for a
> preview at some point.  However it would not be too difficult to try a few
> things out.

I don't think so - these fields should not be second class or they'll
never get used. They should be just as prominent as the existing
fields.

>> *Editing* a package: a table with a scrollbar with a button to add
>> more fields seems fine to me. Editors will use the scroll bar in their
>> hunt for the values they want to change, having seen what values are
>> there when the package is displayed / previewed.
>
> I am tempted to just go for a wide table and see what it looks like and then
> have a scroll bar if its too wide and hope that there wont be too many extra
> fields.  As this is just for the default instance I am not as worried.

Agreed

>> Team members like James are v. quick on the JQuery, so do ask if you
>> want someone to help. The hard part of this is probably the model
>> code.
>
> I think I will start with the model code anyway and then see what it looks
> like afterwards.
>
> Do you think it would be acceptable to just have an extra json field on the
> resource table?  This is instead of a whole 2 new tables
> (package_resource_extra and package_resource_extra_revision).  Package_extra
> and group_extra currently have a json field type in them anyway. The only
> thing we would be loosing is the possibility of repeating keys. It would
> make it a lot simpler.

Agreed, I can't see a need for repeating keys either. As it says in
the ticket we should implement this in the same way as PackageExtra,
unless there is good reason.

> Also do we want any bona-fide new fields for the resource table for
> everyone? i.e alternative_url is a good candidate.

This should be in a separate ticket. The DGU ones mentioned probably
have higher priority.

Cheers,
David

>
>>
>> David
>
> Thanks for you help.
>>
>> On 17 January 2011 20:58, David Raznick <kindly at gmail.com> wrote:
>> > Hello
>> >
>> > I have been looking at ticket 862 .  Technically it should not be too
>> > difficult if we go down the same route as "package extras" and "group
>> > extras" which have extra key value pairs.
>> >
>> > However,  I have no good idea how we can display this extra information.
>> >
>> > Currently the resources are in a 3 column table, which has an add button
>> > and
>> > the option to reorder.
>> >
>> >  * If we can add arbitrary new columns then the table will grow too wide
>> > and
>> > look bad.
>> >  * We could add a horizontal scrollbar, which would look ugly and
>> > obscure
>> > the new fields.
>> >  * We could change it to a "continuous form" instead of a table but that
>> > would muck up reordering.
>> >  * We could add a javascript popup of key value pairs (on hover or click
>> > of
>> > a info icon) that would look good but will not gracefully degrade
>> > without
>> > javascript.
>> >
>> > We also need a way to view the extra resource info in "view" mode, which
>> > is
>> > currently just a table of 3 columns.
>> >
>> > Has anyone got a good ideas about how this should be done?
>> >
>> > Thanks
>> >
>> > David
>> >
>> > _______________________________________________
>> > ckan-dev mailing list
>> > ckan-dev at lists.okfn.org
>> > http://lists.okfn.org/mailman/listinfo/ckan-dev
>> >
>> >
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
>