Loading ...
Sorry, an error occurred while loading the content.
Advanced Search
Author
Subject
Message
Special notice only

131 results from messages in agile-usability

Advanced Search
  • -- In agile-usability@^$1, George Dinwiddie wrote: > > Hi, Scott > > On 12/6/10 10:48 AM, scott wrote: > > However, there's another point in Larry's paragraph that's important. > > A designer, concentrating only on the design, can iterate that design > > a lot faster > > Yes, all of that is true. But that's not where the learning stops. The > design, iterated on paper or through...
    scott Dec 7, 2010
  • --- In agile-usability@^$1, William Pietri wrote: > Of course, that's mainly your business. This one part, though, I take > real exception to: > > > What we really want to avoid is letting the developers design. They are developers, not designers, and waiting for them to design something then reacting to it is NOT what our clients pay us for. We are tasked with being proactive...
    scott Dec 6, 2010
  • I would lean towards a commercial taxonomy-management tool built on top of a database. When we looked at this, we found that the functional requirements for the tool were a lot heavier than we wanted to implement ourselves, especially if you have multiple people working on the taxonomy simultaneously. If you're working on a commercial site, and building a taxonomy large enough to...
    Scott Preece Feb 25, 2010
  • Fetching Sponsored Content...
  • Well, IF you have people who are fully qualified to perform both roles, then by all means, have them do both roles. That's the lowest-friction, lowest-waste approach. On the other hand, both roles require specialized knowledge and training, so most teams will find they don't have people who are qualified to do both and will either need to separate the roles or allow one person to...
    Scott Preece Feb 15, 2010
  • Yes, and both of those refer to approaches (processes, procedures) that are "methodical", i.e., planned or formalized, not just "what I did". American Heritage dictionary allowed a sense that would apply to an ad hoc method, but preferred the sense of a planned process... Note Glen's original statement, "methods have little to do with success" - while you can loosely apply "method...
    Scott Preece Feb 9, 2010
  • It's not my fault the dictionary says what it says... scott ----- Original Message ---- > From: George Dinwiddie > To: agile-usability@^$1 > Sent: Mon, February 8, 2010 1:51:07 PM > Subject: Re: Error Management (was RE: [agile-usability] Re: Real data) > > Scott, Jon, > > While many people like to formalize and generalize what they do into > named descriptions they call methods...
    Scott Preece Feb 8, 2010
  • I believe Jon is right. The word "method" generally implies a planned approach, not just "what was done". Now, if you observe what was done and then do it that way again, it becomes a method, so it's a little ambiguous. scott ----- Original Message ---- > From: Jon Kern > To: agile-usability@^$1 > Sent: Sat, February 6, 2010 10:32:36 PM > Subject: Re: Error Management (was RE...
    Scott Preece Feb 7, 2010
  • Hi, I think there are practices that would make it less likely that such an error would occur. I'm not an expert in the area, but some thoughts that occur to me are: Tthere are tools for state-space exploration that could verify that constraints like "NOT (FULL_POWER AND NO_SHIELD)" are never violated in any attainable system state, but you still have to consciously come up with...
    Scott Preece Feb 3, 2010
  • Well, a lot of software shops do specialize and can estimate pretty reasonably based on experience. When you get into "never done before", you're probably going to do some sketching to decompose the problem into pieces that you've built before or can compare to things you've built before. Obviously, resolution and accuracy go down as you get farther away from what you know. regards...
    Scott Preece Feb 2, 2010
  • This presupposes that one vendor is in the right place to solve the whole problem - from understanding the problem, to proposing and designing a solution, to implementing that solution. I don't know that I would support that as a general rule. In the scenario you describe, the companies capable of each different approach may well NOT be capable of the others - the people who could...
    Scott Preece Dec 9, 2009