Comments on: A funny thing happened on the way to a SaaS model http://www.wrenchinthesystem.info/2009/07/a-funny-thing-happened-on-the-way-to-a-saas-model/ What's sabotaging your business software and how you can release the power to innovate Tue, 24 Nov 2009 04:09:35 -0500 http://wordpress.org/?v=2.8.2 hourly 1 By: Robert E. Bershad http://www.wrenchinthesystem.info/2009/07/a-funny-thing-happened-on-the-way-to-a-saas-model/comment-page-1/#comment-16 Robert E. Bershad Thu, 27 Aug 2009 13:32:54 +0000 http://www.wrenchinthesystem.info/wordpress/?p=117#comment-16 One advantage to non-SaaS applications is that users are (presumably) notified of interface changes when they update their local drives or through unveilings. That notice advantage is not inherent to SaaS applications because interface changes do not require individual user action. Part of the SaaS design process should determine how best to notify the user of any interface changes, and how the changes affect the application’s functionality. One advantage to non-SaaS applications is that users are (presumably) notified of interface changes when they update their local drives or through unveilings.

That notice advantage is not inherent to SaaS applications because interface changes do not require individual user action.

Part of the SaaS design process should determine how best to notify the user of any interface changes, and how the changes affect the application’s functionality.

]]> By: Moti Levi http://www.wrenchinthesystem.info/2009/07/a-funny-thing-happened-on-the-way-to-a-saas-model/comment-page-1/#comment-12 Moti Levi Sun, 26 Jul 2009 17:57:58 +0000 http://www.wrenchinthesystem.info/wordpress/?p=117#comment-12 The difference between easily done and well done is indeed a critical one. Often, technical people (programmers, engineers, etc.) confuse the two as they think that if it easier to do something (change design) it necessarily means it is better (mistake 1) and leads to better design (mistake 2). Mistake #1 is that making things easier does not automatically means things are better - it depends on the stakeholder, and the implications of ease of doing things. Sometimes, when changes are not easy, it means that spurious changes would be avoided. And from a user's perspective, there's a balance between size and frequency of change. The developer prefers gradual incremental changes but users may suffer from too many changes coming at them too fast. Of course, the underlying assumption in "easier=better" is that changes are always better. But many instances have shown users to object and reject such "better" changes (e.g. facebook). Therefore, ease of change requires even a stronger (better) design process because inherently it allows for less consideration in making changes. The difference between easily done and well done is indeed a critical one. Often, technical people (programmers, engineers, etc.) confuse the two as they think that if it easier to do something (change design) it necessarily means it is better (mistake 1) and leads to better design (mistake 2).

Mistake #1 is that making things easier does not automatically means things are better – it depends on the stakeholder, and the implications of ease of doing things. Sometimes, when changes are not easy, it means that spurious changes would be avoided. And from a user’s perspective, there’s a balance between size and frequency of change. The developer prefers gradual incremental changes but users may suffer from too many changes coming at them too fast.

Of course, the underlying assumption in “easier=better” is that changes are always better. But many instances have shown users to object and reject such “better” changes (e.g. facebook).

Therefore, ease of change requires even a stronger (better) design process because inherently it allows for less consideration in making changes.

]]>