Open Source Partners

Many open source companies have partner programs. Companies that become partners demonstrate a commitment to the open source software.

Partnership does not guarentee qualification or competency. Before allowing partnership to influence your selection of a company, the following factors should be considered.

In most cases, companies purchase partnerships in an attempt to gain referrals and to access support resources. One may assume that purchasing a partnership to gain referrals indicates marketing difficulties or sales problems. Access to support resources is more difficult to assess, because companies that are pushing the envelope definitely need support occassionally, but support may also mean inexperience.

Companies that claim to be active participants in an open source community should provide links to their contributions. Contributions may range from bug fixes, extensions, themes, sample code, documentation, forum support, and donations. If a company can’t quickly show how they have contributed, their claim may not be honest.

The number of sites developed with an open source application can be a good indicator of experience level, assuming the team has the maturity to strive to improve their skills on every project. Any company that claims to be an expert with a product should have at least ten sites using the application. No two projects are the same. No two clients are the same. An expert company should have experience with enough different projects that they should have learned how to best resolve the most common issues.

A company should also state clearly what their specialty is with the application. No web company is good at everything. Some are stronger in design, some are better at integrating applications, some build excellent custom applications. Any company that doesn’t clearly state what they do best, and who can benefit most from their services may not have a real strength. They may be competent in many areas, but their solutions may not be as good as other companies.

Open source service providers may only work with one application. In that case, if you have already chosen the application, and you are sure that you want to use it, the company may be a good fit. However, if you don’t have a clear understanding of the available options, selecting a company that really only works with one application is likely to force your decision to fit their skill set. For a very large project, it may be better to invest some time in researching the requirements and the best path toward meeting them, prior to choosing a provider. Single product providers may also have a more limited skillset, due to the reduced exposure. The more applications you work with, the more you learn.

Never forget that open source applications are available for everyone. Check the resumes of the people who will be working on your project. Consider the level of education and the years of experience. Ensure they are inline with your expectations. Do the engineers have Computer Science degrees? Do the designers have Graphic Design or Art degrees? How many years of experience do they have? Do their titles match their education and experience?

Remember that a company that is very comfortable with a product, has a strong team that needs little support, and delivers quality work on time and under budget has little need for partnership agreements. They can stand on their own.

Using Crystal Icons with dojo's dijit tundra theme

The link above is a demonstration of the use of Crystal Project icons with dojo’s dijit tundra theme.

Crystal Project icons allow you to extend and customize tundra. Adding icons to inputs has the following advantages:

  • Many people can quickly look at the icon and enter the correct type of data, without reading the label or prompt. Obviously, this works best with familiar data types, such as times, dates, email addresses, and search strings.
  • If the inputs are in a table, the distance between the labels (column or row headings) and the inputs may be great enough that a quick visual reminder is valuable assistance for the user.
  • Multi-lingual applications almost always benefit from the addition of images.
  • The image are beautiful, they make the page look better.

The images chosen may have been intended for different uses. It is up to the designer to select the ones that work best.

There is also some overhead involved, each additional image is another HTTP request. The easiest way to improve perfomance is using browser caching, the next step would be to use ImageMagick to create sprites.

convert +append cp/16x16/apps/xclock.png cp/16x16/apps/yahoo_protocol.png new.png

http://wirehopper.com/design/new.png

dojo / ImageMagick Gradient Generator

Choose a color, enter a length, click ‘Create Gradients’. Page will generate 4 gradients (.pngs), from the selected color to transparent, along 4 axes, in both directions.

dojo ColorPicker Demo

The above link illustrates the use of the dojo ColorPicker widget.

Select a color, font, and enter some text. Clicking Create Image will display a corresponding image.

ImageMagick (http://imagemagick.org) is used to create the image.

Notes on Building a MultiLingual RIA

  • RIAs must validate on both the client and server-side. Thus, the server must have access to validation data. In that regard, it is easier to have the server handle the language-sensitive validation and then send it to the client, rather than have all language-sensitive elements (prompts, messages, validation) at the client.
  • Application common validation should be allowed. For example, allowing a dash in names - which may not be considered part of an alphabet should be consistent for all supported languages.
  • Localization is a separate issue. It can be addressed in many different ways. The amount of time spent on localization should be carefully considered. For a limited audience RIA, localization may be addressed with screen prompts and documentation which allows users unfamiliar with the formats to work with them. This approach is suitable if the localized elements are limited or the user is unlikely to use them often. For pages that will be used frequently, localization should be considered. Localization should be consistent throughout the application, meaning if one page is localized, or one type of data is, all should be.
  • Language strings can be stored in the database or in files of name/value pairs. They should be constructed in such a way that word order can be adjusted for language, this may mean more strings or multi-word strings.
  • Language resources should be dispersed such that pages only retrieve the data necessary to support the active page.
  • Some parts of the application may be based on the native language of the server. This should be supported with documentation.
  • If it is likely an application will be multi-lingual, it should be built in from the beginning, it will greatly increase the cost of development to change a single language site to multilingual if it wasn’t built with language independence.
  • Frameworks and toolkits like Zend Framework (http://framework.zend.com) and dojo (http://dojotoolkit.org) have execellent resources. It is much better to use these as starting points than to try to reinvent the wheel.
  • Report files and any emails should also be multilingual. Ideally, these should draw language data from the same source as the application.
  • Log files need not be multilingual.
  • Templates should be language independent.
  • Images should be language independent, or language sensitive versions should be developed.
  • Flags are an excellent way to allow selection of language.