Category: Web Development Process

A project manager is a combination client manager, strategist, team lead, qa lead, and more–and plays an integral role in the successful delivery of digital projects. An earlier blog post, The Art of Project Management, explored the role of the project manager in a digital environment and what it takes to be a project manager. 

Many great tools exist to support those who want to learn the trade, including courses and certification through the Project Management Institute, software, seminars, workshops, and books. Each of these tools helps supply project managers with a solid foundation with which to perfect their craft. At SolutionSet, we recommend reading three books which complement these tools and are designed to help with the mindset of a project manager and to teach them how to think. Our recommended reading includes:

The Art of War

Sun Tzu’s classic dissertation on warfare is not solely about the craft of war. It also has many lessons to teach us about managing situations and conflicts. 

Each chapter is dedicated to specific lessons about conflicts from strategy and planning, through initiative, reaction and resolution. These lessons serve to provide a context for approaching a situation and provide a valuable point-of-view for reflection. Not every lesson translates and is applicable, but many are:

 “Those who are first on the battlefield and await the opponents are at ease; those who are last on the battlefield and head into battle get worn out.”

This lesson is very much about preparation and organization. Being prepared for your meeting/project/etc. and being on time, allows you to manage your work and to achieve success. Being late and not prepared sets you up for failure.

Internalizing these lessons allows us to think through situations and react in logical manners to the situations at hand, and this increases the odds of success.

A tried and true maxim about baseball is that you cannot teach running, but you can teach the rest of the skills necessary to play. However, if you cannot run, you will not be a good player. It is similar for project managers: you cannot teach analytical thinking, but you can teach the skills of project management. If you can think through situations calmly and objectively, then you are more apt to succeed.

A project manager is above else the project leader and knowing how to think through the situations at hand and how to plan for issues before they happen is an invaluable tool. The Art of War is a valuable tool for learning how to think.

Flawless Consulting

Flawless Consulting may seem to be a relic of an earlier age (I read the original version, not the updated copy) and a prime example of 1970’s pop-psychology. However, to dismiss it as simplistic pop-psychology would be a mistake. It offers us unique insights into how to read and interact with people and overall how to act like a consultant. 

We often focus on the tasks that make up the project when we are project managers, but it is the people involved: clients, staff and management which are the true challenges. Flawless Consulting teaches us to look at look at how we interact with the people involved in the process, how to understand their motivations, their verbal and non-verbal communications.  These skills are vital to the success of the project.

“Too often, we take the easy road and ignore the underlying issues.”

By taking the time to understand the people involved in the project, allows us to understand how to manage the situation.  It enables us to change the way we behave and communicate to make sure we are heard and achieve our goals. 

An important point we often discuss in our internal project management meetings is how to balance our goals and our efforts to ensure we meet our goals. A question I often ask: “Is it more important to achieve your goals, or to achieve them in the manner you wish to?” Flawless Consulting teaches us to understand our audiences and how to communicate with them in manners which ensures the outcome we envision. Being a consultant is a mindset and it is useful to know how to act like one no matter what our professional role. 

Making Things Happen: Master Project Management (formerly The Art of Project Management)

This is the updated edition of the bestselling O’Reilly book by former Microsoft Program Manager Scott Berkun. Written in down-to-earth plain language, the book offers an examination of the real world trade-offs and decision making tools for getting things done. Berkun excels at explaining both the social aspects of having multiple stakeholders, as well as technical topics of handling deadlines and constraints. The focus is on software and internet development, yet maintains a readable conversational style, and avoids geeky lectures.

Each of these books offers us valuable insights into mastering our craft.

A tour de force lasting from 9am to 7:30pm, day two of Symfony Live was packed with informative sessions and, of course, the preview release of Symfony 2.0 (which will be covered in its own separate blog post very soon).  I wrote this post based on my conference notes while on the plane back from Paris on precious little sleep, so please let me know if you find any inaccuracies. For day one of Symfony Live 2010, click here.

All of the presentation slides can be viewed online on the Symfony Live Event page on Joind.in.

Okapi and Symfony

