01 March 2005

Second Generation Aggregators [2GAs]

Summary

Second Generation Aggregators [2GAs] could be designed to organize boxes of schedule-diagrams, rather than lists of feeds.

Current aggregators are more like long-lists of bookmarks. However, users may not necessarily use bookmarks and tags they way you think they do.

Users could gain if the aggregators had a pre-formatted structure that was similar to a program schedule.

2GAs:

  • will inject content to arrive into a schedule-template when the content is most useful

  • are automatic and pre-developed structures that would integrate information into user-templates.


    Second Generation Aggregators

    Providing users with information based on time and tasks


    Discussion

    I’ve been doing some thinking about linking, tags, and aggregators. It suddenly occurred to me that perhaps there is an opportunity.

    Aggregators are simplistically like a list of bookmarks. And users can find them using key words and tags.

    But have you ever though that this may not be the way that users actually do research? Some users don’t use bookmarks to tag their terms or keep track of links. Rather, they use bookmarks to track projects over time.

    That’s the key difference. And I think the potential opportunity has something to do with changing how developers think about how users could do research.

    Aggregators: Time based -vs- content based

    Assume the way you do your searches is valid. Now, put that aside for the moment. Let me introduce you to a different way of doing research.

    It’s one where bookmarks are not based on tags or terms, but they are based on time. Rather than bookmarks being kept using tags, bookmarks can be saved on the basis of time: Each day, we have a new set of bookmarks for new problems, or continuing projects.

    Each day is like a vertical line on a schedule chart. Some tasks continue, others get refined, and other tasks expand into other efforts.

    When users are working on something or doing research, their goal isn’t to find a link. Their goal is to find another nugget to move them closer to their objective. Along their plan.

    2G Aggregator: Program schedules applied to user feeds

    Think of your software development programs. There are large scheduling charts that the managers may use to track performance. These charts are how some of your users look at the web, links, and content.

    The feed-users’ goals are not to find words. Rather, their goal is to find content that moves them from where they are to where they want to go.

    Tags and bookmarks are only one way of doing research. Another way is to look at how the task is getting accomplished. Aggregators provide a structure for links: There are lists of links in the aggregator.

    However, think about how there could be structure for anything that a user is working on: Think of your program schedule.

    2G Aggregator as structure

    A user when looking for information will want templates that help them track where to apply information along their route to the objective.

    Rather than listing tags and links, aggregators could list a template like a schedule. There could be standard elements on the left side:


    Planning Factors


  • Coordination
  • Research
  • Oversight
  • Testing


  • Horizontally, the template could have categories like:


    Time-related activities


  • Planning tools
  • Preliminary questions
  • Simple efforts
  • Integration
  • Testing
  • Success criteria
  • Objectives


  • The key will be to inject the feeds into this square-shape, and assign information when it is most needed along that framework.

    Things that would be good to put into this template and could be tagged:


    Types of Research Tasks


  • Performance ideas
  • Training
  • Focus
  • Niche finding
  • Evaluating audience needs
  • Quality standards
  • Oversight
  • Identifying gaps
  • Execution and implementation


  • These types of things are what users could have automatically injected into a tool that would be different that simple bookmarks and lists in current aggregators.

    Rather than simply look up simple terms and look for a single word, users might actually be doing more complicated searches. And an integrated aggregator-schedule planning tool would do this.


    LEGAL NOTICE


    Creative Commons License

    This work is licensed under a Creative Commons License.

    You may not copy any of this work to promote a commercial product on any site or medium in the universe.

    If you see this work posted on a commercial site, it violates the creative commons license; and the author does not endorse the commercial product.

    Free to use for non-commercial uses. Link to this original blogspot and cite as .


  • Summary

    Second Generation Aggregators [2GAs] could be designed to organize boxes of schedule-diagrams, rather than lists of feeds.

    Current aggregators are more like long-lists of bookmarks. However, users may not necessarily use bookmarks and tags they way you think they do.

    Users could gain if the aggregators had a pre-formatted structure that was similar to a program schedule.

    2GAs:

  • will inject content to arrive into a schedule-template when the content is most useful

  • are automatic and pre-developed structures that would integrate information into user-templates.


    Second Generation Aggregators

    Providing users with information based on time and tasks


    Discussion

    I’ve been doing some thinking about linking, tags, and aggregators. It suddenly occurred to me that perhaps there is an opportunity.

    Aggregators are simplistically like a list of bookmarks. And users can find them using key words and tags.

    But have you ever though that this may not be the way that users actually do research? Some users don’t use bookmarks to tag their terms or keep track of links. Rather, they use bookmarks to track projects over time.

    That’s the key difference. And I think the potential opportunity has something to do with changing how developers think about how users could do research.

    Aggregators: Time based -vs- content based

    Assume the way you do your searches is valid. Now, put that aside for the moment. Let me introduce you to a different way of doing research.

    It’s one where bookmarks are not based on tags or terms, but they are based on time. Rather than bookmarks being kept using tags, bookmarks can be saved on the basis of time: Each day, we have a new set of bookmarks for new problems, or continuing projects.

    Each day is like a vertical line on a schedule chart. Some tasks continue, others get refined, and other tasks expand into other efforts.

    When users are working on something or doing research, their goal isn’t to find a link. Their goal is to find another nugget to move them closer to their objective. Along their plan.

    2G Aggregator: Program schedules applied to user feeds

    Think of your software development programs. There are large scheduling charts that the managers may use to track performance. These charts are how some of your users look at the web, links, and content.

    The feed-users’ goals are not to find words. Rather, their goal is to find content that moves them from where they are to where they want to go.

    Tags and bookmarks are only one way of doing research. Another way is to look at how the task is getting accomplished. Aggregators provide a structure for links: There are lists of links in the aggregator.

    However, think about how there could be structure for anything that a user is working on: Think of your program schedule.

    2G Aggregator as structure

    A user when looking for information will want templates that help them track where to apply information along their route to the objective.

    Rather than listing tags and links, aggregators could list a template like a schedule. There could be standard elements on the left side:


    Planning Factors


  • Coordination
  • Research
  • Oversight
  • Testing


  • Horizontally, the template could have categories like:


    Time-related activities


  • Planning tools
  • Preliminary questions
  • Simple efforts
  • Integration
  • Testing
  • Success criteria
  • Objectives


  • The key will be to inject the feeds into this square-shape, and assign information when it is most needed along that framework.

    Things that would be good to put into this template and could be tagged:


    Types of Research Tasks


  • Performance ideas
  • Training
  • Focus
  • Niche finding
  • Evaluating audience needs
  • Quality standards
  • Oversight
  • Identifying gaps
  • Execution and implementation


  • These types of things are what users could have automatically injected into a tool that would be different that simple bookmarks and lists in current aggregators.

    Rather than simply look up simple terms and look for a single word, users might actually be doing more complicated searches. And an integrated aggregator-schedule planning tool would do this.


    LEGAL NOTICE


    Creative Commons License

    This work is licensed under a Creative Commons License.

    You may not copy any of this work to promote a commercial product on any site or medium in the universe.

    If you see this work posted on a commercial site, it violates the creative commons license; and the author does not endorse the commercial product.

    Free to use for non-commercial uses. Link to this original blogspot and cite as .


    " />