Who You Calling A Jesse?

Short-sighted customer service moment from a car dealership

jrrodgers@gmail.com (Jesse Rodgers) — Tue, 30 Jun 2009 07:04:00 GMT

Today I find myself at a car dealership in town that is willing to sacrifice a long standing relationship for $50. No more $150 oil changes, no more other service, certainly won’t buy new tires from them, etc all because they insist to charge me to figure out what is wrong with my less than three year old Saab. Talk about a short-sited customer service decision.

After leaving my car to sit for a few weeks while I was on vacation I returned to a car that was just a mess. The lights kept going out, there was a violent vibration from the back wheels (feel it in the seat not the steering wheel), and it just ran rough. Given it is generally a sleep in the garage car I assumed it just didn’t like being outside and/or it is showing its 65K of KM. Although for a Saab 9-5 that shouldn’t be a lot.

I finally managed to get into the dealership a month and a half later. The lights have been an ongoing concern (they have been replaced every time I bring it in) so no worries there, they will take care of it. The vibration might be warranty work or it might not. Just to find out I get the privilege of paying for the time to figure it out.

I realize it is common practice for mechanics to do this. After all, it takes them some time to figure it out (or simply plug in the computer and it tells you) and sure mechanics could spend all day diagnosing things and not get paid. But:

is diagnosis not built into their $80/hr+ billing rate?
I bought the car from that dealership and I might buy another (not now)
The mechanic won’t feel the vibration anyway as he isn’t allowed to go fast enough to feel it (yes it is above the speed limit but not by much)

What I don’t understand is why do people accept this? If more people complained then there is no way it would continue. I am certain the irritation on customers over oil changes is why GM now covers that for the first few years… obviously the service cost is worth absorbing to make customers happy. BMW, Mercedes, and others offer free ‘scheduled’ maintenance as does Cadillac. They probably don’t charge to tell you if something is warranty work or not. Why? Over the ownership time they may have to absorb $200 per customer on average which is pretty cheap for happy people that spend 40k+ on a vehicle.

Our lease is up in a year and I am pretty sure I will not be going back to that dealership for much beyond handing them the keys.

Canada 3.0: Day 2 impressions

jrrodgers@gmail.com (Jesse Rodgers) — Wed, 10 Jun 2009 05:30:00 GMT

The Canada 3.0 conference wrapped up the second day with speeches from the CEO of RIM, the Chair of the CRTC, and others all with a strong patriotic message as well as a surprising amount of useful vision and position stuff specifically from the the Chair of the CRTC. Day 2 did, sadly enough, start off with some rather dry and boring stuff that made for a fun game of buzz word bingo.

Between the speeches I attended the talk that included Waterloo’s own Jacqui Murphy from TechCapital. She took full advantage of having a mic and an audience to make it clear that startups shouldn’t be about seeking funding or exits with big companies buying you. You should dream big and focus on revenue generation. Some great messages to bring back to VeloCity I think.

The round table discussions in the afternoon felt like they lacked energy and urgency. The big rooms and groups just didn’t work well for that but I did meet some really interesting folks around my table. If nothing else, that was a huge bonus.

Overall, the strength of the Canada 3.0 conference was in the diversity of the folks that attended. There were some very obvious complaints about the lack of students attending but we really need to stop idealizing students, if they are interested they will come—if they aren’t there they really don’t care…. yet. There were enough student volunteers to suggest to me that the ones that are interested knew about it and made the effort to attend.

What I think was really missing was the younger entrepreneurs and leaders on the panels. Not the under-25s that the over 50’s marvel at, but the 25-40 yr old professional crowd that have the skills, experience, and know how to really push Canada’s ‘digital economy.’ I would have also liked to see more of an unconference stream. Being a Barcamp/Startup organizer I am already a fan of the format but we needed more conversation over round table sticky notes. I will even volunteer to organize that for next time ;)

I should also point out the technology situation. Stratford doesn’t have 3G, the wireless was overwhelmed by all the mobile devices and laptops begging for data (but we got the tweets out!), innovative things weren’t set up like streaming panels to the media room at the very least. Sure Igloo put together a good site but that was impressive a couple years ago, if this is ‘3.0’ then it should push the boundaries.

Honestly, it was an amazing conference. This should be the start of something… keep the buzz going, follow up with the business cards you collected, and start thinking big!

Canada 3.0 Conference: Day 1 impression

jrrodgers@gmail.com (Jesse Rodgers) — Mon, 08 Jun 2009 16:23:00 GMT

