Archives

Occasionally, in-between the latest iPod rumors and stupid top-10 lists from Cracked, Digg coughs up the good stuff. Case in point: today’s post about Firefox 3 Beta 1. So far it’s only available for Mac and Linux, and the download directory includes the following "IMPORTANT NOTE":

These files are not release versions, they are just potential release
versions. Use them at your own risk, without any of the warnings that we
will be putting in the release notes.

To be honest, if you’re here from Digg or something similar, we’d really
rather you waited until 3.0b1 was officially announced, so the servers
don’t get overloaded and we don’t have a bunch of extra work to do.

Because I’m a bad citizen – and because I didn’t see the note till afterward – I downloaded the beta and installed it on my Macbook Pro. All my extensions, of course, got disabled immediately. Still, I’m already impressed with the interface improvements. The Places concept looks promising. The bookmarks manager is VASTLY more useful and intuitive. And the download manager, though a little iffy on usability, has some cool new bells and whistles, especially the ability to interact with your downloaded files from within the manager itself.

Also, strangely, dropdowns and other form elements now have the native Mac OS look-and-feel: rounded corners and all that jazz. Is this is new feature, or just something that was always there but hidden by my extensions?

Technorati Tags

• Firefox

Share/Bookmark

Too often, the overarching requirement we hear from clients is that the product must be simple to use. As designers, we nod our heads and agree that yes indeed, simplicity is a worthy goal for this project, without ever defining what is meant by simplicity.

At the opening night of the DUX07 conference, B. J. Fogg, from Stanford University’s Persuasive Technology Lab, talked to us for a bit via video about his recent explorations into simplicity. What exactly does simplicity mean? What are the determining factors of simplicity, i.e., what am I looking at in order to rate whether or not a product is simple to use?

To Dr. Fogg, simplicity is not a characteristic of the product but rather a perception of the experience. From his studies and research, he’s determined there are six elements of simplicity:

• time – can I spend the time learning to use a new product? no? then it’s not simple
• money – can I spend money on a new product?
• physical effort – does it require exertion beyond my usual effort?
• brain cycles – do I have to think for a long time?
• social deviance – does it go against the social norm?
• non-routine – does it break my routine?

These six elements vary by individual and by context and there are trade-offs. For example, if I’m a college student who has time but not a lot of money, I might be more willing to invest my time in learning a new product than, say, a business executive who doesn’t have the time but would be more willing to spend a little more money on a product that doesn’t require a lot of time.

Simplicity, therefore, is a function of the user’s scarcest resource at the time. To state it another way: a product, task, etc., is truly simple until it requires a resources that’s not available. But remember, Dr. Fogg said that simplicity is determined by the perception of the experience. Which means a task can be perceived as simple if it uses less resources than expected.

Now I’m not saying that from now on we market our products by setting the expectations high to guarantee the perception of simple …. but it sure is tempting.

Technorati Tags: Design, Information Architecture, Usability

Share/Bookmark

Over the weekend my Gmail finally got upgraded to the new version. (I know, I know, a week is hardly a long time to wait for a slow-rollout Google feature. But I’m impatient.) I have to say, the history and back-button support is AWESOME. It’s funny that Gmail warns you in a huge red banner to disable Firebug. I, of course, kept it enabled and immediately began digging through the DOM of the new UI. As usual, most of the JavaScript is so obfusticated that it’s hard to tell what’s going on. Still, it’s interesting to dig through layers and layers of iframes and nested divs and see how much DOM hackery is involved. Looking behind the scenes at any commercial-grade webapp is like taking a tour of a sausage factory.

Luckily, I have a strong stomach. I’m going to make it a weekend project to really dig in and learn how they’re handling their history support. In a previous post, I wondered why the new Gmail is only available for Firefox 2 and Internet Explorer 7. Given my own experiences with Safari’s history object, I shouldn’t be surprised. With bookmarkable URLs and history management so central to the new Gmail UI, no wonder Safari has been left in the cold; it’s simply too buggy in this regard to receive A-grade support. Safari users have been complaining to Google that it should fix Gmail for Safari even with the old UI. I think those complaints should be lodged at Apple, not Google.

P.S. Sure enough, leave Firebug open in Gmail for any length of time and your Firefox will slow to a crawl. My FF has been crashing a bunch this week, but I’m not sure whether it’s Gmail or Firefox’s own latest updates. Commenters, am I the only one seeing this?

• Gmail
• Google
• Safari
• Firebug

Share/Bookmark

I love browsing Lambda the Ultimate, the "programming languages weblog," because it makes me feel stupid. There’s nothing quite as educational for an undergraduate as hanging out with some grad students and finding out just how much he’s still got to learn about his chosen discipline. That’s how I feel when I read Lambda. I might not "get" everything, but I always come away with a bunch of stuff to look up and explore.

