Website Elements & the Chamberlain Civic Center Website

Design & Colorspace

The open, almost spare design communicated to us (the student web designers) from the example web page we were given to examine (HTML p. 383) and which the instructions of the Rubrik guide us to create for the initial page (Rubrik steps 12 [HTML steps 3-7 on p. 384], 13 [HTML steps 8-15 on p. 384-5} and 14 [HTML step 16 on p. 385]) provides an excellent model to continue throughout the remaining pages of the website we are directed to develop.

In fact, it is important to continue this design for several significant reasons. First, one is given to understand from the image provided in Fig. 5-55 on HTML p. 383 that this is the type of design the client prefers. Second, it is an open, inviting and clean design -- with an almost Scandinavian sparseness to it, which gives it a decidedly elegant and artistic look and feel -- and as the Chamberlain Civic Center represents and works with all types of performing arts organizations, this is an excellent association to cultivate. Third, cohesiveness of design (i.e., having all pages present a common design structure) is, as was learned earlier, of utmost importance to the satisfaction vistors report when visiting a site. Hence, the decision was made to continue on each page the open, white field (as background); the top, horizontal, tabbed navigation system (with small gray tabs and black text before mouse activation and with small red tabs and black text upon activation); and the use of predominantly red H1 text (no background) {note: a few pages, such as Events.html, used gray H1 text as well) with gray H2 text and black body text. All hyperlinks are in red, but on mouse activation they turn a plummy purple. There is also spot color use of purple. Dt text can also be either gray (events.html) or black (facilities.html or box_office.html).

From this discussion, one may gather that the primary (only) colors are: white, black/gray, plum/purple, and red.

Also, all of the pages use the primary (horizontal) navigation system as laid out on the calendar page, but some have an extra "internal" navigation system as well that is included within the text of the file (e.g., local_arts.html, web_elements.html, events.html). These use the red hyperlinks and when the mouse scrolls over them (activates them), the text itself changes color to a plum/fuchsia color.

Top

Text & Code Reuse

In this section, I wish to provide a note about text and code reuse and acknowledge contributors, including myself and others. First, the text for the Feb.html page was provided for us in the assignment. On the Events.html page, I came up with all the text (quite a bit) EXCEPT for the ones that are February events, as these were provided for us as part of the assignment. I based the text for the box_office.html page on that for the box office for Dixon Hall at Tulane, i.e., the Lupin Theater box office, though I simplifed it a good deal (text and styling). I did the same for the facilies page (i.e., I based this text on that for the Tulane Theater page: Department Facilities), but again, I simplied everything and created much of my own text to fill it out. Nevertheless, I owe a debt of thanks to the Tulane Theater web folks, whoever they are.

Furthermore, I designed the text and layout for the directions page after looking at the one for the University of Mississippi's Ford Center for the Performing Arts, which gave me the idea for using the Google map. So a debt of thanks is owed to them as well. (If you get some idea that I did some web research before and while constructing my page, you would be correct.)

I also reused one of my own .html pages; one from week 6's assignment, the Gresham Children's Choir Home page -- i.e., the one for the local arts. I redesigned it a bit and added a number of organizations to it (almost double the links!) I was able to reuse the .html and just add more links; I only had to re-tool the .css file to present a new design-face consistent with the design for the Chamberlain Civc Center. Very convenient! In other words, I took to heart the works in the assignment: "You are not expected to start new websites from scratch. Don't. Remember, reuse is one important topic in computer science. Be a scientist, reuse your work!"

Top

HTML files v/s CSS files

There are 12 files that make up this website: 8 html files and 4 css files. First, we will cover the names of the html files, followed by the names of the css files, and then the relationships between the html and css files (which html files depend on which css files for styling and layout), and we will briefly consider the styling choices made by these particular file groupings.

Of the eight html files, we have the following: Feb.html, events.html, box_office.html, facilities.html, directions.html, local_arts.html, web_elements.html, and contact.html. Of the four css files, we have the following: ccc.css, calendar.css, ccc_others.css, larts.css.

Two of the three html files with secondary navigation systems (discussed above - include: local_arts.html, web_elements.html, events.html) use the ccc_others.css file. These two files also use the larts.css file. Of the three files with secondary nav systems, only local_arts.html and web_elements.html uses ccc_others and larts.css. The styling for events.html was a sort of hybrid between what was used for these other files and for the calendar web page (feb.html), so it was handled differently -- more like the calendar web page.

