User talk:Derek Harkness/Skin

Comments

Please make comments and requests below here using ===three equals=== for the header.

Font size of blockquotes too small relative to main tex font size

How can I code the blockquote font size so that it matches that of the main text font size, and stays matched when the reader changes text size in her bowser? --Anthony.Sebastian 15:44, 28 April 2008 (CDT)

Snapshot

Could you post a snapshot showing how the skin should look like? This would ease comparison of the appearance for different browsers. -- Alexander Wiebel 12:54, 3 March 2008 (CST)

Headings

With the new skin, I find it significantly harder to distinguish between the different heading levels. This page is a very good example for this fact. -- Alexander Wiebel 12:59, 3 March 2008 (CST)

I have to agree with Alexander here. I like the old skin way of handling this, with a line across the page at a level 2 heading and no line at a level 3 heading. Slightly greater differentiation in font size would help as well. --Larry Sanger 13:07, 3 March 2008 (CST)

I also agree. It's not so much of a problem in article where headers are well spaced, but here on the talk page they look too alike. Aside form adding back he horizontal rule, we could use indentations, colour and tone differences, variation in weight (bold or fine text), italics and even add backgrounds. I'll have a play and see which works best without cluttering the pages. Derek Harkness 19:36, 3 March 2008 (CST)

I like the style of the main headings in Frederik's old skin (link here) -- dark gray with (dotted) underlined main headings. Nick Bagnall 02:31, 4 March 2008 (CST)

I've adjusted the sizes in version 2 (coming shortly) and also tweaked the colours slightly so that level 2 and level 3 are not the same shade of grey/black. I also tweaked levels 4, 5 and 6 to make them more apparent too (not that they are used much) Derek Harkness 05:21, 4 March 2008 (CST)

Formulas

Embedded TeX formulas look not so nice with the new background. I think it is hard to fix this with a gradient in the background. ... this is already my third comment, so I probably should mention that I like the new skin very much :-) -- Alexander Wiebel 13:05, 3 March 2008 (CST)

It's possible to make the background of the generated images transparent. At least, it's possible if dvipng is installed and used, which the people with access to the server should be able to tell. -- Jitse Niesen 15:09, 3 March 2008 (CST)

The instructions, for said people: Provided dvipng is installed, you need to change line 8 of math/render.ml in the MediaWiki tree. Add the argument "-bg transparent" to the dvipng command (as instructed in the comments in that file), recompile, and remove all the old .png files generated by texvc. That's it. -- Jitse Niesen 15:19, 3 March 2008 (CST)

I suggest following Jitse's idea in the first instance and see how that works. Derek Harkness 05:16, 4 March 2008 (CST)

Reversed link order

I find it just slightly weird that the top-of-page links (User page, Discussion, Edit, etc.) are in reverse order. I could learn to live with what's up there, but I think I'd prefer it the original way. What do others think here? --Larry Sanger 13:07, 3 March 2008 (CST)

I agree, but I think it should be in the following order: Edit, Article, Discussion, Watch, History, Move. I think edit should be first, as that's what we ant to encourage. The rest are in order of buttons I think are used from most to least. I'd get used to whatever order we use. I must admit - at first, I didn't like the skin (I guess it's because it's much different), but after using it a few times, I now think it's great - fantastic work! :D Oliver Smith 10:21, 5 March 2008 (CST)

Edit window size

Not sure if this is intended or not, but the edit window in the new skin seems to be half the width that it used to be. I imagine I could get used to it, but would prefer it to be bigger. (If this isn't intended, I use Firefox 2) --Todd Coles 22:27, 3 March 2008 (CST)

Fix coming in version 2 skin. Edit box now is the same width as the main content area. Derek Harkness 05:14, 4 March 2008 (CST)

Gray background too dark

I'm using "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12". Text that appears on the darker part of the background gradient is a bit annoying to read (black on gray). Can you make the gradient a little more subtle? Also, the gradient seems to go from gray to light gray. Shouldn't it go from light gray to white instead so the page uses the whole range of available colors? If I wanted to turn down the brightness of my monitor, I could do that with the knobs the monitor provides for that purpose. :) Warren Schudy 09:45, 4 March 2008 (CST)

