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

Hi Léonie,

Sorry I didn’t get back to you earlier. Your comments were forwarded to studio24 before they come up with their proposal:
https://docs.google.com/presentation/d/1kZEv2Cf9W5kqG1fCGtP2CNQc9sVeZNuSlbRJvx_irHo/edit?usp=sharing <https://docs.google.com/presentation/d/1kZEv2Cf9W5kqG1fCGtP2CNQc9sVeZNuSlbRJvx_irHo/edit?usp=sharing>

Please find some additional comments below.


> On 11 Jan 2021, at 16:42, Léonie Watson <lwatson@tetralogical.com> wrote:
> 
> A few immediate thoughts..
> 
> I think labelling and categorisation is critical, and I like the idea of families as a different way to organise things.
> 
> The ability to filter will be important. Off the top of my head the ways I'd want to be able to filter include:
> 
> * Date
> * Family
> * State (in progress, complete, obsolete etc.)
> * Rec state (FPWD, CR etc.)

Studio24 recommended that by default, /TR would use the family layout (specifications grouped by family) as it will give a good overview of the relationships between the different specifications.Then searching/filtering would simply list the specifications matching the criteria without keeping the categorization by family. In the list of filters showed in the mockups, there are:
* a input text field to search on the title and the family name
* tags (ability to select multiple tags)
* status (specific TR status or completed/in progress documents)

The results will be ordered by date so searching by date should be easy.

> 
> 
> Possible other filters:
> 
> * Responsible WG

The group pages actually already lists all the specifications produced by a group, e.g. https://www.w3.org/groups/wg/webrtc/publications <https://www.w3.org/groups/wg/webrtc/publications>
We might mention these pages on /TR if people are interested in a particular group deliverables.

> 
> The ability to sort data is also likely to be helpful:
> 
> * By date
> * By name (A to Z, Z to A)

Date will be the default sort but we'll forward your comment to Studio24 to include the ability to sort results by these two critiria.

> 
> 
> The prototype looks to have good accessibility (headings, lists, unique/informative link text etc.).
> 
> One challenge will be the use of acronyms. Convention is to expand the acronym the first time it's used in a document with the acronym in parenthesis after it, but this is going to be difficult given that filtering will mean the first instance of an acronym like "CR" may change. The best idea I can come up with is to create a glossary and to link to it from somewhere reasonably easy to find on the /TR page (a W3C glossary might be a good thing to "do once, link to often" from elsewhere too come to think of it).

There will be a short description of /TR, at the top of the page, linking to /standards containing more information about the different types of documents, including the different acronyms.

Hope the proposal matches your expectations on the /TR redesign.

Denis


> 
> On 11/01/2021 11:55, Dominique Hazael-Massieux wrote:
>> Hi,
>> 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
>> https://docs.google.com/spreadsheets/d/1WlqmB1ZTUo-nqpZ-E_bMUHD_KCcHUC10c2uctsj9Cv0/edit#gid=0
>> (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:
>> https://cdn.statically.io/gh/w3c/tr-pages/family-grouping/family-mockup/status.html
>> 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.
>> Thanks,
>> Dom
> 
> -- 
> Director @TetraLogical
> https://tetralogical.com
>