Source: StatCounter Global Stats - Browser Version Market Share

First of all, note that as the New York Times reports, the total number of IE users still eclipses the total number of Firefox users. Also, note the trends for FF3.5, which is gaining users, for IE7, which is losing users, and for IE8, which is gaining users. It's evident that the trends for IE7 and IE8 mirror each other pretty well, which leads to the fact that IE7 users are simply upgrading to IE8. It turns out that right now, the number of FF3.5 useres just happens to be at a higher point than both IE7 and IE8 while people are upgrading their version of IE. So, relatively soon, expect the number of IE8 users to climb back ahead of the number of FF3.5 users.

Still, it's reassuring to look at StatCounter's numbers across all browser versions. Note that total Firefox use is still gaining on total IE use:

Source: StatCounter Global Stats - Browser Market Share

In the end, what it shouldn't matter to us web developers which browser has what market share, as long as we leave behind the days of the IE6 monoculture. I think we all prefer our browsers to evolve newer, faster features, and to support web standards.

System Administrator, PingConnect
Summary: As a SaaS Systems Administrator at Ping Identity you will provide in-depth technical support and effective complex problem solving for a wide variety of infrastructure and applications related to the PingConnect service offering. VM, VPN, security, and network design is a must. Must be expert with IPsec and SSL VPN technologies. This position entails network and system design, implementation and maintenance. This is an on-call position that requires support and flexibility at a variety of hours.
Reporting to: Senior Director, Operations
Location: Waltham, MA or Denver, CO

Technical Product Manager
Summary: As a Technical Product Manager at Ping Identity, you will engage with customers to understand detailed use cases and drive requirements in to the Ping Identity product planning process for both PingFederate, Ping Identity's flagship on-premise software, and PingConnect, our expanding on-demand server. You will have the opportunity to interact with key stakeholders inside and outside of the company with a primary focus on the technical aspects of Ping Identity's product offering. You will also be one of the primary technical interfaces for third party technology and SaaS partners, understanding key integration points and combined value propositions.
Reporting to: Director of Product Management
Location: Denver, CO

Oh, and the staff hold the doors open for you when you enter or leave. You won't find that behavior at the Residence Inn.

So make sure you come, too. And by the way, feel free to use my name as the person who referred you. ;)

Chances are you could enter the first value, but the second is a little tougher to understand. It would be useful to be able to give supply an example to show you what type of information is correct, right? But how do you put in examples while keeping it clear to the user that they're just examples and need to be replaced with something else?

But what if you want labels for your form-- say, if it's technical in nature (like my LDAP server example above) and needs some extra context, or so that people know what the fields are supposed to be even after they've entered their own values? Then you can't just grab the labels and put them into the fields. You want to 1) supply example values, 2) style them appropriately, 3) make them disappear when the user wants to type their own value, and 4) style what the user types in with a normal style.

Here's a script using the jQuery library that you can use to supply this form with the behaviors we just listed:

