With a great deal of code stolen from the Devlounge plugin guide (I tipped them), I’m pleased to announce a beta version of the TipJoy TipThis WordPress plugin! The plugin is up and running here with the options in the screen grab:
(click for a screen grab)
- Adding your TipJoy UserID to your header to claim your tips
- Option to add Tip This buttons to EVERYTHING, this will spam your front page with buttons
- More selective option to add a button to Post pages
- More selective option to add a button to Page pages
- Snazzy admin page
Downloads are available from the Official TipJoy TipThis post or right click and save as here.
Bugs and feature requests can be posted here or emailed to me @ David -at- KnightKnetwork.com
Win a free WPDesigner.com Theme Club membership for testing the plugin! Click for more info!
In technology, change is a way of life. Feature stagnation will lead to a competitor jumping ahead of you and an abandonment of your product. At the same time, changes in your product can cause a backlash from users who aren’t happy with the results. A thread on Hacker News is what brought this to my mind and I wanted to explore the subject a little further.
What happens that causes users to hate change and what steps can be taken to make things run smoothly?
In my experience there are three main groups of users who are unhappy with change:
- Users who don’t like anything to change
- Users who don’t need the changes and now have more work to do for the same results
- Users who aren’t using your product the way you intended and who’s functionality has been broken
Do you deal with users who don’t fall into these groups? I’m not talking about people with minor complaints, I’m talking about users that get really angry or frustrated. Passionate users that will let you know how they feel and aren’t afraid to go elsewhere.
What can be done to ease change and make it more universally accepted? I don’t think there’s a silver bullet for this problem, but there are certainly some things that you can do to help:
- Prepare users for the change: Educate your users ahead of time giving them all the info they need about whats coming, making sure to focus on the improvements from their point of view.
- Poll users about the change: Only do this if you care about the results, polling to get a result that you want is a bad idea and if it backfires things could get ugly quickly.
- Preserve old functionality: No one wants to support multiple versions of a product, but it’s done all the time. Why? People don’t get angry about change when they don’t have to do it.
- Enhance simplicity: This is harder than it sounds, adding features while keeping your user experience simple is very challenging. If you can do this and focus your changes on the backend with minimal frontend changes you’ve created a truly elegant product.
- Incorporate unorthodox usage: If a user is using your product in a different way than you intended, then that user has just added value for free. If their usage has some merit seriously look at expanding in the new direction with your next enhancements instead of slamming a door.
While we may want to blame problems with change on our users, if you look hard enough you’ll see that it’s a problem of our own making. I’m curious if other programmers have a different view on this, other categories of change resistant customers or other strategies to make change go smoothly.
This morning my favorite code search engine, Krugle, has made two big announcements:
- The launch of their second generation Code Search Appliance that can access SCM systems. If you can get your hands on one of these then you don’t have to rely on a hacked together app that searches code or worse yet, just dumping everything locally and using something like Google desktop search. Code reuse is an important part of writing programs efficiently, but it only works when you can quickly find the code you need to reuse, Krugle can make that happen.
- The second announcement is it’s OpenAPI for partners. I believe this will be good news for programmers who work with the large Dev networks that Krugle supports (IBM developerWorks, CollabNet, SourceForge.net, Yahoo! Developer Network, etc.) , and should allow for easier to use and better integrated tools.
Read this if you aren’t familiar with Code Search Engines
Press Release Follows: (more…)
I recently got a new laptop, nothing fancy, but it needed some tools to be really useful. This is the list that I came up with and it’s just as useful for desktops:
This is a reminder to all you programmers and lovers of programmers, that Programmer Day falls on September 12th this year. Go ahead and mark your calenders now so you don’t forget! Programmer Day falls on the 256th day of the year, normally September 13th. But since it’s a leap year, we get to celebrate on September 12th this year!
Since I’m in a new launch sort of mood this week, I also want to announce that the greatly improved design for ProgrammerDay.info has been completed. There will be some tweaks and I’ll add sponsors as they come on board, but overall I think this is a huge improvement over the hastily thrown together WordPress site from last year. Since it’s a standalone site with no database behind it, it should hold up to the traffic demands a little better than last year as well. Please check it out and let me know what you think!