The makers of the Okapi translation framework obtained an early copy of the Dependency Injection Container (DIC) from Sensio and undertook a migration of their product to use Symfony Components. The presentation gave some clues on the architecture of Symfony 2.0. For example, arguments will be passed explicitly to the controller (instead of the controller grabbing the request object itself). Lukas Kahwe Smith warned not to simply pass around the DIC as this defeats the purpose and nullifies performance gains. We were also given a peek into how the Dependency Injection (DI) configuration will use parameter syntax like %dsn% to avoid repetition. Symfony Events, as opppsed to the filter chain in symfony 1, can now call filters only once if necessary. They claim that migrating to the Symfony Routing component took only 2 hours to complete (plus some tweaks). After the migration, Okapi now relies more on Symfony classes than custom classes which means less code to maintain.

Optimizing PHP Code

Xavier de Cock’s presentation on performance was the most low-level in nature (from a technology stack perspective). The beginning of the talk was very Zend focused, and a bit hard to follow for a more application-focused person who is not very familiar with Zend Engine (also because of a thick French accent). Essentially, De Cock is interested in profiling an application, such as SwiftMailer, and analyzing every aspect down to the opcode in order to improve performance. In general, he discourages trying to “outsmart” the underlying opcode caching mechanism, noting that you may end up actually reducing performance. He uses Vulcan Logic Dumper to see what opcode was produced by the PHP code and employed both Xdebug and Zend Debug profilers to identify sections of code that are ripe for optimization.

Suggested tips and tricks

• Use built-in PHP functions (as opposed to your own custom functions)
• Use opcode caching (APC, eAccelerator, etc)
• Use data caching
• Optimize SQL (usually the number one culprit)
• Get your data from the 2DB in batches
• Create a PHP extension (I doubt most of us will I’ll go this far)
• Use other extensions like HipHop, Phc, Quercus or Roadsend PHP
• Pre-incrementation of a counter variable inside a loop performs better
• than post-incementation
• While loops outperform for loops
• Stay away from array functions like array_unique() (but they’re dang convenient)

Biggest common mistake: Creating memory leaks created by referencing objects in loops. This is only big deal in processing scripts like daemons (not typical web pages), and the cyclic garbage collection in PHP 5.3 provides vast improvement here.

Bottom line: the most interesting aspect of this talk was seeing what tools and techniques he used to identify slow code, but most developers should not worry about the majority of the techniques he demonstrated and just focus on optimizing database queries because that is where the low hanging fruit is.

Git 101

Scott Chacon is clearly a seasoned speaker, having done the Rails conference circuit, and the high quality of his presentation showed it. The graphics and animation in his slides are more than eye-candy; they genuinely help to demonstrate how Git works. Scott also gave a full-day Git training the day after Symfony Live, which I unfortunately could not attend. I reckon that this presentation was an abridged version of that training sans exercises. There were a lot of points that he did not have time to go into, but here are the high-level features:

• Developed by Linus Torvalds
• Used for Linux Kernel and Android
• Fully Distributed. Each clone is a backup and is equivalent
• No network connectivity needed to do work
• Immutable (never removes data)
• Based on full snapshots (not deltas)
• Commits are hashed strings (incrementing numbers, although convenient, are not used)

Parts

There are three primary working parts to wrap your head around:

1. Working Directory
2. Index
3. Repository

Workflow

In the Git workflow, there are four primary steps:

1. Edit Files
2. Stage your changes (git add)
3. Review your changes (git status)
4. Commit your changes (git commit)

Tips

If you’ve been working on a lot of different files and features simultaneously, committing a “changeset” of related edits instead of one gigantic commit is a good idea.

Random Thought by Scott

Although it is theoretically possible for two Git revision hashes to collide, it is more likely that your entire development team will be killed by wolves in separate incidents.

This presentation solidified my opinion that Git is generally better than Subversion and that it should be the SCM of choice in the future. I have been wanting to make the transition to Git as the default SCM for all of our PHP projects at SolutionSet, but existing infrastructure investments and lack of developer knowledge have been a hindrance. I hope that the use of Git for Symfony 2 will speed the adoption of Git in the PHP community and lead to SolutionSet’s transition to Git in 2010.

