Last week the new Bridgewater State College layout was unveiled. This has a lot of my work in it. The design of the layout was produced by a consulting firm the college hired to help develop the new layout.
Once we got a template that Institutional Communications (the new name for the Public Affairs dept) was happy with it was handed off to me to convert into something usable. IE/Mac users will not have a great experience (still working on that), but it should be good back to IE 5.0. There are lots of areas where I see improvements being made over the next year. Besides compatibility I see adding some extra style-switching bits to the left of the font-size/search bar at the top right such as picking what font to use for the base of the layout. I also see going through the CSS and trying to greatly compact it to cut down on the amount of data people have to download.
I’ve already started doing that with the images. Originally many of the “brand images” were 300-400k in size. I’ve cut a lot of that down to well under 100k per image. A lot of the second-level pages still need to be re-compressed and I’ll eventually get to them. Right now there’s still a lot of back-end coding to work on and that’s my primary focus for the next few weeks.
I was thinking about producing a version to post on my site for the world to use, but decided fairly quickly that would be a bad idea. It’s a design that is certainly wholly unique to BSC and it should probably stay that way for at least a little while.
We opened a demo version to people on-campus for a few weeks prior to going live. In that span of time we really haven’t had much in the way of negative feedback. The actually day we rolled it out into production we had virtually zero feedback. This, in my opinion, was a good sign. It’s rare that you’ll hear about the good things you do, but you’ll always hear (very loudly) about the bad things you do. The calm of the roll-out seems to indicate we’ve got a layout people like.
There are some things I don’t like, such as color and typographical choices in some parts of the web site, but I am not alone in creating nor maintaining this web site and so it can’t be only about what I think is best.
I still believe it’s not a bad idea to stay away from using Calibri in web sites (even though we use it for most of the headings). The size differences between Calibri and Arial mean people who don’t support Calibri will have a much different experience on your web site.
Well just wanted to post a note about that (it’s turned into a novel).
This is one more case for users to, by default, not enable Flash on their browser unless viewing a trusted web site. If we reach that day where such practice is common (and the more Flash vulns that get released, the closer we get) then web sites that rely on Flash will be UNUSABLE unless a user trusts the site. But how can the user learn that the site is trustworthy if they can’t even see it?
Stay away from designing your entire web site in Flash. You’re just setting yourself up for some seriously problems in a few years when web browser security finally gets taken seriously.
I would love to hear any feedback you have. Either here or via e-mail.
Found a fix for Netscape 6 not working with horizontal menus. Seems setting the height to 100% whenever an anchor inside an LI is hovered will get Netscape 6 to not hide the menu items as you mouse over them. Thus I’ve updated Ruthsarian Menus with the fix. It’s nothing big, but if you’re curious the fix can be found at the bottom of the stylesheet.
Downloaded iCab 4 and gave it a go. It looks to be a very solid browser. I ran it by the new Comic layout and everything worked great, including the dropdown menus. This shouldn’t be a surprise since it worked in iCab 3; I guess I’m just jaded from working with IE.
Allow me to direct you to BTreeHugger’s Blog, specifically his CSS category. You will find a ton of great information, but best of all is his maintaining of a CSS mastergrid where virtually all known CSS hacks are listed in a table against what browsers they work with. It’s an amazing resource that every CSS developer should have bookmarked.
And while taking a break from developing your CSS, might I suggest some great reading? The Gargoyles comic. It continues where the series left off and let me tell you that the story has really come on strong with the last couple issues (#7 & #8). The first few issues were a lot of reintroductions to make sure people knew who was who. Now we’re into meeting new clans and new enemies. And the writing is all done by Greg Weisman, the series co-creator. In his spare time Greg is also writing, story editing, and producing the new television series The Spectacular Spider-Man.
Pick it up today!
I’m not officially publishing this yet, but it’s pretty close to done and I figure anyone who keeps up with this blog should get a little something out of the deal.
So here it is, my latest creation: Comic.
The layout explains most of what the layout is about. But to put it briefly, this layout is about conserving horizontal space for content and not navigation. It’s also a showcase for style switching.
I realize the vertical toolbox on the right-side could just as easily be a horizontal piece perhaps placed above the layout at the very top of the page or under the masthead. I liked the idea of making it a vertical toolbar though for a couple reasons. One is it makes the layout feel almost like various popular graphics programs that have vertical toolboxes. The other is I get a sick pleasure in the irony of preaching vertical space conservation and then wasting about 2ems worth with that silly thing.
Getting the buttons to scale with the changing font size of the page was actually a bit tricky. Turns out most browsers set input buttons to a fixed text size that doesn’t scale as you scale the font-size of any of the button’s parent elements (e.g. the BODY). So you have to explicitly set
font-size:1em to input elements. Then it will scale.
The font selection buttons have different font sizes. So instead of saying “width:1.6em” for all three, each one has a different width scaled up or down, depending on the font size for that button, so they’ll all be the same rendered size. Check the CSS.
It’s surprisinglycompatible, even Mac/IE 5.0 works great with this layout. Netscape 6 doesn’t like horizontally centered dropdown menus so I’ll need to fix that, but it’s a ruthsarian menus issue not a comic issue.
No packaged download yet (although you’ll see there’s a spot to put a link to one as soon as I’m ready). But if you want to play around with it I’m sure most of you can figure out where the various bits are and how to download them.
So give it a go. Put it through its paces. Let me know what you think or what you experience.
Allow me to share with you this link to Web Usability a web site in Australia devoted to, well, web usability.
Anyways, I’ve been working on a redesign for Bridgewater State College and the roll-out happens two weeks from today. Of course I’ll be tweaking the hell out of it every day up until launch because… well nothing’s ever really finished when it comes to a web site, is it?
We started taking feedback on the design based on a preview that’s available to anyone browsing from on-campus. The topic of accessibility came up from one user’s comments with regards to screen readers and so I set about revisiting some concepts I had developed early on for the design when it comes to screen readers.
First thing’s first: “skip links” (skip to nav, skip to content) that are hidden with screen media only stylesheets DO NOT NECESSARILY WORK. As it turns out screen readers do.. amazingly… just that. They read the screen. So if your user has, say, IE 7 or Firefox rendering the page, those screen media elements are being applied and the skip links are hidden.
Specialty applications that browse websites for visually impaired users will probably pick these links up, but the point is not all screen readers will!
The result is to either show these links or make sure your site is easy to navigate for blind users. A simple test here is to just use the tab key and see in what order links are accessed.
Originally the layout I had designed was source-ordered. But after this simple tab-test I found that the navigation elements were the last thing to be accessed. This means a user with a screen reader and Firefox wouldn’t see the navigational elements of the website until they got to the very end. Not at all a good thing.
So I’ve removed the source ordering. And, honestly, doing that feels better from a semantic standpoint as well. Index before content – like books.
Yes, I could have used the TABINDEX property, but it just wouldn’t be feasible with how the template is used and how department managers update the web site.
Anyways, the point here is that source-ordered layouts might not be the most accessible thing in the world.
CSS-based drop-down menus are another problem. Try accessing your drop-down menu using just your tab key. YOU CAN’T! Unless your mouse is set to automatically position itself over a link you’ve selected using tab the link never enters the hover state and so all those :HOVER pseudoclass rules are ignored.
What about :FOCUS?
That works, for the first link. You tab over to the link and you see the drop-down menu. But as soon as you hit tab again to go to the first link in the sub-menu your menu disappears. Why? Because the link no longer has focus, a sub-menu link does. And, unlike with :HOVER, if you use :FOCUS on a block element and one of its children has focus, that parent block element, for whatever reason, is not considered to have focus.
This, I think, is a major flaw with current web browsers. If a child element has focus, so should its parent. Just like :HOVER. If this were how browsers worked then using :FOCUS would make CSS-based drop-down menus accessible for blind users with screen readers.
For now I have two options. Either display content in the drop-down menus outside of the menu or make sure each sub-menu option is accessible through the page its parent links to.