Cats and Dogs, Living Together!

Remember back in 5th grade (or sophmore year of college, in my case) when your best friend called the girl's best friend and asked if they liked you, because you like them but only if they liked you first?

Eventually, you realized that this method of communication was getting you absolutely nowhere and you dropped the middle-men and just got the guts to call the girl yourself.

I've been having deja vu lately involving workflow. While I could probably have a decent blog entry on the various approaches we've tried while implementing, I'd rather talk about why we've had to take various approaches in the first place!

Initial requirements gathering turned out to be invalid for a variety of reasons. We deserve some blame on the IT side for not really cementing the process in place - we could have done a better job of forcing users to really walk through the process on paper. Another major issue was not getting beyond the liason's and into the true end users.

The end result is something like: Bob sends to Cindy who can reject in which case it goes to Tom but an approval goes to Al unless Bob hasn't entered the id in which case... yuck.


When we eventually had "what the users wanted", you could take a step back and already identify points that just didn't make sense... You mean to tell me that the CEO at HugeCo wants to have to sign in and click "ok" for every new item coming down the pipe? We're going to get calls on Day2 telling us that we have to take that out because it's a serious kink, etc, etc.

Well, you can't be surprised that this workflow evolved quite a bit as we went a long. We'd put out something for the users - a week later someone would tell them it was there - a week later someone would tell us it "didn't work".

Did it really work? Well, it did exactly what it was intended to do (as code often does), but... no, frankly: it was a piece of crap!



So, month 10 rolls around and things are getting outrageous as the deadline approaches. Finally, not only are we working with liason's but (gasp) in the same room as the end users and actually (triple gasp) talking with them directly! So, now everything went perfectly... THE END.

ok, maybe not. Actually, looking back on the last week I have done what I would normally rate a poor/fair job of getting requirements ironed out.


BUT, using a technique I call "communicating with the user" I have been able to make my mistakes: have them corrected, implement what they think they want: have them realize it's wrong, etc all in the course of maybe 10 hours of legit work. As opposed to the 8 months of make a mistake - wait a week for communication to occur - retry, that we've been going through up until this point.

The moral of the story: Having an open communication line is essential. You can benefit greatly from having technical people talk directly to the client. People who will eventually write the code know what typically needs to be done to actually get the code written! Seems like common sense but it's not always that easy to communicate this need.

Seem like common sense? Of course it does, you're a technical person: now go explain it to your boss.

Becoming a Greasemonkey, one banana at a time

Alright, so I've finally gotten around to my first real taste of creating Greasemonkey user scripts.

I was thinking about what scripts I could write that I might actually use: the best I could do was some little tweaks to the ole' fantasy football site.

Here's what's been annoying me. I look at my list of players and each has a little 'note' icon next to them - letting me know that there's some news to be read. To get to the news I go through this:

1. click the note icon
2. new window opens
3. read
4. close window
5. Repeat for each player

It's not many steps but it's a pretty obvious spot where the UI really could make my life easier. So, I set out with the goal of creating a hidden div in the page - on mouseover of a note I'd show the div and simultaneously populate it with the guys news via xmlhttp. All was going well and the script was running well against html on my PC when I decided to actually point it to the real URLs. I hadn't noticed that the player notes and the list of players were from different domains! Ugh!

Anyway, in the interest of just getting the thing working I gave up on the xmlhttp/hidden div and switched over to opening a new window with the note. It's not so bad since I still close that window onmouseout, but it's not ideal.

Now I have:

1. hover over note icon
2. read
3. mouse off to close note
4. Repeat for each player

My goal was to write my first script and that I did, so we'll count it as a success. If anyone has any (somewhat) straightforward advice on getting around the single domain requirement for javascript (xmlhttp) it would be much appreciated!

Echo2 (Ajax Based Rendering Engine) - RC3 available

Now, to synch it before or after No Fluff this weekend?

I think I'm going to err on the side of caution and hold off until after the 'Effective Ajax' presentation that Rob and I are giving Saturday night. The release candidate (announced yesterday by Tod Liebeck) doesn't make earthshattering improvements, so I don't think the presentation will suffer... hey, I'm not complaining though: progress is progress!

By the way, if you've missed Rob's announcement, the presentation (slides + examples) is available out on his site.