I went to the ACRL tech interest group-sponsored workshop on Content Management Systems (held at College of the Holy Cross in Worcester, MA) on Friday. Three academic institutions' implementations of content management systems were featured as "case studies" for all of us interested in possibly pursuing content management systems. There were a number of interesting notes, the most important giving me confirmation of what I knew & had been heading toward with our site:
- often, you need to standardize your site's code before converting to a CMS, in order to effectively migrate; redesigns - the design work - is often done (using CSS) before the CMS is put into place
- you often start with a client-server type system, such as the use of the Macromedia Dreamweaver/Contribute Publishing System (or FrontPage with FrontPage Server Extensions) before moving into a CMS. The use of such as system does familiarize your users with key web authoring concepts, though these systems allow the authors a lot of freedom that the move to a CMS will eliminate. So there will be power users who - when moved to a CMS - may feel too constrained by the new system.
A few other things that the seminar made me think about were:
(a) the need to get that user input/needs analysis done on the authoring side - realizing that you have levels of contributors / authors / editors and levels of technical skills that correspond. Your CMS has to meet the needs of all levels of content creators on the back-end, as well as meeting the end-user (consumer)'s needs on the front-end.
(b) Web2.0 - nowhere was Web2.0 really strongly enabled by these CMS. The two large CMS, which cost in the 40K-100K range, were designed for the enterprise-level work that they did - but they didn't seem to offer a lot of modularity. Where would you integrate a wiki or a blog? If you have to add these on to an already resource-intensive, often expensive system - is one large system like an enterprise-level CMS really a good answer for an institution like our own? I'm not saying yes or no here, of course, I'm just asking the question.
I thought it was very interesting to learn about how the two larger academics who presented handled their web presence - in one case, the web presence workers had moved out from under Communications/Marketing into IT (still having a strong relationship with their Communications dept., however); in one other case, the web office was under the Marketing department directly, which ran the CMS. In the latter case, a key need for the CMS seemed to be the ability for Marketing to control all aspects of the publicly accessible web presence of the institution (hence, they administered the CMS, approving items to be publishing, authorizing users, etc.).
The final presentation was from a slightly smaller academic using the Macromedia Contribute Publishing system. They were more heavily focused on furthering the students' education through the web (e.g., facilitating the use of web-based portfolios) than on the marketing end of things.
There are likely other points I'll post in a bit, but for now, I wanted to give you my first set of CMS presentation impressions.
Monday, February 12, 2007
NELINET CSS Workshop: What I learned today
(1) About the box model: the "box model" in CSS basically indicates that all elements in a page can be seen as being in a "box" - and attributes of that box can be altered for modified appearance - for more on the box model, see the W3C page on the matter - http://www.w3.org/TR/REC-CSS2/box.html
So you see - if you look at this page, that the elements of the box are (starting with the center/core & working our way out):
- content
-- padding
--- border
---- margin
(2) About the box model problem & "hacks": well, it turns out that the Microsoft folks - when programming IE5 - interpreted the box model differently than other browsers' programmers. In non-IE5 browsers, when the box is set for a certain width, it = the content's width & you add on the padding width, border width, and margin width for the total space taken up by the box element. In IE5, the width set for a given div, for example, includes not only the content, but also the padding, border, and margin. So, in IE5 (and "quirks mode" of IE6 and IE7, but that's another story for another time) - you might have a 250px wide box, for example, including a padding of 10 px and border of 5px (meaning that the content itself was really only 220px wide, add the padding on both sides (left & right, each 10 px = 20 px) and the borders on both sides (left & right, each 5 px = 10 px). The same CSS, interpreted in Firefox or other Mozilla browsers, would instead be 280 px wide: the content would be 250px wide, then the padding on each side would add 10 px (total 20 px both sides), and the borders on each side would add 5 px (10 px total both sides). Anyhow, that materially changes how a page looks, from browser to browser, a big problem in the case of fixed-column layouts, etc.
So, how do you fix the issue? There are several means of dealing with the issue - called "box model hacks". Mostly, they rely on other IE5 interpretation idiosyncrasies. A fairly famous hack relies on use of the "voice-family:" option in your stylesheets (no, I have no idea what voice-family was intended for) - anyhow, to see this hack (and to see a visual rep of the box model issue), go to http://tantek.com/CSS/Examples/boxmodelhack.html
The one that NELINET instructor Ed Sperr recommended, however, was the invocation of the conditional (if IE5) statement to import in an IE5-specific stylesheet. Although this might sound kind of kludgy - like back in the day, when we used to run little scripts to detect the version of browser you were using then to offer up specially coded versions of our pages to respect the html & script interpretation oddities of different browsers - but it keeps your primary (proper box model-compliant - in other words, friendly to Mozilla & IE6+ browsers) stylesheet clean. (no need for that voice-family "\" and reset functions, as in the first hack I gave you the link to - the Tantek hack). As I think about it, I'm beginning to like this concept - the use of the conditional statement and the alternate stylesheet to deal with the issue.
Anyhow, one more thing I learned about the box model today was that there is the whole "quirks mode" problem, wherein IE6+ will actually revert to the same broken box model implementation as IE5 if you do not include a DOCTYPE declaration at the top of your HTML/XHTML page. So, if your box model's misbehaving in IE6 or 7, double-check to make certain that you've got your DTD in place.
A couple of other helpful notes I got from today's session:
(1) if you're trying to use CSS to style list items to approximate the look of a highlighted button in a menu (i.e., area highlighted when you mouse over the area where a link is featured), you must make sure that your code is set to block type display. If you do this, you will get the hover effect throughout the content's box region, rather than just on the text of the link. Did that make sense? I don't have much time as I have a few more posts to make, but I hope that this makes sense to you.
(2) when you use "absolute positioning", you are taking a div out of the normal flow of the content, so it's very easy for it to overlap (which is why it was set up to do so, but be aware of this behavior). When you use "relative positioning", the div is in the flow of the document - and is in position relative to the containing element (e.g., if no higher-level containing element, then it is in position relative to the view port / browser window). The divs will flow one after the other, if positioned relatively, generally speaking.
(3) floats: floating elements means that the elements will float as far right or left (pending float: left; or float: right; can use float: none; to ensure that nothing floats, of course, as well) as they can before they bump up against the previous element. So you can float multiple boxes in the same direction. You can have your div 1 float: left; and div 2 can also float left. There are some oddities with floats, however. Just be aware of this -you may need to specify the height of your containing element when using floats, or to use an empty spacer div to stretch the container, or to clear the floats. The floats are a little flaky - so just note this. The other option is to use the overflow: auto; declaration with your floated elements. If I understand it correctly...
(4) yes, you can use a specialized stylesheet to reformat your docs to be printed, automatically, in a more printer-friendly format - hide display of navigation bars that would be meaningless in a printout - change the ems or pxs to pts for the font-sizes; change the font-family from sans serif to serif. And so on... See A List Apart for more information on this topic...
So you see - if you look at this page, that the elements of the box are (starting with the center/core & working our way out):
- content
-- padding
--- border
---- margin
(2) About the box model problem & "hacks": well, it turns out that the Microsoft folks - when programming IE5 - interpreted the box model differently than other browsers' programmers. In non-IE5 browsers, when the box is set for a certain width, it = the content's width & you add on the padding width, border width, and margin width for the total space taken up by the box element. In IE5, the width set for a given div, for example, includes not only the content, but also the padding, border, and margin. So, in IE5 (and "quirks mode" of IE6 and IE7, but that's another story for another time) - you might have a 250px wide box, for example, including a padding of 10 px and border of 5px (meaning that the content itself was really only 220px wide, add the padding on both sides (left & right, each 10 px = 20 px) and the borders on both sides (left & right, each 5 px = 10 px). The same CSS, interpreted in Firefox or other Mozilla browsers, would instead be 280 px wide: the content would be 250px wide, then the padding on each side would add 10 px (total 20 px both sides), and the borders on each side would add 5 px (10 px total both sides). Anyhow, that materially changes how a page looks, from browser to browser, a big problem in the case of fixed-column layouts, etc.
So, how do you fix the issue? There are several means of dealing with the issue - called "box model hacks". Mostly, they rely on other IE5 interpretation idiosyncrasies. A fairly famous hack relies on use of the "voice-family:" option in your stylesheets (no, I have no idea what voice-family was intended for) - anyhow, to see this hack (and to see a visual rep of the box model issue), go to http://tantek.com/CSS/Examples/boxmodelhack.html
The one that NELINET instructor Ed Sperr recommended, however, was the invocation of the conditional (if IE5) statement to import in an IE5-specific stylesheet. Although this might sound kind of kludgy - like back in the day, when we used to run little scripts to detect the version of browser you were using then to offer up specially coded versions of our pages to respect the html & script interpretation oddities of different browsers - but it keeps your primary (proper box model-compliant - in other words, friendly to Mozilla & IE6+ browsers) stylesheet clean. (no need for that voice-family "\" and reset functions, as in the first hack I gave you the link to - the Tantek hack). As I think about it, I'm beginning to like this concept - the use of the conditional statement and the alternate stylesheet to deal with the issue.
Anyhow, one more thing I learned about the box model today was that there is the whole "quirks mode" problem, wherein IE6+ will actually revert to the same broken box model implementation as IE5 if you do not include a DOCTYPE declaration at the top of your HTML/XHTML page. So, if your box model's misbehaving in IE6 or 7, double-check to make certain that you've got your DTD in place.
A couple of other helpful notes I got from today's session:
(1) if you're trying to use CSS to style list items to approximate the look of a highlighted button in a menu (i.e., area highlighted when you mouse over the area where a link is featured), you must make sure that your code is set to block type display. If you do this, you will get the hover effect throughout the content's box region, rather than just on the text of the link. Did that make sense? I don't have much time as I have a few more posts to make, but I hope that this makes sense to you.
(2) when you use "absolute positioning", you are taking a div out of the normal flow of the content, so it's very easy for it to overlap (which is why it was set up to do so, but be aware of this behavior). When you use "relative positioning", the div is in the flow of the document - and is in position relative to the containing element (e.g., if no higher-level containing element, then it is in position relative to the view port / browser window). The divs will flow one after the other, if positioned relatively, generally speaking.
(3) floats: floating elements means that the elements will float as far right or left (pending float: left; or float: right; can use float: none; to ensure that nothing floats, of course, as well) as they can before they bump up against the previous element. So you can float multiple boxes in the same direction. You can have your div 1 float: left; and div 2 can also float left. There are some oddities with floats, however. Just be aware of this -you may need to specify the height of your containing element when using floats, or to use an empty spacer div to stretch the container, or to clear the floats. The floats are a little flaky - so just note this. The other option is to use the overflow: auto; declaration with your floated elements. If I understand it correctly...
(4) yes, you can use a specialized stylesheet to reformat your docs to be printed, automatically, in a more printer-friendly format - hide display of navigation bars that would be meaningless in a printout - change the ems or pxs to pts for the font-sizes; change the font-family from sans serif to serif. And so on... See A List Apart for more information on this topic...
Why so many library webmasters haven't switched to CSS-based layout
One question I've heard from time to time is why some webmasters don't just ditch the table-based layout they've traditionally used and go with all CSS-based layout. This is particularly true of library web pages. I'm here at a NELINET Advanced CSS workshop and really understand why we haven't migrated.
(1) need to support even the oldest browsers;
(2) all of the knowledge and time needed to work around inconsistencies in the way various browsers implement CSS - particularly, in relation to the "box model"
I'll give you my synopsis of the "box model" issues in my next posting.
(1) need to support even the oldest browsers;
(2) all of the knowledge and time needed to work around inconsistencies in the way various browsers implement CSS - particularly, in relation to the "box model"
I'll give you my synopsis of the "box model" issues in my next posting.
Thursday, February 01, 2007
I think it's a good argument for why you not only can not block young people from joining online communities, but you probably should not (within certain parameters, of course). Since this is likely the wave of the future, it will be a required professional skill - a fluency with social networking sites. Anyhow, join LinkedIn soon & please - friend me!
I can be helpful, in fact. The director of CSL's Division of Library Development was putting together her most excellent blog on LSTA planning - http://lstaplan.wordpress.com and ran into a few questions today. In case perchance, you have the same questions, let me provide the answers here. On Wordpress.com blogs, if you want to create a sidebar widget that features links to other websites/blogs/wikis/whatever, you need to go into the Blogroll function & add links. Then you MUST add some category to them in order for them to show up.
As for myself - well, this week has brought a mix of ups and downs - the usual. It was a joy to speak to the state's Ed Tech Commission re: social networking sites & how libraries are using them. (Even though I felt a bit like a hypocrite given how little we at CSL are really doing to take advantage of the tech - compared to what we could be doing. But I feel a little better because our web committee is excellent & will move us forward. We've just scheduled a new librarian who spoke at NELA to come up & talk with us on Feb. 15th - all about Web2.0 & ways libraries are using the technology to further their missions. Just getting awareness out there will be helpful. Staff is so busy with their own subject area expertise, they haven't been able to keep up with all of the Web2.0 developments, let alone consider how they could deploy them. Yes, I mean there have been victories - I turned the New @ CSL into a blog & then created a script that draws in the RSS feed. And we got the William Webb Wordpress blog up. And there's been a little bit of movement. But movement seems quicker in one of our divisions when compared with the overall institution. I guess that's the challenge in a place like this...)
So, in the meantime, I've been working very hard on an extremely Web1.0 initiative that does very little for users & even for staff. And I'm beginning to question whether or not I should keep banging my head on the wall or to insist that we stop wasting precious resources (my time, for example) on getting something that's old school & not very helpful to very many people on this project. I'll feel bad for only having made about 75% of the project functional, but I'm beginning to think that it's worth cutting and running... I don't want to throw more good time after such wasted time... mixing my metaphors, eh? Anyhow, I have a million crucial things stacked up - but I'm only 1 human being. I do the best project mgt I can, but I cannot control the project demands of the folks around me. I'll have to take this one to the boss, I think.
Subscribe to:
Posts (Atom)