On Mon, 24 Nov 2008 17:08:49 -0600, Ivan M <[EMAIL PROTECTED]> wrote:
Hi Alexandro, Goran,
Many thanks for your constructive feedback.
On Tue, Nov 25, 2008 at 10:34 AM, Alexandro Colorado
<[EMAIL PROTECTED]> wrote:
I brought this point a few months back and told me that it was soooo
dificult. Since I am not a JSP developer I thought the template was
embedded
in the code like PHP usually handle things. Which btw is NOT dificult
at
all to read html from php.
This is the problem: I don't see what's so difficult about doing this,
and I hope someone can explain it to me - test.OOo seems to be coping
without tables - IssueZilla seems fine as well (e.g.,
http://test.openoffice.org/issues/show_bug.cgi?id=200)
Well that's great, let's go for it.
Java developers don't care about W3C. You can also see this on the Save
your
OOo document as HTML 4 with all their tags in uppercaps which is also
not
recomended.
OOo's HTML rendering is a different issue (which should definitely be
addressed). But with the website, we have complete control over
CollabNet's HTML skeleton - the template covers everything from the
DOCTYPE tag to the closing of the HTML tag. Plus there are some basic
functions (e.g. if, else) that allow us to customize this structure in
certain cases.
Actually you are the first that says that, before I got responses like, we
can't control the skeleton or the template can only be accessed by the
Collabnet people. Which made me deterred from my improvement points since
we got a sense that changes wont happen until the system update.
i am glad to see that this is no longer true and we can move forward.
I actually encourage to go tableless and maybe adding more span tags
around
so that the content becomes more manageable.
Could you please give me an example of where more span tags would
help? I'm not against it, but I don't know where they could/should go.
Well menu's logo and including more tabs would be useful so we can target
more specific elements. Menu headers, or the tabs for example. I am not
sure exactly what, I would have to play around to find out if there was
something we REALLY need it.
I would like to propose some CSS toolkit so the projects can have a
better
way to homoneagize their classes. Buttons and roundcorner elements
should be
written in CSS and be documented on the Wiki so that project can
re-utilize
this across the board.
The problem with this is that rounded corners are a CSS3 feature,
supported only by a few browsers Even then, we can't use border-radius
(invalid CSS2 property). We have to have -moz-border-radius: 3px;
-khtml-border-radius: 3px; -webkit-border-radius: 3px;
Well I don't mean CSS rounded corners, but image rounded corners like for
example the one used for the cover page info bubble (the one with the
gull). Have it globally accesible through a specific class can save a lot
of time for people designing specific projects. They just need to know the
name of the class and they will have their info bubbles.
Another one could be butttons for example.
So I'm afraid this will be something to look at in the more distant
future. The other problem is that the Wiki CSS is quite different to
the OOo homepage, and we can't easily change class names because they
are generated by MediaWiki.
I am familiar with both CSS and I understand what you mean. But this is
something that we need to decide, also MediaWiki elements vary greatly
from the page. We could mimic Mediawiki way of doing things in the page?
That way we could have these elements also homogenized.
One big difference for example is the way the menus are positioned,
Mediawiki give priority to the content while the OOo site gives priority
to the menu. I think Mediawiki is better way to go with this. The original
MonoBook CSS was created by Limi, one of the biggest CSS figures from the
Plone community. I think his CSS structure is superior to the Collabnet
one.
The tabs were just one example; on the
website we can have those span tags inside, but on the wiki we cannot
do this without editing core MediaWiki files.
I would also want to have infoboxes like the ones at yahoo.com portal
where
you have boxes with tabs that show different content.
Some would argue that this would be information overload, which goes
against the original motives for the new design. Even if we had these
tabs, the content would have to be manually updated. What I would like
to see is a RSS feed link on the homepage, and a link tag in the HTML
to a RSS feed for OOo updates (e.g. important news, new version
updates), etc.
One problem is that the information is presented very plain. They see text
as a wikipage to be exact. For example the original education project
(sorry ericb) looks more like a wikipage than a real site. Compare
http://education.openoffice.org vs http://porting.openoffice.org/mac/ and
you will see what I mean.
The key is that not every Project lead is a web designer and the key of
having a toolkit is for them not to have to become excellent designers.
Instead have a bunch of classes that they can have (if they wish for).
about the boxes I dont think this is information overload by any means.
Yahoo abused the infoboxes but the infoboxes are a great idea to exactly
not have a site running down forever with content. Take the OLPC
information box.
http://laptop.org/en/laptop/hardware/index.shtml
Is a good way to provide different type of information without making the
reader scroll down forever.
Also i would like to propose building some wiki documentation about how
to
position projects pages. Like best practices, adding a significant
impact
image. Define the look & feel and colors that we recomend to use
(preffered
hex).
Could you please elaborate a little on this? I'm interested in this
kind of idea, but that is what I'm trying to do with the Website Style
Guide - is there anything you would like to see there, or do you have
any ideas on how it could be improved? (except, of course, with more
information about CSS which I still have to add :) )
Well we can document the design elements for example, or generate
coverpage template/layout in css, a information grid template, and so on.
Then we document them and we mention how to call them.
Something like this:
http://layouts.ironmyers.com/
Goran, lots of good points from you (and bugs :) ).
On Tue, Nov 25, 2008 at 11:02 AM, Goran Rakic <[EMAIL PROTECTED]> wrote:
[...]
I don't know if we need min-width property (together with IE hack) for
content page. If screen is not wide enough, #campaign div is floated
under #actionstatements but this can also be a feature, not a bug.
This is definitely a bug, and a nasty one too. I have added a
min-width property to #content so it should not be moving below
#navcolumn any more. I have also set #navcolumn to display: none for
the homepage, so it looks as it should. The header bug should only be
on test.OOo now. That's on my needs-to-be-fixed list, along with the
IE6 search box bug.
Thanks again for your feedback!
- Ivan.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexandro Colorado
CoLeader of OpenOffice.org ES
http://es.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
