[prev in list] [next in list] [prev in thread] [next in thread]
List: kdevelop-devel
Subject: Re: proposal for kdevelop.org new website design
From: "Sam S." <smls75 () gmail ! com>
Date: 2010-05-09 17:33:09
Message-ID: g2h391a1b301005091033lb48362c0nb016b2821426263d () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
[Warning, long email ahead...]
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... :-)
(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.)
A. *Clean-up*
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.
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...
The following constitute potential HTML changes, which:
a) are not technically required for implementing the new CSS design
b) however would make the process easier and/or give a better (less
bugs/corner-cases) and cleaner (easier-to-maintain) result
c) would break the old CSS style though
(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...)
In detail, I propose to:
1. *Get rid of "moduleentry" everywhere*
In the old style, *every* 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.
However, in the new style, the actual page content is not made up of
boxes anymore: Simple semantically correct markup of the form "<h1>Page
title</h1> <p>...</p> <h2>Section 1</h2> <p>...</p>" should suffice.
There are only three kinds of boxes in the new design, and they all need
*different* 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).
I propose the following resolutions regarding all those
div.moduleentry's:
- *Navigation Menu boxes (left column):* rename to div.navbox
- *Quick Access boxes (right column): *rename to div.quickbox
- *Important Content boxes (on front page):* rename to div.importantbox
- *all other occurences:* simply remove without replacement - no need
for those anymore!
The main advantages will be:
- *more semantically correct HTML* (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.)
- *more readable HTML and CSS* (because of more meaningful class
names!)
- *more flexibility* (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.)
- less headaches for Niko and me while implementing the CSS style :-)
2. *Unified, sensibly-named layout columns on all pages*
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.
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).
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.
3. *Unified markup for lists of aggregated news/blog items*
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.
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.
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.
4. *(Possibly) switch from the current absolutely-positioned
columnslayout to a fluid
columns layout...*
...using either floated or display:inline'd div's.
This *might* require HTML changes such as switching the order in which
the individual columns are defined in the HTML markup.
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.
B. *Additional features*
1. *Breadcrumbs bar*
(as seen in the mockups)
Amilcar, you're the expert on this (you created the Sitemap page...) -
would breadcrumbs be difficult to implement?
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).
2. *Quick-access boxes for horizontal links within page classes*
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).
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".
As an example for what I'm talking about, see my 'News page' mockup (link
at http://sam.megabyet.net/kdevelop-website-design/) which shows the
'News of 2007' page with a quick-access box for the 'News of year X' class.
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).
C. *Content changes & restructuring*
1. *Cleaning up the top links*
--> only Download, Features, Screenshots
(Niko has already done this on the test site.)
2. *Cleaning up and restructuring of the navigation menu links (left
column)** for KDev4.x*
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.
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?
3. *Rephrasing the "What is KDevelop and KDevPlatform" text on the front
page*
(my suggestion can be seen in the mockups.)
4. *A dedicated 'About' page*
This would be the page that you get to when clicking the "About" link in
the left navigation menu as I propose it.
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.
It would be a simple static page, not one that needs to be duplicated for
each release like e.g. the screenshots page.
It's purpose would be to:
- *explain what KDevelop is, what it is not, what it's
purpose/goal/vision is, etc.* (more verbose than the text on the front
page, but without going into technical details - for that, it
should refer
to the 'Features' page)
- *explain what KDevPlatform is*
- *explain the difference between KDev3 and KDev4* (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.)
- *explain who is behind the development of KDevelop* (explain its
open-source nature, it's relation to the KDE project, etc.), and
link to the
'Authors' page of the current release.
- *link to the FAQ page* (as that is not linked to in the navigation
menu)
5. *A dedicated 'Features' page*
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 :-)...
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).
6. *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...*
...especially "User Manual", "Tutorials", "Tips & Tricks", and the
various "How to contribute" links.
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.
Phew!
I didn't actually intent to write this much when I started the
email<http://www.dict.cc/?s=%5Bcoll.%5D>
...
Anyhow, have a nice week y'all!
Sam
[Attachment #5 (text/html)]
[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>
--
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic