Why am I writing this post? Because if you have followed this blog for a while, you know I like not only passing what I’ve learned along to up and coming web developers, but I use this as a reference sometimes. I recently completed a freelance project that involved moving very large video files into a new WordPress install, and I came across multiple problems that were hard to find answers to. Adding video looks like it would be easy, right? Just click that little Upload/Insert button, drag/drop the file onto the page, and BAM! Video file is in the media library. What could POSSIBLY go wrong? I’ll start with the background to the project, and go over how I solved the issue.

Transfer a WordPress blog please!

It all started with an email from my website asking if I could transfer his WP blog from wordpress.com, to a self hosted WP install. The site’s main feature was the video clips on the site. If I couldn’t get the video over, then it was a no go. After some chatting, the client asked if I could honestly tell him if wordpress.com’s guided transfer was something he should look at, since it was cheaper than what I was charging. I told him that I have no idea, as I don’t know anyone that had paid for that. Blah, blah, blah….I got the job, and started transferring his blog over.

It always seems easy in the beginning

As it turns out, getting the data out of a WP.com hosted site is pretty damn easy. Under tools, they have a nifty little Export option, that will download an xml file for you. At that point, everything was going well. Wow, got the file, now how do I get it into a self hosted WP site? Simple, install the WordPress Importer plugin. It easily imports the data file into the new install! You click import, and then use the WordPress option. That is about as far as I got without any problems, because there is a checkbox asking if you want to import all of the media files attached to the data. Why the hell wouldn’t I want to do that? This seemed like a dream come true! I would be done with this little project in a couple of hours! So I checked the box and clicked import…

And the shit hit the fan.

What do you mean memory limit?

I kid you not, five seconds into the import and I got an error saying “Fatal error: Allowed memory size of …”. What? Google then tells me it is because the memory limit in the host’s php.ini file is set at 64Megs, all I have to do is ask my host to increase it. Soooo, I get the host (hostgator by the way – and they do indeed rock) to increase my limit temporarily after I explain what I was trying to do. THANK YOU! So they tell me, try again, which I do. Unfortunately this produces the same error. They then increase it to 300 and something for me, import again, and same error. At which point he asks me how large the video files are.

I didn’t really look, which was my fault. I did now though, and to my astonishment, the first file it is trying to import is a massive 687 megs. HOLY @#$%! That is huge. After a while, I realize this isn’t going to work. Quick thinking on my part, I say “Jeremy, why don’t we try using the file manager and upload them through the host itself?” Quick, yes. Stupid? Yes. I should have skipped this step, but don’t worry, I quickly found out why that was not going to work. Unfortunately it made me assume something that wasn’t true. The host’s file manager has a 500Mg single file limit, but I didn’t find that out until I had tried uploading the file though, which took about ten minutes.

Let’s look at a different approach

This is where I called the client and told him, this is probably not the best way to do video. Let’s look at hosting them on YouTube? WordPress has a very easy way of getting video from YouTube into a post. Looking into at first brought a smile to my face. YouTube’s limit for a single file is one gig. Awesome, none of the video is larger than that. Oh, but wait…how long are these videos minutes wise? See, YouTube limits it to 15 minutes. Some of these videos are over twenty. No good there, and after a brief conversation the client concludes that he doesn’t want to cut the videos up. Fine. Back to the drawing board.

Determination wins the day

At that point, I was up for trying anything. Enter FileZilla, which I should have done right from the start. I uploaded the videos into WordPress’ uploads folder, fully expecting it to die when it hit the 500 mark. To my astonishment though, it went through. All the way. Why? No idea. The host’s file manager has a limit, but using ftp didn’t. I was happy though because now I got the video up on the server.

I then login to WordPress, go to the media library, and….nothing is there. Shiznit. More searching with Google, and I find that there is a plugin called Add From Server. This little thing takes files you uploaded onto the server, and places them into the library for you. That was what I needed. I puts a nice little button in the Media tab that says Add From Server, and a list of all the files shows up when you click it. You then check all the boxes of the files you want in the library, and it moves them over for you. I was then free to insert them into the post at will!

Conclusion

Why was this so hard to figure out? Because apparently not many people have uploaded files this large into WordPress. I found tons on uploading 4Meg files, but nothing in the 500+ range. Google didn’t help me there. Large video files like that are not the best way of handling things, but I had to figure out how to do it. Doing that again would only take me a couple of hours total, but because I had never done it, and most others haven’t either made the process a bitch.

Wondering how the client got his files up on WP.com? Easy…he paid for an extension called Video Press that allows you to upload large video files into WordPress. Hell if I could find the same kind of thing though for a self hosted version.

So, if you need to do something like this follow this guideline:

• Import the WP data file with the WordPress Importer plugin
• Don’t transfer the media if you have large files like what I talked about. Won’t happen.
• Install the Add From Server Plugin
• Use FileZilla, or other ftp software to upload the video
• Use the Add From Server button in the Media tab to import the video into the Media Library
• Insert the video into the post

NOTE: If you use FileZilla, make sure you have the most up-to-date version. I originally tried with an older one I had installed and it truncated the files by a few thousand bytes or so. The files were then unusable. Once I updated FileZilla to the current version, this stopped happening.

Coupon Code: webmachine

I haven’t done anything on jQuery in a while, so I thought I would write about another simple photo gallery I had to write. Nothing complicated, and easy to add to or edit. I’m basically writing some jQuery to automatically write the large image source attribute, and the thumbnail’s CSS background property, then throwing in some simple effects. For those of you that are just learning jQuery, you will hopefully learn something and be able to modify this little script to suit your needs. So lets get started. Take a look at the demo first though, so you can see what is going on.

View Demo

Here is the HTML:

<div class="halfBlack"></div>
	<div id="container">
		<div id="newGalleryLarge">
			<div class="lrgImgContainer group1">
				<ul>
					<li class="close"></li>
					<li><img src="images/image-1-1b.jpg" /><p>This is image 1</p></li>
					<li><img src="images/image-1-1b.jpg" /><p>This is image 2</p></li>
					<li><img src="images/image-1-1b.jpg" /><p>This is image 3</p></li>
				</ul>
			</div>
			<div class="lrgImgContainer group2">
				<ul>
					<li class="close"></li>
					<li><img src="images/image-2-1b.jpg" /><p>This is image 1</p></li>
					<li><img src="images/image-2-1b.jpg" /><p>This is image 2</p></li>
					<li><img src="images/image-2-1b.jpg" /><p>This is image 3</p></li>
				</ul>
			</div>
			<div class="lrgImgContainer group3">
				<ul>
					<li class="close"></li>
					<li><img src="images/image-3-1b.jpg" /><p>This is image 1</p></li>
					<li><img src="images/image-3-1b.jpg" /><p>This is image 2</p></li>
					<li><img src="images/image-3-1b.jpg" /><p>This is image 3</p></li>
				</ul>
			</div>
			<div class="lrgImgContainer group4">
				<ul>
					<li class="close"></li>
					<li><img src="images/image-4-1b.jpg" /><p>This is image 1</p></li>
					<li><img src="images/image-4-1b.jpg" /><p>This is image 2</p></li>
					<li><img src="images/image-4-1b.jpg" /><p>This is image 3</p></li>
				</ul>
			</div>
		</div>
		<ul id="newGalleryThumbs">
			<li><a href="#"></a>Group 1</li>
			<li><a href="#"></a>Group 2</li>
			<li><a href="#"></a>Group 3</li>
			<li><a href="#"></a>Group 4</li>
		</ul>

