[ckan-discuss] SEO Review

Rufus Pollock rufus.pollock at okfn.org
Mon Jun 28 10:29:18 BST 2010


On 26 June 2010 13:09, Tim McNamara <paperless at timmcnamara.co.nz> wrote:
> On 21 June 2010 10:28, Glen Barnes <glen at opengovt.org.nz> wrote:
>>
>> Charles Coxhead (http://twitter.com/charlescoxhead) did an SEO site review
>> for us which can be found here:
>>
>> http://www.quicksitereviews.com/ckan-net/
>
> I have implemented one of the suggestions in this video. Of all the points
> in here, I think alphabetical pagination of tags would make the biggest
> difference to users of CKAN. I've crafted a fairly attractive solution with
> JQueryUI's tabs. I thought I would discuss the solution before I worry about
> finishing touches like getting JQuery's CSS to comply with CKAN's default
> styles.

Great stuff Tim! By the way, one thing to suggest is that you could
push your copy of the CKAN codebase with any revisions you've made to
your own repo on, say, bitbucket.org (if you haven't already). This
way you can already point to some of your changes when discussing them
which may be useful ...

> The problem
> Currently, CKAN uses Pylon's pagination helper. Which is great at doing what
> it does, but it uses numerical values. When people visit
> http://www.ckan.net/tag/, they encounter pages 1 ... 16. But, if they're
> looking for a specific tag, it wouldn't help them too much.

What about using the tag-search? I realize this has the issue (at the
moment) that searching for 'c' gives you all tags with c in them.
However, one could imagine a small mode to the search to support
matching on first letter only (this would also improve the
autocomplete?)

> My approach
> The tags controller: Select all tags from the db by recycling the SQLAlchemy
> Query object that is already there. From there, create a dict with the 0th
> letter of each tag as its keys. This results in something like:

This sounds reasonable but might be pretty bad on performance (1000s
of tags in there). Though this could be ameliorated by caching ...

> tags = dict(
>   a=['alphanumeric', 'animal', ... ],
>   z=['zebra']
> )
>
> From there, the template renders every tag. Using CSS magic, most tags
> remain hidden. However, every tag is still accessible to screen readers &
> text browsers.  The HTML looks something like this:
>
> <div>
> <a href="#tag-a">a</a>
> ...
> </div>
>
> <ul id="tag-a" class="tags">
>   <li>alphanumeric</li>
>   <li>animal</li>
> </ul>
>
> <ul id="tag-z" class="tags">
>   <li>zebra</li>
> </ul>
>
> Snags
> The Genshi template ckan/templates/layout_base.html asks for optional head
> components in at the end of the head block. This means that any CSS imported
> overrides the defaults. This means that downloading from
> ajax.googleapis.com/.../jqueryui.css is fast, but leads to inconsistent
> styling.

This suggests an additional optional head component I think -- or you
could try something sneaky (and probably not recommended) like
matching a given <link /> tag that's already there and replacing it
with itself but your new css.

> Feedback welcome. If people think this is a beneficial suggestion, I'll add
> some polish and submit a patch.

Aside: Echoing earlier comment, rather than a patch if you can just
push your copy of the repo to, say, bitbucket that is even better ..

Regarding the approach, I think this sounds good but I'm concerned a
bit about performance if we load all tags at once :) I wonder if there
is a way for us to mod the search to support this. SQLAlchemy query
for all tags starting with a letter is extremely simple:

model.Session.query(model.Tag).filter(model.Tag.name.ilike(letter + '%'))

However, this is great stuff and we're really looking for some more
jquery-like UI polish so it's fantastic you are doing something like
this!

Rufus
-- 
Open Knowledge Foundation
Promoting Open Knowledge in a Digital Age
http://www.okfn.org/ - http://blog.okfn.org/



More information about the ckan-discuss mailing list