Bug 346136

Comment 1 John Arthorne 2011-05-17 16:51:28 EDT

*** This bug has been marked as a duplicate of bug 346070 ***

Comment 2 Boris Bokowski 2011-05-17 21:08:00 EDT

Sorry but this is not really a duplicate of bug 346070. 

I would suggest the following:

1. On the repositories page, have a text field for entering a Git repository URL. No need to open a dialog after pressing a button, we have enough screen real estate to show the text field right away.
2. Changing the text field triggers (with a time delay) a validation function. If the entered text looks like a valid git URL, determine if the repository name already exists as a top-level folder. If yes, display feedback that the folder name already exists, and go to 4, otherwise, go to 3.
3. Enable the button called "Clone" next to the text field. Pressing this button will start the clone operation with default options, and will end up creating a new top-level folder with the same name as the repository.
4. Close to the "Clone" button, we have a smaller button or link "Options". Clicking on it opens a dialog, or better reveals more options in the page itself, where you can enter optional information like the target folder name. If more options are revealed on the page itself, they should appear between the text field and the "Clone" button so that this remains the button to trigger the clone operation. We can validate the additional options such that the Clone button will be enabled as soon as the clone operation could succeed.

Comment 3 Boris Bokowski 2011-05-17 21:08:23 EDT

Created attachment 195932 [details]
mock-up

Comment 4 Szymon Brandys 2011-05-18 04:27:50 EDT

(In reply to comment #2)

I like the idea. There are already bugs opened for getting rid of dialogs in Orion. See for instance bug 334044, where we talk about using a filter field instead of a dialog for opening resources. I think that we could also get rid of dialogs for creating/linking files and folders.

You wrote in 3) 
> "Pressing this button will start the clone operation with default options, and will end up creating a new top-level folder with the same name as the 
> repository."

Right now, when you clone a repo for the first time, you may clone it to any workspace location. So I guess that 'Options' are enabled always and I can change the workspace path even during cloning for the first time.

> 4. Close to the "Clone" button, we have a smaller button or link "Options". Clicking on it opens a dialog, or better reveals more options in the page itself, where you can enter 
> optional information like the target folder name.

I think we should reveal more options in the page instead of showing a dialog. In Bug 342739 we have a discussion about how to gather ssh credentials during Git operations. I would expect that when a Git URL is entered and it requires authentication, the page itself will show more fields to gather credentials. I wonder if we should show the workspace location picker as a dialog or reveal it in the page.

Comment 5 Boris Bokowski 2011-05-18 08:15:56 EDT

(In reply to comment #4)
> Right now, when you clone a repo for the first time, you may clone it to any
> workspace location. So I guess that 'Options' are enabled always and I can
> change the workspace path even during cloning for the first time.

Sure - it should always be possible to provide additional information. We might add more options in the future, too. My point was that we should optimize for the 80% case, and hide optional UI behind a mechanism like an Options button/link.

Comment 6 John Arthorne 2011-05-18 09:18:59 EDT

Another choice for additional options is a tooltip dialog:

http://docs.dojocampus.org/dijit/TooltipDialog

Comment 7 Tomasz Zarna 2011-05-18 10:13:55 EDT

(In reply to comment #2)
> 3. Enable the button called "Clone" next to the text field. Pressing this button
> will start the clone operation with default options, and will end up creating a
> new top-level folder with the same name as the repository.

I will address this one in bug 346070.

Comment 8 Susan McCourt 2011-05-18 13:50:11 EDT

I think we should focus on workflow and not too much on dialog technology.  I will do something to make the dialog experience better, but based on our use of dojo and templating, it might not be any better than lighter styling and sticking the dialog up closer to the command that launched it.

For cases where we can infer a default, or are only collecting a single item of info, I think we need to tackle that at the specific workflow level and not assume that the command framework will make it better/easier.

I personally do not like the look of the TooltipDialog, but I was going to see if it could be styled away any easier than dijit.Dialog (I was hoping to style away the title bar but have not been successful).

Comment 9 John Arthorne 2011-06-13 08:37:04 EDT

Can this now be marked fixed? I now just have to paste a Git URL and click "Clone". What other specific changes are planned for this bug?

Comment 10 Szymon Brandys 2011-06-25 05:58:41 EDT

Fixed.