Goodday is a great app. Has huge potential. Very useful for keeping track of goals but also tracking moods, virtues I’m working on, and vices I’m trying to overcome. – Jay

An excellent tool. I use it repeatedly throughout the day with GREAT success – I’ve reached some pretty lofty goals lately. This app has helped greatly. If you want to stay on track with an aspiration or two, or more, this lets you quickly and easily track your efforts. I had started a googleDoc to do this and when I found it I bought it immediately. It’s simple, clean, clear and incredibly easy to use. In addition, I’ve submitted a number of enhancement requests that I hope will be considered. Even without them, in just two weeks I’ve managed to maintain a high level of awareness and consciousness of my personal goals by updating my assessments throughout the day.Aid my efforts to do my best and achieve my goals? For $0.99 cents? Yeah, I’ll buy that for a dollar. – msg_man in an app store review.

I am a writer and Good Day is a useful calendar and motivational tool.  It helps me track my morning writing hours. - Alexandra

It’s great to be helping people that also believe change comes from simple daily goals.  And yes, now that OneDayApp has shipped there will be another GoodDay update that takes more customer suggestions.  In the meantime… what do you want to track and change?

Facebook does not have a way to associate URLs with pages. 

This means that http://kickofflabs.com can never really be tied to http://facebook.com/kickofflabs.  There are separate likes, fan counts, and facebook insight reports. 

When I initially published the landing page for kickofflabs.com I set the Facebook like button to the kickofflabs.com URL.  I’d also set the following meta-tag in the page header to “link” our page with our domain:

    <meta content=’200576366633574′ property=’fb:page_id’ />

Along with other Open Graph protocol information.

The assumption was that this would tie the URL to the domain.  But that’s not the case. As of today you have a choice:

1. Have people like your URL and manage the interaction there.  Which is more complicated… but you can do this and have your URL publish stories to Facebook just like it’s a Facebook page itself. 

2. Have people like your Facebook page and publish stories from your URL.  This option is much more user friendly if you are just getting started… but keeps the relationships tied to the Facebook URL instead of  your site. 

You can use the URL linter on Facebook http://developers.facebook.com/tools/lint/ to see what’s going on by entering something like http://microsoft.com and comparing it to http://facebook.com/microsoft.  They’ve push most of the fan activity to the facebook page…but over 5k people have liked the microsoft.com URL directly and generated social activities with it.

So what did we choose:

Since we had the Facebook page http://facebook.com/kickofflabs  we decided to just have our like button link to that instead of our own URL.  The upside is that it’s easier to manage publishing content to fans on facebook.  The downside is that the facebook insights on our domain (for liked blog entries, visits, or someone just sharing a URL directly by posting a link) are now separate and we have to look at both of them if we want aggregate data.

Back to the moral of this story… before you get too many people sharing your URL you want to decide if you want them liking that or your Facebook Page.  So secure your Facebook page ASAP and you can push people to congregate there.  Thankfully only 14 people had shared our URL when we made the switch and most of them had also liked our Facebook page. 

Working on the OneDayApp series has dramatically improved the quality of what I’m doing with my next application.  There are all sorts of corners I would be cutting, steps I’d be skipping, and personal education I’d miss out on in the final product if I wasn’t building it partially to teach people. 

It can be valuable at any stage.  If you record your code you’ll find yourself caring about things like variable names in new ways.  Once you have something to demo you’ll see all sorts of rough edges that you’d never see if you just used it.  There’s simply nothing that beats actually “going to the tape” to get a glimpse of what other people see. 

Over the weekend I released a “lite” version of GoodDay.  My price experiment over the holidays showed me that the difference between free and 0.99 is an amazing barrier. So, if someone was holding out for another price drop… you can get the free version now.  It’s ad supported.

The paid version will continue to progress with new features starting at the paid level first.  There are also no ads in the paid version of GoodDay.  Other than the ads the only difference today is the ability to sort your goals.  This debuted on the paid version and will remain a paid feature for a while.

Thanks for all the support so far!

Goodday 1.2 was released to the app store yesterday afternoon.  It’s awesome and I’ve been using it for the last week.  Yes, I’m biased, but there is no simpler way to track life’s important daily goals than the 5 seconds you’ll spend each day in Goodday.