Writing Clean Class Interfaces with Symfony Events

Dennis Benkert, also the organizer of Symfony Day in Germany, shared his thoughts on how to reduce coupling in your classes and separate concerns. Accoring to Ted Faison, “Coupling is single greatest problem in complex system”. When different classes need to interact, a Service Layer should be used. There are two main ways to achieve decoupling (once you’ve already logically defined your classes): Depency Injection (DI) and Events. DI should be used for mandatory depencies and Events for optional dependencies. This presentation focused on Events.

Types of Event messages in Symfony

• notify - doesn’t expect a response
• filter - returns a value to the next filter in the chain
• notifyUntil - similar to a filter but stops the filter chain when a certain condition is met

When Dennis put out a call on twitter for example of Event usage, he got some useful responses such as allowing someone to override the behavior of a plugin, but the most notable was a sarcastic tweet about using Events to totally obfuscate your classes so no one else can follow them.

Event Usage Pitfalls

• Don’t use for mandatory coupling (use DI)
• There is no order to event listeners (if you are expecting this you are doing something wrong)
• Events make code harder to follow and debug
• Events can be slow once you add a lot of listeners
• Don’t use events in the model

There were a couple of memorable quotes from this talk…

A phrase that was picked up by multiple other speakers: “Every time you use sfContext, you kill a kitten”.

And my personal favorite (on the Symfony Events component mascot): “The octopus is keeping his eye on everything. Like with his arms.”

Zend Framework and Symfony

Matthew Weier O’Phinney, project lead for Zend Framework (ZF), started by saying “I am not the enemy”, and I believe him. Given the fact that Zend invited representatives of Symfony and other PHP frameworks (Cake, Agavi and CodeIgniter) to spar at the last ZendCon and the fact that Symfony 2 heavily relies on Zend Components, it appears that ZF and Symfony headed more in the direction of cooperation than competition. That being said, O’phinney still won the best tweet of the conference for saying “I enjoy the fact that Fabien is worried about spilling secrets to me”. Expect ZF to take a few pages out of Symfony 2’s playbook in the future.

Matt explained that there is really no magic to using Zend Components within Symfony; it’s as simple as adding some code for the Zend autoloader in the ProjectConfiguration class. An example of this is given in the Jobeet tutorial, but the code has been optimized to store the autoloader instance. His theory is use the best tools to do what you need to do regardless of their source, be it PEAR, EZ Components, or anywhere else.

Zend Library Standouts

• Feed Tools
• Remote APIs
• Lucene Search
• PDF generation
• Queuing
• Cloud computing

It was exciting to hear Matt talking about the Service Layer concept from Domain Driven Design. With the new flexibility of Doctrine 2 and Symfony 2, it should now be possible to design a richer domain layer within a Symfony project that includes Services, Entities, Data Mappers and a Data Access Layer (DAL). The Service layer is useful for validation and filtering, permissions (ACL) and interactions between Entities. For unit testing he mentioned 80% coverage as a good target (as opposed to 90-100%). Zend libraries can be used to easily expose your service layer as an API. I am looking forward to using this technique on a current project of mine.

Debugging Symfony

Alvaro Videla shared his experience debugging and optimizing a very large German dating site with 2 million members hosted on 28 production servers. He uses the vast amount of data that is stored in Symfony logs to identify slow areas of code by using a flag in APC to turn logging on in the production environment for a short period of time on each server and store the logs in CouchDB. CouchDB was able to handle storing 15 million log records in the first week!

Debugging Tools and Technologies Used

• AWK - for extracting log data
• avRedisLoggerPlugin - a persistent key-value database
• Tsung - a high performance, open source benchmarking framework
• XHProf - code profiler
• Graphite - a powerful data visualization tool

He uses logging to detect site outages by generating an alert if say 100 DB connection error logs happen within a minute and calls this “threshold logging”. Alvaro is also the developer of the FireSymfony Firefox plugin, which is an awesome replacement for Web Debug Toolbar except for the fact that it doesn’t work with the latest version of Firefox. Well, at least it doesn’t work for me on Snow Leopard and a lot of other people if you check the support forum.

