web notes - a blog

“Together Everyone Achieves More”

• It is very difficult to test a complex RIA thoroughly. It is even more difficult if it is yours. Sending the system to the users, and asking them to focus on specific areas is an excellent way to find problems you missed. Remaining focused on delivering quality software and doing a good job makes it easier to acknowledge oversights, errors, bugs, and mistakes - and fix them.
• Don’t send harsh comments or accusations. If something is wrong, check very carefully to see what is happening. Report only the facts, for example: ‘this is in the log’, ‘this sequence of steps causes an error’. Read carefully. Take your time.
• Don’t underestimate the value of the data in the system. Take great care to protect it at all times from corruption. Test the system on a different server or using a different database prior to launch.
• Respect the value of other people’s time. Don’t ask them to test anything that you aren’t very confident in. Request their help with several, specific issues, to reduce communication overhead. Offer to meet them in person if it is difficult to resolve through email.
• Use version control. Be sure that if you changed the file last, you didn’t overwrite anyone else’s changes.
• Thank those that test the code and take the time to respond, even if they find problems.
• Even if there isn’t a problem, or it is a simple piece of code, it is good to allow others to review it and suggest changes. Whenever possible, make the changes.
• Avoid scope creep by adhering to written and recorded content. email and verbal changes that have been agreed upon should be entered into a defect management system. This ensures the details aren’t forgotten and also serves to limit the scope of changes when the work is done. Use the ids from the defect system to be sure everyone knows which issue is being addressed.
• Use neutral colors and be courteous in email replies. Many people perceive red text and UPPERCASE as harsh, even if the content isn’t. Blue, green, purple are better choices.
• Remember that it isn’t ‘your’ code, it belongs the the company or the client, whoever is paying your salary. The objective of the project isn’t to produce software, it is to provide a solution to a need or requirement. Strive to find the best solution.
• Give credit for good ideas from others.
• Test plans are excellent resources. They don’t need a specific template. Any way that you can comfortably explain what to do, and what should happen is find.

Notes on using a dojo/RIA web interface to launch background (server-side) scripts.

• File uploads can run under FF and IE with dojo.io.iframe.send, and it is a nice interface. There is another post on this blog, with sample code.
• Synchronizing background server tasks with client launch and monitor requires the client to be able to identify script failure to execute, execute reporting whether the operation was successful or not.
• Two-phase, asynchronous execution can be made much more secure by storing the second-phase action on the server. Thus, if the first-phase executes correctly, no information is required from the client to continue the operation. All data submitted can be disregarded.
• Success or Error can be indicated with HTTP headers in cases where no data is required on the response.
• Client-side redirects can be used to transition to the next phase after a successful run of one phase.
• User should be alerted that scripts initiated through the web interface cannot be stopped (unless a mechanism is provided).
• User should be able to return to a previously initiated scripts and view the output.
• Background script output should be delivered to the initiator through an email. User should be able to suppress email.
• Background scripts should deliver output in text only.
• Server must be responsible for state management. Server must ensure background scripts do not collide with each other, or the data, and must provide an interface that allows the client to determine if administration should be readonly or prohibited when specific scripts are executing.
• Server must be responsible for scheduling resource intensive tasks to prevent service interruptions.
• An object is an excellent way to allow a single dialog box to submit data to different scripts without writing additional code. The object is then assigned to the AJAX content property.
• Server must have intelligence to adjust state of client, for example hiding informational messages after termination, enabling buttons to allow continuation, and providing alerts for errors.
• Initial error reporting can be limited to ‘Error’, a simple indication that something went wrong. After testing, common errors should be delivered with additional explanatory text.
• Balance distribution of client side code. Although it is nice to split a page into many components that can stand alone, this increases the number of HTTP requests which has performance impacts. Building the javascript into a single file is one solution, bundling related code together is another. Templates should include only the elements that require template processing. Large sections of javascript should be removed. Use caching to improve performance.
• Break server side code into components such that only the code required to execute is read. This doesn’t always work out perfectly, and there are impacts to opening alot of files as well, but the server impacts are less serious than the client side, because there is no data transfer.
• Put some timing code into the application so you can see where the time goes. Use YSlow to improve page delivery performance.
• Use FireBug to monitor traffic between client and server.
• Use a log file to write out debugging information. Check the error_log frequently. Use echo, var_dump, and exit. Build graceful error reporting into the application from the beginning. This will make debugging much easier. Log all errors. Put a switch in to allow debug displays to be suppressed for production systems.
• Use a tee (*nix command) to pipe script output to a file and into mail.
• Document the entire process and describe it to the appropriate people. This will ensure you understand what is happening and that it is what is supposed to be done. Be ready to change.
• Write a good test plan and use it.
• Be mindful of security. Validate all inputs. Escape all command line parameters that are user submitted. Check for access privileges for all requests, at all times. Avoid divulging application details or data.
• Copy script output to a temporary access area, do not grant access further into the server for output display. Identify script output with the script name and session id.
• Have Apache execute as apache:apache, or nobody:nobody, and allow only those scripts that should be executed through the web to have execute permissions for that user.
• Be persistent and creative.