The Canada 3.0 started today in Stratford Ontario (45km west into farm fields from Waterloo) and surpassed a lot of people’s expectations I think. The morning had the typical political talk you would expect when government folks are given a microphone along with the University of Waterloo making it clear it is committed to the Stratford campus and all the potential developing such a campus may hold. What followed was a day of great conversation about communities, what to do to foster entrepreneurial talent, mobile technology, and more.

It was high level discussion mostly but it was honest discussion focused not on how great Canada is but where Canada needs work. Have a look at the twitter stream under the #can30 hash tag for some great bits of information. Day 2 promises to be more interactive with work groups tackling some of the issues presented today.

I spent a lot of they at the VeloCity booth talking to people that are interested in the idea and colleagues at other schools that are a bit envious that Waterloo has such a residence. I will be around for day 2, stop by the booth and say hi!

Test driving the Cheverlot Traverse on my Twitter Test Drive

jrrodgers@gmail.com (Jesse Rodgers) — Thu, 04 Jun 2009 12:28:00 GMT

Over the past couple of days I have been driving the Chevrolet Traverse as part of a Twitter Test Drive arranged by Waterloo Auto Mall. Overall I think it is a great XUV (SUV is so 1990s) that does pretty much all of what a mini-van offers but with a much more solid vehicle that you can use on light off-road fun and snowy days.

What I really liked about it:

Back row of seats—although not entirely usable for adults (what back row is?) there are plenty of seat belts for when you need to move kids around town
Even with the back row up you have space for stuff—something I didn’t expect given it isn’t a Yukon or Tahoe.
The 3.6L engine can actually move the thing—it has enough acceleration to be fun
Overall design of the interior—although not up to European quality of materials, it certainly is well designed and comfortable

What I don’t like:

The stock GM technical parts that you see in 20-30K vehicles in this one that has a 50K+ price tag—The quality isn’t there in the 20 year old digital displays compared to similarly priced BMW’s and Mercedes.
The exterior lighting—again, for the price I would expect xenon lights and less ‘cheap’ looking plastic
Mileage—this vehicle isn’t broken in but but the avg economy on a highway drive between Waterloo and Hamilton was 12L/100km (~20 mpg). Why wouldn’t I just drive the V8 Tahoe?
The one I had was front wheel drive only—for the price I would expect all wheel drive.

The two top things I don’t like is (I think) because this model has a 50K price tag but there is a 35K version. That is something that I think plagues GM vehicles as a whole. You can’t upgrade bits here and there and add that much to the price because you start getting into BMW and Mercedes land that have all those features and more in a much nicer designed package with quality finish. BMW and Mercedes just don’t have a lower priced option… GM needs to either upgrade more in a vehicle or stop trying to have premium domestic vehicles.

My verdict

If you can get an all wheel drive version at the 40K level you are getting a great vehicle. The quality, the performance, and the utility is certainly there. However, I am not convinced I wouldn’t look seriously at a Jeep Commander instead if I want a 4×4 that can do family stuff for ~35K.

Also: See the Edmunds report on the Traverse

About TwitterTestDrive

As far as I know the Waterloo Auto Mall is the only dealership trying to actually use social media and reach out to its customer base. I think it is a brilliant idea to try out and let the users of social media reach out to their online friends about a real experience that is essentially word of mouth marketing. I expect the #twittertestdrive hashtag will be filled of some honest and interesting experiences over this summer that will influence at least a couple car buying decisions out there.

StartupCampWaterloo number 6!

jrrodgers@gmail.com (Jesse Rodgers) — Mon, 01 Jun 2009 18:52:00 GMT

Almost ready to have the sixth StartupCampWaterloo in just under two years. For this one it was decided to not get an opening speaker and just leave it to the community to drive the event. Our sponsors are still doing the same thing and making sure everyone has snacks and liquids. I am really looking forward to the event and meet some new folks as well as catch up with others. If you haven’t signed up and are coming, please head over to eventbrite!

After number six there will be some changes coming to StartupCampWaterloo. We didn’t get a chance to put them in place this time due to vacations (I didn’t post a thing in May) and overall being busy. If anyone has suggestions please post them here to drop me an email (jrrodgers on gmail).

Higher ed web @ Cornell

jrrodgers@gmail.com (Jesse Rodgers) — Fri, 24 Apr 2009 10:26:00 GMT

Today I had the pleasure of presenting at the regional Higher Ed Web Conference that was held at Cornell University over the past two days. What a great conference put together by Jason Woodward and his team at Cornell. The speakers started off yesterday with a heavy focus on how to get the user involved in your web project from user testing to engaging folks through social media story telling.

Today we moved into an actual project aimed at a particular set of users at Cornell, into project management (my presentation), and off into the high level thinking about the future of higher ed with Mark Greenfield. My head is swimming with ideas and issues but even more focused on the purpose of the web in higher ed.

