big up your blog's font size

28 February, 2007 //
11

I noticed on Coté’s blog a few week’s ago that he was using a very big font size.  At first I thought it looked goofy, but after I while I thought to myself “damn if this isn’t easy to read!”  I played follow-the-leader and changed the default font size setting of my WordPress blog from the default 75% (normal letters approximately 10px high) to 120% (normal letters approximately 22px high).  Since then, I’ve gotten a number of compliments from friends and family who can now read the blog easier (and aren’t familiar with the browsers’ font scaling controls).

So unless you’ve got a really good reason to keep your font tiny, why not follow Coté’s lead and make your blog’s font real big?

Categories meta

eXtreme UI design

24 February, 2007 //
0

In the last week of the most recent Jazz milestone, I realized that I was running out of time to give one of the web features a UI overhaul. Jen Hayes, the primary web UI designer, had sent me a spec more than a month before but I hadn’t implemented it because I was overwhelmed by the many lines, measurements, and notes specifying the changes I was to make. So I moved on to other stuff and forgot about the UI work until the UI designers brought up my procrastination on a UI design review call with Erich. Doh!

Jen pointed out the most pressing problem (font style in form elements, if memory serves) and I said “Oh, I can change that” and one line of CSS later, the major problem was fixed. Hey, this was pretty easy! Jen mentioned a few other things and I realized that they were easy as well. Erich and the other folks dropped off the call and we decided to start a NetMeeting and try to knock out as many UI polish items we could. Two hours later we were completely done – not only had we fulfilled the spirit of the spec, we’d rethought a few spec’d decisions and tweaked a few additional items in the process of our extremely rapid iterations.

A few days later, I reflected on this and wondered why the heck we had the UI designers sending us super-detailed specs in the first place. If someone were to send me a highly-detailed technical spec on how I should code a particular feature, I’d ask them if I were being Punk’d. Yet with regards to UI design, this is standard practice. Not anymore, at least for me. The UI designers are welcome to draw up whatever specs they like, but I’m only going to do major UI work via pair programming with a UI designer.

Pair programming with a UI designer has the same benefits as pair programming something in [fill in your programming language of choice]. You can experiment, discuss, learn, and refine very quickly, and the real-time verbal and visual communication is much higher bandwidth than email and documents. This is especially true in a web environment, where you can hack CSS literally in real-time via EditCss and a screen sharing program.

This experience and another recent email conversation with James Governor on my reticence to publish a new Ajax article “before it is completely ready” has made me decide to reflect on how I can apply the principles of experiment/discuss/learn/refine to everything I do.

Categories culture, design, jazz

disciplined laziness

22 February, 2007 //
2

The other day, I thought of a clever solution to speed up an important Jazz function by perhaps 20-40% (depending on a set of environmental factors). I eagerly documented the solution in a bug report and CC’d several teammates. Several times over the past week, I almost went ahead and just coded the solution, because I was so happy with its cleverness.

But I haven’t done this.

Fortunately for users but unfortunately for my idea, the function in question already runs as fast (1-4 seconds) as users expect it to run, given the nature of the function.  So although the 20-40% improvement is certainly relatively significant, it isn’t of any practical significance to users.  After all, who cares if something that currently runs in a ‘speedy’ 2 seconds were reduced to 1.5 seconds?

So it’s been with great discipline (and a bit of angst) that I’ve abstained from writing this clever code, basically because of the YAGNI principle, which the team as a whole rigorously observes.  The benefits (0.2 – 1.6 second reduced response time) simply don’t justify these costs:

  • time to implement
  • time to test
  • potential defects (the current implementation has been stable for six months)
  • increased complexity (it’s clever, you know)
  • opportunity cost of not doing other work which is of practical use to users (backlogged enhancement requests, UI/UX improvements, bug fixes)

The reason I bring this up is because it demonstrates the powerful temptation to implement a clever or elegant solution despite the fact that it lacks a compelling problem.  I consider YAGNI to be a fundamental principle of my personal development philosophy, yet I still found myself tempted to implement the solution once I had fallen in love with its cleverness and efficiency.

