Home » Eclipse Projects » Mylyn » Fishtail - Using task context to automate web searches
| Fishtail - Using task context to automate web searches [message #38263] |
Wed, 05 December 2007 16:36  |
Eclipse User |
|
|
|
Hi everyone,
Are you constantly searching the web for resources as you program?
(E.g.: Are you searching for information about how to integrate with Eclipse?)
Gail Murphy and I have been working on a new tool, Fishtail, which uses the
context of a currently active Mylyn task to formulate web searches about the
code of interest. Searches are performed for a variety of categories, such as
articles, tutorials, and examples of code use. The goal is to bring web
resources into the development environment as you work, so that information is
readily available when you need it.
It is available at: http://www.cs.ubc.ca/labs/spl/projects/fishtail/
If you have any comments or feedback, please contact me via email at
nhapke@cs.ubc.ca.
Cheers,
Nathan
|
|
|
| Re: Fishtail - Using task context to automate web searches [message #38296 is a reply to message #38263] |
Wed, 05 December 2007 17:04  |
| Eclipse User |
|
|
|
Hi Nathan,
I've played a little with this tool but didn't noticed any relevance
between my task context and search results suggested by this view, so I
am not sold on the usefulness yet. :-)
Besides, there are several UI-related things.
First of all, it is completely unnecessary to have borders around
widgets that are put in the view. Compare it, for example, with standard
Eclipse view, i.e. Problems or History view and because screen real
estate is limited it would be useful to be able to disable the
description area and provide better markup in the tooltip for search
results.
Also, after looking at this view for some time I started to wonder why
does it have to be a separate view? There is already Help / Dynamic help
view, which seem a really good candidate for this sort of search
results. More over, there is also Mylyn's own Active Search view, that
might be another good candidate to plug in this tool into.
Another interesting aspect is that Mylyn does have core support for
tracking external resources, such as web pages with the task context.
Unfortunately in my understanding it been left out for commercial tools
to provide UI for that. So developer tools are lacking support of
managing or tracking such resources, but it would be really useful for
developers to have list of web resources or wiki pages along with the
sources relevant to the active task, i.e. show those resources right in
the Project Explorer view or on a special tab in the Task Editor.
regards,
Eugene
Nathan Hapke wrote:
> Are you constantly searching the web for resources as you program?
> (E.g.: Are you searching for information about how to integrate with
> Eclipse?)
>
> Gail Murphy and I have been working on a new tool, Fishtail, which
> uses the context of a currently active Mylyn task to formulate web
> searches about the code of interest. Searches are performed for a
> variety of categories, such as articles, tutorials, and examples of
> code use. The goal is to bring web resources into the development
> environment as you work, so that information is readily available when
> you need it.
>
> It is available at: http://www.cs.ubc.ca/labs/spl/projects/fishtail/
>
> If you have any comments or feedback, please contact me via email at
> nhapke@cs.ubc.ca.
>
> Cheers,
>
> Nathan
|
|
|
| Re: Fishtail - Using task context to automate web searches [message #38329 is a reply to message #38263] |
Wed, 05 December 2007 17:06 |
| Eclipse User |
|
|
|
Hi Nathan,
I've played a little with this tool but didn't noticed any relevance
between my task context and search results suggested by this view, so I
am not sold on the usefulness yet. :-)
Besides, there are several UI-related things.
First of all, it is completely unnecessary to have borders around
widgets that are put in the view. Compare it, for example, with standard
Eclipse view, i.e. Problems or History view and because screen real
estate is limited it would be useful to be able to disable the
description area and provide better markup in the tooltip for search
results.
Also, after looking at this view for some time I started to wonder why
does it have to be a separate view? There is already Help / Dynamic help
view, which seem a really good candidate for this sort of search
results. More over, there is also Mylyn's own Active Search view, that
might be another good candidate to plug in this tool into.
Another interesting aspect is that Mylyn does have core support for
tracking external resources, such as web pages with the task context.
Unfortunately in my understanding it been left out for commercial tools
to provide UI for that. So developer tools are lacking support of
managing or tracking such resources, but it would be really useful for
developers to have list of web resources or wiki pages along with the
sources relevant to the active task, i.e. show those resources right in
the Project Explorer view or on a special tab in the Task Editor.
regards,
Eugene
Nathan Hapke wrote:
> Are you constantly searching the web for resources as you program?
> (E.g.: Are you searching for information about how to integrate with
> Eclipse?)
>
> Gail Murphy and I have been working on a new tool, Fishtail, which
> uses the context of a currently active Mylyn task to formulate web
> searches about the code of interest. Searches are performed for a
> variety of categories, such as articles, tutorials, and examples of
> code use. The goal is to bring web resources into the development
> environment as you work, so that information is readily available when
> you need it.
>
> It is available at: http://www.cs.ubc.ca/labs/spl/projects/fishtail/
>
> If you have any comments or feedback, please contact me via email at
> nhapke@cs.ubc.ca.
>
> Cheers,
>
> Nathan
|
|
| | |
| Re: Fishtail - Using task context to automate web searches [message #38742 is a reply to message #38329] |
Mon, 10 December 2007 18:35 |
| Eclipse User |
|
|
|
Originally posted by: beatmik.acm.org
Nathan,
First, it's great to see this kind of experimentation and innovation
being done on top of Mylyn. From your message below, I'm glad to see
that the effort that you've been putting into this work is not
discouraged by the negative message below. I think that you should
probably take Eugene's complaints as a complement, because all Mylyn
committers are constantly subjected this kind of UI nit picking :)
Regarding reusing Dynamic Help, in your place I would not consider it at
this stage. While in general the heuristic of integrating with existing
UI facilities rather than adding new ones is very important, in this
case the flexibility that you would lose would likely not be worth it.
You would need to invest significant time in bringing your results into
Dynamic Help, and you would lose a lot of the flexibility that you are
getting from using a viewer (e.g. the ability to show results as a tree
view, decorate their labels, and show custom tooltips).
Lubos put it well in stating that when an idea has promise, like this
one, people will be willing to try it again. As he said, in the early
stages it took people multiple tries with Mylyn as well, and for some
I'm sure that it still does. In my experience, the trick with
integrating innovative ideas of this sort is to figure out how to get
the UI friction low enough to get enough people to try it without
investing a ton of time into the UI work, since that takes time away
from the core work and evaluation. Here are some tips that have worked
for me (note that you're following some of these already, and that some
of them are an ongoing effort in Mylyn as well):
* Decide and communicate whether you want the plug-in to be something
that people experiment with, or something that they use for their daily
development.
* If the plug-in is to be used for daily development, it should have a
very low performance footprint. What's most important is that it does
not slow down the user's Eclipse when it is not being used, otherwise
many users will quickly disable it.
* When your plug-in is doing any background work, make sure to have that
indicated in the Progress view (via the Jobs API). This will help
people trust the tool, since their Eclipse could be getting slowed down
by something else.
* Decide carefully on the UI that's needed to enable early adopters to
make use of your tool. Eclipse users tend to have a very high
expectation of UI polish, and UI work can dominate implementation time.
Try to reuse existing UIs as much as possible. When adding new UI, it
can help to follow the Eclipse UI guidelines (either the document or by
example) since this will make it easier for people to use your tool
without needing to read documentation.
* Eat your own dogfood as much as possible. If you expect others to be
able to use the tool you should be able to use it yourself (as long as
you are representative of the target audience). One of the key benefits
of consuming what you produce is that it will help you prioritize both
the performance and the UI work.
* Provide people with a public forum for feedback, since open discussion
is important to many of the open source contributors who may try it. If
you do not have a forum available you can start a discussion thread on
the Mylyn newsgroup.
* In order to get support specific to your tool from the Mylyn
committers create a Mylyn bug called "support integration with
MyCoolTool".
I've added these notes to:
http://wiki.eclipse.org/Mylyn_Integrator_Reference#Innovatin g_and_Experimenting
If anyone has feedback or additions please comment there or reply to
mylyn-dev.
Cheers,
Mik
Eugene Kuleshov wrote:
> Hi Nathan,
>
> I've played a little with this tool but didn't noticed any relevance
> between my task context and search results suggested by this view, so I
> am not sold on the usefulness yet. :-)
>
> Besides, there are several UI-related things.
>
> First of all, it is completely unnecessary to have borders around
> widgets that are put in the view. Compare it, for example, with standard
> Eclipse view, i.e. Problems or History view and because screen real
> estate is limited it would be useful to be able to disable the
> description area and provide better markup in the tooltip for search
> results.
>
> Also, after looking at this view for some time I started to wonder why
> does it have to be a separate view? There is already Help / Dynamic help
> view, which seem a really good candidate for this sort of search
> results. More over, there is also Mylyn's own Active Search view, that
> might be another good candidate to plug in this tool into.
>
> Another interesting aspect is that Mylyn does have core support for
> tracking external resources, such as web pages with the task context.
> Unfortunately in my understanding it been left out for commercial tools
> to provide UI for that. So developer tools are lacking support of
> managing or tracking such resources, but it would be really useful for
> developers to have list of web resources or wiki pages along with the
> sources relevant to the active task, i.e. show those resources right in
> the Project Explorer view or on a special tab in the Task Editor.
>
> regards,
> Eugene
>
>
> Nathan Hapke wrote:
>> Are you constantly searching the web for resources as you program?
>> (E.g.: Are you searching for information about how to integrate with
>> Eclipse?)
>>
>> Gail Murphy and I have been working on a new tool, Fishtail, which
>> uses the context of a currently active Mylyn task to formulate web
>> searches about the code of interest. Searches are performed for a
>> variety of categories, such as articles, tutorials, and examples of
>> code use. The goal is to bring web resources into the development
>> environment as you work, so that information is readily available when
>> you need it.
>>
>> It is available at: http://www.cs.ubc.ca/labs/spl/projects/fishtail/
>>
>> If you have any comments or feedback, please contact me via email at
>> nhapke@cs.ubc.ca.
>>
>> Cheers,
>>
>> Nathan
|
|
|
| Re: Fishtail - Using task context to automate web searches [message #585634 is a reply to message #38263] |
Wed, 05 December 2007 17:04 |
| Eclipse User |
|
|
|
Hi Nathan,
I've played a little with this tool but didn't noticed any relevance
between my task context and search results suggested by this view, so I
am not sold on the usefulness yet. :-)
Besides, there are several UI-related things.
First of all, it is completely unnecessary to have borders around
widgets that are put in the view. Compare it, for example, with standard
Eclipse view, i.e. Problems or History view and because screen real
estate is limited it would be useful to be able to disable the
description area and provide better markup in the tooltip for search
results.
Also, after looking at this view for some time I started to wonder why
does it have to be a separate view? There is already Help / Dynamic help
view, which seem a really good candidate for this sort of search
results. More over, there is also Mylyn's own Active Search view, that
might be another good candidate to plug in this tool into.
Another interesting aspect is that Mylyn does have core support for
tracking external resources, such as web pages with the task context.
Unfortunately in my understanding it been left out for commercial tools
to provide UI for that. So developer tools are lacking support of
managing or tracking such resources, but it would be really useful for
developers to have list of web resources or wiki pages along with the
sources relevant to the active task, i.e. show those resources right in
the Project Explorer view or on a special tab in the Task Editor.
regards,
Eugene
Nathan Hapke wrote:
> Are you constantly searching the web for resources as you program?
> (E.g.: Are you searching for information about how to integrate with
> Eclipse?)
>
> Gail Murphy and I have been working on a new tool, Fishtail, which
> uses the context of a currently active Mylyn task to formulate web
> searches about the code of interest. Searches are performed for a
> variety of categories, such as articles, tutorials, and examples of
> code use. The goal is to bring web resources into the development
> environment as you work, so that information is readily available when
> you need it.
>
> It is available at: http://www.cs.ubc.ca/labs/spl/projects/fishtail/
>
> If you have any comments or feedback, please contact me via email at
> nhapke@cs.ubc.ca.
>
> Cheers,
>
> Nathan
|
|
|
| Re: Fishtail - Using task context to automate web searches [message #585648 is a reply to message #38263] |
Wed, 05 December 2007 17:06 |
| Eclipse User |
|
|
|
Hi Nathan,
I've played a little with this tool but didn't noticed any relevance
between my task context and search results suggested by this view, so I
am not sold on the usefulness yet. :-)
Besides, there are several UI-related things.
First of all, it is completely unnecessary to have borders around
widgets that are put in the view. Compare it, for example, with standard
Eclipse view, i.e. Problems or History view and because screen real
estate is limited it would be useful to be able to disable the
description area and provide better markup in the tooltip for search
results.
Also, after looking at this view for some time I started to wonder why
does it have to be a separate view? There is already Help / Dynamic help
view, which seem a really good candidate for this sort of search
results. More over, there is also Mylyn's own Active Search view, that
might be another good candidate to plug in this tool into.
Another interesting aspect is that Mylyn does have core support for
tracking external resources, such as web pages with the task context.
Unfortunately in my understanding it been left out for commercial tools
to provide UI for that. So developer tools are lacking support of
managing or tracking such resources, but it would be really useful for
developers to have list of web resources or wiki pages along with the
sources relevant to the active task, i.e. show those resources right in
the Project Explorer view or on a special tab in the Task Editor.
regards,
Eugene
Nathan Hapke wrote:
> Are you constantly searching the web for resources as you program?
> (E.g.: Are you searching for information about how to integrate with
> Eclipse?)
>
> Gail Murphy and I have been working on a new tool, Fishtail, which
> uses the context of a currently active Mylyn task to formulate web
> searches about the code of interest. Searches are performed for a
> variety of categories, such as articles, tutorials, and examples of
> code use. The goal is to bring web resources into the development
> environment as you work, so that information is readily available when
> you need it.
>
> It is available at: http://www.cs.ubc.ca/labs/spl/projects/fishtail/
>
> If you have any comments or feedback, please contact me via email at
> nhapke@cs.ubc.ca.
>
> Cheers,
>
> Nathan
|
|
|
| AbstractRepository.credentialsComplete() not behaving as expected [message #585674 is a reply to message #38263] |
Fri, 07 December 2007 05:28 |
| Eclipse User |
|
|
|
Originally posted by: googelybear.gmail.com
Hi,
I have a small question regarding the Repository settings dialog:
AbstractRepository.credentialsComplete() validates the credentials but
only if needsAnonymousLogin() returns true - why is that so?
This doesn't make any sense to me, I mean if I set
setNeedsAnonymousLogin(false) meaning that no anonymous access is
possible the credentials should be validated as well... (of course I
could do this myself in isPageComplete() but the right place would be in
credentialsComplete())
cheers,
Dennis
(btw. is this the right place to post such questions or should I use the
mailing list instead?)
|
|
| |
| Re: Fishtail - Using task context to automate web searches [message #585793 is a reply to message #38329] |
Mon, 10 December 2007 18:35 |
| Eclipse User |
|
|
|
Nathan,
First, it's great to see this kind of experimentation and innovation
being done on top of Mylyn. From your message below, I'm glad to see
that the effort that you've been putting into this work is not
discouraged by the negative message below. I think that you should
probably take Eugene's complaints as a complement, because all Mylyn
committers are constantly subjected this kind of UI nit picking :)
Regarding reusing Dynamic Help, in your place I would not consider it at
this stage. While in general the heuristic of integrating with existing
UI facilities rather than adding new ones is very important, in this
case the flexibility that you would lose would likely not be worth it.
You would need to invest significant time in bringing your results into
Dynamic Help, and you would lose a lot of the flexibility that you are
getting from using a viewer (e.g. the ability to show results as a tree
view, decorate their labels, and show custom tooltips).
Lubos put it well in stating that when an idea has promise, like this
one, people will be willing to try it again. As he said, in the early
stages it took people multiple tries with Mylyn as well, and for some
I'm sure that it still does. In my experience, the trick with
integrating innovative ideas of this sort is to figure out how to get
the UI friction low enough to get enough people to try it without
investing a ton of time into the UI work, since that takes time away
from the core work and evaluation. Here are some tips that have worked
for me (note that you're following some of these already, and that some
of them are an ongoing effort in Mylyn as well):
* Decide and communicate whether you want the plug-in to be something
that people experiment with, or something that they use for their daily
development.
* If the plug-in is to be used for daily development, it should have a
very low performance footprint. What's most important is that it does
not slow down the user's Eclipse when it is not being used, otherwise
many users will quickly disable it.
* When your plug-in is doing any background work, make sure to have that
indicated in the Progress view (via the Jobs API). This will help
people trust the tool, since their Eclipse could be getting slowed down
by something else.
* Decide carefully on the UI that's needed to enable early adopters to
make use of your tool. Eclipse users tend to have a very high
expectation of UI polish, and UI work can dominate implementation time.
Try to reuse existing UIs as much as possible. When adding new UI, it
can help to follow the Eclipse UI guidelines (either the document or by
example) since this will make it easier for people to use your tool
without needing to read documentation.
* Eat your own dogfood as much as possible. If you expect others to be
able to use the tool you should be able to use it yourself (as long as
you are representative of the target audience). One of the key benefits
of consuming what you produce is that it will help you prioritize both
the performance and the UI work.
* Provide people with a public forum for feedback, since open discussion
is important to many of the open source contributors who may try it. If
you do not have a forum available you can start a discussion thread on
the Mylyn newsgroup.
* In order to get support specific to your tool from the Mylyn
committers create a Mylyn bug called "support integration with
MyCoolTool".
I've added these notes to:
http://wiki.eclipse.org/Mylyn_Integrator_Reference#Innovatin g_and_Experimenting
If anyone has feedback or additions please comment there or reply to
mylyn-dev.
Cheers,
Mik
Eugene Kuleshov wrote:
> Hi Nathan,
>
> I've played a little with this tool but didn't noticed any relevance
> between my task context and search results suggested by this view, so I
> am not sold on the usefulness yet. :-)
>
> Besides, there are several UI-related things.
>
> First of all, it is completely unnecessary to have borders around
> widgets that are put in the view. Compare it, for example, with standard
> Eclipse view, i.e. Problems or History view and because screen real
> estate is limited it would be useful to be able to disable the
> description area and provide better markup in the tooltip for search
> results.
>
> Also, after looking at this view for some time I started to wonder why
> does it have to be a separate view? There is already Help / Dynamic help
> view, which seem a really good candidate for this sort of search
> results. More over, there is also Mylyn's own Active Search view, that
> might be another good candidate to plug in this tool into.
>
> Another interesting aspect is that Mylyn does have core support for
> tracking external resources, such as web pages with the task context.
> Unfortunately in my understanding it been left out for commercial tools
> to provide UI for that. So developer tools are lacking support of
> managing or tracking such resources, but it would be really useful for
> developers to have list of web resources or wiki pages along with the
> sources relevant to the active task, i.e. show those resources right in
> the Project Explorer view or on a special tab in the Task Editor.
>
> regards,
> Eugene
>
>
> Nathan Hapke wrote:
>> Are you constantly searching the web for resources as you program?
>> (E.g.: Are you searching for information about how to integrate with
>> Eclipse?)
>>
>> Gail Murphy and I have been working on a new tool, Fishtail, which
>> uses the context of a currently active Mylyn task to formulate web
>> searches about the code of interest. Searches are performed for a
>> variety of categories, such as articles, tutorials, and examples of
>> code use. The goal is to bring web resources into the development
>> environment as you work, so that information is readily available when
>> you need it.
>>
>> It is available at: http://www.cs.ubc.ca/labs/spl/projects/fishtail/
>>
>> If you have any comments or feedback, please contact me via email at
>> nhapke@cs.ubc.ca.
>>
>> Cheers,
>>
>> Nathan
|
|
|
Goto Forum:
Current Time: Tue May 06 02:16:11 EDT 2025
Powered by FUDForum. Page generated in 0.07197 seconds |
Home