Team page direct link

[gilesdring]

It should be possible to link directly to a team on the team page, perhaps using a url such as theodi.org/team#team-board

[pezholio]

FWIW - I'd prefer it if they were proper URLs, and if people accessed them directly, they'd just see that team. Sure @JeniT would agree :smile:

[gilesdring]

Yes, and in fact the # part is never passed to the server - it's a client-only thing. I suspect that something that uses params may be that way to go in the first instance, as theodi.org/team/xxx already refers to a team member. Propose /team?filter=<tag_id> or similar.

[pezholio]

Ah, good point, that sounds like a good compromise

[JeniT]

I'd be happiest with something that looked like /team/board, /team/evidence etc. The only reason I suggested the hash version was because the existing filtering looked to be client side so I thought that would be least work to implement.

Note selection of the team from the dropdown should change the URL.

[gilesdring]

Rewriting the URL properly (assuming the ?filter=<tag> approach) requires HTML5 browsers and history rewriting. Feel slightly dubious about introducing that without consider impact.

An alternative would be to provide a clearly identified permalink that could be copied / clicked to allow the user to select it. Propose only doing this if the filter is selected.

I'm slightly concerned that none of this stuff is accessible - or at least I've not considered the impact on screen readers, etc. Would be good to hear your thoughts on that.

The URL hash approach (as Jeni points out) needs client side stuff, and although it's running filtering on the client side, it feels a bit wrong somehow.

A full page redirect to a new URL is also overkill, and defeats the speedup of client-side filtering.

Ref the /team/xxx approach - this is currently used for team members (not teams). Feel somewhat dubious about overriding it - they're in different namespaces (teams tags are tag ids, people refs are slugs), so there is a potential for clashes. Granted, this is unlikely, unless you get some oddly named people or teams, but you know what I mean. Options are to promote teams to edition / artefact status, or change the information architecture to link to people as /people/xxx and teams as /team/xxx. This is far more far-reaching, I suspect.

[gilesdring]

For discussion, here's a potential design for a permalink which would show up as the list is filtered. Anchor would disappear as the filter is cleared.

[JeniT]

If we have to include a permalink link in the page (ie separate from the URL bar) then we may as well not do it (I predict people won't use it).

If possible, I favour a progressive enhancement technique whereby URLs of whatever form is chosen are supported (probably server-side). For browsers that do support the history API (and most of them do), capture the link following event and replace it with the client-side filtering to get the speed of update of the page while updating the URL bar.

[gilesdring]

Fair comment regards the permalink. I think this comes down to the consideration of two separate behaviours

1. the ability to prime the filter on page loading (which I have all but working). I think the cleanest current way of doing this is by providing a parameter on the request, given current URL design (team == people).
2. the unambiguous communication of this filtering mechanism to users. URL rewriting definitely cleanest way of doing this.

My proposal is thus url /team for whole team, and /team?filter=team-tag for a specific team. Everyone OK with this? For supporting browsers (90+% in UK), this will be rewritten (pushed?) to the history. For all others, the client will trigger a redirect (and we trust to caching).

[JeniT]

Fine by me.