Certainly the reduction of complexity and commoditization of function pushes the differentiation (for the pro) to the what to do, and not the 'how to do' - as exemplified by the scores of pixel pushers editing frame-by-frame film effects (think ILM). And that is not necessarily a bad thing for some professions.
My point was more to the influence of marketing and position as it effects the user interface. It certainly has not hurt the adobe suite of products. As distasteful as this may be to many idealogs in the UI world, the sustainability of a product, and its positioning amongst lead users (most often the professional users) is an important consideration. After all - continued improvement to the product should not, but sometimes does, shorten the adoption and longevity of that product. Mark On May 2, 2008, at 7:31 PM, Jared M. Spool wrote: > > On May 2, 2008, at 6:26 PM, Andrei Herasimchuk wrote: > >>> The thinking goes... if the process is to easy, then everyone can do >>> it and it erodes my (the professional user's) >>> value in the marketplace. >> >> I know of no one who has ever said that or thinks like that. Further, >> I can certainly tell you that no one on the Photoshop team ever >> thought along those lines. > > Interestingly, I have met product developers who did say that was > their objective, years ago. They were concerned that their customers, > all craftspeople who were being threatened by a commoditization of > their skills, would reject software that didn't have a learning curve > to it. > > Interestingly, the inevitable simplified software came about and, sure > enough, the crafts went mostly obsolete. In all the cases I'm aware > of, the developers are no longer in business. > > Complexity takes two forms: Tool complexity and domain complexity. > Tool complexity can (and is often) rendered simpler through advances > in interfaces. Often it's through the elimination of excessive > features and options, to core functionality. While this does reduce > the options available to the user, the reduction is often in the form > of fringe functionality. > > Domain complexity is more difficult. Here is where serious process re- > engineering needs to take place. The going-back-to-the-blackboard-and- > rethinking-the-core-processes kind-of approach. > > Reducing tool complexity does open the user to faster productivity, > but often still requires similar skill levels for the core skill. (A > simpler drawing tool doesn't help you draw any better, only more > efficiently.) > > Reducing domain complexity brings new capabilities to users who > previously couldn't master the skills. Think WYSIWYG database tools > (ala Access or Filemaker) replacing the previous code-based generation > (ala DBase or IDMS). Think desktop publishing replacing previous > typesetting activities. > > Of course, bringing capabilities to people without the formal > skillsets results a flurry of crude activity, such as the ransom-note > style publishing we saw in the early '80s. However, this flurry often > seems to die down once people realize that it does matter what you do. > Good examples and guidance such as templates help with this. > > I think it's unlikely you can make something too easy. However, > sometimes making it easier requires serious advances in the design > approaches. > > Jared > p ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
