Hi *, On Tue, May 11, 2010 at 6:54 PM, TJ Frazier <[email protected]> wrote: > On 5/11/2010 08:29, Christian Lohmaier wrote: >> [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. >> [...] >> 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.
Well, if you do upgrades on the same technology, then I fully agree. > Any improvements you can make in the old code, /provided/ they can be > completely tested and shown to work, are very worth doing. THAT is exactly the point. There is no way to test it. Testing would mean having it on the live site. And doing testing on the site that is presented to the user ain't what I'd like to do. Let alone the "completely" - as mentioned in the other post: It is unclear who uses what css elements, OOo just is too huge, you surely will miss some of them. > "Mission creep" > is a deadly enemy of good conversions. Tons of broken links (used on external sites, etc) because someone did revamp a site completely is the other side of the story. > It makes the conversion effort easier because it > defines what the output should be, and reduces the level of expertise > required for the conversion. Oh, the what it should be/look like can start now. I'm hoping that the branding/marketing/ux projects will come up with a nice design/guidelines for the new site. > (I'm thinking of old PITAs like unified login, and > message numbers on e-mails, I doubt that much will change in that regard unfortunately.. > 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. Sure, I fully agree. It is the "as you can" that's the problem in my eye. > 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/ If you can communicate that to the affected entities, tell them why you broke their part of the site while they had an important event and thus lots of traffic on the site ... > -- 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. I don't see a big difference between doing it now and breaking the site, or breaking the site once it runs on kenai. The difference is that kenai offers different possibilities, different ways to remove the cruft/replace it with something more suitable. I don't know whether you were involved in the last redesign. Be assured that we already did try hard to clean up the css. And we did already throw out much of useless stuff. But the css of CEE is really a nightmare, full of really stupid inheritance, duplication, no structure/separation. This was when we had a statging site. And believe me: We did break it often enough. And when CEE was updated by CollabNets admin, a big part of our efforts were undone again. This time on the live site. As it was not just readding stuff that was removed, cleaning is/was not an easy task, and many of that stuff still is in today (as the risk of not knowing where the code is (re)used/referenced from and thus breaking the site is there. Nobody wants to be blamed for an embarassing defacement of the site....) ciao Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
