...more recent posts
Parsley looks like a nice javascript form validation library.
Seems like Safari under iOS strips out most EXIF data when uploading photos. I guess I can see why they do this but it is a real bummer for me.
Posthaven is a soon to launch blogging platform from two co-founders of Posterous (which was acquired by Twitter in 2012 but is now being shut down). We have no details about the platform, other than it being a for pay hosting model ($5/month to start), with no ads, and a "pledge" to keep it running, and keep your blog's URL permanent, "forever".
How will they do it? They can't say, exactly, but I like the idea in general. If people want to own their data, have easy exportability, not have ads inserted into their pages, etc..., they probably need to pay for the service. Not exactly rocket science. We'll see how the details shake out. But clearly this is the general direction from which to attack FaceBook and Twitter and others who give you the platform for free in exchange for a fairly significant loss of freedom.
I'll write more about it soon, but there is a new image upload system for this site. Assuming you have upload privileges, you can access it here:
/upload2/
Unlike before, this will resize your photos for you. I'm doing this to make it easier, but also to get the full resolution images onto the website (when I resize them I save the originals into a subfolder.) Because screen resolutions are increasing dramatically - on mobile devices and on retina display MacBooks - we will want higher resolution images one day (soon). So now we will start saving them so we can be ready. The downside here is that uploading a 4MB images takes a lot longer.
Unlike before you can now upload multiple photos at once. This is assuming your browser supports it. On the Mac just command-click on as many files as you want in the file browser window instead of just clicking a single file like you used to do. On Windows it's probably a right click. This works from iOS too (where not having to resize before upload makes posting from there possible.)
And finally, unlike before, when the upload is done you get a page showing thumbnails of what has been uploaded, followed by a textarea posting box that is already populated with the code for posting the images you just uploaded. Select the page you want to post to from the drop down menu. Add text or rearrange photo order as you see fit. Then click post and you'll be taken to the page where the post was made.
I'd love feedback on this. It's still rough. No layout or styling has happened yet. But it looks like it is functional.
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.