On Tue, May 11, 2010 at 5:54 PM, TJ Frazier <[email protected]> wrote: > On 5/11/2010 08:29, Christian Lohmaier wrote: >> >> ... >> Well, any effort now, before the migration to Kenai would be a waste >> of efforts IMHO. Better be the first to raise your hand when the >> staging server is available. I'm pretty sure we need to do some more >> or less heavy adaption of the website anyway. >> >> [snip] >> >> Yes, css is full of legacy cruft. But it isn't easy to just throw out >> everything as OOo is huge and you never know who else is using parts >> of it. >> Not to mention the servlets, IZ, Mailinglists, anything that is >> dynamic basically. That combined with different level of access rights >> (not all users see every control available), then you need to be extra >> careful. >> >> But yes, the migration to Kenai is a great opportunity to get this >> straight/to clean up. >> ... > > It seems just common sense to put off changes until the conversion, but > sometimes common sense is just ... wrong. > > Forgive the old guy for maundering on, here, but in forty years of systems > programming, I got called in on a /lot/ of conversions, upgrades, > re-hosting, ... Here's my advice from down in the trenches. > > Any improvements you can make in the old code, /provided/ they can be > completely tested and shown to work, are very worth doing. "Mission creep" > is a deadly enemy of good conversions. Doing the work now also allows for > major "schedule slip" in the conversion ("We won't be able to start for > another six months."). It makes the conversion effort easier because it > defines what the output should be, and reduces the level of expertise > required for the conversion. It also allows for the inevitable "got to have > this" work, which will tie up the resources one might fondly imagine would > be available for cleanup. (I'm thinking of old PITAs like unified login, and > message numbers on e-mails, not to mention golden-rule stuff like > re-branding.) In short, do as much as you can ahead of time; you'll be glad > you did. > > And if there are "cruft" parts of the code that are in fact being used in > some obscure place, the time to find that out is /now/ -- some feature may > be wacky for a day, until we restore the missing code, but it may be missing > for a long time if we suddenly discover that it needs to be converted. > -- > /tj/
I think this conversation is going on a completely different path from intended. I have seen the code plenty of times I think we should make decision upon certain aspects of the HTML tree: - CSS Usually I have a CSS for layout, and another for styles. Should we continue like this? What about browsers specific CSS. Or content-generated design on CSS3 where we could use it for localization of menus (more on that later). - 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. - Meta data Maybe should be slimmer, many designers argue the validity of the Meta-tags, both keywords and description. - 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. - 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. - 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. - 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. - Social networks Buzz... but still open to consideration. OOoES has a Google connect for example, but the lack of javascript positioning on the site, disallowed me to plug some key widgets. - 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. The site however is a pain and things like comments could greatly help us on some areas like documentation improvements or reference guides. This is different comments from code but comments on the content of the site by visitors. Google friend connect served for that porpouse but should be think about wherre it makes sense and if we want to have our own. - Identity Probably outside of the design spectrum but should we consider adding OpenID support, avatar presence and other things related to the way usrs of the site can do. Then again, is mostly delegated to SSI so I wont get much about that here. -- Alexandro Colorado OpenOffice.org Español http://es.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