Implementing a CMS in Symfony

When Marcos Labad set about providing a Content Management System (CMS) for his client in the publising business, he looked at the major options available in early 2009 (Sympal, Diem and Apostrophe) and decided to roll his own. Key aspects to the success of his project were great people, good communication, designating stakeholders and planning backwards.

Why Choose Symfony as base?

Active development and support Some Learning curve but good documentation Big and growing community Form framework Easy maintenance and support for the final owner Based on good practices and patterns Reusable parts Easy to integrate new engineers

Why not Drupal or Joomla? Not good for specific data models Learning curve as well May be fast to implement but are hard to maintain and extend

Tips

• Don’t forget about 301 redirects when upgrading a site
• Use Doctrine behaviors to save time

Symfony in the Cloud

Kris Wallsmith, release manager for symfony 1.3 and 1.4, is currently working on a startup called nebul.us which allows users to passively share what they are doing online (as opposed to actively blogging or tweeting about it). It seems like a powerful idea if they can make it easy enough to control what people see without making it an active process again. He made some very good points about deploying nebul.us (or your app) to the cloud:

1. You don’t need to know how the could works, you just need to know how to use it, and hosting providers like Rightscale, Amazon and others make it easy
2. There is nothing difficult about deploying to the cloud. It’s essentially the same LAMP stack you are used to.

Query Splitting

Kris put a lot of thought and into query splitting and has shared his work in the sfDoctrineMasterSlavePlugin which uses database transactions by default.

File Uploads in the Cloud

Files in the cloud will need to be:

• Uploadable to a service (like S3)
• Retrieved from a service in the view (with a helper)
• Disable-able (for the dev environment)

Deployment Tips

• Use the symlink method so you site is only down during the database migration (and not the code update)
• When using migrations during deployment, be sure to only execute once

Symfony at Yahoo!

Dustin Whittle joined Yahoo! with the assignment of migrating Yahoo! Bookmarks to symfony. Once Bookmarks was proven as a test case, Yahoo! went about migrating several more web properties, such as Yahoo! Answers, to symfony. Yahoo! Answers is the largest collection of human knowledge on the Internet (515 million answers). Clearly, a generic ORM is not going to cut it for a data store of this size, so Yahoo! only uses symfony for the presentation layer and uses web services to retrieve the data (although for smaller projects Yahoo! still uses Doctrine). Dustin makes a good point when he says, “all PHP developers use a framework, even if they don’t think so”. In other words, your non-framework based project still makes design choices that could be considered a framework. Dustin works for Rasmus Groth (the creator of PHP), who believes that you should design your application to solve your particular problem and nothing more. It was this kind of thinking that led Sensio to create Symfony 2 with much more flexibility.

Yahoo! Symfony Plugins

Yahoo! has created and shared a handful of plugins that they use to build symfony applications. They all start with a “y”, for example:

• ysfBuildPlugin (for deploying performant apps)
• ysfR3Plugin (for Yahoo!’s flavor of translation)
• ysfDimensionsPllugin (adding depth to symfony’s configuration)
• ysfYUIPlugin (for Yahoo!’s javascript library)

Tips and Observations

• Scalability is when you can add hardware and get a proportionate increase in performance
• Most performance comes not from the language, but from the design -Rasmus
• Don’t spend more time managing the cache than retrieving data from it
• Don’t use .htaccess (use regular Apache config for better performance)
• Aggregate and minify your CSS

Dustin encouraged developers to get to know the Yahoo! Open Stack.

MOST INTERESTING MOMENT: After plugging YUI, Dustin asked the room to raise hands to show what javascript framework they use. jQuery left all other libraries in the dust. Then he tweeted “It just clicked how many jQuery users there really are…”

Symfony 2

The preview release of Symfony 2 deserves it own post, which I will post soon.

For day one of Symfony Live 2010, click here.

Today was the first day of Symfony Live, the biggest symfony conference of the year and there has been a LOT going on. For day two of Symfony Live 2010, click here.

All of the presentation slides can be viewed online on the Symfony Live Event page on Joind.in.

sfPot

