RFC: mock-up for possible shelve/unshelve UI
Stefan
Hi,
talking to Julian about the TSVN UI for the new Shelve/Unshelve feature today, we came up with some mock-ups for that.
Posting this to this mailing list to get some feedback/discussion going on about what you think of the concepts and where you might see some limitations/pitfalls.
To initiate the (un-)shelving, you right click any folder in a working copy. This brings up the Shelve/Unshelve commands in the TSVN context menu.
In case of hovering over Unshelve, another list pops up:
This list displays the (5?) most recent shelved entries which apply to the selected directory (i.e. doesn't contain shelve-entries which contain changes in paths not descendants to the current path). Hovering over one of these entries displays a popup stating the associated comment which was entered when creating the shelved entry (see shelve GUI mockup below). Clicking one of these entries, will unshelve the entry directly (i.e. it won't bring up any detailed unshelve-dialog).
Clicking on "Show all..." will display the following detailed
unshelve-dialog.
This dialog allows you to perform more complex/advanced unshelve
operations.
Checking a shelved entry via its checkbox marks this entry to be
unshelved when clicking the OK button.
Entries which involve changes on parent paths are by default
greyed-out to prevent accidentally modifying files in paths
outside the initially right clicked folder (in the previous step).
Checking the setting "allow unshelving in different parent paths"
enables these lines and allows these previously greyed-out shelved
entries to be marked as well.
Each changeset displays the changeset name (i.e. Shelved Entry
1..3), its associated comment, and the common parent path where
the shelved entry is rooted from (relative to the current path -
where "." means the common parent path is the current path).
Note that in case of it not being the current path, the entry
displays first the relative path based on the initially right
clicked folder followed by the absolute path in brackets.
If an entry is unshelved, it will not be removed completely. It'll rather end up in the trash container, so it can be restored at a later time, if required. Note that I didn't make a sketch up for the Trash dialog, but envision a simple list of shelved entries (also showing the comments) with a possibility to completely remove these.
Right clicking an entry in the unshelve-dialog brings up a context dialog allowing the following operations:
- remove (moves the shelved entry to the trash container)
- export (exports the shelved entry as a patch file)
- merge (available only if selected at least 2 entries - to merge both shelved entries into a single entry - a popup dialog will ask for a name/comment of the merged shelved entry (defaulting to use the first shelved entry comment/name))
When clicking the "Shelve" entry in the TSVN context menu, the
following will be displayed.
The top list displays all modified files which are descendants of the initially right clicked directory.
If you want to add modified files to an existing shelved entry, select these in the top list, select the existing entry in the second list, and click the "Add" button.
If you want to create a new shelved entry for the selected files, add a name for the new shelve entry, optionally a comment, and click the "Create" button.
The caption of the Add/Create button will change based on whether or not an existing shelved entry is selected.
Selecting a row in the top list (i.e. clicking on the filename line instead of on the checkbox) will highlight that row and all existing changesets in the second list which contain already changes to that file (to easier identify a candidate for the user which he might want to add the new change to).
Right clicking any shelved entry will have the same options
available like right-clicking these in the unshelve dialog
provides.
What's your opinion on that design?
Regards,
Stefan
Stefan
On Tuesday, November 21, 2017 at 11:03:11 PM UTC+1, Luke1410 wrote:
Hi,
talking to Julian about the TSVN UI for the new Shelve/Unshelve feature today, we came up with some mock-ups for that.
Posting this to this mailing list to get some feedback/discussion going on about what you think of the concepts and where you might see some limitations/pitfalls.
To initiate the (un-)shelving, you right click any folder in a working copy. This brings up the Shelve/Unshelve commands in the TSVN context menu.
In case of hovering over Unshelve, another list pops up:
This list displays the (5?) most recent shelved entries which apply to the selected directory (i.e. doesn't contain shelve-entries which contain changes in paths not descendants to the current path).
Hovering over one of these entries displays a popup stating the associated comment which was entered when creating the shelved entry (see shelve GUI mockup below). Clicking one of these entries, will unshelve the entry directly (i.e. it won't bring up any detailed unshelve-dialog).
Clicking on "Show all..." will display the following detailed unshelve-dialog.
This dialog allows you to perform more complex/advanced unshelve operations.
Checking a shelved entry via its checkbox marks this entry to be unshelved when clicking the OK button.
Entries which involve changes on parent paths are by default greyed-out to prevent accidentally modifying files in paths outside the initially right clicked folder (in the previous step). Checking the setting "allow unshelving in different parent paths" enables these lines and allows these previously greyed-out shelved entries to be marked as well.Each changeset displays the changeset name (i.e. Shelved Entry 1..3), its associated comment, and the common parent path where the shelved entry is rooted from (relative to the current path - where "." means the common parent path is the current path).
Note that in case of it not being the current path, the entry displays first the relative path based on the initially right clicked folder followed by the absolute path in brackets.
If an entry is unshelved, it will not be removed completely. It'll rather end up in the trash container, so it can be restored at a later time, if required. Note that I didn't make a sketch up for the Trash dialog, but envision a simple list of shelved entries (also showing the comments) with a possibility to completely remove these.
Right clicking an entry in the unshelve-dialog brings up a context dialog allowing the following operations:
- remove (moves the shelved entry to the trash container)
- export (exports the shelved entry as a patch file)
- merge (available only if selected at least 2 entries - to merge both shelved entries into a single entry - a popup dialog will ask for a name/comment of the merged shelved entry (defaulting to use the first shelved entry comment/name))
When clicking the "Shelve" entry in the TSVN context menu, the following will be displayed.
The top list displays all modified files which are descendants of the initially right clicked directory.
If you want to add modified files to an existing shelved entry, select these in the top list, select the existing entry in the second list, and click the "Add" button.
If you want to create a new shelved entry for the selected files, add a name for the new shelve entry, optionally a comment, and click the "Create" button.
The caption of the Add/Create button will change based on whether or not an existing shelved entry is selected.
Selecting a row in the top list (i.e. clicking on the filename line instead of on the checkbox) will highlight that row and all existing changesets in the second list which contain already changes to that file (to easier identify a candidate for the user which he might want to add the new change to).
Right clicking any shelved entry will have the same options available like right-clicking these in the unshelve dialog provides.
What's your opinion on that design?
Stefan
On Tuesday, November 21, 2017 at 11:03:11 PM UTC+1, Luke1410 wrote:
Hi,
talking to Julian about the TSVN UI for the new Shelve/Unshelve feature today, we came up with some mock-ups for that.
Posting this to this mailing list to get some feedback/discussion going on about what you think of the concepts and where you might see some limitations/pitfalls.
To initiate the (un-)shelving, you right click any folder in a working copy. This brings up the Shelve/Unshelve commands in the TSVN context menu.
In case of hovering over Unshelve, another list pops up:
[...]
This list displays the (5?) most recent shelved entries which apply to the selected directory (i.e. doesn't contain shelve-entries which contain changes in paths not descendants to the current path).
This might be a problem: to show those context menu entries, you would have to do a lot of disk access to get the required info. But since the context menu should not cause any delays (always consider slow network shares!) disk access should be minimized as far as possible.
Good point. I talked to Julian a bit about this. I guess I'll let him think a bit about whether some caching behavior for that should be integrated on the SVN side (current gut feeling is that it should), or whether some caching-behavior would have to be added to TSVN. Or would you argue that this would not suffice?
Hovering over one of these entries displays a popup stating the associated comment which was entered when creating the shelved entry (see shelve GUI mockup below). Clicking one of these entries, will unshelve the entry directly (i.e. it won't bring up any detailed unshelve-dialog).
Clicking on "Show all..." will display the following detailed unshelve-dialog.
[...]
This dialog allows you to perform more complex/advanced unshelve operations.
I would just use this dialog and have only one unshelve command in the context menu.
In principle I'm envisioning opening up a new workflow possibility by adding these quick-access entries. It'd only be a few clicks away to restore work which you shelved and even easily combine multiple previously shelved entries, something which might be cumbersome to go through via a dialog where multiple clicks would be required to achieve the same.
Checking a shelved entry via its checkbox marks this entry to be unshelved when clicking the OK button.
Entries which involve changes on parent paths are by default greyed-out to prevent accidentally modifying files in paths outside the initially right clicked folder (in the previous step). Checking the setting "allow unshelving in different parent paths" enables these lines and allows these previously greyed-out shelved entries to be marked as well.Each changeset displays the changeset name (i.e. Shelved Entry 1..3), its associated comment, and the common parent path where the shelved entry is rooted from (relative to the current path - where "." means the common parent path is the current path).
Note that in case of it not being the current path, the entry displays first the relative path based on the initially right clicked folder followed by the absolute path in brackets.
If an entry is unshelved, it will not be removed completely. It'll rather end up in the trash container, so it can be restored at a later time, if required. Note that I didn't make a sketch up for the Trash dialog, but envision a simple list of shelved entries (also showing the comments) with a possibility to completely remove these.
Will there be a timeout period after which those trashed entries get deleted? If not, should the cleanup dialog be extended to allow cleaning of those entries?
Right clicking an entry in the unshelve-dialog brings up a context dialog allowing the following operations:
- remove (moves the shelved entry to the trash container)
- export (exports the shelved entry as a patch file)
- merge (available only if selected at least 2 entries - to merge both shelved entries into a single entry - a popup dialog will ask for a name/comment of the merged shelved entry (defaulting to use the first shelved entry comment/name))
How would conflicts be handled when merging two entries?
When clicking the "Shelve" entry in the TSVN context menu, the following will be displayed.
[...]
The top list displays all modified files which are descendants of the initially right clicked directory.
If you want to add modified files to an existing shelved entry, select these in the top list, select the existing entry in the second list, and click the "Add" button.
If you want to create a new shelved entry for the selected files, add a name for the new shelve entry, optionally a comment, and click the "Create" button.
The caption of the Add/Create button will change based on whether or not an existing shelved entry is selected.
I would use two buttons, and disable those that can't be used. i.e. disable the "Add" button if no entry in the second list is selected, and disable the "Create" button if no text is in the "New entry" box.
Sounds good to me.
Selecting a row in the top list (i.e. clicking on the filename line instead of on the checkbox) will highlight that row and all existing changesets in the second list which contain already changes to that file (to easier identify a candidate for the user which he might want to add the new change to).
Right clicking any shelved entry will have the same options available like right-clicking these in the unshelve dialog provides.
What's your opinion on that design?
Looks good so far.
Btw. we were thinking of whether this shelve/unshelve feature should be shipped with TSVN 1.10 already (i.e. assuming shelve/unshelve would be considered experimental in SVN 1.10). What's your opinion on adding an advanced setting to TSVN's conflict dialog named: "Enable experimental features" which by default would be disabled in the released builds but be enabled by default in the latest dev-nightly builds? The Shelve/Unshelve feature would then be enabled/disabled based on this setting.
Regards,
Stefan
Stefan
On Thursday, November 23, 2017 at 11:21:52 AM UTC+1, Luke1410 wrote:
On 22/11/2017 20:00, Stefan via TortoiseSVN-dev wrote:
Good point. I talked to Julian a bit about this. I guess I'll let him think a bit about whether some caching behavior for that should be integrated on the SVN side (current gut feeling is that it should), or whether some caching-behavior would have to be added to TSVN. Or would you argue that this would not suffice?
On Tuesday, November 21, 2017 at 11:03:11 PM UTC+1, Luke1410 wrote:Hi,
talking to Julian about the TSVN UI for the new Shelve/Unshelve feature today, we came up with some mock-ups for that.
Posting this to this mailing list to get some feedback/discussion going on about what you think of the concepts and where you might see some limitations/pitfalls.
To initiate the (un-)shelving, you right click any folder in a working copy. This brings up the Shelve/Unshelve commands in the TSVN context menu.
In case of hovering over Unshelve, another list pops up:
[...]
This list displays the (5?) most recent shelved entries which apply to the selected directory (i.e. doesn't contain shelve-entries which contain changes in paths not descendants to the current path).
This might be a problem: to show those context menu entries, you would have to do a lot of disk access to get the required info. But since the context menu should not cause any delays (always consider slow network shares!) disk access should be minimized as far as possible.
In principle I'm envisioning opening up a new workflow possibility by adding these quick-access entries. It'd only be a few clicks away to restore work which you shelved and even easily combine multiple previously shelved entries, something which might be cumbersome to go through via a dialog where multiple clicks would be required to achieve the same.Hovering over one of these entries displays a popup stating the associated comment which was entered when creating the shelved entry (see shelve GUI mockup below). Clicking one of these entries, will unshelve the entry directly (i.e. it won't bring up any detailed unshelve-dialog).
Clicking on "Show all..." will display the following detailed unshelve-dialog.
[...]
This dialog allows you to perform more complex/advanced unshelve operations.
I would just use this dialog and have only one unshelve command in the context menu.
Nope, the trashed entries would stay unless explicitly cleaned-up (i.e. maybe the unshelve dialog then also should get a checkbox whether it's removed directly or whether it's moved to trash). And yep, certainly... The cleanup dialog should get an option to clean things up (as should the svn cleanup command).Checking a shelved entry via its checkbox marks this entry to be unshelved when clicking the OK button.
Entries which involve changes on parent paths are by default greyed-out to prevent accidentally modifying files in paths outside the initially right clicked folder (in the previous step). Checking the setting "allow unshelving in different parent paths" enables these lines and allows these previously greyed-out shelved entries to be marked as well.Each changeset displays the changeset name (i.e. Shelved Entry 1..3), its associated comment, and the common parent path where the shelved entry is rooted from (relative to the current path - where "." means the common parent path is the current path).
Note that in case of it not being the current path, the entry displays first the relative path based on the initially right clicked folder followed by the absolute path in brackets.
If an entry is unshelved, it will not be removed completely. It'll rather end up in the trash container, so it can be restored at a later time, if required. Note that I didn't make a sketch up for the Trash dialog, but envision a simple list of shelved entries (also showing the comments) with a possibility to completely remove these.
Will there be a timeout period after which those trashed entries get deleted? If not, should the cleanup dialog be extended to allow cleaning of those entries?
Initially I was thinking of merging two shelved entries corresponding to appending one shelved entry patch file to the other. But unarguably Julian pointed out that this is quite likely to cause additional conflicts upon unshelving these merged shelve entries lateron (while the user thought that the merge-operation of two shelve-entries actually wouldn't cause such problems, since this didn't trigger any warning). Given that handling this via an alternative approach (i.e. handling conflicts at the point of merging two entries) will be quite complex, I'd simply scrub this feature from the proposal.Right clicking an entry in the unshelve-dialog brings up a context dialog allowing the following operations:
- remove (moves the shelved entry to the trash container)
- export (exports the shelved entry as a patch file)
- merge (available only if selected at least 2 entries - to merge both shelved entries into a single entry - a popup dialog will ask for a name/comment of the merged shelved entry (defaulting to use the first shelved entry comment/name))
How would conflicts be handled when merging two entries?
Btw. we were thinking of whether this shelve/unshelve feature should be shipped with TSVN 1.10 already (i.e. assuming shelve/unshelve would be considered experimental in SVN 1.10). What's your opinion on adding an advanced setting to TSVN's conflict dialog named: "Enable experimental features" which by default would be disabled in the released builds but be enabled by default in the latest dev-nightly builds? The Shelve/Unshelve feature would then be enabled/disabled based on this setting.
Stefan
On Thursday, November 23, 2017 at 11:21:52 AM UTC+1, Luke1410 wrote:On 22/11/2017 20:00, Stefan via TortoiseSVN-dev wrote:
Good point. I talked to Julian a bit about this. I guess I'll let him think a bit about whether some caching behavior for that should be integrated on the SVN side (current gut feeling is that it should), or whether some caching-behavior would have to be added to TSVN. Or would you argue that this would not suffice?
On Tuesday, November 21, 2017 at 11:03:11 PM UTC+1, Luke1410 wrote:Hi,
talking to Julian about the TSVN UI for the new Shelve/Unshelve feature today, we came up with some mock-ups for that.
Posting this to this mailing list to get some feedback/discussion going on about what you think of the concepts and where you might see some limitations/pitfalls.
To initiate the (un-)shelving, you right click any folder in a working copy. This brings up the Shelve/Unshelve commands in the TSVN context menu.
In case of hovering over Unshelve, another list pops up:
[...]
This list displays the (5?) most recent shelved entries which apply to the selected directory (i.e. doesn't contain shelve-entries which contain changes in paths not descendants to the current path).
This might be a problem: to show those context menu entries, you would have to do a lot of disk access to get the required info. But since the context menu should not cause any delays (always consider slow network shares!) disk access should be minimized as far as possible.
Caching is always a problem, since users will expect the context menu to show immediate and real entries. And if the cache is not up-to-date, this could be a problem.
Another problem which will confuse users: if you only show the last x entries in the menu, how would a user know to use the "show all" button? I'm pretty sure we will get a lot of posts on this list from users wondering where their shelves have gone...
In principle I'm envisioning opening up a new workflow possibility by adding these quick-access entries. It'd only be a few clicks away to restore work which you shelved and even easily combine multiple previously shelved entries, something which might be cumbersome to go through via a dialog where multiple clicks would be required to achieve the same.Hovering over one of these entries displays a popup stating the associated comment which was entered when creating the shelved entry (see shelve GUI mockup below). Clicking one of these entries, will unshelve the entry directly (i.e. it won't bring up any detailed unshelve-dialog).
Clicking on "Show all..." will display the following detailed unshelve-dialog.
[...]
This dialog allows you to perform more complex/advanced unshelve operations.
I would just use this dialog and have only one unshelve command in the context menu.
Well, there's also the wait time (and some users even click) to get the submenu.
Submenu:Click or wait for the submenu, click on entry, dialog shows upMaindialog:Click on entry, dialog shows up with the shelve list, doubleclick to select shelve
I don't see the gain here: instead of two clicks you get a click and a doubleclick. Not really more clicks...
Submenu:
Click or wait for submenu, click on entry, "success" dialog pops up stating the unshelving succeeded (shift+click in the previous step could correspond to not showing the success-dialog to save another click)
Maindialog:
Click on entry, dialog shows up with the shelve list, wait for the dialog to popup (which might be positioned on a different screen in multi-screen environments), *move the mouse to select the shelve-entry in the list*, *move the mouse to the "unshelve" button*, click the unshelve button, click away the dialog box
So basically where I'd see the savings is not so much the number of clicks, but having to move the cursor to click on the actual button/entry. But as said: all fine with scrubbing this idea.
[...]
Btw. we were thinking of whether this shelve/unshelve feature should be shipped with TSVN 1.10 already (i.e. assuming shelve/unshelve would be considered experimental in SVN 1.10). What's your opinion on adding an advanced setting to TSVN's conflict dialog named: "Enable experimental features" which by default would be disabled in the released builds but be enabled by default in the latest dev-nightly builds? The Shelve/Unshelve feature would then be enabled/disabled based on this setting.
Would we really need a setting for this? I'm ok with just having this enabled unconditionally.
We are trying to push the 1.10 release now so it'll get out asap. With the shelving just having been integrated in the past weeks, it's not really considered stable and there are known caveats/missing features (most notably would be the restriction of it not working with binary data atm). Being flagged as experimental in the SVN core also means that it might break in 1.11 (even though this is currently not expected and an upgrade path would be anticipated (if the underlying format changes), though this is *not* promised!). Personally I would not consider it ready for production environments just yet, that's the rational behind hiding it behind the experimental-feature idea.
Regards,
Stefan