Firefox 4 status bar

On run­ning Fire­fox 4 for the first time I was shocked to mouseover a link and appar­ently not be able to see where I was going. Had they ban­ished the sta­tus bar? Of course, everyone’s just play­ing catchup to Chrome’s UI, and its sta­tus bar isn’t really a bar at all — it just appears as and when it’s needed. Perfect.

Floating status bar in Chrome - only appears as you mouseover a link

The way it’s meant to happen!

As and when typ­i­cally just means “right before you click on a link”, with the whole thing trig­gered by mouseovers. The first page Fire­fox loads when you start the browser is avail­able here — http://www.mozilla.com/en-US/firefox/4.0/firstrun/ — can you see what’s wrong with it?

I love event-listenery JavaScript as much as the next guy, but the icon on Step 2 sug­gested I’d be going to another page (c’mon, that’s just what right angle quo­ta­tion marks have been co-opted to mean on the web!) while the browser wouldn’t say where.

Before vis­it­ing any actual pages in Fire­fox, not much trust­ing it at this point, I did some quick Googling and dis­cov­ered two things:

  1. That you can bring back the sta­tus bar by sim­ply typ­ing ⌘ + / or Ctrl + /, and
  2. That, not know­ing this, peo­ple have cre­ated at least one browser exten­sion to do exactly that.

Fail.

Of course, if I’d both­ered to actu­ally USE Fire­fox for 2 min­utes – trust­ing it even though it wouldn’t tell me where links were point­ing – I’d have dis­cov­ered that ordi­nar­ily it does. Pie-faced, I retreated to blog­ging angrily about how Mozilla’s first run screen is a great HTML5 page but a hor­ri­ble ini­tial demo of the browser’s capabilities.

A few obser­va­tions from this:

  • Browsers need to tell you where you’re going next. Users don’t[/shouldn’t] trust the Inter­net enough to find out when they arrive.
  • None of this would’ve hap­pened had the team cre­at­ing the land­ing page used pro­gres­sive enhance­ment and unob­tru­sive JS technique.
  • The team prob­a­bly didn’t because they wanted to show off how well their amaz­ing browser does fancy “HTML5” (in the Jobs-ian CSS/JS inclu­sive sense) stuff. Fine, but also link to a page that has the same content.
  • Browser ven­dors are respon­si­ble for keep­ing user’s trust from the very start. This is a weird issue because it’s actu­ally noth­ing to do with the browser’s func­tion­al­ity itself, but it tem­porar­ily impacted my opin­ion on how seri­ously Fire­fox take user choice/security/usability in a sig­nif­i­cant way.
  • No-one actu­ally uses Fire­fox any­more, so it doesn’t mat­ter. It is a pain while using Fire­bug to test my own sites, though. ;-)
# by Josh Street on March 29th, 2011 Tags: , , , , , , ,
| No Comments »

Reiteration of hatred of table-based layout

You all know the story. This time around it’s table-based lay­out with some crap JavaScript rollover script that is throw­ing debug errors in IE. Whatever.

# by Josh Street on June 17th, 2006 Tags:
| No Comments »

Knee-jerk response to Flickr Gamma

Flickr’s new Orga­nizr is a huge step back­wards. It takes an incred­i­bly usable Flash appli­ca­tion, reworks it into a much-slower JavaScript ver­sion (that’s still just as inac­ces­si­ble, and who really cares about screen read­ers see­ing as we’re deal­ing with vast num­bers of pho­tos? *flame­bait*), and in the process removes use­ful graphic (as in, hav­ing the qual­ity of graphs, not graph­i­cal) ele­ments, replac­ing them with numeric date selec­tors, etc.

Oh, yeah, and they’re browser-sniffing and reject­ing any­one aside from Fire­fox, Safari, and IE. Which is ridicu­lous because Opera is so much eas­ier to get to work with stuff than Safari is… in fact, it’s one of the bet­ter behaved browsers. Mean­while, Flash would work on any­thing and so many peo­ple have Flash it’s hardly a great prob­lem. To choose between a great, usable app and a less-usable, quasi-standards-embracing, still-just-as-inaccessible app seems like it should have an obvi­ous out­come. Sigh. Why couldn’t they just focus on mak­ing the Flash thing work bet­ter? Multi-select drag­ging in the Flash UI was the last thing I really desired from Orga­nizr: beyond that, I’d be pretty much con­tent with exist­ing fea­tures. But no… they had to go tear it apart. Grrr. Just because pro­gram­mers like num­bers, doesn’t mean the rest of us do. Bring back the drag-and-drop!

p.s. Yes, I know you can get to the old ver­sion still. It’s not that so much as the new ver­sion seems like a mas­sive regres­sion with absolutely zero advan­tages, and devel­op­ment on the Flash ver­sion is going to be in per­ma­nent hia­tus (at least until they realise I am infal­li­ble and sur­ren­der in their folly, etc., etc.)

# by Josh Street on May 18th, 2006 Tags:
| No Comments »

Horrible homonyms

I’m not even think­ing of homonyms so much (though that may be true of the word in ques­tion, if you ignore sim­i­lar mean­ings) when I get upset (as I am at present) about the unten­able nature of the word “class” or “classes” (as in school/education) in any con­text where it could pos­si­bly be con­fused with pro­gram­ming of any sort.

As usual, it’s the geeks’ fault. I sup­pose classes in pro­gram­ming gen­er­ally refer to a group­ing of objects, as a class of stu­dents is a group­ing of the same… so per­haps con­text should make the dis­tinc­tion clearer. But still, waaaay too much poten­tial for con­fu­sion. Roget’s was thor­oughly unhelp­ful in this regard… “course” is inac­cu­rate, “grade” is too broad, and every­thing else was way off the mark. I think I’m going to go with “course” for the minute, at least until/unless I come up with some­thing better.