I don’t know if this event was named after Fabien Potencier (the leader of the symfony project) or what, but it was a good chance to drink some locally brewed beer with other serious members of the symfony community before the actual conference at Le Frog’s pub in a charming part of Paris.  I learned that Fabian thinks “Symfony 2 isn’t really an MVC framework in the typical sense”, but I’ll just wait until Wednesday’s unveiling of Symfony 2 to get the juicy details. Note: This event coupled with jet lag induced me to miss the first presentation the following day on internationalization.

Working with the Admin Generator

John Cleveley gave a useful and witty presentation on working with the symfony admin generator which included tips that are not in the documentation.  I did not know that the admin generator automatically created REST routes for your modules or the best techniques to go about creating your own admin theme.  Here are his “Ten Commandments”:

1. Understand the client’s workflow
2. Think about security from the start
3. Look through and understand the auto-generated, cached PHP files
4. Change the table_method call to reduce database calls
5. Use a custom (bespoke in U.K. english) form class for the admin if its different from your app(s)
6. Keep form configuration in the form classes (as opposed to the generator.yml) where possible
7. Create a theme or plugin to reuse your work
8. Consider users with small screens
9. Create functional tests to guard against regression
10. Maintain good MVC and decoupling practices

He also recommended the sfAdminDashPlugin and sfAdminThemeJsRollerPlugin.

Microsoft Presentation

Two representatives from Microsoft gave a pitch on the history of supporting PHP within Microsoft, the Open Source Techonology Center (OSTC) and using Windows Azure for cloud applications.

Symfony Internals

Geoffrey Bachelet quickly walked the audience through symfony’s execution of a request in a french accent so thick you could cut it with guillotine.  This was a review for advanced developers but a very useful reminder of the relevant design patterns that symfony implements such as the Observer and Chain of Responsibility.  It was enlightening to learn that returning the “Error” template is not often used since the new form framework was introduced and that the proper way to serve ajax requests for HTML is with the “None” return value in your action.

Doctrine Migrations

Dennis Benkert, the orgnizer of Symfony Day in Germany, shared his knowledge of Doctrine migrations which are largely inspired by Rails migrations.  I was pleased to learn that Doctrine now has command line tasks that will compare your newt schema.yml file to your existing model classes and generate a “migration file” for you.  This migration file is associated with a numbered and timestamped version of the database and consists of an up() and down() method which you run on your production database at deploy time.  This will replace the risky, error-prone and annoying process of having each developer maintain a SQL file with schema changes.  It is worth noting now that rollbacks don’t often work if a failure occurs during the migration and that Doctrine 2 will use a totally new migration technique.

Doctrine 2

The most exciting presentation of the day was given by Jon Wage on Doctrine 2.  With all of the talk recently about the Propel project being reinvigorated of late, this was Jon’s chance to show that Doctrine is still in the leading spot as far as PHP ORMs (Object Relational Mappers) go.  Given the features that Jon showed and that Fabien and Sensio are currently supporting Doctrine, I would agree that Doctrine is definitely the ORM to choose when starting a new symfony project or choose which one to learn.

The codebase has been completely rewritten to take advantage of PHP 5.3 and performs a LOT faster according to the benchmarks reported. Fabien requested that they “Remove the magic”, so there will be a bit more work for developers to do, but a better understanding of what is really happening and more control for advanced queries. A key feature is the separation of the ORM and the DBAL (Database Abstraction Layer). This will allow for the DBAL to used as a standalone component if desired and will allow for schema-to-database comparisons and improved migrations.  DQL (Doctrine Query Language) will be a true language with a recursive parser that builds queries and throws useful, informative exceptions.  A more explicit relationship between your model classes (based on PHP comments) will vastly improve entity inheritance, performance and the ability to write raw SQL and still get hydrated objects back as a result.

Worst case timeline for a stable release is six to twelve months.

Offline Admin Generator with HTML5 and Gears

