[ckan-dev] Removing AlphaPage
david.read at okfn.org
Tue Nov 9 13:24:29 UTC 2010
Glad to hear you're not dropping browsing after all! I do like faceted
browsing, but the key point is that you can see some general packages
*before* you filter by facet or search. This isn't a prime way that
eBay/Google/Guardian work, but I agree with you it would be good for
Maybe you should send this to the ckan-discuss list for ideas on this
topic, as this is not really a dev question?
I'm no expert in SEO, and I'm not clear exactly what you're suggesting
on this topic, but as long as you can view any package from the browse
screen in 2 clicks then I think that is covered.
On 9 November 2010 12:40, Friedrich Lindenberg <friedrich at pudo.org> wrote:
> Hi David,
> On Nov 9, 2010, at 12:23 PM, David Read wrote:
>> You want to drop browsing?!! For me it is essential to three key use cases:
>> a) user aimlessly exploring datasets
>> b) user wanting to get a rough idea of what datasets are in the d.b.,
>> without having to choose a search term
>> c) search engine indexing all data packages in fewest links
> I don't want to drop browsing, quite the opposite. The whole point of faceted search (browsing, actually) is to invert the process: the default query isn't empty but "*:*" (everything) and you drill down, either by using term queries or by specifying facet values. I think this is perfect to cover a) and b) which is why sites like eBay or the Guardians Govdata Search have chosen it: it gives structured feedback and refinement options on the composition of the current result set.
> I would imagine that the default facets for CKAN would include "tags", "groups", "resource_format" (forcing convention a bit!) and perhaps license classes (or licenses). Given that we figure out standardization on this (e.g. by introducing a "handle" system), "author" and "maintainer" would be very useful as well.
> As for c) (SEO), there's no reason we shouldn't link to the respective queries from some page (or even introduce routes to generate nice URLs), but I see no reason to implement specific controller actons for SEO (except, perhaps, to introduce a sitemap.xml).
>> The de.ckan.net 'b' page takes a fraction of a second to load. There
>> are 2 or 3 screenfuls of info - hardly overloading the user's page
>> down key or taking much browser memory.
> The page speed is due to the caching we have in there ATM which - as far as I know - returns stale data. I'd like not to do that in the future. The main argument around result page length is cognitive, though, and my argument would be that "Google has researched this and settled on 10 items a page" (not a very enlightened attitude, I'll admit).
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
More information about the ckan-dev