Now look at three of Adobe’s latest products: Flash Catalyst, Edge and Muse. There’s one common thing to all these programs, build things without coding. This all leads me to believe one thing, Adobe gets how to build programs for designers but has no idea how to build anything for the serious developer. I’m a firm believer that Flash Catalyst was a direct response to designers saying they liked Flash better back when it was more of an animation tool that allowed a bit of coding. And you know what, I’m glad they made it, I don’t know if anyone actually uses it, but it hasn’t flooded the web with Flash sites that were any worse than people were putting out there before. Edge has potential, but I think it’s going to have to have it’s animations be canvas or SVG based to really catch on. And Muse to me is just a bad idea. The code it creates is awful and really, it’s just Dreamweaver with the code view removed.

I wasn’t the least but surprised by the web development community’s reaction to Muse. I pride myself in my ability to take a design and recreate it using HTML and CSS as close as a browser will let me. I spend a lot of time communicating with the designers I work with, I let them know what’s realistic and they let me know when they think I’m just being lazy. Muse seems to me to be evidence that Adobe feels developers are neck bearded nerds that don’t care how long you spent getting that gradient just right, they’re going to ruin your design because of things like functionality. So, Adobe is giving the designer the power to make their design look exactly like they want, no more arguing with those nerds that just don’t get it. But when Adobe’s example site has 1500 lines of HTML and someone recreates it using only 105 lines when they hand code it, it shows you how much Adobe missed the mark.

There was and maybe still is a way that Adobe could have avoided the developer backlash. Dreamweaver is actually a really decent code editor, it’s just expensive and most developers don’t want to be bothered with all the extra stuff it comes with. Adobe should come out with a cheap, or even free, version of Dreamweaver that’s just a code editor. Imagine if they’d released that at the same time as Muse? Look, Microsoft has two free coding environments that are actually really good and that I actually recommend to people, Visual Web Developer and WebMatrix and both are free.

But then again, has Adobe ever made a great coding environment? Flash Builder doesn’t seem to have the greatest reputation and Dreamweaver heyday was when it was built by Macromedia. I don’t think there’s been any major changes to Dreamweaver since Adobe bought it. And really, at $399, I doubt anyone that uses Dreamweaver actually bought it on it’s own, most people probably got it because they bought one of the Creative Suites. And who’s going to pay that much for something when you can get the same thing for free or for $29.

I think Adobe is fighting to stay relevant to the web design community but they’re doing it with the risk of alienating the web development community. I like Adobe and I like a lot of their products (any time I get to use After Effect is a good day), I think they are having trouble finding their place in the evolving world of the web.

Eventually, I came across Komodo Edit, which replaced Dreamweaver for me as my main editor. I love that it’s pretty light weight, free and has code hinting for everything from HTML5 to jQuery. I can’t say that I have any real complaints. It’s open source and there’s a pretty good community around it.

But before I came across Komodo Edit, I gave a ton of editors a chance. Aptana is OK but it can really start to run slow after a while and anyone who’s been in a hardcore coding stretch, it really sucks when your editor starts to slow down. I did a couple of video tutorial series on JavaScript and the host was using Microsoft’s Visual Web Developer, which I tried out, but it just has the feeling that it’s made to work with Microsoft technologies like .Net and I could never just get comfortable with it. Microsoft came out with Web Matrix, which I gave a shot, and while it wasn’t bad, it just didn’t have some of the features I have become used to in a code editor.

I work on a computer running Windows, so I have to admit, when watching video tutorials where the host uses Textmate, sometimes I’d just a bit jealous because of some of the features it has that none of the editors I’ve used on Windows has. That was until I came across E, a text editor for Windows that has, as far as I can tell, all the same features as Textmate. I’ve been playing around with it for the last couple of days and so far I’ve enjoyed it. But there’s one problem, it doesn’t have code hinting.

Komodo Edit has plug-ins that add some of the Textmate features I want, like using tab to insert code snippets, but it doesn’t work quite how I’d like and because most of the snippets that are included aren’t set up the way I’d like and it changes some of the functionality in ways that I’m not a fan of. I’m going to give E a chance but I’m not sure if I’m going to able to live without code hinting, it just speeds everything up so much and I’ve gotten so used to it.

I still firmly believe that what you use to build with doesn’t really matter, what matters is the end product, whether it’s an app or a website. I’m just searching for the right one for me. In fact, I shouldn’t have been surprised, but it seems most developers are as passionate about what editor they use as they are about what languages they use.

But I kept looking into JavaScript and got really excited about jQuery. jQuery is the perfect gateway drug to JS, I think. It allows you to get projects up and running quickly, and for me at least, it made me want to learn more straight JavaScript. Now I find myself trying to figure out a way to include some JavaScript effect into every site I work on.

I don’t think that JavaScript itself won me over, it’s the fact that the modern version of all the major browsers allow you to build things that would be nearly impossible without a plug-in a few years ago. But now, for a lot of effects like an animated drop down navigation, you just need to link to a JavaScript file and, bang, you’ve got the effect you’re after.

Plus, I think with JavaScript and ActionScript both being based on ECMAscript, learning one after being familiar with the other makes it really a situation of learning the differences between the languages than anything else. So switching my focus has been pretty easy for me but it has been without some frustration. Not strong typing variables took a bit of getting used to.

I still can’t believe that I get excited about JavaScript heavy projects but I think that the leaning of the web to move from plug-ins to browsers for dynamic website experiences has been a good thing. Plus, it’s taught me that as a web developer, you shouldn’t limit yourself to one or two technologies. Honestly, for the longest time, I was hoping that Flash would take over for HTML because of the crazy dynamic things you could build with it. But now, thanks to the innovations by Chrome and Firefox, it can be done with HTML/CSS/JS, which means you can build a great website experience with a text editor as simple as Notepad. Which is pretty cool when you think about it.

I’ve just been messing around with some transitions made a couple of examples of what you can do. You can check out the demo here.

The first example is pure CSS. The animation is triggered by the :active selector which unfortunately won’t let you just click on the div to tigger it. The second example uses jQuery to toggle the a class on and off to trigger the animation. Although I’m using jQuery here, it’s just to trigger the effect, the animation is still 100% CSS.

And using CSS3 transitions, it’s actually really easy to set up some sliding captions using just CSS. Here’s the HTML I used:

Here I’ve created three divs that each have an id but also share the slider class. And the div inside the parent slider div is going to be the one that we apply the transition effect to. Next, we just need to set up the CSS:

The important stuff here is what’s in .slider and it’s child properties. First we set the height and the width of the slider div and it’s overflow to hidden, this will hide the caption.

Next, we set up the div inside the slider div. The important parts here is the padding-top is set to be the same as the height of the slider div. And here we set the transition properties, I’ve put in all for the property we want to effect just to make things easier, but it could also be set to padding-top and work the exact same. The time is set to 0.2 seconds because no one wants to wait to see a caption.

The property that we are going to change to make this effect work is the padding at the top of the div inside the slider div. Why? Because using CSS we can only effect an element that we are hovering over or clicking on. So we have to set the padding so we can shrink it and have the child paragraph tag slide up.

You can check out a demo here.

The rest of the CSS is just for styling. Building something like this isn’t that complicated but there is something that I have added to my CSS wish list. I wish there was some way to set it in CSS that when you are interacting with one element on the page, you can have the effect on another element. This was something I thought we’d be able to do with the :target pseudo selector but it doesn’t appear to work that way. I’d love it if we could do something like this:

This way we could set it up so that when the user hovers over the slider div, the slider-up div moves up 20 pixels. Maybe something like that will be added in the future, it really would make CSS even more powerful.

We are going to take the totally usefull plug-in we made last time and change it so we can pick the new background color and also so we can set a new width of the div. The HTML and CSS are the same:

Same as last time, nothing major here. Next we’ll modify our plug-in to allow us to pass in some variables:

Ok, so what’s going on here? Well, the first change from our early plug-in is in the second line:

We are passing in our variables from the HTML file through vars. With this we can pass through as many variables as we want to. This time we’re passing two plus the element in the HTML document that we want to affect, this will give us these three variables:

The first one, clicked, is the same as last time, but the other two look a lot different and might be a bit confusing to some one that’s not familiar with JavaScript shorthand. What we are doing here is setting the variable color to what we set color to in the HTML file or else to #0f0. This is the same as an if statement.

So we are saying if vars.color isn’t undefined, color equals vars.color or else color equals green. We do this so that if we don’t set a color then the plug-in will default to green. And we’re doing the same with width, if we don’t set it, then the default with is 400 pixels. We could also set this to null and then run an if statement later, but this is simpler. Next is the actual meat of the plug-in:

Here we’re saying when element is clicked then change the CSS properties for element. Now we have to set up how we call the plug-in in our HTML file:

We’re calling our plug-in for both the #blue and #red divs and we are setting the width for the #blue div to 100 pixels and the background color of the #red div is being changed to yellow. So now when the #blue div is clicked it changes to a width of 100 pixels and changes to a green background whereas the #red div will become 400 pixels wide and get a yellow background.

And that’s all there is to setting up a jQuery plug-in that has custom values. Building your plug-ins this way makes them even more useful and enables you to use them over and over without having to edit the actual JavaScript file.

We’ll write a quick plug-in here just to show you how simple it is. Here’s the HTML and CSS:

We’re just making two boxes, one red and one blue. And we’ve linked to directly to Google’s CDN of jQuery. Now we’re going to make it so when you click either one of the boxes, they turn green. Pretty much useless but I think it’s a good way for a beginner to see how to set this up. Now for our jQuery file. Open a blank file, I’ve called mine our_plugin.js and start off with this:

That’s how every plug-in is going to start, we’re assigning the $ to jQuery so the browser knows what to do when it loads the file. Next, we need to set up and name our function:

The standard is to name your plug-in the same as the file name. Honestly, I don’t know if this would still work if you didn’t. Now for the actually meat and bones of this thing:

