Difference between revisions of "Talk:R-button"
(New page: Let's start a discussion. ~~~~) |
|||
(One intermediate revision by the same user not shown) | |||
Line 2: | Line 2: | ||
[[User:Joe.andrieu|Joe.andrieu]] 17:02, 9 September 2008 (EDT) | [[User:Joe.andrieu|Joe.andrieu]] 17:02, 9 September 2008 (EDT) | ||
+ | |||
+ | FROM: Iain Henderson | ||
+ | |||
+ | Here's my original query from email a couple of weeks back. I'd be delighted to think we can retain the core simplicity, but think so far as the r-button outside of point applications is concerned we'll need to take a sizable step back to gain perspective before writing a detailed functional spec then technical one. | ||
+ | |||
+ | '''My own view, certainly as far as the wider deployment of Relbutton, is that there is a lot of work to do on the functional spec before we get to the technical spec. | ||
+ | |||
+ | I believe it can be made to work if we put enough thought time into it, but in current guise I think it's simplicity (a core virtue) is such that at the organisational end I think it would just bounce off, because it just moves the underlying/ actual complexity elsewhere or ignores it (and they already have ways of dealing with the complexity). | ||
+ | |||
+ | The complexity, as I see it, is that there are many facets of customer-supplier relationships, all of which could be leveraged in visualisation/ automation: | ||
+ | |||
+ | - reason for first use | ||
+ | - longevity | ||
+ | - depth | ||
+ | - breadth | ||
+ | - status (live, dormant, potential etc) | ||
+ | - nature (pay as a you go, account) | ||
+ | - importance (to both parties) | ||
+ | |||
+ | ....and many more | ||
+ | |||
+ | If we can find a way of addressing the underlying complexity in ways that mask it then we'd be onto something very powerful. | ||
+ | |||
+ | Thoughts?''' | ||
+ | |||
+ | Iain |
Latest revision as of 09:37, 12 September 2008
Let's start a discussion.
Joe.andrieu 17:02, 9 September 2008 (EDT)
FROM: Iain Henderson
Here's my original query from email a couple of weeks back. I'd be delighted to think we can retain the core simplicity, but think so far as the r-button outside of point applications is concerned we'll need to take a sizable step back to gain perspective before writing a detailed functional spec then technical one.
My own view, certainly as far as the wider deployment of Relbutton, is that there is a lot of work to do on the functional spec before we get to the technical spec.
I believe it can be made to work if we put enough thought time into it, but in current guise I think it's simplicity (a core virtue) is such that at the organisational end I think it would just bounce off, because it just moves the underlying/ actual complexity elsewhere or ignores it (and they already have ways of dealing with the complexity).
The complexity, as I see it, is that there are many facets of customer-supplier relationships, all of which could be leveraged in visualisation/ automation:
- reason for first use - longevity - depth - breadth - status (live, dormant, potential etc) - nature (pay as a you go, account) - importance (to both parties)
....and many more
If we can find a way of addressing the underlying complexity in ways that mask it then we'd be onto something very powerful.
Thoughts?
Iain