search

ptsochantaris / trailer

Managing Pull Requests and Issues For GitHub & GitHub Enterprise
https://github.com/ptsochantaris/trailer
Other
1.16k stars 67 forks source link

Snooze PR/issue until next activity #243

Closed stepanhruda closed 8 years ago

stepanhruda commented 8 years ago

Now that https://github.com/ptsochantaris/trailer/issues/241 is implemented it'd be cool to have the "opposite" of muting. I'd like to completely hide a specific PR or issue from the list until there is activity in it or until a certain time expires (or perhaps a combination of both).

Basically I'd like all the PRs and issues that trailer shows me to be actionable, similarly to how I use email – either reply, archive or snooze it for later, but keep the inbox at zero. If someone submits a PR, I give them feedback and am waiting for them to implement it, it makes sense to not show the item until they reply.

tooluser commented 8 years ago

That’s an interesting idea. The first notification could cause the others on the same PR to accumulate until you decided whether you wanted it on your list, or not.

On Mar 18, 2016, at 11:42, Stepan Hruda notifications@github.com wrote:

Now that #241 https://github.com/ptsochantaris/trailer/issues/241 is implemented it'd be cool to have the "opposite" of muting. I'd like to completely hide a specific PR or issue from the list until there is activity in it or until a certain time expires (or perhaps a combination of both).

Basically I'd like all the PRs and issues that trailer shows me to be actionable, similarly to how I use email – either reply, archive or snooze it for later, but keep the inbox at zero. If someone submits a PR, I give them feedback and am waiting for them to implement it, it makes sense to not show the item until they reply.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/ptsochantaris/trailer/issues/243

stepanhruda commented 8 years ago

Could you explain what you mean a bit more? In my mind the first notification immediately brings the item back to the list, because something has changed and I need to act again. If I want the item to stay away, I need to snooze it again (and it'd be nice to have an "ignore" option where it disappears permanently).

This feature fits into a workflow where I say "show me this PR in 7 days, or show it earlier if there is any activity". If there is activity, great, do stuff and repeat. If nothing happens for 7 days, I can bug the PR owner to not keep it open for so long.

Currently this is my Trailer:

screen shot 2016-03-18 at 4 43 39 pm

A lot of these I can do nothing about. I'd be able to focus more if the icons were issues: 3, PRs: 2 which are probably the correct actionable numbers.

ptsochantaris commented 8 years ago

Hi @stepanhruda and thanks for posting this!

I think I understand your requirement and where you’re coming from in terms of UX, but I would be worried about planning out one big feature like this in it’s current form.

To be clear right off the bat, I am definitely not arguing against the usefulness of what you’re suggesting. It is immediately obvious how a “GitHub Inbox” workflow could be helpful, I’m just not sure Trailer can (or should) be that.

There are various intertwined reasons for my reluctance, but TL;DR mostly because this is a packed requirement, i.e. it would take a complex set of intertwined modifications to Trailer to support the workflow you describe, and it would end up changing Trailer into something fundamentally different.

Another concern I have is that of UI complexity. Having a set of hidden items would create two “layers” of data that the user would have to be implicitly aware of. For example, once an item has been hidden, it still needs to be accessible by the user somehow to “un-hide” it - what kind of new UI would be needed to do that? In the case of a duration/day-based hiding like you suggest, what if the user changes their mind and wants to change the “reminder” date 10 seconds after setting it?

(Of course, it can be argued that once you delete an email then it’s gone for good, but then an Inbox-style behaviour would be a radical departure from how Trailer works now - how would the existing behaviour be catered for then? It would be hard for the two over-arching “metaphors” to exist in one app in an obvious way.)

Another issue is that some of this could just be a case of wanting to integrate behaviour from the OS into Trailer: A reminder for an item can easily be set up using the system Reminders app, for instance (ah, there’s a thought, exposing an NSActivity in iOS and future OSX for allowing “remind me of this” using Siri (making a note)) but I’m not sure how tighter integration inside Trailer would improve this.

The “hide until further activity” part of your suggestion makes a lot of sense up to the point where a user needs to un-hide a specific item which they originally hid-away until further activity, which brings us back to the implicit “hidden layer” UI problem mentioned above. Sure, we can add an option like “unhide all” for instance, but that would feel like a kludge and lead to a mountain of previously hidden items falling on top of your head like Tribbles from a Quadrotriticale tank.

I guess what I’m trying to say (sorry this isn’t too well structured but I’m kinda thinking aloud :)) is that I would resist having an action that would lead to explicitly hiding (as opposed to greying out) any specific item for the above reasons.