Lo and behold, today’s Lambda post delves into ECMAScript Edition 4 and Backwards Compatibility. I posted yesterday about the ECMAScript 4 brawl, but trust the folks behind Lambda to sidestep the drama and focus on the actual impact the proposed changes would demand of existing JavaScript programs in the wild. Of course, the paper the article links to comes from Adobe Systems, the Mozilla Foundation and others who’ve been playing a major or supporting role in the aforementioned drama. Still, it’s packed with useful information for those who haven’t made it through the draft language overview or given the reference implementation a spin.

• JavaScript
• Mozilla
• Adobe

Share/Bookmark

It’s always interesting when the wider tech media picks up on a turf war that would otherwise be visible only to its participants, their peers and the followers of obscure programming blogs. Ars Technica and Slashdot are now reporting on ECMAScript 4/JavaScript 2 dust-up that’s been big news on Ajaxian all month. These fairly insidery sites aren’t losing too many of the story’s nuances. But several more generalized IT publications have picked up a story from IDG News Service’s Chris Kanaracus that reduces it to a "Mozilla vs. Microsoft" thing. Even Slashdot and Ars Technica can’t resist the easy headline:

• Ars Technica: Mozilla, Microsoft reps argue over the future of web scripting
• Slashdot: MS, Mozilla Clashing Over JavaScript Update
• Computer World: Mozilla, Microsoft drawing sabers over next JavaScript
• Info World: Mozilla, Microsoft drawing sabers over next JavaScript
• PC WorldMozilla, Microsoft At Odds Over Next JavaScript

From where I’m sitting, the headlines tell only part of the story. Yahoo’s Douglas Crockford has very reasonable concerns about the future of browser security, but that’s getting left out of most of the coverage – mostly, I imagine, because it isn’t as sexy as open letters and blog bitch-slaps with an easy "David and Goliath" subtext. Meanwhile, plenty of everyday developers have strong opinions about the proposed spec, and they’re the ones who are actually going to be using the language – whatever it becomes.

The Slashdot and Ars Technica forums provide an interesting vox populi on the issue. But for pure entertainment value, you can’t beat the comments over at Ajaxian, particularly the first comment on this post, by someone called Roustabout, which adds colorful though NSFW metaphors to an already, um, sticky debate.

Technorati Tags

• JavaScript
• Mozilla
• Microsoft
• Yahoo

Share/Bookmark

The Great Lakes Software Symposium (aka No Fluff Just Stuff) is coming to Chicago November 16-18th, and if you are a java/ajax/agile developer or manager you should really check it out. I went for the first time last year and it was great. With the amount of relevant and interesting sessions they have, I could have gone to the Milwaukee one the next week and still not made it to every session I wanted to.

  Why is it good?

1. No Fluff, Duh! – This means there are no B.S. artists there trying to pitch their half-baked, proprietary, "silver-bullet", junk.
2. Best of the Best – the people that present are top-notch practitioners, and more importantly top-notch, well practiced presenters. (Its one thing to be a smart guy who knows how to write great code, but to present it and really "Teach" the audience is a different skill set)
3. Fair price- Compared to other conferences, the NFJS series is very reasonably priced (particularly because its close by). Also a $100 discount for alumni!! combine that with the early registration
   deal (which has passed already for this year), and you are down to a
   very good price.
4. Great networking – I’ve seen a fair amount of some of Chicago’s finest developers at NFJS, and found it to be a great way to meet people from other companies (its good to find out which companies sponsor the cost, and which ones don’t)
5. Relevant topics – The latest on Ajax, Agile, Spring/AOP, Groovy, Ruby/Rails, and overall development best practices.
6. Door prizes – last year a friend of mine won an Ipod. This year they have more iPods, iPhones, Sony PS3.

All in all its a good conference at a good price, and even in the cases where it covers a topic you know well, there are always good things that come out of the discussion. There is a cool energy in the air when you go to a conference like this. Amazing ideas are thrown around, groups of people huddle around a laptop trying out new ideas, and you leave the place really excited about development and eager to try out some new ideas.

Hope to see you there!
-John

Share/Bookmark

In the rush to develop entirely new Web 2.0 systems based on Ajax, it is often easy to lose sight of how it can be used to improve the so-called “legacy” enterprise systems. Over at the Ext JS blog, there’s a post about German developer who put together a reporting/BI application to front-end RPG code running on an AS400.

The backend serves up JSON data (together with this old article about reskinning a Spring MVC application with Tibco GI, it makes for a solid approach for refactoring existing webapps) to the Ext JS/Flash front-end. Slick. You can view a demo (unfortunately in German for you non-German speakers) here.

Technorati Tags: ajax, ext js, as400, flash, json

Share/Bookmark

