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 "E4/position papers/Kevin McGuire"
(→Eclipse Shouldn't Look like Anything) |
(→Make it Easier to Write Plugins) |
||
| (10 intermediate revisions by the same user not shown) | |||
| Line 8: | Line 8: | ||
=== Make it Easier to Write Plugins === | === Make it Easier to Write Plugins === | ||
| − | Eclipse has grown incredibly over the years | + | Eclipse has grown incredibly over the years, but at a cost of it gradually becoming more and more difficult to write Eclipse based applications. There's simply too much to know. |
| + | |||
| + | At this point we've written most of the big, IDE like tooling suites that we are ever going to write. They will continue to be a hugely important area of application for Eclipse, driving Eclipse requirements and needing ongoing Eclipse support. But there are a vast number of smaller applications, and corresponding wider audience, that can benefit from Eclipse. But only if we shift a little the cost/benefit trade off for them, and only if we can stop looking like an IDE all the time. | ||
| + | |||
| + | We need to get back to basics so that Eclipse plugins are easier to write, where there is less a feeling of "fighting the frameworks". We need to widen the audience of who can build Eclipse plugins, and we need to make it cheaper to write them. This is the growth area for Eclipse. | ||
=== Eclipse Shouldn't Look like Anything === | === Eclipse Shouldn't Look like Anything === | ||
| − | + | As I survey the Eclipse based applications, RCP or not, they all look, well, like Eclipse based applications. Eclipse provides much power through reuse of existing components and extension of frameworks. But my goal as an application developer is to build software that is as appropriate for my audience as possible. That audience could be anybody. However, many choices we made early on in Eclipse were with an IDE user in mind and just don't work well for other user types. | |
Why should my choice of technology so blatantly drive the UI experience? I'd like all that reuse and power, thank you, but the end result shouldn't betray the technology used to build it, provided I am willing to invest in specializing it. | Why should my choice of technology so blatantly drive the UI experience? I'd like all that reuse and power, thank you, but the end result shouldn't betray the technology used to build it, provided I am willing to invest in specializing it. | ||
| − | If | + | If we compare to WorkdPress or Joomla, we see there highly energetic communities producing good content components but also separate, fantastic style sheets. I'd like to see as rich a set of graphical front ends for Eclipse. Certainly CSS helps by providing good separation of behaviour and UI, but the components must be designed to make use of this separation. |
| + | |||
| + | The Eclipse community has built some fantastic RCP applications, despite the limited and shallow variability we provide at the Presentation layer. Its not enough for us to simply extend the set of flags available. Applications should be assembled based on the set of UI components needed rather than relying on some flag to hide the element you don't want (e.g. perspectives). Eclipse based applications should be capable of the same degree of visual and interaction sophistication as web based applications. This is essential for reaching a wider audience. | ||
| + | |||
| + | == Bio == | ||
| − | + | Kevin McGuire is a platform UI contributor on the Eclipse UI team in Ottawa, working for IBM. He is a former Team/CVS committer, and was the team lead for Team/CVS in Eclipse 1.0 through to 2.x, in addition to a period as Core team lead. He's also been on the product end of Eclipse, spending three years as UI Design and Development Lead for IBM WebSphere Application Server Integration Edition and WebSphere Integration Developer. | |
Latest revision as of 18:06, 20 May 2008
Contents
Position Paper: Kevin McGuire
There are two main themes of what I'd like to see come out of e4:
- Make it easier to write Eclipse based applications so that more people can write them at reduced cost.
- Make Eclipse based applications stop looking like Eclipse based applications.
Make it Easier to Write Plugins
Eclipse has grown incredibly over the years, but at a cost of it gradually becoming more and more difficult to write Eclipse based applications. There's simply too much to know.
At this point we've written most of the big, IDE like tooling suites that we are ever going to write. They will continue to be a hugely important area of application for Eclipse, driving Eclipse requirements and needing ongoing Eclipse support. But there are a vast number of smaller applications, and corresponding wider audience, that can benefit from Eclipse. But only if we shift a little the cost/benefit trade off for them, and only if we can stop looking like an IDE all the time.
We need to get back to basics so that Eclipse plugins are easier to write, where there is less a feeling of "fighting the frameworks". We need to widen the audience of who can build Eclipse plugins, and we need to make it cheaper to write them. This is the growth area for Eclipse.
Eclipse Shouldn't Look like Anything
As I survey the Eclipse based applications, RCP or not, they all look, well, like Eclipse based applications. Eclipse provides much power through reuse of existing components and extension of frameworks. But my goal as an application developer is to build software that is as appropriate for my audience as possible. That audience could be anybody. However, many choices we made early on in Eclipse were with an IDE user in mind and just don't work well for other user types.
Why should my choice of technology so blatantly drive the UI experience? I'd like all that reuse and power, thank you, but the end result shouldn't betray the technology used to build it, provided I am willing to invest in specializing it.
If we compare to WorkdPress or Joomla, we see there highly energetic communities producing good content components but also separate, fantastic style sheets. I'd like to see as rich a set of graphical front ends for Eclipse. Certainly CSS helps by providing good separation of behaviour and UI, but the components must be designed to make use of this separation.
The Eclipse community has built some fantastic RCP applications, despite the limited and shallow variability we provide at the Presentation layer. Its not enough for us to simply extend the set of flags available. Applications should be assembled based on the set of UI components needed rather than relying on some flag to hide the element you don't want (e.g. perspectives). Eclipse based applications should be capable of the same degree of visual and interaction sophistication as web based applications. This is essential for reaching a wider audience.
Bio
Kevin McGuire is a platform UI contributor on the Eclipse UI team in Ottawa, working for IBM. He is a former Team/CVS committer, and was the team lead for Team/CVS in Eclipse 1.0 through to 2.x, in addition to a period as Core team lead. He's also been on the product end of Eclipse, spending three years as UI Design and Development Lead for IBM WebSphere Application Server Integration Edition and WebSphere Integration Developer.