Thomas Parisot’s offline admin generator is a peek into the future of running web applications offline.  Neither HTML5 nor Google Gears (which is discontinued) is supported enough to make this a reality for a consumer application yet…perhaps if you can force people to use a particular browser.  He did make some interesting observations about how it is possible make a javascript listener on every form that posts to the server to generically capture and locally store all of the transactions in the local SQLite database.  There are two models to choose from when designing an offline app.  The simpler approach is to have the user explicitly request to switch to “offline” mode before they lose connectivity.  The preferable, yet more complex approach is to always store transactions locally and then check if the connection is still up when moving from the local copy to the database.  Admittedly, the sample offline admin generator was more of a proof-of-concept than anything we can expect to actually use in the near future.

The Symfony Community

Finally, Stefan Koopmanschap, the current symfony community manager, gave a talk about how to properly get involved in the symfony community.  There are the Google Groups (symfony-users, symfony-docs, symfony-devs and symfony-community).  If you can’t find what you want there, then there are the IRC channels or sending out a tweet with the #symfony hashtag.  There are many local groups as well.  For example, the San Francisco Symfony Meetup group where I’ll be giving a recap of Symfony Live in the near future.  He stressed that if no one contributes, then there is nothing to be gained from the community, so please submit bugs to Trac if you find them, answer people’s questions, speak at a meetup or conference and introduce yourselves to your fellow developers!

For day two of Symfony Live 2010, click here.

Often as web developers and designers we forget that we are not a typical web browsing laymen. Even though we’ve created the handy, stunningly good looking help section on a site, a user shouldn’t have to use it. By simply observing a few users in the beginning of a project we can find countless ways to improve a site’s functionality and ease of use.

Recently one of our clients asked us to conduct usability studies to ensure that our wireframe and creative directions would be enticing and functional for their website’s users. Below is a brief summary of the two processes we conducted: focus groups and user testing.

Focus Groups

Website focus groups are critical in understanding how a site is used by a target audience and how a site’s conversion rate can be improved. By conducting focus groups on various design directions we were able to determine what our users would think and feel when they visit our redesigned site. We were able to compile feedback that can then be used to enhance the site’s user experience, increasing the site’s overall appeal and functionality and ultimately drawing in new users.

A website focus group study begins by outlining specific goals. For example, one of the goals of the focus groups may be to determine what appeals more to the target audience: images of people using a given product or just the product itself. Another goal may be to determine the response to a given page structure: Are users able to easily locate the site’s main navigation? Does the primary promo space engage the user or is another portion of the page grabbing their attention?

One of the most crucial aspects of a focus group is the selection of the participants. At this point the client has revealed the site’s target audience: age spread, demographics, etc. The number of participants for each session is intentionally kept relatively small to encourage open discussion and to promote a comfortable environment.

To ensure the conversations remain on topic a moderator is present during the entire process. Using a Moderator’s Guide, we balance the encouragement of free discussion with the underlying focus of the meeting – the outlined goals. Balancing the use of the script and free-form discussions the moderator guarantees the information received is kept relevant. Others involved in the focus group process observe the study, including note-taking and digital video and audio recording of the session.

Depending on the goal of the focus group, we are able to gather opinions about the site, including information on the site’s usage or what the participants need in order to use the site more efficiently. This information adds to the understanding of the site’s target audience, helps plan the site’s strategy, and helps to identify any areas for improvement.

User Testing

In addition to our focus groups our team conducted usability testing on key areas of functionality using a protoype. Our userbility testing involved interviewing individuals who were representative of the target audience and leading them through a series of predefined scenarios. By asking them to accomplish specific, representative tasks to determine ease of use and recommend improvements, we gathered first-hand information about how users would behave and their opinions towards each workflow.

The advantage of user testing is you learn what the target audience can and can’t accomplish, understand why users are having trouble, how to correct it, and receive direct feedback. The disadvantages are obvious: it can be more expensive to test individuals, especially when you’re dealing with multiple user types and a large number of test participants. In addition to a testing facility and moderator costs, there are also costs to recruit and compensate test participants.

Determining whether a website is compelling is the ultimate goal in user testing. During our most recent user testing session we used a variation of MultivariateTesting. This allowed us to use several variations of product pages to test the users understanding and usage of each variant.

