Re: [opensuse-boosters] Bento-Theme implementation approach
Am Donnerstag 04 März 2010 schrieb Robert Lihm:
I'm afraid that we make the same mistakes we made with the current opensuse.org theme and endup with a big, not maintainable, patchwork- monster-theme.
Hi, But you agree that creating mockups alone won't help you finish the goal of a theme that works for all applications, right? So I think the approach to "define something, try it, redefine it, try it again, redefine it, try it again till it works" is a good one - it just needs to be clear that all our porting efforts are part of the great "define a common theme" goal and to me it is. Then again I must say I asked you the week before christmas what the timeline for bento is and you said it's only weeks from finished not months (I asked you explicitly) and you agreed that starting to experiment with it for build.o.o is good. Now I'm suprised you meant "DON'T TOUCH IT!" when you said that. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On 04.03.2010, at 15:53, Stephan Kulow wrote:
Am Donnerstag 04 März 2010 schrieb Robert Lihm:
I'm afraid that we make the same mistakes we made with the current opensuse.org theme and endup with a big, not maintainable, patchwork- monster-theme.
Hi,
But you agree that creating mockups alone won't help you finish the goal of a theme that works for all applications, right?
It would be a solid base in a traditional project-management.
So I think the approach to "define something, try it, redefine it, try it again, redefine it, try it again till it works" is a good one - it just needs to be clear that all our porting efforts are part of the great "define a common theme" goal and to me it is.
Yep, but I'm a bit afraid, that the "umbrella" drift more and more apart.
Then again I must say I asked you the week before christmas what the timeline for bento is and you said it's only weeks from finished not months (I asked you explicitly) and you agreed that starting to experiment with it for build.o.o is good.
That's correct. It was an experiment. I'm just saying, that I see us running into the same problems as last time. I'm _not_ saying "Person A made everything wrong". We should think about, how to avoid the old misstakes.
Now I'm suprised you meant "DON'T TOUCH IT!" when you said that.
No :-) Cheers, Robert
Greetings, Stephan
-- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
--- Robert Lihm, Webdesigner - openSUSE Boosters Team SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0 - rlihm@suse.de ____________________________________________________________ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ____________________________________________________________ SUSE - a Novell business -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On 03/05/2010 12:09 PM, Robert Lihm wrote:
On 04.03.2010, at 15:53, Stephan Kulow wrote:
Am Donnerstag 04 März 2010 schrieb Robert Lihm:
I'm afraid that we make the same mistakes we made with the current opensuse.org theme and endup with a big, not maintainable, patchwork- monster-theme.
Hi,
But you agree that creating mockups alone won't help you finish the goal of a theme that works for all applications, right?
It would be a solid base in a traditional project-management.
I'm with coolo here. We are working on incremental steps forward to get the skin working with all applications. For this we need versions of these applications running with the bento theme to give you real world feedback. To not make the bento umbrella sprint drift appart in different directions we have the webdesign project which is under your control and the authoritative source. Do you have examples which projects don't follow or duplicate stuff that is done in webdesign/ ?
So I think the approach to "define something, try it, redefine it, try it again, redefine it, try it again till it works" is a good one - it just needs to be clear that all our porting efforts are part of the great "define a common theme" goal and to me it is.
Yep, but I'm a bit afraid, that the "umbrella" drift more and more apart.
Then again I must say I asked you the week before christmas what the timeline for bento is and you said it's only weeks from finished not months (I asked you explicitly) and you agreed that starting to experiment with it for build.o.o is good.
That's correct. It was an experiment. I'm just saying, that I see us running into the same problems as last time. I'm _not_ saying "Person A made everything wrong".
We should think about, how to avoid the old misstakes.
As most of us were not involved in the last redesign: Which were the problems and how do you suggest to avoid them? I think the problems were that each app duplicated the design files and did local changes to it. But I didn't see this happening in the apps I work on. Greetings -- Thomas Schmidt (tschmidt [at] suse.de) SUSE Linux Products GmbH :: Research & Development :: Tools "A strange game. The only winning move is not to play.", Wargames -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On Friday 05 March 2010 14:45:31 Thomas Schmidt wrote: Hi,
As most of us were not involved in the last redesign: Which were the problems and how do you suggest to avoid them? I think the problems were that each app duplicated the design files and did local changes to it.
this is one of the many problems (compare en.o.o with help.o.o) for example. Others are: * not all apps use static.o.o as a single source for common CSS, JS and images (so this stuff can be browser-cached for all opensuse servers) * there are some common elements such as the webstatistics JS snippet or the sponsors box, that are local to all apps. Changing these ATM means to do the same edits to almost 20 files on different servers * there is no policy that the skin has to be used - some servers such as features.o.o or lists.o.o do not use the skin at all * there is a number of web applications developed in-house. Instead of using the same pool of CSS (wherever possible) together with a unique naming convention each application uses it's own css implementation * apart from the skin itself we have no common CSS for non-skin elements that should be used in all apps * we have no openSUSE JavaScript library for common JS tasks such login ...and I probably forgot some topics... -- Regards Frank Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On 05.03.2010, at 15:52, Frank Sundermeyer wrote:
On Friday 05 March 2010 14:45:31 Thomas Schmidt wrote:
Hi,
As most of us were not involved in the last redesign: Which were the problems and how do you suggest to avoid them? I think the problems were that each app duplicated the design files and did local changes to it.
this is one of the many problems (compare en.o.o with help.o.o) for example. Others are:
* not all apps use static.o.o as a single source for common CSS, JS and images (so this stuff can be browser-cached for all opensuse servers)
* there are some common elements such as the webstatistics JS snippet or the sponsors box, that are local to all apps. Changing these ATM means to do the same edits to almost 20 files on different servers
* there is no policy that the skin has to be used - some servers such as features.o.o or lists.o.o do not use the skin at all
* there is a number of web applications developed in-house. Instead of using the same pool of CSS (wherever possible) together with a unique naming convention each application uses it's own css implementation
* apart from the skin itself we have no common CSS for non-skin elements that should be used in all apps
* we have no openSUSE JavaScript library for common JS tasks such login
...and I probably forgot some topics...
* we have no way to maintain common content, like the main navigation/ sponsors/footer-elements/etc. In the current theme, I e.g. had to add manually links to other openSUSE.org pages many times. Best, Robert
-- Regards Frank
Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
--- Robert Lihm, Webdesigner - openSUSE Boosters Team SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0 - rlihm@suse.de ____________________________________________________________ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ____________________________________________________________ SUSE - a Novell business -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On 03/05/2010 04:12 PM, Robert Lihm wrote:
On 05.03.2010, at 15:52, Frank Sundermeyer wrote:
On Friday 05 March 2010 14:45:31 Thomas Schmidt wrote:
Hi,
As most of us were not involved in the last redesign: Which were the problems and how do you suggest to avoid them? I think the problems were that each app duplicated the design files and did local changes to it.
this is one of the many problems (compare en.o.o with help.o.o) for example. Others are:
* not all apps use static.o.o as a single source for common CSS, JS and images (so this stuff can be browser-cached for all opensuse servers)
And as long as we are in testing with these skins we won't use static.o.o, because that would be a too large turnaround time for simple changes. When in production all apps can use static.o.o ideally with a config switch.
* there are some common elements such as the webstatistics JS snippet or the sponsors box, that are local to all apps. Changing these ATM means to do the same edits to almost 20 files on different servers
That's true, but I hope changes there are rare, and if we have responsible people for these 20 apps, it's just a mail to these people. (or see ideas below)
* there is no policy that the skin has to be used - some servers such as features.o.o or lists.o.o do not use the skin at all
* there is a number of web applications developed in-house. Instead of using the same pool of CSS (wherever possible) together with a unique naming convention each application uses it's own css implementation
* apart from the skin itself we have no common CSS for non-skin elements that should be used in all apps
* we have no openSUSE JavaScript library for common JS tasks such login
So let's start a page in the wiki with style guidelines so that everyone can stick to them. I think one reason of the current patchwork of styles is that the developers creating the apps simply don't know how to do it and take something as a base. We would be happy when there are clear guidelines how to use the umbrella skin because it makes the work for all of us easier.
* we have no way to maintain common content, like the main navigation/sponsors/footer-elements/etc. In the current theme, I e.g. had to add manually links to other openSUSE.org pages many times.
I suggest we create small snippet files for these parts (main navigation box, header, footer, statistic js) in the main webdesign repo. We have to see how to include these files in the different apps dynamically (SSI includes, PHP fopen, ...), or is this also possible with iframes? Greetings -- Thomas Schmidt (tschmidt [at] suse.de) SUSE Linux Products GmbH :: Research & Development :: Tools "Wir sind nicht in Vietnam, sondern beim Bowling. Hier gibt es Regeln." John Goodman in Big Lebowsky -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On 05.03.2010, at 16:50, Thomas Schmidt wrote:
On 03/05/2010 04:12 PM, Robert Lihm wrote:
On 05.03.2010, at 15:52, Frank Sundermeyer wrote:
On Friday 05 March 2010 14:45:31 Thomas Schmidt wrote:
Hi,
As most of us were not involved in the last redesign: Which were the problems and how do you suggest to avoid them? I think the problems were that each app duplicated the design files and did local changes to it.
this is one of the many problems (compare en.o.o with help.o.o) for example. Others are:
* not all apps use static.o.o as a single source for common CSS, JS and images (so this stuff can be browser-cached for all opensuse servers)
And as long as we are in testing with these skins we won't use static.o.o, because that would be a too large turnaround time for simple changes. When in production all apps can use static.o.o ideally with a config switch.
May I misunderstand it, but couldn't we pull the common stuff already from static.o.o and the local stuff stays local?
* there are some common elements such as the webstatistics JS snippet or the sponsors box, that are local to all apps. Changing these ATM means to do the same edits to almost 20 files on different servers
That's true, but I hope changes there are rare, and if we have responsible people for these 20 apps, it's just a mail to these people. (or see ideas below)
* there is no policy that the skin has to be used - some servers such as features.o.o or lists.o.o do not use the skin at all
* there is a number of web applications developed in-house. Instead of using the same pool of CSS (wherever possible) together with a unique naming convention each application uses it's own css implementation
* apart from the skin itself we have no common CSS for non-skin elements that should be used in all apps
* we have no openSUSE JavaScript library for common JS tasks such login
So let's start a page in the wiki with style guidelines so that everyone can stick to them. I think one reason of the current patchwork of styles is that the developers creating the apps simply don't know how to do it and take something as a base. We would be happy when there are clear guidelines how to use the umbrella skin because it makes the work for all of us easier.
That fits exactly to my thoughts. I start such wiki-page ASAP.
* we have no way to maintain common content, like the main navigation/sponsors/footer-elements/etc. In the current theme, I e.g. had to add manually links to other openSUSE.org pages many times.
I suggest we create small snippet files for these parts (main navigation box, header, footer, statistic js) in the main webdesign repo. We have to see how to include these files in the different apps dynamically (SSI includes, PHP fopen, ...), or is this also possible with iframes?
I would not got with iframes. Mainly because I think they make the pages unaccessible. But I'm open for vetos :-) Tom, thank you for your cooperation and great ideas :-) Best, Robert
Greetings
-- Thomas Schmidt (tschmidt [at] suse.de) SUSE Linux Products GmbH :: Research & Development :: Tools "Wir sind nicht in Vietnam, sondern beim Bowling. Hier gibt es Regeln." John Goodman in Big Lebowsky -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
--- Robert Lihm, Webdesigner - openSUSE Boosters Team SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0 - rlihm@suse.de ____________________________________________________________ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ____________________________________________________________ SUSE - a Novell business -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On 08.03.2010 10:05, Robert Lihm wrote:
On 05.03.2010, at 16:50, Thomas Schmidt wrote:
On 03/05/2010 04:12 PM, Robert Lihm wrote:
On 05.03.2010, at 15:52, Frank Sundermeyer wrote:
On Friday 05 March 2010 14:45:31 Thomas Schmidt wrote:
Hi,
As most of us were not involved in the last redesign: Which were the problems and how do you suggest to avoid them? I think the problems were that each app duplicated the design files and did local changes to it.
this is one of the many problems (compare en.o.o with help.o.o) for example. Others are:
* not all apps use static.o.o as a single source for common CSS, JS and images (so this stuff can be browser-cached for all opensuse servers)
And as long as we are in testing with these skins we won't use static.o.o, because that would be a too large turnaround time for simple changes. When in production all apps can use static.o.o ideally with a config switch.
May I misunderstand it, but couldn't we pull the common stuff already from static.o.o and the local stuff stays local?
Yes, we can do this if it makes you life easier. So please announce the path to the bento design on static.o.o and give some people access to this machine so we can update and debug it.
* there are some common elements such as the webstatistics JS snippet or the sponsors box, that are local to all apps. Changing these ATM means to do the same edits to almost 20 files on different servers
Btw: Can we have access to the google statistics report that is generated from this snippet?
That's true, but I hope changes there are rare, and if we have responsible people for these 20 apps, it's just a mail to these people. (or see ideas below)
* there is no policy that the skin has to be used - some servers such as features.o.o or lists.o.o do not use the skin at all
* there is a number of web applications developed in-house. Instead of using the same pool of CSS (wherever possible) together with a unique naming convention each application uses it's own css implementation
* apart from the skin itself we have no common CSS for non-skin elements that should be used in all apps
* we have no openSUSE JavaScript library for common JS tasks such login
So let's start a page in the wiki with style guidelines so that everyone can stick to them. I think one reason of the current patchwork of styles is that the developers creating the apps simply don't know how to do it and take something as a base. We would be happy when there are clear guidelines how to use the umbrella skin because it makes the work for all of us easier.
That fits exactly to my thoughts. I start such wiki-page ASAP.
* we have no way to maintain common content, like the main navigation/sponsors/footer-elements/etc. In the current theme, I e.g. had to add manually links to other openSUSE.org pages many times.
I suggest we create small snippet files for these parts (main navigation box, header, footer, statistic js) in the main webdesign repo. We have to see how to include these files in the different apps dynamically (SSI includes, PHP fopen, ...), or is this also possible with iframes?
I would not got with iframes. Mainly because I think they make the pages unaccessible. But I'm open for vetos :-)
Does someone have an idea how to solve this? Greetings -- Thomas Schmidt (tschmidt [at] suse.de) SUSE Linux Products GmbH :: Research & Development :: Tools "Don't Panic", Douglas Adams (1952 - 11.05.2001) -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On Monday 08 March 2010 11:48:03 Thomas Schmidt wrote:
Btw: Can we have access to the google statistics report that is generated from this snippet?
I have access to it and can share the data. If there's anybody else that needs access, I'm sure we can arrange it - please contact me offline, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On 08.03.2010 12:09, Andreas Jaeger wrote:
On Monday 08 March 2010 11:48:03 Thomas Schmidt wrote:
Btw: Can we have access to the google statistics report that is generated from this snippet?
I have access to it and can share the data. If there's anybody else that needs access, I'm sure we can arrange it - please contact me offline,
Couldn't all boosters have access there? It's probably useful for enhancing our pages. Greetings -- Thomas Schmidt (tschmidt [at] suse.de) SUSE Linux Products GmbH :: Research & Development :: Tools "Don't Panic", Douglas Adams (1952 - 11.05.2001) -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On Mar 8, 2010, at 12:34 , Thomas Schmidt wrote:
On 08.03.2010 12:09, Andreas Jaeger wrote:
On Monday 08 March 2010 11:48:03 Thomas Schmidt wrote:
Btw: Can we have access to the google statistics report that is generated from this snippet?
I have access to it and can share the data. If there's anybody else that needs access, I'm sure we can arrange it - please contact me offline,
Couldn't all boosters have access there? It's probably useful for enhancing our pages.
+1 This could be really handy. R
Greetings
-- Thomas Schmidt (tschmidt [at] suse.de) SUSE Linux Products GmbH :: Research & Development :: Tools "Don't Panic", Douglas Adams (1952 - 11.05.2001) -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
--- Robert Lihm, Webdesigner - openSUSE Boosters Team SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0 - rlihm@suse.de ____________________________________________________________ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ____________________________________________________________ SUSE - a Novell business -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On 03/05/2010 04:50 PM, Thomas Schmidt wrote:
I suggest we create small snippet files for these parts (main navigation box, header, footer, statistic js) in the main webdesign repo. We have to see how to include these files in the different apps dynamically (SSI includes, PHP fopen, ...), or is this also possible with iframes?
I think it will break statistics if we use it in an iframe. Server side includes should work for dynamic websites (PHP, Ruby, Perl, ...), but I'm not sure if there exists a solution for static ones (I guess not). -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On 08.03.2010, at 11:35, Pavol Rusnak wrote:
On 03/05/2010 04:50 PM, Thomas Schmidt wrote:
I suggest we create small snippet files for these parts (main navigation box, header, footer, statistic js) in the main webdesign repo. We have to see how to include these files in the different apps dynamically (SSI includes, PHP fopen, ...), or is this also possible with iframes?
I think it will break statistics if we use it in an iframe. Server side includes should work for dynamic websites (PHP, Ruby, Perl, ...), but I'm not sure if there exists a solution for static ones (I guess not).
MAybe we could use a JavaScript. And finally Server Side include should work on static pages as well, shouldn't it? I think we do it this was on our landingpage (www.o.o). R
-- Best Regards / S pozdravom,
Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
--- Robert Lihm, Webdesigner - openSUSE Boosters Team SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0 - rlihm@suse.de ____________________________________________________________ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ____________________________________________________________ SUSE - a Novell business -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On 08.03.2010 11:38, Robert Lihm wrote:
On 08.03.2010, at 11:35, Pavol Rusnak wrote:
On 03/05/2010 04:50 PM, Thomas Schmidt wrote:
I suggest we create small snippet files for these parts (main navigation box, header, footer, statistic js) in the main webdesign repo. We have to see how to include these files in the different apps dynamically (SSI includes, PHP fopen, ...), or is this also possible with iframes?
I think it will break statistics if we use it in an iframe. Server side includes should work for dynamic websites (PHP, Ruby, Perl, ...), but I'm not sure if there exists a solution for static ones (I guess not).
MAybe we could use a JavaScript. And finally Server Side include should work on static pages as well, shouldn't it? I think we do it this was on our landingpage (www.o.o).
SSI only work for local files and cannot include parts of the page (header, footer) from static.o.o (which is rlihm's goal if i understand correctly). Greetings -- Thomas Schmidt (tschmidt [at] suse.de) SUSE Linux Products GmbH :: Research & Development :: Tools "Don't Panic", Douglas Adams (1952 - 11.05.2001) -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On Monday 08 March 2010 11:51:10 Thomas Schmidt wrote: Hi,
On 08.03.2010 11:38, Robert Lihm wrote:
On 08.03.2010, at 11:35, Pavol Rusnak wrote:
On 03/05/2010 04:50 PM, Thomas Schmidt wrote:
I suggest we create small snippet files for these parts (main navigation box, header, footer, statistic js) in the main webdesign repo. We have to see how to include these files in the different apps dynamically (SSI includes, PHP fopen, ...), or is this also possible with iframes?
I think it will break statistics if we use it in an iframe. Server side includes should work for dynamic websites (PHP, Ruby, Perl, ...), but I'm not sure if there exists a solution for static ones (I guess not).
MAybe we could use a JavaScript. And finally Server Side include should work on static pages as well, shouldn't it? I think we do it this was on our landingpage (www.o.o).
SSI only work for local files and cannot include parts of the page (header, footer) from static.o.o (which is rlihm's goal if i understand correctly).
IMHO it would be sufficient to use SSI on all servers if the SSI snippets are hosted at a single source on git or svn. Regards Frank Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Reality is always controlled by the people who are most insane (Dogbert) -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On 08.03.2010 12:33, Frank Sundermeyer wrote:
On Monday 08 March 2010 11:51:10 Thomas Schmidt wrote:
Hi,
On 08.03.2010 11:38, Robert Lihm wrote:
On 08.03.2010, at 11:35, Pavol Rusnak wrote:
On 03/05/2010 04:50 PM, Thomas Schmidt wrote:
I suggest we create small snippet files for these parts (main navigation box, header, footer, statistic js) in the main webdesign repo. We have to see how to include these files in the different apps dynamically (SSI includes, PHP fopen, ...), or is this also possible with iframes?
I think it will break statistics if we use it in an iframe. Server side includes should work for dynamic websites (PHP, Ruby, Perl, ...), but I'm not sure if there exists a solution for static ones (I guess not).
MAybe we could use a JavaScript. And finally Server Side include should work on static pages as well, shouldn't it? I think we do it this was on our landingpage (www.o.o).
SSI only work for local files and cannot include parts of the page (header, footer) from static.o.o (which is rlihm's goal if i understand correctly).
IMHO it would be sufficient to use SSI on all servers if the SSI snippets are hosted at a single source on git or svn.
That's the current state for the wiki at least. The files are: http://gitorious.org/opensuse/webdesign/blobs/master/design_concept/theme_o.... http://gitorious.org/opensuse/webdesign/blobs/master/design_concept/theme_o.... Greetings -- Thomas Schmidt (tschmidt [at] suse.de) SUSE Linux Products GmbH :: Research & Development :: Tools "Don't Panic", Douglas Adams (1952 - 11.05.2001) -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On Monday 08 March 2010 12:37:53 Thomas Schmidt wrote: Hi,
SSI only work for local files and cannot include parts of the page (header, footer) from static.o.o (which is rlihm's goal if i understand correctly).
IMHO it would be sufficient to use SSI on all servers if the SSI snippets are hosted at a single source on git or svn.
That's the current state for the wiki at least. The files are: http://gitorious.org/opensuse/webdesign/blobs/master/design_concept/theme_o .o-bento/header.html http://gitorious.org/opensuse/webdesign/blobs/master/design_concept/theme_ o.o-bento/footer.html
is it possible in the meantime to checkout subdirectories in git? IMHO it would be unfortunate to have to checkout the whole bento theme directory on each server, nor would it be probably be a good idea to split the bento repo into different projects on gitourious just for the sake of a sane checkout. -- Regards Frank Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
is it possible in the meantime to checkout subdirectories in git? IMHO it would be unfortunate to have to checkout the whole bento theme directory on How large is it going to be? So far it's 2.5MB and I don't think there is a
Am Montag 08 März 2010 schrieb Frank Sundermeyer: problem associated with that number. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On Thursday 04 March 2010 15:53:36 Stephan Kulow wrote: Hi,
But you agree that creating mockups alone won't help you finish the goal of a theme that works for all applications, right? So I think the approach to "define something, try it, redefine it, try it again, redefine it, try it again till it works" is a good one - it just needs to be clear that all our porting efforts are part of the great "define a common theme" goal and to me it is.
as long as you do not lose sight of this goal, everything is fine. We had the same goal last time, but somehow lost it on the way and I think it's Robert's fear that it will happen again. Having set up and maintained the "old" theme together with Robert I am sharing his fears. The problem I see with the current approach is as follows: Look at the wiki, or connect, for example. The skin is in use (connect) or can already be used (wiki.o.o) and it looks like the skin development is in a pretty advanced state (meaning far more advanced than a simple mockup). Having gone this far makes it pretty hard to say at a given point in the future: OK, nice work, but now that the templates and guidelines are ready, please start from scratch (and that is basically what you have to do, because doing diffs is almost impossible). On the one hand the person having done the skin is less motivated to start over and on the other hand it's hard to convince his manager that the same work has to be done again. Perhaps it's different this time, because you boosters are solely dedicated to openSUSE - something we didn't have last time. -- Regards Frank Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On 05.03.2010, at 13:40, Frank Sundermeyer wrote:
On Thursday 04 March 2010 15:53:36 Stephan Kulow wrote:
Hi,
But you agree that creating mockups alone won't help you finish the goal of a theme that works for all applications, right? So I think the approach to "define something, try it, redefine it, try it again, redefine it, try it again till it works" is a good one - it just needs to be clear that all our porting efforts are part of the great "define a common theme" goal and to me it is.
as long as you do not lose sight of this goal, everything is fine. We had the same goal last time, but somehow lost it on the way and I think it's Robert's fear that it will happen again. Having set up and maintained the "old" theme together with Robert I am sharing his fears.
The problem I see with the current approach is as follows: Look at the wiki, or connect, for example. The skin is in use (connect) or can already be used (wiki.o.o) and it looks like the skin development is in a pretty advanced state (meaning far more advanced than a simple mockup). Having gone this far makes it pretty hard to say at a given point in the future: OK, nice work, but now that the templates and guidelines are ready, please start from scratch (and that is basically what you have to do, because doing diffs is almost impossible). On the one hand the person having done the skin is less motivated to start over and on the other hand it's hard to convince his manager that the same work has to be done again.
Precisely! Thank you Frank :-) Robert
Perhaps it's different this time, because you boosters are solely dedicated to openSUSE - something we didn't have last time.
-- Regards Frank
Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
--- Robert Lihm, Webdesigner - openSUSE Boosters Team SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0 - rlihm@suse.de ____________________________________________________________ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ____________________________________________________________ SUSE - a Novell business -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
The problem I see with the current approach is as follows: Look at the wiki, or connect, for example. The skin is in use (connect) or can already It would be pretty stupid to take yaml as base for new apps. If we have to choose between "completely old crap[1] we have to redo" and "work in
Am Freitag 05 März 2010 schrieb Frank Sundermeyer: progress we have to redo" I would always pick the later. Greetings, Stephan [1] Not my words -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On Friday 05 March 2010 14:52:00 Stephan Kulow wrote:
Am Freitag 05 März 2010 schrieb Frank Sundermeyer:
The problem I see with the current approach is as follows: Look at the
wiki, or connect, for example. The skin is in use (connect) or can already
It would be pretty stupid to take yaml as base for new apps. If we have to choose between "completely old crap[1] we have to redo" and "work in progress we have to redo" I would always pick the later.
??? I was talking http://wiki.opensuse.org/?useskin=bento and http://connect.opensuse.org and _not at all_ about reusing the old skin. -- Regards Frank Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
Am Freitag 05 März 2010 schrieb Frank Sundermeyer:
On Friday 05 March 2010 14:52:00 Stephan Kulow wrote:
Am Freitag 05 März 2010 schrieb Frank Sundermeyer:
The problem I see with the current approach is as follows: Look at the
wiki, or connect, for example. The skin is in use (connect) or can already
It would be pretty stupid to take yaml as base for new apps. If we have to choose between "completely old crap[1] we have to redo" and "work in progress we have to redo" I would always pick the later.
??? I was talking http://wiki.opensuse.org/?useskin=bento and http://connect.opensuse.org and _not at all_ about reusing the old skin.
connect is a new app and wiki is for testing with existant pages. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
On Friday 05 March 2010 15:30:49 you wrote: Hi,
Am Freitag 05 März 2010 schrieb Frank Sundermeyer:
On Friday 05 March 2010 14:52:00 Stephan Kulow wrote:
Am Freitag 05 März 2010 schrieb Frank Sundermeyer:
The problem I see with the current approach is as follows: Look at the
wiki, or connect, for example. The skin is in use (connect) or can already
It would be pretty stupid to take yaml as base for new apps. If we have to choose between "completely old crap[1] we have to redo" and "work in progress we have to redo" I would always pick the later.
??? I was talking http://wiki.opensuse.org/?useskin=bento and http://connect.opensuse.org and _not at all_ about reusing the old skin.
connect is a new app and wiki is for testing with existant pages.
sure. I knew that when I wrote my original mail. Perhaps it's time to add a personal disclaimer: In no way I intend to offend anyone working on this project nor do I disagree with the project or the work that has been done so far. I only want to help you avoiding the mistakes we (and that does include myself in large parts) made in the past. -- Regards Frank Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
Am Freitag 05 März 2010 schrieb Frank Sundermeyer:
Perhaps it's time to add a personal disclaimer: In no way I intend to offend anyone working on this project nor do I disagree with the project or the work that has been done so far. I only want to help you avoiding the mistakes we (and that does include myself in large parts) made in the past.
And I want to avoid the mistakes done when webclient2 ended up being a dead mockup in svn ;( And I didn't feel offended nor did I try to defend anyone else - we just seem to have different ideas on how to reach the goal. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-boosters+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-boosters+help@opensuse.org
participants (6)
-
Andreas Jaeger -
Frank Sundermeyer -
Pavol Rusnak -
Robert Lihm -
Stephan Kulow -
Thomas Schmidt