Release Management Case Study - Formerly "Styling Fixes"

Since we have been making changes to the style here, we need to export the style from here back to where you develop styles, or updates from there will overwrite changes we have made here. One of the changes was to remove birthday and location from the signup forms. No more CSS overrides. Instead, I have a css supplement that facilitated the removal of those fields.

Here is the full contents of /css/dansSupplements.css

Code:

.errorPanel
{
   color: rgb(0,180,0);
   background: rgb(235, 255, 235);
   border: 1px solid rgb( 0,180,0);
}

.clearFloat{
   clear:both;
   width:100%;
   height:1px;
}
.tweet, .facebookLike .sharePage{display:none;}
.sidebar .sharePage{display:none;}

.elementHidden{display:none;}

There is another change I want to ask about. I don't know if I did it on the wrong version of the style, but the change I am talking abot is to





I am not keeping track of all the changes, I am just figuring they all will roll forward from this version, but that means if you have changes somewhere else, they need to be merged with these.

The concept that development is forward actually originated with the situations like this. To move forward, keeping versions straight has to be handled efficiently. No time for messing around, so the easiest way to do it is always have a migration path from dev->live. When using live for dev, as we started doing here to recover from May 9, it puts is in position to learn the hard way what is not forward..

 

The changes will roll forward because I work from a fresh export of live in every session. In addition, exporting and working from a copy of live provides a rollback version in case of problems.
I can look at this tonight.

 

Okay, I've got a copy of the style as it stands right now on my dev version.



Time to see what's up.

 

What happens if you have pulled from live and while you are making changes I am making other changes to live?

 

Let me know you've made changes, and I'll export again. I haven't done anything yet as I was interrupted.

 

I see the changes to the gradient stops in the primary message box (where you're reading this right now) and in the forum node info boxes here and in my dev.
I'm beginning to see the problem.
The big difference is in the log in page. It looks really nice here: (Gender and birthday boxes are gone)




But in my version that stuff is still there, and my nice yellow terms and rules are red again.




And I see your css on the legacy-systems server:



However, for it to be valid wouldn't I need the classes that correspond to these styles on my copy?
I think so. That means the whole forum needs to be copied and pasted over to my version every time you make a change. Kind of a pain.

I have an idea but I'm not sure it would work. It depends how the css affects the rest of the system. My impression is that css affects styles and colors only. I can change how things look and where they appear on the screen, but no matter what I do with the css, I can't wreck how the system works, I can only wreck how it looks.

If that is true (if I'm wrong my idea won't work) couldn't I work on the css on the live system, but on a copy of the live style that is not user selectable? Once the style is acceptable and the changes look good that new version can be made the default style and it will be the one users see. In fact, in this scenario I could see us both working on the same style, and having it selected for our use, but not for other users, via the selection menu in the lower left corner.
So, for example, we are in Longview 1.3 as the default now. I could duplicate that style and call it something else that indicates it is our next iteration, we could both run it here and make changes to it without users being the wiser. Then when the changes are done it goes live, and another copy is made, where we make our next changes. I'm going to assume that we will either notify each other of the changes or that the changes will be clearly an improvement and not to be messed with.

There is one snag in this idea, and that is the log in page is always the default style, so if I'm working on the log in page I would have to work on the live style. So for log in changes it looks like I would need to have the copy of live made for dev. Right now though, the log in page looks pretty nice I think.

I'm going to look around for the error panel you are referring to, but I am not making any changes to live until we come to a conclusion about how this would work best.

 

The changes I made were in the templates only. Does that mean you have to copy the whole forum over to your dev area? I don't really understand how templates figure in when making a new style. At first, I thought templates were part of an imported or exported style, but then I saw things go wrong and I never have understood since then. That was months ago.

I think if you export the style and get the templates with it, and put that supplemental css file in the css folder of your xf, then it will work. I'll try it now. On my copy of xf, not yours.

 

I tried exporting the style and copied the css file to http://devserver-002.info/testareas/L_S/. I don't know everything to look for.. Here is a side by side

 

You can just drop the changes I was trying to make if they are causing complications.

 

Is this a good color scheme for poll questions?

 

It could be better. The title text should be darker red and the background would look better as the lighter gradient we have on the post boxes now. At least its not too bad to read though.
I could make the changes myself, but I am working on trying to figure out a workflow for the styling because I don't want to change the live settings. It will be good to figure out a styling workflow anyway, because I want to apply the styles I have for Holly at some point without jeopardizing the stability of her system.

 

Your changes are fine, and the sign in page looks great. I don't want to change anything about it.

 

good call on the workflow. Do you have changes in more than one environment that need to be merged? Getting by that can be a real hassle, so I want to help that happen if it is needed so it is not hanging over you. That simplifies the workflow when that is not a factor.

I am not sure I have had a good look at Holly's new styles. Do you need a new copy of her system?

 

The styles work flow is so confusing. There are a few things I am having trouble with in these templates.
Starting with 21C:

I'm okay with working only on the latest version of the styles here (and then writing my changes back after I'm done), but I haven't figured out where changes like the one you made to the log in page are in the templates. I need to know how that works so I don't overwrite those kinds of changes. Maybe you could show me how you made that change so I can replicate it on my dev version, and that way I can learn where it is and not mess with it?

