Comments on: IT is Dead (ish) http://www.theenvisioners.com/index.php/2009/10/08/it-is-dead-ish/ Thinking About The Future, Not Just Predicting It Wed, 08 Feb 2012 19:07:05 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Jonathan Peach http://www.theenvisioners.com/index.php/2009/10/08/it-is-dead-ish/comment-page-1/#comment-111 Jonathan Peach Mon, 19 Oct 2009 07:48:56 +0000 http://www.theenvisioners.com/?p=307#comment-111 Great article Dave! We need more BOTTOM-UP approaches; we need brand new ideas, not improvements! I look at things such as the iPhone, even the Xbox 360..and I know these are consumer products, but if you look at how Microsoft and Apple revolutionised the mobile phone and games console markets to be more efficient, accessible and more compelling, it bewilders me why we can't reengineer some of the dated processes that we have become acquainted with in business IT. We have become so complex in our approaches that people run scared if they hear “Upgrade” in the office! Great article Dave!

We need more BOTTOM-UP approaches; we need brand new ideas, not improvements! I look at things such as the iPhone, even the Xbox 360..and I know these are consumer products, but if you look at how Microsoft and Apple revolutionised the mobile phone and games console markets to be more efficient, accessible and more compelling, it bewilders me why we can’t reengineer some of the dated processes that we have become acquainted with in business IT. We have become so complex in our approaches that people run scared if they hear “Upgrade” in the office!

]]> By: Gary Burt http://www.theenvisioners.com/index.php/2009/10/08/it-is-dead-ish/comment-page-1/#comment-102 Gary Burt Mon, 12 Oct 2009 01:31:31 +0000 http://www.theenvisioners.com/?p=307#comment-102 About time too. The goal here is to either eliminate problems from happening or making the resolution that simple that anyone can fix it. This is a mindset shift in the way that software and hardware is designed. Underneath this change though are a set of rules that need to be followed by developers and engineers: - Design for you mum (if she cannot use it, most users will not be able to). Test with your kids too. - Don't require an install if you can help it (IT departments still lock machines down, so this stops things working). This is the online app age - so use this. - Have auto-save and state-recovery on by default. No one wants to lose their work. - Design the UI for the audience, not the technical department. Good design means saying 'no' to features as well as 'yes', so focus on ONLY what is needed to make it work. - Follow the norms in UI design. Don't try to be innovative in design of your UI. The chances are your skills are much worse than you think. Follow the norms for where things should be, what icons mean and how the application flows. - No manuals please. No one will read it. Help is OK at a push, but try to avoid this and just make it work. - Test, test, test. With everyone. Reward them and encourage openness. If you have a pig - it is better that they tell you, rather than end users once released. - Build in upgrades. Whatever you are doing, architect the application to allow it to upgrade itself (or allow the user to upgrade it without a FULL reinstall). Learn from iTunes here. - Don't disable or lock-down more than the absolute minimum. Users are more savvy than you realise. Trust them. Allowing them to fix things will prevent calls to the helpdesk. - Cut the technical jargon. Speak plain english - everywhere. No technical terms, no complicated taxonomies - and no 'invented' words. if you follow these rules, you will be doing better than about 90% of in-house (and many commercial) software developers and well on your way to making a great app. Gary About time too. The goal here is to either eliminate problems from happening or making the resolution that simple that anyone can fix it. This is a mindset shift in the way that software and hardware is designed. Underneath this change though are a set of rules that need to be followed by developers and engineers:

- Design for you mum (if she cannot use it, most users will not be able to). Test with your kids too.
- Don’t require an install if you can help it (IT departments still lock machines down, so this stops things working). This is the online app age – so use this.
- Have auto-save and state-recovery on by default. No one wants to lose their work.
- Design the UI for the audience, not the technical department. Good design means saying ‘no’ to features as well as ‘yes’, so focus on ONLY what is needed to make it work.
- Follow the norms in UI design. Don’t try to be innovative in design of your UI. The chances are your skills are much worse than you think. Follow the norms for where things should be, what icons mean and how the application flows.
- No manuals please. No one will read it. Help is OK at a push, but try to avoid this and just make it work.
- Test, test, test. With everyone. Reward them and encourage openness. If you have a pig – it is better that they tell you, rather than end users once released.
- Build in upgrades. Whatever you are doing, architect the application to allow it to upgrade itself (or allow the user to upgrade it without a FULL reinstall). Learn from iTunes here.
- Don’t disable or lock-down more than the absolute minimum. Users are more savvy than you realise. Trust them. Allowing them to fix things will prevent calls to the helpdesk.
- Cut the technical jargon. Speak plain english – everywhere. No technical terms, no complicated taxonomies – and no ‘invented’ words.

if you follow these rules, you will be doing better than about 90% of in-house (and many commercial) software developers and well on your way to making a great app.

Gary

]]>