Re: implementing webdesign for plone



--On Mittwoch, August 26, 2009 10:52:29 -0300 Vinicius Depizzol
<vdepizzol gmail com> wrote:

Hello, everyone.

I completely agree that having a different navigation lists according
to the page is not a good way to make it simple for the user. I
changed the pages and now all of them are using the standard sidebar
navigation list.

However, it might be a good idea to at least allow something like
that. Special pages (like the Release Notes) may have a 1-column
content, like Firefox does[1] (a content like this is actually very
easy to create using the grid system).

[1] http://www.mozilla.com/en-US/firefox/features/

I'm not sure release notes will be managed with plone. But anywhere an
editor can turn of the content of the sidebar like navigation. Then
the one column styles are used.

I updated the template during the weekend and now it is using the way
you suggested. Instead of using <div class="grid_9"> and <div
class="grid_3"> for both content and sidebars, #container now can have
<div class="content"> and <div class="sidebar">, with an optional
.two_columns.

# container still needs to use class container_12, since all the grid_*
classes need this as inherit element.

Do you think is a good idea to allow the edition of the pages using a
WYSIWYG editor? Won't it generate ugly source code? We need to make
sure the content of the page will be clear as handmade html. And since
we are using <div class="grid_*"> in several pages for handling
columns in the content, I think we need to have more control than a
visual editor can offer.

The overall layout is delivered from a cms. The main texts (on "normal"
pages one text area) are edited by a wysiwyg editor (kupu or TinyMCE). I
would rate the html created by the editor delivers html as acceptable (only
tags and classes, no stupid attributes like style or font). It's not
realistic (and in any case not productive) to let editors write html. A
text markup language (ala markdown, in our case called ReST) would be
possible, but not much better then html.
The output from the editor is fitted into the layout, together with many
other parts (the title, the vertical navigation, the horizontal navigation
box in the 2nd levels, maybe a marketing box or a box with a feed from
plant.gnome.org, ...). Which layout is used is decided by the cms (via the
output it generates).

In the end it means that, in the page a visitor sees:
* the layout elements are taken mostly directly from your template
* the content (html child nodes) of #title, #content, #sidebar #navigation
  etc. are the output of the cms.
* the output of a wysiwyg editor will (mostly) always go into #content

You can see a sample output of how a page looks like when it is mostly
edited with the wysiwyg editor here: <http://gnome.rehfisch.de/downloads>
(note: old content and before the navigation box work Johannes did).

..Carsten

Thank you.

On Fri, Aug 21, 2009 at 14:10, Carsten Senger<senger rehfisch de> wrote:
Hi all,

--On Freitag, August 21, 2009 16:51:33 +0200 johannes raggam
<raggam-nl adm at> wrote:

hey,

- regarding to the templates, the submenus are shown in 2 different
locations. for a few items the submenu is next to the title. if there
are more items the submenu is in a block on the right side. i created
some deliverance rules which put the submenu to these locations,
dependend on the number of submenu-items (less then 4: next to title. 4
or more: right side).

I suggest to use the vertical navigation box in all sections for
different reasons:
* The inline navigation breaks if content editors set longer titles.
* It doesn't work as good as the vertical navigation with bigger font
 sizes.
* Different kinds of navigation in different section make it
 harder for a visitor to navigate. When they switch to a section with
 the other kind of navigation the navigation isn't where they expect it
 to be, they have to search for it.
* The inline navigation is harder to identify as a navigation.
* It's much more simple for the theme implementation (the navigation in
 plone is already a box in the right column so we can have more general
 rules to put this content into the theme templates)

Markup/Css
----------

We should modify the markup and the styles to have a simple way to
switch the 2-column layout. We should do this anyway cause we should plan
to have other content than the navigation in the sidebar sometimes.
In this turn, we should replace some grid_* and container_* with generic
identifiers that we can use to style them differently in different
situations.

I suggest to use such a template structure:
 <div id="container">
  <div id="content">... (now it's id="content" class="grid_12")
  <div id="sidebar">... (now it's class="grid_3")
 </div>

We switch between the one and two column layout by changing the
container's identifiers to <div id="container" class="two-column">
(and maybe dropping #sidebar from the template) depending on the CMS
output. The result that is delivered to the browser looks like this::

 <!-- one column layout -->
 <div id="container">
  <div id="content">...
 </div>

or::

 <!-- two column layout -->
 <div id="container" class="two-columns">
  <div id="content">...
  <div id="sidebar">...
 </div>

In the css, we add our selectors to the definitions of container_12,
grid_12, grid_9 and grid_3 (approximately, don't know the details of
960gs):

 #container (same as container_12)
 #container #content (same as grid_12)
 #container.two-columns #content (same as grid_9)
 #container.two-columns #sidebar (same as grid_3)

This way we can have simple rules to switch between layouts (presents of
a portlet in the right column in plone or something like that).

..Carsten

ps: display: table-*  isn't supported by IE 7.




--
Vinicius Depizzol <vdepizzol gmail com>
http://vinicius.depizzol.com.br






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]