I wanted to share the following independent review of UA.edu, which was recently conducted by EDU Checkup, a higher education blog and review site. The review was very positive – in fact the reviewer (Nick DeNardis) tweeted that UA.edu is “one of the highest scoring sites on @educheckup”, and called it “rock star work” (http://twitter.com/nickdenardis/status/5894882926).

Overall, UA.edu received a 98% on visuals, 99% on code, and 93% for information, for an overall score of 97%. While it’s certainly nice to receive such a high score, the most gratifying part of the review is to see an impartial observer pick up on many of the intentional design decisions made during this process and appreciate the rationale and the work that went into those choices.

The review, in video form, is here:

http://educheckup.com/2009/11/20/the-university-of-alabama-episode-129/

Also, UA.edu is currently featured on eduStyle.net:

http://www.edustyle.net/site.php?site=3512

UPDATED 11/23:  As a follow-up to his review, DeNardis blogged about his review of UA.edu on the eduStyle Blog, here:.

http://www.edustyle.net/blog/?p=710

Since there is beginning to be a fair amount of buzz surrounding some of the upcoming browser releases, I thought I would take a moment to share some of the recent news that has begun spilling out on the Internet Explorer front since PDC.

IE general manager Dean Hachamovitch reports Microsoft is “…focusing on three very specific areas: performance, interoperability standards, and hardware acceleration.”

What does this mean?

Well, on the performance front at least some of the slated rendering-speed increases will be due to new technology which allows IE’s browser engine, Trident, to pipe text and graphics rendering through DirectX (older IE versions have used GDI). This means IE will be able to make use of the hardware acceleration in a computer’s GPU to ramp up things like streaming video performance and flash-based interfaces. Of course there is also javascript-parsing-speed increases, but all of the cool kids on Browser Street have been working on this front for quite some time – so this news hardly warrants dwelling on.

Regarding interoperability, there will reportedly be increased support for CSS3 selectors (yay!) as well as pledged support for the evolving technologies outlined in the HTML5 preliminary spec (audio/video/canvas support?).

More detailed information can be found at the following links:

• Paul Thurrott’s WinSupersite for Windows: IE9 preview
• CNet News: With IE 9, Microsoft fights back in browser wars

Update: And now a word straight from the horse’s mouth – IE Blog: An Early Look At IE9 for Developers

WordPress has just won the Overall Best Open Source CMS Award in the 2009 Open Source CMS Awards. In addition to popular vote, judges for this award included Bryan Ruby, who runs CMSReport.com, jQuery creator John Resig, Deane Barker of Blend Interactive, and Karen Koombs, Head of Web Services at the University of Houston Libraries (more details on the judges).

To some extent, WordPress has been a victim of its own success in terms of its reputation as a CMS. Because it has worked so well for the blogging community, the perception has often been that WordPress is merely a blogging platform. In fact, it is a full-featured, highly scalable CMS capable of running complex websites — and running them in a way that is flexible, efficient, and intuitive.

Awards can vary in meaning depending on who is handing them out, but in this case the judges seem legitimate and well-qualified. Clearly, the panel was convinced not only that WordPress is a fully-featured CMS, but more importantly, that it is a very good fully-featured CMS. It’s nice to see the public perception catching up with the reality of what this platform does, and WordPress notes as much in a post on WordPress.org:

This is a landmark for us, as it is the first time we’ve won this award, and it marks a shift in the public perception of WordPress, from blog software to full-featured CMS. No small contest, the Open Source CMS Awards received over 12,000 nominations and more than 23,000 votes across five categories….

Every day thousands of new people are embracing WordPress to power not just their blogs but entire sites and communities without compromising on usability or scalability (as would be the case with a legacy CMS).

Web Communications has been able to customize some fairly complex sites with WordPress (UA News, Research Magazine) and we’ve not yet run into any significant limitations as far as its ability to work as a traditional CMS. We’ve had good experiences working with the code and design side, and our writers/content creators have found the user interface to be intuitive and the learning curve to be painless.

If you want to explore more about WordPress, here are a couple of good sites to know about:

• WordPress Codex: WordPress has a great community of users and some of the best documentation of any open-source project around.
• Digging into WordPress: A blog about how to build, customize, and run sites with WordPress by Chris Coyier and Jeff Starr. Coyier states on the site that he subscribes to the theory that not only is WordPress capable of powering any website it is almost always the right choice.

As mentioned in our announcement of UA Mobile Web, resources on how to get started designing and developing your own mobile site are now available on UA Web Guide.  Currently, this documentation provides themes for the iPhone and Blackberry devices.  As UA Mobile Web expands functionality to other devices, so too will Web Guide’s resources.

The documentation provides code and instructions for:

1. Automatically detecting mobile devices and forward to a mobile theme
2. Setting a PHP cookie which allows the user to get back to the full website
3. Different themes for each targeted device

Click here to download the UA Mobile Web Templates

We believe providing these resources will speed up development time for others on-campus and push forward mobile accessibility at UA.  If you have any questions or comments, please let us know.

As part of an ongoing strategic process to optimize our web presence for all users, the Office of Web Communications has completed the initial development and rollout of a UA Mobile Web site for The University of Alabama.  This site is a custom web site and suite of applications which deliver top-level content, services, and features from UA to your iPhone, Blackberry, PDA, or other smartphone.  UA Mobile Web optimizes web services and content specifically for mobile devices, making them immediately available to users any time from anywhere.  The beta version of UA Mobile Web includes functionality and content such as: 

• News
• Events Calendar
• Campus Map
• Faculty/Staff Directory
• Video
• UA Web Sites
• CrimsonRide
• Contact UA
• Search

UA Mobile Web is now part of the UA Home Page, so that visitors who navigate to www.ua.edu on mobile devices will automatically be redirected to the appropriate mobile version for their device, including separate versions for iPhone and other devices such as Blackberry, Android, Windows Mobile, etc.  Users will always have the option of viewing the full UA Home Page (as it appears in a web browser) via a link on the mobile site if desired.  The UA Mobile Web site can also be accessed directly at http://m.ua.edu/.

UA Mobile Web was developed in-house by the Office of Web Communications using open source code and platforms.  As this is a “beta” release, we plan to grow and expand its functionality and content in the near future and over time.  Also, we are treating this platform as an open one, so there is certainly the opportunity to add to the mobile site with additional pieces and applications developed elsewhere or by other groups.  We’ll be reaching out to other areas on campus to make this option known and available.

We believe this effort represents a significant step forward in making our content and services available to all audiences in as many platforms as possible.  If you have any questions, feedback or comments, please don’t hesitate to let us know.

Ever wonder how web designers keep everything in order when they’re typing out their code? Well, commenting helps a lot in organizing. By using comments, you can also signal out things you want to fix, make note of, or even just keep track of. So how do you keep the comments from messing up the 18 hours of coding you just did? Well, there are different options for different languages.

HTML

Below is the style for your basic html web page which really shouldn’t have too many comments- just nice clean code.

<!-- Comment Here -->

CSS

For organizing your styles and your main boxes- or whatever else you need- this commenting style works for single line or block quotes.

/* Comment Here */

JavaScript or jQuery

For JavaScript or jQuery, this method comments out the entire line starting from behind the back slashes. It is used as an end of line comment. CSS style is used as a short single line comment.

// Comment Here

/* Comment Here */

For block comments the code looks like CSS, but remember to keep an asterisk on each line.

/*
* Comment Here
*/

PHP

PHP can use the JavaScript method, or the pound symbol to comment out a line.

// Comment Here

# Comment Here

For multiple lines, the comment code is like the CSS code but unlike the JavaScript, no further asterisks are needed.

/* Comment
Here */

Ajax

To comment in Ajax, use the same method as in JavaScript.

// Comment Here

ActionScript

When working with flash, you might want to use these to comment on your action script. The first works for multiple lines and single lines while the second is just used for single lined short comments.

/* Comment Here */

// Comment Here

“Why do web designers do that?” Well, there are a lot of reasons, but most of them are just accepted and never explained. Here’s a little look at why we do what we do in the web world.

Why do you use san-serif fonts like Verdana and Arial for body copy?

San-serif fonts retain their appearance no matter how small their size and will read cleanly on any computer. They are also web standard because every computer automatically has them in their font folder.

Why do you mainly use jpg and gif for images?

Tiff files are usually big, having resolution of 300dpi or more, and take a longer time to load. They’re wonderful for print, but a computer screen only displays 72dpi anyway, so all that extra won’t show up even if it’s there. PNGs are wonderful with smooth transparency and a nice transition- but IE6 doesn’t display PNG transparency. (There is a hack for that if you really want it though.) In any case, jpg and gif images load faster and will display in all browsers.

Why do you need an alt tag on an image?

Alt tags are for when your image decides to go on holiday and doesn’t show up for work. A viewer will still be able to read the description of the image in the blank box where the image was supposed to appear. This way, they won’t have to guess at what was meant to show up. Alt tags also help the web readers that blind people use when they have a web page open. So remember to include an alt tag on your images!

Why do you use a grid to design a web page?

The eye reads things in a certain way. In order to create a clear path for the eye to follow, web designers use a grid to line up images and text. Just placing text wherever you like it makes it confusing for the reader. They won’t know which place you want them to look at next. Creating on a grid cleans up the page, creates an automatic hierarchy, and allows a better flow for readers.

Why do you use CSS instead of tables for design?

CSS helps design in a lot of ways. It is more flexible, makes faster changes across all pages, and multiple CSS can style the same page information in different ways for a variety of media. Tables cannot be layered, adjust to different screen sizes, or change their appearance readily over a succession of pages.

Example: Say you want to change a link color to red. CSS can do that for every page in the site with one line of code. With a table, you’ll have to go to every page and manually change the link color. It’s a lot of work, but by using CSS we can eliminate the tedium and save time.

Why are some designers so against Flash?

Flash is a useful tool, but if the same thing can be done with another script language most web designers will opt for that instead of Flash. Why? Because Flash is an application which must be installed on the computer trying to access the information. If Flash is not installed the viewer must download it- which takes them away from your page. Flash also doesn’t make content as accessible for people using alternative web browsing devices, such as the iPhone, or for search engines to pick up information.

Then why do some people use Flash?

Flash is a useful animation tool that provides a smoother movement than most scripts which require the browser rendering to keep up with their speed. Flash script is all internal and therefore must load before it plays. This allows Flash to become separate from the browser’s influence. Because of this, many use Flash for playing videos. It’s a good way to stream video content quickly and efficiently without worrying about what type of browser supports the video encoding.

What about music or sound effects on pages?

If you have to have music on your page- keep it optional. Let people be able to turn it off. In general, it’s not a good idea to have noise on a page since the people browsing might already be listening to their own music and will resent the jumbled sound of two audio waves at once.

Why are designers against flash intros?

Intros take up time that a viewer might not have. Also think about people who come to the site repeatedly. They will have to watch the intro every time they visit- which can get annoying no matter how good the intro looks. If you really want an intro- include the option to skip it. You’ll find that most people will skip.

Why include meta tags?

Meta tags are used by web search engines to help your page get noticed in the way you want. They provide keywords to what your website is all about and help the people searching for the information you have find your site.

Why do you test in different browsers?

Different browsers have different ways of reading code. IE and Firefox might display the same bit of CSS differently. It’s best to look at your website in all the main browsers (such as IE, Firefox, Safari, Opera, and Chrome) before you unleash it upon the world. Also keep in mind with IE that different versions display differently. IE 6, 7, and 8 are very different. I would recommend downloading IE Tester to have a look at your site in all the versions.

With this I hope to have demystified at least a bit of why web designers do what they do. Remember, everything has its reasons- especially on the web!

Web templates based on the design and functionality of the current UA Home Page are available for usage by any official unit of The University of Alabama. There are three basic versions of the templates available, each of which offers numerous options for customization and arrangement of content. The template packages are organized into three different navigation types — one-level horizontal navigation, two-level horizontal navigation, and no horizontal navigation.

Also, new this time around is the release of a significant “how-to guide” for explaining how the templates work and best practices and techniques for customizing them to specific needs.  The UA Templates Guide explains the basic design elements of the templates, details the grid structure upon which the templates are built, describes the process of customizing the templates, explains how to create content to fit within the templates, and provides further resources for learning how to build highly-functional and visually-engaging web sites. This guide is intended to be a primer for working with the templates, and we encourage all users of the templates to read it carefully before beginning any design work.

By using these templates, units of The University of Alabama ensure that their web site is closely tied to the University’s top-level web sites and help build a cohesive and effective overall institutional web presence.  Please feel free to use the templates as needed, and to share this information with anyone you think would benefit from knowing about it.  And as always, please let us know if you have questions, comments or feedback regarding these templates. 

• UA Web Templates: http://webguide.ua.edu/templates.html

I’d like to share the outcome of a project we’ve been working on that positively impacts our top-level strategic web sites.  Below is a high-level summary of the project.  If you have any questions about this, please ask them in the comments section and we’ll be glad to answer.

Background/Challenge

We have recently been working to optimize our key strategic web sites for mobile devices, in order to ensure maximum accessibility and compatibility with all mobile platforms.

The challenge here is that manufacturers of mobile devices use a variety of platforms for mobile web browsing – some very “web-like”, and some not so much.  So taking the content of a web site and making it work in all of the major mobile platforms requires dedicated design processes that target specific devices, and deliver content to those devices based on their capabilities.  By doing so, we optimize the experience of browsing our sites on mobile devices without overwhelming the device beyond its capabilities, and we ensure that the mobile user experience for browsing our sites is of the highest quality.

Incidentally, we have always designed our web sites with mobile platforms in mind, as the process of building web standards-based web sites makes these sites mostly accessible in almost any platform.  But in order to improve the experience for our users, we have undertaken the task of optimizing our key web sites for mobile devices, separate from our standard development practices.

The Results

The results of this process are that we have successfully optimized our key strategic content-related web sites – UA News Center (http://uanews.ua.edu), Research Magazine (http://research.ua.edu), and Dialog (http://dialog.ua.edu) – for all of the major mobile platforms, so that the content on these sites is easily accessible and navigable on all devices.

Of particular interest and focus during this process was development for the iPhone platform, which is growing in popularity and market share.  We have built alternate versions of these web sites that are specifically tailored for the iPhone’s functionality using open source plug-ins that work with our content management system, WordPress, and the functionality of these sites is now very high for the iPhone.

Also, the UA Home Page (http://www.ua.edu) displays very well on the iPhone as well, as it has the exact look and functionality as it does in a web browser.  It also displays well in a stripped-down format in many older mobile devices, but we will be working to further advance its mobile functionality by fine-tuning its mobile capabilties.

Examples

Below are some screenshots of each site in various mobile devices so that you can see how they now appear in these devices.  We will continue to work to optimize and fine-tune these mobile versions of our sites and look for further opportunities to expand our reach to these mediums.  These steps represent a significant upgrade in the mobile browsing experience for visitors to our web sites, and will help us continue to spread our messages to new audiences while staying at the forefront of technology trends.

Click for larger version

More:

• CSS for the Phone (WebTide)
• How to Test Websites for Mobile Devices (WebTide)
• The 5-Minute CSS Mobile Makeover (Perishable Press)

With the world of web expanding to mobile devices, designers must remember that ‘fantastic’ on a computer may be ‘horrifying’ on someone’s phone. However, CSS can help. By using an alternate style sheet, the computer and all the web wandering phones out there are covered.

First, we create a separate style sheet for phones by using media=”handheld” and place it in the head.

<link rel=”stylesheet” href=”name.css” type=”text/css” media=”handheld” />

Now comes the business of design in your CSS. Designing for the phone means designing for a small vertical screen and all the challenges it possesses.

First we take out all extraneous information by placing a  “display: none” in the CSS you want to hide. Once all the important areas have been singled out we’re ready for re-design.

Layout

Divide your layout into sets of horizontal bars. Horizontal layouts will keep things easy to read and provide a better hierarchy for your viewers. Try not to have two much side by side as it makes the text smaller. Make sure that your logo is at the top at all times and your main content comes directly after.

Examples:

To better design your layout, a helpful guide to screen sizes can be found here at Sender 11.

Navigation

With touch screens popping up all over the place, it pays to consider the width of a human finger. Make sure links are large and well spaced so that mistakes do not happen. A good way to do this is to insert plain content or space around links. Another is to go with the button route. By turning a link into a button it is easier for the viewer to put their finger on the right spot.

Look

Remember that people mainly want to browse a page for information, so keep the layout simple. People will appreciate not having to navigate through a ton of images to get to what they want. Try understated patterns in small strips or as a background to add a different feel, or use a horizontal image at the very front to grab people’s attention.

Examples:

To conclude, the most important thing when designing for the mobile phone is readability.  Keep this in mind and everything will be perfect.

For more help and ideas, here are some good sites:

For info on designing for the iPhone try iPhone Microsites.
For examples in web design for the iPhone, try CSSiPhone.
For some good before and after pics try readyforiPhone.

To check if your CSS looks good on all cell phones, refer to “How to Test Websites for Mobile Devices” by Matthew Muro.

Developing for the mobile web is a mixed bag and with new phone technologies coming out frequently, it’s hard to stay ahead of the game.  Unless you have an eclectic group of cell phones lying around, it’s hard to test your site against their browsers.

This is where emulators come into play.

By installing a few pieces of  software, we can quickly refine a mobile style sheet and minimize the damage that different mobile browsers do to our sites.  By the way, all of this stuff is free.

Windows Mobile

What you will need:

• Microsoft Virtual PC
• ActiveSync
• Device Emulator Manager 3.0
• Windows Mobile 6 Professional Images

Testing for Windows Mobile:

1. Open Device Emulator Manager
2. Open an emulator image (e.g. WM 6.5 Professional WQVGA)
3. Once the device has completely booted up, go to the Device Emulator Manager and you should see an entry under Others (you may have to hit Refresh in order to see the device).
4. Right-click on the entry and select Cradle.
5. ActiveSync should pop up.  Click Cancel.
6. Use the Windows Mobile Internet Explorer to browse to your website and start testing!

Blackberry

What you will need:

• Java JDK (ignore the bundles here and just go for the standalone)
• Blackberry Email and MDS Services Simulators
• Blackberry device simulators (download which versions you want to test on)

Important Note:  You must install the Java JDK before the Blackberry MDS

Testing for Blackberry:

1. Run MDS.  Wait until you see “Task- pending push messages” before moving on.
2. Open a device simulator you downloaded (e.g. 9630)
3. Go to the Browser, type in a website and start testing!

iPhone/iPod Touch

What you will need:

• Safari

Testing for iPhone/iPod Touch:

1. Open Safari and go to Preferences (Edit->Preferences).  Under the Advanced tab, ensure that “Show Develop menu in menu bar” is checked.
2. In the menu, click on Develop->User Agent->Mobile Safari 3.0
3. Browse to your website and start testing!

Screenshot Comparisons

By designing, testing, and targeting for different mobile browsers, you can achieve wildly different looks.  Hopefully setting up the above testing environments will make that job just a little easier.

Click for high resolution version

If you have any questions or problems, leave a comment.

I’m sure most of you know by now that we rolled out a new UA Home Page yesterday at http://www.ua.edu.  This new version refreshes the Home Page with a modernized look and feel, simplified navigation, updated functionality, and close integration with the new Touching Lives campaign.  You’ll begin to see more about the latter as the fall goes on.  So what’s new about it?

What’s New?

• Updated, modernized look & feel
• Open layout; lots of whitespace
• Sized for 1024 pixels-wide monitors, allowing larger text sizes and elements across the board
• Simplified navigation through combination of primary and targeted navigation and “toolbox” - all in header
• Contextual, page-specific navigation on second level and below
• Addition of dynamic features-oriented image slideshow on Home (uses jQuery, and images will update frequently)
• Addition of jQuery-enabled Quick Links section on home page to better position wide range of links and resources
• Columnar grid layout, allowing for many combinations
• Greater flexibility and customization, including ability to totally customize everything between header and footer
• Greater ability to position and integrate content and content types
• Integrated with “Touching Lives” campaign

What’s Next?

• New web templates based on the design of the new Home Page will be available on September 28, 2009
• Many institutional web sites (that are managed by WebComm) will be transitioned to new look by October 26, 2009

We’re very excited about this rollout, and the reception has been fantastic so far.  We hope you like it, and we’re hopeful that our campus will benefit greatly from this effort.  Let us know if you have any further questions about this initiative.

By the way, if you’re interested, you can see a mini-history of the UA Home Page at http://www.ua.edu/aboutsite.html.  Enjoy!

This is a quick tip for all those Dreamweaver users out there.  If you don’t already know, you can preview your local pages in a browser by opening an HTML file and hitting F12.

Well, I always thought the file had to be open…until today.

If you want to preview a file without opening it, simply click on the file and hit F12.  That’s it!

Hopefully this quick tip will shave minutes of unnecessary loading times off your life.

Charles and I have been emailing back and forth about the security of LDAP and my incorporation of LDAP authentication into WordPress makes this issue even more important.

My question is this:

Could a hacker sniffing UA network packets intercept the traffic between, say, the TCF Web server and the LDAP server? And could he/she thereby discover userIDs and passwords?

What I worry about is that in LDAP authentication it appears to me that the userID and password are traveling across the network in plaintext — not hashed or encrypted. Is that right?

Perhaps I just don’t understand how the authetication works!

Thanks for any enlightenment.

I was about to leave another comment on Charles’ useful post about his LDAP script, but then I figured that this is a different enough topic to warrant its own post — even though inspired by Charles’ LDAP enthusiasm.

I’ve just been experimenting with using LDAP to authenticate users on my WordPress sites and, I tell you, it is a beautiful thing. With the addition of one plug-in and a few simple configuration settings, I can now let UA’s LDAP server handle all the authentication chores for my sites! This includes the creation of new site users!

This is a huge step for my department as it allows faculty and students to log into our WordPress Website with their Bama userID and password! So much more convenient for the users!

And it makes my job easier as an administrator because I don’t have to manually create accounts and I can pass off password management to the Bama system.

With so many WordPress installations on campus, I thought the details of my installation might be of interest. Before you experiment with this, make sure that your installation of PHP includes LDAP support, which is not compiled into PHP  by default!

When I first tried this out, I came close to disabling login for my site because PHP was not ready to do LDAP authentication!

So, of course, you must back-up your system before trying this and I would recommend against trying it on a production system before you experiment on a less critical machine.

Here’s what I did:

1. Installed/activated the Simple LDAP Login WordPress plugin (version 1.3.0.3).
2. Under Settings -> Simple LDAP Login, I did the following configuration:
   1. LDAP Directory: this defaults to “Active Directory” and must be changed to “OpenLDAP (BETA, may support other LDAP directories)”.
   2. Account suffix: @ua.edu
   3. Base DN: ou=people,dc=ua,dc=edu
   4. Domain Controller(s): ldap.ua.edu
3. Be sure to click the “Update Options” button to set this configuration when you’re done.

Additionally, you’ll need to decide how Simple LDAP Login will or will not create new WordPress users on your system. The choices are:

• Authenticate WordPress users against LDAP. I will create the accounts in wordpress myself. (default)
• Create WordPress account for anyone who successfully authenticates against LDAP.
• Create WordPress account for users in specified AD group.

For now, I’m sticking with the default and manually creating accounts, but I’m going to experiment with automatic account creation soon.

I’ll be interested to hear what others think of using LDAP authentication with WordPress. Add a comment to this post if you use it!

I’m sure you’re all familiar with the A-Z Site Index on UA Home (http://www.ua.edu/site.html), which contains an alphabetical listing of UA web sites.  This list is intended to be a semi-comprehensive listing of all major web sites on the UA campus, in order to help guide visitors to the information they’re seeking.  It has historically been one of the most heavily-visited pages on UA.edu, and continues to play an important role in helping the Home Page direct visitors to the information they seek.  So we certainly all benefit from it being as accurate and complete as possible.

As part of a bigger project, I’ve been cleaning up the A-Z Site Index and other pages on UA Home to be more accurate and complete.  Because sites get redesigned frequently all over campus, links and resources change pretty frequently, so it’s a challenge to keep these links up-to-date and inclusive of all that needs to be there.  Many webmasters on campus already do this, but I’m reaching out via this blog to campus webmasters to help me keep it up-to-date.  If you redesign a site or implement a new site architecture that changes the URL’s of important pages on your site that might be linked from the Home Page, please let us know. 

Also, if you implement new, important resources on your sites, or you find that your site isn’t listed where you feel it should be, please let us know and we’ll add it to the Site Index and position it elsewhere where appropriate.  And if you have time to review the A-Z Index to make sure your important assets are included, that’d be great too.

Thanks so much for your help!

How to notify us:

• Send an email to webmaster@ur.ua.edu with the title of the page, the old URL (if applicable), and the new URL.

It sounds silly to welcome someone to the team who has in fact been a part of it longer than yourself, but no matter. I’d like to announce the permanent addition of Lisa Sandy to the Office of Web Communications, and welcome her to the team. Lisa has served as a student and part-time worker with WebComm for almost five years, and she has certainly paid her dues by performing a hodge-podge of design, maintenance, content and development tasks for us over the years. She is a talented graphic artist and a good designer, not to mention a tireless worker and a very nice person, so we are THRILLED to have her on board. As a web communications specialist, she’ll continue to perform a variety of duties, with a heavy focus on design and site maintenance. And she’ll become a regular contributor to the WebTide community as well, as she has much to offer to these discussions.

So, welcome to the team, to our longest-tenured veteran! We’re thrilled to have you with us full-time, Lisa.

This post grows out of a brief email conversation between Andy and myself regarding the CMS service models on campus. During our conversation, Andy asked me to share some of our experiences in Arts & Sciences as they relate to CMS selection support, policies and so on – so I am delighted to extend our dialog online to share with the WebTide community.

When it comes to web application support (CMS, etc.), we are currently developing policies in Arts and Sciences for a 3 tier support system:

Primary Supported (WordPress, phpbb, 1 or 2 other high-level web applications)

• Installation support
• Maintenance support
• Automated security updates
• Office training
• Documentation, etc.
• *Only tier available to Content Managers

Secondary Support (around 20-30 commonly used web applications that can be distributed via the automated account mechanisms in most current-generation web management environments such as Plesk and Cpanel)

• Installation support
• Automated security updates
• Users are responsible for internal maintenance

Tertiary Support

• Users may have custom, 3rd party applications not covered by Primary and Secondary tiers, but are bound by the College’s web services policies to keep them up to date with security releases, etc.
• Yearly security audits are performed.

Our goal was to create a system of policies that reflected the heterogeneous nature of needs and realities within the College while providing a uniform mechanism for support that doesn’t raise the need for lone-wolf scenarios (that are almost impossible to support en masse). I would imagine any significant campus-wide discussion would have similar hurdles to negotiate.

It is also worth noting that the heart of what makes this service model work is the availability of instantly-installable applications via a server-based framework such as Cpanel or Plesk. All that is necessary, however, is to have an automated mechanism to generate accounts, applications, maintain them, and keep all resources up to date. Otherwise scalability becomes an issue very quickly.

*We distinguish between ‘Webmasters’ and ‘Content Managers’ – many departments (most?) may never have experienced personnel capable of being webmasters. Departments who only have content managers are automatically ‘primary supported’ – only in instances where we have identified qualified webmasters do we enter into the options of the secondary and tertiary support levels.

If you’re setting out to learn how to use CSS (Cascading Style Sheets), the first step may not be learning the language but learning where to put the language. It turns out there are 3 ways to apply CSS to your HTML.

Note: With tools like jQuery and old-fashioned JavaScript, some might say there are more than 3 ways to apply CSS, but this article is about the 3 basic ways that will suit most purposes.

It doesn’t matter which order you learn these in but for this article we’ll go from the specific to the general. We’ll start with inline, then move to internal, then finish with external.

Inline

We start with the inline method of CSS placement. Inline style declarations allow us to define styles at the exact point we need them. For example, if we want to make a headline show up as large, bold, crimson text, we will find that headline in our HTML and add the CSS where the headline appears in the markup. Here is an example of what this inline CSS declaration would look like:

<h1 style="font-size:2.5em;font-weight:bold;color:#990000;">Sample
Headline</h1>

<p>This is a paragraph that has no inline styles applied to it.</p>

What you see in the code example above is mostly HTML, but it has some CSS essentially dropped right in the middle of it. We have specified that our h1 heading should have a font-size of 2.5 em (fairly large), a font-weight of bold (the CSS way of saying it should be boldfaced) and a color of #990000 (the hexadecimal, web-safe code for crimson).

We’ve also included a paragraph below the headline in our example, but we haven’t added any inline styles to it. With inline style declarations, we only affect the elements that we choose to style.

Now, if this was the only way to apply CSS, you might wonder just how useful this technology is. After all, it would be pretty tedious to have to add these kinds of statements to every piece of content you want to style throughout a website.

That’s where the other 2 methods of CSS placement come in so let’s move on.

Internal

Let’s say we want all our h1 headings and paragraphs on one particular web page to have a certain size, color and maybe a certain line-height (space between lines). One way to do this would be to include internal styles on the page rather than inline.

With internal placement of CSS, we will make our style rules in the HEAD section of the HTML. By using this method, the style declarations we make will affect only content on this page.

The basic syntax for writing internal CSS is to enclose these style declarations in style tags, so we add the following lines inside the HEAD section of our page:

<style>
h1 {font-size:1.5em; color:#990000;}
p {font-size:.9em; line-height:140%;color:#000000;}
</style>

This code sets the style on all p elements and all h1 elements within this particular web page. Keep in mind that there are ways to override those styles on certain paragraphs. One way to do that would be to put an inline style on a certain paragraph that sets its color to gray instead of black. Another would be to add more rules that would affect certain paragraphs using classes and IDs.

In case you’re wondering, technically you could put your internal CSS declarations in the BODY of the HTML rather than the HEAD, but placing the CSS in the HEAD is better for organization and performance and is definitely the way to go.

External

The 3rd method for applying CSS to your HTML is to put your CSS in an external file (call it something like style.css) and then link to that CSS in your HTML file. The great thing about this method is that you can have 1000 pages (or more) in a website and have every one of them link to that stylesheet. This means you can make changes to that one CSS file and have the changes apply across all 1000 pages of your site.

There are basically 2 steps to this method, building the CSS file and then linking to the CSS file in your HTML. We won’t cover making the CSS file in this post, so let’s just assume we have a CSS file called style.css that lives in the same directory on our server as the HTML file we want to apply it to.

All we have to do is type the following in the HEAD of our HTML document:

	<link rel="stylesheet" href="style.css" media="screen" />

As long as you have a stylesheet called style.css then any HTML file that includes that link in its HEAD will have the rules from style.css applied to it. This is generally how you would go about setting styles that control the appearance of a whole website in one place, the external CSS file.

Note: The href part of the link above has to correctly link to style.css, so if you are linking from a different directory you will have to use relative or absolute linking to navigate the path to style.css.

When to use which

You might wonder why there are 3 ways to apply CSS to your HTML, but once you start doing this stuff on your own website, you’ll quickly realize that all 3 methods are useful depending on the situation.

For example, most well-done CSS websites with more than about 2 pages employ an external CSS file to define most styles for the site. You can think of these as the default styles for all pages.

Now suppose there is one page where you want all styles to be the same as the rest of the site but with bigger paragraph text, or different colored headlines. You can use internal placement to define those different styles in the HEAD section of that page only and override the styles in your external CSS file. But, there’s a catch. If you want to override the external CSS with internal declarations, you’ll need to place the internal style tags and declarations after the link to the external style sheet.

Internal styles do not necessarily override external styles. If your internal styles come before the external CSS link, the external will overwrite the internal.

On the other hand, when we’re talking about overriding external or internal CSS with inline styles, things are a little more clearcut. Inline styles do override internal or external CSS. This means you can use inline styles if you have something that you just want to do for one specific element on one page without writing a rule that affects anything else.

It’s probably best to use inline styles sparingly. One of the main advantages of CSS is to separate the presentation, or look, of your website from the content of the site. External stylesheets and, to some extent, internal rules in the HEAD of a page, facilitate this separation. Inline styles mix presentation and content, and doing this too often can leave you with a site that’s difficult to maintain when you start making changes to the look with CSS.

If you are just getting started with CSS, here are a couple of good introductions (one video / one article) that cover a lot more than the one topic I’ve discussed above:

• HTML and CSS – The VERY Basics (Video by Chris Coyier on CSS-Tricks)
• Starting with HTML and CSS (from the W3C website)

I recently received the below message from Nicholas A. Kraft, an assistant professor in the department of computer science at UA.  I share it here to add to the ongoing discussion of CMS options and to document another success story of an open-source CMS implementation at UA:

Hi Andy,

I just happened across the WebTide post about content management systems and wanted to know what the current status of this endeavor is. I see from the thread that there was little to no support for Plone — just FYI (seeing as how I’m several months late to the party), this is the CMS I chose after performing my own recent evaluation. I chose Plone for several reasons, although a big one is that it is a python system and I would like to hire my undergrads to work on it (we now teach python in our introductory programming sequence). The WebLion group at Penn State has a ton of useful information about getting Plone configured. Tying authentication to my LDAP server was painless, and I am able to configure all Plone user capabilities/permissions from within Plone. In all, I added only three non-default packages (one for delegating auth to the web server, one for captchas, and one for my theme). I was also able to get it themed in reasonably little time. My site now reasonably approximates the departmental template that your group provides (by the way, thanks much for providing these). Feel free to check it out:

http://reu.cs.ua.edu/

Best,
Nick

–

Nicholas A. Kraft, Ph.D.
Assistant Professor
Department of Computer Science
The University of Alabama

More on Plone: 

• Plone CMS
• WebLion at Penn State