I would also suggest making all text colors have at least one RGB component equal to 0. To make some text look different, mix in a tiny bit of color. Warren Schudy 09:57, 4 March 2008 (CST)

There are elements of the page that are pure white. There are also elements that are pure black. By toning down the some colors a very small amount (and it is a very small amount) allows some elements to be highlighted in white or emphasized in black. Setting one arm of the RGB colours to 0 does not equate to a higher of lower contrast between colours. Having said all that, I have darkened the main text more in the next version. Derek Harkness 10:42, 4 March 2008 (CST)

Here is a contrast analyzer which applies W3C accessibility standards to color combinations. The gray sidebar links and the normal blue links vs. the darkest part of the background fall below the threshold. Petréa Mitchell 15:42, 21 March 2008 (CDT)

I ran the colours used in the main content area through this test and they passed OK. The user menu at the top of the page is a little below the threshold but of low significance as for most users (e.g. the reading public) that menu doesn't exist. Derek Harkness 08:59, 22 March 2008 (CDT)

Has there been an editorial decision to write off visually impaired people as potential authors? That threshold is an absolute minimum for accessibility, and ideally one should aim higher. Petréa Mitchell 10:53, 22 March 2008 (CDT)

You make is sound like the site is only just scraping through by a narrow margin. The threshold given by the site you linked is 125 and we scored 221 for the main content area. That's not a narrow margin. That's quite a clear and distinct margin. At the footer where the graduation comes in, the score drops 195 which is still a big margin above the guidelines.

I also tested the color range of my Firefox browser's menus and those of Apple's Safari browser and our site is significantly higher in contrast than both of them. In fact the apple web site and operating system failed the test! Derek Harkness 12:13, 22 March 2008 (CDT)

It was the words "below the threshold" that I was responding to a couple paragraphs up. Petréa Mitchell 14:24, 22 March 2008 (CDT)

More usability whinges

The sidebar links should remain the same color as other links, so that they're discernible as links.
Users who simply click "Go" without changing the text in the box should arrive at a page explaining search.
Or, even better, that text should be in front of the box, rather than in it. Petréa Mitchell 15:48, 21 March 2008 (CDT)

-Not true, most web pages use different styles for the menu as compared to links in content

-Good idea. Now done. Though could do with some help writing the page at CZ:How to use this site's search function that this targets. Derek Harkness 08:50, 22 March 2008 (CDT)

Fill large blank area with quote that encourages author participation

Regarding the large blank area under the Workgroups logos/titles and above the Article-of-the-Week: I thought a quote that encourages author submissions/edits might look nice and not intrusive. For example only:

no caption

A different font etc. might be considered. Also consider moving green check button to left of

Approved Articles
Developed Articles

Anthony.Sebastian 19:47, 21 March 2008 (CDT)

It's a sound idea but not one that can be implemented by the skin. To do what you want you just edit to front page just as you would any other page. The <blockquote> tag will render your text in italics and a serif font. However, an image would be required to create the fancy handwriting in your example. I don't think there's any restriction on who can edit the front page text so I'd say this comes under 'be bold' or some similar wikipedia phrase. Derek Harkness 08:36, 22 March 2008 (CDT)

Bug reports

Bug reports can go below here using ===three equals=== for the header. When reporting a bug, please give me the name of your operating system, and version of web browser as well as the page you saw the bug on.

WikEd tool is disabled

This might be an easy fix as CZ:Enhancing_your_editing_with_javascript_extensions#How_to_install these instruction on installing WikEd on the user's browser by editing the user's monobook.js file might also work for whatever js file powers the new skin. I am using FireFox 2.0.0.12. - Robert Badgett 09:31, 3 March 2008 (CST)

The following hasn't been tested as I live in China and so can't use the WikEd or Popups scripts as they still run off of wikipedia's server, but it should be a very easy fix. The javascript extensions are enabled by making a file called Special:Mypage/monobook.js. That file is particular to the monobook skin. When you move to a different skin you need to move your .js page to the new skin's name, e.g. Special:Mypage/pinkwich5.js Derek Harkness 09:46, 3 March 2008 (CST)

Links suggestion

This is not a bug, but a layout suggestion. Under toolbox, consider adding links to:

I think the general public will find MediaWiki hard to use well. These are links to try to make the experience easier pending development of a more wysiwyg interface by mediawiki or other group. - Robert Badgett 09:31, 3 March 2008 (CST)

space around photos

Could you add a little space to the right of photos that are positioned on the left of the page? As it is, the text runs right up to the edge of left-positioned photos and looks sort of cluttered. Photos on the right of the page look fine. Great job overall! --Joe Quick 12:58, 3 March 2008 (CST)

I second this recommendation. I'm using the latest version of Firefox, and there's no space between the text and images on the left side of the page. Overall though this is a superb design. Kudos. Nick Bagnall 02:33, 4 March 2008 (CST)

Coming in version 2. Added some space top and bottom too. Derek Harkness 05:27, 4 March 2008 (CST)

Image: pages

On a number of image pages, the image runs off the right of the darkened box that holds text on regular pages. See Image:Palau_Diver_with_shark.jpg, for example. --Joe Quick 13:09, 3 March 2008 (CST)

Could you provide a screenshot of the problem you're having? I'm on FF2.0, and it looks okay to me. It may depend on your screen resolution, but I'm not an expert. Oliver Smith 10:24, 5 March 2008 (CST)

Several things

I'll just duplicate what I created accidently

My initial stuff (I'm the backward compatibility guy with IE 6)

IE:

tabs wrap incorrectly in preferences
main page title text "Main Page" is displayed under CSS elements (needs to be moved up, same with article headers)
page width does not scale correctly to browser width
navigation boxes at top of "recent changes" displays horribly.
word wrapping on semi-continuous lines of text do not wrap correctly (see example in recent changes)
In IE (not sure about other browsers) you can no longer highlight main body text for copying and pasting!

I've just discovered the problem on this: any text that falls above or below the left navigation table is highlightable, but any text that falls exactly to the right of the navigation and within the top or bottom bounds is unhighlightable because the navigation takes precedence, somehow. --Robert W King 09:48, 5 March 2008 (CST)

Firefox 2:

Nothing so far

Style:

gradient in articlespace text body does not scale well on short pages ( I would remove bottom gradient)
would recommend horizontal lines for subheading text
would put "Categories" section in a box to seperate it from the body text.
Might change the font too; it seems like there's not enough space between lines now--maybe something with serifs, or less "round".

--Robert W King 21:39, 3 March 2008 (CST)

Bug:

Diff text is not in a fixed-font, e.g. Courier, System

Tab wrap fixed by widening the page a smidgin. This site has one extra tab that's not on my wiki install
Invisable overlying element adjusted so as not to overlap the main page content.
Can you provide screen shots of page scaling problem.
Recent changes fix will be in version 3.
Gradient fixed for IE the same way as for Firefox.

Derek Harkness 09:58, 5 March 2008 (CST)

Two things

Not bugs, rather recommendations for the style.

would move the "watch" and "move" tabs to the right, would put "edit" first on the left (to make the most prominent action; "edit" in the middle is hardly visible). Also, the constabulary-related "protect" and "delete" tabs might be moved to the right of the line.
would link the top-left CZ logo to the main page; I know it's redundant to the link in the toolbox below the logo (and it's always been), but such a link appears to be a well-established standard in the web. If I had to choose I'd suppress the explicit link from the toolbox.

Otherwise, good work! Aleksander Stos 03:05, 4 March 2008 (CST)

Subtle changes to the order within the menu cannot be controlled by the skin, if they could I'd move the 'history', 'talk' and 'article' links down into the subpages (where 'talk' and 'article' are duplicated already) and just leave 'edit, move, watch and protect' that top menu. However, that would cause another complication as not every page has subpages (e.g. userpages, templates, CZ namespace and workgroup pages).

