implementing webdesign for plone

[johannes raggam]

hey all, hey vinicius,

i'm currently doing some plone integration of the webdesign (which is
really nice!).

now, direct communication with the design team (vinicius) would be
great.

- currently the space for the up-to-date webdesign templates is on
dropbox. i don't have access there. can you give me access to the shared
space? my dropbox account ist: raggam-nl@... screenname: thet

- i'll may have to change some of the templates if necessary - but then
the files will get out of sync. what do you think of using an svn space
to allow collaborative development? the current development space is on
https://svn.plone.org/svn/collective/gnomeweb-plone
here is some information on how to get an account for collective:
http://dev.plone.org/plone/wiki/ContributeCollective
any other ideas of how to sync the codebase are welcome.


cheers,
johannes raggam / thet


_______________________________________________
gnome-web-list mailing list
gnome-web-list@...
http://mail.gnome.org/mailman/listinfo/gnome-web-list

[Vinicius Depizzol]

On Thu, Aug 20, 2009 at 14:15, johannes raggam<raggam-nl@...> wrote:
> hey all, hey vinicius,

Hello, Johannes!

> i'm currently doing some plone integration of the webdesign (which is
> really nice!).

Good to know! Thank you for your comment. :)

> now, direct communication with the design team (vinicius) would be
> great.
>
> - currently the space for the up-to-date webdesign templates is on
> dropbox. i don't have access there. can you give me access to the shared
> space? my dropbox account ist: raggam-nl@... screenname: thet

Sure! Done.

> - i'll may have to change some of the templates if necessary - but then
> the files will get out of sync. what do you think of using an svn space
> to allow collaborative development? the current development space is on
> https://svn.plone.org/svn/collective/gnomeweb-plone
> here is some information on how to get an account for collective:
> http://dev.plone.org/plone/wiki/ContributeCollective
> any other ideas of how to sync the codebase are welcome.
>

Is there a way to keep the sync under Dropbox? For me it is just
easier :). With the shared access you are able to edit it too. But if
svn sounds a better idea, I can go for it.

During the weekend I'll keep working on fitting the content in the layout.

Thank you.

--
Vinicius Depizzol <vdepizzol@...>
http://vinicius.depizzol.com.br
_______________________________________________
gnome-web-list mailing list
gnome-web-list@...
http://mail.gnome.org/mailman/listinfo/gnome-web-list

[johannes raggam]

hi,

On Thu, 2009-08-20 at 14:35 -0300, Vinicius Depizzol wrote:
> > - currently the space for the up-to-date webdesign templates is on
> > dropbox. i don't have access there. can you give me access to the shared
> > space? my dropbox account ist: raggam-nl@... screenname: thet
> Sure! Done.
thank you!
just to be sure: the folder with the templates is here, isn't it:
https://www.getdropbox.com/share/fog-website/gnome.org-implementation/code/content/

> > - i'll may have to change some of the templates if necessary - but then
> > the files will get out of sync. what do you think of using an svn space
> > to allow collaborative development? the current development space is on
> > https://svn.plone.org/svn/collective/gnomeweb-plone
> > here is some information on how to get an account for collective:
> > http://dev.plone.org/plone/wiki/ContributeCollective
> > any other ideas of how to sync the codebase are welcome.
> >
>
> Is there a way to keep the sync under Dropbox? For me it is just
> easier :). With the shared access you are able to edit it too. But if
> svn sounds a better idea, I can go for it.

i'm going to try out the dropbox client for linux. it seems that it may
be sufficient enough to work with. personally i would prefer a real
version control system like svn, but let's use dropbox for now.

cheers,hannes


_______________________________________________
gnome-web-list mailing list
gnome-web-list@...
http://mail.gnome.org/mailman/listinfo/gnome-web-list

[johannes raggam]

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 changed the template fog-website/gnome.org-implementation/code
static/content/index.html in 2 ways to have the submenu slots always
present:
- added ul.subpages_list to div#title
- added div.grid_3

then i had to add some css to have the right-block to be on the right
side and the content block to expand to full width if there are no
submenu items in the right block.

what do you think of this procedure?

please review my css code since it uses min-width to have the content
area always 700px minimum width. min-width isn't supported very well by
all browsers as far as i know. maybe the css should be integrated in
960.css.


regarding dropbox:
> > Is there a way to keep the sync under Dropbox? For me it is just
> > easier :). With the shared access you are able to edit it too. But if
> > svn sounds a better idea, I can go for it.
>
> i'm going to try out the dropbox client for linux. it seems that it may
> be sufficient enough to work with. personally i would prefer a real
> version control system like svn, but let's use dropbox for now.

let's stick with the dropbox client, it works really good! i integrated
the dropbox folder locally in my svn working copy. what i did is:
- removed the static directory from svn
- mkdir static
- sudo mount --bind ~/Dropbox/fog-website/gnome.org-implementation/code
static/
- svn add static

this way, any changes to files in static are reflected in dropbox AND in
svn!

cheers, hannes
> cheers,hannes
>


_______________________________________________
gnome-web-list mailing list
gnome-web-list@...
http://mail.gnome.org/mailman/listinfo/gnome-web-list

[Carsten Senger-3]

Hi all,

