Re: More compact display for inherited properties and methods in DOM object pages

First, thank you very much!

Second, I am sorry, but this member cloud is really not comfortable for me
(as a developer).
The summary is crucial for every member. This turns a fully contained page
into a multiple click flow (and with the performance issues the wiki has,
it is very annoying and time consuming).

The compromise, in my opinion, would be to just change the order of the
sections on the page.
Summary, Syntax, Overview (and notes and the rest), Examples, member
listing (with summaries and inheritance) and finally, standards and
compatibility information.
(Perhaps the standards information can be shown before the member listing,
I do not feel strongly about it)

Regarding the grouping, I am not sure the current grouping makes a lot of
sense (though MSDN does that, MDN does not, if I remember correctly).
Events should be separate from the rest, but I would argue that properties
and methods should be shown in a single place. Perhaps denoting its type
(property or method) by adding an icon before the name.

I also do not think there should be a "more" link. Everything should reside
on the same page. Clicking on it gets you totally out of context, into a
special property search page.

Once we clean up the DOM interfaces (for example, the readyState property
should not be there, as are a lot of other properties shared only by a few
elements), it would be cleaner.
If not, grouping by topic (for example, ARIA properties) might be better.
On top of that, showing a few properties and a "more..." link that simply
makes the rest visible, without loading anything, looks fine to me.


☆*PhistucK*


On Sat, Jul 26, 2014 at 3:38 AM, Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

> Feedback needed!
>
> Working through the QA review of DOM pages, I was finding that the
> endless, near-identical tables of inherited properties/methods/events
> distracted from the main content of the page.  You have to scroll down
> quite a ways to reach examples and compatibility.
>
> I've come up with a more compact template and have got some sample pages
> in the test wiki.  I'd appreciate feedback before rolling this out on the
> main wiki.
>
> I've got three pages in the test wiki set up to use that template, with
> different amounts of content.  Please *don't* edit these pages using the
> forms, as it will over-write the custom template call.
>
>    - http://docs.webplatform.org/test/dom/HTMLTableCellElement
>    - http://docs.webplatform.org/test/dom/HTMLTableElement
>    - http://docs.webplatform.org/test/dom/HTMLElement
>
> Compare with how the same pages currently look on the main wiki:
>
>    - http://docs.webplatform.org/wiki/dom/HTMLTableCellElement
>    - http://docs.webplatform.org/wiki/dom/HTMLTableElement
>    - http://docs.webplatform.org/wiki/dom/HTMLElement
>
> Ignore differences in which pages show up as links and the fact that most
> don't have summaries in the test wiki; the focus is on the layout.
>
>    - Is the compact display *too* compact?  In-between options, such as a
>    multi-column bulleted list, are also possible.
>    - Does the organization make sense (grouping by
>    methods/properties/events instead of grouping by the interface they are
>    inherited from)?
>    - Should there be different number of results before the results lists
>    gets truncated with "More.."?
>    - Is the "More..." link obvious enough, or does it need stronger
>    formatting? (see the HTMLElement page)  The default table has this link in
>    a table footer, but I don't think that can be done with the custom
>    templates, since it is always added *after* the footer template.
>    - Any other concerns / suggestions / aspects you find confusing?
>
> The new template, for those interested in such things, is at
> http://docs.webplatform.org/test/Template:API_Object_new
>
> P.S.  Thanks to Renoir for rolling back his single-sign-on test so that I
> could use the test wiki.
>
> Amelia BR
>