Each thumbnail is a list item, and pertains to one of the groups above. Need another thumbnail and its corresponding gallery? Add a list item to the ul “newGalleryThumbs”, copy one of the image groups above it and change the number. Nothing too hard going on here.

Let’s get on to the jQuery…

$(function () {
	var $thumbs = $('#newGalleryThumbs a');
	var $thumbsContainer = $('#newGalleryThumbs');
	var $largeImages = $('#newGalleryLarge div');
 
	var a = 0, b = 0, c = 0, d = 0, e = 0, f = 0;	
 
	$thumbs.each(function() {
		a++;
		$(this).css('background', 'url(images/image-' + a + 'a.jpg)' + ' no-repeat left top');
	});
 
	$('.group1 img').each(function() {
		b++;
		$(this).attr('src', 'images/image-1-' + b + 'b.jpg');
	});
 
	$('.group2 img').each(function() {
		c++;
		$(this).attr('src', 'images/image-2-' + c + 'b.jpg');
	});
 
	$('.group3 img').each(function() {
		d++;
		$(this).attr('src', 'images/image-3-' + d + 'b.jpg');
	});
 
	$('.group4 img').each(function() {
		e++;
		$(this).attr('src', 'images/image-4-' + e + 'b.jpg');
	});
 
 
	$thumbsContainer.delegate("li", "click", function(e) {
		$('.halfBlack').show(500);
		$largeImages.eq($(this).index()).fadeIn(1000);
	});
 
	$('.halfBlack, .close').click(function(e) {
		$largeImages.fadeOut(1000);
		$('.halfBlack').hide(500);
	});
});

Two things to quickly note for you newbies, is that in the script above, I am using variable caching. I am not really sure it is actually caching, but it does store information so that it can be used again without jQuery making further calls to it. You will see that in the first few lines. Looks like this:

var $thumbs = $('#newGalleryThumbs a');

If you are going to be calling something more than once, store the crap in a variable. Got it? Good. The other thing to take note of, is that I am using ‘.delegate()’. Read the post I wrote about it and you’ll see why.

After the variables, you will see that I am using the each() method on the thumbs variable. This is looking at each ‘a’ tag in the unordered list (newGalleryThumbs) and writing the CSS for background on each of them in turn. It takes the variable ‘a’, which starts at 0, and increments it by one each time through the loop. I do a similar thing with the large image groups, only I’m writing the ‘src’ for the image rather than the CSS.

This all works because I am following a strict naming convention in this gallery. All of the thumbnails are going to be named: image-1a.jpg, image-2a.jpg, and so on. All of the large images, say in group 1 will be named image-1-1b.jpg, image-1-2b.jpg, and so on. By naming the images this way, I can use jQuery to write out the source values, and it makes adding more images later on very easy.

Next comes the click function on the thumbnails…

$thumbsContainer.delegate("li", "click", function(e) {
	$('.halfBlack').show(500);
	$largeImages.eq($(this).index()).fadeIn(1000);
});

When one of the thumbnails is clicked, a div with the class name ‘halfBlack’, which is initially hidden, is set to display: block. All that div is, is an empty div with a background image (an all black png set to 50% opacity). This creates the lightbox style effect. The next line says get one of the large image groups and show it. Which one exactly? The one whose index value is equal to the index value of the thumbnail that was clicked. If the first thumbnail is clicked, its index value is ’0′, and it then shows the div that has an index value of ’0′. Piece of cake!

Finally we have to get the large images to go away. I basically am treating this as a light box. Which it pretty much is, I guess. When either the close button or the black div is clicked, it fades out the images, and hides the black div.

I set myself a goal at the beginning of the year to learn Ruby by the end of it. Well, I finally started doing just that. Actually I’ve tried a couple of times, but didn’t get far into it. By starting with Rails this time, I am actually picking up things a lot quicker. I’ll give all the credit to Michael Hartl, who wrote the book Ruby On Rails 3 Tutorial, which is what I am using, and so far recommend. You can also visit the site here. This isn’t a book review, though I might do later on. This post is the beginning of many that I’m going to use to document my progress. You know, show you where I was being stupid, and the awesome “ah-HA!” moments.

The beginning is the hardest

I’m talking about setup here, not writing any code. There are a lot of things that I had to do before I could start typing anything that looked like Ruby. First came Rails. Installing Rails is actually the easiest part of it. I didn’t have any trouble there.

Then came Git. Had to download an install that, and there is a bunch of stuff you need to do to get that to work with github.com. Be it the key you have to type in, create a repository, then do a test app and add the files, followed by commiting them, then pushing them…went on and on it seemed, but I got Git up and running. Go me!

Next came Heroku. A place to store your newly created app and view it online. Where Git is the version control, heroku.com is like the host. But in order for that to function right, you have to create an app space. Oh ya, install the Heroku gem by the way. Once you have the app space created, you then have to hook it up with Git, so you can use Git to push your app to Heroku. Luckily there is pretty good documentation for this stuff, so if anything goes wrong, which it will, you aren’t dead in the water.

Of course that doesn’t exactly mean everything will go smoothly.

Rails’ Gemfile is cool

This is a file that Rails creates where you tell it what gems your app needs in order to work. I have had a little experience with gems before because of my use of Sass, and recently Haml. While going through this glorious book it tells you what gems to require, and how to add them. So simple in fact that I decided let’s add a few just to see if it really IS that easy. In went Sass, Haml, and Compass. Then of course, you must bundle all this crap together with the “bundle install” at the command line. Piece of cake!

That is until I tried getting everything in the tutorial to work with Heroku. You see, in the book it tells you to include this line:

gem 'sqlite3-ruby', 1.2.5', :require => 'sqlite3'

This gave me an error when I tried to push it to Heroku. Why? Easy! Heroku doesn’t support SQLite databases. FREAKIN’ awesome. I then spent a long time figuring this crap out until a friend sent me to Stack Overflow for the fix. The funny part was that I had already seen that article and I swear I tried the solution. Apparently not though, because putting this in my Gemfile instead, worked:

