- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 12 Jan 2021 17:59:36 +0100
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>, spec-prod <spec-prod@w3.org>
- Cc: "public-website-redesign@w3.org" <public-website-redesign@w3.org>, Denis Ah-Kang <denis@w3.org>, "vivien@w3.org" <vivien@w3.org>
Le 11/01/2021 à 13:21, Nigel Megitt a écrit : > Realistically, for this human, 280 and 1200 are pretty much the same degree of "hard to navigate". > > I like the idea of grouping and categorising. You'll likely find overlap between groupings regardless of what classification scheme you define. For example folk interested in video media may well want to know about timed text, but folk interested in timed text may want to know about CSS or SVG, for example. I had initially tried a more curated/editorial approach to classification (which would help with guiding potential users based on their interest); but from that experience and past experience in this space, it feels like it would be challenging to create *and* maintain such a categorization (partly, this is what we tried to do in the 2008 redesign with the so called "tech groups", which had to be later abandoned for lack of take up from the groups). This is why I chose to proceed with a less ambitious but more easily systemizable approach of grouping specs that are more or less unambiguously part of a single set, with room for further guidance from groups. > Maybe a tagging and filtering approach is more useful than a strict classification grouping, because it allows any report to be findable via different routes. It also allows more useful groupings, if they are found later, to be added without breaking existing groupings. The TR page already has tagging and filtering, and I expect this will remain true in the redesign; from my early discussions with Denis, it's likely that the tags could be applied at the family level (but we haven't verified that yet). > On a specific point, if you're using families, then for the TTML and WebVTT families, it probably makes sense just to make a "Timed Text" (super?) family. I agree they would form a logical "super family"; but I'm hesitant to create a hierarchy of family at this stage. > It may be useful in general (but not always) to be able to group by the Working Group that published the docs. This may be possible already via other routes, but it's an obvious source of tags to define first order groupings. There are already views of specs by groups, e.g. https://www.w3.org/groups/wg/webrtc/publications Are you suggesting the TR page itself should provide such a grouping directly? (in any case, I agree with you that in many cases, groups provide useful hints for grouping, whether at the tag or family level) > I like the "in progress" vs "completed" distinction as a concept, but how does it work with Recs that can have new candidate features added? Isn't that a Rec that's always "in progress"? Great remark! I think a Rec with candidate/proposed changes would probably be marked as "in progress", but I welcome input on this. Dom
Received on Tuesday, 12 January 2021 16:59:40 UTC