It turns out I’ve been following agile principles for longer than I realized. Back in the early 90′s, I was living in a grad student coop at the University of Chicago. The house manager — a 50-year-old physics Ph.D. who handled all of the plumbing, electrical and other assorted house maintenance — had decided to leave. In a house populated with humanists and social scientists, all eyes turned to me, the lone "scientist." I didn’t bother telling them that computer "science" isn’t really a science, and to top it all off, I was studying mathematical comp. sci., which meant I was a fair hand at Combinatorics, but I couldn’t tell the business end of a soldering iron from a ground wire. Still, I had helped my dad install some drywall back when I was in junior high (mostly I held the drywall in place, while my dad did all the work), so I agreed to be the new house manager.

I set two conditions, however. First, I was not going to live in the house until I was 50, and second, we would have two house managers, whose terms would overlap by 6 months. An early form of pairing. As a result, I and my pair house manager did not feel as overwhelmed as we might have if each of us had been on our own. Further, we shared information, documented it and now, over 15 years after I introduced pair house managing, the coop still uses the practice to good effect.

I know I have mentioned my 4 commandments of Agile development: iterative development; pair programming; test driven development; continuous improvement. It is hard to point to a "most important" one of the commandments — as far as I’m concerned this is really the bare minimum of what is necessary to practice good agile development — but pair programming seems to be the one that is most often left on the cutting room floor. The excuses are endless: "we don’t have enough people," "we have an odd number of developers," "we have too many tasks to pair." The list goes on and on. For anyone that has practiced pair programming, the only objection that holds water is the "odd number" one. It is hard to pair with 3 developers, and rotating pairs or three-somes don’t work so well — someone is always the odd man out.

So what does pair programming give you and why and how does it work? In their hilarious article All I really need to know about pair programming I learned in kindergarten (May 2000, Communications of the ACM, Volume 43 Issue 5), Laurie Williams and Robert Kessler describe some of the reasons for its success. First, in a survey of developers they found that overwhelming majorities of developers were more confident of their solutions and enjoyed their jobs more. Happier programmers produced better solutions, no surprise there. But the fact that stereotypically introverted developers would enjoy a more social, collaborative work environment seems counterintuitive.

According to the article, another key benefit of pair programming is the constant code review that it provides. As it turns out, developers working in pairs think of twice as many solutions and work more than twice as fast as two developers on their own. Anyone who has seen the parabola of bug fix expense in action, i.e. bugs are much more expensive to fix the further you get toward deployment, will appreciate how valuable this constant code review is.

The article goes on to describe some best practices for pair programming, couched in kindergarten term — "share everything," "clean up your mess," "play fair," "don’t hit people." One principle that I adhere to, and that the article mentions, is that it is permissible to work alone for up to 50% of the time — "nap time." I’m not really an advocate of the "one monitor, keyboard and mouse approach," but rather prefer the shared desk model. That way you can collaborate, but are not exhausted by the constant engagement that the shared terminal forces on you.

One additional benefits of pair programming that I’ve observed is that developers reach their potential more quickly, i.e. they move from junior to senior to architects or leads more quickly. They learn from others (got to keep switching the pairs from iteration to iteration), they get to make decisions on design and architecture instead of taking dictation from a tech lead, and they feel empowered. No wonder they progress and learn more quickly than developers working along.

Back in the mid to late 90′s when I first tried to introduce agile methods on Wall Street, pair programming was the practice that garnered the most pushback. I usually convinced skeptical managers by convincing them that developers would spend less time surfing the web. They nodded knowingly and agreed to give it a try. I got my way, but for the wrong reasons — managers didn’t trust their developers. That points out another agile principle that fits hand in glove with pair programming: trust your people. Or, as the Agile Manifesto puts it

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

These days, I have a much easier time of selling pair programming to clients, which is all to the good.

Technorati Tags: agile, pair programming

Share/Bookmark

Songbird, the open-source, Mozilla-based media player, received its 0.3 "developer pre-release" on Oct. 30. The UI hasn’t changed much since the 0.2.5 "developer preview," but things continue to evolve under the hood. Better yet, the documentation and demos keep getting better. Check out the developer center for information about using XUL to build add-ons or using the JavaScript API to integrate your webapp with Songbird’s media player.

If you’ve yet to experience Songbird, a little background is in order. The project is run by Pioneers of the Inevitable, a Bay Area company founded by veterans of Winamp and the Yahoo! Music Engine. Building on Mozilla’s XULRunner platform and the VLC media player, Songbird aims to unite a web browser, a media jukebox and an online media player into a skinnable, extensible, open-source application. At this stage, the app is a long way from challenging the likes of Windows Media Player, let alone iTunes. But as it grows, it promises to cultivate the same kind of fervent user and developer communities as Firefox, Thunderbird and other Mozilla projects.

