Archive for March, 2009

Web App Desktop Clients – Bluring The Line

Monday, March 9th, 2009

We have built a lot of apps recently in Adobe Air. Clients love desktop apps, and personally so do I, and I like them for the following reasons:

  1. A desktop client allows you to receive alerts even if you do not have a browser open
  2. There is a different experience to using a browser
  3. You can work on them off line – using Adobe Air’s built in SQL lite database
  4. People are more familiar with desktop apps

Adobe Air makes it so easy to create desktop apps that run on Windows, Linux and Mac that anyone can build them. Having a desktop client gives clients the flexibility to choose the medium that makes sense to them.

Check out some of the showcase applications listed on the adobe site, there are some great ones on there.

Know Your Client

Sunday, March 8th, 2009

Do you really know who your client is?
Do you know their management and reporting structure?
Have you analysed the key stakeholders in the project?

If you have answered yes to all of these then well done, if not you could be in for a big surprise when you come to sign off the project. Many a project has failed due to key stakeholders wading in at the end of a project, if you have not engaged with them at all key decision gates.

Who is your client?

We define the client as the main point of contact within the company you are working with. Your client is not always a senior stakeholder or project sponsor. You need to identify who has the authority to sign the project off in your client’s organisation.

Project sponsor

The project sponsor is the person who owns the business case for the project, and is responsible for delivering the project benefits to the organisation. The project sponsor is the most important person on the project, so you must identify and engage with them at all times.

Analyse project stakeholders

Stakeholders are people with a vested interest in the project, and a cross section of stakeholders usually sit on the project steering committee with the project sponsor.

Not all stakeholders are made equal, so you need to rank the stakeholders with the following criteria:

  • How much influence they have in the organisation
  • How much interest they have in the project

The most important stakeholders are those with a lot of influence and a lot of interest in the project.

Stakeholders have a huge impact on a project, so you need to know who the key influencers are and who calls the shots.

Conclusion

Knowing your client affects the way you communicate and how the project is run, and ultimately affects the success or failure of the project.

We make sure that at the start of every project we have only one main point of contact (client), who calls the shots, and we make sure that we communicate and collaborate with the key statkeholders. Otherwise your project is doomed to fail.

The Idea – Talk About It

Sunday, March 8th, 2009

Following on from my post on The Idea Comes By Solving A Problem, we have found several issues in our business that we are going to solve with a web app.

We use a range of tools to manage our business, basecamp, lighthouse, sugar crm, as well as custom built internal apps, and none of these really integrate. So we are going to build a suite of apps to help manage your business. Nothing revolutionary but it will be a one stop shop for small business owners.

Some people will be saying so why have you told everyone your idea, do you not want to keep it secret?
The answer is no there is no need to keep your ideas secret; because telling people your idea does not matter.

The more you talk about your idea, the more you will understand it and be able to articulate it when you start the marketing drive.

As you talk about your idea with people, people will give you feedback, advice, offer ideas, make sure you listen, but do not let negative people deter your from your vision. Also talking about your idea will create a buzz surrounding it, that will keep you energised in the tough times.

This idea is solving a need in my business that needs to be addressed, so if someone else beats me too it then that is great.

I also think I can build this tool better than anyone else, and even if I don’t there is more than enough businesses to target so there is more than enough pie to go round.

Proactively Keeping Clients Informed

Saturday, March 7th, 2009

During a long project it is easy to get involved in the development and forget to keep the client updated. It is really annoying as a client if you do not know what is going on, and have to keep asking for updates.

I have found it much more proactive to send project updates once per week to clients and key stakeholders. The format of these updates depends on the type and influence of the stakeholder.

What to put in the report

The reports we send are fairly informal and short, our reports typically contain the following:

  • Title of project
  • Summary of the brief in one sentence (in case you have multiple projects with the same client)
  • Principle contact and names of key stakeholders
  • Progress we have made in the week
  • Highlight any risks or issues
  • Projected time line for completion
  • Any aspects that have affected the budget

Clients have really responded to the weekly updates, and they have drastically increased client satisfaction rates. It also makes clients feel part of the project and that makes them much more engaged when they are kept in the loop.

Time To Take Stock In The Downturn

Friday, March 6th, 2009

If you are suffering from reduced activity in the office due to the downturn in the economy, then it can be a really good time to take stock before things pick up again. You need to make sure you are in good shape before all hell breaks loose again when things pick up.

Now is a great opportunity to work on the business instead of chasing your tail working in the business. Here are some things that you might want to look at:

1. Marketing

We have been re-writing our case studies, developing client presentations and designing a video show reel, ready for our new direct marketing campaign. These are the kinds of things that get missed when you are working on projects.

