...more recent posts
I rely heavily on jQuery, which is basically a layer on top of javascript that makes writing javascript easier as well as more consistent across browsers. One of the best things about it is the large developer community that makes their own little "widget" type modules available for others to use. These are called plugins. Need a photo gallery? Calendar? Form validator? Someone has already coded one, and hopefully the community has helped the best rise to the top for your choosing. I follow a ton of blogs for the sole purpose of keeping up on new plugins, and there are literally dozens of new ones released every day. Well, now there is a central repository: jQuery Plugin Registry. This should be very useful.
I've mentioned some changes in my work world involving a move from building only back end (or server side) software, to a more all around role involving code both on the server (for me mostly PHP + MySQL) as well as on the client. For the client side stuff we're talking, loosely, about HTML5 which involves layout "code" (HTML + CSS) as well as actual javascript code (for me always using jQuery.) Plus, once you've gone that far you are already into the graphic design realm - so although I still like to work with an actual designer when a job makes it possible, I'm trying to come up to speed there as well and thus be able to do it all.
I feel this is a trend in the industry, driven at least in part by price concerns. If I can do the whole project myself I can either charge less or make more. The other benefit is that by doing everything myself there is no development delay often inherent in going back and forth between team members.
And I'm not the only one noticing this. Nathan Bashaw's blog post, Designer Eats Engineer, outlines his view of what seems to me to be the same progression, but from the opposite direction. Monday By Noon (where I found the link to this post) sums it up:
This is a nice overarching view of our industry’s landscape. Lots of trends are leading towards people doing more of everything and less of one thing. That seems to be a result of so much of the stack relying so heavily on multiple parts that you need to take time to research each bit. That leads to more intrigue and more time spent researching additional pieces you weren’t familiar with. There was a time when being a Jack of all trades meant you were a master of none. Perhaps that time is long gone around here.
I'm not a graphic designer, but I'm trying to learn enough to get by. Luckily there are tons of great designers out there who like to share their knowledge. Like: Design tip: never use black. Is this correct? I don't know. But the argument makes sense to me. And I use black all the time. I guess I'll try to change my ways and see what happens.
Image Picker is a jQuery plugin that transforms a select element into an interface for visually selecting images.
Web fonts are something that is undergoing explosive change. A couple of years ago you basically had no choice. You had to use a font which would be installed on all computers by default, and the set of such fonts was extremely small (Helvetica, Georgia, Arial, Times, ect...) These days, with some caveats, it's possible to load fonts along with your page, freeing the designer to use specimens that are not already installed on the browser's computer.
The now standard (but not necessarily without peril across browsers and platforms) @font-face CSS rule allows anyone to embed their own fonts into web pages. Paul Irish has an in depth look at the issues and offers a bunch of work arounds for common problems. But beyond even these technical issues (due mostly to browser differences) there is the issue of most high quality fonts aren't licensed for use like this. (i.e., just because you own a bunch of great adobe fonts doesn't mean you are allowed to embed them in web sites you make.)
Typekit is an Adobe web service that allows you to choose from a huge selection of fonts. Fonts are downloaded to the browser from the Typekit servers. It's not free, but it's reasonably cheap ($50 - $100 per year depending on usage), and the quality is very high. And you don't have to worry about licensing issues.
Google Web Fonts is a similar service. The quality is probably not as high (there are lots of fonts in the collection without bold and italic versions, plus lots of just bad fonts since anyone can contribute to the collection), but it's free, and the fonts are all legal to use. I used GWF on the Louis/Dressner site (metrophobic for most of the text.) Some people have collected what they consider just the "good" Google web fonts so you don't have to wade through all the chaff in Google's directory. For instance: Better Google Web Fonts.
Some type foundries have free downloadable fonts. Prime, from Font Fabric, is one I want to remember for an upcoming project.
There are issues, but I think it's usable. And it's great to see some variation in fonts on the web.
Still, if you want to stick with the old way (using only fonts already available on the browser's computer), there well may be a bit more variation in what is possible then what is commonly assumed. CSS Font Stack is a nice collection of font stacks that should be reasonably safe to use. (We say "stack" because you can specify several different fonts for each use, and any particular browser will try to use the first specified, but if it isn't installed on the computer it will try the next font specified, and then the next.)
Obviously I haven't been blogging here in quite some time. I think that is going to change, and the changes I've gone through professionally, which I think largely mirror trends in the industry in general, should become clear.
I used to be proficient on the "server side" of the web equation (hence the blog title), meaning I mostly focused on the server: linux admin, Apache, MySQL, PHP (plus email, dns, and everything else that happens on the server.) I still do all that, but things don't change very much or very quickly inside that technology stack. The other side of the equation is the stuff that happens on the client side (i.e., in the browser.) Way back in the day this didn't matter much. The web browser just rendered the HTML encoded web pages that you sent it. Javascript existed, but you couldn't really count on any particular client having it enabled. But times have changed.
Nowadays, for most websites, a ton of stuff happens in the browser. Instead of just sending already baked HTML to the browser for it to render into a web page, you send it some HTML, along with programming code which is then executed in the browser in order to complete the HTML page. The programming code is written in javascript, which all browsers can execute, and which you can count on clients not having turned off (since so little of the web would work if you tried to surf without javascript enabled.) This results in the kind of interactive web pages we have all become accustomed to. You can click on interface elements on a page, and things happen (menus open, new content is fetched from distant servers, slide shows launch, etc...) without having to reload the whole page from the server. Going from a web of static pages to a web of dynamic interactive pages is largely the result of moving code from the server side to the client side of the equation. Web sites become less like "pages" of content and more like traditional desktop "applications".
HTML5 is a not very strictly defined term used to cover a lot of this new(-ish) technology. It means not only the latest version of the HTML standard (the latest HTML tags you can use to mark up the content of your pages thus creating the visual layout,) but also CSS for styling (fonts, colors, etc., and increasingly animations,) and javascript. HTML5 is sort of the catchall term for the technologies underlying this transition from static web pages to dynamic web apps. (Yeah, of course, this is a quick post and not completely accurate, but hopefully gets the general flavor.)
In any case, if I succeed in starting up the blog again, most of the posts are going to be about the client side. Especially Jquery which is (again, not completely accurate, but for our purposes...) a dialect of javascript that makes it easy to write javascript code that works the same in all browsers. I doubt this will all be very interesting. Mainly it will just be a place for me to put links which I think I might need at a later time. But occasionally I'll try to say something more high level about the state of the web and possible futures I see.
TideSDK looks incredible: "Create multi-platform desktop apps
with HTML5, CSS3 and JavaScript" (and PHP, Python, or Ruby.) Can't wait to dig into this.
Could have used this years ago, but at least I know about it now: mod_xsendfile
mod_xsendfile is a small Apache2 module that processes X-SENDFILE headers registered by the original output handler.
If it encounters the presence of such header it will discard all output and send the file specified by that header instead using Apache internals including all optimizations like caching-headers and sendfile or mmap if configured.
It is useful for processing script-output of e.g. php, perl or any cgi.
HTML email boilerplate. Should probably incorporate this.
Maybe I should change the name of this blog to WOW and then start every post with wow.
Wow. HTML5 bookmarkable infinite scroll example. Infinite scroll itself is cool, although it's not terribly new - basically instead of forward and back buttons (or previous and next) to page through content (like a blog), infinite scroll just loads new content in the background using asynchronous calls to the server as you scroll. So, for instance, as you get close to the bottom of the page some javascript calls the server, asks for more posts, and then they magically appear so you can keep scrolling. This way you can read a whole blog on one page, but you don't have to load the whole thing in at once (and you don't have to load a ton of content yo don't need in the case that you don't scroll all the way back which would probably be the usual case).
The cool thing in the example here is the use of the HTML5 History API - specifically replaceState - so that the URL changes as you scroll, thus making any point on the infinite page bookmarkable.