proposal for kdevelop.org new website design

[Sam S.]

[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100509/f852f46a/attachment.html>