2. Vision and Direction

Have a look at the company mission and values, do they still make sense? Do they need to be changed? Is the company going in the direction you want it to? Dust off the company vision and update it with your new vision and ideals.

3. Connect With Customers

Go out and see your customers, this is a great opportunity to connect and reaffirm the working relationship.

4. Training & Staff Development

Learn a new programming language or framework, think about adopting a new methodology such as agile development. Look at your staff objectives for this appraisal cycle and help them to reach the goals they set.

5. Upgrade Technology

Make sure any systems that need an upgrade get them now, fix all the small work flow issues that have been bugging you for months.

6. Systems and Processes

We have recently completely redesigned our working practices, based on the lessons we have learned over the last six months. It was a great opportunity to address some of the issues that affect profitability (such as over servicing clients, client changes, and feature creep). The whole team was involved in the process and this helped get buy-in to keep to the new system.

7. Work on Internal Projects

Remember all those cool projects that you have planned that you never have time for, now is the chance to work on them. Better yet come up with a project that involves cross functional teams, to improve collaboration.

This current economic cycle will not last forever, and you need to make sure that when it ends you are in a good place to take advantage.

Designers And Developers At War

Thursday, March 5th, 2009

Working in a technology office that places a large emphasis on design, we have a larger than normal ratio of designers to developers.

I was listening to an interview between Joe Stump (lead architect) and Daniel Burka (creative director) of Digg, which made me think a lot about the designer, developer relationship.

This relationship is often a strained one, often there is clear separation of teams with designer and developers often working in separate offices.

I am generalising somewhat but developers tend to be more pragmatic and see the whole picture, where as designers are much more creative and grand with their visions. There needs to be a compromise in order for the two teams to work well together.

Here are my tips for a productive working relationship between designers and developers:

1. Sit Together

If you all work in the same space then it is much easier to see what the other team do, and appreciate the skills that they have. You will also get to know the designers personalities and that helps when communicating with them.

2. Collaborate start to finish

From the very start of the project designers and developers should work together. This ensures that the best ideas are highlighted, and there are no nasty surprises later in the project, when the developers see a signed off design and freak out as it cannot be done.

3. Developer sign off

Any design that gets sent to the client has to be signed off by a developer first, so they can assess whether the design is actually possible, and can be built in the time line specified.

4. Keep talking

Always keep talking, have round table meetings, cross team brainstorms and make sure you developers keep your techie speak to a minimum.

5. Educate each other

The more you can educate designers on what is and isn’t possible the easier it will be the next time, simply saying that it cannot be done is not acceptable, always give reasons.

6. Mutual respect is the key

Both teams must respect and work together if you want to create an amazing product. Each team cannot do it by themselves.

7. Naive knowledge

I have often seen very elegant solutions suggested by designers as they do not really understand the technical points. Sometimes developers can over analyse and be too risk adverse.

8. Pause before you speak

Listen to what the other party is saying and then pause before you reply, really consider their point of view. This is universal for all teams.

9. Don’t say no – developer’s default response tends to be “No”

We have all done it and it is not healthy, remember there are shades of no, only use a flat out no if it really isn’t possible. Most developers love a challenge and no should not be part of their vocabulary.

10. Compromise

There is always middle ground, if you are asked to build the impossible, give options and suggest alternatives.

11. Don’t be afraid to challenge

Don’t be afraid to challenge each other ideas even if they are not in your field. I often challenge a design that I see even though I am not a designer. However you should always defer to the experts, at the end of the say if I challenge a design but the designers over rule me, then fine they are the experts in design.

Conclusion

We have a lot of healthy banter between the development and design teams, words like spot uv, belly band and matt lam, always make me laugh. Recently the developers were talking about extreme programming, this prompted the designers to come up with extreme design, which involved designing while snow boarding.

As a developer I personally hold designers in very high regard and have huge respect for their skills and expertise, I have learnt a lot from them, and hopefully I have taught them something in return.

Developer and designer can work very well together, given the right environment and ethos, and when they do, amazing things happen.

The Idea Comes By Solving A Problem

Thursday, March 5th, 2009

The best web apps come out of a real need, if you have a problem in your business or your life, chances are others have had the same issue. Building a tool to solve that need can then be very profitable.

The best problems to solve are ones that you face often and really annoy you. We run a small business and it is very hard to keep on top of everything. So building a tool to help us with this would be a great idea for an app.

Also building an app to solve your own problems means that when you start using it, you will be able to refine the tool so that it really works.

Don’t invent the wheel though, make sure there are no tools out there that already solve your problem.

Design Does Not Always Solve Everything

Wednesday, March 4th, 2009