Version 2 will have the logo linked. Derek Harkness 05:37, 4 March 2008 (CST)

Logo link

Minor usability issue: The logo should be a link -- clicking on the logo should take the reader to the main page. This is a fairly standard practice with websites, and most people expect the header/logo to be a link to the main page. Utkarshraj Atmaram 23:06, 3 March 2008 (CST)

A fix for this is in Version 2 and will have the logo linked. Derek Harkness 05:38, 4 March 2008 (CST)

However, it's also recommended that the logo on your main page not be a link, if possible. I don't know if it's possible to do that here... Petréa Mitchell 21:55, 21 March 2008 (CDT)

If you mean on Main_Page, the logo isn't a link. You can click to get a bigger version of the image. --Robert W King 22:16, 21 March 2008 (CDT)

Search window text

The big, bold text in the search window (which in my Mac Safari appears to be about 16 pt. bold Arial) is initially both a too-striking contrast to the important menu items above it. It is also initially off-putting and not clearly a search box. (O.K. Yes, I want to ask a question now where and how do I do it? was my initlal reaction). Since most people know what searches are for, the question may be unnecessary and a blank search box might be better. The text also appears to be bold face, which is unlike any other search box I've ever encountered. Bold is usually reserved to headers and other purposes.) If it isn't bold, a different font might be the answer.

Apart from that, I find the new skin a dramatic improvement over both the old CZ skin and Wikipedia. Nice piece of work!

Roger Lohmann 07:12, 4 March 2008 (CST)

The menus above and below the search box are not important. In fact I'd argue that they are the least important. Most users of this site are not authors or editors (I hope). For them, the menus linking to, "Yourself, My talk, My preferences, My watchlist, My contributions, Log out." do not exist. It's just "Log in / create account".

As for the bold and text size. I was actually copying another popular web site though I'm not going to say which one. Derek Harkness 09:47, 4 March 2008 (CST)

Can't click in blank windows

Using IE6 here at work, I am unable to click on a blank area to input text (Edit windows on new pages, the edit summary line below, etc.) If there is text already there, it's fine, but I have to click on the text itself and move the cursor to the end before I can add my own text. --Todd Coles 12:20, 4 March 2008 (CST)

I noticed this also. --Robert W King 12:21, 4 March 2008 (CST)

Confirmed. I'm using IE6 right now and I see the problem. But don't worry, I know the solution. Will take a little work to fix though. I'll report back later. Derek Harkness 23:30, 4 March 2008 (CST)

Now fixed in version 2. Derek Harkness 10:06, 5 March 2008 (CST)

Live tomorrow AM

Hi Derek, will we be ready to go live with the new skin tomorrow AM? Does/will Greg have what he needs to upload? --Larry Sanger 11:57, 4 March 2008 (CST)