group :production, :staging do
  gem "pg"
end
 
group :development, :test do
  gem "sqlite3-ruby", "~> 1.3.0", :require => "sqlite3"
end

Everything then was handy dandy for a while. Until I added the Blueprint framework CSS and tried to push it to Heroku. Some error about the SCSS file not precompiled. Again I had to go and search Google’s pages to find the answer, which was to change a line to this:

config.assets.compile = true

I’m told testing is good!

Test-driven development is good according to this book. From what I know now, that is probably a good thing to get into the habit of. This led to installing rspec, which places files in Rails and lets your write test to see if things are working properly. Is the correct title showing up on the right page? Good. No? Fix it. Well, installing rspec was fine, but running my first test popped up an error about something or other. All I remember is having to install something called ANSICON v1.40. Can’t remember what it does, but that it was being asked for.

From rspec install, to first test, to installing ANSICON, to test again was probably about 40 minutes of time. Not terrible, but when you start adding all this stuff up and realize I haven’t actually done anything yet, you start to think that this isn’t as simple as you were hoping. Ruby might be an easy language to read, but getting all this crap going is a serious pain in the ass.

Actually learning something…priceless

At work I sometimes have to dive into the folder structure of Symfony, which is a framework for PHP. Never liked it. Finding crap was a pain because I could never remember where certain things were placed. Learning Rails though has cleared some things up a little. I now understand MVC a bit more. What the hell is MVC? Good question.

It stands for Model View Controller. The Model is what talks to the database. The Controller tells the View what to display and gives/takes things from the View to relate back to the Model. They really need to come out with a book for noobs explaining all the vocabulary in plain terms. Rails provides folders actually called: models, views, and controllers, so you actually get this stuff buried in your brain some.

I see the power of Haml more clearly

Within the folder structure you have a file that makes me think of “template”, called ‘application.html.erb.’ Which now that I just looked it up, apparently IS a templating system, just not as cool as Haml. You can go read my four part series on Haml at your leisure. One thing that really became apparent though is how perfect a fit Haml is with Rails. Rails seems to be about building things quickly and easy to read (due to Ruby), and Haml just adds to that. Now add in Sass? Holy F*$# this is getting exciting. I wish I didn’t feel so late to the party.

A good but difficult start

Well now, it looks like it is going to be a long trip. So far I feel like I have learned a lot, while at the same time having a voice in the back of my head telling me I’m not grasping all of it. Maybe it will take me a couple of passes through this book, who knows. What I do know is that I am having fun learning this, and that has kind of been missing for a little while. I need something to dig into, and Rails/Ruby seem to finally be it for me.

This is not a subject that the average front end developer is going to like unless you have been looking to get into a programming language. Most I know, have no desire to actually do that. A major barrier with Rails though, at least for the inexperienced, is the amount of time you spend using the command line and fixing problems just to get everything running smooth. So much depends on what version of whatever it is you are using, which can cause so many problems. If you add up all the time I spent just trying to get to the “Ok, NOW I can start writing crap” moment, most people would have given their computer the finger and said screw it. This is even more infuriating due to my book saying stupid crap like “If that doesn’t work, try using version 1.2.5. Beyond that use Google.” Ok, not that exactly, but really freaking close.

Anyway, I will write about my progress as I go along and learn or come upon. This is basically what I started this blog for almost two years ago. To show what I’ve learned and what bugged or created difficulty for me.

I have built plenty of websites for freelance, and I thought I had everything down. I know how to guide a client away from bad decisions, give advice that may go against what they want to do, get the information I need, and everything else that goes with starting a project. At least…I thought I did. I came across a problem with my latest project that I wasn’t really prepared for: building a site where the client wasn’t even sure what the whole idea was from the start. They knew what the basics were, but not the whole, and that is where I ran into trouble. It is because of this, that I learned how not to do things in the future. The most important being writing out the project’s scope.

Enter Closet Fish…

In the beginning…

The clients are two very cool women who work in the fashion world. Something that I know absolutely nothing about. Their concept was a voting site where the user pays to upload photos of outfit options and get professional advice from the owners of the site. While I got the information I needed from them, I realized that I couldn’t build this on my own. There was going to be a lot of back-end programming that was beyond me. Part of the learning process for me was the role of project manager. I have never really done that with more than the client and myself. I was going to need to involve other developers who knew some crap.

I ended up being pretty good at that. At least I think so. Anyway, I recruited a programmer I know, and he came up with a time frame and a dollar amount. I then went back to the client and told them the price. I have no idea if they shopped around, but I believe they did and realized more quickly than I did that we had completely underbid.

Colors, colors, colors

All I knew about what the client really wanted the site to look like was that it had to have pink. Not just any old pink, but freakin’ HOT pink. The kind that blinds you in its awfulness. It was something though, and I went with it. Hot pink is not easy to use in a design. In fact, you should never do it. I tried 2 designs, going through every color pallet I could think of that would make hot pink bearable. Even using hot pink as the accent color wasn’t working. I then said enough is enough. Hot pink is out. I then toned it down to a very soft and mellow pink and everything went much smoother.

I then called the clients and said “Hot pink is out. You will respect my authority in this matter.” Ok, I didn’t say that, but I was able to get them out of the hot pink mode, and they were happy with the colors once they saw it. One of the best things working with these particular clients was that they were very open to any ideas. If I gave them a good reason, they would listen and usually take my advice. There were a couple of times they did not, but they did when I thought it really mattered. I love them for that.

Logos are not easy

After designing the layout I added a temporary logo to show what it would look like. Nothing fancy, just a nice font with a gradient and some cute little bubbles floating around it. A very quick logo design, with barely any thought put in because I knew I wasn’t going to be using it. I then sent them the design, telling the clients that “Hey, this logo is just for placement, I am having one created for you.”

I then call a graphic designer friend of mine (ironic because my degree is IN graphic design) to come up with a logo. Why didn’t I do it? One, I didn’t want to spend time doing that when I could be writing the front-end, and two…he is better at it than I am. I knew he would do a good job. When I got the design back, I knew that I had made the right decision.

After replacing the logo on the mockup and resending it to them, I waited to here back. Which I did right away. “This is AWESOME! But…we think we like the other logo better,” came the reply. Not good because I was paying my friend to do this, and his logo was clearly better. Once the project all came together I think they are happy with me talking them in to using it. What do you think?

My 5 minute job:

Or his:

Things started to get crazy

After some time went by I start getting emails about other websites the client has seen. Can you add this? What if we do that? Lets make most of the site free where EVERYONE can give advice and then….Wait, what? After a few emails back and forth and a couple of calls, the scope of the project had changed. Looking back now, I realize a whole ton of crap I should have done.