I would also prefer (although this isn’t set in stone if there’s a good reason) to avoid adding functionality to Trailer that you can get with system apps like Reminders, unless integrating that would dramatically speed up an action.

All that said, I really do feel that the current “show only items which have comments” option is definitely bare-bones and due for some refactoring and “modernising” :) With this in mind, let’s think about breaking your requirement down into more manageable features and see what combination could get you and others as close as possible to this workflow. Suggestions / thoughts from my side:

I hope you see where I’m going with this. Again, I want to be clear that I’m not arguing against the usefulness of what you’re proposing, I'm only thinking about the scope of changes we should make to Trailer so we can best accommodate it, but without fundamentally changing Trailer’s behaviour and “mental model”.

Looking forward to hearing your thoughts on the above and anything else you think may be relevant to this. Also, let me know in case I have misunderstood any of your points!

stepanhruda commented 8 years ago

If this is not the way you want your product to go, that is a totally legit reason.

Trying to go along your suggestions:

What if there was a fourth category of PRs (on top of mine/participated/all) called "snoozed". If I right-clicked and said Snooze on a PR, it'd jump into the snoozed category from its current one. After next comment, the snoozed label would get removed and the PR would jump back. With a new checkbox in the settings "hide snoozed PRs", this would be a basic implementation of the workflow I'm looking for.

I don't want to go into philosophical discussion about workflows, but I don't think Reminders should be used for this. You could do the same with email inboxes, but there is a good reason why many of them include a snooze feature.

ptsochantaris commented 8 years ago

I really like that idea, it makes a lot of sense, it's specific, and I can see many cases where I would use it too (see for instance many cases where I use the "waiting for feedback" label in issues, those would be perfect for the Snoozed section in the issues menu)

Some thoughts (brainstorming) and questions to help shape this into something build-able, your comments are welcome on each point:

That's most of what I can think of the top of my head just now - let me know your thoughts, and I can start building the feature :)

stepanhruda commented 8 years ago

My gut feeling is that we'd want this section below all the others, not above, especially if the objective is to keep the snoozed items "out of the way", but was there a specific reason you suggested having them above the other sections?

Sorry, must have not been clear enough, definitely agree with you that Snoozed should be at the bottom.

In your mind, what are the criteria of "de-snoozing"? Is it just receiving comments, or would other events, such as assignment or mentions also constitute a "wake up" - I'm leaning towards yes? Also, apart from those events I think it's fair to guess that closing/merging will de-snooze an item and move it to the appropriate section.

I didn't want to make this complicated initially, but yes, criteria are a great feature. I imagine a radio button "Wake up PRs because of"

These are in order of noisiness, and the lower levels are supersets of the higher levels, so a merge would still wake up PRs if your choice is CI status change. Hopefully this should be obvious.

I can imagine the "snooze" submenu being a "snooze until X" list, which most probably will have a few presets plus a "custom" date picker. What do you think those presets ought to be? I'm thinking "For an hour", "For 24 hours", "For 7 days", "For a month", "Forever", and "Select a date..." but since you already have a workflow in place, what presets do you think most people would find useful there?

The following would make sense to me. Obviously this is opinionated and there is also room for user customization here.

I picture the "un-snooze" or "wake up" option in the snooze section as the accessory button - i.e. the button that in the closed/merged sections now says "remove", which would then immediately "wake up" the item and place it back in the section it was supposed to be before snoozing. Not sure if a "wake up all" button in the section header makes sense though, as accidentally hitting that would be the GitHub equivalent of hitting a gong inside a maternity ward :)