Consequently, we have two html files that depend on ccc_others.css and larts.css (local_arts.html and web_elements.html) and the other six html files all depend on the ccc.css file (except that events.html also depends on larts.css and feb.html depends on calendar.css because of its inclusion of the calendar styling. The reason that events includes the larts.css file for styling is because it uses the "Top" link that is placed throughout the content of the file, allowing the page viewer to immediately jump back to the navigation system at the top rather than scrolling; larts.css holds the styling for this "Top" link system. For more on the styling that is produced by each of these .css files, please see discussion in sections below.

Before concluding this section to move to the next, a few words should be said about the decision-making behind the division of css code into various files. Partly it was due to borrowing files and heredity thereof. For example, since I needed to use the "Top" hyperlink (discussed in the previous paragraph) and its styling was in lart.css, I saw no need to 'reinvent the wheel' and I simply borrowed this small file with its limited styling (it also has some limited paragraph styling).

Next, because I foresaw that those html files having multiple navigation systems would need a different styling approach to those that did not -- I decided to encapsulate their styling in a file separate from the others; hence, this accounts for the establishment of ccc_others.css for the local_arts.html and the website_elemente.html files (as both of these html files have two navigation systems) and the establishment of ccc.css for the other 6 files (feb.html, events.html, box_office.html, directions.html, facilities.html, contact.html). [Note: at this point, I had not foreseen that events.html, whose styling started out like the files using ccc.css (the other 5), would end up needing a second navigation system. I was not yet far enough along in design. This would, of course, present problems to be surmounted. See discussion in a later section.

At this point, the intention was to keep (most or all of) the rest of the styling in what was intended to be the primary file for this purpose, ccc.css, especially as it was initially thought that the rest of the files would be very similar in structure. However, there were differences that eventually had to be addressed within ccc.css that could have merited separate css-styling files for each html file (but there would have been, undoubtedly some significant code duplication this way). Nevertheless, the solution I adopted, that of leaving the code to account for all the styling idiosyncracies between the remaining 6 html files in one css file could be said to be confusing. My answer to this is: yes it *could* be, without proper commenting, which I think (and hope) I have provided.

Furthermore, the main (structural) difference between the two sets of files (set one, 2 files: local_arts.html and web_elements.html; and set two, 6 files: feb.html, events.html, box_office.html, facilities.html, directions.html, and contact.html) is that the first set (of two files) has the main navigation system AND a secondary inter-page navigation system (mentioned above). Because of this, it was felt that styling would be sufficiently different (though there would be overlap, as well, between the two groups) to merit handling the styling of the two groups in two different files, hence the establishment of ccc.css (for the group of 6 files) and ccc_others.css (for the group of two files).

Top

CSS for Style and Layout

Using named sections and div's were more important in this project for dealing with what I termed above as 'styling idiosyncracies' between pages. So, not only is it important to know what css file goes with what html file (discussed in the immediately preceding section) in this code design, but it is also important to know what section or div applies to what html page (or part of a page) to, effectively, 'turn on' some parts of the styling code and 'turn off' others.

First, since neither larts.css (designed before this project and simple enough that it does not have to address more complex styling issues) nor calendar.css (designed purely for the calendar layout only) deal with multiple, changing styling complexities, they are both exempt from this consideration (they have no sections or divs) and need not be considered for this discussion. So that leaves only ccc.css and ccc_others.css

Second, ccc_others is by far the simpler of the two files. Inside it one will find the default styling, body styling and header styles, all fairly standard. Where it becomes interesting is where the id attribute selectors come into play. As mentioned above, they cause different sections of styling code to be activated or deactivated. For example, in ccc_others.css, there are two sets of id attribute selectors at play, labeled #ONE and #TWO. Since the HTML files that employ the ccc_others.css file have two sets of navigation systems, one might reasonably assume that #ONE applies to the first (or main) one and #TWO applies to the second (or secondary) one; such an assumption would be correct. Within the HTML files, the main navigation system resides within a Div section id'd as ONE and the secondary navigation system lies within a Div section id'd at TWO. Then using these labels within the css file allows us to target styling for each section that can be (and is) different from the other section. Consequently, whereas the main navigation system has gray tabs (that turn red when activated) hanging from a red line, which distinguish it as the main nav system, the secondary nav system is a set of embedded links in the page the text of which is red and which turns fuchsia when activated. Thus, the two different systems have different styling and are distinct from each other.

The last file (the behemoth - at least for this project) is ccc.css. With minimal comments, it is eight pages long. Fully commented, it should run to 10 or 11 pages. Why so long? Because of the various styling idiosyncracies handled. For example, several use horizontal lines, but some of them need the lines to be 50% in width, black in color and centered; some need to be 85% in width, red in color, and not centered. Also almost all the html files use either unordered or ordered lists and they all call for different fonts, font-sizes, colors, margins, weights and more. Using divs and sections provides a way to easily keep everything consistent for all divs or sections of a certain name, but yet allow for variety (between divs and sections) without having the variety of styling creep into and affect other areas you would not like to expose to alternate formatting. In other words, it provides a wonderful mechanism for managing your styles and maintaining control.

CCC.css, like ccc_others.css, also employs the id attribute selectors for managing the two sets of navigation systems. Initially, it was not foreseen that this would be needed. The idea was to keep this within ccc_others.css. However, the html file which eventually made use of two navigation systems necessary for ccc.css was events.html. In the beginning, I did not have a clear idea of what the file content for this file should be and I was thinking it would be shorter than it turned out to be. However, as it grew, I realized it would need an internal navigation system with links to jump back to the top. Yet, it was more of a hybrid file at this point, having more styling in common with the files using ccc.css than the ones using ccc_others.css EXCEPT for this one point. So, I took the div's in play within the html files using ccc_others and set them up in events.html in much the same way AND THEN took the code from ccc_others.css having to do with the styling of these div's (the #ONE and #TWO) and put this into the ccc.css file. One might ask, why did I just not include the ccc_others.css into the html file for events.html (instead of taking the code for #ONE and #TWO out and putting it in ccc.css); good question. Yet, I did not do this because it would have been too much work to overcome the other styling that ccc_others would have applied to the html file of events.html, especially when I had a perfectly serviceable file in ccc.css EXCEPT for the need of the #ONE and #TWO div styling code.

In addition, ccc.css employs still other id attribute selectors and it does so as follows (i.e., the majority of the functional html code in the files listed is encapsulated into the section with the given name):

• 1. Section: 'summary';

        Files: feb.html, box_office.html, facilities.html, directions.html.

•  

• 2. Section: 'summary_addy';

        File: contact.html.

•  

• 3. Section: 'summary_events';

        File: events.html.

So, in other words, the styling for those files encapsulated in 'summary' will be the same; the styling for 'summary_addy' will be similar but have suble differences for variety; and the styling for the file in 'summary_events' will be like that for 'summary_addy'.

So, as mentioned above, it is true that the code identified by id attribute selector could have been put in different files (instead of sections named 'summary,' 'summary_addy,' and 'summary_events,' we could have had css files with these names to include in the html files instead) and then ONLY those file could have been included in the html file it went with, but this would duplicate common code at least 3 times. So, it was felt that using sections was a better way to go. Without a clear preference expressed by our book, I was left to my own thought processes to decide and that is what I came up with.

Top

Issues

I should write down issues as they occur because in the heat of design and pursuing the goal, the next one that arises tends to supplant the one that came before. I feel like I had so many during the design of this project, yet now I can only recall a few. Maybe it happens that as I work with what, to me, is an issue at the time, once I have the solution, it no longer looms as large nor seems like it should have been such a problem, but seems more like an 'old friend' now (weird as that may seem).

At any rate, there is one issue I HAVE NOT resolved and it vexes me mightily, but I think I am in good company, so that makes me not feel quite as bad as I might otherwise. It involves the unordered list. For some reason, I have not been able to get it to work properly with this project, try as I might. I even spent a fair bit of time researching it on the web and trying out different solutions that were proposed there, all to no avail. Finally, in the interests of making progress in limited time, I had to give up and go on. Still, rather annoying, that!

Another issue which turned out to be solved very easily (and which I did not notice myself at first) was the trailing red line for the main navigation system. When I was getting close to being done with coding both html and css I asked a friend to look at my project and he immediately said, "What's up with that red line trailing out?" I hadn't really noticed it before then (too close to the forest to see the trees). But fixing it simply involved tweaking the margins of the nav system.

The usefulness and necessity of controlling code (the application of styling or not) by using named attribute selectors as often as I did was a real eye-opener for me, too. At first, I was a bit perplexed how to handle some of these styling differences. It was a kind of mental leap to permit myself to use these so freely. Once the leap was made, I was off like a gazelle!

In building feb.html -- specifically the calendar segment of the code -- I encountered some difficulty with step 9 at first. That is, getting the spiral notebook edge to show up correctly on the borders was non-trivial. When I attempted to enter it, I thought I could specify each piece of the back ground image (the top-left piece, the top-right piece, etc.) on its own line of code as in 'background-image: url(top-left.jpg)' and then 'background-image: url(top-right.jpg)' with several of these statements, one for each image (and then an accompanying background-position and background-repeat statement for each image -- I know it probably sounds goofy NOW, as I would have had loads of these statements, but I was thinking it would be a simple way to easily grasp what I was doing when I looked back at it). Only this DID NOT work. To work, it had to be entered as:

"background-image: url(topleft.jpg), url(topright.jpg), url(bottomleft.jpg), url(bottomright.jpg), url(top.jpg), url(left.jpg), url(right.jpg), url(bottom.jpg);

background-position: top left, top right, bottom left, bottom right, top left, top left, top right, bottom left;

background-repeat: no-repeat, no-repeat, no-repeat, no-repeat, repeat-x, repeat-y, repeat-y, repeat-x;"

Sigh ... live and learn. I hope I have a lot of living left to do because I sure have lots of learning left to do!!!

Top