Firefox 3.6 was recently introduced as an upgrade to the Mozilla Foundation's popular 3.5.x version browser. A move from one sub-version of a browser to another is not generally cause for concern, as revisions between sub-versions are often slight. However, in the move from 3.5.x to 3.6 Firefox has changed enough that there are some compatibility issues with SWEB.

This document is intended to serve as a reference point for the incompatibilities as they are uncovered. The incompatibilities are ordered roughly by level of severity, though this is obviously a relative measure.

Unable to upload assets
Description: When one goes to Create > Assets or Manage > Assets > Create New asset the fields to select an asset from your hard drive are unavailable in Firefox 3.6
Workaround: none at present. Suggest the use of a different browser until this issue is resolved.

Difficulty editing forms
Description: When one goes to Manage > Form Data and clicks on the name of an existing form, it does not open for editing.
Workaround: none at present. Suggest the use of a different browser until this issue is resolved.

Unable to manage users
Description: When one goes to Manage > Users and clicks on the account of an existing user, if one is using Firefox 3.6 nothing happens.
Workaround: none at present. Suggest the use of a different browser until this issue is resolved.

As many of you may be aware, SEIU International recently launched the next version of their website.  If you have yet to see this new site, take a minute and check it out: http://seiu.org.

So, why are we blogging about the new SEIU.org, then?  Simple. To start providing information on how to interact with it - from your perspective, that of the SWEB Administrator.

The first topic, Posting Jobs to the new SEIU.org, is now available in the Tutorials section.

We expect that this topic will grow, so please be sure to check back often.  Some topics will be more suited to tutorials, others may become FAQ's - all we know is that we'll post information on new items here, as they're added.

Here on the SWEB Support Desk, we spend a great deal of time reading and writing emails, in fact, it's our preferred method of communications in most instances. Because of this fact, the clarity of the information included in your communications with the Support Desk is of the utmost of importance.

Through this posting, we hope to provide some insight into how we manage email requests, in addition to providing you with a sample of a well-formatted email request.

So, why is email our preferred method of communications, anyway...? There are several potential answers to this question, but the top three reasons are:

1. Email provides an automated path to distribute your request directly amongst the entire SWEB Support Team.
You may have heard us recommend that "all new support requests be sent to LOLv3Help@threespot.com" - this is why. When you send an email to this address, it automatically gets distributed amongst the team. There's no need to wait for one person to get back to you - your request gets placed immediately into the queue for handling by the first available SWEB Support Team member.

2. Email provides chain of authority as we work with you to resolve issues on your site.
As you might imagine, your site belongs to you - we require specific authorization from you, the administrator of the site, to help you resolve technical issues. Having all support correspondence documented in email chains allows for us to capture the required authorization to provide timely support on your site.

3. Finally, perhaps most importantly, email provides you, the administrator, with the opportunity to clearly describe the problem you are experiencing.
This last point is the most important, as our ability to quickly and accurately diagnose your trouble depends, in large part, on the quality of the information we receive along with the request for help.

To assist with this last point, we'd like to provide a sample of a clear, concise, well-formatted email support request:

	FROM:	SWEB Admin [sweb.admin@domain.com]
	SENT:	Thurday, July 31, 2008 at 2:45 PM
	SUBJECT:	SEIU4321: Article Placement Problem
	BODY:	I have an article that I want to place on the front page of my site, but it doesn’t seem to be working correctly. When I try to place the article on the page, I select the article from the list of available articles, but it does not appear on the page. The page seems to refresh, but the article is not there. The name of the article is: “SEIU Supports Union Membership" The page I am trying to place this article on is: http://www.seiu4321.org/fakepage/default.aspx Thank you, SWEB Administrator

Please note the clarity of the most important support information:

• Note the inclusion of the site and description of the problem in the subject line
  
• Note the clear statement of the problem
• Note the clear statement of expected results
  
• Note the inclusion of the URL of the item requiring assistance.
  

Please endeavor to follow the guidelines provided here - doing so will allow for us to help you in the quickest, most efficient manner possible.

At the Support Desk we’ve encountered a number of cases where Local admins report that they are unable to see certain parts of their site, or find that some functions of the website seem not to operate from inside their offices, yet when these problems are tested from outside the Local's offices, there is no trouble at all.

We’ve determined that the reason this happens is linked to the Local’s internal network configuration. Most often this occurs when the Local's internal network name is the same as the Local’s web address. Although this frequently is reported to us as an error in the SWEB framework, the error is not something wrong with SWEB; however, we do have some tips for fixing this.

Try this test to see if your network is configured properly:

1. Pull up your site.
2. Now try to pull your site up without using 'www' in the address.

If there is an error or you don't get your site when you don't use www, then your local network is likely not configured properly. You'll need to contact your local networking folks and direct them to this blog or our Support team.

A website should always be available when www is used with the domain, or when www is not used. So http://seiu4321.org should always bring up the same website as http://www.seiu4321.org.

What's happening for Locals that have this problem is that their network is set to send anything using www in the web address to a location outside their local network (consequently, http://www.seiu4321.org works), but because the domain name and the local network have the same name, any traffic not using www is assumed by the network to be internal. Consequently http://seiu4321.org does not work.

This is the reason users may get a 404 error internally, and it has been linked to a number of other odd behaviors as well, such as seeing only gray squares in the Photo Gallery, having links to blog entries not work properly, and more.

In cases where this is happening, the local network administrator will need to ensure that both the www hostname *and* the wildcard for the domain are both pointed at the external IP address of the website. We in Support can provide all of the necessary information, should there be any questions. Feel free to contact us for more details.