Hi Alexandro, On Tue, May 11, 2010 at 7:27 PM, Alexandro Colorado <[email protected]> wrote: > On Tue, May 11, 2010 at 5:54 PM, TJ Frazier <[email protected]> wrote: >> On 5/11/2010 08:29, Christian Lohmaier wrote: >>> [snip] > - CSS > Usually I have a CSS for layout, and another for styles. Should we > continue like this? What about browsers specific CSS.
No browser specific css. Don't put every statement in one single stylesheet. Seperate it as much as possible. > Or > content-generated design on CSS3 where we could use it for > localization of menus (more on that later). I think we should stick with the current approach, as OOo has many native-lang projects, and the website creation/maintainance should be simple. > - How should the menu be structured > I think that a pluggable design is better than a monolit one, so > having 1 menu design is really not a good option since some frontpage > for example, dont want a menu at all (ie. homepage). Having this > retrieve to another project oriented file would be more suitable. This is exactly one of the reason why in my opinion we should wait for a kenai driven site. With the current site this just is not possible. You can differenciate between servlets categories and the main page, but that's about it. > - Meta data > Maybe should be slimmer, many designers argue the validity of the > Meta-tags, both keywords and description. I don't think the current metadata is too excessive - basically only keywords and a description one. So how could that be any "slimmer"? > - Javascript > We should think how should we used it since there are potential with > localization issues to have a use at JS, but also issues regarding > people disabling Javascript and having a fallback would be good. We used javascript, because that is the only way on the current site to do somethng else but to deliver a static page. Thus there is no alternative for javascript on the current site. Thus wait for kenai. > - Mobile design > Not sure if this is relevant to many but, having a mobile oriented > site could be useful specially for information, however here the > workability might be too great. Mobile like cell-phone mobile? > - Localization > This caused some problems on people wanting to get rid of the default > menus because of the lack of localization. So you have a page on > language "a" but has all these elements on language "b". Something we > definetly need to think about from both code and design perspective. > Having icons might be a good way to get around, but also there are > issues of being too ambigous, JS could help us select the right > language but also present some issues. The language is not really the problem here. The problem is providing those pages in different langauges in the first place. If the main menu entries are localized, but the user still gets an english page, this would be worse than having the english menu entry. (IMHO) > - Comments > Code should be better commented for project leads to be able to easily > hack it, having maybe a simplistic design could help them speed up the > setup. Oh, there are comments in the template code. Of course in the actual pages, it is up to the editor to add comments. > [...] > - Read/Write web > The wiki is excellent and the site is weell.... not. Basically because > is easy to interact and write to it on the wiki. As kenai also has integrated wiki: Is it worth thinking to move from a cvs with html files to a wiki type structure? Don't get me wrong - stuff that is meant for collaboration should definitely go into the "global" wiki. > [...] ciao Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
