Symphonious

Most issue tracking/customer relation/todo list things have a concept of resolving an issue for later or a remind me later option. The idea is that you don't want to or can't deal with the issue straight away, but you need to come back and review it or follow up later.

Unfortunately, it turns out that marking an issue for later tends to mean "make this disappear so I have no chance of remembering it" because the issue disappears from all the open issues lists forever. Many systems have an option to e-mail you regularly about issues that are marked as remind or later, but the e-mails are hit and miss - usually they remind you about the issue too early and you just get used to ignoring them.

What I don't understand is why these systems don't just ask the user for a date to follow up on. If you mark the issue as later, you should have to specify a date upon which the issue will automatically be marked as open again. If you specify remind, you should have to specify when to start and how often to send reminders. The reminders could either come via e-mail or some other system or just by raising the status of the bug so it appears on open issues lists again or both.

We've seen various problems with this over the years in various different systems where things got forgotten, but the worst example occurred this afternoon. I was closing out some bugs and went to mark one as a duplicate of bug 2171, but mistyped and marked it as a duplicate of bug 271 instead. Our of curiosity I went back and checked what bug 2171 was. Turns out, it was still assigned to me and marked as "REMIND". Since 2002. On the plus side, the fix shipped many years back, we just didn't realize the bug was still open. The last few comments are now:

——- Comment #2 From Adrian Sutton 2002-06-28 16:15:03  ——-

Using the nifty new weekly reminder feature to make sure we don't forget it. :)

——- Comment #3 From Adrian Sutton 2003-03-27 17:10:22 ——-

> Using the nifty new weekly reminder feature to make sure we don't forget
it. :)

Oh the irony…. What happened to that nifty new weekly reminder feature???

And more relevantly, what's the deal with this bug, can it be closed now or are
<very old client> still waiting?

——- Comment #5 From Adrian Sutton 2007-03-21 15:32:36 ——-

I think we can safely close this bug now. RIP bug, RIP.

There is an awful lot of money spent on user interface research, carefully tracking what users do with an application and trying to find ways to improve based on that. It's a shame that so much of it is wasted because the captured data is misinterpreted.

The Office 2007 Ribbon is a classic example of this, it was clear that Microsoft had real world data to back up their decisions about the Ribbon, they'd spent millions on it. Yet somehow it just didn't seem right to me. Turns out at least Damien agrees with me. It turns out that despite the fact that usage data shows that users work in different modes, designing an interface that reflects those modes isn't ideal.

