Full blog post coming soon, but for those of you following our feeds, we wanted to let you know here. :-)
- UX overhaul
- Later & Scheduled
- Preferences for fonts / background
More to come…
EDIT: There’s an amazing discussion regarding this upgrade happening here: http://help.nirvanahq.com/discussions/general-chit-chat/23-feedback-on-new-ux
Where is the much anticipated Nirvana upgrade we were hoping to release over the weekend? Well, ahem, our “friend” the-slow-script-alert decided to haunt our Internet Explorer power users again. We know we know, it’s our responsibility to work out the kinks, and IE accounts for less than 5 percent of our current user base, but we are expecting this number to grow and we must ensure Nirvana plays nice in the Microsoft eco-system.
Granted the alert only affects hard core users of Nirvana (you need to have entered a lot of tasks for the alert to popup) — these are the very last people we want to upset.
We couldn’t upgrade knowing that we’d be stomping on our best IE users.
So getting technical for a moment (or skip this paragraph if you don’t want to), with the user interface overhaul and added features/filters, the number of event listeners (such as click-handlers, mouseenter/leave etc) have been balooning. jQuery, which we use for ajax and DOM manipulation, is absolutely amazing — but is often used sparingly on your typical web site. Nirvana, however, is 99% DOM manipulation, and using jQuery the way most people do (and the way we have been thus far) can really start to push the boundaries of what the average browser was designed to handle. We’ve been attaching listeners to individual elements as they are rendered on screen (think checkboxes, date widgets, context menus, note detail togglers — on every task). This means that as the number of task on screen increases, so do the number of listeners (and the size/complexity of the DOM parsing). So over time with longer and longer lists, you get more and more event listeners that are constantly “listening” to every move, and it just drains your browsers resources. So, while this is the typical jQuery way of listening for events, and while it certainly is convenient for quick coding, we are taking another approach. We are now attaching ONE click event listener to the “body” element, and are determining when to do something (or not) based on what was clicked AFTER the event bubbles up. This is how many other js libraries work by default, and there’s really no reason not to do things this way with the jQuery we know and love (…except that it really is so much more convinient to simply attach listeners to DOM elements with CSS style selectors, but whatever). The boost in performance for YOU outweighs the development convenience for US. So, you win.
The upshot: we are heads-down rewriting a large chunk of the application, with the added benefit that it has sped up Nirvana performance not only for users of IE, but for other browsers as well. A huge win at the cost of a few more days of patience.
We will release just as soon as we’re convinced everything is stable.
Thanks for understanding…
While we’ve been busy working on new features, we’ve also decided to loop back and improve on some existing features that people have been requesting. As our mission is to make the experience of GTD as intuitive and effortless as possible, we’re always looking at ways to remove clutter, makes things faster, and help size up your next action without wasting precious brain cycles.
Check out the screencast below to see where we’re headed.
We’re working out the kinks this week and hope to have these changes rolled out soon.
We hope you’re as excited as we are!