W3C home > Mailing lists > Public > spec-prod@w3.org > January to March 2021

Re: Feedback sought on reorganizing the list of W3C Technical Reports

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Mon, 11 Jan 2021 12:21:43 +0000
To: Dominique Hazael-Massieux <dom@w3.org>, 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>
Message-ID: <CB0C9A3C-12CE-45F6-AF6B-C38C77F7B1ED@bbc.co.uk>
Hi Dom, Denis and Vivien,

Some quick thoughts since you ask for comments with some urgency:

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.

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.

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.

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.

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"?


´╗┐On 11/01/2021, 11:57, "Dominique Hazael-Massieux" <dom@w3.org> wrote:


    As part of the Web site redesign, Denis, Vivien and I have been looking
    at some of the approaches we could take to make the TR page easier to
    consume - with a goal of bring this  as input to the redesign Studio 24
    is going to bring to the page as part of the overall site redesign. This
    message concludes with a short-term request for feedback .

    Part of the challenge with the TR page is that we have over 1200
    technical reports on the page, which makes it hard to organize and make
    sense of.

    Denis and I have been exploring the idea of bringing more structure to
    the list by recognizing that a significant number of individual
    documents can be grouped into more meaningful sets, along two main axes:
    * specification series (level 1, 2, ...)
    * specification "families" where a given "technology" is split in
    different documents (e.g. XQuery & XSLT, OWL, RDF)

    (in many cases, these "families" can be manually inferred from use of
    common shortname prefixes, or common title subsets - moving forward, we
    would want to put in place a more systematic approach to defining and
    tracking these families)

    When using this approach, and ignoring obsolete technical reports (those
    currently advertised as "retired" on the TR page), a first stab at this
    grouping produces ~ 280 entries (to be compared to the 1200+ full
    list or TR ) which sounds like it should be easier to grasp, and in
    general, help bring sense to our past and ongoing work.

    The said grouping is described in

    (exported as attached CSV as well) - this is based on TR data obtained
    on Dec 17.

    Denis and I have been working on a wireframe-mockup of how a TR page
    reorganized along these lines would look like:


    There is naturally a lot of improvements that needs to be brought to
    that design, but we thought it would help get a sense of what these
    families would enable.

    We're primarily (and most urgently) interested in feedback from groups
    and spec authors on whether this is a reasonable way to organize the TR
    page moving forward. Given the timeline constraints of the redesign
    project, it would be great to get such *feedback before next Monday (Jan
    18, 2021)*.

    We're also interested in suggestions on how to improve the specific
    classification of specs proposed in the spreadsheet (ideally, towards
    reducing the number of families), but we have a lot more time for that
    work, on which we expect we would iterate on a more relaxed basis if
    this is indeed a viable way forward.



Received on Monday, 11 January 2021 12:22:03 UTC

This archive was generated by hypermail 2.4.0 : Monday, 11 January 2021 12:22:04 UTC