Note: this suffers from the same problem as with notices: when there is no client attached, it's impossible to know where the result should go. It is also unclear when multiple clients are attached which window this should go to. So it will take a while before we get there, as handling this will require a special global channel for the clients to be able to display this sort of messages properly.

If no client is attached, notices can go to the server window. If multiple clients are attached, is it impractical for each client to decide where to place the incoming notice depending on which window is active?

I still think things like that should go to a modal window. Let's not just
keep thinking in old irc terms. We are building a modern web app, we can do
much better things.

A whois is generally something you use because you want to see something
now. You don't generally want to look at it later, and its not really going
to happen when someone is disconnected.

On Tue, 12 Jul 2016, 04:15 dgw, notifications@github.com wrote:

If no client is attached, notices can go to the server window. If multiple
clients are attached, is it impractical for each client to decide where to
place the incoming notice depending on which window is active?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#492 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACD_4ahaNDfk9tHCfw1MIDR0kf7vtyy6ks5qUwbGgaJpZM4JJsXy
.

Even if I weren't opposed to the idea of incoming data triggering a modal window, I'd still have questions about the UX of logged-on clients other than the one which sent the WHOIS request displaying a modal window upon receiving the response. And I am very much opposed to using modal windows except where absolutely necessary, because they're either annoying to get out of (only "Close" or similar button closes) or too easy to dismiss by accident (clicking anywhere outside the modal closes).

I did get a little distracted by the comparison to notices, and I'll add that feedback on the appropriate issue instead.

Oh, I'm not suggesting the ones that didn't request it showing a modal.

On Tue, 12 Jul 2016, 07:06 dgw, notifications@github.com wrote:

Even if I weren't opposed to the idea of incoming data triggering a modal
window, I'd still have questions about the UX of logged-on clients other
than the one which sent the WHOIS request displaying a modal window upon
receiving the response. And I am very much opposed to using modal windows
except where absolutely necessary, because they're either annoying to get
out of (only "Close" or similar button closes) or too easy to dismiss by
accident (clicking anywhere outside the modal closes).

I did get a little distracted by the comparison to notices, and I'll add
that feedback on the appropriate issue instead.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#492 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACD_4fS9HWdwYcpHwn-mVZguYjI69HPFks5qUy5PgaJpZM4JJsXy
.

I'm going to suggest having it go to the server window. This avoids confusion on determining where it should go and avoids creating a useless chat window just for whois results.

Would the ideal behaviour depend on how you requested the information? Writing /whois user probably means you want the text output while right-click in the user list and selecting "User information" probably means you would prefer a dialog.