The beauty of Multivariate Testing is that it offers the ability to isolate and assess the performance of virtually every element of a web site, landing page, or application. From page layout, to headline text, to complete color palette variations, Multivariate Testing can be highly effective in identifying what works and what doesn’t from a user’s perspective.

With our focus groups and user testing complete, we created a consolidated feedback document to pass on to the client. With recommendations in hand we allowed to client to form their own opinion of what may need to be changed and we go from there. Though the process can be extensive and tedious the results are worth it. Within one week we were able to make our site that much more user friendly and attractive to new customers.

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; }

}

SolutionSet hosted its first symfony workshop last week on October 14-16th at our San Francisco office at 85 Second Street. Eight developers participated in the 3-day (9 to 5) training exercise targeted at beginner symfony users. People flew in from as far away as Michigan and Denmark! The following topics were covered:

1. Introduction to Symfony
2. From Flat File Application to MVC
3. Actions and Templates
4. Configuration and Model
5. Model and Doctrine
6. Conclusion and Environments
7. Installation
8. More with Doctrine
9. Routing and Forms
10. Admin Generator
11. Session and Credentials
12. Unit and Functional Testing

The material was well-matched to the experience level of the majority of attendees. In the future, we hope to develop an “advanced” curriculum that would benefit experienced symfony users. The next SolutionSet training will likely be held in San Francisco in early 2010. More details about future workshops will be posted at http://www.solutionset.com/symfony when they are finalized.

This month saw the sad passing of Patrick Swayze after a remarkable fight with cancer.  I was struck by the overwhelming response and postings to this news on various blogs, Twitter, and Facebook.  It was not just the *size* of the response, but the varied nature.  Women wrote nostalgically about Ghost and Dirty Dancing.  Men shared favorite/absurd moments from Red Dawn, Roadhouse, and Point Break.  When you think about it, what other actor can claim lead roles in first-ballot Hall of Fame “chick flicks,” great rewatchable-on-cable action movies, and a top-10 SNL skit?  I can’t think of any.

What does this have to do with advice for startups?  Absolutely nothing.

I was just looking for an excuse to pour back through Swayze’s greatest hits, maybe get a new generation to rent some of his DVDs, and shamelessly look for a theme for a blog post that might get reposted.

We do work with a ton of startups here at SolutionSet and I personally have founded, worked at, raised funding for, and helped build a number of ventures.  When I get asked for advice, here are the 5 most common themes I talk about… as told through some favorite Swayze movie quotes.

Tip #1 – Disrupt from the Bottom
“It’s kind of strange, isn’t it? How the mountains pay us no attention at all.” (Red Dawn, 1984)

My advice to startups usually starts with “Have you read Clayton Christensen?”  I will pass on trying to detail the concept of Disruptive Innovation, but there is one easy lesson to take.  Some of the most successful startups are ones that “disrupt from the bottom” by introducing a new, cheaper/faster/better product into the lower end of a market. These ventures succeed because the incumbent providers dismiss the threat of this low-end offering as being “insufficient.”  Think Flip video cameras vs. Sony, Salesforce.com vs. Seibel, Open Source vs. Proprietary Software, etc.

These ventures not only benefit from “flying under the radar”, but by building a base of real, paying customers allowing the venture to move up market steadily over time as they add new, more premium features.

Tip #2 – Build Something that Does One Thing You Love
“It’s not tragic to die doing what you love.” (Point Break, 1991)

Today’s product development environment moves at unprecedented speed.  To gain traction, a company should focus on delivering a single thing that a core of customers will rave about.  Don’t worry about feature complete, worry about being memorable.  The best way to achieve this is not just find that “one thing,” but to make sure you build something YOU would love to use.  Great companies like HP, Apple, and others were built on this simple, but demanding premise.

Tip #3 - Launch Early and Ugly
“You can learn to punch in the barn, but you gotta learn to survive on the ice.” (Youngblood, 1987)

This piece of advice flows directly from the previous.  It is hugely tempting as a new venture to want to wait to launch until your product is perfect.  You’ve poured your life into this new venture and everyone you know is waiting to see it.  You want it to be impressive.  Get over it.

