At the beginning of the month, Redgate sponsored Talk UX. Revathi and I went to Manchester to attend it, and we’ve been talking about it to whomever wanted to hear. These are some of the questions we have been asked, here is what you’d have heard us say if you were there too… How was… Read more »
I should probably start with a disclaimer here: we are completely unconnected to Smashing Magazine in any way and have no vested interest in the site other than really enjoying reading the articles and tutorials they produce. We recently came across Smashing Magazine which deals with a large number of topics and content like UX, design and tutorials to name but a few.
It’s safe to say that we have really enjoyed the articles very much not only for their clear presentation but for the multitude of real examples that everyone can relate to and the relevance of the content to the challenges we face trying to provide a great end user experience. Here are just some of our favorites and hope you find them as great to read as we did:
- Call to action buttons: examples and best practices
- 15 Common mistakes in E-commerce Design
- Minimizing complexity in user interfaces
- How to respond effectively to design criticism
- Search results design: best practices and design patterns
I could create a seriously long list here of all the articles I found particularly interesting but I would strongly encourage anyone interested in design and related areas to go check Smashing Magazine out for yourself and learn from some great examples and content.
The team I work with release every Wednesday.
Why? Well, we believe in releasing frequently to give our users valuable enhancements as quickly as possible and to get timely feedback on the direction we are taking the product. We’ve believe in keeping the delta between releases small and the risk associated with an individual release low. We think practice makes perfect and that the more often you release the less frightening it is to do so.
Moreover, we want to be deliberate about releasing frequently, rather than opportunist. An opportunist frequent release process is one where you are able to deploy a given code change reliably and with little overhead, but that you choose to do this when the opportunity arises. That could be when you’ve just fixed a bug, when a feature has been completed or perhaps when ‘all the planets align’ and all your automated tests have finally passed.