I am often called in to consult when a site, software or systems are not working correctly, either they do not deliver the benefits they were built for, or they are not as successful as the owners expected.

Working in an agency that places a heavy emphasis on design, it is easy to say that a new design solves all problems. Most creatives place a lot of emphasis on refreshing or changing designs, however this is just one part of the solution and needs to be used with a more holistic approach.

If you site is not giving you the returns that you expect, the design of the site is probably only one part of the solution.

Think about the following aspects of your site:

  1. Navigation – can users find what they want quickly and easily
  2. Signposting – are you highlighting the most important information
  3. Leading and Calls To Action – make sure users know what to do on each screen
  4. Information Architecture – grouping and arranging data into logical groups
  5. User Feedback – engage with your target audience and get their input
  6. Analytics – watching users move around your site can yield surprising results

Remember that if your site is not working, giving it a new set of clothes will not fix anything, using a more balanced approach will fix the real root of the problem.

The Right and Wrong Way To Software Prototype

Tuesday, March 3rd, 2009

We do a lot of work for Oracle, who tend to grow by acquisition rather than organically. This can lead to a lot of company integration issues and a lot of people internally (especially salespeople) who do not know what all of the companies do.

So we recently built a prototype application for Oracle; the acquisition app is a desktop application, that is a directory of all acquisitions, what they do, the key contacts, products and value propositions. It also alerts users if there is something new that has been added or posted.

We decided to use some new technologies to build the prototype: Django and Adobe Air. I had not used Django before, but I know some Python and it was love at first sight, it just felt right. With the help of my friend Jason Davies, the back end was built really quickly and effortlessly.

However the same cannot be said for the front end application. I decided to use Adobe Flex for the Air interface so we found a contractor to do the job for us. Three weeks later they were still working on the interface, I thought Flex was supposed to be fast for building interfaces quickly? We brought in another contractor to get the job done and they took another two weeks to finish the job.

The end result was a very clunky interface, that did not flow and, had lots of imperfections. Now we are really serious about anything that leaves our office, our quality control is very high. We were faced with a dilemma, we had spent a lot of money and had ended up with a product that did not pass our high standards.

So we took the bold decision to build the app ourselves using Adobe Air using AS3. Our flash guru took up the task, and we worked night and day to get the app completed in just five days! The end result is a work of art and is a slick iPhone style interface that really wows people when they see it.

We really went the extra mile, and this paid off as the app was taken showcased at Oracle Openworld, and as a result we got to tender for a large pitch for the global pharmaceutical company Novartis.

From this project I have learnt or reinforced the following lessons:

  1. If you use external contractors then you need to watch them like a hawk and perform code reviews daily, and set daily milestones
  2. If you go the extra mile for clients, and keep high standards no matter what the cost, then you will be noticed and your hard work rewarded
  3. Prototyping requires constant involvement and collaboration with the client – think agile and iterative
  4. If you are using a technology you do not usually use, or do not know then at least learn the basics before you start
  5. If you can build something in house, that is always better than using contractors
  6. Using new technologies takes more time for development (obvious!), so account for this in the budget

You can read the Oracle Acquisition App case study here (Adobe PDF download).

Building A Web App Team

Monday, March 2nd, 2009

The right team will make or break your web app business, and it is so important to get it right. Treat it like a business, which means having all the main management disciplines covered.

At a minimum you will need, the following disciplines:

  1. Web developer
  2. Database developer
  3. Server administrator
  4. Interface designer
  5. User experience designer
  6. Marketing/ sales manager
  7. Finance manager
  8. Operations manager

Now that does not mean you need a team of eight people for your start up! I think the best number of people for a start up is between one and four, any more than that and you lose the special magic that can only come from a small, tight knit team.

The founding members of our web app team are:

  1. Arif Harbott (Me, The Naked CTO) – in charge of web development, database and server admin, finances
  2. Scott Sanders – entrepreneur, solutions expert and legendary web app designer and user interface specialist
  3. Mystery Partner – a senior technology executive in charge of operations and sales

It is such an important part of the business that we are all responsible for marketing; with these blog posts forming part of the marketing campaign.

We all work really well together and are very creative when we have meetings, so it is important that you all bring out the best in each other. It also helps as we have worked on projects together in the past.

We are a remote team, Scott has recently moved to Perth and as such we have regular meetings on Skype and email, so you do not have to all be in the same office, although it is preferable.

One last thing, if you are working on a project part time, then it is important to assign someone with overall control as a project manager. That person needs to be a finisher, someone who will work until the job is done. No surprises then, to find out that, that person is me in this venture, as I have the project management background and will work to get the finer details of the project completed.