| *** tosky has quit IRC | 00:18 | |
| *** tosky has joined #storyboard | 00:18 | |
| davidlenwell | persia, defeated? say it isn't so! | 00:38 |
|---|---|---|
| persia | Sadly, it seems to be. It may actually require looking at, or even writing, code to make this work. | 00:39 |
| *** tosky has quit IRC | 00:48 | |
| *** tosky has joined #storyboard | 11:16 | |
| SotK | persia: be logged in, go to the worklist you want to subscribe to, click the star | 12:11 |
| SotK | we should probably add a star on the search page like we have for other things | 12:11 |
| openstackgerrit | Adam Coldrick proposed openstack-infra/storyboard master: Fallback to Natural Language search if syntax is bad https://review.openstack.org/533353 | 13:20 |
| persia | SotK: and to subscribe to a board, one subscribes to the individual worklists? | 13:48 |
| SotK | huh, I thought we'd implemented it for boards too but it would appear I was wrong | 14:05 |
| persia | Quick patch is adding <subscribe> elements to board worklist headers, but doing so made me realise that the overall experience needs more thought, and doing that isn't necessarily right. | 14:06 |
| persia | There's some untangling that needs doing between "it is nice to allow board creators to use other folk's worklists when composing their board", and "it is not nice to be subscribed to 10 different worklists, all called "In Progress". | 14:07 |
| SotK | yep | 14:08 |
| SotK | I think we should support subscription to boards, and dissuade people from subscribing to the worklists that implement the individual lanes | 14:09 |
| persia | I suspect that untangling is why we never implemented for boards, although I don't have any fresh ideas about how to make it work less painful. | 14:09 |
| persia | Where, if one is subscribed to a board, one gets notification that items were added or removed from lanes in the board, with no reference to worklists? | 14:09 |
| SotK | persia: indeed | 14:09 |
| persia | And if people happen to use worklists on multiple boards, the notifications are different, depending on the subscribed board? | 14:10 |
| persia | If people are subscribed to individual worklists, where those worklists are also used outside boards, they would get notified of add/remove events, but presumably the worklist would have a semantically meaningful name to the subscriber. | 14:10 |
| SotK | currently sharing a worklist across boards like that isn't possible, because of the mess it would cause with permissions to edit (or sometimes even view) said worklist | 14:11 |
| SotK | and yes, I would not expect many people to want to subscribe to a worklist called "In Progress" unless they knew exactly what that specific "In Progress" meant to them | 14:12 |
| SotK | (and I think anyone who wants to subscribe to many worklists called "In Progress" would find more use out of subscribing to the boards instead | 14:12 |
| SotK | ) | 14:14 |
| persia | Yes. I think subscribing to boards is more useful, if the notification can advise the user *which* board and lane are affected. | 14:14 |
| SotK | yeah, I expect that to be the minimum useful board notification (other than something like "board name was changed") | 14:31 |
| *** jtomasek has joined #storyboard | 14:35 | |
| persia | This model of boards is very powerful, but looking at how people seem to be using them, I vaguely wonder if it may have made almost as much sense to just have a "board"-like view of worklists, segmented by task status. | 14:58 |
| persia | (not that I want to change it now: I like the facility for complex boards, use of the boards UI to create dashboard effects with automated worklists, and similar) | 14:59 |
| SotK | it would certainly have been less effort on our part | 15:08 |
| SotK | but I suspect we'd get even more requests for varied and numerous task statuses if we'd done that | 15:09 |
| SotK | and also the variety of workflows boards enable in their current state is good | 15:09 |
| persia | On the other hand, it uncovers another aspect that would benefit from documentation: it is far easier to create an "intuitive" UI for a simpler model: with this level of complexity, some docs on how to set up the simple model (automatic worklists as lanes, etc.) is far more beneficial than it might be were the system less capable. | 16:13 |
| persia | But some of that is pervasive: I found a number of phrasings ordered as "project story task" rather than "project task story" in the code while I was looking at subscriptions. Part of me suspects that we will only comprehend the set of ways in which the flexible models that are enabled by storyboard affect naive perception as we have more users who become confused. | 16:16 |
| Zara | the boards docs you suggest are another one that mostly entails copy-pasting a blogpost, should anyone want to | 16:17 |
| Zara | weird grammar but hry | 16:17 |
| Zara | *hey | 16:17 |
| Zara | phones, how do they work. | 16:17 |
| persia | Zara: Yep. The key fact I was expressing is that I'm just realising *why* it is important to show people that blog post, even though it doesn't help folk do some of the more complex things boards enable. Previously, I had the feeling that the docs would be useful for the complex bits, and it made sense to try to fix the UI so that there were fewer complex bits. | 16:23 |
| persia | Now I'm developing the opinion that docs are useful for the simple bits, and that users are likely to happily discover the rich complexity after using it for a while. | 16:23 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/storyboard master: fix rst heading styles https://review.openstack.org/533356 | 16:33 |
| SotK | I made a concept for a simplified version of the project group view which replaces the stories with a button, as we talked about the other day: https://codepen.io/StoK/full/PJBdzK/ | 19:52 |
| persia | I like that. The language seems to have all the right implications, and the interface is clean. | 20:29 |
| *** jtomasek has quit IRC | 21:12 | |
| * SotK plays with a search UI in that codepen too (click search in the sidebar) | 22:47 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!