Common Application Bugs

There’s a curious article in the NY Times about the Common Application‘s technical glitches. The Common Application is a uniform way of filling out one application to apply to many colleges, as opposed to filling out an application for each individual college.

As a web developer, this struck me as particularly odd:

As it turns out, applicants do not have, say, 150 words to discuss their most meaningful extracurricular activities; they have something closer to 1,000 characters (Max said he eventually figured this out). And because some letters may take up more space than others, one applicant’s 145-word essay may be too long, while another’s 157-word response may come up short, Mr. Killion said.

“A capital W takes up 10 times the space of a period,” he said. “If a student writes 163 characters that include lots of Ws and m’s and g’s and capital letters, their 163 characters are going to take many more inches of space than someone who uses lots of I’s and commas and periods and spaces.”

Asked why the problem had not been fixed, Mr. Killion said, “Believe me, if there’s a way to do it, we’d do it. Maybe there’s a way out there we don’t know about.”

Sounds like the folks behind the common application need to go back to middle school and learn about variable width and fixed width fonts. If they had switched to fixed width fonts in the <textarea/> and used the same number of cols and font size it should be pretty accurate. I’m guessing some designer insisted on Helvetica or whatever they are using.

That said, are they actually printing these things out? Is there no way to do this electronically in 2010?

Back in my day (2002), I was advised to go the paper route since many still felt/feared that electronic applications weren’t being fairly considered (and in some cases not processed correctly). That was also the first year public colleges could join the Common Application as I recall. I suspect I was the last class where the majority did it on paper. I guess it’s still an improvement for a technophobic educational system.

80% WONTFIX?

I hate when misinterpretations become seen as fact. Supposedly 80% of Firefox bugs won’t be fixed. That’s said to be a bad thing. Here are some realities:

  • In every release cycle, everyone wants every bug to block a release and therefore everyone is “blocker-happy”, and later in the cycle, all are changed to non-blocker status except the most critical as perceived by developers, drivers, and testers.
  • Every release of Firefox, like every release of every large software project ships with thousands and thousands of documented bugs. The overwhelming majority of which nobody encounters, or are so minor you don’t even notice.
  • This process isn’t new, it’s been happening since the early days of software development.
  • If this process didn’t work like this, there would never be a release of major software products.

A bug is either a defect or an “unintended feature”. Complex products like browsers have thousands. This isn’t a surprise to anyone who works with software on a daily basis. Why? Because every bug you fix, feature you add introduces new code, which potentially causes new bugs in other places. Even if you devote 100% effort to fixing bugs, you’ll likely never get there. That’s the nature of the game. So what makes one bug worthy of blocking? Well generally they must meet some requirements:

  • Must be reproducible and clearly a bug (not a Firefox doesn’t load ActiveX).
  • A fix must be identifiable and achievable.
  • Must be in a more visible location. It’s not effective to allocate large amounts of effort for something so obscure 1 in 10 million people will ever encounter such a testcase.
  • Must be severe in some sense (data loss, security, usability, performance, etc.)
  • Fix must not be beyond risk tolerance threshold.

or, it must be a project requirement, meaning a feature that is deemed necessary to ship the release and worth holding for (artwork for UI for example).

Every project involves deciding what bugs ship, and what holds a release. Every single one. If there’s someone who doesn’t, it means their QA is likely flawed or inadequate. Firefox has the advantage of thousands of nightly testers. This helps quite a bit not only finding bugs, but seeing how prevalent a particular bug is, and what it’s impact is.

One should note that just because something isn’t blocking, that doesn’t mean it won’t get fixed. It simply means the release won’t be held for that bug. Should someone fix it, and it’s approved, it can still potentially make the release. The key is that the fix be low enough risk that the benefits outweigh the risk of potential regressions.

If you’re still shocked by this, let me alert you to something: the product (browser, feed reader, etc.) you are using to read this has thousands of bugs. The OS it runs on, has thousands of bugs. Any alternative you pick will be the same. Pick your poison.

I should note these bugs do not get marked as WONTFIX or INVALID. They remain open. They may be fixed in a subsequent release or they may just become outdated and fixed through some other means (code is depreciated and replaced with something else, feature dropped, revamped).

Winter Break is upon us

That’s right. Final 6/6 is done. That means it’s time for 1 (6/6) Winter Break. I’ve got a few things on my agenda.

The first thing that needs to get done is a clean install of windows on my laptop. So I’ll be backing up this afternoon/evening and wiping tonight. Tomorrow I’ll start copying data and reinstalling. It should take several hours, but it’s necessary. I put it off for a while because the semester was still going on, but it’s time.

After that, reporter webtool is a big priority, I want to wrap that up, and get the second test deployed. Lots of improvements, a massive UI overhaul, and tons of tweaks, changes, bugfixes, enhancements. I’m looking forward to that.

Then I’ve got some more ‘classified’ stuff to take care of… Of course some sleep falls into this whole picture somewhere.

Overall, going to be busy, but should be fun.