--On Freitag, August 21, 2009 16:51:33 +0200 johannes raggam
<raggam-nl@...> 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.
_______________________________________________
gnome-web-list mailing list
gnome-web-list@...
http://mail.gnome.org/mailman/listinfo/gnome-web-list

[Vinicius Depizzol]

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 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.

Thank you.

On Fri, Aug 21, 2009 at 14:10, Carsten Senger<senger@...> wrote:

> Hi all,
>
> --On Freitag, August 21, 2009 16:51:33 +0200 johannes raggam
> <raggam-nl@...> 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@...>
http://vinicius.depizzol.com.br
_______________________________________________
gnome-web-list mailing list
gnome-web-list@...
http://mail.gnome.org/mailman/listinfo/gnome-web-list

[Carsten Senger-3]

--On Mittwoch, August 26, 2009 10:52:29 -0300 Vinicius Depizzol
<vdepizzol@...> 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@...> wrote:
>> Hi all,
>>
>> --On Freitag, August 21, 2009 16:51:33 +0200 johannes raggam
>> <raggam-nl@...> 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@...>
> http://vinicius.depizzol.com.br

_______________________________________________
gnome-web-list mailing list
gnome-web-list@...
http://mail.gnome.org/mailman/listinfo/gnome-web-list

[Vinicius Depizzol]

Hello!

On Wed, Aug 26, 2009 at 12:28, Carsten Senger <senger@...> wrote:

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).

Will we be able to generate pages like this[1][2] in a wysiwyg editor? I really think we can't get stuck in a simple editor that can only generate simple pages. For these cases, only HTML can be extensible enough.

We already have live.gnome.org for putting fast information in a wiki format. The GNOME Website should not look like a wiki. We need pages that look and feel as polished as possible, and for this I think there will be always a designer by the side of the editors to edit the pages and make it beautiful (editing in HTML! :D).

[1] http://vinicius.depizzol.com.br/gnome-website/content/about/index.html

[2] http://vinicius.depizzol.com.br/gnome-website/content/download/distributions.html

Thank you. ;)

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

_______________________________________________
gnome-web-list mailing list
gnome-web-list@...
http://mail.gnome.org/mailman/listinfo/gnome-web-list

[Carsten Senger-3]

Hi Vinicius,

--On Mittwoch, August 26, 2009 17:25:00 -0300 Vinicius Depizzol
<vdepizzol@...> wrote:

> Hello!
> On Wed, Aug 26, 2009 at 12:28, Carsten Senger <senger@...> wrote:
>>
>>
>> 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).
>
>
> Will we be able to generate pages like this[1][2] in a wysiwyg editor? I
> really think we can't get stuck in a simple editor that can only generate
> simple pages. For these cases, only HTML can be extensible enough.

kupu (the default wysiwyg editor) can't. I can test if TinyMCE (default
wysiwyg editor in the next plone version, but usable now) can do that.
You can always turn off the wysiwyg editor and write html source in an text
area, or maybe switch in the editor to a html source view. So you can get
shiny pages in, yes. But frankly this is normally over the head for
editors, it needs someone who speaks html.
Another option is the way the frontpage is generated. An editor can
composition a page with colums and rows. These are all <div>s. The content
of a div is whatever you fill it with. As the wysiwyg editors produce more
or less clean markup, this approach can be used and should be better
managable for editors (even if not as extensible as cooking tag soup by
hand). You can take a look at the source [a]. "News" is aggregated content
from the site, the right column ("Headingparagraph ...") is edited with an
wysiwyg editor.

> We already have live.gnome.org for putting fast information in a wiki
> format. The GNOME Website should not look like a wiki.

It won't even if you can't do two column layouts ;)

> We need pages that
> look and feel as polished as possible, and for this I think there will be
> always a designer by the side of the editors to edit the pages and make it
> beautiful (editing in HTML! :D).

Not sure if editors want to be stuck if they can't get hold of a designer
to publish their content.  But we can largely get both: An easy way to edit
the pages while using the exciting, shiny and polished CD for editors, and
enough flexibility for designers to make special pages even more shiny.

> [1] http://vinicius.depizzol.com.br/gnome-website/content/about/index.html
> [2]
> http://vinicius.depizzol.com.br/gnome-website/content/download/distributi
> ons.html

[a] <http://gnome.rehfisch.de/>
_______________________________________________
gnome-web-list mailing list
gnome-web-list@...
http://mail.gnome.org/mailman/listinfo/gnome-web-list

[Vinicius Depizzol]

On Wed, Aug 26, 2009 at 18:36, Carsten Senger <senger@...> wrote:

You can always turn off the wysiwyg editor and write html source in an text
area, or maybe switch in the editor to a html source view. So you can get
shiny pages in, yes. But frankly this is normally over the head for
editors, it needs someone who speaks html.
Another option is the way the frontpage is generated. An editor can
composition a page with colums and rows. These are all <div>s. The content
of a div is whatever you fill it with. As the wysiwyg editors produce more
or less clean markup, this approach can be used and should be better
managable for editors (even if not as extensible as cooking tag soup by
hand). You can take a look at the source [a]. "News" is aggregated content
from the site, the right column ("Headingparagraph ...") is edited with an
wysiwyg editor.

Well, this solves all the problems! :D

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

_______________________________________________
gnome-web-list mailing list
gnome-web-list@...
http://mail.gnome.org/mailman/listinfo/gnome-web-list