Tagged: development

Harder, better, faster, stronger

Working in a fast-paced environment on a stressful project with a short timeline can easily take a knock on your development time and efficiency. Here are some tips to quickly get organized and get coding.

Review the designs

When you’ve first find out that you’re starting on a new project, ask the assigned Project Manager if there can be a period of time reserved before development for review:

• Resolve any inconsistencies between page designs
• Get all of the fonts being used in the design for sIFR or Cúfon
• Ask any questions that you may have about the design, for example: Does that box stay the same height, or will it grow with content? Is that text going to be part of the image?
• Bring up any potential issues and figure out a strategy for resolution before starting development

Build templates

When building HTML templates, it’s best to start with creating your global elements, then work towards specific page elements.

• Build out the global elements first
  • The header and main navigation
  • Footer or super/fat footer
    • Another example
  • Secondary navigation
• Build the secondary page templates
  • Make sure your layout works in all browsers after adding in some filler copy
• Build out the home page
• Build out important secondary pages or various landing pages

Know your browser bugs

Keep track of known issues you could encounter when building a page. The best way to prevent having to constantly cross-check everything is to stick with code that you know will work with multiple browsers. Try to not get too extravagant with your HTML and CSS. Sometimes even the code you think will work doesn’t.

When you know what bugs or differences in rendering you’re likely to encounter you can squash the bug and resolve differences before the QA cycle.

Choose a reset stylesheet that you can agree with

There are so many options out there for reset stylesheets. Many will change the font-size of all elements, which you may not want. Some will change the font-size to go with the hierarchy of tags [h1, h2, h3, etc]. You’ll be changing most of these values to match your design anyway, but what if you’re just working on clickable wire-frames?

What are some of your options?

• YUI Base - Sets default sizes for some elements
• YUI Reset - Sets all font-sizes to 100%
• MeyerWeb - Sets all font-sizes to 100%
• Blueprint - Also has helpful grid CSS for fast templating
• There are many more out there. Do your research and build your own if you want!

Options for IE6 specific issues

It can be a hassle to deal with 24-bit transparent PNGs. It’s the alpha-transparency that kills us, really. For inline images, it’s usually easiest to use something like DD_BelatedPNG. For background images that are added via CSS, always go for the CSS option: Microsoft’s AlphaImageLoader.

Both of these options run on page load, so they can slow down your page-load time. If you can avoid PNGs, stick to using GIFs. If you have no other option, approach with caution as functionality may be limited by IE6.

Some notes about AlphaImageLoader:

• The code: filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(sProperties)
  • The only part you will need to change is sProperties: src=”” and sizingMethod=""
• The src is always relative to the page that you will be viewing.
  • If the image is to be displayed on http://test.com/about/news/ and your image lives at http://test.com/images/news/transparent.png the src should read: src="/images/news/transparent.png"
  • Note the preceding /. This means start at the root directory and work your way down. Simply putting src="images/news/transparent.png" won’t work.
  • Normally in your CSS you may format the image paths relative to where your CSS lives: background-image: url(../images/transparent.png);. This path formatting wouldn’t work either, because IE6 would then be looking for transparent.png in http://test.com/about/, where it doesn’t live.
• There are three options for the sizingMethod attribute, but usually it’s best to go with the scale option. This depends on what you’re trying to put a transparent PNG background on, though.
  • scale: scales the image to fit within the constraints of the container
  • image: scales the container to the size of the image
  • crop: crops the image to fit within the container

Another issue to look out for is the use of floats, margins, padding and positioning, and a combination of the four in IE6/7. Making too many nested elements position: relative; will cause some of the items to be displayed in the wrong place, or the z-index of other elements to be completely off.

• Limit your use of position: relative; and -absolute;
• Floated elements with margin and padding can sometimes cause layout problems
• Don’t use negative margins too frequently as many browser hacks are needed to make the elements render correctly

Use browser specific stylesheets sparingly

Reducing the number of stylesheets used will make it easier to manage the site later on. However, there are many cases where you should use browser specific stylesheets, i.e. when applying Microsoft’s AlphaImageLoader, because filters will make your CSS invalid.

If there are small differences between browsers, there’s no reason to create separate stylesheets, just add them in to your current CSS using browser hacks (IE6 only: _property: value;, IE7 and older: *property: value;). Currently there are no one-line browser hacks for IE8, Firefox or Safari, although all three of these render nearly the same.