Sounds like there would be a lot of buttons since this'd be on every row of the Snoozed section. Personally I'd probably prefer a right click menu for waking up, but I am not very strongly opinionated here.

I'm thinking we don't want CI status update notifications for items that are in the Snoozed section, probably no need to even have a switch for that unless somebody explicitly requests that, although I do think we still want to have status displays, if the user has selected to turn that feature on anyway.

As noted in the criteria bullet, I think CI update could wake a PR up if you desire so (but should not be the default).

ptsochantaris commented 8 years ago

Cool - thanks for all the thoughtful input there @stepanhruda it's been extremely valuable. I think this would definitely make a good feature. Will start work on this soon and try to stick to this plan as much as possible :+1: Stay tuned!

ptsochantaris commented 8 years ago

Hi @stepanhruda - I've been tinkering and I have a test OS X build based on your suggestions above. Have a go and see how well it works for you, what you think would be good tweaks, if things break for you (disclaimer: they might) and so forth.

[link removed - please use updated link below]

In the end I really couldn't think of any sensible defaults for the snoozing list, so I made an interface for the user to create their own snoozing targets for items, so you probably want to stop there and make a few defaults that work best for you. If you have thoughts and suggestions about this prefs panel, they would of course be very welcome. (I'm already thinking that panel needs a few text "hints" about how to construct snoozing deadlines and how they work, but I'd rather hear your first impressions directly.)

If you run into problems or unexpected behaviour (2nd disclaimer: this is likely :)) please do let me know. Hope this feature is close to what you were hoping for!

ptsochantaris commented 8 years ago

Updated build with some small improvements to the snooze menu:

[link removed - please use the updated link below]

ptsochantaris commented 8 years ago

Updated build with cleanups and tweaks based on the iOS UI work as well. This, from my testing, feels good-to-go, at least for an initial feature iteration, and I'm thinking of sending an update out soon.

Happy to take any suggestions you may have on this feature onboard in the meantime!

[link removed - please use the updated link below]

ptsochantaris commented 8 years ago

Approaching release: https://www.dropbox.com/s/zii3qtj2wzwznw8/Trailer-1318-rc1.zip?dl=0

stepanhruda commented 8 years ago

Sorry, I wasn't watching this thread – will check out the build today

ptsochantaris commented 8 years ago

No worries! Let me know how it goes.

stepanhruda commented 8 years ago

Seems great for a first version 👍

from a UX perspective, I'd replace "Add a new preset" and "Delete preset" with +/- buttons, which is more standard in OS X nowadays

screen shot 2016-04-26 at 11 04 03 am

The Up/Down buttons could also be replaced by drag & drop in the preset menu, which is standard and intuitive.

stepanhruda commented 8 years ago

The segmented control item could probably say "Snooze" instead of "Snoozing"

The text on the radio buttons could drop the word "Snooze" to become shorter and easier to quickly scan, i.e.

Selected preset

O for a certain amount of time
O until a specific date/time
ptsochantaris commented 8 years ago

Thanks for the feedback @stepanhruda. Can't argue against any of your points on the +/-/Delete, they're all good, although I may end up implementing them in the next point update. Will tweak the labels now, though.

ptsochantaris commented 8 years ago

Just a quick note: If you are running any OS X before El Capitan, this development build will not migrate properly to the final version. Please be sure to export your settings before upgrading (or just do an export now and have it handy :)) so you can re-import them after the upgrade, or you will lose all your configured repos.

ptsochantaris commented 8 years ago

Hi, just wanted to let you know the final 1.3.18 is out with this feature now. Please DO take heed of the above warning if you are not running El Capitain. Many thanks for your suggestion and feedback on this issue. Looking forward to integrating your suggestion for reordering and +/- buttons in the next release too.

I hope you find this feature useful! Going to close this now, but please feel free to open more issues with further suggestions and ideas, they're obviously very welcome.