[
http://jira.magnolia-cms.com/browse/DOCU-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Suzanne Deprez updated DOCU-241:
--------------------------------
Description:
Create documentation that describes the process that needs to be followed when
applying a design to a website.
The following instructions were sent in an E-mail by Christian Ringele and can
be used as a guide.
The main steps as I approach such a situation:
1. Analyzing, what of the designs generally matches the html grid/layout
(http://documentation.magnolia-cms.com/templating/stk/html-structure.html).
What areas do we need, which not.
What kind of pages we need, articles, section, news and so on.
In what grid, section floating in two columns and so on.
So trying to find out, how many templates need to be created:
- 2 sections: section nav-col-subcol & section-col-float3
- 3 articles: article-nav.col-subcol & article no extras & article no extras no
promos
ans so on.
So by that you see fast, if you need additional areas, and/or if you need to
exchange in general a complete area (for example section header need to be
flash aware).
The goal of this is:
- to know what templates are needed, and what general grid adaptions need to be
implement
-> knowing of the differences to the prototype, knowing the differences to
implement
2. A very similar approach for the paragraphs:
Trying to find the paragraphs, which match the designs as close as possible.
Often a bunch of paragraphs directly fit the need, some need to be adapted, and
some new ones have to be implemented.
So for example if I see a accordion element, I know I can achieve that fast by
the faq items.
Of course that analyzation is close together with point 1, cause if I need
different paragraphs on similar kind of pages, that would also point to
different magnolia templates.
3. creating from STK's prototype a project prototype, containing the pages
analyzed in the last two steps.
Removing pages you don't need. Removing from needed pages areas which you don't
need.
Removing from the pages paragraphs which are not needed.
So creating a html base for the first implementation and the next step.
Important is only to remove html, or copy from other pages the html.
But NOT ever changing any html!!
-> all that you can achieve in STK just by configuration.
4. Having based on that static prototype a first design impl.
So somebody tries to adapt the css, to get as close to the designs as possible.
No html changes allowed!
Meanwhile somebody can create the STK project and to the template
configurations decided in 1.&2.&3.
When the design is finished on this first try, you can use the css in
Magnolia/STK, and it will look the same.
Know you really see the differences & implementations needed to get closer to
the final design.
And know you do a iterating process until design is finished as needed:
Iteration:
1. Look at only one element which differs to the needed design.
Decide on the html changes needed (best based on STK, which produces least
impl, like a addition div or a div class or li class is usually very fast in
there).
Usually a STK implementor and css designer need to decided that together.
2. add the changes html to the static prototype.
- designer changes now based on that the css
- stk implementor changes the scripts according to the html change
3. changes css is plugged into STK.
Now the iteration starts again -> look at the next element, decide on html
changes needed, and so on.
In the same E-mail customer stated that the designer provides HTML-templates
(HTML, CSS, JS). Christian replied with following:
That I would never accept, cause:
1. You are the customer, so you can decide what they should deliver
2. You can provide them with the prototype, and say they shall use that as a
bases.
3. You will get agency locked in this way. How should any body else understand
the html/css concept? How should anybody else take over the project and extends
it, maintain it.
4. Its much more expensive to build any CMS around a html, than html around a
CMS
5. Mostly such html is not optimized in the sense of accessibility and other
open standards.
If you must use the html, you must start from scratch.
But still I would use the stk (global functionality as site definition, theme
and so on).
But just do your own impl as the stk did:
- take the html apart into areas & subsnippets, try to include them dynamically
-> having a template definition providing these configurations comparable to
the STKTemplate RenderableDefinition.
was:
Create documentation that describes the process that needs to be followed when
applying a design to a website.
The following instructions were sent in an E-mail by Christian Ringele and can
be used as a guide.
The main steps as I approach such a situation:
1. Analyzing, what of the designs generally matches the html grid/layout
(http://documentation.magnolia-cms.com/templating/stk/html-structure.html).
What areas do we need, which not.
What kind of pages we need, articles, section, news and so on.
In what grid, section floating in two columns and so on.
So trying to find out, how many templates need to be created:
- 2 sections: section nav-col-subcol & section-col-float3
- 3 articles: article-nav.col-subcol & article no extras & article no extras no
promos
ans so on.
So by that you see fast, if you need additional areas, and/or if you need to
exchange in general a complete area (for example section header need to be
flash aware).
The goal of this is:
- to know what templates are needed, and what general grid adaptions need to be
implement
-> knowing of the differences to the prototype, knowing the differences to
implement
2. A very similar approach for the paragraphs:
Trying to find the paragraphs, which match the designs as close as possible.
Often a bunch of paragraphs directly fit the need, some need to be adapted, and
some new ones have to be implemented.
So for example if I see a accordion element, I know I can achieve that fast by
the faq items.
Of course that analyzation is close together with point 1, cause if I need
different paragraphs on similar kind of pages, that would also point to
different magnolia templates.
3. creating from STK's prototype a project prototype, containing the pages
analyzed in the last two steps.
Removing pages you don't need. Removing from needed pages areas which you don't
need.
Removing from the pages paragraphs which are not needed.
So creating a html base for the first implementation and the next step.
Important is only to remove html, or copy from other pages the html.
But NOT ever changing any html!!
-> all that you can achieve in STK just by configuration.
4. Having based on that static prototype a first design impl.
So somebody tries to adapt the css, to get as close to the designs as possible.
No html changes allowed!
Meanwhile somebody can create the STK project and to the template
configurations decided in 1.&2.&3.
When the design is finished on this first try, you can use the css in
Magnolia/STK, and it will look the same.
Know you really see the differences & implementations needed to get closer to
the final design.
And know you do a iterating process until design is finished as needed:
Iteration:
1. Look at only one element which differs to the needed design.
Decide on the html changes needed (best based on STK, which produces least
impl, like a addition div or a div class or li class is usually very fast in
there).
Usually a STK implementor and css designer need to decided that together.
2. add the changes html to the static prototype.
- designer changes now based on that the css
- stk implementor changes the scripts according to the html change
3. changes css is plugged into STK.
Now the iteration starts again -> look at the next element, decide on html
changes needed, and so on.
> Add Process for Applying Design to a Site
> -----------------------------------------
>
> Key: DOCU-241
> URL: http://jira.magnolia-cms.com/browse/DOCU-241
> Project: Documentation
> Issue Type: New Feature
> Security Level: Public
> Reporter: Suzanne Deprez
> Assignee: Suzanne Deprez
>
> Create documentation that describes the process that needs to be followed
> when applying a design to a website.
> The following instructions were sent in an E-mail by Christian Ringele and
> can be used as a guide.
> The main steps as I approach such a situation:
> 1. Analyzing, what of the designs generally matches the html grid/layout
> (http://documentation.magnolia-cms.com/templating/stk/html-structure.html).
> What areas do we need, which not.
> What kind of pages we need, articles, section, news and so on.
> In what grid, section floating in two columns and so on.
> So trying to find out, how many templates need to be created:
> - 2 sections: section nav-col-subcol & section-col-float3
> - 3 articles: article-nav.col-subcol & article no extras & article no extras
> no promos
> ans so on.
> So by that you see fast, if you need additional areas, and/or if you need to
> exchange in general a complete area (for example section header need to be
> flash aware).
> The goal of this is:
> - to know what templates are needed, and what general grid adaptions need to
> be implement
> -> knowing of the differences to the prototype, knowing the differences to
> implement
> 2. A very similar approach for the paragraphs:
> Trying to find the paragraphs, which match the designs as close as possible.
> Often a bunch of paragraphs directly fit the need, some need to be adapted,
> and some new ones have to be implemented.
> So for example if I see a accordion element, I know I can achieve that fast
> by the faq items.
> Of course that analyzation is close together with point 1, cause if I need
> different paragraphs on similar kind of pages, that would also point to
> different magnolia templates.
> 3. creating from STK's prototype a project prototype, containing the pages
> analyzed in the last two steps.
> Removing pages you don't need. Removing from needed pages areas which you
> don't need.
> Removing from the pages paragraphs which are not needed.
> So creating a html base for the first implementation and the next step.
> Important is only to remove html, or copy from other pages the html.
> But NOT ever changing any html!!
> -> all that you can achieve in STK just by configuration.
> 4. Having based on that static prototype a first design impl.
> So somebody tries to adapt the css, to get as close to the designs as
> possible.
> No html changes allowed!
> Meanwhile somebody can create the STK project and to the template
> configurations decided in 1.&2.&3.
> When the design is finished on this first try, you can use the css in
> Magnolia/STK, and it will look the same.
> Know you really see the differences & implementations needed to get closer to
> the final design.
> And know you do a iterating process until design is finished as needed:
> Iteration:
> 1. Look at only one element which differs to the needed design.
> Decide on the html changes needed (best based on STK, which produces least
> impl, like a addition div or a div class or li class is usually very fast in
> there).
> Usually a STK implementor and css designer need to decided that together.
> 2. add the changes html to the static prototype.
> - designer changes now based on that the css
> - stk implementor changes the scripts according to the html change
> 3. changes css is plugged into STK.
> Now the iteration starts again -> look at the next element, decide on html
> changes needed, and so on.
> In the same E-mail customer stated that the designer provides HTML-templates
> (HTML, CSS, JS). Christian replied with following:
> That I would never accept, cause:
> 1. You are the customer, so you can decide what they should deliver
> 2. You can provide them with the prototype, and say they shall use that as a
> bases.
> 3. You will get agency locked in this way. How should any body else
> understand the html/css concept? How should anybody else take over the
> project and extends it, maintain it.
> 4. Its much more expensive to build any CMS around a html, than html around a
> CMS
> 5. Mostly such html is not optimized in the sense of accessibility and other
> open standards.
> If you must use the html, you must start from scratch.
> But still I would use the stk (global functionality as site definition, theme
> and so on).
> But just do your own impl as the stk did:
> - take the html apart into areas & subsnippets, try to include them
> dynamically -> having a template definition providing these configurations
> comparable to the STKTemplate RenderableDefinition.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
----------------------------------------------------------------
For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