First, I should have written a good old contract, but I didn’t because I dealt with this client before. I needed to have something down that said, here is the cost for what you have asked for. Anything further will have additional charges added, and the date for launch pushed further. But the programmer and I were yes men on this one, so we changed everything so that everyone could give advice, but you still had to pay for professional comments.

The second issue was photos. I generally pick the photos for a site I am doing. This time, because I had no idea about the fashion world, and because I thought they would want some specific things, I thought I would let them give me some options. Very VERY bad. on two counts. I didn’t specify that only certain photo groups could be picked from. Why did that matter? Because they started picking photos that were going to cost about $200 a pop….for web quality. Screw that!

Part B of this has to do with the website’s actual name. Closet Fish. Cool name once you understand what the site is doing and what people are doing on it. BUT, and this was a big head slapping moment when the emails came in with image selection. They were picking images that contained women and….take a guess! Got it? Freakin right! Images with women in lying in bed with a dead (though very fresh looking) fish lying on the pillow next to her. Images of mermaids, and marine scenes with fish swimming all over the place. After looking at a bunch of their choices, I made a quick phone call and told them to halt what they were doing.

See, it took a while for me to come around and start actually liking the name. The thing was, while it has the word fish in it, I felt the site shouldn’t have anything what so ever to do with actual fish. We are closet fishing for clothes here, and having people think of dead smelly fish is not a good way to get people to the site. Once I had them on the band wagon with that, image selection became easier.

Shit hits the fan

When the project was FINALLY coming down to the wire, we came to a round of testing. I called them up and said “You guys need to start getting people to come and test this website.” To which I get a reply, “Great idea! We’ll get some friends to do that!” A few days later I get an email saying things looked great, we just want this changed to that. No problem, cause you expect a ton of the micro changes crap. A couple of more days go by, and it is like 3 days before we said we were going to launch, and things went bad. “WHAT THE FUCK! WE CAN’T GET ANY IMAGES UPLOADED TO THE SITE! IT KEEPS GIVING US AN ERROR!”

To which I replied, “Don’t panic. THIS is why we wanted you to test the site.” After some thorough problem solving we found the issue. Rule number 4 of web development: NEVER rely on web developers alone to test your stuff for you. When we tested image upload, we were grabbing images from the internet…Google, Facebook, whatever we could find. It didn’t matter because it wasn’t going to stay up there. Any idea what the problem with that is? Real users are going to be using their camera or phone to take these images. Bigger problem? I’m guessing no one adjusts the image size of the images they are taking.

Question…WHY would you take an image with your phone that is 3000 pixels wide?? WHAT THE HELL are you going to do with that photo? Aren’t most photos taken thrown up on Facebook anyway? Well regardless of what I think people SHOULD do, they don’t. The problem was that each image was like 4 megs each. We were uploading photos that were like 200k each. The server had a built in limiter, and the image resizing script did as well. When they uploaded their images, server said nooooo way, and crashed. That got fixed and everyone was happy.

Now, I calmed them down, but I learned another very valuable lesson. I already know to expect things like that to happen at the last minute. The client that doesn’t know that though, will panic and start freaking out all the while calling you unprofessional.

I am now smarter for doing this project

Why? Well for one, this project was easily worth $15-$20k. I bid substantially lower because none of us knew what was going to be involved. A contract would have equaled this all out for us. This would have helped us more than them.

I really understand what project management is all about now because of Closet Fish, and I found that I really liked doing it. I found I was good at getting it all together, but learned a lot in the process. I think the biggest thing I learned though was the danger posed by a client who (while having a good idea) doesn’t have everything ironed out.

If a client comes to you and says “I have this great idea for a website. People come and do X,” you had better start asking questions about how they do X. What happens after they do X? Get all the details about how the site is going to function before you do anything. Then give them a quote for that work, and then let them know that anything else besides what you talked about, goes beyond the scope of the project. Which will cost more and set the deadline back. I saw this in action, and it is the one thing I do not want to repeat again in my career.

So what did we learn here? And by we I mean me

It basically comes down to these:

• No client is perfect, but these two were close
• Get ALL the details hammered out BEFORE you start working on a project
• Write up a contract, regardless if you worked with the client(s) before
• Anything beyond what was talked about for the quote will cost more, and push the deadline
• The people working on the site make horrible testers – they won’t use the site like a normal person would
• Explain to the client before hand that SOMETHING will go wrong…just don’t panic

All in all, I had a really good time working on this project. I think what made it so awesome to do was the fact that I got really lucky in who the clients were. They were open to suggestions, trusted my advice, and were extremely friendly and nice. I wish them all the luck with Closet Fish, and I really hope to work with them again sometime. It is rare to see the amount of drive these women have, and I hope you go check out their new website.

We need more of them. I only know of a few, but the ones that I do are pretty bad ass. Seems odd that the two I use were created by the same person, but if you have used Haml and Sass then you will see the connection and some of the thinking behind them.

Language abstractions make me think differently about the way I do things. Sass taught me to be a lot tighter in my CSS, and Haml showed me how you can write out an HTML page faster than lighting. In short, because of the these, I have improved as a web developer. For that alone they get my high praise and a check mark in the cool category.

Will I use Haml in the future?

Simple answer: yes. But I’ll go into the long one because this is my blog.

Even without knowing Ruby, I’m still going to use Haml. Just in the tests that I did myself I was able to breeze through an HTML page. Learning the syntax took less than twenty minutes. Haml did to HTML, what Sass did to CSS. It cut out the crap, and made coding out a page fast. I know you’re thinking that you can write out an HTML page quickly as it is. I can too. Haml just makes me faster than you now. By the time you have three divs with an id on them, I will have most of the layout written out, getting ready to add the content. I’m being totally serious when I say that. Even with having to open the command line to render it into HTML, I will blow you out of the water.

I use it in a bastardized way though. At least at the moment. I’ll create the layout in HAML, the content in Markdown, and when I’m done I’ll render it to HTML to modify that from there on out. That is not how it is supposed to be used, but it makes writing HTML so awesome I don’t care.

Should YOU use them?

Yes, because I think even knowing just one of these will help you. Writing something you think you know well in different way, makes you rethink how you were doing everything to begin with. In a good way, I promise. You’ll see the stupid mistakes you were making (and don’t even pretend you don’t make any) and how to slim it down or write it more efficiently.

I must warn you about something though. Learning Haml or Sass is like taking the red pill in the Matrix. Once you do, you can’t unlearn it. Why is that bad? Ask yourself if you like writing CSS. Did you answer yes like a good web developer? We all do, because it is cool to see what we are doing come to life on the web, or we wouldn’t be doing it. The problem I ran into is that once I really started using Sass on my freelance projects, writing CSS became a real pain in the ass.

