Matthew Lang

At the moment I'm working on an application for a decision making tool for groups that uses email to track people's responses to a question that forms the basis of the decision. Basically this application sends an email to all the people you want feedback from regarding a decision. In the email are the responses they are allowed to reply back with. They click the appropriate response and it's done. With me so far? Good.

Collaboration tools like this in teams are okay because everyone knows one another and the team work together for the greater good of delivering a great product or service. In a team you expect to get emails from other team members that want your input on a decision.

What happens though when you receive an email asking for your input on a decision, when you know that person but not as well as you know your family or friends? Another way to look at it is this:

How would you feel about giving feedback on the decisions of others you know in only a professional manner?

This is where I am having trouble with this idea. On one hand I know that teams are always going to respond to one another's questions, but say we have a decision making tool for the masses that anyone can use. You want feedback from a group of people that you know on a professional level who opinions you might value, especially when it comes to getting feedback on a key decision, but your worried that they won't participate in your decision.

If these people who opinions you value, mark your request for feedback as spam, are they really people you want feedback from or are they simply too busy to provide feedback?

This has been a stumbling block for me for a while and it's led to two different strategies to allow people to be included in decisions.

First Strategy: No Restrictions, Include Everyone

This was the initial idea for the product. The decision maker can include anyone they want feedback from on a decision. Whether it's a member of their team, someone from a particular social network they interact with, or just someone who opinion the decision maker values.

Emails are sent out to everyone requesting feedback on the decision. The main benefit to this is that you can include anyone in on a decision easily and quickly. However there are a number of drawbacks:

• What if the email is marked as spam? - It doesn't do well for your product to be perceived an another form of clutter in the inbox.
• Should the user have the option of blacklisting themselves from all future emails from my product? - To combat the possibility of the emails from my product being marked as spam, users could have the option of automatically blacklisting themselves out from all future emails. This gives a greater form of control but it does limit the decision maker in who they ask for feedback.
• Should the user have the option of blacklisting themselves from this decision only? - A spin on the previous option, but again it does limit who the decision maker can ask for feedback from.

Second Strategy: Verify Respondents First

This is a more controlled form of getting feedback from the right people. You are pre-approving people to be included in your decisions, so you should be able to build a reliable network of people who you can ask for their feedback on any number of decisions. There are drawbacks to this though:

• You just can't include anyone in a decision - Initially I wanted a platform where people can ask others for their feedback on anything.
• More barriers to getting feedback - Even if a person does want to help we require extra steps to include them on your decision. After one click to verify who they are, they might just get bored and not bother taking part in the decision.

Test Group Will Provide Feedback

Thankfully, I have a test group who are keen to use this service to help them make decisions with regards to small investments as a group. I'll be providing a simple implementation of this application for them to use for a while as a group.

As an added test, I will ask the test group to use the application to create decisions that are not related to investments. I want to see if there is a difference in the number of responses depending on the topic of the decision. I expect investment decisions to generate more responses because that is what the application is for.

I still haven't decided whether to go ahead with this product in the long term, but sharing this here did give me a moment to weigh up the two options.

This goes right to the top of the wishlist. I've wanted to own a Rocky Mountain bike since I was a teenager, but only if it's was one of their top end bikes.

via Singletrack

I'm in between work at the moment. It's an odd place for me to be. I've worked in the full-time job market for over 10 years. If I wasn't working, I was on holiday or I was made redundant and I was looking for another job. This freelancing lark is different though and with some time in between gigs and I want to use the time I have wisely.

With a few days free in between gigs I had two choices today:

1. Work on products
2. Get some chores done

I opted for the chores.

It was a lovely day here in Scotland so I thought it would be a good idea to simply step away from the computer and let my head rest while getting a few things sorted around the house and the garden.

We're not all fortunate to have a day away from out desks like this, but I'm so glad I'm in the position where I can do this and not worry about the implications on my income by taking a day away.

Feedly has been my choice of RSS reader for about 2 years now. Initially I was won over by a service that provided a better user experience but still allowed me to continue to use Google Reader as my main RSS reader.

Feedly was a great application but lately I've become a little bit weary of it. One particular problem I have is the number of times I need to log back in. I've got Feedly running on my Macbook, iPad and iPhone. About once a week I would need to log back in on either the iPad or the iPhone. Logging in each week can be a bit of a pain. Especially as it's linked to my Google account.

It was time to look for something else.

After some searching I found the RSS reading service Feedbin. It's a subscription service with a web client that also works with the Reeder app for the iPhone.

At just $2 per month or $20 for the year, it's relatively cheap, but as a paid service it at least has more of a fighting chance of being around in the long term.

I've taken the $20 for the year offer as I want to try Feedbin for the long term. With the use of Reeder I have a supporting app for my iPhone that can let me use my Feedbin account. It will be interesting to see how Feedbin pans out as my main RSS reader over the next year.

Nice geometry on the Dart.

via Pedal Consumption

Curtis McHale sums up why clients should wait for their favourite consultant.