My presentation slides are here, thanks everyone for the great feedback and I look forward to continuing many of the conversations online and maybe even at the big Higher Ed Web conference in Milwaukee in the Fall:

Web Project Management

View more presentations from Jesse Rodgers.

Associate Director of VeloCity

jrrodgers@gmail.com (Jesse Rodgers) — Fri, 03 Apr 2009 10:39:00 GMT

After a few weeks of going back and forth with all the internal workings it is now official, I am one of two new Associate Directors at U of Waterloo’s incubator 2.0 residence, VeloCity. I join Virginia McLellan (the other Associate Director) and Sean (Director) as the new team to really push things into something really great (and fun).

The residence has come a long way in last 8 months since it started taking on students. With more investment in people to help push the direction we plan on building more of a community around VeloCity, trying out new things, and seeing where we can go. It is very exciting to be involved in such an innovative and fast moving project.

Can’t wait to get started.

Feeling Cynical about Web Accessibility and Standards?

jrrodgers@gmail.com (Jesse Rodgers) — Tue, 24 Mar 2009 04:52:00 GMT

Shortly after I started working in the Higher Education web space (2001) I came across the brilliant post by Jeffrey Zeldman on A List Apart that lead down all sorts of paths towards web standards and accessibility. I wasn’t alone. I think many web folks that were dealing with the internet bubble bursting were inspired by Zeldman’s call to arms to change things and many had the time to explore the possibilities. I did what I could in my position to influence the University of Waterloo web space and in 2004 we had a XHTML/CSS layout that was clean and accessible which was finally let loose on campus in early 2005.

Things changed on campus and I spent more time on usability testing and meeting with the few students that relied on adaptive technology. I wasn’t put off by the fact only two people might notice the enhancements as I knew UW was doing the right thing by fixing things. However, all of the applications students and staff rely upon were not going to be fixed or changed with even the course management system saying it was section 508 compliant but that version was even less usable than the main user interface. A problem that I have observed is that accessibility laws or regulations seem to force people under the covers in the HTML to make things work in screen readers (sometimes) but people ignored how usable the content or the application actually is.

It gets stranger by the day, developers demand unit tests they can meet to make the app accessible but there aren’t any… I don’t think. Laws and guidelines just compound the problem by giving people a false sense of compliance. In the case of learning environments most aren’t even all that usable but golly gee they are 508 compliant. It starts to drain hope.

Blame technology or developers?

A developer most certainly should make browser based apps (HTML/JavaScript/CSS apps) ‘professional’ grade by using semantic HTML, unobtrusive JavaScript, and sensible colour contrasts. That checks off a lot boxes in terms of Search Engine Optimization, re-usable code, dealing with rendering fun, and accessibility. There are different ideas of what it takes to make a web app or page accessible however, and I am not sure a developer should kill a load of time on certain things (that change with the project) like zoomable layouts—especially when browsers are implementing features that make that time wasted.

I am not sure that is inline with that Derek brings up in his post When is the right time for accessibility? as I think some (or a lot) of the things that are generally seen as making HTML as ‘accessible’ really should be the responsibility of a different team of developers (mainly those that make web browsers). I don’t disagree with the strategy of implementing accessibility later based on need and I think Derek’s post offers a bit of an olive branch to developers. You shouldn’t be expected to be all that accessible until you actually know that (a) people will use your product and (b) knowing how people will use your product.

What is my problem?

Honestly I don’t know. Call it a long winter, annoying problems repeating themselves for years, and new experts making the same mistakes.

I started this post sometime after I saw the small torrent of comments about a JavaScript framework which was summed up in Drew’s post The Cost of Accessibility. Drew is on that fence of innovation needs to take into account the reality of the web browser right now and I am not sure I agree.

At the same time I got into a few insane conversations about making the new job system for co-op on campus accessible and IE6 isn’t dead (like we had hoped) for an important 5% of our user base. Our development process makes it insanely difficult to spend time testing, fixing, and tweaking for accessibility (application is hiding behind a VPN and has a few other features that make it hard to access outside of our network). We use jQuery wisely, CSS, and HTML to the browser. AJAX is sprinkled in parts but nothing should depend on it. For a first version that isn’t really ready for user testing it has some good fundamentals but someone pulled the ‘yes but you are missing x’ and I just got deflated.

The problem, in my mind, goes back to the way people think about accessibility. The whole issue is an Art not a Science and certainly not engineering. Engineers have left us with this problem, with HTML, a stateless browser, and a crippled feature set that forces hacks, short cuts, etc. They are doing their part, slowly. Code artists like Derek Featherstone and Drew McLellan help spread the word and lower the barriers through simplified approaches and keeping the dialogue going.

