MDN: Page Titles for Javascript methods

[Jean-Yves Perrier]

Hi!

Page Title/H1 are a recurrent problem. Our page titles are not good,
neither for users, nor for SEO.



Our main limitation right now is that our <title> and <h1> are identical
(with a - MDN added automatically to the title). That means that no
perfect solution can be achieved yet.

But we surely can do better than what we have now.

I've gathered some possible solutions. Feel free to add other ones, to
complete these ones and even to propose other criteria. I'll compile an
edited list.

-- JY


==================
Naming of the Javascript method pages in MDN

A. Current case: <h1> and <title> (with - MDN added to the <title>)

Feel free to add your opinions, more criteria and more cases. Add your
initials next to your opinions as colors may disappear inadvertently.

1) "shift"

* _Description_: what's done now

* _Title readability in tabs_: Fair (starts with the most
significant part, but no disambiguation
automatically done)

* _H1 readability_: Fair (most significant, context given by
breadcrumbs which are very small)

* _SEO consideration_: Very poor. No Array, No Javascript keywords
in h1, title

* _Search engine description_: Low (the title doesn't give the context)

* _Surprise?_No surprise.

* _Remarks_: JY: until we can separate <h1> and <title>, it may be a
fair compromize

2) Array#shift -JavaScript

* _Description_: The # is not standard (AFAIK) but make the
different between a method of a class and the .
meaning calling a method of a given object (similar
to the :: / . distinction in C++)

* _Title readability in tabs_: Low, shift is the most significant part
but hidden in the middle with complex
syntax

* _H1 readability_: JavaScript is not useful, the most significant
info is in the middle

* _SEO consideration_: Good, though the consequence of a # there
must be studied

* _Search engine description_: Low (the title does give a context
but the # make the surprise element
very annoying)

* _Surprise?_ the # is a surprise element.

* _Remarks:_ the # surprise element is a big deal in my opinion (JY)
and the JavaScript in the <h1> is ugly (JY)

3) Array.shift()

* _Description_: This is the C++/Java way.

* _Title readability in tabs_: Fair, but Array.shift is not correct
in JS

* _H1 readability_: Fair even if most significant info not in front

* _SEO consideration_: Good, (except for JS)

* _Search engine description_: Fair (but the fact that it isn't
correct JS is not good)

* _Surprise?_ Incorrect syntax

* _Remarks:_ the incorrect syntax is probably a no-go(JY)

4) Array.prototype.shift()

* _Description_: This is used in the Ecmascript documentation

* _Title readability in tabs_: Low, the significant part will be
often hidden

* _H1 readability_: Fair even if most significant info not in front

* _SEO consideration_: Fairly good, but array and shift are from the
other (bad for JS keywords)

* _Search engine description_: Fair (though JS keyword is missing
from the title)

* _Surprise?_ No, but the title is complex and not all beginner
master the syntax though.

* _Remarks:_ the incorrect syntax is probably a no-go(JY)

5) Array shift method

* _Description_: Proposed new standard

* _Title readability in tabs_: Fair, though the most significant
term is not at the beginning

* _H1 readability_: Low, the most significant part is in the
middle. Correct english though and bring the
context (method of array) out of the breadcrumbs

* _SEO consideration_: Good (bad for JS keywords)

* _Search engine description_: Fair (though JS keyword is missing from
the title)

* _Surprise?_No

* _Remarks:_ Doesn't really solve the keyword in title problem
(JavaScript missing) and I don't like the most
significant part in the middle (JY).

6) Array shift

* _Description_: The common SE request (maybe w/ JS)

* _Title readability in tabs_: Fair, though the most significant
term is not at the beginning

* _H1 readability_: Fair to low, is this a method? or something else

* _SEO consideration_: Good (bad for JS keywords)

* _Search engine description_: Fair (though JS keyword is missing
from the title)

* _Surprise?_ No

* _Remarks:_ Doesn't really solve the keyword in title problem
(JavaScript missing)

7) shift (Array)

* _Description_: Wikipedia way of disambiguation

* _Title readability in tabs_: Very good

* _H1 readability_: Good, though the parenthesis may be mistaken
as a parameter list identifier

* _SEO consideration_: Good (bad for JS keywords)

* _Search engine description_: Fair but complex too parse, maybe
(and JS keyword is missing from the
title)

* _Surprise?_ A little as the parenthesis means something different
in the language

* _Remarks:_Worked very well for Wikipedia ;-) (JY).

8) *shift() — Array object method*

* _Description_: I call the two part page h1.

* _Title readability in tabs_: Very good

* _H1 readability_: Good, though the it may be a little long

* _SEO consideration_: Good (bad for JS keywords)

* _Search engine description_: Rather good (and JS keyword is
missing from the title)

* _Surprise?_ I would say not.

* _Remarks:_ I don't like dashes in <h1> but may be a compromise (JY).

9)... Surely you have other ideas.

B. Future case: <h1> and <title> may be different
(Not done yet, but the discussion is needed too). So if you already have
a proposal, feel free to tell us about it.

[Burak Yiğit Kaya]

Why are we bound only to h1? We are trying to treat each page as a separate
"book" where as all are sub sections, articles in a much larger "book". I
liked option 7 most but what I have in mind is using something like this:

<h1>JavaScript MDN Documentation</h1>
> <h2>Array</h2>
> <h3>shift()</h3>
>

Where the title is constructed from there but in a reversed order so it
would be something like the following: shift() - Array - JavaScript MDN
Documentation

This way:

1. You have semantic mark-up
2. You clearly show that this is a sub-sub section of a much larger
thing where all the headings can be linked
3. You sort the title from the most important/specific thing to the
least important/specific thing

Which I think are all good for SEO and usability.

Burak Yiğit "BYK" Kaya <http://byk.im>

> ______________________________**_________________
> dev-mdc mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-mdc<https://lists.mozilla.org/listinfo/dev-mdc>
>

[Jean-Yves Perrier]

On 24/04/12 10:21, Burak Yiğit Kaya wrote:
> Why are we bound only to h1? We are trying to treat each page as a
> separate "book" where as all are sub sections, articles in a much larger
> "book". I liked option 7 most but what I have in mind is using something
> like this:
>
> <h1>JavaScript MDN Documentation</h1>
> <h2>Array</h2>
> <h3>shift()</h3>
>

But <h1> must be the subject of the page!

[Burak Yiğit Kaya]

You are correc, my badt! =)

Then I would go with the 8th option where "JavaScript MDN Documentation" is
*appended* to h1 for the title.

Burak Yiğit "BYK" Kaya <http://byk.im>

[David Bruant]

Le 24/04/2012 18:58, Jean-Yves Perrier a écrit :
> Hi!
>
> Page Title/H1 are a recurrent problem. Our page titles are not good,
> neither for users, nor for SEO.
>
>
>
> Our main limitation right now is that our <title> and <h1> are
> identical (with a - MDN added automatically to the title). That means
> that no perfect solution can be achieved yet.
>
> But we surely can do better than what we have now.

Do we need to change this now? Kuma is about to be released and with it,
the opportunity to decouple urls, <title> and <h1>.
What is Kuma's current ability on that regard?
If it allows to have different <title> and <h1>, then I think we're good
because there is no urge to do the modification before Kuma release.
If Kuma can't do it, we probably should put that high in the priority list.

As for a convention, I thing h1 should be: "Array#shift" and
"Array.isArray" as these are widespread conventions among JavaScript
developers.

David

> _______________________________________________
> dev-mdc mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc