Bugzilla – Full Text Bug Listing
| Summary: | Move the project creation templates to the projects page | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Maciej Bendkowski <maciej.bendkowski> |
| Component: | Client | Assignee: | Project Inbox <orion.client-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | antonm, john.arthorne, ken_walker, lmsurpre, Mike_Wilson, susan |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 397721 | ||
| Bug Blocks: | |||
|
Description
Maciej Bendkowski
this should be cleared up when we implement bug 378749 comment 2, so I'll take this one. The user will be prompted ahead of time to name the folder and confirm the action. This behavior has changed a little with the commit in bug 378749, but it's still not ideal. The user now has to confirm the creation of the folder, and then we run a command that will populate the folder. So instead of a "magic folder with default name" the user is in control of the naming and creation of the folder. However, if the next part of the folder population stops (either the operation fails with an error, or the user has to provide additional info in a dialog and cancels the dialog), you are still stuck with the folder and would have to delete it. At least now the user is in control of the naming of the folder and has performed an action to create it. I'm generalizing the title of this bug. The whole workflow for "create new content" is kind of weird. As mentioned first, we create a folder and then "do something" and if that "something" fails, the user is still stuck with a folder. We can't detect that "something" failed because it's a command contributed by a plugin, and commands typically have their own error handling. Even if we could detect that the folder was empty after the operation (a likely failure)...we would have to delete the folder which would cause some additional user noise. There are some other issues, too. In bug 378749 Simon mentioned that we need to ensure the user gets a chance to confirm any workspace content that a plugin wants to contribute. For example, if a zip file is going to be imported and unzipped, we want the user to have a chance to see where it's coming from, etc. But at the same time, this a "brand new user" command and it's a bit overwhelming to say "Create new HTML site" and then be bombarded with some information that doesn't really mean much to you. We need to rework/rethink some of this... Anton and I were talking today about project-level issues such as the deployment scheme (ftp vs. git, etc.). If you think about it, the "create new content" is trying to be a "project generator" but it has no lasting value. It lets you import (or upload, or clone) content, but then it doesn't tie the content back to its origin (except for git). It seems that to make this useful, we should provide more meat behind these projects. - we need to identify the project nature somehow (so that we can resolve navigator commands against it). - we should consider having the left hand side of the navigator enumerate projects (top level folders) rather than having it enumerate file systems. In the same way that we pushed file systems to the left hand side and removed them from the tree, we could consider doing that with projects. - projects could store some default creation information (such as ftp credentials, etc.). - these credentials can be described as parameters by a plugin and then the UI generated see old thoughts/mockups in 361856 as it touches on this. Per our discussion in the UX call on 1/8/2013, the "create new content" should be removed from the navigator. Instead, the code that processes the creation templates should be available from Anton's project page. Once a project is created, the user should be able to populate it with default content. So our current "orion.navigate.content" extension point can be simplified to only deal with templates rather than trying to deal with commands such as "upload" and "sftp." I also think we should rename the extension point something like "orion.project.content" For a first step I will rework the extension point to separate the project creation part from the content generation. I'll put "create new content" as an action on a project folder and remove from the sidebar. Then, when the project page is ready, we can add a similar action there. (In reply to comment #7) > For a first step I will rework the extension point to separate the project > creation part from the content generation. I'll put "create new content" as > an action on a project folder and remove from the sidebar. > > Then, when the project page is ready, we can add a similar action there. I've done the first step. The idea is that the extension point is now correct and we'll just be moving UI around. The extension API changes: - renamed orion.navigate.content to orion.core.content (since this is just about content generation) - changed service extension API so that extensions know nothing about running commands or parameters. Instead the extension either specifies a uriTemplate link (as before) or a contentURITemplate (link) to import. - extension point no longer describes a folder name In the UI: - removed the import zip and sftp content extensions since they don't fit this simplified world and will be handled instead by the projects page - so now you have git clone, sample html5 site, or sample plugin - we use the button text as the folder name for now (in the projects page presumably the user will be generating into a folder they created). I'll update the wiki doc. The rest of this bug depends on the projects page and us figuring out exactly how the user initiates the template generation. If we end up leaving these buttons on the nav, there are accessibility issues with those buttons in bug 395383. We won't be making the projects page the landing page for 2.0, so these buttons will stay on the navigator for now. Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html |