No matter what you think your product will be, it will be different when the market gets a hold of it.  Take a deep breath and launch with the minimal acceptable product.  People will engage with it in ways you never imagined and that data will do more to inform your product strategy than anything else.

Tip #4 – Pick Your VC Wisely
“You ain’t seen bad yet… but it’s coming” (Next of Kin, 1989)

Okay, so now you have launched and have customers/traffic.  You will inevitably face the choice of accepting venture money.  Before you read too much into my quote, I’m not reflexively anti-VC.  They can be hugely helpful in the right circumstances… but there are a few key things to know.  First, choose the specific Partner, not just the firm.  Do your own due diligence on both the person and the firm and make sure you are comfortable with the values, reputation, and focus of each.  Talk to not just portfolio CEOS, but also VPs down the chain (who often will be more willing to share honest feedback.)  But do your research; the wrong decision can be catastrophic and the right one can help you build a much better business.

Tip #5 – Beware of the Big Customer
“He’s stuck, that’s what it is. He’s in between worlds.” (Ghost, 1990)

You’ve built a Version 1.0 product and raised money.  You are now getting introductions to customer prospects you only dreamed of meeting.  Seems great, right?  Beware… many companies have died at the hands of a won deal.

Big customers mean big money.  That’s a good thing.  But they also mean big demands.  Startups can get trapped in an endless cycle of dedicating all of their resources to a single “hail mary” customer.  Instead of building a product for everyone, they get taken off track building a ton of features specific to “Big Customer” that do not help them build a product for the larger market.

The result is a company stuck between two worlds.  You are a trying to build a product company, but instead you are functioning as a professional services firm working on a “project” for a client.  If you want to build a product company, resist building for a world size of one.

* If you liked this blog post, or even if you hated it, please consider donating to the American Cancer Society.

So you’ve built yourself an email. Or banner ad. Or just about anything that mentions your URL. Interested parties have been lured to your website and they’re looking for instant gratification. Is the red carpet laid out or is the page business as usual?

Scott Brinker wrote a superb article for searchengineland about post-click marketing best practices. Brinker created a graphic that shows the eight dimensions of excellent landing pages:

You’ve got about one second to reassure your landing page visitors that their clicks weren’t a mistake, so figuring out how to make your message big, quick, and clear is of the utmost importance. Take in the full article here.

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.

We attended a webinar today, with the scary (but motivating) title “Get Ready For Combat This Holiday Season - Winning The Battle For Market Share In A Ruthless Economy”. Sucharita Mulpuru, Principal Analyst at Forrester Research doled out some recommendations for getting your eCommerce act together for holiday ‘09.

These included:

Site Experience - Your site availability should be above 99% (during 2008 holiday season, the average hovered around 96%), key content should load in 3 seconds or less, language should be the language that the consumer uses (not internal widget-focused language, as good as that might make you feel), and “add to cart buttons” should be prominently displayed. In summary, your site should be available, fast and easily understood by the shopper. Sounds like a no-brainer, but how many times have you been flummoxed by looking for the “add to cart” button?

Shipping - We can’t really talk about online holiday shopping without talking about shipping, right? According the Ms. Mulpuru’s data, shipping is one of the biggest cues for consumers, highly correlated with conversion rate. And the prediction is: this year more than ever, since consumers are going to be extremely concerned about value. So get that shipping cost down, even if it means raising the cost of products to offset the cost of shipping. Further, expose the cost of shipping early and often in the shopper’s session. One of the biggest reasons for shopping cart abandonment is “surprises” at the end, like shipping costs.

Check-Out Experience - With shopping cart abandon rate 50% and higher, there’s lots of room for improvement. A good recommendation: test your check-out flow i.e. single screen check-out vs. multiple-screen. If you’re a regular reader of this blog, then you know we’re gigantic fans of “data not assumptions”, so get your test on while you still have time to optimize before the holidays.

While we’re all basking in the afterglow of the Memorial Day weekend, it may seem too early to get started on holiday site planning. But it is never too early to implement tests, check your basics, and make a plan for improving on them. Any one of the three things above could eat up most of your time between now and the start of the holiday shopping season in October.