Similarly, just because the most commonly used command is paste, doesn't mean that you should add additional features to it, particularly if it requires adding more complex UI. From Andrew Robert's Office UI Tidbits (UPDATE: That would be the internal blog but NetNewsWire remembers my password automatically. Sorry Andrew, on the plus side, possible improvements to paste options shouldn't be too top secret…):

I am always blown away by how much people love our Word copy-and-paste support. I guess this is why.

We should think about how to improve it even further… such as having the paste options in a toolbar drop-down or having a funky floaty thing after a paste?

The connection seems obvious - if a feature is heavily used you should add extra functionality there because clearly users like using that function. The problem is, users like using that function as it exists now. Our Word copy-and-paste support is exceptionally popular because it just works, you don't need to mess around with funky little floaty things and toolbar drop-downs - just hit control-V. What we should improve about our Word import is the fidelity of HTML import, how well we clean up the HTML and what we can do to avoid the user ever having to go through the Paste Special dialog to pick special pasting options. The thing is, if we're doing our job properly, there shouldn't be a need for funky floaty things or toolbar drop-downs, it should just work. Right now it pretty much does, but there's always plenty of room for improvement.

I found it quite amusing when Andrew's post came in the other night actually, because not two minutes earlier I'd had to explain to my Fiancé that you can just hit escape to get rid of that "annoying floating thing" that appears every time she pasted and got in her way. Word had done precisely what she wanted when she pasted and then ruined it by distracting her with pointless UI. Oh well.

Rob posted about his second month at Ephox and it made me realize it's been a while since I've taken the time to reflect on how things are going for me. Warning, lots of rambling ahead with no attempt at editing.

Towards the end of last year it had gotten too long between holidays and I was getting stressed out and generally sick of work in general. Fortunately, if you haven't taken holidays for a long time you also have a lot to take, so I took all of January off to recuperate. Since then I've been working on my own for the most part with the rest of the team tied up with other projects. I must admit, I quite enjoy going off and coding stuff on my own, still doing TDD and all the other XP practices except of course pairing. It does however tend to let the odd thing slip through and we've seen a few issues crop up that we've had to fix. Fortunately, since we run the latest builds internally the problems were caught before clients saw them. I'm really not sure if a pair would have picked them up anyway, but it may have helped.

Last week we got the major features of the next release completed and I settled in to clear out some of the bug backlog that's built up. We still haven't got defect management settled into our XP process, but at least we're not introducing as many as we used to so hopefully in time the defect rate will be so low that management becomes simple. There's something quite satisfying about churning through open bugs and getting them fixed. Particularly when each morning you can check the open bug chart and see it plummet downwards.

Today, at last, we freed up another member of the team to come and pair with me on the bug fixes - keep me honest and get some experience with this code base. There seems to be something about having a pair that makes me lazier. I had been really good about always adding tests for every bug, but today I tried to dodge that a few times for some reason. Fortunately Jack's a stickler for the rules and pulled me back into line. It was good having someone there to challenge my assumptions, but I need to get a lot better at navigating instead of trying to drive all the time.

I realized on the way home this afternoon that it would be really good for me to work on a code base that I have no idea about with a pair that's an expert in it. I've worked at Ephox long enough that I have a really strong knowledge of our editor's code and the general technology around it, so even in areas that I haven't seen before I tend to feel pretty comfortable. Even our various integrations center around EditLive! so much that they don't go far enough outside my comfort zone to really challenge me. Maybe I should pair with Andy next time he has to work with EditLive! for Windows - a bit of VB should make me feel humble pretty quickly. Alternatively, since I'm heading over to JavaOne this year, maybe I should track down someone from a random open source project that wants to pair on something…

Overall things are going well, getting back into pairing will be a big challenge for me but one that I'm keen to tackle. I'd like to pay more attention to some of the fledgling community projects like LiveWorks!, but I'm not entirely sure where they should be going or how to get them there just yet. Working with upper management to get a clearer idea of those things should be interesting too.

Nice article from the Chief Happiness Officer this morning on pimping your office. Most of the things listed are just over the top, but I really did like the look of Softwall. If Ephox winds up moving offices we should definitely think about using these - it'd let us have an open plan development environment with the flexibility to close off sections as needed.

Very cool.

We've been looking at ways to improve the experience for end users when applets first start up. It's unfortunate that the worst experience with applets is always the first one since that's when the JVM has to start up and the applet has to download. Once all that happens subsequent usage of applets tends to be lightning fast - particularly with the latest JVMs.

Sadly, that awful Java coffee cup graphic just doesn't make users happy while they wait for the applet to download. Equally sadly, there's no good option to get rid of it. You can specify an image of your own to load, but then it replaces the progress bar and it can't be dynamically resized to fit the applet. Heck you can't even center it. Worse yet, by the time the graphic downloads and displays the applet is just about ready so the user winds up seeing an empty box for a while then a brief flash of the image and then the applet's ready.

You can't overlay a DIV on top of the applet because most browsers will render the applet on top regardless and there's no way to show the applet's download progress from a DIV anyway.

The only vaguely plausible option is a light-weight bootstrap applet that displays while the real applet is loading, but that suffers from the same problems as the image in that it takes too long to download and be ready to display - you'd be better off just loading the applet. Plus it breaks LiveConnect functionality because all of a sudden the public methods on your applet are hidden behind the loader applet. You could delegate through but you'd have to do it via reflection or the class loader will demand the main applet be available before if will load your loader class.

Java 1.4 was a little better in that you could have the progress bar showing with your own custom image in the top left hand corner and you could customize the background color of the rest of the applet. Still ugly but at least workable. With Java 1.5 and above the option to display the progress bar is gone, the default animation is distracting and ugly and the Java 6 animation is going to become even worse with the next update.

Sigh…