At work, I write plain old CSS. You start writing out the styles and halfway through the stylesheet you start thinking how redundant a lot of it is. I am constantly thinking about how much clutter I could get rid of if had the use of variables, mixins, and nesting. Honestly, it is sometimes a real drag writing CSS now. That is the red pill for you. If you take the blue, CSS remains awesome. Take the red though…well, I warned you. And you won’t truly get what that means unless you try it.

So to stop my rambling on, yes, you most certainly should use them. You’ll learn something new, learn how to do the old better, and most likely save time by using them. Haml and Markdown will show you the speed, and if you combine it with Sass you’ll add the power.

Closing Arguments

If you were going to choose one language abstraction, I’ll be honest and say that I wouldn’t recommend Haml. You won’t learn as much. You will write up an HTML page very quickly, but in the end I don’t think you come away with much more than that. I would recommend Sass first. You learn a LOT about how you write your CSS, see a lot of the mistakes you make and how to correct them, and how to make your stylesheets tighter all around. Sass makes you think about what it is you are writing, where Haml is just a speed boost.

Articles in this series:

• Introduction to Haml For HTML Layouts for Newbs – Part 1: Installing Stasis
• Introduction to Haml For HTML Layouts for Newbs – Part 2: Writing Haml
• Introduction to Haml For HTML Layouts for Newbs – Part 3: Markdown Syntax For Content
• Introduction to Haml For HTML Layouts for Newbs – Part 4: Final thoughts

Coupon Code: webmachine

So obviously I really like Haml. Pretty sure that comes through in my writing. I’ve also stated that it is good for the layout/structure of your page, but what about the fluff of the page? You know, all the paraphraphs, lists and other crap the end user will actually read. Let me finally give you an example of why Haml is not the way to go for this.

#content
    %ul
        %li
            %a{:href=> "/index.html"} Home
        %li
            %a{:href=> "/services"} Services
        %li
            %a{:href=> "/about"} About

Keep in mind this is a very uncomplicated example, but I want you to note that each element has to be on its own line, which is a pain in the ass when dealing with content. There is a better way though, and that is where Markdown comes in (and use that link for reference later). Think of Markdown as a small syntax, within another syntax, used specifically to write plain text formatting and turn it into HTML. All you have to do is use Haml’s Markdown filter. How the hell do you do that? Easy, and I’m glad you were so thoughtful to ask. A simple colon, followed by the filter name. To write the same thing I wrote above using Markdown, you would write:

#content
    :markdown
        + [Home](/index.html)
        + [Services](/services)
        + [About](/about)

Much easier to read, wouldn’t you agree? If you want to see a really good example, go and check Chris Eppstein’s article and you will REALLY get the point. Which basically is that Haml isn’t really made for creating content because of how it must be written. Markdown though handles it very well. Seriously, check out that link and you will see what must be done to get a simple link within a paragraph tag.

Markdown’s basic syntax

Markdown isn’t going to pay attention to your indentation. It is better to give you a clear cut example though of the basics, because it is easier to see than to explain it.

#content
    :markdown
	#This is an h1 tag
	##This is an h2 tag
	###This is an h3 tag
 
	This is a paragraph
 
	<p class="highlight">You can also insert html</p>
 
	This is **strong**
 
	This is *italic*, and below is an image
        ![Alt text](/path/to/img.jpg)
 
        + List item
        + List item
        + List item

This will render in HTML as:

<div id='content'>
        <h1>This is an h1 tag</h1>
 
        <h2>This is an h2 tag</h2>
 
        <h3>This is an h3 tag</h3>
 
        <p>This is a paragraph</p>
 
        <p class="highlight">You can also insert html</p>
 
        <p>This is <strong>strong</strong></p>
 
        <p>This is <em>italic</em>, and below is an image
        <img src="/path/to/img.jpg" alt="Alt text" /></p>  
 
        <ul>
        <li>List item</li>
        <li>List item</li>
        <li>List item</li>
        </ul>
</div>

There are some things to note, as there always are when using something like this. First, as you can see in the Haml part, you are free to inject HTML within the Markdown filter. Yep, that’s right! Second, there are multiple ways to do certain things, such as the header tags which you can see marked with the ‘#’ in front of them. Here are two ways to do ‘h1′ and ‘h2′ tags in Markdown:

#This is an h1 tag in Markdown
 
This is also an h1 tag
================
 
##This is an h2 tag in Markdown
 
This is also an h2 tag
--------------------

Any number of equal signs or dashes will work underneath the headings, but the cool part is that there are different options to write the same thing. Bold and italic also have different options, but for my main example I used the ones I preferred. The heading tags just seem easier to remember if I use the correct number of ‘#’ in front of them. If you want to see all of the syntax used in Markdown, go to the site that I linked to above.

Wait, so I have to learn TWO different kinds of syntax?

Oh GOD with your complaining. No, feel free to use Haml for the content of your site. See if I give a crap. I guarantee after about five minutes you will be fed up. Also, it’s not like you are learning a coding language. Haml basics take about 20 minutes or less to learn, and once you have written some basic content in Markdown, you will understand it without much need to go look something up. It is that easy.

I can’t explain in words how fun it is to write a page out using Haml. You have to go and do it yourself to really get it. Once you do though, I’ll bet you will see how much better it is to write your layout in Haml. Using Markdown to write the content makes it even easier. Not only will you actually enjoy it, you will see how clean your web page can really be. Feel free to leave a comment thanking me after showing you the light.

Now go and do it!

Articles in this series:

• Introduction to Haml For HTML Layouts for Newbs – Part 1: Installing Stasis
• Introduction to Haml For HTML Layouts for Newbs – Part 2: Writing Haml
• Introduction to Haml For HTML Layouts for Newbs – Part 3: Markdown Syntax For Content
• Introduction to Haml For HTML Layouts for Newbs – Part 4: Final thoughts

Coupon Code: webmachine

Haml is great! But for what, is the real question. According to Haml’s website, “Markup should be beautiful.” It definitely does make things look clean and easy to read, but there seems to be a catch. Chris Eppstein (creator of Compass) wrote an article that basically says don’t use Haml for content, and I suggest reading it when you are done reading this. Looking at his first example, which I won’t duplicate here, you see what he is driving at right away. For the actual content of the site, Haml starts to look like garbage. What it IS good for though, is the actual structure of the template. Template, file, whatever. The stuff you write in HTML, like this:

<div id="luckDragon"></div>

Haml can do better:

#luckDragon

The lesson to be learned here is that, for the main layout of your site use Haml. For the fluff we’ll use something called Markdown, which I’ll talk about in Part 3 of this series. In this post, we are going to deal with the basics of Haml though.

