Friday 23 November 2012

Creating my Website w/ The Design Cycle 2

Developing My Portfolio Website


Problems and Resolutions

Cross Browser Functionality
Throughout the majority of creating my website I used Google Chrome to check what the page would look like by the user instead of the inbuilt function provided by Dreamweaver. However, with the knowledge about cross-browser functionality I decided to use other browsers to preview my website and I came across some issues, this brought in the usage of Vender Prefixes. Vendor Prefixes are only required with sophisticated CSS3 property elements, seeing as I had multiple box-shadows, border radius', etc I had to use VPs to get the required affect I desired across most browsers. With websites such as cssportal.com I was able to generate the prefixes needed for cross browser functionality. This website also managed to teach me what certain CSS3 properties work within particular browsers and how they would look like with a preview box. However, the issue about Vendor Prefixes is that I had to implement multiple lines of the same code in my stylings each time I wanted to add a property to an element. Not only adding this code is time consuming but begs the question of unity within the same rendering for browsers or having some other method to support all of them.

Jquery Libraries
When importing certain features within my website I came across referencing JQuery libraries for them to work correctly. An issue I came across at one point was the fact that I was using an old version of a JQuery Library for my smooth scrolling affect. This meant that when I came across referencing to a more up-to-date version of the Google JQuery Library for my carousel, the carousel did not work as it was told to use both libraries. To resolve this issue, I made sure I was only referencing one JQuery version from the same source and not referencing both of them. The usage of comments and clear definition can help me realise my problem much quicker in the future when I do import similar JavaScript dependant features.

Correctly Defined JavaScript Properties
When setting up the main carousel for both my main page and portfolio page I needed to make sure I was setting the correct visual properties for both. Visual properties such as the size of the main panel, the size of the thumbnail frames, whether or not to have an information overlay and what not. In order for these features to work, they must be defined exactly otherwise the slightest hitch-up in code can completely disable the whole carousel feature. Whilst implementing the carousel, I use a classmate of mine to double check whether or not I was writing the code correctly with what certain symbols had to go where. Furthermore, with using the correct tutorials from http://spaceforaname.com/galleryview/ I was able to create the desired carousel I wanted for the website. 

Positioning Preferences
When positioning elements with CSS there are a multitude of ways one can do it. Whether it be padding, margins, position selectors or just plain floating, a variation of using these features was the best for my portfolio website. However, I did come across a few problems when I wanted to fix my header. Initially, I used "Position:fixed;" to fix my header however I forgot to use the correct top and left selectors to position it correctly. Instead, when using only position:fixed this brought an unwanted affect further down the line as my header was inheriting this margin-top "like" property from one of my pages. This took me one or two hours of toying with my CSS, cleaning it all up, using websites such as j-fiddle to display my problem to friends and trying to fix this very basic error. Eventually, my classmate and I figured it out after much experimenting. But just the simplest of code can completely create errors which seem to have no correlation to what you were aiming for initially. This can seriously throw a spanner into the works as most of the time during those 1-2 hours I was chasing leads which had nothing to do with my error. This proves to me that if I never noted down my research into the tools needed in CSS, I could've been stuck with this issue to this very day.

Tips to Avoid Further Issues
          
Usage of the Cascade in Cascading Style Sheets
As stylesheets are read from top to bottom when the browser passes over each declaration it pucks up new properties and resets the properties that have already been set by declarations. Therefore, if an element with associated styles is mentioned again, not only it will inherit those stylings but you can also reset them by re-mentioning the properties. This affect was useful when styling my sections for the page as I gave each page a height of 600px, however for my final page not only did I want it to inherit the initial properties but I wanted to re-write the height so it would look more like a footer. Therefore, not only was I able to keep the same stylings but I was also able to re-write some properties in order to befit the specific id, this shows the importance of the cascade affect as I'm writing less code.

Commenting on Code
A great method of not keeping code messy and incoherent is using comments to clearly display what a chunk of code does. For example, when I was referencing all my exterior stylesheets and scripts, I used comments to clearly display what the code did. Otherwise, if I didn't use comments in this situations I wouldn't know what certain JQuery library was being used for or what a certain JavaScript file was doing, especially as I have low knowledge about JavaScript itself. Addiontionally, commenting was also useful for when I was setting stylings in CSS, by splitting up what was for positioning and visual I was able to clearly see what certain properties did what without a massive cluster of code instead.

Using Reset Code
Originally when I set up my main CSS Stylesheet I used a reset code at the beginning of it before starting on my own stylings. I used this reset code to abolish the semantic stylings that come already with HTML elements. If I wasn't to use this reset code then I would receive unwanted padding/margin/etc affects that would automatically be associated with the elements I put into my HTML. The reason why HTML has semantic stylings is not totally understood by me but hopefully in the future HTML will because more independant of content structure and CSS independant of presentation.

The Usage of Classes and IDs
When styling with CSS, we can group elements together to be stylised with Class elements. They're defined with using a "." before a selector, assuming that it's previously defined with "class=" beforehand. However, if one would want to specifically stylise one element, it is better to use an id as they're not meant to be re-used.
During the process of creating the buttons for my navbar, I used one class element that would be associated to each button. To avoid having one massive block of code for each button, using class elements allowed me to only repeat the "class=" reference in my html for each listed item. Therefore, using class elements saved me a lot of time and code rendering for my website.

No comments:

Post a Comment