Before it does go live, can someone investigate as to why the items above the edit box appear twice? This is a long standing issue :(. --Robert W King 12:05, 4 March 2008 (CST)

Greg has looked into it and hasn't had time to figure it out. That's not a skin issue anyway, so... --Larry Sanger 12:08, 4 March 2008 (CST)

Hold on just one more day. I want to get a few of the IE6 bugs squashed which will require me to go to work and use the old PC there to test it. Derek Harkness 19:41, 4 March 2008 (CST)

Another plug for an improved upper left logo

If any kind creative soul would like to take a few minutes to make a new upper left logo out of [1] that would be time well spent, I think. Send the results to bugs@citizendium.org for uploading...or to me if you want me to look it over first... --Larry Sanger 22:57, 4 March 2008 (CST)

Footnotes too large?

I've been looking over a few articles and I noticed that the footnotes seem to space the text a little too much -- if I'm quickly glancing over an article I can hardly tell the difference between the spacing of a new paragraph and the same paragraph broken up by a footnote. Anyone else agree with me? Nick Bagnall 00:46, 5 March 2008 (CST)

Integration with subpages

Has it been determined if this is possible? --Robert W King 10:25, 5 March 2008 (CST)

This will be possible but I'll have the recode part of the subpages template so that they use CSS rather than inline styles. Derek Harkness

`;D`

I imagine you're still working on it, but now everything appears about a page down from where it should be, and the edit box now spills beyond the page width.

"Recent changes" and "edit" both have a blank page at the top for me too. I'm using Firefox 2.0.0.12 for Windows. Warren Schudy 22:56, 5 March 2008 (CST)

This seems to have something to do with the

<div style=" width:1px; height:768px; float:left;"> </div>

appearing at the start of the "content" div in the HTML. I've no idea with this is doing there. -- Jitse Niesen 06:37, 6 March 2008 (CST)

The fix is on the way to Greg as I type. Derek Harkness 09:18, 6 March 2008 (CST)

Content still appears a page down from where it should be. --Robert W King 11:46, 17 March 2008 (CDT)

This should be fixed now. Derek Harkness 03:19, 22 March 2008 (CDT)

Checking in

I've been assuming you'll get in touch when the skin is ready to "go live"--right? --Larry Sanger 23:44, 7 March 2008 (CST)

autominor & autosummary

autominor= and autosummary= don't work (when appended in the address bar) on talk pages :( --Joe Quick 15:10, 16 March 2008 (CDT)

Nothing to do with the skin. Did you enable popups on the new skin? Derek Harkness 05:54, 17 March 2008 (CDT)

Are you sure? They work fine when I switch back to the regular skin. How do I enable popups on the new skin? --Joe Quick 11:10, 18 March 2008 (CDT)

Very sure. Refer to my reply here for solution.

Centered pix

Hi Derek, I believe the pictures in the left column of Main Page used to be centered (I believe they're properly coded to be centered), but they are flush left. It looks better with them centered... --Larry Sanger 12:40, 21 March 2008 (CDT)

Fix is coded and on the way to the server. Derek Harkness

More bugs

Skin is not wide enough; it causes templates and pages to incorrectly word-wrap or use scroll-bar. The left margin should be moved over about 100 pixels.
Some pages cause the skin to spill over the browser width, some do not. Especially if there are <pre> fields or percent widths.
<pre> blocks do not have any visible surrounding around them.
Also have a look at my user page. The graphics inside the image table are left-aligned, the table below does not correspond to the 33% widths I have defined.
There's also no VLINK color to indicate the status of already visited links.
There is a bug that pertains to headings and subheadings: there is an extra <br/> that can be seen especially on metadata pages.
See CZ:Templates, you should be seeing little squares around each + next to the folders.

--Robert W King 12:43, 21 March 2008 (CDT)

See Adjunction formula. Is it possible to make the backgrounds of the formulas transparent instead of white? --Larry Sanger 14:03, 21 March 2008 (CDT)

See #Formulas above for my suggestion; needs Greg or somebody else with access to the servers. -- Jitse Niesen 18:08, 21 March 2008 (CDT)

See below

there is a newline above this line

but not above this line.

I might be the only one who finds this annoyingly different from the old skin, but I doubt it... I think the above should be rendered without a newline above "there is a newline above this line". --Larry Sanger 14:50, 21 March 2008 (CDT)

I find that distressing also. Note, the next line starting with a ";" should be bolded but it isn't.

This should be in bold.

--Robert W King 14:52, 21 March 2008 (CDT)

I think the following fragment needs to be copied from skins/monobook/common.css to skins/Pinkwich5/common.css

dt {
	font-weight: bold;
	margin-bottom: .1em;
}
dl {
	margin-top: .2em;
	margin-bottom: .5em;
}
dd {
	line-height: 1.5em;
	margin-left: 2em;
	margin-bottom: .1em;
}

And to get the surrounding around the PRE blocks

pre {
	padding: 1em;
	border: 1px dashed #2f6fab;
	color: black;
	background-color: #f9f9f9;
	line-height: 1.1em;
}

This is just a quick fix; Derek might want to tweak the numbers to make it look better.

A super-quick fix which requires constabulary rights but not access to the server would be to put the above fragments in MediaWiki:Pinkwich5.css, but I'm not sure that will work. -- Jitse Niesen 18:08, 21 March 2008 (CDT)

I would do this if I was sure I wasn't going to screw it up... --Larry Sanger 19:49, 21 March 2008 (CDT)

The whitespace between comments has always been there. What I changed was to remove the white space form between the 2nd and 3rd comments. There was always a slight difference in the size of the spaces, look at the old monobook skin closely again. The reason for the spaces is that the first line of the comment is a paragraph, there should be a space after a paragraph. The second line is a definition list definition (without title). There shouldn't really be a big gap between title and definition but there should be a gap between definition lists and paragraphs and definition lists and another definition list. We abuse the dl, dt and dd tags on our talk pages. A different markup should have been used but it's too late in the game to change this now. I have adjusted the space between the paragraphs to match the space between dl items.

To demonstrate. This line

This line

and this line should be equally spaced

The same goes for this line

and this line: but this one should be on a shorter spacing.
followed by a big gap: then a short space again.

These won't be showing correctly now, but they will on the next upload.

Skin is not wide enough; No, this has always been variable. The skin will work on monitors set at 800x600px (the default size of windows 98) and a little smaller actually. It is optimised for 1024x800 screens (the typical setting in XP) and larger. Everybody's screen is a little different and always has been. Pages should be coded to fit variable sizes of screen — not your screen. Pages that don't adjust to smaller sizes should be altered.

"Some pages"? What pages? Provide a link please and I'll fix it.

<pre> is for pre-formatted text. It's not for drawing borders round things. There's no reason why pre should have borders and I can think of some reasons why it shouldn't. If you want a border round your text you should use <div> tags plus the relevant styles to show the border. The pre element should be an inline element, but in the wikipedia it is treated as a block level element.

"The graphics inside the image table are left-aligned." This is fixed as per my reply above to Larry.

"There's also no VLINK color" I'll add this once I decide which colour they should be.

"There is a bug that pertains to headings and subheadings" I've looked and I don't see any stray <br /> tags. If you mean there's more white space between headings and paragraphs, well yes there is, that's how they are supposed to be.

This was bold in the old skin.: But there's no rule that says it should be bold. However, I will make it bold because that probably looks best.Derek Harkness 08:17, 22 March 2008 (CDT)

There's no more box surrounding the "you have new messages" indicator.

there's no box surrounding the "Categories: " at the bottom of the page.

plainlinks

I noticed this function does not work. Most obvious example is the links in the "unused subpages" hidden box at the top of each talk page. It's no big deal but thought you might like to know. Chris Day (talk) 08:57, 22 March 2008 (CDT)

Didn't even know these existed. I've copied over wikipedia's styles for this. They should work on the next update.

At WP, these style and other template specific styles are put in via the font end by a sysop. That's probably a sensible thing to do as the person who has rights to edit the template should also have rights to edit the css that the template depends upon. Derek Harkness 09:39, 22 March 2008 (CDT)

Hi Derek, I have to agree that this is annoying--this is just to add another request that it be fixed...just tell me what to do to fix it, and I will. I could also give you special-function sysop rights if you want to fix it yourself directly, if you don't already have them. --Larry Sanger 10:40, 21 May 2008 (CDT)

suggestion: change color on "discussion" link

Hey, I like the skins.

So my suggestion is to try and make it easier for people to find the discussion link for when the subpage bar is not available - for example, when they go to a user page for the first time and try to find the talk page.

I spent a good 4 minutes, trying to figure out how to get from Larry's user page to his talk page. There are not subpage bar links on userpages so you can't hit the talk button on that...

Then I finally found the discussion link in the upper right corner.

Maybe, to make it easier to find this link if when people are on a talk page, the discussion link could have a color change that is a little more pronounced than the current color change.

Just an idea, though. It looks great overall! Tom Kelly 18:15, 22 March 2008 (CDT)

I understand your idea but the logic doesn't work through. There are many links and really you only want the one that you are looking for at that moment in time. All the other links get in the way. In your above example, you were looking for the talk page. Tomorrow it might be the history page or the upload file link or whatever. We can't make every link a special colour. Derek Harkness 06:18, 26 March 2008 (CDT)

feature I miss about the old/classic wiki skin - detect if discussion page was blank by the color

In the old skin, you could be looking at an article and tell if the discussion page was blank without clicking on it (it was red if it was blank or blue if something was on it). With the new system, you can't tell until you click discussion in the upper right corner. Thanks for your hard work, it is really paying off. Tom Kelly 15:05, 25 March 2008 (CDT)

Not quit true. There is a prompt that comes up from the subpages that ask for the talk page to be created if there is no talk page. For example, http://en.citizendium.org/wiki/Audrey_Landers . Also the talk link in the subpage template will be red. Chris Day 15:15, 25 March 2008 (CDT)

I was going to post that I had forgotten about that an will do it soon but then Chris has a good point. In CZ, the link to the discussion page should never be red because when you create an article you should add the subpages template to the talk page. Thus all article discussion pages are blue by default.

However, Chris, subpages don't go on other namespaces like CZ: or template: so the red link in these places may be useful so I will add the code when I have a chance.

Chris, do we really need two links to the talk page? Is not the talk link in he subpages template superfluous? Derek Harkness 06:23, 26 March 2008 (CDT)

Good point but it is different to the discussion link at the top. Within a cluster the talk link goes to one page only, either the Talk:Article or Talk:Article/Draft if approved. In this way discussion relating to the whole cluster can occur at one page. Chris Day 07:21, 26 March 2008 (CDT)

Sounds fine but if you want to do that you have to disable the other link. There are several subpages which have their own talk pages in existance and people will click one link one day and the other the next and wonder where the page went to. Could you add a line of code to the subpages template to hide the other talk link when the cluster is present but leave it visiable when the cluster does not exist. For example, if you add this line to the subpages template, then the other link will be hidden:

I have wrestled with this concept on and off, should we use one talk page alone or also use the subpage talk pages. i can see good reasons to have subpage talk pages active, which is why I have not pursued the option to shut them down completely. At present the subpage talk pages have a note at the top directing users to the main cluster talk page (if they have a subpage template at the top). If we close off the discussion tab at the top then there will be no way to easily link to those pages if they happen to be used. Is there an easy way to distinguish if the talk tab is distinct? Chris Day 10:34, 26 March 2008 (CDT)

You guys are over my head with the computer lingo. I just wanted to add that many pages, like user pages, do not have a subpage template - therefore, it might be necessary to have a way built in to the skin itself to get the discussion/talk page. Also, I don't mind have both ways of getting there on article pages. Tom Kelly 15:43, 27 March 2008 (CDT)

Return links

This is not a bug but the subpages all have redundant return links above the subpages template. Is there anyway to turn that function off in the skin or is it hardwired into mediawiki? Chris Day 11:25, 26 March 2008 (CDT)

I could disable it but I sometimes use it. There are pages, such as this one we are on now, which have subpages but no subpages template. The breadcrumbs are useful in such places. Derek Harkness 05:51, 28 March 2008 (CDT)

workgroup link?

I am struggling to find the workgroup link in the new skin. Should it go in the communication section? Tom Kelly 15:45, 27 March 2008 (CDT)

here is the page I am referring to - http://en.citizendium.org/wiki/CZ:Workgroups I can't find the link for it on the new skin. Tom Kelly 15:50, 27 March 2008 (CDT)

The links on the left are controled by the Sysops such as Larry, not by I. You need to direct your comments on this to Larry. (I was also looking for this link recently) Derek Harkness 05:49, 28 March 2008 (CDT)

I'll re-add the workgroups link in there. I'm sorry I removed it--that shouldn't be. --Larry Sanger 18:15, 31 March 2008 (CDT)

Nice touch!

Excellent touch with the rounded corners on the tables of contents. --Larry Sanger 18:15, 31 March 2008 (CDT)

But now after six weeks, I gotta add (repeating I'm sure what others have said above) that there are two particularly annoying bugs about the skin that need fixing:

Horizontal scrolling!
When the text in a table of contents happens to be narrow, the word "Table of contents" is cut off/not displayed.

--Larry Sanger 10:42, 21 May 2008 (CDT)

Can you point to the pages that have the scrolling problem. I suspect it's the article's code not the skin that is to blame. Derek Harkness 06:14, 22 May 2008 (CDT)

Usability essay

This skin change and a few other things have prompted me to write this essay on CA and usability. Comments welcomed. Petréa Mitchell 10:40, 12 April 2008 (CDT)

Suggestion

Hi Derek--I have to say it's a bit annoying that I have to click through on the talk page for an article to see whether there's anything on the page. It would be nice if, say, the bold were removed for talk pages that are blank. Another nice touch, though I don't know if this is something you can do with the skin (I doubt it), would be to make the date last edited alternate text when you mouse over any link... --Larry Sanger 14:26, 12 June 2008 (CDT)

Yes, I enjoy different color links - red when there is no information present, blue when there is. I don't know if it is possible since the template or metadata or whatever it is counts as edits. I think we need to find a way to make this happen though... even if we can't do it through the skin. It will make users less frustrated (especially if they are used to W.P.). Tom Kelly 15:08, 12 June 2008 (CDT)

As Tom points out, there are no blank talk pages. They all turned blue when we put the checklist/metadate onto them. Nothing the skin can do for that. The only place where the red link would show would be in the other namespaces like help: template: and CZ:. If you still want it done, I can do it quite easily. As for the date last edited, that would need to be done using the AJAX engine in Javascript. The popups addon gave the function you require. You could nudge the tech support team into fixing the bug report I sent them some time ago regarding popups. Derek Harkness 10:58, 14 June 2008 (CDT)

Template Bug Help?

Hi Derek, Larry Sanger pointed me to you to ask about a curious template rendering problem I am having. Have you got time to take a quick look at {{Props}}?--David Yamakuchi 07:30, 5 December 2008 (UTC)

I don't see any problems here that are skin related. It looks to me like you have a Template:Or or | in the wrong place or possibly missed one out that should be there. I'm no expert on Media wiki templates - I suggest you ask Chris Day if you haven't already. Failing that, break your template down in to it's basic components and test each part on its own. You should then be able to identify the section of code that contains the bug, and rectify it. Derek Harkness 16:04, 5 December 2008 (UTC)

Already done. See [2], [3], [4], and [5] The template was working. I'm pretty confident that the code I have there should work mainly because it had for months.--David Yamakuchi 19:21, 5 December 2008 (UTC)

The evidence that there is a problem on the wiki side is seen in Expand templates. If you use that page to expand the template {{Props|Material=Iron}} you will see that an unexpanded template appears in the output. That is the bug that was introduced in the recent wiki update.

Chris Day suggested there may be some new rules for templates, perhaps this is a case where something that used to be OK, is now against the rules. If that is the case I'll gladly stop spinning my wheels, I just don't know where to look to see documentation on the changes.

It's so odd, with all the history and tracking implemented in the MediaWiki software, the Version page doesn't have a "history" page associated with it. All your suggestions are greatly appreciated, BTW--David Yamakuchi 19:21, 5 December 2008 (UTC)

Problems on on the wiki script are not something I can fix. I just take the output of the wiki script and make it look nice. If the wiki script outputs rubbish then all I can do is make the rubbish look nice. For bugs in the wik script you need to go to http://www.mediawiki.org/

I'd still recommend following the procedure above. There is always more than one way to do something in programing (template included). Split up your code, find the section that no longer works and then find another way of doing a similar thing. Derek Harkness 02:03, 6 December 2008 (UTC)