Haml’s syntax

The first part you need in an HTML file is the doctype, and while there are many you can use (which you can see here), I am going to use the HTML5 version. The doctype is written out with three exclamation points, like so:

!!!5

Which will give you this HTML output:

<!DOCTYPE html>

Pretty sweet, because I am all about eliminating as many characters as possible, so I can get my work done faster. Haml does this with almost everything.

After that, things are pretty straight forward. Elements start with a “%”, id’s start with a ‘#’, class starts with a ‘.’. What is really badass is that Haml defaults id’s and classes to render as a ‘div’ in the HTML output file, unless you specify otherwise. Let’s take a look some basic syntax in an actual example:

!!! 5
%html
	%head
		%title Stasis - Static Sites Made Powerful
		%link{ :href => "stasis.css", :media => "screen", :rel => "stylesheet", :type => "text/css" }
	%body
		#container
			%nav
				%ul
					%li
						%a{:href=> "#"} Home
					%li
						%a{:href=> "#"} Services
					%li
						%a{:href=> "#"} About Us
					%li
						%a{:href=> "#"} Blog
					%li
						%a{:href=> "#"} Contact Us
			#content

If you have followed along so far, you can easily see what is going on here. Everything with a ‘%’ symbol in front of it, is an element. Everything with a ‘#’ in front of it is a div tag with an id. Once you render this into the HTML file, this is what you get:

<!DOCTYPE html>
<html>
  <head>
    <title>Stasis - Static Sites Made Powerful</title>
    <link href='stasis.css' media='screen' rel='stylesheet' type='text/css' />
  </head>
  <body>
    <div id='container'>
      <nav>
        <ul>
          <li>
            <a href='#'>Home</a>
          </li>
          <li>
            <a href='#'>Services</a>
          </li>
          <li>
            <a href='#'>About Us</a>
          </li>
          <li>
            <a href='#'>Blog</a>
          </li>
          <li>
            <a href='#'>Contact Us</a>
          </li>
        </ul>
      </nav>
      <div id='content'></div>
    </div>
  </body>
</html>

Now I know what you are thinking. Yes, the HTML is not formatted the way you would like it to be, but there are options in changing that, which I won’t get into right now. For now, just accept it and move along. In reality, if you are using Haml, the actual HTML is not what you are going to be working with. You would use the ‘.haml’ file. That is the point here.

Moving forward now, so keep up. If you really looked at the example I used above, you will see something I didn’t mention, and that is an element’s attributes. Not that big of a deal, it’s just markup you wouldn’t recognize if you haven’t seen Ruby. After the element you are going to put the ‘{}’ in, and between that are the attributes. If you have multiple, they are seperated by a comma, and each attribute starts with a colon. The odd part you will most likely forget without looking the first few times is the ‘=>’. I look at it as the attribute pointing to the value it is supposed to be. That could have been the intention, but what the hell do I know. Here is what the link to a css file would look like though:

%a{:href=> "#"} Home

Which outputs this HTML:

<a href='#'>Home</a>

Indentation matters, so pay attention!

Yes, Haml pays attention to how you indent your markup. You probably already do this kind of thing in your normal HTML when you nest your div tags, but it isn’t required. Forget to indent at the right place using Haml, and you could get an error when you try to render it into HTML. In the following example, you will see Haml’s markup for the HTML5 doctype:

!!! 5
%html

The above is correct, but if you tabbed over the ‘%html’, which renders as the ‘html’ tag, you will get the error: “Illegal nesting: nesting within a header command is illegal.” This is because Haml treats the indent as if you were nesting the ‘html’ tag within the doctype.

Now, if you indented an element over twice (2 tabs) from its parent, you would get an error that says something like “The line was indented 2 levels deeper than the previous line.” If you ever get an error like this, you know what your problem is. Indenting is extremely important because it shows Haml how to structure everything. If it is tabbed over from the element above it, that element becomes nested within. Seriously, this is important if you are going to be using Haml.

Rendering Haml into HTML

Two methods really. The regular way, and the way Stasis does it if you have that all loaded and ready from the previous post. I’ll show you both though, just in case.

Using Stasis: at the command line, cd to the directory your file is in (index.html.haml) and type:

$ stasis -o index.html.haml

This will output an HTML file in the public folder named ‘index.html’.

Just using Haml, in the command line, cd to your project folder, and type:

$ haml index.haml index.html

The first file (index.haml) is obviously your Haml file, while the second is what you want the output file to be called (index.html in this case).

Either way is easy, you just don’t have to go through all that install crap that I went through in my first post in this series. I was using Stasis because I might be using its options later.

Final thoughts

I REALLY like Haml for its simplicity, and almost as much as I love Sass. You become aware of things pretty quickly once you start using it, such as indentation being key to writing your structure. I think the best part of writing your layout using this, is that the basics are learned quickly. Once you have it down, writing the main structure becomes a breeze. I should also point out that while you are using Haml’s syntax, you can also inject HTML into it just like normal. Seems kind of pointless, but the option is there.

What’s next?

Since Haml is not great for writing the actual content of the site, the third post in this series will deal with Markdown. It is a plain text formatting syntax that you can use within Haml, and makes writing the content easier.

Hope you learned something today, so leave a comment and let me know!

Artilces in this series:

• Introduction to Haml For HTML Layouts for Newbs – Part 1: Installing Stasis
• Introduction to Haml For HTML Layouts for Newbs – Part 2: Writing Haml
• Introduction to Haml For HTML Layouts for Newbs – Part 3: Markdown Syntax For Content
• Introduction to Haml For HTML Layouts for Newbs – Part 4: Final thoughts

Coupon Code: webmachine

Learning something new is awesome, and writing about what I am learning helps me get it into my head a lot more. Yesterday I started learning how to use Haml, and once I started, I thought I would pass on this newly acquired knowledge on to you. This series is for NON programmers. You might know javascript/jQuery, but the people I am writing this for are not really going to have any real knowledge of programming. If you have just gotten into using Sass, then this is a perfect next step for you. Here are the topics in this four part series:

• Introduction to Haml For HTML Layouts for Newbs – Part 1: Installing Stasis
• Introduction to Haml For HTML Layouts for Newbs – Part 2: Writing Haml
• Introduction to Haml For HTML Layouts for Newbs – Part 3: Markdown Syntax For Content
• Introduction to Haml For HTML Layouts for Newbs – Part 4: Final thoughts

So what the hell is Haml anyway? Well, imagine taking out the syntax of an HTML document, and replacing it with a cleaner syntax. It also adds a ton of other functionality, but what I’m going to be talking about in this series is just basic HTML layout writing. Mainly because I just got started with it myself, so the other stuff will have to wait.

Let’s install Stasis

