#98 #halp/help widget: Default in the CommOps Hub

Created a year ago by decause
Modified 7 months ago


This is a new widget, that displays #help/#halp requests from meetings in a widget. This should be a default widget on the commops hub, which is #97.

HelpWidgetFinal.png - 2016-06-24 13:00:16 Comment Download
HelpWidgetRework.png - 2016-07-11 03:30:14 Comment Download
HelpImproved.png - 2016-08-12 18:01:20 Comment Download
help_widget.png - 2016-09-13 19:14:55 Comment Download
help_widget-request_modal.png - 2016-09-13 19:14:55 Comment Download
help_widget-all_requests-modal.png - 2016-09-13 19:14:55 Comment Download

So, should this widget have zero configuration? For commops at least, I think they want #halp/#help messages from all the other teams/meetings.

it might be worth having config available to filtering the help/halps displayed to a specific group(s) halps, so the widget could be re-used on other hubs (like a help/halp widget for design-team meetings to display on the design team hub)

This will be pretty similar in code to the stuff we need for #26.

This is my basic level of understanding about the help widget.

The user asks for help in the IRC channel which might be specified in a semi-structured format. The Json has to be populated and it is sent to the back-end. Next, it gets pushed to the help widget where it is converted into a format which is understandable to the user.

Some use cases that I can think of are :

  • How would the user specify in IRC channel ? ( Tagging maybe one solution)

  • How will we display the message in the help widget ?

  • What all we would want to show in the help widget?

  • How to configure the help widget?

These are some use cases I have in mind, do share your feedback on this. Further, feel free to let me know if I had mis-understood the feature.

From today's meeting:

<mizmo> radhikak, i think the way it works based on the fedmsg doc entry is that someone in a
meeting uses the #help hashtag in a meeting

<pingou> correct

<mizmo> each meeting has a topic/team

<mizmo> and the person will write a message to go with the #help tag

<mizmo> and the msg of course will have a date

<mizmo> so i'd suggest something - to use the docs example -

<pingou> #help radhikak would like feedbacks on her thoughts on the ticket https://pagure.io

<mizmo> the help widget could have a listing by team of who needs helpk, eg

<mizmo> "“The #fedora-apps team needs people to help review code http://ambre.pingoured.fr

<mizmo> they could be broken down by team / meeting name / or even date

<pingou> (where have I seen this one before?)

<pingou> and person I guess

<mizmo> probably the newest ones should be most prominent and the oldest ones should scroll
off bc as it gets older probably less likely they still need the help

<mizmo> yeh the person who called for help should be listed next ot each item

<mizmo> i guess maybe think of it like a bulletin board where people are looking for babysitters
or dog walkers or whatever, the help widget is sort of abulletin board where people look for help
across the project

Edited a year ago by duffy

Here are some thoughts about the design I have done so far

  1. The first three mockups show the drop down and filtering by name, meeting name and date. This accordion will have auto-suggestion feature. (Much like the first pattern in https://harvesthq.github.io/chosen/ )
  2. The last two mockups show the when the user has already been helped and the listing disappears by sliding to the left. Probably giving the user an update on the state i.e whether the issue has been resolved or not would be great.
  3. The most recent call for help will be shown at the top based on the date of the posting.

Some improvements

I probably would like to change the pencil icon as it suggests edit, would love to get some ideas for that icon.

Edited a year ago by radhikamani88

Here's the comments pagure ate when it went down:

1) These look great! The general style / flow I think looks right! Good work!

2) I would be more judicious / use a lighter hand with the magenta. It really pops - so many reserve it for only the very most important thing. I'd suggest maybe making the icons grey instead of magenta. And maybe keeping the team names magenta - I think it's okay to have that magenta bc those are probably the 1st most important thing for people looking at the list: they want to help with stuff, but want to quickly hone in on things they actually have skills to help with! (what do you think?)

3) You can probably drop a lot of the labels on some of the metadata. E.g., drop the "team:" in "team: fedora-design", drop the "date:" from "Date: 06-25-2016." I think it's clear without having the label and you'll save space / get a cleaner design by dropping them.

4) You might not need to have status: open at all, right? because if it's closed, then it wouldn't show up in the list at all. Unless you're using it as a mechanism to let users close the ticket, in which case -

5) Have you thought about mocking up the mechanism to mark a ticket closed / unneeded? The last two look like they show an animation of the closed ticket sweeping right and the next most recent ticket coming in, but how do you get to that point?

6) I'm not following the system for the icon displays here. There's a pencil for some and a photo icon for others. What dictates which type of ticket gets what? (Is there a specific icon per team? We'd need some way to map teams to icons in that point - think about what backend systems / data we might need in place.)

7) I think the green is too bright / low contrast with the white to work well for text, esp at a small size. One thing you could try (I don't know if it'd work without trying it out) is make a green box as a background and then make the text inside dark grey or black or white. Alternatively, have the text in black or dark grey and have a green square border around the text (with some padding.) There's some playing around you could do to make it more readable. I do think the NEW label is a great idea! Do you envision them fading in as the come onto the list?