So … I’ll be patient for now and my solution will remain unimplemented, but documented in a bug report.  If, over time, other system factors cause the response time to degrade, perhaps the solution’s value may increase enough to justify its costs.

Or not.

Categories culture, design, jazz

links for 2007-02-16

16 February, 2007 //
0
Categories links

the Javascript logical OR assignment idiom

13 February, 2007 //
1

I recently discovered that in Javascript v1.2 and later, the output of the logical OR operator is not simply boolean true or false, but rather:

  • the value of first operand, if the operand can be converted to any of the Javascript variants of “true” (anything other than: false, 0, null, undefined, or the empty string) or,
  • the value of the second operand

I’ve found this useful for a number of situations:

lightweight normalization of cross-browser differences

// determine upon which element a Javascript event (e) occurred
var target = /*w3c*/ e.target || /*IE*/ e.srcElement;

provide a default value

var arr = anObject.aPossiblyNullArray || [];
for (var i=0; i<arr.length; i++) {
    // do something (or not)
}

The code above is likely second nature to people coming from a C or Perl background, but when you’ve been using a language like Java for a few years, it’s easy to forget about this sort of idiom.

(idiom source: Javascript: The Definitive Guide, 5th Ed. – page 72)

Categories programming

links for 2007-02-10

10 February, 2007 //
0
Categories links

my unusual start with the Jazz project

8 February, 2007 //
1

I first came in contact with the Jazz project back in 2005 while I was working as an IT architect in IBM Global Services. A couple of IGS and Rational managers agreed that it would be a good idea if I shared with the Jazz team some of my experiences working on large IT integration projects. So I began spending 25% of my time working with the Jazz product management team.

I felt fortunate for this interaction because I was impressed both with the Jazz strategy and the Jazz team – composed primarily of the folks who created the Eclipse platform. However, I felt like I wasn’t adding as much value as I could have since I didn’t interact much with the development team, who were driving much of the direction.

I spoke with Kurt Bittner of the product management team about my concerns and he told me “You’ve got development experience, why don’t you talk to Scott Rich about joining the development team?”. To me this was a pretty wild idea, since in Global Services I’d worked hard to ‘escape’ the Developer caste in favor of architecture. But Kurt explained that in the Eclipse/Jazz team, everyone, up to the executive level, participated in technical design and even wrote code.

After thinking about this a while, I decided it was a good idea, so I spoke with Scott about working on his Jazz server team. Our talk went well and we both had a good vibe but the outcome was a bit muddy. Because no one on the Jazz development team had seen my technical skills first-hand, and because I hadn’t done active development for more than a year, they wanted to bring me on in a sort of trial period. If I did well, there was an opportunity to join full-time, and if things didn’t go well, no harm done.

At first this was quite surprising, because since I joined IBM, I’d always been a top technical performer and had a very good reputation around Global Services. But the more I thought about it, the more I realized that this was a very positive sign about the Jazz development culture. My glowing performance reviews weren’t enough – I had to prove and show my capabilities – this team would not risk bringing on dead weight. Now I wanted to join this team even more and worked very hard. So on September 14th 2005, after two months of working on a trial basis, Scott asked me to join the team full-time. This was probably the happiest moment of my IBM career. I even saved the chat:

Scott Rich – hey, still there?

Bill Higgins – yes

Scott Rich – what would you think about joining the Jazz team? 🙂

Bill Higgins – !!!!!!!!!

Bill Higgins – are you serious?!?!?!?!

Scott Rich – yep, you’re in. your final test is to figure out how to apply for JobReq #006282 in the jobs system…

Categories culture, jazz

Jazz.net

8 February, 2007 //
2

As of yesterday afternoon, a subset of the Jazz.net community site is now publicly available with some basic information on Jazz.

Also the Community page has some information on the “Building Jazz with Jazz” BoF session we’ll be doing at EclipseCon in a few weeks. If you see me at the BoF, please stop over and say hi.

Categories jazz

links for 2007-02-04

4 February, 2007 //
0
Categories links

links for 2007-02-01

1 February, 2007 //
0
Categories links
« Older Entries
Newer Entries »