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

David Raznick kindly at gmail.com
Tue Jan 18 22:24:34 UTC 2011


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?


> 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.


>
> *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.

>
> 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.

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


>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110118/8d875d4d/attachment-0001.html>


More information about the ckan-dev mailing list