| [spaces-dev] Spaces design goals and EclipseCon |
|
I was going to send Henrik an email before our call tomorrow, but
instead I decided I'd just send it to the whole list. _________ General Design Ideas ___________ I original envisioned Spaces as a light-weight way for non-Eclipse-insiders to share plug-ins. Based on conversations with you all, I've expanded the idea to sharing any Eclipse project. My idea is that the user interface/experience should be as simple as possible. I envisioned a five element context menu associated with projects: Spaces > Publish, Spaces > Share, Spaces > Promote, Spaces > Collaborate, and I forget the fifth one just now so let's go with Spaces > URLs. Each of these would invoke a wizard to step the user through the process of publish/share/etc. to a spaces provider. Publish is about publishing a project as a consumable binary. My original idea was that it would take a single plug-in project and package it up as an update site (with a feature.xml, site.xml, etc) and upload all the necessary files to the spaces provider. Later discussion convinced me that publishing multiple plug-ins at once seemed like a good idea, so if one does that the feature.xml references all of them. Each spaces provider will have its own format for storing these files and for the login/password mechanisms to get to those files and for what kind of public url will return the files. The user will do a Spaces > Publish (providing the login/password or whatever) and will get back (in a dialog) the public url to the update site. Then he/she can email that url to friends, post it in a blog, whatever and, voila, those friends/the greater outside world can install this user's plug-in in their own Eclipse and use it. Spaces providers will probably store login/password information in the preferences or resources or something so that people don't have to login in each time. Also, if the user has no account/login/password, the provider will step the person through the process of signing up for a new account/spaces account. The Spaces > Share menu item steps the user through the process of connecting the project to a CVS or SVN repository on the spaces provider. Once the connection is set up, the Spaces > Share does a Team > Synchronize... action. Users will have to know enough about source code control to know what to do next (update, commit, etc). The Spaces > Promote menu item steps the user through the process of promoting their work on the spaces provider and perhaps other places like Eclipse Plug-in Central. Promotion probably includes writing a little blurb about the plug-in and maybe a picture or logo. And the promotion adds it to the appropriate interesting new things list for that spaces provider. The Spaces > Collaborate menu item steps the user through the process of connecting to a mailing list, newsgroup, forum, wiki page, irc channel, or whatever that spaces provider provides for communicating with users of the plug-in. For example, the spaces provider provides each spaces user with a forum (sort of like a Myspace page or something), then this wizard will help the user set up that initial forum. Once the collaboration space is set up (the mailing list, wiki page, whatever), then the Spaces > Collaborate menu item takes the user to that place. Note: all these Spaces > ... menu items are designed to work the same way: the first time, they set things up. Thereafter, they take the user to correct place or do the correct action. Publish: setup, then re-publish; Share: setup, then synchronize. Promote: setup, then go to the promotion. Collaborate: setup, then go to the collaboration. The Spaces > URLs opens a dialog that shows the public urls for the various published, shared, etc. pieces. Thus if I forgot what the url for the update site for my project is, I can use Spaces > URLs and it will be listed. Same for the public url to my source code repository. Etc. _________ EclipseCon ___________ There are hundreds of talks and tutorials at EclipseCon. We will (through emails to the authors) encourage the authors to make their samples and example code available via Spaces. I imagine an uptake of 20% of the authors, thus perhaps ~80 authors. I hope that we can have a Spaces > Promote item that promotes their work on their EclipseCon talk detail page. At the time, we will invite attendees (again, through emails) to get the example code from Spaces (by going to the public urls linked to from the EclipseCon talk detail pages) and to play around with it and to publish/share their own versions of the code through a spaces account. I would anticipate a 10% pick before the conference and maybe another 10% at EclipseCon (~150 and then another 150). Thomas Hallgren wrote: One of the goals for Spaces is to simplify. We don't want to force the full complexity of plugins, features, and update sites (or OBR's for that matter) onto the user. He has a plugin that he wants to make available. Click, click. It shouldn't be more complicated than that. Ideally, the user right-clicks on a plug-in project, and he clicks "Publish", clicks OK in the wizard that pops up, and that's it. The default values in the wizard should be such that the plug-in is published and readily available.Exactly, I agree 100%. Some things to consider in order to make it that simple are:My idea was that we would auto-generate a feature for the plug-in so that we can have an Eclipse update site (update sites only work with features, right)? Where do we draw the line between simplicity and functionality?We should go with simplicity and then provide the person with a url link to "the real story" that explains how to do more if they want to do more. - Bjorn --
|