Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Search UIWG Walkthrough"
(→Other thoughts) |
|||
| (6 intermediate revisions by one other user not shown) | |||
| Line 5: | Line 5: | ||
== Prep/Homework == | == Prep/Homework == | ||
| + | :None | ||
== Discussion Topics == | == Discussion Topics == | ||
| − | + | :How to make the Search Criteria and Search Results combined in a single View. | |
== Discussion Notes from Walkthrough == | == Discussion Notes from Walkthrough == | ||
| + | |||
| + | :Bogdan Vatkov made a quick walk-through on the pain points in the current Search UI in Eclipse. The main point is that defining search criteria and looking at search results are tightly connected tasks. Therefore, it is quite natural to have them in one and the same view. See the attached slides for details. | ||
| + | :Kevin McGuire presented a concept that is very close to Bogdan's proposal. He mentioned that there are dev resources needed to realize this experimental search form - may be the interested parties in the community can help? The Platform team is open on making changes. | ||
| + | ::Clarification by Kevin: | ||
| + | ::''I actually don't own or maintain Search UI. I just have lots of opinions on lots of things and that provides the illusion of ownership :) I am though a platform committer and care about Search. I have no planned enhancements to Search and am not aware of plans in this area. What I showed in the call was some ideas I had resulting from investation two years ago. Its healthy for us to have some new thinking in this area so I'd like to encourage this effort!'' | ||
| + | ::''If the community wants to put some heads and hands together, I can help by providing some input and guidance, but the platform team hasn't resources to apply much above that of guidance, sadly. Dani Megert (committer for platform, text, JDT) is also interested in this topic. We said we'd have a follow up call and he'd like to be on it.'' | ||
| + | ::''If there's energy behind this then by all means lets do some exploration as a tweaklet and see how it plays out. I'd advise front-loading this work in the 3.5 release cycle to give lots of time for feedback and iteration if something is to come of it.'' | ||
| + | :There were people on the call that were in favor with the proposed new search concept and others that like the existing one. Therefore, the following was concluded: | ||
| + | :*There should be simple and advanced search modes in one and the same view. User make the choice for the mode. | ||
| + | :*Eclipse could provide Search UI for both old and new concepts and not sacrificing any of them. | ||
| + | ::Clarification by Kevin: | ||
| + | ::''My thought was that we could do it as a tweaklet which would allow people to experiment with it. That could also be considered as a delivery vehicle if it was decided not to make it the default. I believe tweaklets are the right way to provide opt-in feature changes (v.s. the old approach of adding preferences). Given that we now have this lovely P2 work, people can and will hang onto their workspaces longer, so my hope is tweaklets become a more common mechanism.'' | ||
| + | ::''It'd be cool to see a variety of tweaklets from the community, available for people to customize their IDE with, much as they do with Firefox add-ons.'' | ||
| + | ::''Tweaklets are a way to experiment with new UI features which replace existing ones. An example is Boris' exploration of editor tab management; he did one that provides more of a Firefox model of tab reuse and management.'' | ||
| + | ::''Tweaklets work by providing a non-API access point within existing platform code so that the substitute behaviour can be inserted via an extension point. This way, incubator exploration work can be layered above the platform in a low risk, low impact to the platform, non future-API-binding manner.'' | ||
| + | ::''I thought we had a page on this but I can't find one. The only reference I can find is in the UI incubator page, [[Platform UI Incubator]]. In any case, see org.eclipse.ui.internal.tweaklets.TabBehaviour as the example mentioned above.'' | ||
== Conclusions/To-do's == | == Conclusions/To-do's == | ||
| + | :Start with a Bugzilla bug to collect our initial resources from this walk-through - documents, notes, etc. (Bogdan and Kaloyan) | ||
| + | ::Done - see [https://bugs.eclipse.org/242235 bug 242235] | ||
| + | :Bogdan Vatkov will send the presentation slides. (done with this mail) | ||
| + | ::Done - see the [https://bugs.eclipse.org/bugs/attachment.cgi?id=108540 attachment] in the bug | ||
| + | :Kevin will send a document describing his new experimental search form. | ||
| + | ::Done - see [[UIWG SearchUIAnalysis]] | ||
| + | :Follow-up call in few weeks - there will be more people coming back from vacation. Until then discussions continue in the mailing list and Bugzilla. | ||
== Other thoughts == | == Other thoughts == | ||
| − | [[UIWG_SearchUIAnalysis|Kevin's Search UI Analysis from 10/20/06]] | + | :[https://bugs.eclipse.org/242235 Enhancement bug 242235] |
| + | :[https://bugs.eclipse.org/bugs/attachment.cgi?id=108540 Walkthrough slides] | ||
| + | :[[UIWG_SearchUIAnalysis|Kevin's Search UI Analysis from 10/20/06]] | ||
| + | :Wind River's text search results UI with integrated controls - {{bug|118200}} - [https://bugs.eclipse.org/bugs/attachment.cgi?id=30696 Proposal with Screenshots (PDF)] | ||
| − | |||
[[Category:User Interface Best Practices Working Group]] | [[Category:User Interface Best Practices Working Group]] | ||
Latest revision as of 12:00, 30 July 2008
Contents
Search UI Walkthrough Eclipse UI Best Practices Working Group 7/9/2008
Prep/Homework
- None
Discussion Topics
- How to make the Search Criteria and Search Results combined in a single View.
Discussion Notes from Walkthrough
- Bogdan Vatkov made a quick walk-through on the pain points in the current Search UI in Eclipse. The main point is that defining search criteria and looking at search results are tightly connected tasks. Therefore, it is quite natural to have them in one and the same view. See the attached slides for details.
- Kevin McGuire presented a concept that is very close to Bogdan's proposal. He mentioned that there are dev resources needed to realize this experimental search form - may be the interested parties in the community can help? The Platform team is open on making changes.
- Clarification by Kevin:
- I actually don't own or maintain Search UI. I just have lots of opinions on lots of things and that provides the illusion of ownership :) I am though a platform committer and care about Search. I have no planned enhancements to Search and am not aware of plans in this area. What I showed in the call was some ideas I had resulting from investation two years ago. Its healthy for us to have some new thinking in this area so I'd like to encourage this effort!
- If the community wants to put some heads and hands together, I can help by providing some input and guidance, but the platform team hasn't resources to apply much above that of guidance, sadly. Dani Megert (committer for platform, text, JDT) is also interested in this topic. We said we'd have a follow up call and he'd like to be on it.
- If there's energy behind this then by all means lets do some exploration as a tweaklet and see how it plays out. I'd advise front-loading this work in the 3.5 release cycle to give lots of time for feedback and iteration if something is to come of it.
- There were people on the call that were in favor with the proposed new search concept and others that like the existing one. Therefore, the following was concluded:
- There should be simple and advanced search modes in one and the same view. User make the choice for the mode.
- Eclipse could provide Search UI for both old and new concepts and not sacrificing any of them.
- Clarification by Kevin:
- My thought was that we could do it as a tweaklet which would allow people to experiment with it. That could also be considered as a delivery vehicle if it was decided not to make it the default. I believe tweaklets are the right way to provide opt-in feature changes (v.s. the old approach of adding preferences). Given that we now have this lovely P2 work, people can and will hang onto their workspaces longer, so my hope is tweaklets become a more common mechanism.
- It'd be cool to see a variety of tweaklets from the community, available for people to customize their IDE with, much as they do with Firefox add-ons.
- Tweaklets are a way to experiment with new UI features which replace existing ones. An example is Boris' exploration of editor tab management; he did one that provides more of a Firefox model of tab reuse and management.
- Tweaklets work by providing a non-API access point within existing platform code so that the substitute behaviour can be inserted via an extension point. This way, incubator exploration work can be layered above the platform in a low risk, low impact to the platform, non future-API-binding manner.
- I thought we had a page on this but I can't find one. The only reference I can find is in the UI incubator page, Platform UI Incubator. In any case, see org.eclipse.ui.internal.tweaklets.TabBehaviour as the example mentioned above.
Conclusions/To-do's
- Start with a Bugzilla bug to collect our initial resources from this walk-through - documents, notes, etc. (Bogdan and Kaloyan)
- Done - see bug 242235
- Bogdan Vatkov will send the presentation slides. (done with this mail)
- Done - see the attachment in the bug
- Kevin will send a document describing his new experimental search form.
- Done - see UIWG SearchUIAnalysis
- Follow-up call in few weeks - there will be more people coming back from vacation. Until then discussions continue in the mailing list and Bugzilla.
Other thoughts
- Enhancement bug 242235
- Walkthrough slides
- Kevin's Search UI Analysis from 10/20/06
- Wind River's text search results UI with integrated controls - bug 118200 - Proposal with Screenshots (PDF)