Many web companies focus on SEO to generate traffic for sites. One may argue that SEO is used to define the contents of the content with an objective of enhancing the position of the page or site within the result sets of search engines.

Using a list of keywords expected to deliver valid site visitors, then building the content around them, is reversing the priorities.

If site visitors arrive at the site, the content is what they will see. The strategy that brought them there is transparent. Poor content won’t compensate for high traffic.

A site’s content should be carefully chosen to reflect the company’s mission, the site’s mission, the products and services, information available. Although the technical aspects of page construction should be in compliance with the recommendations of the search engines (for example, the use of title tags on links and images), link based navigation in addition to javascript controls, proper use of title and header tags), the focus should be on welcoming the visitor with a professional, informative page - regardless of entry point.

The layout of the page should support the content by offering an attractive page. It must consider the types of devices it will be displayed on.

Recommendations

Have the entire marketing team learn about SEO. It is vital that they understand SEO so that they can avoid any pitfalls, before developing content.

Answer the following questions, provide the indicated information:

• What is the mission of the company?
• Are there special characteristics or qualities of the company that make it different from others?
• What does the company do?
• What are the products and services? Include alternatives, to help site visitors understand what the company offers, what the other options are, and the advantages and disadvantages of each.
• Approximate pricing data. Site visitors should have a ‘ballpark’ figure of what things cost.
• What is the objective of the site? A web site can’t be everything to everyone. A good start is a clear collection of information to help a site visitor decide if they would like to contact the company. Chasing complex applications like social networks may not have any advantage.
• What is the target market?
• Are there situations the company would like to avoid? For example, a company with very talented engineers may want to avoid small projects because the overhead makes profit difficult. Although this information probably won’t be on the site, understanding it will help tailor the content.
• What do the competitors’ sites look like? Understand what people will see as they search for businesses like yours. Learn from them, features that look valuable, issues that should be avoided, etc.
• Examine the current site statistics and SEO metrics to see what pages people are viewing. Save this data and use it as a benchmark. This allows the effect of content updates to be quantitatively analyzed.

Most people will not watch complex Flash videos, it may be better to rotate a series of simple images or use a simple Flash video to bring the page to life.

When people arrive at a site, they are interested in what you can do for them. They are less interested in what you have done for others.

Be honest in the list of skills, products, and services in your arsenal. A huge list of skills and experience implies either that the company has many employees, very high turnover, an inflated opinion of itself, or considers exposure the same as experience. The web is fairly specialized, it is better to be able to do a few things well, than many things poorly. Be specific, ensure the site visitor understands what you are good at and why it makes your company a good choice. Clients do not want to fund training, education, or learning curves unnecessarily. Don’t imply that your company loves a challenge. Every project should be a challenge to excel, but it should be to advance existing skills, not start from scratch.

List active and direct clients only. If you were a subcontractor on a project, it is unfair to claim the end-client as a client, unless the end-client is fully aware of your company’s involvement and contribution. Inflating your credentials with the prestige of others is wrong and unethical. State only the work your company performed, it is also immoral to claim performance of work your company didn’t do.

Provide an integrated search so people can quickly find information.

Make it easy to contact the company. The contact link should be easy to find, and if there is a form, it should be easy to use. If the volume of contact traffic is significant, offer FAQs and integrate knowledgebases to allow site visitors to get answers immediately. Consider online help or chat features.

