Mailinglist Archive: opensuse-boosters (113 mails)

< Previous Next >
Re: [opensuse-boosters] Bento-Theme implementation approach
  • From: Thomas Schmidt <tschmidt@xxxxxxx>
  • Date: Mon, 08 Mar 2010 11:48:03 +0100
  • Message-id: <4B94D5E3.70700@xxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-boosters+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups