I agree with multiple paths to content, but in the context of the question:
web apps, is multiple paths for completing tasks the same thing providing
affordances for the contextual inquiry to the content?
To me, content is a single point destination but generally contains multiple
points of interest. Getting to content is the goal but its hard to predict
which part of the content the user is specifically interested in or the
context they are coming from. I can take any number of routes around
news.bbc.co.uk to find content but I have a very focused path for printing
or sharing (web app tasks) any of those pieces of content
So conversely, tasks can be multi point paths and the goal is generally
well defined by both designer & user, the goal is also abstract from the
path. That is, using googlemaps to print out an itinary, using excel to
crunch some numbers to be inserted in to a powerpoint slide for a physical
presentation, uploading pictures to flickr to share & discuss with family.
Complex multi steps, clearly defined end point.
In practical terms I provide multiple paths to help content in my CLI & web
interface but I have yet to come across a design that aided the user when I
provided multiple options/functions/wizards/menus etc for the steps that
lead to specific task end point. The handholding might have a steeper
initial learning curve but I think the long term benefits outweigh this.
Webapp: Guide the user through a fairly specific path. The interface is a
means to an end and is in the domain of the system. ACD
Content: throw a wide net of routes to the content. The content is the goal
and is the domain of the user. UCD