I have been wanting to use Haml (a Ruby gem) for a long time now, but I didn’t know how to go about doing it. If you are not familiar with the command line or Ruby, things like this are intimidating. Thanks to another Ruby gem, called Stasis, I was finally able to get a Haml file rendered into an HTML file and finally get started with seeing what it is all about. I love learning new things, so thank you to SmashingMagazine for tweeting about it yesterday. Who would have thought they would be the ones to let me know about this?

First, we need to get a few things installed. Most importantly, Stasis, but even before that, we need to make sure we have a few things done. Open your command line and make sure your Ruby Gems are updated (it’s probably just a good idea to do so):

NOTE: the ‘$’ seems to be a universal thing when showing that you are writing a command line instruction. No idea why, but I’ll use it as well. Just note that you do NOT type the ‘$’ in the command line.

$ gem update --system

Then install Haml:

$ gem install haml

That was the easy part. Now onto the annoying crap. I had to install a bunch of gems to get stasis to work, and while I am not sure which ones are required, I recommend doing all of them at the same time. The one I know you need for certain, is the Ruby DevKit. Go there, download it, extract it (I did it straight to my C: drive), and then go to the command line, change directories until you are at the location of where you put the DevKit, and type:

$ ruby dk.rb init

After you get the confirmed initialized message, type this:

$ ruby dk.rb install

Now, it might just work after that, but mine was still having issues, so I went to the Stasis page on the Ruby Gems website and installed everything that was listed at the bottom:

$ gem install directory_watcher
$ gem install redis
$ gem install slop
$ gem install tilt
$ gem install yajl-ruby
$gem install rake
$gem install rspec

I’m guessing you don’t need all of that, but it didn’t hurt. Once you have all of THAT done, NOW you can install Stasis:

$ gem install stasis

Start a new project

Now that you have Stasis installed, go and create a folder to test all this crap in. Create a new file and save it as ‘index.html.haml’ using a text editor (Notepad++ for me!), within that folder. Next, go back to the command line and change directories until you are in that folder, then:

$ stasis

This should place a folder within the one you created, called ‘public’. In it, you will see a file called ‘index.html’.

Can I use Haml now? Please?

YES! Just not in this post. I’ve probably already went beyond your capacity to really pay attention to me anymore, so you shall have to wait until the next post! I’ll let you see a hint of what Haml is all about though.

What you might write in HTML

<div id="container">
    <p>This is typical crap.</p>
</div>

The same thing, but written in Haml:

#container
    %p This is typical crap.

So what will we be learning in the next post?

The fun stuff of course. Haml’s basic syntax as I walk you through how to write up a standard static web page. The third post will be on writing the content (what you read on the site) using Markdown syntax, and putting it within Haml. The final post in the series will be my thoughts on all of it combined.

If any pros have an easier way to just use Haml (and quickly), I’d love to hear it!

Coupon Code: webmachine

If you haven’t heard of Adobe’s latest offering, Muse, then you probably don’t read any web development blogs, including this one. If you do read them, and still haven’t heard of it, well, you have now! You may thank me for your enlightenment later. Anyway, there are a LOT of comments from web developers bashing the hell out of this product. I have not seen many (I can’t even recall one actually) comments praising it for what it does. What does it do? Write serious crappy code. I mean divititus to the umpteenth degree.

This product isn’t meant for my people though. Who do I mean by “my people”? I’m talking about those who hand code their sites and left software like Dreamweaver in the dust years back. Muse is meant for graphic designers, or web designers that don’t actually know how to create a site but design them anyway. They create a design, and then use Muse (which has tools like other Adobe products – think Photoshop) to make a nice little layout. Hit a button and BAM! Here is your website.

I think many of the people doing this for a living though feel a slight twinge of fear, thinking this might cut into our freelance projects, or possibly worse…our jobs.

Damn…that went all serious, didn’t it?

Nothing to fear

If anything, Muse might actually GIVE us more work for the future. Some designer building a site for a client that wants a little functionality, or some jQuery bit added later, is going to get screwed. “I’m sorry Mr. Client, but I don’t actually know how to do that cool widget thing,” which in turn makes the client go out and look for someone like us. They give us a call, and we say yes, we can help. We go to their current site, look around and say “Nice design you have.” But…then we look at the source. In two seconds we think “Well this is interest…WHAT THE F#$@!?” Because we are looking at something like this:

<div class="colelem" id="n4"><!-- group -->
     <div class="grpelem" id="n5"><!-- group -->
      <div class="grpelem" id="n6"><!-- content -->
       <p id="n8">Some stupid line about hummingbirds</p>
       <div class="wrap"></div>
      </div>
      <div class="grpelem" id="n10"><!-- content -->
       <p id="n12">Yes, hummingbirds are indeed small.</p>
       <p id="n14">&nbsp; <span id="n15"></span></p>
       <p id="n16">They are even fast as hell!</p>
       <div class="wrap"></div>
      </div>

Ok, I changed the actual text in there, but the HTML is actually from one of Muse’s showcase sites. What is worse is, that is only a small piece. While looking at this poor client’s site, after the initial shock, we take a look at the CSS and pray for something brilliant. What do we see?

#n18, #n148
{
	z-index: 100;
	width: 534px;
	min-height: 82px;
	position: relative;
	margin-right: -534px;
	margin-top: 199px;
	left: 299px;
}
 
#n26, #n156
{
	z-index: 108;
	width: 447px;
	position: relative;
	margin-right: -447px;
	margin-top: 10px;
}
 
#n28, #n158
{
	z-index: 110;
	width: 534px;
	min-height: 214px;
	position: relative;
	margin-right: -534px;
	margin-top: 301px;
	left: 434px;
}

At that point I would get up and throw my trackball at the wall cursing the heavens for making my eyes see this offense to the gods of web development. “Why?!” My first reaction was actually just speechless. I seriously HATE negative margins. HATE them. This stylesheet is littered with it. On top of that, everything is positioned pixel perfect. That is just a few items you see positioned relatively, and z-indexed to hell. Trust me, the whole THING is like that. So what would you do if a client comes to you for some changes or additions to a site built like this?

For me, there are two options: 1) I either flat out tell them no, because I don’t want to get involved knowing that this type of client isn’t going to want to pay me what I need/want, or 2) I charge them my usual hourly rate and warn them this could possibly cost them more than what they paid for the site. I either get the money for the work I’ll have to put into it, or I won’t end up having to deal with this pile of crap.

People are overreacting

I understand all of the bad comments I’ve read. I agree with some of them. Muse writes horrible code. Must writes horrible CSS. Muse is bad for the web. Wait…what? See that is where I don’t agree. One, I think the audience for this product is going to be very small. It’s not like every freakin’ graphic designer is going to go out and buy this and think “HAHAHA! Screw all you HTML junkies, I can build websites too!” Absolutely not. If people are really into learning how to build a website, they aren’t going to be getting into Muse. No one is going to start a business where they build websites for clients using it. Just won’t happen.

