Cosmetic changes happen on a website throughout its lifetime. Some major, others so small they are sometimes unnoticeable. You may notice when you created a bulleted or numbered list using the LiveWhale tools, the indent has shifted a little to the right. This helps differentiate from the preceding paragraph content to let the user know that this is, indeed, a list.
Latest Updates: css RSS
Bulleted and Numbered List change
When was the last time you printed out a page on the website and ended up with a lot of content you didn’t need (like navigation links and footers)? Well, now we’ve rolled out a stylesheet that prints out the essential content. Of course, this doesn’t include links to files like PDFs or Microsoft documents.
Word of warning: depending on your browser, the results may not be what you expect. We’re still in testing mode but your feedback is appreciated.
SXSWi Report: One Application Codebase
While I love my iPhone as much as the next person — and perhaps even a bit more — the proliferation of smart phones, tablets, large displays, netbooks, laptops along with the old standby desktop has made developing an application able to serve many/all very expensive. Each device requires its own set of programming code in a language specific to that device.
Codebases are expensive.
Imagine this scenario, you want to build an application, say a new Source, which will of course be available as a website. But, we’d like to also display a similar view (technically) of campus news/events on the ten 42″ displays arriving on campus this summer, and what about having something available for tablets and smart phones? Creating a native application for major smart phones is three to four codebases alone.
With each new codebase, you will double the amount of time (at least) a single feature update to the application as whole takes — clearly not a great idea when you have a small staff, as we do. However, there is an alternative path developing. (It’s early, but right about the point where we can jump in and see benefits.)
You might have heard about HTML5 — dubbed the flash killer by some? Well, all flash versus HTML5 aside, HTML5 is simply the next revision of the standard structure that is used to create websites — nothing more or less. While HTML5 is not yet been finalized by the consortium writing it (and thus not fully supported by web browsers yet) some of it has already been implemented and gives us enough of a resource to begin using it.
The changes in HTML5 give us a great new toolset for developing robust applications that live in a web browser. If you’ve ever used Google Docs, GMail, or even OfficeLive, you’ve seen where we’re heading. The benefit here is that with the new features available to web/application developers, we can write an application in a single codebase and have it not only function, but be responsive to the device on which it runs.
This means that we can write one set of code that will work across all/many of the client devices which we choose and that gets us down to two codebases. Now, you’re asking yourself why two? I though we were down to one? Read on.
Server-side, client-side, what?
I’m going to get a little technical here, but promise to keep it sane. Stay with me.
This is the server-side.
Web servers are really just bigger versions of the computer that you tote around or that lives on your desk. Currently, the Lewis & Clark web servers run software that takes content stored in databases (like user information, news, events, etc.) and files on disk (like web pages) and depending on the location in the website, mashes these resources up to produce a webpage or structured data that is delivered to your web browser in under 1.5 seconds. I think that is pretty amazing. (Note: 1.5 seconds is our target minimum home page speed via broadband. Really, we like it to be under a half second.)
We use two primary languages on the web server to do this: PHP and Ruby on Rails. For instance, LiveWhale is written in PHP, the search engine is Rails. Both languages are open source and have been developed for a number of years. (I started coding in PHP a decade ago, when it was already not young.) This is the server-side.
This is the client-side.
- HTML is the structure — the content. If I were to anthropomorphize HTML, it is the part that says: “Here is a paragraph that says ‘Hello world.’ and after it, show a link to the home page at http://www.lclark.edu/”
- CSS, or cascading stylesheets, is the design or styling of the page. It says: “Make that paragraph text align to the left, and make the font Helvetica Neue, 18 point” among many other attributes, including many that tell the paragraph where to appear on the page.
But wait, there’s more!
What’s more, rather than sending a subset of code to the web browser just to handle select tasks as we do now, we could send the entire application code. The application could then run in your web browser and be more responsive to your needs, only communicating with the web server as needed and only for data. (Sending/receiving data costs less than a whole web page.)
This is faster and better for you, in that the application is more responsive, and faster and better for newmedia since changes are now less expensive.
So what, if it’s not ready.
Why can’t I style my text further?
Many people ask (and lots don’t) about using colored or styled text for web page content. We get this request from time to time and often turn it down, but many people don’t know why. There are three primary reasons.
First and foremost, on rare occasions we use a find/change routine to edit website content. This is not a frequent occurrence because we prefer to have content editors know why a change needs to occur, so when we do this, it is often an important change that we need complete quickly. However, even with sophisticated pattern matching, introductions of style characteristics out-of-the-norm greatly increase the likelihood that a find/change will fail to be complete.
Secondly, we frequently update the styles of the website on a global basis to add new styles and update existing styles as we add new website features. Local, “inline” styles always predominate anything we set at a global level, so when we update styles you may not see/get them or at the unlikely extreme, it will break your page.
Thirdly, a consistent appearance across the entire Lewis & Clark gives the site a degree of weight, gravitas if you will. For example, a visitor coming to a page on the site (having already been to several other pages), knows within a fraction of a second (and without reading a thing) that this page is “official”. While some student groups will undoubtedly be allowed more latitude, a Lewis & Clark organizational unit (division, office, department, program, etc.) would not be allowed as much.
There is one last consideration that can happen with and without custom styles (but does often happen with the use of custom styles). As an editor, you may be trying to bring attention to specific links, words, a phrase, etc. and limited use of styles can help. However, more is not better. In fact, it is quite worse. If you were to bold every other sentence, like I have here, notice how difficult it is to continue reading. Many people already don’t read online, overuse of styles will only make it more likely that your page will not be read at all, because it looks like too much work. Seriously. (This goes for CAPS too, which still carry the textual weight of yelling.)
I hope this helps. As with anything we do there are probably some exceptions and we’re always here to listen and entertain the possibility. Of course, feel free to bounce back about this reasoning with thoughts, concerns or questions. (Use the comments.)