Now it's all over, it seems a suitable time to do some analysis:
- Why did I write it?
- Why did it get picked?
- What helped me develop the application?
- What did I learn from the process?
- What would I do differently next time?
Why did I write it?
A few reasons:
- I thought it'd be cool to write an app that got used in quite a cool, high profile event.
- I had an idea that I thought was quite good.
- I thought it'd be a good opportunity to build some experience with WPF and particularly with WPF animation.
- To prove to myself that I was able to produce a good piece of software that meets a clients requirements.
Why did it get picked?
"... because of the twitterfeed and because the graphics are actually appropriate"I think there are several reasons:
- Because I actually produced something that met the requirements. - I was surprised by the number of entries that didn't. (Users won't [usually] use[/buy] a product that doesn't meet their needs.)
- Because I actually delivered something. - There were a lot of comments from people who said they were working on something but never posted anything. (There's no reward for not showing up.)
- Because the graphics were appropriate. - While I also had some novel. alternative, ideas I knew these wouldn't tie in with the StackOverflow or DevDays brands. (A bit of marketing knowledge helps in software development.)
- Because I did more than was asked. - The twitter element wasn't part of the original requirements. (Having something unique is always a good selling point.)
What helped me develop this application?
- I made sure I understood what was wanted. - I read the requirements thoroughly. I asked questions and madde sure I understood the answers. I read other people's questions and answers.
- I understood the domain. - I go to quite a few conferences and am keen on understanding their organisation and how they are put together. (This partly ties in with my experiences of organising DevEvening.) Knowing the application domain is essential to good software development!
- I've seen lots of different ways twitter has been used at conferences and other comparable events. - This guided how I incorporated the twitter element.
- I have a desire to only do things well, or not at all. - Loads of people can do average. Fewer people will put in more effort to make something really refined and polished. - Good enough isn't good enough!
- I focused on my strengths, not my design skills. - By basing the design on an existing layout, colour scheme and images.
What did I learn from the process?
- Make the first user experience great. Optimise for it. (User input handling wasn't brilliant in the first version.)
- Visually stunning (slick?!) and different is good for creating a good first impression. Animation is a good way of adding something new, different and visually appealing to traditional desktop apps.
- Make user input handling really solid, smart and tolerant.
- People love seeing their own contribution/thoughts (tweets) on screen.
- TweetSharp is cool (despite a few temporary problems) and fluent interfaces are really nice to use.
- There are a lot of ways user input can get into an application. Consider all of them and 3rd party libraries and APIs as external input and treat them with caution.
What would I do differently in the future?
- Better caching of tweets retrieved from the twitter API. So can download many at once and then stagger their display.
- Better error logging. - Currently swallowing quite a few exceptions with no logging. - It didn't really matter for this case but could help with debugging.
- Better messages to display if no new tweets to show.
- Add unique images for fake tweets.
- Add processing rules for tweet inclusion. Possibilities to consider would include: ignoring retweets; profanity filtering; spam detection and ignoring.
- Ability to play music?
- Better validation of all input.
Right. Must be time to go back to some of my other projects.
*This year! - who knows about the future.