Think of Gandalf (Lord of the Rings wizard if you don’t know). He was always running from one place to another. Someone always needed his help. He was a busy dude and couldn’t just take on every issue at the drop of a hat.

Any decent consultant is going to be like that. Really if you need more than a few hours of work, you should be expecting to wait.
— Wizards are Busy People by Curtis McHale

Never thought of myself as a wizard before though, but I do like the idea.

No way could I build an online product.

That was me two years ago. Thankfully my confidence has went up since then, but it took me some time to get to the point of shipping a product online. To do this I wrote about my product and what I hoped it would do. I put it down on paper and then started to realise how simple it would be to build.

Michelle's 11 point list is a great place to start if you want to "pick yourself".

1. Write. Set aside time to ask questions, dream, think big. Put your phone on silent and set an alarm twenty minutes out.
   — 11 ways to "pick yourself" by Project Exponential

Read on for the full list. It's worth it.

Last week I started work on an idea for application. Just a small prototype of the idea really. No tests, no fancy user-interface, just the bare bones of the idea. In typical agile fashion I wrote out some of the basic features that I needed for the prototype as user stories on index cards and then set to work. Then a call from a client came in and before I know it, it’s two days later and I’ve not started work on the prototype.

My problem is that I’m starting client work as it comes in and my own projects are getting done in really small pieces. I am not keeping a daily schedule.

Truth is I haven’t kept a schedule of my work for at least a couple of years now. Not since I worked at a consultancy where you could plan your day most days. There was days where you would have interruptions to your schedule, but as it was customer support calls, you had determine if the customer’s support issue was that important that it had to be resolved there and then. With interruptions like this mounting on daily basis, I abandoned my calendar of work and just did work ad-hoc.

Now though I am more in control of my own time and schedule. I am my own company and I need to schedule work to ensure that client work gets done most days, but I also allow for some time to work on ideas and products.

Scheduling your work in a calendar is a commitment to getting that work done. I have the benefit of having a laptop with an external monitor so I use my laptop as my secondary screen. On here I have my calendar and I leave it open while I am working as a reminder to stay focused on the task I have set myself.

I’m using Apple’s Calendar application and the iCloud service to synchronize my calendar to my phone. This makes it easy for me to schedule stuff in my calendar when I am away from my desk. I use the brilliant Fantastical app to manage my calendar from my phone. It has a great agenda view for upcoming appointments and it has a very easy appointment entry system that means you don’t need to fill in four different fields to make an appointment. It’s smart enough to know that “10am Meeting with client” should be scheduled for 10am.

Scheduling your day and your week is a great way to making a commitment to getting things done. It’s more structured than a to do list, but provides a way of breaking your day down into chunks so that you’re not working on the same thing for hours or days at a time.

There’s a great line from the start of “Pirates of the Caribbean: Dead Man’s Chest” spoken by everyone’s favourite pirate Jack Sparrow.

Complications arose, ensued, were overcome.

If only it was that easy. It is never that easy. When complications do happen, are we making things complicated for ourselves?

I do. I make things ridiculously complicated sometimes when I’m writing code. I’m always thinking too far ahead. What if we need to do this, what if the format changes? I’m always thinking of edge cases for features that won’t be encountered on a daily basis. I find it quite a hard habit to break.

Take for example this form I was working on yesterday. It required three things:

1. A question
2. Your email address
3. A list of other email addresses

So handling the first two things is easy, but I wanted to do something smart with the list of email addresses so that people could input any number of email addresses. I ended up with a form like this:

Handling the code to add and remove the email addresses from the list wouldn’t be too difficult but it’s clearly not the easiest thing to do. Annoyed at the complicated form I would need to build, I left my project to do some client work that had been scheduled in.

Then it hit me that night. What else uses lists of email addresses that are not constrained by size? When you are writing an email you simply enter the names of the people you want to send the email to. In one textbox. It’s that easy. The next day I changed my form to use a single textbox for the list of email addresses. A complicated form made easy.

Two things I took from this:

1. Keep it simple stupid

The KISS principle is a recurring topic in software development, but we developers tend to think of the YAGNI (You aren’t gonna need it) principle. The two are similar, but what I need to remember is the simplest and stupidest way is always going to work. It might not be clever, but as long as a simple design works, we should use it. If the simple design can’t handle an edge case in the future we can fix it then. There’s no need to worry about it for the moment.

2. Look to other examples

When building software, there’s no shortage of examples that you can refer to for influence. I’m not suggesting that you take a straight copy of a unique feature for another product, but when designing processes for your application, it can help to look to other examples to see how it is handled already. It’s probably going to be simpler than you first thought. I didn’t even think to initially look towards other examples of how this could be done. I could have saved myself a lot of time.

So there we go. My complications were not as quickly overcome as Jack Sparrow’s complications, but then he doesn’t write code does he?

Journalong is just one of a number of options that I could recommend. But there are others if saving your journal entries to Dropbox isn't your thing.

Peter Aitken kindly informed me of a new service, Oh life, that uses just email for your journal. Looks great.