The image gives away the big feature added was the ability to sort your goals.  This was by far the biggest request I’d received for the app. Hundreds have updated already… have you?

Other small updates include making it easier to edit longer goals and performance improvements. iPad users can also rejoice now that the app will actually work on your device.

What’s next for Goodday?  Right around the corner is a less featured lite version that’s ad supported.  For paid users I’ll also be looking into some new goal types and a feature that lets the app tell you if you can give you a running comparison of this week to last week. This way you can use Goodday to tell you if you can afford to slack or not as the week goes on.

Want to learn how you can build apps with your existing web development skills?  You can pre-order the “From Web to App Developer in One Day with Phonegap” training series today.

Ottima!!!!!!! - Anche io avevo avuto la stessa idea, ma la vostra realizzazione è geniale!!! Ottima, semplice, leggerissima! La app che cercavo!!! GRAZIE!!!!

Which, if you believe google means…

Excellent !!!!!!! - I also had had the same idea, but your achievement is great! Very simple, very light! The app I was looking for! THANK YOU!

It’s little nuggets like this that I think keep you going in the early stage I’m at.  Thanks.

Next someone could build an App Store that actually lets me connect with these people in more meaningful ways.

The QA Team

As I stated in the opening of this series you are here to accurately measure the status of customer quality regularly in a repeatable fashion throughout the development cycle. The words here are critically important.

As a bonus – nothing beats a few good rounds of ad-hoc testing by creative people trying to break things.

Ok, this concludes this 5 part series on product quality.  It’s obviously something I’m pretty passionate about and I hope you enjoyed it.  If you are digging back for the first 4 posts in this series to see how other roles own quality.. here they are:

• Part 1: Sales and Development
• Part 2: Consulting and Support
• Part 3: Marketing and User Experience
• Part 4: PMs and Leadership

User Experience

On the use experience team you are going to control the feel of the product.  Will the user achieve their goals seamlessly or will they be frustrated and start looking for more problems? So what can you do?

• Fail fast.  It’s way faster for you to test UI on paper with users than it is for any developer to code it up.  And if the experience on paper doesn’t work you don’t have to rewrite code… which leads to quality problems.  Just refine it offline until you have a winner. Only winning designs should move onto development.  Trust me… you’ll still have to iterate once it’s been implemented anyway… but you can minimize this up front.
• K.I.S.S.  Unless you work for Microsoft your team does not have the resources for complex features with lots of options.  I love brainstorming new, exciting UI, but most of the time it’s not worth breaking conventions for unless you have a lot of time for testing. Stick with what’s worked on Google, Amazon, & Facebook for the last few years. 
• Performance is quality and while animations are fun they CAN NOT get in the way of the user. They are there to reinforce the user action and the user shouldn’t ever be waiting for one to finish.
• Keep those blinders on and stay focused on the feature/flow you are working on.  I’ve seen UX people and designers get sidetracked all the time by looking into surrounding UI, features, and issues. Take a note, save it for later, and move on.

Marketing

Like the sales team you also own the first touch so your role is also critical in the users perception of quality.

• Pull the right customers in.  If the message you are sending about the product isn’t pulling in the customers your company/product is optimizing for then those people are going to be frustrated users if they make it through the sales pipeline.
• Show people the product.  Maybe it’s because I’m visual, but there is nothing worse than a company site that doesn’t have the product described in pictures at least.  Ideally there are also quick videos that explain how you are going to solve my problem.  If I can’t see the product and it’s hidden behind stock photos of happy customers then I assume you are somehow ashamed of the actual product… and I should be ashamed to run it as a customer… so I’ll look for more issues.
• Make your message a WHY.  What’s the cause or belief that you want everyone to be able to convey in their work?  It will give people focus on what is really important since not everything is equal.  Telligent, for example, lives and breaths social customer communities.
• Keep people on message – At a small company you probably own both internal and external communication.  It’s critical that everyone is on the same page about the solutions the product aims to provide since everyone will touch customers. 
• Test your messages and your WHY. Test them internally and test them with customers before you finalize them.