I first became aware of Songbird via a Boing Boing post. I’m surprised it hasn’t generated more noise in the various Ajax feeds and news sources. With all the excitement about specialized browsers and desktop webapps, from Mozilla Prism to Google Gears and Adobe AIR, it seems like Songbird would be earning a lot of buzz. Maybe I’m just not hanging out at the right water coolers.

As an Ajax developer and huge music nerd, I’m looking forward to playing with the JavaScript API. It promises seamless integration between webapps running in the Songbird browser and the media player itself. Imagine iTunes, but instead of a built-in browser that only supports the iTunes store, you’ve got a Firefox clone that plays well with music vendors, P2P networks, MP3 blogs and any other internet music resource. Visit a music mag, for instance, and see all of its featured downloads automatically show up as a playlist in the media player (as in the Hype Machine example above). Visit an online music store and experience an iTunes-esque purchase experience. Indie-music brands such as eMusic and the aforementioned Hype Machine have already gotten on board. To see Songbird’s API in action, compare these sites in Firefox and Songbird.

Songbird’s add-on ecosystem is cool, too, especially for long-time Firefox developers. They can adapt existing add-ons with just a few tweaks. (GreaseMonkey, for instance, has already been ported.) But Songbird’s API allows for more radical innovation than Firefox’s add-ons. Instead of simply adding context menus and pop-up dialogues, you can rewire the entire UI of the media player. One example on the developer site shows how to replace the single play/pause button with individual play, pause and stop buttons. That’s a trivial example, but a telling one.

I’m already salivating about the cool stuff I’ll be able to do with add-ons:

Tag-parsing madness

Imagine Doug’s AppleScripts for iTunes ported to XUL. Like a lot of people, I’m obsessive about my meta tags, and I can’t wait to use JavaScript regexes to bend them to my will en masse. I’m also hoping that Songbird will record all of its meta data in the music files themselves instead of socking some of it away in the music library. With iTunes, if you decide to rebuild your library in another player – or even in a different iTunes installation – you lose things like star ratings and play counts. It’s a real bummer.

Huge libraries

The flat XML database in iTunes scales horribly. Get above about 100 gigs of music and performance slows to a crawl. This problem has only gotten worse with the bloat of Cover Flow, Quicktime integration and all the other features I don’t need. I have 450 gigs, most of it ripped from my huge CD collection, and I’ve had to separate it into four separate libraries (using Libra) just to get decent performance. That sort of defeats the whole "any song at any time" promise of the MP3 era. Enter SQL Lite, which is how Songbird stores its own media library. I’ve got high hopes that a relational-database back end coupled with open-source how-to will make Songbird the media player of choice for folks with enormous libraries.

Interface freedom

iTunes and its Smart Playlists are all about endless, automated mixes. But I’m an old-school mix-tape guy. At the end of each year, all of my friends usually get a four-CD retrospective of the year’s best tracks as compiled by me. But with iTunes, it’s excruciating to build a "source" list of possible tracks for these multi-disc epics, then slot the tracks into individual discs and experiment with sequence. You can only view one playlist at a time, so every time you decide to move a track from one playlist to another, it’s a multi-step operation. Imagine an interface where I could see my "source" list and all of my target lists at once, and where drag-and-drop defaulted to a "move" operation rather than a "copy" operation. With XUL and JavaScript, I’ll be able to build any specialized interface I want and swap it in for Songbird’s default UI.

Sure, most of my needs are pretty specialized, but I hardly think they’re unique. And that’s the point of an extensible, open-source player. You’re free to build the features YOU want to see and share them with others like you. That’s a lot more productive than griping over at the iLounge forums about iTunes’s shortcomings.

I know Songbird isn’t the only open-source, component-based music player out there, but it is the only one that’s drawing on the power of the Mozilla Foundation. Firefox has shown how disruptive the Mozilla community can be in the browser market, which, like the music-player market, is dominated by a single product. Songbird may not topple iTunes any sooner than Firefox topples IE, but it should provide a powerful alternative and perhaps put some competitive pressure on the folks in Cupertino. It was extremely shrewd of Pioneers of the Inevitable to hitch their wagon to Mozilla’s. I’m definitely going along for the ride.

Songbird links

• Songbird site
• Songbird Blog: post on the 0.3 release
• Songbird Wiki
• Wikipedia entry
• Technorati tag

Songbird posts

• Boing Boing interview with Songbird architect Rob Lord
• Ars Technica
• C|Net
• Internetnews.com
• Alpha’s Place
• Blog of the Vicious Beast
• Views of a Discerning Critic
• Current_
• Hardware Beyond the Hype

Technorati Tags

• Songbird
• iTunes
• Mozilla
• Firefox
• XUL
• JavaScript

Share/Bookmark