[Warning, long email ahead...]<br><br>Amilcar, this mail mainly concerns you (but of course Niko and others might have opinions too) - anyways if you find some time, could you briefly take a look at the following things, put your webmaster hat on and make some decisions... :-)<br>
<br>(Deciding whether or not to include the "additional features" and "content changes & restructuring" stuff can be delayed until after the new style is finished (and has gone live). The clean-up stuff, however, should be decided now, as this strongly affects the ongoing CSS implementation.)<br>
<br><font size="4">A. <b>Clean-up</b></font><br><br>Until now, as far as I can see, the implementation of the CSS for the new style (mainly by Niko) was done in such a ways as to keep the current HTML of the website intact wherever possible, at most putting in additional divs or class names.<br>
While we could certainly continue on that road and get the CSS finished with none or very few further HTML changes, I'm finding more and more reasons for possibly taking another approach. But of course it's your decision...<br>
<br>The following constitute potential HTML changes, which:<br> a) are not technically required for implementing the new CSS design<br> b) however would make the process easier and/or give a better (less bugs/corner-cases) and cleaner (easier-to-maintain) result<br>
 c) would break the old CSS style though<br> <br>(In case you don't mind considerable changes being made to the HTML markup wherever one of us (Niko, you, me) sees fit, and you don't care about keeping the HTML compatible with the old CSS style, just say so, then you don't need to read the rest of this section...)<br>
<br>In detail, I propose to:<br><ol><li><b>Get rid of "moduleentry" everywhere</b><br><br>In the old style, <i>every</i> little piece of the website was a box, end they all looked the same, so having <div class="moduleentry"></div> wrappers all over the place which could all be styled through unified CSS markup made sense.<br>
<br>However, in the new style, the actual page content is not made up of boxes anymore: Simple semantically correct markup of the form "<span style="color: rgb(0, 0, 0);"><h1>Page title</h1> <p>...</p> <h2>Section 1</h2> <p>...</p></span>" should suffice.<br>
There are only three kinds of boxes in the new design, and they all need <i>different</i> CSS markup: 1) the boxes for the navigation menu (left column), 2) those for the quick-access links (right column), and 3) those for highlighting important pieces of content such as the "What is KDevelop" box on the front page (currently this is not planned to be used anywhere other than on the front page).<br>
<br>I propose the following resolutions regarding all those div.moduleentry's:<br><br><ul><li><i>Navigation Menu boxes (left column):</i>  rename to div.navbox</li></ul><ul><li><i>Quick Access boxes (right column):  </i>rename to div.quickbox</li>
</ul><ul><li><i>Important Content boxes (on front page):</i>  rename to div.importantbox</li></ul><ul><li><i>all other occurences:</i>  simply remove without replacement - no need for those anymore!</li></ul><br>The main advantages will be:<br>
<ul><li><i>more semantically correct HTML</i> (no superfluous invisible div's that are not used at all; also, the "div.header > h3" of each modulebox would be replaced by whatever actually makes sense in each specific context, e.g. <h2></h2> if it's a normal page section.)</li>
<li><i>more readable HTML and CSS</i> (because of more meaningful class names!)</li><li><i>more flexibility</i> (e.g. applying the quick-access box style to "div.quickbox" directly instead of "#quickoverview div.moduleentry" would make it easier to add other quick-access boxes in the future which are *not* part of a dedicated "#quickoverview" column, like for example in my "News Page" mockup which shows a quick-access box with text floated around it. In general, I think it's good practice to make CSS styling of any element as agnostic about the surrounding page structure as possible, and choose meaningful class names accordingly.)</li>
<li>less headaches for Niko and me while implementing the CSS style :-)<br></li></ul><br></li><li><b>Unified, sensibly-named layout columns on all pages</b><br><br>On the front page, the actual page content (i.e. the middle column of the layout, which is surrounded by the header/footer/navigation bars and link boxes) is currently wrapped inside <div id="news"></div>, even though the actual News section forms only a small part of it.<br>
It should be renamed to <div id="maincontent"></div>, like it is already called on all other pages (which don't have a right layout column).<br><br>A truly unified handling of columns on all pages might be easiest to implement if point 4 ("fluid columns layout") is implemented, because then the CSS styling for the main (center) column might not even care whether there is a right column or not.<br>
<br></li><li><b>Unified markup for lists of aggregated news/blog items</b><br><br>The "KDevelop News" and "Developer blog posts" lists show information that has the same logical structure (except for an additional "source" field in the latter), and they are supposed to show this info with exactly the same visual style.<br>
Yet, they currently have very a different HTML structure ("p.newsDate, h2, p" opposed to "div [h4 [span.date], div.entry-content]") and hence two separate sections in the CSS file.<br>This should be replaced by unified HTML markup combined with CSS that's agnostic towards the "type" of the news as well as the surrounding page structure. The last part also means that heading elements (h2, h4, etc.) should not be used here, as the whole thing can appear at different levels of the logical page structure (compare news lists on front page and news page) without it's style being affected.<br>
<br></li><li><b>(Possibly) switch from the current <i>absolutely-positioned columns</i> layout to a <i>fluid columns</i> layout...</b><br><br>...using either floated or display:inline'd div's.<br>This <i>might</i> require HTML changes such as switching the order in which the individual columns are defined in the HTML markup.<br>
It could help with making the layout more rubust regarding different page-content-dimensions and screen resolutions, however I'm not sure yet whether it will actually be necessary.<br></li></ol>  <br><font size="4">B. <b>Additional features</b></font><br>
<ol><li><b>Breadcrumbs bar</b><br><br>(as seen in the mockups)<br>Amilcar, you're the expert on this (you created the Sitemap page...) - would breadcrumbs be difficult to implement?<br>Will it be possible to have "virtual pages"/categories in the breadcrumb hirachy, e.g. show "News >> News of 2007" even though there isn't actually a "News" page, only "News of X" pages (clicking on it in the breadcrumb bar would either bring you to the most recent (current year) news page, or not be clickable at all).<br>
<br></li><li><b>Quick-access boxes for horizontal links within page classes</b><br><br>Quick-access boxes are intended to also show up in various places other than the "Downloads", "Support" and "How to contribute" boxes on the front page (of course, those specific ones should only be shown on the front page).<br>
<br>Specifically, I think pages that are part of a "class" of similar pages differentiated by a linear parameter (such as calendar year or KDevelop version) should show a right-aligned, floated quick-access box with links to the other pages of the same "class".<br>
As an example for what I'm talking about, see my 'News page' mockup (link at <a href="http://sam.megabyet.net/kdevelop-website-design/">http://sam.megabyet.net/kdevelop-website-design/</a>) which shows the 'News of 2007' page with a quick-access box for the 'News of year X' class.<br>
As another example, the 'KDevelop 4.0 Screenshots' page should show a corresponding quick-access box for the 'KDevelop X.X Screenshots' class, and so on (this would effectively replace the "Other versions" section at the bottom of the page).<br>
</li></ol>  <br><font size="4">C. <b>Content changes & restructuring</b></font><br><ol><li><b>Cleaning up the top links</b><br><br>--> only Download, Features, Screenshots<br>(Niko has already done this on the test site.)<br>
<br></li><li><b>Cleaning up and restructuring of the navigation menu links (left column)</b><b> for KDev4.x</b><br><br>Back when my proposal for the new website design was first discussed, I think it was agreed upon to remove the "Links" section from the navigation menu, as it doesn't link to any useful content anymore.<br>
<br>In addition to that, I've made various other changes to that menu in my mockups compared to the current state of the website. These changes can be seen as suggestions for a cleaner and more easily-accessible navigation menu. What do you think?<br>
<br></li><li><b>Rephrasing the "What is KDevelop and KDevPlatform" text on the front page</b><br><br>(my suggestion can be seen in the mockups.)<br><br></li><li><b>A dedicated 'About' page</b><br><br>This would be the page that you get to when clicking the "About" link in the left navigation menu as I propose it.<br>
Also, the "more info..." links in the "What is KDevelop and KDevPlatform" and "KDev3 vs KDev4" boxes on the front page would link to this page.<br>It would be a simple static page, not one that needs to be duplicated for each release like e.g. the screenshots page.<br>
It's purpose would be to:<br><ul><li><i>explain what KDevelop is, what it is not, what it's purpose/goal/vision is, etc.</i> (more verbose than the text on the front page, but without going into technical details - for that, it should refer to the 'Features' page)</li>
<li><i>explain what KDevPlatform is</i></li><li><i>explain the difference between KDev3 and KDev4</i> (in general terms, more verbose than on the front page, but not comparing all the individual features - for that, it should link to the wiki page with the comparison table.)</li>
<li><i>explain who is behind the development of KDevelop</i> (explain its open-source nature, it's relation to the KDE project, etc.), and link to the 'Authors' page of the current release.</li><li><i>link to the FAQ page</i> (as that is not linked to in the navigation menu)<br>
</li></ul><br></li><li><b>A dedicated 'Features' page</b><br><br>This would ideally present KDevelop's features with detailed text and close-up pictures in a professional manner. I have some cool ideas for that, but they'll have to wait for now as I'm focusing on the CSS re-design currently :-)...<br>
<br>For now, even an empty page with just one sentence that states that this page has not been finished yet and in the meantime links to Andreas's release anouncement would imo be much better than linking to some section of some wiki page directly from the "Features" top menu link. That's just unprofessional imo (for such a "core" page of the website), and also it means there's no easy way to reach the KDevelop 3 features page then (since wiki pages don't integrate with the "See also: This page for KDevelop version x.x" paradigm).<br>
<br></li><li><b>New pages for everything else that doesn't have a KDev4-page yet but appears in the main menu or quick-access boxes in my mockup...</b><br><br>...especially "User Manual", "Tutorials", "Tips & Tricks", and the various "How to contribute" links.<br>
It wouldn't matter if these were only empty wiki pages initially with only one or two sentences, and only slowly gain content after time. Still better than nothing, or than linking to outdated stuff by default.</li></ol>
Phew!<br>I didn't actually intent to write this much when I started the email<a href="http://www.dict.cc/?s=%5Bcoll.%5D"><kbd title="colloquial"></kbd></a>...<br><br>Anyhow, have a nice week y'all!<br><br>Sam<br>