For those won­der­ing why I’m talk­ing about some­thing IT-related out­side of the murky realms of seman­tics (though this arguably relates, albeit in a dif­fer­ent sphere!), pseudo-design/browser-bug-fighting, and my all-encompassing-JavaScript-ineptitude… well, I’m play­ing with Ruby on Rails again. Or rather, prop­erly for the first time. Because, you know, I don’t think there are enough balls I’m try­ing to jug­gle already ;-) Meh. If Rails is really fast and I don’t run out of time and make this drag out for­ever (which I inevitably will… bleh) this’ll prob­a­bly take about a month. If Rails actu­ally sucks, which by most reports it doesn’t — spec­u­la­tion about crap per­for­mance for large-scale ser­vices and con­cern over the small bus-factor (if one dev mem­ber got hit by a bus, what’d hap­pen to the project?) aside — then I might give up for another cou­ple of months. Whatever!

If noth­ing else maybe I’ll learn some stuff about MVC along the way. Not bad for an Arts stu­dent, hey?

# by Josh Street on March 14th, 2006 Tags: , , ,
| No Comments »

JavaScript print_r() equivalent

It was observed today that I’m doing an awful lot of JavaScript for some­one who has no idea what they’re doing with it. Any­way, was look­ing for an easy way to do a PHP-esque print_r but with Javascript today and stum­bled across this rather-nifty func­tion.

*book­marks*

# by Josh Street on February 28th, 2006 Tags: ,
| 1 Comment »

Don’t do this on a large site

This post is actu­ally some­thing I meant to say last week, but forgot.

So I’ll say it now: Load­ing JavaScript on a promi­nent page that builds a link to a non-existent resource is a BadThing. Think ridicu­lous num­bers of 404 errors and partially-defeated sta­tis­tics track­ing! Hav­ing said that, I man­aged to man­ual work out JS/no-JS sup­port to be even lower than it is on this site — it’s 1.5% non-JS here — which is impres­sively (pleas­ingly) low!

AWstats is fun to run on many-gigabyte log­files… just not mul­ti­ple times once you’ve realised “Oh, I screwed up and no amount of grep­ping can save me now!” (First time I’ve absolutely required my dual-boot Ubuntu/XP install at work… because it’s lots eas­ier to watch load on a com­puter you’re phys­i­cally on rather than by SSH, and because multiple-GB-logfiles aren’t fun to trans­fer across networks!)

# by Josh Street on February 27th, 2006 Tags: , , ,
| No Comments »

Trapping return for form field focus

Today I had to cook up a sim­ple form with two input fields, so that two bar­codes could be scanned into their respec­tive fields and then sub­mit­ted (the point being to link two IDs in a data­base that have been encoded in sep­a­rate bar­codes). There was one twist.

The bar­code reader auto­mat­i­cally appends a return char­ac­ter to the end of the string it’s read… which would, in any nor­mal cir­cum­stance, sub­mit the form. Obvi­ously prob­lem­atic unless we split the form over sev­eral pages, which is just yuck.

If the bar­code reader hadn’t returned char­ac­ter 13 (return/enter/whatever you’ll call it) at the end of the string, it’d be triv­ial to pick up a “maxlength=x then go to next field” script off the side of the road… they’re every­where. Not so much the case with this exact prob­lem, though, so I thought I’d share…

[source:str javascript]function catchEnter(e){
var char­ac­ter­Code
if(e && e.which){
e = e
char­ac­ter­Code = e.which
} else {
e = event
char­ac­ter­Code = e.keyCode
}
if(characterCode == 13){
document.getElementById(‘cardid’).focus();
return false
} else{
return true
}
}[/script]

Note we’re not using DOM meth­ods here… there isn’t any equiv­a­lent to which or keyCode that I’m aware of (I looked enough). keycode is the impor­tant one… which is used by the likes of Netscape 4.x and other nas­ties… I don’t really want to know about it, but I stole the key trap code from some­where (lost the site) and didn’t really have a rea­son to inten­tion­ally break the behav­iour for those browsers!

So we use one of those (prob­a­bly key­code) to set char­ac­ter­Code, which is a numeric value that cor­re­sponds to Uni­code dec­i­mal val­ues. 13 is car­riage return. Then it needs to be com­pared to event (the char­ac­ter that trig­gered the onkey­press event), here used as e for con­ve­nience… and if this is true, then focus will go to the next field (in this case cardid) and the char­ac­ter will return false to pre­vent the form from submitting.

Screenshot of the demo page

I’ve got a sta­tic demo here (don’t mind the mes­sage at the top, it was an HTML mockup)… try enter­ing some­thing into the first field and press­ing return. Then press return again, and the form will submit.

Obvi­ously this Javascript only works for a two-field case… but you could dynam­i­cally set the ele­ment for focus to fol­low to by pars­ing that through to the func­tion onkeypress event. The only other thing I can think of is to getEle­ments­By­Tag­Name every input field in the form and use the array to dynam­i­cally set the “next” field… but that would have been waaaay overkill for what I had to do.

This behav­iour isn’t just use­ful for bar­code scan­ners, by the way. Desk­top appli­ca­tions often exhibit this kind of behav­iour, and it also goes some way to ensur­ing all fields are filled with­out doing for­mal val­i­da­tion (either JavaScript on submit, or server-side).

# by Josh Street on February 21st, 2006 Tags: , ,
| 8 Comments »