Things that shouldn’t be

  • Popup Blocker UI is a yellow bar on top notifying the user. They can simply click on it to get a contextual menu with options. That’s good. XPI blocker is the same yellow bar, but you have to click on a button to get option. Should be 1 interface.
  • When you save an image to a disk, there’s no need for the download manager. It’s bothersome more than helpful. People use the download manager to track download times. An exception should be large (>500k) images perhaps. But not all images
  • Extensions, and Themes shouldn’t be listed separately in the tools menu. Should be 1 option. The dialog that opens should have 2 tabs. One for extensions, one for themes.
  • While were at it, we should have one for plugins to, since people are confused about the difference between plugins and extensions. That’s a 3rd tab. Same format. about:plugins content, but formatted for consistency. No it’s not unnecessary duplication. look at about: and the about dialog.
  • Smooth Scrolling should be enabled by default. This just ticks end-users off. They don’t see it.
  • Download Manager gets slow as heck when it’s full of downloads (100+). This delay is annoying, especially with small files that should be done in the bat of an eye. Should notify user first time they exceed the threshold, and allow them to ignore (forever), or purge.
  • Preferences (especially in privacy) should contain a little ‘?’ icon that opens up the help and takes them to relevant document ion, so they can make an informed choice should they want more info. Ideally, it should popup a specialized shortened detailed explanation of the option, and it’s consequences
  • Viewsource should show line numbers. Goes good with “Go to Line” menu option.
  • Auto-Update should have option to automatically install (at a minimum) security patches. As MIcrosoft learned, people aren’t inclined to do it themselves. Stuff like this can easily be automatic. We are asking for trouble if we don’t. People will still credit Mozilla as insecure, even if it is their fault for ignoring requests to upgrade. This should be a default, and warn if you disable it.
  • When not using auto-update you should get a dialog clearly stating if it’s a security fix. Perhaps a different color.
  • Wikipedia should be an included search option. Were looking to get end users. End users like searching stuff like that. We want them to have stuff they like. We aren’t Microsoft after all.
  • A script as follows is in the page
    <script language="Javascript" type="text/javascript">
    var $x = ‘@’;
    var $a = ‘accettura.com’;
    var $r = ‘robert’;
    document.write(‘<a href="mailto:’ + $r + $x + $a +’" title="Email Robert Accettura">‘+ $r + $x + $a + ‘< \/a>‘);
    </a></script>

    When you view source of the page, you see:

    <script language="Javascript" type="text/javascript">
    var $x = ‘@’;
    var $a = ‘accettura.com’;
    var $r = ‘robert’;
    document.write(‘<a href="mailto:’ + $r + $x + $a +’" title="Email Robert Accettura">‘+ $r + $x + $a + ‘< \/a>‘);
    </a></script><strong><a href="mailto:robert@accettura.com" title="Email Robert Accettura">robert@accettura.com</a></strong>

    That’s not right. The output isn’t in my source. The script is. Only the script. Grr.

There bugs for some, no bugs for others. Feel free to link to relevant bugs, feel free to create bugs (cc me if you do), feel free to link to this post to advocate some things mentioned. Bla bla bla. Gripe, disagree, debate, as long as it’s peaceful, and done with an open mind…. you know the deal.

Reason speaks: It’s coming together

After some insanity, and some resistance, finally some reason. The two biggest mistakes have been avoided. Not only that, they come back better than ever.

And who says design through committee doesn’t work? This was a whole community debate, and in the end we got better than if either side “won”. Improved Style Sheet Switcher.

1.0 PR1 Candidates should be backing soon.

Jesse Ruderman as usual has a great list of change on his Bigger Picture page. Awesome resource for everyone, hard to beat the work that went into that list.

Features of the future

Well, I thought I’d sit down and be a visionary for a moment, and think about what it would take for Mozilla Thunderbird/Firefox to become the ultimate product for me. A few are bugs, a few are in the process, and a few are wishful thinking. Here’s what I came up with:

Firefox

  • Take Livemark’s to a new degree. I’m thinking personal portal. As users install livemarks, and visit sites, Mozilla’s internal start page puts things in priority (machine learning). Making my start page totally feel perfect for me. It learns what I visit, harvests those sites, and makes things work just like I would work.
  • WebDAV is awesome, but Mozilla doesn’t have it. We could really leverage it’s power by supporting it. Corporations love it because it uses port 80 (don’t need to ask the networking group to open some obscure port). So no open holes, just regular HTTP. Some Asset management software already supports it, other products are starting too. One thing some have done is ‘extend’ WebDAV to support their own unique filesystems (versioning etc.). So in our case, a company could write a firefox extension to add their own stuff to it, making Firefox ideal for the workplace. WebDAV is increasing in popularity, it’s a sweet solution to an old problem.
  • Patch updates – that’s right. No more ‘download the whole release’. But the ability to download what’s changed, and install through the updater UI. We need it, badly. It would save some serious bandwidth for Mozilla.org to update a .1 release without users downloading the whole client. Especially when not every file changed. Such as 0.9 to 0.9.1 would have been an ideal time for such a situation. Download in the background, and ask to install when the user quits. Simple and they didn’t even feel it.
  • ‘Add Engines’ needs to use update.mozilla.org
  • Pressing the spacebar with ‘find as you type’ enabled, shouldn’t cause the new search bar to open. It should just scroll down the page.