8) I'm still worried about users looking at a filtered list not realizing it's filtered... have you thought about some animations / transitions / loading animations to indicate when the filter is being processed and some other affordance / indication that the list is actually filtered? (it's hard to get a feel for this in a flat mockup... might want to play around with some html/js to see what feels right?)

9) So your tickets have two strings, the header string (e.g. "Duffy needs help on designing a signage for the upcoming flock") and then the msg string "please ping me in irc for more details IRC: mizmo." But a problem here is that we only get one string per help item. (e.g. remember that spec Remy linked to? https://fedora-fedmsg.readthedocs.io/en/latest/topics.html#meetbot-meeting-item-help ) All you have to work with for these cars are the fields shown in that docs, so you only have the single 'line' field (ex: 'The #fedora-apps team needs people to help review code http://ambre.pingoured.fr/fedora-infra/') and the nick of the person who said it (e.g. 'threebean')

You could, though, construct some strings from the smaller pieces of metadata, if you did something like this:


threebean asked for help in fancytown:
"The #fedora-apps team needs people to help review code http://ambre.pingoured.fr/fedora-infra/"

You can message threebean in IRC or email threebean @fedoraproject.org for more information.


which templated out might look something like this (i'll use $VAR for variables):

$NICK + " asked for help in " + $CHANNEL + ": "


"You can message " + $NICK + " in IRC or email " + $USERNAME + " @fedoraproject.org for more information."


Does that make sense?

hope this helps!!

Few improvements to the design :

  1. Improved the visual design
  2. Incorporated the feedback given for the first iteration
  3. Writing the front end for the visual design so that the ticket closed mechanism would be more understandable.
Edited a year ago by radhikamani88

Update : First interactive prototype of the widget


Feedback :

  1. It seems the pull down / filter box needs a label otherwise ppl won't know to click on it / why they could / should
  2. probably the filters need a 'clear all' button

User feedback

  1. The "help" button is not intuitive , will it link to the person's profile in hubs ?
  2. How will I know the status of the ticket or issue I am supposed to help ?
  3. The users had no idea about the last two mockups and what it does ( with reference to the closing of the ticket )
Edited a year ago by radhikamani88

Hi some thoughts about the design iteration

1. I improved the design and added the "assigned" text to indicate the current status of the help request
2. As for the closed status, the widget will not show all the tickets. So only open and assigned tickets will be shown in the widget


11 months ago

@duffy changed the status to Fixed

11 months ago

@duffy changed the status to Open

Okay, I did a bit of tweaking to the visual design here to match other widgets (notably the PR and ticket ones) and also added some additional mockups to show what happens if you click the button to help (you'll get a help request modal with suggestions about what to do next) and what happens if you click on view more (a modal with a full filterable list of requests.) I took the filters out of the main widget because I felt it was too fiddly and better-suited for the full view.

For the full list of requests, the modal should function like a tweet details page where all the replies / back-and-forth infinitely scroll / lazy-load below as you scroll down.

Okay here's the widget itself:

Here's what it looks like if you click on the button next to a request to help:


Finally, the 'all requests' view:

All right. I'm going to unassign the ticket from myself since there's a set of mockups now. Welcome any / all constructive feedback on the mockups and of course questions about how they'd function / etc. esp from any dev who wants to dive in and try to implement!

@duffy Mockups look great to me. :smile:

A note about this design:

we were originally thinking you could 'dismiss' help opportunities once they were 'claimed'. but we thought that would be a lot of overhead and a lot of busy work ppl wouldn't tend to do. so the idea is that it always shows the most recent things at the top - and as a request gets old it just sorts of scrolls off. the idea being you really want to help with things people want help with right now and wouldn't really ever want to dig through super old archives bc the needs have likely changed etc. so it pushes people to talk to the help requestor and work it out - and the thought is if an old request never got answered, someone would ask for help again.

in practice that may not work out so great so we may need to put in some kind of thing where the person who's listed as owning a request can log in and delete it. eg 'omg i answered 6 ppl about helping me frobble my fribs today - make it stop!'

Hey! I'm almost done with the UI. I'm now working on plugging in the backend, and I'm having an issue : the mockups list hubs to "watch", but #halp messages only come from IRC channels. So I need a way to map IRC channels to the hubs where they are used.

I see two solutions:

  1. From the hubs models, it does not look like this is something you can set in the hub configuration, but it could be. A hub could be linked to 0 or multiple IRC channels, and I could filter messages to the list of watched hubs. Then we'll have a second harder problem: how to map meeting channels (like #fedora-meeting-1) to the hubs that are using it at the moment the halp message is emitted. I suspect I could ask Fedocal, but that's another story :-)

  2. I could make the widget watch IRC channels, not hubs, but we'll still have the above problem (halp request in meeting channels unrelated to the hub's purpose), and the design would have to change because I wouldn't be able to link a message to a hub, so I wouldn't know what to put in the blue pill on the top left of a request.

That said, if the widget watches IRC channels, we'll end up entering the mapping from hubs to channels in that field, so we'd have the information I needed for the first solution. And since I'm sure it would be useful for other widgets, it could be a hub configuration value instead of a widget configuration value.

What do you think?

Rather than watching fedocal, would it be possible to have meeting chairs in random channels (like #fedora-meeting) enter a command for zodbot/fedbot/whatever to capture the meeting output to specific additional hub(s), e.g. "#hubs <hubname>"?

Just a quick update on this ticket from today's meeting - abompard is investigating errbot to replace meetbot so we can achieve a lot of the features we need to implement this feature the right way.

Here is a blog post that explains the game plan:


As an update - @abompard has still not heard back from the openstack team. We probably need to make a decision to go ahead with using errbot anyway, or trying something else at our next meeting if we haven't heard back by then.

Login to comment on this ticket.