Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show whois in active window (and default to server window on reload) #1868

Closed
wants to merge 1 commit into from

Conversation

AlMcKinlay
Copy link
Member

Fixes #492

@AlMcKinlay AlMcKinlay force-pushed the yamanickill/492-whois-active-window branch from 43a7281 to 81b7278 Compare December 21, 2017 14:33
@xPaw xPaw added the Type: Feature Tickets that describe a desired feature or PRs that add them to the project. label Dec 21, 2017
Copy link
Member

@xPaw xPaw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eh, we can afford to do this now.

@astorije astorije self-requested a review December 22, 2017 05:32
@AlMcKinlay AlMcKinlay added this to the 3.0.0 milestone Dec 22, 2017
@AlMcKinlay AlMcKinlay force-pushed the yamanickill/492-whois-active-window branch from 81b7278 to 89ea796 Compare December 22, 2017 15:08
@AlMcKinlay AlMcKinlay force-pushed the yamanickill/492-whois-active-window branch from 89ea796 to 90fbadd Compare December 28, 2017 11:21
Copy link

@Klaas- Klaas- left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works fine ontop of 2.7.0 :)

@astorije
Copy link
Member

We've discussed it a few weeks ago on IRC so it shouldn't come as a surprise to @thelounge/maintainers, but as it is, I'm very 👎 about this.

Having things that move location across refresh is something we should avoid at all cost, because it's very unpredictable, especially for new users and users with cognitive disabilities. I know we introduced this in #1380 and I'm still uneasy about it.
Also, over time, we should get away from adding general-purpose stuff to the server window, which is the most cryptic part of our client (and IRC clients in general), especially for non-technical users.

I don't like putting this in the middle of a channel either, I actually think that leaving it in the direct messages window is more appropriate.

That said, I'm not opposed to changing just because I don't like change, I just think it's not the direction we should take. I have something half-working locally (I might even have pushed a branch but I'm not sure, I'll check):

whois

If/When this works, it opens so many possibilities for future features: refreshing on demand, having actions directly in there, having admin-only features, etc. The UI is also gross right now, but because it's bespoke to whois/user information, we can design it however we want, not be bounded by the canvas of messages.
You'll notice that at the moment it opens the info in the user convo still, which I understand is what this PR tries to avoid. My next step is to make this open in the current window. There are a couple paradigms we can use, I'll try until it fits.

@AlMcKinlay
Copy link
Member Author

We've discussed this privately a bit, so as promised, here are my thoughts in hopefully a more understandable way, and also for public consumption.

I prefer the sidebar to how we are currently doing it, however, I don't think it should be how we do things 100% of the time.

  1. When I click "user information" I don't want to suddenly pop the chat to a different chat window. That feels really wrong. I don't like the context switch there
  2. Unless we are going to do whois everytime we open a query, then sometimes the sidebar won't be there, how do we feel about that?

I have previously really been pro the idea of showing it in a modal, but I understand the objections to that. However, how about doing something similar to how slack does it. You click on a user's information, and it shows in a context menu.

So how about, you click on the "whois" and it shows the information i nthe context menu? I'm not 100% sure about that, but it's a thought.

I'm not happy with any of the ideas we've come up with, tbh.

The other thing to discuss is showing the whois on reload. I think we shouldn't do that at all. My reasoning is that whois is a 1-time question, not something you will want to re-read later (apart from anything, it may have changed later) so if you want to do it later, you can redo it.

What should happen:

  1. I click on whois (or type it)
  2. It somehow shows me the whois
    3, I can dismiss it, or reload
  3. I don't see it again until I ask for whois again

Now, part of the problem of not showing the whois again is because we show it as a message, but it isn't a message at all, is it? It's contextual information based on a request. I'm not sure how we do that, as I said, I like the idea of the sidebar, but I'm not sure I want to switch to the user's page when we request.

Maybe I can be convinced... ¯\_(ツ)_/¯

@astorije
Copy link
Member

astorije commented Feb 4, 2018

I'm gonna be short because reading your comment, it feels to me we are overall in agreement, just a bit of miscommunication and other minor details.

  1. When I click "user information" I don't want to suddenly pop the chat to a different chat window. That feels really wrong. I don't like the context switch there

I understand and I think I agree. I actually mentioned that in my previous message, stating that what you can see in this GIF (the context switching you mentioned) is not what I'm trying to accomplish: "You'll notice that at the moment it opens the info in the user convo still, which I understand is what this PR tries to avoid. My next step is to make this open in the current window. There are a couple paradigms we can use, I'll try until it fits."

So, yes, my next step is to trying loading in current window and see how it goes.

  1. Unless we are going to do whois everytime we open a query, then sometimes the sidebar won't be there, how do we feel about that?

IMO all variants are fine. It can be 1) the opposite of the channel list, which is open on first channel opening (and after #1606 would remember your choice), or 2) both channels and queries have sidebar closed on joining, open on request (my favorite option once #1606 is merged), or 3) sidebar always opens.
I think this doesn't have to be answered right away, a few UX decisions/changes I still need to make in this PR (+ #1606) will affect it anyway.

However, how about doing something similar to how slack does it. You click on a user's information, and it shows in a context menu.

Yep, as mentioned that's the goal I'm trying to reach. The only thing about the Slack way is that I've noticed people (and I include myself in it) being confused by that sometimes. I can't point my finger on it yet because I have never really cared, but now that I have a goal, I'll be more careful, looking at where people look/click/search/etc. when they use it (at my work), it will probably show a pattern.

Anyway, I'll try to get back to that soon, so I can push something somewhat usable at the very least.

@astorije astorije self-assigned this Feb 20, 2018
@AlMcKinlay
Copy link
Member Author

Probably no point in keeping this open just now. Feel free to open one when you get to your solution, @astorije

@AlMcKinlay AlMcKinlay closed this Feb 21, 2018
@AlMcKinlay AlMcKinlay deleted the yamanickill/492-whois-active-window branch February 21, 2018 16:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature Tickets that describe a desired feature or PRs that add them to the project.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants