Archive for the 'Techniques' Category

Auto-Building YUI 3 Custom Modules

The details of my development strategy to automatically build YUI 3 Custom Modules that I outlined in my talk at YUICONF 2009.

YUI 3’s modularity and instance sandboxing invites developers to create their own custom modules, breaking apart their specific application logic.

Diagram depicting the categories of YUI 3 modules on a scale from general to specific

YUI 3 Modules Categories from General to Specific

Having developed over 30 Custom YUI 3 Modules in the last year I quickly realized I needed a sane way to go from writing code to running it in the browser. So, I set out to connect the YUI Builder with my IDE.

For the last three or more years I’ve been using Aptana Studio IDE for HTML, CSS, and JavaScript code development. Aptanta, which is built on Eclipse, can be used standalone or as a plugin to Eclipse. The concepts here are not specific to Eclipse; the details of my technique on implementing the concepts are however.

Goals and Reasons

  • Synchronize UI building with the rest of the project code.
    Compiling of JavaScript (when needed) should occur along with any server-side code compilation. IDEs such as Eclipse, ‘Build Automatically’ a project’s Java code; I want my YUI 3 Custom Modules to ‘Build Automatically’ as well.
  • Faster turn-around.
    I don’t want to switch from my IDE to another program to run builds on my UI code. The IDE should recognize when it needs to re-build my UI code. I want a process where I: hack… hack… save… refresh-browser…
  • Easier for non-UI developers.
    Teams of developers are usually working on a shared code-base; a mixture of server-side and client-side code wrapped up into one project. If the UI code is built automatically, like the server-side code, the non-UI developers won’t bitch don’t have to do anything UI-related.
  • Cmd + S = JSLint, Compress, & Deploy.
    Anytime the source file(s) to a YUI 3 Custom Module change, the YUI Builder tool runs, giving me: JSLint-ing, YUI Compressor-ing, and YUI 3 Module wrapping.

Continue reading ‘Auto-Building YUI 3 Custom Modules’

Adaptive CSS-Layouts: Compromising Ideals

Smashing Magazine recently published an article posing a question [as it's heading]:

Adaptive CSS-Layouts: New Era In Fluid Layouts?: “Fluid web designs have many benefits, but only if implemented correctly. With proper technique, a design can be seen correctly on large screens, small screens and even tiny PDA screens. With bad coding structure, however, a fluid layout can be disastrous. Because of this, we need to find ways to work around most, if not all, of the cons of fluid design.”

(Via Smashing Magazine.)

Intrigued, I read through the lengthly article; which, seemed to answer the posed question positively; or at least suggested the possibility of a yes answer.

The article is a prescription of six “effective techniques to create 100%-functional adaptive CSS-layouts” (quoted from article). These techniques are not independent from one another; they must be used together, and implemented correctly to achieve their prescribed solution to the Adaptive/Fluid layout problem.

All of these techniques can be implemented in one design to create a very user-friendly fluid layout. A smart use of the fluid grid can create an adaptable layout whose proportions remain faithful to the Rule of Thirds, balance and other design principles…

I’m left dissatisfied with Smashing Magazine’s solution. Spending time to understand and apply six different, seemingly independent, layout techniques to an interface feels too compromising. The one-size-fits-all approach to User Interface design leaves you compromising on crucial interface components and aspects of usability. The interface for a web site/application on a computer isn’t going to best serve a user on their iPhone; users with a computer screen resolution of 800×600 are rare; users with wide-screen monitors don’t browse at full screen.

Contorting the development of one interface to serve vastly different devices is not ideal. To achieve a better, more usable interface you must design for the device. I’m not buying the idea that we, as web developers and designers, can get away with forcing our compromised interfaces on user’s screens big and small.

I posed a somewhat opposing question about layout— regarding it’s flexibility, in October 2008: Layout Flexibility – Still A Requirement?

Questioning my own pervious layout techniques and use of Elastic Layouts (em’s to specifying box-model dimensions). Concluding that the adoption of full-page zoom in modern browsers leaves the elastic-layout technique obsolete.

Using Bazaar On a Mac

Bazaar has become a tool I’m using all the time. Using Bazaar as a version control system means using a command line interface. I haven’t found a feature-rich Bazaar GUI tool like the ones that exist for Subversion. I feel alright with using a command line interface for executing commands; but it is frustrating to edit text, review diffs, and manage merges in a command line environment. It just sucks! I want something better: a work-flow that keeps me productive, and an appropriate interface for the task at hand. Specifically, I want my version control system to be integrated with my Mac and the existing tools I use; I want to be able to:

  • Manage my files and folders using Finder
  • Write commit messages, view diffs, and manager merges in TextWrangler

Continue reading ‘Using Bazaar On a Mac’

Browser Testing IE On a Mac

For the past couple of years I’ve been trying to get a reasonable setup for testing Internet Explorer on my Mac. With the recent release of IE 8 RC1, I thought it might be a good time to revisit my browser testing setup.

I use an Apple Macbook (the black one) with OS X 10.5 and 4GB of RAM as my sole machine. With my Mac I should be able create a reasonable setup to test all major web browsers. I’m less interested in testing all OS and browser combinations simply because that seems unreasonable for most projects.

Operating System and Browser Testing Combinations

The following is the list of OS and browser combinations I want to be able to test; each OS has browsers listed in the order of which I care most about supporting:

  • OS X 10.5
    • Firefox 3
    • Safari 3
  • Windows XP
    • IE 7
    • IE 8
    • Firefox 3
    • IE 6
    • Firefox 2

Developing on a Mac, I’m always running things in OS X 10.5 / Firefox 3, making the combination always supported. I will also occasionally checkout how Safari 3 is doing while developing, although it’s usually fine.

When in browser testing mode (not developing new features) I’ll run through the Windows XP / Firefox 3 and Windows XP / Firefox 2 combinations; mainly to checkout how the font-renderings are holding up in Windows.

Then comes IE testing. I start with IE 7 which I find not too difficult to get working, usually just have to fix the hasLayout issues. With IE 8 coming into the mix soon I’m going to start testing it; hoping that it will be even easier to get working than IE 7. JavaScript frameworks like YUI are pushing hard to support IE 8; which is great as the CSS support in IE 8 seems to be much better than in IE 7. Of course the hardest of all to get working, IE 6; some projects need to support it no matter what, others can just not worry about it (like my personal web page).

I feel that I’ve found a testing setup that will allow me to carry out my browser testing process much easier than I could in the past.

Continue reading ‘Browser Testing IE On a Mac’

Layout Flexibility – Still A Requirement?

Is having a flexible layout required anymore?

It is second nature for me to command + while testing out my XHTML and CSS to make sure the text scales nicely and the layout is flexible to wider and longer content. Firefox 3 has been my default browser since it’s been out of beta and I still increase the text-size to check if my layout is adapting correctly. Doing this in Firefox 3 has a different effect then what I am used to and I’m constantly reminded, “Oh yeah, Firefox now does that full-page-zoom thing”.

On a recent project I was working to get an Adobe Fireworks design “sliced” into XHTML and CSS; this time I remembered about the Firefox 3 full-page-zoom. Thinking about what Firefox 3 does, I also remember that IE7 does something similar but not as well as Firefox. Now launching Safari 3.1…, ready, set, command + …aww bummer, just normal text-resizing.

So which browsers are doing the full-page-zoom and which are doing just text-resizing?

Continue reading ‘Layout Flexibility – Still A Requirement?’