I recently used American Express Travel to book a vacation for my wife and I. We are celebrating her 30th birthday. I have a ton of points so I wanted to book an awards travel. Seems simple enough. I've used points before to rent a car; I recall a slight hassle back then, but hey, I wanted to use my points.
So, here is the issue. We live in a world of simplicity. Everywhere you look, interfaces get easier and easier to use. Online banking, dinner reservations, email, its all super easy because that is what users have demanded. When I run across poorly designed web pages at work, I make it a point to fix it; time permitting. If it sucks bad enough, it will get fixed sooner rather than later. If it just plain doesn't work at all you can bet that Crash will be asking WTF?
American Express is a reputable company with a lot of resources. I recently worked with their international team on a credit card interface and it went very smooth. Needless to say I was shocked to find that they had such a poor interface for booking rewards travel. I assumed the site would be perfect because of their name; that was a poor assumption.
I'll try to explain the experience:
Here is the Membership rewards area where I'm applying 19k points to my hotel reservation. As soon as you click the "Redeem the full balance" radio button, the "Amount credited to your Card" is updated on the right and is highlighted in yellow. Seems simple right? I'll get back to this one in a minute.
Section #3 is where it asks you to select a method of payment. I was using my points, but wanted to pay with a Visa. So, I selected Visa, plugged in my data and moved on. Everything seemed normal, no surprises.
Once I processed the reservation request, an error occurred. The error stated that I did not provide the Card Identification Number for my Amex. I was not paying with my Amex, why do they need it? Also, I noticed that the "Use Another Card" option was gone. Had I been doing this in Firefox I would have used firebug to see exactly what was going on. The last annoyance was that the data I mentioned earlier with the "Amount credited to your Card" was wrong. It no longer reflected the credit I was getting by using my points, yet the radio button was selected.
This smells like poor state management. Why have the values not persisted through this round trip?
My wife was wanting me off the computer, both babies were crying and I was in a hurry so, like user that was just introduced to the Internet, I clicked proceed with the reservation. Can you guess what happened? They charged my Amex, not my VISA. WTF? I'm pissed that this happened. Not because it absolutely had to be the Visa, but because I wanted it to be the Visa and I didn't get what I wanted even though I was very deliberate with my intentions.
I posted about this on Twitter and shortly after I received a customer satisfaction survey. I'm not sure that was related but I was glad to give them some feedback.
Why is an intuitive UI important?
Using a Blog to Publish… Everything!
Last week we finished up with our second sprint – Wednesday was the last day and Friday was Demo Day. One of the new features added during the sprint, as Meat mentioned, was the integration of a Blog into our primary application. It’s not a real blog in the way that most people think of a blog – random thoughts, opinions, and politics, but rather a series of documents describing specific features and modifications to the application itself.
Background
A couple of years ago, I pimped out some programming to my wife for a new set of golf clubs. She helps run a dog rescue, and their old website sucked – it was traditional html in the format of something you would see back in the mid 90’s. They we constantly rescuing dogs and looking for adoption candidates, and needed a better way to help people understand what the status of the dogs that were going through the rescue process. I delivered a website that helped with the dogs part of it, but she was constantly asking me to update the front page.
Back to the Sprint…
In the previous sprint, one of our business analysts was tasked with delivering .pdf documents for some of our more popular reports describing each report in some detail. We were planning on showing the document in some kind of iframe when a user clicked on the report description page. In reviewing his work, i realized that we could use this kind of documentation all over our application, but I wasn’t too crazy about .pdf documents being the method of delivery. So I brainstormed with Meat and a couple of other lead developers and decided to blog our documentation.
Meat wrote the Atom Interface classes and made it easy for us to drop them onto any page, and I worked on selling the concept to the rest of the Senior Management team.
Whatever you do, don’t mention “Blog”
In a “Roadmap” meeting after our second sprint was well underway, a couple of VP’s were concerned about the amount of “stuff” coming out, and how to get the clients and support staff up to speed on new features. I mentioned the blog concept – how I thought it would be a good way to get the word out on new features – and yikes – it was met with a lot of skepticism. I think it would have been an easier sell if I hadn’t used the word “Blog”. I should have called it “A Collaborative Interactive Article Authoring and Publishing Tool”.
I never really sold the concept to them, but they reluctantly agreed to wait until the demo before passing judgment. I did get them to consider having the support managers actually participate in the sprint, and author some of the blog content, but I haven’t heard back as to whether or not they will. It was exciting to me because up until that point I hadn’t considered anyone besides the software development and QA teams would actually author any “articles”. Now, the more I think about it, the blog is a PERFECT tool for this – and I want as many authors as are willing to post.
Context Sensitive Blog
Demo Day
In order to help drive the concept of the blog, and to help sell the idea that we should have many authors, we asked all of the team members to write one article each on a new feature they were adding during the sprint. So Friday, we rolled out the concept of the blog, along with all of the team’s content, and the feedback was emphatically positive. Several of the chickens expressed interest in writing content, and others called it the most exciting feature they’ve seen in years.
I don’t think I’ll have any trouble selling the concept now…
Software Gear Shifting
I was riding my new bike today with my son in the trailer. We went everywhere, to the park, down a green belt, through the neighborhood, always at different speeds and always changing gears. As I approach my house, there is a small hill that I need to climb in order to get the bike and trailer into my garage. I was not paying attention and forgot I was in high-gear so as soon as I went up the hill, the resistance was too strong and I got stuck.
I've gone up this same hill, in the same gear, everyday for about two weeks straight. So, why did I forget to shift this time? I almost immediately related this problem to software and my short programming career.
Over the past year, my programming skills have evolved rapidly and I'm constantly learning how to be a better programmer. With that comes a different mind set during development. For example, I just completed a major engineering effort on one of our product's website navigation system. Think of it as a database driven site-map on steroids, complete with contextual options, event bubbling, keyboard support, layout options, styling options, oh and did I mention its contextual? This challenge only took me a couple of days to write, test and implement. A year or two ago this would have been a side-project (in fact it once was) that may have never been finished.
During the short lifecycle of this project I found myself thinking of things that would have never crossed my mind before. Things like, this method should or should not be static, or this method does not belong inside this class. I even took it as far as "what would the solid principles of design or WWSPDTMTD as I like to call them" tell me to do in this situation. With every line of code I wrote I kept thinking, make sure this thing is scalable. Make sure it is extendable, make sure it works...
I feel like I went above and beyond what was required. I component-ized the class objects and built controls that other programmers could implement later. I have no idea if the controls will ever be used again, but if they are, I'm confident they will work and the programmers that implement them can do so with very little effort.
Again, this is such a change for me from a year ago. I was a green programmer who eagerly wanted to bang-out as much code as possible; I did not pay much attention to code purity or scalability, rather I just made sure it worked. The more code I wrote and the more involved I was with important projects; it seemed like people looked at me with higher regard. After no time at all it was apparent that I became the go-to guy. Being the go-to guy comes with some heavy weight on your shoulders. Not from your peers, or your bosses, but from yourself because you are the one that sets the bar for everyone else.
Once you are a go-to guy, or gal, you touch nearly everything. System problem, you get the call. User problem, you get the call. Business needs a new credit card process written and implemented in two days, you get the call. The experience that you get starts to grow exponentially with each product you build, feature you add and or bug you fix. Get enough bug fix requests thrown your way and you realize you are fixing your own code. It may not be the code you laid of finger on, but it is the code that you are responsible for. It is code that was written in a way that you would have done when you were green.
Don't get me wrong, everyone writes code that they could say "I could re-write that better", a few years after they've written it. I'm referring to the "what the hell was I thinking" moments, or the, son-of-a-biscut, I have to re-write this thing now so that its a little more generic and can be reused by other objects.
So things have become so clear to me now. Do things the right way up front and you wont have to fix them later. Sure, it may add a few hours to your LOE (Level of Effort) now, but that costs you and the business much less than fixing it later when it is a bug and a fire-drill ensues until you force a deploy to squash it. Spend a little extra time and consider scalability, flexibility and extensibility when writing code. I've learned this the hard way. I like to move forward, not backwards, and to fix a bug I created, or to re-write code I've already written before nearly drives me insane.
When I look back at the navigation project and the extra effort I put into it so that other programmers could use it in other applications, I'm convinced that I did it twice as fast, if not faster, than I could have done it a year ago. So tell me, was there business savings in that? You bet your a$$ there is. Not just in the time I spent on it, but in the time we will save when we tell programmer X over there to implement the same navigation system on this other site.
Ok, so now that my rant is over, here is the point I'm making about Software Gear Shifting. It should be our goal as developers to build software that is bug free, easy to change, scales well and that people like using. We should make sure our users never feel like they are going up a hill in 24th gear, when using our software. It's not just about the users either. Other programmers should be able dive into the code and develop it, not fix it. The software as a whole, meaning the code, and the UI, should work like a bike, which can seamlessly switch gears with very little effort. If you haven't guessed already, Software Gear Shifting is a really long way of saying Agile.
As for me not making it up the hill... That was my mistake. I went back down the hill, re-shifted to first gear and took us up the hill.
Powered by Qumana
Writing a blog for a blog
A while back I talked about our evolving blog world. To summarize, we've implemented an internal blog by scraping atom feeds from blogger. Google hosts the content and we read it and display it in our application so that the user experience is that the content is homegrown.
We added this project to the sprint and Crash and I specked it out via Google talk. This was a very high-level conversation and it was fun for me. I'm a visual guy and had to throw some stuff on the white-board for clarification but the bulk of the conversation and design were done over instant message. So, we truly have this mobile communication rocking!
The development vision I had:
Crash did the heavy lifting architecture stuff. Meaning it was his design and he defined what he wanted (strongly typed blog objects).
My job was to take that design and make it functional and that's what I did. A blog has a feed, a feed has entrees. I wrote an atom parser (yeah yeah, we aren't on .net 3.5 yet), a blog datasource control and a blogliteral control (to give other programmers a drag and drop control example). The implementation is simple; drop a blogdatasource control and a blogliteral control on a page, set the literal datasource to the blogdatasource and bind.
The last step is implementation. Once the core foundation is complete, we can had it off to programmers for implementation. I like this concept for several reasons.
1) Another programmer is reviewing my code, even if they don't realize it. This can be very beneficial for the team. Think of it as pre-QA.
2) More than one person will understand its functionality on a technical level. This is important for me because as I get "drive-by's, I now have the ability to delegate to someone with experience on the project.
3) I get to move-on to developer tasks. Implementation is important, but the hard work is in the design.
Everything went great until it was time for implementation. We had delegated the implementation as a sprint item on a programmers list. Crash is very excited to show this feature off at an upcoming demo so he wanted it implemented as soon as possible. I think Crash realized, as anyone at his level would, that the implementation needed a trusted touch. So, guess who implemented it? Me!
I'll be honest; it was fun. To write a set of controls without the intention of implementing them yourself was different for me. I got to test my own programming skills which was super cool. So I created grunt work and I became the grunt.
I've always felt that the success of a new development project was determined by how many new changes are requested by the users. I'm talking about the "hey, this is cool. It would be really cool if you could also do this" type of feedback, not the "WTF, it doesn't work" feedback. This project is unique in that there is not a specific client that asked for the development; it was Crash. I sit next to him everyday so the feedback will be quick and relentless. Nevertheless, I know if I get "dude, it would be cool..." type feedback, this project, at all levels, was a success! Worst case scenario would be no feedback at all. In my experience this means no one gives a sh!t. I've had a few of those in the past...
Testing 911
I just purchased new ip phone service with Vonage and received an email from them regarding my 911 service.
Please do not test 911 without first checking state and local laws, as dialing 911 in non-emergency situations may be unlawful in certain jurisdictions.
Wow! So the first thing that comes to mind here is I HAVE TO TEST THIS! The QA in my blood is boiling right now. How dare anyone tell me not to test something. That is like giving my son a Buzz Lightyear doll and telling him not to play with it.
I get the "don't call us unless there is an emergency" point they are making. After all, if I were calling for an emergency and was held up because some schmuck was calling to test their service, I would be pissed.
I went looking for solutions and here is what I found:
You are never really without 911 service. I mean, how could you be, you pay for it? What happens is you get routed to the Vonage national emergency response center, I'll refer to that a nerc from now on. So, your call goes to nerc and a trained agent will contact a local emergency center, i'll refer to that as lec from now on. Ok, I hope your following along. So, nerc calls a nearby lec center; great. If you are routed to nerc and lec, you better tell the guy robbing your house to hang tight while you provide nerc and lec with your address and phone number.
I'm trying to be funny; it's probably not working. Anyway, the bottom line is you are always connected; just not directly all the time. In fact, you can dial 933 to get the status of your 911 service. In my situation, I've been connected to the local 911 center before I even received the v-portal from Vonage. That makes me happy. Sounds like the best case scenario is that you are directly connected and the worst case scenario is that you may have to talk to one or two people to get the ball rolling. Have you called 911 recently? I did about a year ago when someone was trying to break into my house and my wife ended up taking to a few people before she got routed to the sheriffs department, while I was at the door guarding my family. In my mind, Vonage is an improvement, no matter what 911 category you fall into. I live far from the city so it may be different for you.
So, with Vonage, my family's life is in the hands of my boradband connection, and my Rugar...