The people that will use it are going to be designers who want a portfolio of their work up, but don’t know how to build a site, or maybe a person starting a small business that has no budget or a willing relative that dabbles in HTML. Or maybe a print designer who has done a bunch of advertising work for a small client, who then needs a basic info site which they can provide now. We are talking about a very small fraction of people here.

Here is a quote from the comment section of this article that really sums up what others are also probably feeling:

“This whole idea to me seems like cheating and it devalues our trade. To top it off, it does not even create elegant, semantic or as you rightly say, fluid markup either!”

Does it create non-semantic code? Yes. Does this matter to anyone that isn’t a web developer? No. Clients do not know, nor do they care about semantics. I’ve never had a client actually even look at the HTML of a site I’ve built. Ever. It just needs to work for them to be happy.

Does Muse take the web a step backwards? Are we going to see thousands of sites made with Muse, and end any type of innovation? What?? No, that is ridiculous. We all need to take a step back and take a breath. Web developers are taking such huge offense by this product. “How dare they make a product that makes it seem like what we do is easy!” Adobe didn’t take aim at our jobs. There is no hidden agenda trying to belittle what we do. They are trying to make money, that’s it.

Read about it and forget it

My whole point is that the people hating on Muse, are the people that won’t be using it. It was NEVER intended for web developers. I will never open the program, and mostly likely neither will you. Muse is meant to get a website up by people that have no idea about how to do it. It is another WYSIWYG, and we left those behind some time ago anyway, haven’t we? I say bring on the freelance projects that might come our way because of it. The amount of time it will take to correct Muse’s crap will bring in some nice cash! Unfortunately it is hard to gauge how actual users like the product because we are the only ones commenting on it. Which kind of seems unfair. Let a designer use it who hasn’t built a site before make the call. I don’t see much difference between Muse and Dreamweaver’s design view. Muse just writes the HTML/CSS in a much more offensive manner.

Your opinion and mine don’t really matter on it. I’d like to know what the actual potential users of it think, but by now they are probably too scare to comment because a lot of us are bitching up a storm.

If you wish to read another article about Muse, this one was worth the effort as well.

Coupon Code: webmachine

A project I’m working on had me looking into how to create a nice looking mobile site. Two very popular frameworks came to mind: jQuery Mobile, and Sencha Touch. The back-end guy I’m working with on this project recommended Sencha Touch, so I took a look at that first. Let me just say that if you haven’t worked with Ext.js and it’s panel component, or are not even familiar with that library, you are going to have one hell of a time. It is not all that easy to use, and the limited amount of tutorials on how to use it suck beyond belief. After a couple of hours fiddling with it, I decided to say screw it, and went over to jQuery Mobile. The difference? I got a site up and running in roughly a half hour with no problems themeing. jQuery Mobile wins in ease of use hands down.

This isn’t to say that Sencha Touch is bad, because it sure looks good, but it isn’t as intuitive as Mobile. This isn’t really about Touch though…it’s about Mobile. So let’s get into it!

Pages, nav bars, and buttons – this stuff is easy!

Not just those specifically, but everything in general. Pages though, couldn’t be any more simple because you can do it on one layout. Each different type of section is identified by the attribute ‘data-role’. A page has a data-role of page, a nav bar has a role of nav, footer has a role of footer, header – header, and it goes on from there. You could almost guess at most of them. So let’s say you have a mobile page, and you want a header, a nav bar, the content section, and a footer. Check out the simplicity of how you would write this:

<div data-role="page" id="homePage">
 
	<div data-role="header">
		<h1>Home</h1>
	</div>
 
        <div data-role="navbar">
		<ul>
			<li><a href="#homePage" class="ui-btn-active">Home</a></li>
			<li><a href="#about">About</a></li>
		</ul>
	</div>
 
	<div data-role="content">	
		<p>Any idiot with an HTML editor can do this!</p>	
	</div>
 
	<div data-role="footer">
		<h4>All your footer crap goes here. Like social icons that no one cares about.</h4>
	</div>
</div>

For the second page (about in the above example) you would just copy the above html, and change the id of the page dive to ‘about’, and switch the ‘ui-btn-active’ class to the ‘about’ link in the nav, and you are good to go. Want more pages? Keep doing that. That is what makes this framework so nice. I don’t have to think about what I am doing. How about buttons? Piece of cake!

<a href="#contact" data-role="button">Contact us</a>
<a href="#pricing" data-role="button">Pricing</a>
<a href="#services" data-role="button">services</a>

Or a list:

<h1>Favorite Movies</h1>
<ul data-role="listview" data-theme="d">
	<li><a href="#a">Goonies</a></li>
	<li><a href="#b">Better Off Dead</a></li>
	<li><a href="#c">Interview with the Vampire</a></li>
</ul>

Theming jQuery Mobile

Theming also couldn’t get any better. There are five basic theme swatches, which is what the framework calls them. They are lettered a, b, c, d, and e. Certain data-roles default to specific swatches, like header and footer, which default to ‘a’. Others default to c. There is a hierarchy on how something defaults, but you don’t really care about this crap because you are going to style your own in any case.

Well besides adding the necessary script to get jQuery Mobile to work, there is also a CSS file you will link to. All of the required styles are in there. So let’s say you want your header to use swatch ‘b’ (which is blue), you would just have to add the data-theme attribute with the correct letter, like so:

<div data-role="header" data-theme="d">
     <h1>Home</h1>
</div>

Your header would now have the blue color with white text. But no one is going to use the that blue color, so you go into the style sheet, and find the class and change the color. You could create a whole new swatch theme by copying the necessary styles, and changing the letters within the class names to ‘f’. Be careful though because any button that is placed within a bar, such as the header, will automatically be assigned a swatch letter that matches its parent bar.

jQuery Mobile for the win!

My main point in showing you the things that I did above is that the entire framework is easy as hell to use, from basic html to methods for page transitions, to touch events. The documentation is really easy to read, gets to the point quickly, and gives great examples. This is one of the major reasons why I think Sencha Touch will be the number two framework. Anyone can create a nice looking mobile page with jQuery mobile, and get it done quickly.

This doesn’t mean that the framework only does simple things. It is up to you to use it and do some very cool stuff with it. I also just touched on the basics, so be aware that there are things you have to look out for. An example being that anchor tag linking doesn’t work because Mobile uses the hash tag to identify pages. Point being, go and actually read the documentation on each part you are working on so that you don’t run into problems later.

For the brief time I have used jQuery Mobile, I am already a huge fan.

Coupon Code: webmachine