HTML 5 gives me hope even if the Engineers aren’t too quick to drop it in our browsers! I am not really cynical ;)

A lesson parenthood teaches, have fun.

jrrodgers@gmail.com (Jesse Rodgers) — Wed, 04 Mar 2009 05:17:00 GMT

A bit of a personal post… It is already March and the todo list starts to get pretty crazy. I thought going a masters and working was hard, came kid #1 while I still had to finish up the grad work. Then along comes kid #2 and I don’t understand how people do it. How do you balance the demands required to stay on top of the work game and still spend as much time as possible with these cute squishy things that seem determined to never allow me to sleep again?

My approach is to have fun. If you aren’t having fun doing what you are doing you should figure out how to make it fun.

Web Development team roles in an agile process

jrrodgers@gmail.com (Jesse Rodgers) — Mon, 23 Feb 2009 05:00:00 GMT

What is the ideal structure for a web application development team that is using Agile methodologies? What is the process that results in the most bug free development possible? Over the past few weeks I have been documenting and tweaking team roles and process for our front-end development. It has been a lot harder than I thought it would be, especially when you throw co-op students in the mix.

In the past year roles on our team have evolved as we have had to figure out the limitations of our technology, backgrounds, and our skills but I think after about 12 months of a team functioning in a development mode things are pretty much set. What I have found is that you have to adjust certain roles to match people’s strengths and find their comfort level—especially if they are co-op students or recent grads. Once comfortable in their role people start to really shine.

The Web Development team

Every team is a bit different but this is what the Special Projects Group looks like at the moment:

Design/UX Lead: Manages the front-end design work, participates in development, has responsibility for what is displayed on the screen and how it is displayed – satisfying the requirements set forth by the Client and Project Leads. Interacts with the Project Lead to determine what is ultimately on the screen and how the users interact with the system.
UI Tester Lead: Design, manage, and execute testing. Collects and consolidates data for the Lead Design/UX.
UI Designer/testers: Works on designs, incorporates feedback. They also do what would pass as unit testing on the application using a web browser.
Client Lead: Provides input and has shared authority with Project Lead on screens.
Project Lead: The person responsible for the project wrt development and satisfying project requirements. Interacts with the Client Lead to determine functionality, business logic, and general interface requirements. Interacts with the Lead Design/UX and Client Lead to develop the front-end requirements.
Developers: Code the screens.

Like with any web app project and team, there is a creative process group that must meet up with a coding/logical process group. Ideally you throw some usability testing/feedback, client feedback, and a project lead that has sold a particular level of functionality to the client and you get into some fun. The above roles try and address this but they need an integrated process that all roles can work with.

Problems that had to be managed largely had to do with timing

A problem we have had is that coders can’t code a screen until a UI designer/tester has run the screen past a number of people within the client group. That has been cut down to one client lead who has his own process to run it past a larger client stakeholder group. There was another problem with the feedback loop from the client and project leads and when was the best time for them to provide it. This problem is still not fully addressed but hopefully the current process will solve it.

Embracing the issue tracker (or how I love bug reports)

Bug tracking, even the concept of what a bug is, along with having a reliable/useful system was our final problem to overcome. We started with Team Foundation Server then we switched over to Bugzilla and adopted a very religious approach to using it as an issue tracker. This worked out extremely well in providing focus and a task list for coders to pick up. The new problem it has caused is that if you are tracking issues in the system how or why would you use the sticky notes on the wall? Honestly, we are still working on it.

Our process, incorporating bug tracking with sprint planning

The above work flow works really well. What we have done is broken the project into milestones that fit a two week sprint planning process (or a series of planning sessions). The screens are developed quickly with paper, they are discussed, modified, and bounced back and forth in less than 48 hours. From there coding can begin.

We make an effort to switch modes on a screen so that our bug system isn’t overwhelmed. Our team members roles funnel decisions up to a contact point and then allow certain ‘bugs’ or issues to be incorporated in two weeks or less.

Translate agile to your team

Agile doesn’t mean you are infinitely changing things and incorporating feedback. You need to have a cycle that allows you to reach a milestone, provide time to iterate, and move on. You need to be able to classify the feedback and make decisions against the larger vision of what you are building. Where Agile works for us is that it provides an opportunity to catch major problems before too much time to it. Where it fails is when our process doesn’t incorporate the tools at our disposal effectively.

The goal of this process is to avoid being ‘too agile’ where the people in higher positions can cloud the process with mixed expectations and contact points. Using a big wall with sticky notes full of stories and tasks works great but as soon as you introduce bug tracking software it starts to slide a bit. The balance is hard to find but when you do it is worth the short term pain.