However, there are options for Safari and Chrome only, which appear to work flawlessly:
@media screen and (-webkit-min-device-pixel-ratio:0) {

    /* Safari 3.0 and Chrome rules here */

}

And there are other options for Firefox only, which require more research:
/* Firefox 1 - 2 */

    body:empty #firefox12 {

    display: block;

}
/* Firefox */
@-moz-document url-prefix(){

    #firefox { display: block; }

}

The relationship between designers and developers is too often overlooked on projects. Commonly the two teams are removed from each other and designers are asked to simply throw their work over the fence to the HTML monkeys who faithfully turn the designs into a webpage using 10,000 typewriters. At SolutionSet, the “front-end” of a website is a combined effort of three different teams; The IA/UE team does the sitemap and the wireframes, the design team creates the designs, and the HTML/CSS team takes the designs and turns them into a web page. It is all too easy to fall into a pattern of non-communication between the departments where we start to lose focus on the real people that live on the other side of the proverbial fence.

In the web industry, there is a long standing battle between the design team and the development team. One source of the conflict comes from the varying backgrounds of the designers who may have a stronger background in advertising or print rather than web. In reality, it is the designer’s job is to push the envelope and make something inspirational, drawing from a diversity of sources, not just the web. HTML/CSS developers usually make poor designers because the more experience they have with HTML, the more practical their designs become. This is another source of the conflict: the developers can feel like the designers are punishing them by building designs that have drop-shadows over gradients, multiple different homepages load at random, as well as many other interesting and creative ideas that become difficult to translate into a syntax.

The conflict can get even more heated with a looming deadline. With a few pen strokes on a Wacom tablet, huge swaths of functionality can be added to a project. Suddenly there are light boxes everywhere, stylized tooltips, special buttons, a different width for the left column on every page, and the list goes on. Digesting a PSD is a daunting task and the natural process of design approvals ensures that each page will be *slightly* inconsistent. And of course, the design needs to be ready by next week so that the back-end team can take over.

It is extremely difficult (and not always desirable) for the designer to fully consider the development implications of a specific design. The developer is also faced with the fact that they are going to need to get elbow deep in the design, inspect it with a fine tooth comb—often zoomed to 1600%—and do it fast. This can get vicious for both sides.

Designers can develop too!
First, any designer that knows the most basic of the HTML/CSS rules will already bring something special to the table. Web designers should familiarize themselves with the basic rules of HTML/CSS and interactive elements in Javascript. What bugs exist in IE6 and IE7? What are the difficulties that come with lightbox that covers a flash element? Will my developer be able to implement an ajax image gallery if he has 6 HTML pages to build in a week? With basic HTML skills, the designer can not only create beautiful designs for the web but also determine the best way to create web beauty and developer friendly designs.

Developers can be designers too!
This one is huge. Get a front-end developer into the project life cycle earlier. Get them in on the design reviews, interactive design reviews, introduce them to the project timeline, the client, and the designer. This will allow the designer and developer to communicate with each other and gain a better sense of the difficulties of both sides. Letting developers become part of the design process allows them to gain respect from the designers for knowing what visual hierarchy is just as the developers are impressed by the designer for knowing about the double-margin bug in IE. It’s important to remember that most front-end developers went to school for web design not a degree in HTML/CSS.

Module design/development
In college a web designer friend of mine introduced me to a design methodology that he practiced that completely inspired me and has since become my primary way of development. When designing, he first determines the layout of the site (Right sash, left sash, 3 col, etc), the color scheme, and builds a logo. From here he designs all of the sites standard elements. This includes h1 - h4, paragraph text, links, link hovers, ordered and unordered lists, blockquotes, tables, numbers, drop caps, forms, buttons, any elements that the site will need. Then he designs by element in a modular way. He will take the header box and start designing only the header. He will add his login form, his logo, anything he wants to go in the header. He will not touch the navigation, the body, the footer, nothing else on the page until his header is complete. Then he moves to another element, and one after another he puts together a page. This is now how I develop. Build a navigation (or whichever element is ready to develop) in HTML/CSS/Javascript, test in all browsers, then copy/paste into the main site layout. This allows me to complete element by element and keep them all separate not only in my html but on my stylesheet. Everything remains completely organized, consistently cross browser compatible, and easily replicable.

