Template talk:LSL Header

Layout

Style

I think a review of the header is in order. I'm thinking some javascript dropdown menus (which will require harassing LL to add that sort of thing to the wiki). We could stuff more stuff into it then. -- Strife ^{(talk|contribs)} 14:37, 8 October 2013 (PDT)

Ordering

The order of the values doesn't seem entirely right. -- Strife ^{(talk|contribs)} 14:37, 8 October 2013 (PDT)

New Item Suggestions

General criteria for new suggestions:

1. How often will a user visit the page?

   If the user is only going to ever visit the page a couple times, it's probably not a good reason to list it.

2. Is it a fundamental category of LSL Portal content?

   Users expect the links in the header to bring them to a hub of content. You want these categories to introduce people to the class of content they contain and direct them to the content they seek.

3. Will they want to visit it from any random page on the LSL Portal?

   Typically only in the context of getting them back to the category of content they are interested in.

LSL_Alternate_Editors

I believe it could use a link to LSL_Alternate_Editors. Whatcha think? -- Kireji Haiku 10:16, 8 October 2013 (PDT)

My gut says no. The question that comes to the top of my mind as the most important question is this: "How often is will a user visit the page?" I can sort of see a user, after reading a random LSL article suddenly going "Ahha! You know what would make this better is if I switched to an Alternative Editor. Now how do I go about finding one that supports LSL?" but I cannot see them going the next day "vim sucks, now how do I find out about Alternative Editors?" There isn't much in the way of demand for repeat use. Everything that is currently in the header is a category each which links to a plethora of articles. They each represent a different fundamental view of the content that lives in the LSL Portal (with the exception of the Categorized Library, which really needs a the above #Style remake to resolve).

Considering the how low we would be setting the bar if we accepted AE, we would have trouble fending off LSL Protocol and the like. One of the design goals is that the header doesn't take up a huge amount of screen space. -- Strife ^{(talk|contribs)} 14:37, 8 October 2013 (PDT)

I think what you are wanting to do is raise the communities awareness of AE. If that is the case, I think that's more an issue for LSL Portal and not so much for the header. -- Strife ^{(talk|contribs)} 14:50, 8 October 2013 (PDT)

Hm, I get your point. The idea behind it was that using alternate editors with (syntax highlighting and) autocompletion will make people write better formatted code which helps readability. Just an idea, no big issue. -- Kireji Haiku 23:11, 8 October 2013 (PDT)

It could also be worked into the Tutorials, maybe also into the category pages (since highlighting is homogenous within major categories) but that seems a bit of a stretch. -- Strife ^{(talk|contribs)} 13:13, 9 October 2013 (PDT)

Maybe we need a "Featured Article" doohickey... which could get linked in the header and the first could be AE. -- Strife ^{(talk|contribs)} 13:17, 9 October 2013 (PDT)

Well if there's anything I can do, lemme know. I'm not good at wiki hacking, though. -- Kireji Haiku 09:49, 12 October 2013 (PDT)

"Selected" tab?

It would be a nice featurette to have a way to select one of the tabs, so that people coming from a wiki-wide search will know, within context, which (sub)section they are in!

This is mostly true for the Library/Examples but may apply to others as well (functions, events, etc. can be easily "automated" since they have their own template... which could, in turn, "activate" the selected tab).

It's just an idea...

— Gwyneth Llewelyn (talk) 10:11, 26 February 2024 (PST)