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 -~----------~----~----~----~------~----~------~--~---