A strong bond between the designer and the developer can create an extremely efficient development cycle using this type of methodology. There is always an offset between what the designer is designing and what the developer is developing. We obviously can’t be developing the footer until the designs are complete. The idea of modular development reduces the offset. If both the designer and developer can move from element to element, both teams can nearly work in unison.

At SolutionSet—time permitting—we produce style guides after we’ve had the initial designs approved by the client. Style guides essentially distills the Photoshop document into its base elements. There will be a page describing the grid, a page listing out all of the header styles, and so on. This is also a positive step in the direction towards modular design. Style guides help catch funny situations like having 25 different header styles on a site. In general, the style guide records the intent of the designer much better than the raw PSD’s. A designer under a time crunch can make minuscule mistakes (most frustratingly page to page) that aren’t noticeable to the naked eye but make a big difference in the CSS.

There’s always ways to improve a process. The biggest challenge is trying to make common practice out of something that is constantly changing. Every project is unique, every design will be completely original, new browsers will launch. It’s a tough world to keep up with. We shall see if some of these new ides bring anything to light. If you have other ideas, please contribute.

Late last year, Google announced their intention to create a new technology which would allow a web browser (presumably Chrome) to run native, x86 machine language from the web.  They have recently put out a ‘call to service’ to developers and web enthusiasts to assist in the testing & QA efforts, and ultimately contribute to project.  Obviously, the biggest concern here is security; the ability for a web server to execute native code on your machine is a potential vulnerability.  Microsoft went down this path with Active X in the late 90’s and early 2000’s, and the result was a security disaster.  The hope here is that by virtue of utilizing the open-source model, Google will be able to conquer the same hurdles which buried Active X.

The core of Google’s release is centered around a runtime, a browser plugin, and a set of GCC-based compilation tools.  The idea is that this framework will allow a developer to produce powerful, browser-based applications that can harness the full potential of the client’s CPU, while maintaining portability, neutrality, and security.  This is achieved by incorporating a strict set of rules for writing Native Client modules.  At a high level, these rules specify 1) that all modules meet a set of structural criteria that make it possible to reliably disassemble them into instructions and 2) that modules may not contain certain harmful instruction sequences.  The approach to runtime security is designed around a component called the ‘inner-sandbox’, which prevents unintended interactions between the Native Code module, and the client’s system.  The inner-sandbox uses statistical analysis to detect security defects in an untrusted code-base, and will prevent such code from being executed.

If you are interested in getting involved, please check out the Native Client homepage at http://code.google.com/p/nativeclient/.  This site contains information about how you can help Google, as well as the source code and demo modules for downloading.  In addition, you can check out the Google Code Blog, http://google-code-updates.blogspot.com/2008/12/native-client-technology-for-running.html, for detailed information on the Native Client framework.

The other day I stumbled upon a very well put together Facebook Connect - Wordpress plugin. Given the task of finding a way to connect the two, a Google search pointed me to www.sociable.es.

Once installed, the plugin implements a widget into your Wordpress sidebar that allows users to log into their Facebook accounts and share a blog post with friends, post a blog article to their Facebook wall, share blog comments to facebook, even import registration data to the Wordpress application. The registration part is clever. As a new visitor to the Wordpress blog, a user simply click the “Connect with Facebook” badge and enters their Facebook credentials. In a snap a new Wordpress account is created based upon their Facebook profile and their profile image and other basic information is imported over.

Check out a demo at http://www.onewelcomesone.com/wordpress/  - The demo is a clean installation of Wordpress with nothing but the plugin added. The overall setup took less than an hour and could be done by anyone.

Developed by Javier Reyes, the Wordpress plugin is easily installed through the Wordpress plugin directory and immediately configurable through the Wordpress administration interface. Backed with a straightforward read-me, the plugin is installed in 8 steps. For a noob, the toughest part of the installation is probably creating a Facebook application through www.facebook.com/developers but after that, it’s all drag and drop. Anyone who toys with the two applications will love this plugin.

Check it out, install it, enjoy it. If you have any questions, leave a comment. It’s an excellent way to start boosting traffic on your blog and getting your articles spread across larger social communities.