I guess what I don't understand is how a style I download from here at 21C, modify in my dev, and upload again here at 21C can overwrite something that was modified here at 21C before I downloaded that version.

I am taking a look at Holly's styles again, because I've learned some new stuff working on the 21C style that I can use to make hers better I think. No major changes or anything, but I've discovered more options in the CSS than I knew about then and I know how to make the background fit the screen at 100% instead of the problem I had with the repeating pattern.
But-- yes, I might need a copy of her current system to make sure the styles will work the way they should. I'm not sure if my version of her system is current, and how my styles will affect your work on that system. If there were changes since that version was made in December, (link to post at 21C where the changes were made) my styles will need to work on that newer copy.
And I have the same question about the changes in the XF that you make at HWC and how they affect styles as I do about 21C, which is, it would be interesting to know where your changes are so I am confident that nothing I do will overwrite that. If there are changes in the style at the live forums I will need to know about those too, although I can probably figure those out by comparing the two .xml files before committing to anything.

As far as where this falls in terms of priorities, I know that at this point my styles at HWC have probably fallen off the radar which makes me really glad I stuck what I had on there in December when I had a chance. However, there are some things that bug me every time I see them, and it would be nice to get that fixed up. Thank you for your help on this.

 

Showing my work. It seems to help to lay things out on the table,(or the screen.)

My first task is to reproduce the new log in screen on my dev version, and part of that is getting dansSupplements.css into a position where they can affect my css.








Don't worry, I'm careful when I go exploring.

 

In other styling news, I downloaded and uploaded another style revision, but didn't make much progress. All the low hanging fruit has been fixed, and I need to level up again, to fix this next set of problems.
The personal details page, for example, is a disaster, ...



The new version is Longview 1.3.1, and is not user selectable. However it is available to admins and I am running it now to check for possible problems before it goes live.

 

This is a really important comment you are making here. When you are the person taking responsibility for holding the versions of a package together, you have to get from the other developers all the detailed information you need. What i am trying to say is there can't be a burden placed on you to track this stuff down, it is too impractical. Version control requires super strict and detailed rules and really, it take special version control software to get it done right but that software introduces other types of problems. I was an IT manager at an insurance company. We had about 100 programmers working there and the whole shop was ground to a near halt because of the knots they had put themselves into with their horrible version control.

It is good that you have run into this the way you have, so you can experience first hand just how difficult it is manage this.

Recommendation
i'll answer any questions you want about what I did but you should be quick to throw in the towel on any non-essential change. Redoing the changes and accepting the regresion that would incur as bad a thing as any regression is, is a small cost compared to the agony and time that could be involved in sorting through these changes. This is a good area to apply your sense of simple practicality and not let yourself get wrecked over changes that would be easy enough to redo.

The Login Form
My objective was to remove the gender and location fields. I checked at XF HQ where I learned there are not controls in admin for just turning those fields off, so it was off to the templates. My plan was to find those form elements and put a display:none; style on them.
That is where the supplemental CSS came in. I am moving that supplemental CSS from the css file I added and putting it into EXTRA.CSS. The reason I shy away from EXTRA.CSS is a quick peek at the page source shows that EXTRA.CSS goes in there the beginning of the css, which means there are tons of overrides that will be block it from having effect. The supplemental css file is placed last,s o nothing overrides it.

So the templates...register form

 

So, thst's it for the login form