What’s going on here is that we are assigning whatever we’ve passed to our plug-in from our HTML file to the variable name clicked. And then we are saying when clicked is clicked run this function where we are changing the background color of whatever we passed into the function.

And that’s it. It’s pretty quick when you’re just doing something simple. Remember, this is just to show the basics of how you going about setting up a jQuery plug-in. But we aren’t done yet. Even if you linked to the our_plugin.js file, nothing would happen. We just need to add a little bit more to the HTML file:

The usual place to add this is at the top in between the head tags or at the end, just before the closing body tag. Remember to have it after the script tag that loads jQuery though, or else it won’t work.

So what’s happening here? Well, first, we’re passing the #blue div to our plug-in and then next we’re passing the #red div. And now when you click on either div they’ll change to green. Yes, it’s really that easy to set up.

Next time, I’m going to show you how to build one that’s a bit more complicated, where you’ll set up some variables that you can control when calling the plug-in in your HTML file.

Webkit has become the favorite of developers over the last couple of months, I think for a couple of reasons. First, the two major browsers using Webkit, Chrome and Safari are pushing forward and both have fast JS engines, Chrome especially. Second, a lot of web designers use a Mac and a fair amount of them use Safari as their main browser, so of course you’re going to use the browser you’re comfortable with when you’re building something.

But here’s the thing, most of the people on web, by a vast majority, don’t use Webkit. I switch back and forth between Firefox and Chrome and I try to get everyone I know to use one of them. But the fact is, no matter how great your thing is in Webkit, if it doesn’t work in even Firefox, then it’s useless. At least until the other browsers catch up. At work, my bosses only care that it works right in IE and then Firefox because those are the browsers the clients use and a majority of clients don’t care that there’s more than one browser out there, which is a unfortunate fact. I check them in Chrome and Safari but I’ve never been asked about it.

So really, if your effect or transition or design only works in Webkit then how many people are going to see it? If it’s just an experiment that you made and it’s really only for other designers and developers to look at, then it doesn’t matter. But if it’s something that you think has real commercial value, then you’ll either have to find a way to make it work another way using something like jQuery or you’ll have to wait for the other browsers to catch up. Personally, I wish the CSS3 3D transforms worked in every browser and not just Webkit.

I’m not saying that we shouldn’t be making things that only work in one browser, especially if we’re just doing it show off what the browser or we can do. I’ve made things that only work in Webkit or worse, only work in Firefox 4 beta. But usually those are just to show what the future is going to hold for us. Webkit is great and hopefully IE catches up soon and I’m sure they eventually will. But don’t be a Webkit snob, it’s almost as bad as being an Apple snob.

I will say there are times when I see Flash being used and it frustrates me. I don’t see any need now to use Flash for only the navigation on an otherwise HTML site. I’ve yet to see an effect special enough to justify it. Most, if not all, of the Flash effects I’ve seen on website navigations I’ve seen could either be created with JavaScript or wasn’t worth the extra memory. It goes without saying that Flash intros are long dead and so are Flash banners used to in the header of a website. I’ve built sites with these and usually they just feature something movie or a sheen moving across quickly and they end up being more annoying then adding anything to the design. Also, if you’re Flash site looks like an HTML site, then you really wasted you time building it in Flash.

Flash still has it’s strengths though. I really think that if you want to create and experience, you still need to use Flash. Firefox 4 shows some of the potential of what we’ll be able to do eventually with just CSS but for now, Flash is still the way to go. Great examples of sites like this are usually made by companies who want a site to showcase a product. Car companies do this a lot with Flash sites that mix in a lot of different media, like video and other interactive elements.

Personally, I think video is going to be the domain of Flash for the next couple of years, for two reasons. 1) Until IE9 becomes the main version of IE on the market a majority of the browsers out there don’t recognize the video tag and 2) Until one of the codecs become dominant, Flash will be the easiest way to get your video online. Plus, until the end of IE6, you’ll always need to have Flash as at least a back up if IE6 users are part of your target audience.

Flash is a long way from dead but I think it’s feeling the backlash of developers overusing it for the past few years. I’m still a big fan of Flash and I really believe that sometimes Flash is still your best option to build interactive features on a website. If you’re someone like me, who is still learning JavaScript, in order to get things built fast and to know it will function how you want, Flash is right there. And a big point I think that a lot of people miss is the average Internet surfer doesn’t care what you built it in as long as it works.

Here’s a demo of the effect.

Our HTML:

All we have here is a basic website nav, links to jQuery, jQuery UI and our jQuery code.

The CSS:

Here we’re setting the green_glow.png as the background to #glow. #glow also has a z-index of 1 and the links have a z-index of 2 to make sure that they appear on the top. Other than that, the CSS is just basic styling.

The JavaScript:

The main differences between this and Jeff’s original code is that we aren’t creating the background with the slider using CSS, we’re using an image. And the slider isn’t bigger than the regular <li> tags.

And here’s what we get.

This is a great effect that can be different every time and it’s pretty straight forward. And a nice bonus is that you can reuse the jQuery code every time because the main effects and styles are all set with CSS.