Part 4 will look at the role of PM’s & Leadership.

Consulting Services

If you sell additional services, and code enhancements in particular, then you also own the quality of the product that was shipped. Your on the front lines working every day with a customer who is perceiving the final experience of the product through all the customizations and integrations that you have implemented for them.

• Customizations and integrations require just as much of a test plan and unit tests as code that ships with the product. Anything I previously said about how development team members own quality applies here for the improvements.  A customer will never differentiate between groups at your company… good and bad perceptions apply to everyone.
• As experts you are engaged to prevent customers from shooting themselves in the foot.  This applies to technical choices (deploying on underpowered hardware) AND softer choices about site policies and configuration (requiring too much information to register).
• The goal isn’t that customers are up and running… it’s that customers are achieving what they set out to do.  Because if they aren’t achieving their goals then your services are easy to blame… quality of experience is key and you helped set them up.

Customer Support

I work with some outstanding support people that exemplify the traits below – they own product quality to.

• Quickly gathering information and reproduction steps for bugs that are reported… and making sure the bugs are fixed quickly.   Make sure your product team is accountable for fixing at least 90% of the issues that are reported in each next release.
• Identifying support trends and forcing the team to address them… each quarter the product team should be looking to address “supportability” by looking to reduce the top time consumers of your support team.  It may not be a bug… it may be confusing UI that customers call about frequently… which costs everyone money.
• Communication and closing the loop is critical. Like the lonely tree, If something is fixed in a service pack it doesn’t do any good if the customer that reported the issue doesn’t know it’s been addressed.  This is really hard to do well.

In some ways your goal should be to eliminate the need for your job… except that if you do this well your company will have more customers to report issues… and you won’t need to hire an army to support them.

Part three will look at the role of the User Experience & Marketing teams in product quality.

Me: “We’re responsible for the quality of the product.”

Test Manager: <Laughs>

Me: “Then who owns it?”

Test Manager: “Everyone – the job of the QA team is simple to accurately measure the state of product quality consistently.”

It’s true.  The QA team does not own quality. They are there to accurately measure the state of quality during the development cycle… but real quality is actually a perception formed in the minds of your customers about your product.  The reality is that everyone who touches a customer at your company is responsible for their perception of your products quality. Now lets examine how different roles own quality.  Because no one reads really long posts I’m going to break this up.  Hat tip to Jim Holmes… who inspired this series.

Part 1: Sales and Developers

Sales & Account Managers…

You own the first touch before I may have even seen the product. If no one gets back to me for weeks then I assume that no one would follow up on any issues I may encounter.  If three people get back to me with duplicate questions I assume you can’t properly coordinate basic ownership… let alone product development as a company.  I recently had a company that didn’t get back to me… but did add me to their company mailing list.

Once we’re working together (customer & sales) I form my product expectations from you.  If you say I’ll get the following features & values out of the product then my expectations have now been set.  I’d rather be told “No, we can’t do that today.” than “Yes” followed by months of frustration trying to make the product do something it really can’t do.

This means you have to know the value props and product features like the back of your hand… and be OK with being honest when the answer is “no”.  As a customer I’ll respect you more for that… and will probably come back when I realize a competitive sales person miss-represented the product to me.  You do not have to know how the engine in the car works… but you have to be able to tell me if I’ll go 0-60 in greater or less than 10 seconds.

Developers/Engineers…

You are building whatever it is your company sells and you’ll be the first ones blamed (right or wrong) when something goes bad for a customer.  Entire books and blogs have been written on the subject, but I’ll try to highlight a couple of bullets:

• Demand clear expectations or clearly set and communicate them yourselves for overall functionality, performance, security, and scale.  Get clarification on what the non-happy path behaviors should be.  Never assume. An assumption is a customer that’s going to have their expectations set incorrectly.
• Write tests that validate these expectations.
• Write code you would be proud to print in a book.
• If you see complex code… simplify it. Understand what complex code looks like… there are any number of tools available to you that you can use to measure it with.
• Understand the problem your feature is solving, the user goals,  and WHY you are building what you are building.

Part 2 looks  at Consulting Services & Support.