[ckan-discuss] CKAN UI improvements #1 - Package Page

[Richard Cyganiak]

Hi Richard,

Great to see work on the UI of CKAN happening!

On 30 Nov 2010, at 13:44, Richard Pope wrote:
> First up here are a few suggestions and a mockup for the package page:
>
> http://ckan.org/wiki/UIRedesignPackage

Nice!

Some comments:

> Comments - Suggest move to a separate tab and rename discussion as  
> per Wikipedia.

Not sure about this. On Wikipedia, the discussion page is not for  
discussions about the topic of the article but about discussing the  
article itself. On CKAN, my impression is that comments about either  
of those are encouraged. Or not? And if the comments can contain  
useful information about the dataset (“it's full of errors and not  
actively maintained, don't waste your time with this”), then they  
shouldn't be hidden on a separate page.

So I guess some clarity about the purpose of the comments field is  
needed first.

> Getting the data - 'resources' is unclear term, just call it  
> 'downloads?'

That would be a step in the wrong direction IMO. It's not just  
downloads but all sort of other things too -- API endpoints,  
documentation, example links. See [1] for a proposal that deals with  
this in a better way IMO -- by moving the description to the first  
column, it becomes much clearer what the resource is (download or  
something else).

> Groups - Confusing having groups and tags on this page, suggest  
> remove groups for now focus on tags as primary method for  
> organising / grouping.

Please don't do that. Groups don't have to be visually prominent, but  
you would make my job as the manager of a CKAN group MUCH harder by  
removing this information completely from the package page. I agree  
that tags are certainly much more important for the average user, and  
should be displayed more prominently.

> Title - Name of package gets lot in the buttons (edit etc) and the  
> package slug id

The package ID shouldn't be as prominent as it currently is, but  
should still be shown somewhere to enable tools like datapkg where one  
needs to know the package ID.

> API / package slug - Create new API section the explains the slug id  
> and how to access via datapkg etc

Yes good idea. Don't call it “package slug” though!

Please keep the package URL (homepage) more prominent. I'd vote for  
keeping it where it is now, under the big title. I often use CKAN as a  
sort of directory for going to the web pages of certain packages.

+1 to the other points.

Some other points that I would like to see addressed in a redesign of  
the package page UI:
http://ckan.org/ticket/818
http://ckan.org/ticket/816
http://ckan.org/ticket/814

Again, thanks for working on this! I'm very much looking forward to  
seeing some of these improvements go live on the site soon.

Best,
Richard

[1] http://ckan.org/ticket/817