Yarko, I don't think our opinions are that much different, we describe more or less the same thing with a grain of perspective and terminology difference.
On Oct 31, 10:39 pm, "Yarko T" <[EMAIL PROTECTED]> wrote: > I must not have been clear - technology is completely irrelevant as far as > describing a client's problem domain (even if part of the problem is an > existing solution, that still is not part of the client's problem domain, > rather part of a mismatched solution)... and a client need know nothing > about the technology (other than how to use it to accomplish his/her goals). > I know this gets muddy the more technical the application gets.... but when > talking web solutions, a non-profit raising money doesn't care if it's x, > y or z web technology inasmuch as the donated hosting they have will support > it (that's just a design constraint, not anything to do with the client > problem space). In your statement, client needs to know client wants a > web-presence and a web solution... and possibly one that delivers on mobile > platforms... or has corporate security concerns ... but that's not about > technology!!!! that's about constraints client places on possible > technologies. > I think I'm tapped out on this discussion. You can see your own way. We > can agree to see it differently. > > But what remains is - _my_ problem space is providing web applications as > solutions, and what toolset(s) will allow me to do so flexibly, reliably, > and (mostly) efficiently (in terms of both my effort, and ability to provide > end user w/ performance). > > Thanks for all the discussion. > > Regards, > Yarko > > On Fri, Oct 31, 2008 at 4:27 PM, achipa <[EMAIL PROTECTED]> wrote: > > > Okay, now we are not even in generic software / ISV land but generic > > solutions talk. Which is cool, but a bit irrelevant unless you're > > doing things on the scale that nears IBM or SAP :) If I'm a baker and > > somebody suddenly comes in and says he needs apples, I won't be able > > to sell him one, but that does not mean I can't be a good baker, but > > rather that the client is lost if he want's to buy such a thing in > > such a place. The 1-2-3 is troublesome as we were talking about > > prototyping as a part of understanding the problem. This is for larger > > businesses where we first make a case study / concept and then make > > choices and solutions. For small-medium scale things, for which web2py > > is IMO most suited for, you often don't have that luxury - the > > prototype is at least halfway to the solution. The technology is VERY > > relevant as it can be a part of the spec and you can't really offer > > all possible technologies (unless, you are on the level that you don't > > do the actual development and are an integrator with dozens of > > subcontractors). If the client does not have at least a basic grasp of > > the technology (not talking about web2py or sql level) how will he > > know which solution providers he needs to turn to in the first place - > > so he's not asking for apples in the bakery mentioned above ? We can > > rename the topic to IT / B2B management now :) > > > On Oct 31, 8:15 pm, "Yarko T" <[EMAIL PROTECTED]> wrote: > > > The nature of the problem is different from the nature of the solution... > > in > > > that, the technology is _completely_ irrelevant; > > > > The solution provider's problem is [1] understanding the problem [2] > > > understanding the technology (to know what solution level can be > > > offered.... and [3] competitively costing the solution. > > > > In the second problem space, the question "what does appcelerator / and > > or > > > web2py provide me - the solution provider" - is completely relevant. > > > > Who's problem perspective we are talking about is what seems to be in > > > question. I mean appcelerator (or anything like this) is evaluated from > > the > > > perspective of solution-provider's-problem. For a discussion of the > > > differing aspects of problem vs. solution (and how you can tell which you > > > are talking about) seehttp:// > >www.ccsr.uiuc.edu/web/Techreports/1990-94/CCSR-91-14.pdf > > > > On Fri, Oct 31, 2008 at 12:24 PM, achipa <[EMAIL PROTECTED]> wrote: > > > > > We seem to be using different terminology, apart from that, I agree (I > > > > would have said defining the problem *is* a task which is part of the > > > > whole project, just as prototyping is a task/phase in itself, > > > > sometimes overlapping other tasks to an extent). The importance of > > > > clients understanding the technologies involved at least to a certain > > > > level can hardly be avoided. Otherwise, they simply won't know what is > > > > possible (and won't communicate it to you as a problem or requirement > > > > and thus will be very hard to discover). On the other side is the 'too > > > > savvy for his own good' problem, where they request a *specific > > > > solution* without both of you analyzing the problem and requirements > > > > (like requesting/specifying the development of a complex feature which > > > > has already been technologically surpassed or there is an acceptable > > > > solution available from third parties). But we digress, this is > > > > generic software development talk, and has less to do with > > > > appcelerator and web2py. > > > > > On Oct 31, 4:46 pm, "Yarko T" <[EMAIL PROTECTED]> wrote: > > > > > Defining the problem is part of the task; prototyping can help > > clarify / > > > > > validate; the preliminary part I don't think requires client > > knowledge > > > > of > > > > > technology, nor consultant/company knowledge of client problem - it > > is a > > > > > discovery phase, which is equally important when you _think_ you have > > a > > > > > grasp of what is needed. > > > > > > There is no one "right" or "best" strategy, but a bagful... but one > > > > thing > > > > > common is "rapid prototyping", or mockups, _and_ effective listening > > > > (that > > > > > is NOT jumping to solution - a common engineer's behavior, > > necessarily: > > > > we > > > > > are those who solve, after all) are all part of it. > > > > > > In terms of web application solutions, malleability of "look", > > > > presentation > > > > > to user is something that helps delivery (underlying business logic > > is > > > > > perhaps the most stable component of a solution, evolving rather than > > so > > > > > much changing; we seem to have the DB / backend part in pretty good > > > > shape). > > > > > > Proposed engineering adjuncts / solutions like Appcellerator I think > > need > > > > to > > > > > be evaluated in the light of how well it serves the engineering needs > > as > > > > I > > > > > outline above, particularly support of effectively being able to > > iterate > > > > as > > > > > client needs are better understood & discovered through a process. > > > > > > On Thu, Oct 30, 2008 at 7:40 PM, achipa <[EMAIL PROTECTED]> > > wrote: > > > > > > > We were talking about the tech part of prototyping (the idea to > > > > > > prototype phase of project). The prototyping you outline contains > > also > > > > > > a preliminary part - the development of the idea itself. Often the > > > > > > client does not really know what he wants or has a very limited > > grasp > > > > > > of the technology and solutions available. In these cases, good old > > > > > > pen and paper (even if electronic like google docs, or just > > annotated > > > > > > mockup screenshots) are a very valid and good way to go to get an > > > > > > actual spec, which then can go to tech people to be prototyped and > > > > > > developed/refined further. > > > > > > > On Oct 30, 10:38 pm, "Steve Shepherd" <[EMAIL PROTECTED]> wrote: > > > > > > > Just to pickup on the prototyping discussion, > > > > > > > I have pulled my hair out about this for over 3 years. > > > > > > > The key to prototyping is to allow very quick changing of ideas > > to > > > > match > > > > > > the > > > > > > > GOALS of the user. > > > > > > > If you code it you start pouring concrete and immediately start > > > > building > > > > > > > walls to further innovation. > > > > > > > The more effort a coder invests in developing the prototype the > > more > > > > > > > resistent to changes the mind automatically becomes. > > > > > > > I finally settle on a simple Google doc with hand drawing of the > > > > screen > > > > > > with > > > > > > > implementation notes at the bottom. > > > > > > > Its not perfect but it does allow collaboration with google docs > > and > > > > it > > > > > > > doesn't have a whole technical knowledge thing to breakdown. > > > > > > > > Below I have included an example of a screen I am developing for > > an > > > > > > > applicaiton: > > > > > > > (The square brackets are buttons and dropdowns) > > > > > > > > The Marketing Manager Main Page > > > > > > > ------------------------------ > > > > > > > * > > > > > > > [Add a Campaign] [Select an Action[v]]**- (1 to 2 of 15) > > Campaigns > > > > > > > * *Select* > > > > > > > *Title > > > > > > > * *Information > > > > > > > * *Responses* > > > > > > > * > > > > > > > ( )* > > > > > > > *Messages to Prospective Students for Hort 2 Course prior to > > them > > > > > > signing > > > > > > > up* > > > > > > > (4) Messages, Horticulture, Agri Learning Category, Followup, > > > > Modified > > > > > > > Yesterday, By Me The Information section is a combo of a number > > of > > > > fields > > > > > > of > > > > > > > information. > > > > > > > (10) People linked > > > > > > > (2) Sent a Response > > > > > > > (20% Responses) > > > > > > > (3) Added last 10 days [Adjust] > > > > > > > * > > > > > > > * *(*)* > > > > > > > *A Welcome for new Hort 2 Students before course starts.* > > > > > > > (2) Messages, Horticulture Category, Countdown, Modified Last > > Week, > > > > By > > > > > > Jan > > > > > > > Davies > > > > > > > > *Include > > > > > > > * *Filter the Campaigns > > > > > > > * [X] > > > > > > > Horticulture > > > > > > > [X] > > > > > > > Agri Learning > > > > > > > [ ] > > > > > > > Sport > > > > > > > [X] > > > > > > > Last 7 Days > > > > > > > [ ] > > > > > > > Last Month > > > > > > > [X] > > > > > > > By Me > > > > > > > [X] > > > > > > > By Others > > > > > > > *Options* > > > > > > > *Add a Filter* > > > > > > > > ------------------------------ > > > > > > > Design Info You can hover over the 2 and change the number of > > > > records on > > > > > > a > > > > > > > Page. etc etc --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
