Large-scale sites can be a large learning experience. The lessons I learned from my first experience with a larger site has helped me become a better designer.
Projects tend to run over a long span of months and with each project change is inevitable. Designs change, functionality changes, minds in general change. I’m one of those people who actually use calendars, stick to my planned appointments, and I keep my pinky promises. I’m so used to life having a plan that when plans changed, I wished that I had written my code to be more flexible. This is both for not only my sake, but the engineer’s, too.
Since it was also my first time working with an engineer, I hadn’t realized that whatever I had written wasn’t always going to stay exactly the same once functionality was added in. When working on the site, for example, I found myself making a lot of adjustments and sometimes even re-building to make sure that the design and functionality went hand in hand. I gained a few new helpful habits and learned some lessons.
- Things change. It’s best to write HTML so that elements and blocks can be shifted around or selectors changed with minimal CSS adjustments afterwards. Some examples of keeping CSS flexible would be:
- Write basic classes for elements that repeat, then more specific selectors can be written for where things will be somewhat different, but not an entirely different element. IDs can be helpful in cases like these where the same class is used, but the ID will allow tweaking to that specific element.
- Avoid heights on elements where the length of content will change. Also for sites with liquid layouts or responsive design, having percentages instead of fixed sizes for widths will be necessary.
- Do not combine selectors with their classes/ids unless you are sure that these things will not change. For example, if I use a#myIdName and I later change that anchor tag to an input button, I’ll have to remove or edit that part of my stylesheet. It doesn’t seem like such a big deal at first, but when the end result is a fifty-page site and hundreds of CSS lines, it’s a definite time-saver.
- Look at the designs before building, see what every page has in common and then begin writing code using those common hooks as a guide. This is important because of limitations on CSS brought on by versions of IE which keep your CSS file from being able to get past a certain size.
- Keep the engineer and the Integration in mind. When I work on a site now compared to my work in the beginning, if I don’t know my engineer enough or just want to run it by him in case, I ask how he plans to implement functionality and how I can support that with my HTML and CSS. Never assume that your job on front-end is over just because the site has entered the integration phase and it’s all on the engineer. If I write my HTML and CSS flexible enough, with the engineer’s functionality taken into account, it makes it easier for both sides in the end – smoother sailing and less bug fixing. It’s like building a piece of furniture – if it doesn’t fit in the room, what’s the point? Can’t use it. So, nothing is better than being able to take a page from Front-End, dropping in some functionality and Armageddon hasn’t unleashed chaos into the design.
- Be prepared to have a love-hate relationship with long-term projects, but understand that in the end, it will all be worth it. Some days you want to look at everything but your current project and other days, you realize that in some strange, odd way, the project becomes your metaphorical baby. Like a rebellious teenager on some days that won’t stop talking back, these teenagers are mine and when they finally graduate and became something – You feel like a proud mama… err- developer. (Apparently my strange relationships with my projects affect my analogies.)
Since working on my first project, I have remembered these lessons and they’ve helped me until this day. It’s important to consider everything, plan ahead, and be mentally prepared.
Share your questions or comments below, or tweet us @Pixafy!
