Devmo has a new skin that is ready for testing. If you go to your user preferences, you can change the skin to "Devmo". This is currently just a preview, but we would appreciate help with testing.
Please add any feedback to this page. Thanks!
Feedback
- Fix weird width bug on Preferences page. --dria
- CSS classes for Feature and Subfeature boxes, including required graphics. -- dria
- When will these fixes be on the live site? --Nickolay 10:38, 31 Aug 2005 (PDT)
- Existing fixes should be on test/docs/ now. --dria
Stuff That's Been Fixed
Note that while I've made these fixes, they haven't necessarily been checked in yet.
- Edit page textarea needs to 'scale' better with page width (so large whitespace area's are non-existant), suggest min-width:some-em-size; width: 88%; and max-width set to 95% or something like that. --Callek
- I tried this, but it gets totally screwed up in IE for some reason. I'll try again, but can't guarantee this will be fixed for the initial upgrades. --dria
- Took two days, but I finally got this sorted out. When the skin is updated on test/docs, editform textarea should be resizeable in all browsers. Yay! --dria
- I tried this, but it gets totally screwed up in IE for some reason. I'll try again, but can't guarantee this will be fixed for the initial upgrades. --dria
- WordPress skins need footer information. -- dria
- When a page is redirected, need to say-so and what it was redirected from, (see document for an example of such.) This is only an issue in MW1.5 so far. Devmo Skin vs Cavendish Skin --Callek
- I can probably pull-off this patch if needed (quickly), so dria or others do not have to hunt up "how". --Callek
- Add "what not to do" css class to stylesheet, as discussed on Talk:Core JavaScript 1.5 Reference.
- What's the class called? --Maian 21:08, 1 Sep 2005 (PDT)
- In the new MW1.5 skin (not the one currently available here) there's class "wrong" and class "wrong-inline". Those will be available after we do the wiki upgrades in the near future. --dria
- What's the class called? --Maian 21:08, 1 Sep 2005 (PDT)
- Headers need a little padding. H1 could be smaller. --dria
- Is it just me or visited links are not marked as such? --Nickolay 07:16, 29 Aug 2005 (PDT)
- Imho the visited color looks horrible. We're a documentation site. There's no real reason for user to give him info that he already visited XML main page. It's hardly possible that he'll be interested in it. In all other dev centres there is no "visited link color" and we should remove IMHO. It looks odd when someone who uses Devmo on regular basis sees some violet links just because he already worked with this site yesterday.
Also, the current color for visited links makes them less visible. --Gandalf 00:45, 31 Aug 2005 (PDT)- I don't like the current color too, but I strongly disagree that we don't need to give visited links different color. This is not what user expects (well, I don't expect sites to style visited and non-visited links the same), and it's false that other documentation sites do this (I just checked Apple's and Microsoft's sites). Your statement that "It looks odd when someone who uses Devmo on regular basis sees some violet links just because he already worked with this site yesterday" holds true for every single place on the web, yet visited links use different styling on most sites. --Nickolay 01:34, 31 Aug 2005 (PDT)
- Ok, so I'm asking just to change this color. --Gandalf 04:55, 31 Aug 2005 (PDT)
- Fine, changed. --dria
- Ok, so I'm asking just to change this color. --Gandalf 04:55, 31 Aug 2005 (PDT)
- I don't like the current color too, but I strongly disagree that we don't need to give visited links different color. This is not what user expects (well, I don't expect sites to style visited and non-visited links the same), and it's false that other documentation sites do this (I just checked Apple's and Microsoft's sites). Your statement that "It looks odd when someone who uses Devmo on regular basis sees some violet links just because he already worked with this site yesterday" holds true for every single place on the web, yet visited links use different styling on most sites. --Nickolay 01:34, 31 Aug 2005 (PDT)
- Imho the visited color looks horrible. We're a documentation site. There's no real reason for user to give him info that he already visited XML main page. It's hardly possible that he'll be interested in it. In all other dev centres there is no "visited link color" and we should remove IMHO. It looks odd when someone who uses Devmo on regular basis sees some violet links just because he already worked with this site yesterday.
- The default link color is to bright. It's less readable than the old one. I'd suggest to use the color from Cavedish. -- gandalf
- That was my first thought, too. -- AxelHecht
- Ok, I'll tone the main link colour down a bit. --dria
- That was my first thought, too. -- AxelHecht
- Page title needs "Development Skin" removed. -- dria
- The skin looks nice, but the links on the right are too small. If this is going to be the default skin used by editors, they are unacceptably small. --Nickolay 01:59, 25 Aug 2005 (PDT)
- I'm planning on doing up a special skin for editors in the future (with the edit tools and such closer to the top, etc). In the meantime, I'll bump the font size of those links up. --dria
- But if the editors use a different skin, they won't have an easy way to make sure the pages look good to end-users. --Nickolay 04:43, 25 Aug 2005 (PDT)
- The skin won't be that different -- it will just have the editor tools moved around. The main content layout will not change. --dria
- But if the editors use a different skin, they won't have an easy way to make sure the pages look good to end-users. --Nickolay 04:43, 25 Aug 2005 (PDT)
- I'm planning on doing up a special skin for editors in the future (with the edit tools and such closer to the top, etc). In the meantime, I'll bump the font size of those links up. --dria
- The color of the internal and extenrnal links is now the same, is that intentional? --Nickolay
- I didn't ever notice that they were different, honestly. I'll take a look. --dria
- Ok, the difference on the cavendish theme is negligible (to the point where I never noticed). Direct external links have icons to differentiate them from internal links, so I think we'll just leave the internal/external links colours the same. ==dria
- You've got to be kidding me, the colors are clearly different (rgb(0,51,153) vs rgb(51,102,187)). --Nickolay 09:19, 25 Aug 2005 (PDT)
- Ok, the difference on the cavendish theme is negligible (to the point where I never noticed). Direct external links have icons to differentiate them from internal links, so I think we'll just leave the internal/external links colours the same. ==dria
- I didn't ever notice that they were different, honestly. I'll take a look. --dria
- (moving this to a new item) On the contrary, the list of categories current page belongs to, should be near the footer (see MDC:Policies_and_guidelines page) (dria: fix catlinks style)
- The arrows that appear if you select "Enhanced recent changes" in your preferences have an ugly border around them. --Nickolay 04:43, 25 Aug 2005 (PDT)
- The radio buttons on history page are jumping in a weird way because the selected row becomes bold. --Nickolay 04:46, 25 Aug 2005 (PDT)
- The sidebar overrides content on diff pages --Nickolay
- Turns out this was fixed for 1.5 already. --dria
- the buttons in the upper-right of the horizontal nav-bar don't really feel like buttons; maybe add a pseudo-class for onHover that gives them an underline? --beltzner
- the "+" item under the "Views" menu of a discussion page looks really out of place. Can we replace it with "Add section" or something? --beltzner
- I'll look into it, but I think this is one of those "don't hold your breath" things because that's not managed by the skin. I could probably just eliminate it entirely.
- that'd work, too; you'd mentioned that it was very rarely used --beltzner
- I'll look into it, but I think this is one of those "don't hold your breath" things because that's not managed by the skin. I could probably just eliminate it entirely.
- The category template must be improved, it looks very unpolished comparing to rest of Devmo. -- gandalf
- Unfortunately the Category styling is very much embedded into the MediaWiki code. There are some other changes I need to make, however, so I'll try to fix it up a bit while I'm digging around in there. --dria
- How about modifying style for the side-bar to have a :hover class added which modifies (to a slightly lighter shade) the background color of the link, this will help to make items "appear as links" to many users, possibly add a text-decoration: underline as well. --Callek
- Is it possible to remove the blank space on category pages, like Category:DOM?
By the way, it looks like this skin has the same problem as previous - the edit box, category list on category pages, and others are always below the end of the sidebar. The major problem it caused in Cavendish skin - that they were out of the screen - is solved by making the sidebar smaller, which is not the right thing to do, IMO (see my comment 1).--Nickolay 02:11, 25 Aug 2005 (PDT)- Yeah this is actually a problem with MW, rather than the skin -- they use a <br style="clear:both" /> in some pretty annoying places. I'll try to get those fixed today. --dria
- Well, with mediawiki skin, you can have the clear:both's in content area without a problem. I understand it might be hard to fix in the skin, but it is very desirable (because we sometimes use the floats and 'clears' in our pages). --Nickolay 04:52, 25 Aug 2005 (PDT)
- The clear/boths aren't in the content, they're embedded style information in the .php files in the /includes directory. It's just sloppy coding. I cannot think of any reason for writers or editors to add "clear:both" brs to their document. Under what situations does this seem like something that should be embedded directly into the wiki content? --dria
- When using floated divs - images and such. If you don't use it they overlap with headings, which is something we seldom want. See for example the venkman tutorials (although the clears are down the page) or MDC:Frequently Asked Questions. I'm not saying this can't be worked around, just that it would be better if the skin coped with that fine. --Nickolay 05:46, 25 Aug 2005 (PDT)
- Ok, I'll see what I can do. Thanks for pointing it out. --dria
- When using floated divs - images and such. If you don't use it they overlap with headings, which is something we seldom want. See for example the venkman tutorials (although the clears are down the page) or MDC:Frequently Asked Questions. I'm not saying this can't be worked around, just that it would be better if the skin coped with that fine. --Nickolay 05:46, 25 Aug 2005 (PDT)
- The clear/boths aren't in the content, they're embedded style information in the .php files in the /includes directory. It's just sloppy coding. I cannot think of any reason for writers or editors to add "clear:both" brs to their document. Under what situations does this seem like something that should be embedded directly into the wiki content? --dria
- Well, with mediawiki skin, you can have the clear:both's in content area without a problem. I understand it might be hard to fix in the skin, but it is very desirable (because we sometimes use the floats and 'clears' in our pages). --Nickolay 04:52, 25 Aug 2005 (PDT)
- Yeah this is actually a problem with MW, rather than the skin -- they use a <br style="clear:both" /> in some pretty annoying places. I'll try to get those fixed today. --dria
- External link icons missing on IE version of skin. --dria
- Edit/Preferences/Diff pages end up being too wide at times. Definitely need to fix for IE. --dria
- The edit section links are gone (they are only shown in normal skin if you set the appropriate preference). --Nickolay
- Do you know if there's a LocalSettings variable to have the edit-section links off by default? It appears that they're on by default right now. --dria
- Yeah, I think we want them off by default, as the more common case for a reader will be to read documentation, not to edit it. --beltzner
- Put these back in. Will try to sort out how to change the default behaviour. --dria
- Headers which are also links that point to as-yet-unwritten wiki pages are colored as though they actually do exist. For an example of this, see Creating XPCOM Components. --Waldo 21:09, 25 Aug 2005 (PDT)
Not Going to Change (Yet or possibly Ever)
- Adding pipes between buttons in horizontal nav-bar (ie: My talk | Preferences | My watchlist) (stricken part is done). Also, and this is a nit, it's a little "my" crazy up there -- do we need all the "My"s? --beltzner
- Any chance we can mobe the "main page" scrollbar to the actual "content area" of the page, so that the sidebar `stays` when in-use, and on dynamic pages (such as the preferences page) if you toggle between something that needs a verticle scrollbar and something that doesnt, you get screen-jitter; if this is not-feasable, perhaps some method to have a viewport scrollbar always appear for the vert direction. minor-nit. --Callek
- I couldn't find a quick "logout" link accessible from everywhere. --mmondor 12:25, 26 Aug 2005 (PDT)
- What pages can you not find a logout link from, I see it on nearly all devMo wiki pages in the "upper right: along with "My Talk" "Preferences" etc.
- Oh, I went back to login page, logged in and then from there went to the /test/ pages and it's like the old look (with menu bar at the left), where indeed, the logout link is as it should be on the left in personal tools. --mmondor 12:49, 26 Aug 2005 (PDT)
- The logout link is exactly where the login link is. This makes sense as-is. Not changing. --dria
- Oh, I went back to login page, logged in and then from there went to the /test/ pages and it's like the old look (with menu bar at the left), where indeed, the logout link is as it should be on the left in personal tools. --mmondor 12:49, 26 Aug 2005 (PDT)
- What pages can you not find a logout link from, I see it on nearly all devMo wiki pages in the "upper right: along with "My Talk" "Preferences" etc.
- The menu column seems larger than before in the current test theme, so as to cause some reference pages to look ugly when browser set in 800x* resolution, using the default FireFox 1.0.6 fonts settings on XFree86. A few examples: , .
These work fine with the old theme, and I expect that this affects a lot of reference articles. That our screen resolutions are now wider than 800 pixels width does not mean that we always want to enlarge the window that large and as a result get extra-wide unreadable text lines :) and some people really are restricted to 800 (we can ignore 640, this will most likely require fonts settings changes as well). But it should work by default with 800 pixels width, IMO. --mmondor 11:54, 26 Aug 2005 (PDT)- For all that it is worth, I am against setting the 'base' font-size to anything other than 100%, let the User figure out which font-setting is best for him/her on his/her computer, rather than tweak it to what the designer feels is the right size for the designers eye(s). If the designer wants smaller text, tweak his UA's text size off of the base, for 100% page specified text. And when done, verify that the designer did not break the page with a "normal" font setting, by using a default profile. And no, break in that sense does not mean "font is too big" it means, still useable for the target audience. --Callek 12:02, 26 Aug 2005 (PDT)
- The font size isn't the problem, and we indeed shouldn't change it. The menu bar at the right, however, is too large in the new system, but is fine on the current (non-test) system. --mmondor 12:25, 26 Aug 2005 (PDT)
- Hmm, note that when logged-in, the theme is all fine like the old one, it's when a user doesn't login and reads the docs through the test site that the menu bar then is at the right and is slightly too large... --mmondor 12:52, 26 Aug 2005 (PDT)
- will revisit sidebar width later. --dria
- For all that it is worth, I am against setting the 'base' font-size to anything other than 100%, let the User figure out which font-setting is best for him/her on his/her computer, rather than tweak it to what the designer feels is the right size for the designers eye(s). If the designer wants smaller text, tweak his UA's text size off of the base, for 100% page specified text. And when done, verify that the designer did not break the page with a "normal" font setting, by using a default profile. And no, break in that sense does not mean "font is too big" it means, still useable for the target audience. --Callek 12:02, 26 Aug 2005 (PDT)
- I see that it was activated as default for non-logged in people already, it appears that there is no intention whatsoever to fix this at current time, since it's been placed in this section. Just so that (perhaps) this might revive the topic, a side bar shouldn't exceed 16% to allow proper viewing at 800 pixels width ideally in my opinion, I find strange that I'm the only person not too fond of large side bars (or side bars at all, for that matter :) considering that in most articles we scroll down to read the text, and that the side bar scrolls as well, the links aren't there anymore, but the width remains wasted anyway. In the case of a story book, small text columns do seem reasonable, but I don't think this is nice for technical documentation which requires usage of tables, etc... Wikipedia's side bar is smaller, btw, probably for the same reasons. Since I manage a number of sites for which I must respect quality standards at 800 pixels width for compatibility (we accept break 640 compatibility nowadays except for sites intended for PDAs/PPCs), I find myself needing to use ctrl+- with the devmo wikki currently, not to change my global settings of course, which are fine and factory-default, working well with the other sites I visit regularily or manage... Thanks again --mmondor
Future Fixes
- In l10n versions there all heading links are wrong - main link and documentation leads to english Devmo, and DevNews and Webwatch should be hidden or localized too. --Gandalf 01:30, 29 Aug 2005 (PDT)
- We'll revisit this later. Tab links are currently as intended. --dria
- No, they're not. When I'm on polish devmo and I click on Documentation or main Devmo logo I'm redirected to english version. It's a bug. --Gandalf 00:39, 31 Aug 2005 (PDT)
- Link URL fixed for wiki skin only. Tab text will currently remain untranslated ("Documentation"). DevNews and WebWatch are not currently being localised so shall remain as they are, with link to english wiki. --dria
- No, they're not. When I'm on polish devmo and I click on Documentation or main Devmo logo I'm redirected to english version. It's a bug. --Gandalf 00:39, 31 Aug 2005 (PDT)
- We'll revisit this later. Tab links are currently as intended. --dria
Further Notes and Ideas (Future)
- Skin designed more for the editorial crowd, with the editor tools more prominently placed in the skin. The core format would be the same as "default", however.
- Skin designed with simplicity in mind -- minimal header, nav, footer -- plausibly good for alternate or small screen display, or people who prefer more straight-up formatting for on-screen docs.
- Skin designed specifically with accessibility in mind. Might want to consult with aaronlev to see what would be best. Also see about improving accessibility of default skin.
- We definitly need to add some UI to multipage stuff like tutorials. Things like TOC and back/forward and "page X of Y" are extremly needed - it can be that they'll land in sidebar --Gandalf 08:27, 29 Aug 2005 (PDT)
- We'll revisit this later. This is too complex to deal with right now, unless someone wants to write and submit an extension. --dria