Tell about all the people in the company, not just the CEO. It can generalized, listing the technical teams and skills, or personalized with names, images, and brief biographies. This helps site visitors see who you are, and transforms the impersonal text on the screen into a visual impression of your people.

Testimonials and references have limited value. No one is going to post a negative reaction to their work.

Be sure the page loads quickly enough for the majority of the target audience. People abandon slow pages very quickly.

Make it easy for potential candidates to find employment opportunties, but don’t place career opportunities on the home page. It may be interpreted as an indication of growth, but it can also represent staffing shortages or high turnover.

The tone of the site content must be established. If it is a professional organization, the tone should remain professional through all content. Attendance at conferences should be presented in terms of what the company contributed and gained. It shouldn’t look like a vacation post or an adventure. Informal content in blogs or other posts should be avoided entirely. It is too difficult to predict how people will interpret or perceive the authors based on simple text posts.

If the site is extremely large, use subdomains to break content and features into logical areas.

Support resources should be easy to find and navigate through.

Viral marketing, the use of interesting, interactive content which can be shared with others through links may soon be relegated to the same status as forwarded joke emails - where many people disregard them entirely. Although many people consider the web a place to have fun, a business site striving to attract clients should avoid attempting to entertain people, and focus on informing those that are likely to become customers.

Demonstrations and sample services are extremely valuable, especially for software. Site visitors should be able to login, push some buttons, edit some settings or material, change colors, see the features, to understand the products better. Even if you must purchase additional licenses for software to support this, or develop a small amount of supporting code, the investment will probably be extremely cost-effective.

If you choose to avoid technologies, post them on the site with a discussion of why your company is not using them. This will serve to educate the site visitor, and may reduce calls from people who would be better suited for other companies.

Make it clear that the company is selective about its clients. This creates an elitist attitude, people may perceive the company as more valuable because it is not willing to work with anybody, only those which meet certain criteria. If they don’t meet the criteria, they may not be well suited as clients anyway.

Instead of distributing content in informal formats or places such as Facebook, MySpace, it may be better to focus on the site itself. If Facebook and MySpace are used, the content should be synchronized, both in quality and chronology, with the site.

Open Source software is often maturing.

Cycling back to the distribution site has many advantages:

• Upgrading open source components usually delivers many bug fixes and new features. Although upgrading after ever update is probably unnecessary, it is worth considering an upgrade if something isn’t working exactly as expected.
• Upgrading increases the lifespan of your code, as well as often improving the quality.
• Documentation often improves, both directly from the author and with contributions from other users. Repeat visits usually increases understanding.
• As new features are added, they can be integrated into your code.
• As you learn more, you can contribute to the site.

Cycling back through your application also has many advantages:

• As your skills improve, your code will, too. Revisiting code allows you to improve it.
• Look for ways to consolidate and reuse code. The less code you have to maintain, the better. Overly complex or large applications are often more difficult to work with than sleek, elegant systems.
• Validate XHTML and CSS periodically.
• Use jsLint, and other tools.
• Run the pages through different browsers after major changes.
• Keep an eye on the architecture, understand what goes where and why.
• Add comments for things that are difficult to understand.
• Look for opportunities to improve performance.

dojo’s Fisheye widget is fun. The link above is to a demo of the Fisheye widget.

Notes:

<div dojoType="dojox.widget.FisheyeList"
itemWidth="50" itemHeight="50"
itemMaxWidth="200" itemMaxHeight="200"
orientation="horizontal"
effectUnits="2"
itemPadding="10"
attachEdge="top"
labelEdge="bottom"
conservativeTrigger="false"
>

itemWidth and Height refer to the images when they are displayed initially, before the mouse hovers over them. You can use them to size the images as they are displayed.
itemMaxWidth and MaxHeight refer to the images when they are active or the mouse is hovering over them.

For best results, the images should be MaxWidth and MaxHeight dimensions, or larger. Images usually look better after they have been reduced, rather than expanding a small image. It is also easier to use square images, and make all the images the same size.

Check the CSS carefully if you find your list wrapping down to the next line. I found using min-width was helpful.

Credit/Thanks to:

http://dojotoolkit.org/demos/fisheye-demo
http://www.ajaxdaddy.com/demo-dojo-fisheye.html