<style type="text/css">
.example { color: #666666; }
<style>

<form>
<label for="LDAPS_URI">The public IP address or DNS for your LDAP server:</label>
<input type="text" name="LDAPS_URI" id="LDAPS_URI" value="" />

<label for="LDAPS_ADDN">AD Account DN</label>
<input type="text" name="LDAPS_ADDN" id="LDAPS_ADDN" value="" />
</form>

<script type="text/javascript" src="http://jqueryui.com/latest/jquery-1.3.2.js"></script>
<script>
function fieldExample(fieldID, example) {
	var field = document.getElementById(fieldID);
	var exampleClass = 'example';

	// If the field is empty or has the example value in it
	if(field.value == "" || field.value == example) {
		// Style the field with our example class
		$(field).addClass(exampleClass);
		// Set the field's value to the example text
		field.value = example;
	}

	// When the field receives focus
	$(field).focus( function() {
			// Remove the example class
			$(this).removeClass(exampleClass);
			// If the field contains the example text, remove it
			if($(this).val() == example) $(this).val('');
		}
	);

	// When the field is no longer has the focus
	$(field).blur( function() {
			// If the field is empty
			if($(this).val() == '') {
				// Add the example text back in with the example class
				$(this).addClass(exampleClass);
				$(this).val(example);
			} else {
				// Else if the field is not empty, make sure it doesn't have the example class
				$(this).removeClass(exampleClass);
			}
		}
	);
	
	// When the field's form is submitted
	$(field).parents('form:first').submit( function() {
			// Loop through each of the form elements
			for(input = 0; input < this.elements.length; input++) {
				// If the element is of type input and has the example class
				if($(this.elements[input]).hasClass(exampleClass))
					// It must have example text, so clear the field before it's submitted
					$(this.elements[input]).val('');
			}
		}
	);
}
</script>

To populate the fields with examples, just call the fieldExample function after the form:

<script>
// Identifty each of the fields and example values you want
fieldExample('LDAPS_URI', 'ldap.mycompany.com, or 200.200.200.200');
fieldExample('LDAPS_ADDN', 'CN=user, OU=marketing, DN=mycompany, DN=com');
</script>

All of which would add up to behavior like this:

Why won't developers make schedules? Two reasons. One: it's a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it's not going to be right?

If you're like me, and don't have the data available to do evidence-based scheduling, to produce estimates you basically make a guess based on past experience. And we all know how accurate those guesses are. (Usually, not very accurate at all. I worked with a project manager once who confided to me that all of the PMs at the company would take the developers' estimates and then double them to come up with what they felt was a more realistic schedule.) Sometimes I feel like it's like a serious job endeavour and more like a game of Name That Tune for software ("I can code that feature in... 6 hours, George!").

So around here at Ping Identity, we don't have to rely on time estimates so much. Instead, the engineering team has started using a metric called "Whitneys", measured on what we call the Whitney Complexity Scale. It's named after its creator, technical project director Brian Whitney.

Whitney Complexity Scale

Complexity = f(C#, CF, TE, K, S, U, F)

C# = Components impacted
C = Complexity of feature by self
TE = Test environment and challenge of quality needs
K = Knowledge level or not in dev team
S = Scope/impact to Ping portfolio
U = Consideration of upgrades
F = Consider that it may be only a doc, SQE solution

Now the labels of the actual scale are where it starts to get funny:

Effort/Label	Complexity Rating	Description
Negative	-1	Although we haven't started on it yet, it will be done before you ask for it.
Zero	0	It's already done, you just don't know about it yet.
Minimal	1-2	Bill's cat JJ* could do it and it really wouldn't take him very long
Easy	3-4	This is an extension to an existing feature to implement new use cases or configuration options. We can use existing test environments and add new test cases to accommodate new use cases. Requires some changes to existing sections within existing documents to describe new use cases or configuration options.
Medium	5-6	It may be a complex feature that requires quite a bit of development effort, along with a number of different configuration and deployment options to test. May use existing 3rd party environments as needed. It might be relatively simple to implement, but requires setting up a complex test environment and re-testing across multiple different options in the matrix.
Challenging	7-8	This could be a large new feature with an extensive set of use cases involving a new technology that we don't know much about.
Whoa Nelly	9-10	This is a major effort. It will affect multiple components in multiple products. Extensive new set of use cases. Must be extensively regression tested in multiple environments. Requires testing of many different options. Requires testing across multiple products or across multiple physical instances of a single product. Requires integration with 3rd party environments, including many different configurations of same.
Impossible	11	Requires an act of {the deity of your choice} to implement. It affects all Ping Identity software as well as competitor's software, as well as other 3rd party software. This affects physical properties of materials. This affects physical behavior of the universe.

* Bill refers to Bill Wood, VP of Engineering at Ping Identity

Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn't even increase security, but it does cost you business due to login failures. It's time to show most passwords in clear text as users type them. Providing feedback and visualizing the system's status have always been among the most basic usability principles. Showing undifferentiated bullets while users enter complex codes definitely fails to comply.

He claims that miscreants can still steal your password just by watching the keyboard instead of the screen, and that mistyped passwords will reduce business because of user frustration. I don't agree that either of these are worthy arguments: first, it's a lot harder to watch someone's keystrokes than it is to read off letters accumulating in an on-screen field; and second, I would guess that the amount of lost business due to user frustration over password fields is very neglible. Plus I'm willing to bet you'd lose more users if you didn't obscure your passwords because they would think your site was lacking in good security.

I do agree with one of his suggestions later in the posting, which Jeff Atwood has proposed before: adding a checkbox to the form (or dialog box) so the user can control whether the password field is masked or revealed. This setting could even be applied globally in application preferences, applied by web site, or even applied by network connection. If you're on the home network, don't mask; if you're at work, mask; if you're on an unrecognized network, and therefore probably in public, mask.