Thunderbird

  • Calendar Integration – This will be big. Really big
  • PalmSync in the installer
  • MAPI bugfixes (this is a long process I bet)
  • With Calendar integration needs to be some sort of ‘landing’. Similar to what Outlook does (but without the sucking). I see something a little like for Firefox (mentioned up above). But with Mail&News taking priority, as well as Calendar integration into the system. Tell me whose contacting me, what I need to do, and make it easy.
  • Bring back ‘open in new tab’ if Firefox is the default browser.

Both

  • Firefox and Thunderbird are both moving to take advantage of things like RSS, and Atom feeds. But they are separate Apps. When users use both Apps, they should be smart and keep in sync, so I can have it all available in both Apps. If I add it in Firefox, it goes to Thunderbird, and vice versa.
  • GRE

If something here isn’t a bug, feel free to file a bug, feel free to provide bug numbers, feel free to implement one of these. cc me on any bug that’s relevant to the above list. Have more things? Let it out. It’s the only way the best thigns make it into Mozilla, is when people say what they need. Support an idea? Say it, don’t like one? Say it!

Premature Release

Well, things are pushing towards 1.0. Especially evident in a note by Ben Goodger today.

Note, this isn’t in any way meant, to start a flame war, or a “Ben Goodger$oft is evil” rant… so if you’re going to comment along those lines, just disappear and save us all the time.

I’m a little concerned, as I’ve voiced before. In particular the following quote alarms me a bit:

There is a new bugzilla nomination flag – blocking-aviary1.0RC1. We are now going to be fairly tight fisted about approvals here since we prefer to hit our target dates than become sidetracked. We would like to keep the bug list as similar in length to or shorter than what it is now. Basically we are trying to maintain feasibility. This may mean that your pet bug may be minused. This is an unfortunate consequence of project management, but if you can produce a patch and make a case for your fix, it may be allowed in.

Emphasis mine

My concern is this: Mozilla has built quite a reputation in recent weeks regarding security, and alternate browser articles. Pretty much every technology publication has mentioned it (as I mentioned earlier), often with very fond reviews in the past 14 days. That’s awesome news! It honestly is.

But with that comes some responsibility: So far, Firefox has shipped as ‘pre-release’ or ‘test’ releases. The authors of those articles note that these builds aren’t intended for production use. Just ‘technology previews’ as Mozilla.org likes to call them. And that’s great. That’s the way pre-1.0 should be.

But the second we hit 1.0, Mozilla Firefox will be viewed in a new light, and with a new level of detail. My personal concern is following a slightly buggy 0.9 release, there should be a little less emphasis on a shipping date, and more emphasis on what got us to this point: focus on quality code and end user experience. That’s what got this reputation. Not that builds are prompt and on the date.

For example, Jesse Ruderman makes a security note on his blog which is of particular interest, considering how many browser holes have been exploited in IE in recent weeks (Mozilla right now is being hailed as a ‘more secure’ alternative). Time should be taken to address, and examine stuff like this, and really make sure it’s given proper attention.

Another concern of mine is stuff like bug 154892. This effects quite a few sites. Users expect to be able to print, and get reliable output. It’s a simple, ancient function (from an enduser perspective, I realize printing is somewhat complex). But the end users won’t read/understand the bug. They just take it as ‘incomplete’, ‘buggy’, ‘unreliable’, ‘cheap’ software. That’s not how Mozilla should appear.

I’m not saying Mozilla should wait until Bugzilla clears (obviously won’t never happen). My point is simply that this mentality is a little bothersome.

As I posted in the MozillaZine forums:

But we only have 1 chance to make a first impression. I think we all know how Netscape blew it with Netscape 6. Even though Mozilla 1.0 really made up for that blunder. Many saw Netscape 6, and referred to it as ‘RIP’. Netscape never quite rebounded from that.

(perhaps the first time I ever quoted myself)

That is my ultimate fear. That negative karma associated with a pre-mature release. Apple suffered it a bit with Mac OS X 10.0. They got quite some negative feedback over DVD support, and burning support. The software itself was pretty good. Really quite good. But those missing holes were much more vibrant than the new Aqua interface, or UNIX core. They are what end users and the media focused on. That’s how they work.

Apple released 10.2 (Jaguar) a much more complete and thorough release. Covered all their bases. Jaguar did excellent. People were very satisfied with the product. Why? Because Apple had a complete product. It wasn’t bug free, it was succeeded by future versions, security patches, etc. But that maturity was valued.

What’s the moral of the story? We need some serious testing between now an 1.0 if this is going to happen. Extension Manager is extremely new, and as some have found a bit buggy still. That needs to change if this is going to be viewed as the new way to view the net.

The first impression will always be important. Mozilla’s got a high expectations to meet. The media is playing it up as a possible savior. To disappoint would be a shame. You never get to make a second first impression.

Just my $0.02.