The "Questions? Chat with us!" graphic is way too visually intrusive #1360
Comments
|
@neilbowers Please read #1235 I'd be interested in hearing from people who's projects have IRC as to if this helps newbies (the key audience) find them - or if it makes no difference (in which case design can be revisited). Closing for now (lets give it a few weeks to settle in) |
|
Opening again - so more people don't raise new tickets, but lets give it some time to bed-in and then get further feedback |
|
I support @neilbowers in this regard. In fact, @oiami's original idea (red chat icons) seems enough distinct to me. |
|
@neilbowers++ it is uncomfortable to read module documentation p.s. why not red blinking marquee?.. ) |
|
If it isn't ridiculously obvious, users won't find it. If users don't find it, they won't end up joining the community nearly as easily. If anything, I would like to see a similarly "intrusive" link to the mailing lists for projects that have them. Optimise for newbies applies, basically - if you want to add some sort of configuration system that lets you then theme metacpan your way, discussing that would be perfectly reasonable - but what you're basically saying here is "I care more about my own visual preferences than growing the perl community". I find it a little bit jarring too. I just don't mind that, because I care a lot more about growing the perl community than my own visual preferences. |
|
Is it possible to do an A/B test with this (some get the ribbon, some get the other suggestion), then run that for some length of time to gather stats and see if there is a difference? Could be worth the effort in terms of taking opinions out of this and letting the data speak. ...oh, I see oalders also suggested this on the original ticket (1235)... |
|
While the goal of fostering collaboration and communication is noble, typographically prioritizing realtime chat over other forms of communication is inappropriate. Channeling all support requests to IRC ignores the individual preferences of each project. It's not something that should be handed down from above. |
|
@rcaputo I think having distmeta specifying an empty webirc resource (or whatever the proper x-meta was) and implementing the mailing-list thing as mentioned by @shadowcat-mst in #1360 (comment) is all that's needed to address your concern. That is - the metadata is the driver of what is displayed, nothing is handed from above. |
|
@shadowcat-mst I don't think @neilbowers is placing his own preferences above growing the Perl community. That would be totally out of character for him. ;) The point of this exercise was to "go big" with the feedback link and then wait for opinions on whether we should move it, scale it back etc. @neilbowers has been kind enough to get the ball rolling with some constructive suggestions, so we should thank him for that. I should also note that we implement a lot of NEILB suggestions, so I'm always happy to hear what he has to say. It comes from a good place. Probably what we should do is implement some click tracking and then try a couple of different placements and/or designs so that we can see what people actually find more compelling. We now have something that everyone can see, but we need to figure out what actually works. This is a fun experiment. I'm interested to see where it leads. |
|
@ribasushi Did you mean #1235? Do you mean that the way to avoid the IRC preference is to stop providing an IRC resource at all? That seems like a poor implementation, so I probably misunderstood it. I don't care enough to press the issue. CPAN is diverse. If I'm right, it's only a matter of time before this upsets people who will press the issue for me. If I'm wrong, there's no point in pursuing it. 😄 |
|
@rcaputo The parser implementation understands both |
|
@ribasushi What do people who want the link but not the prominence do? |
|
@rcaputo Interesting question - we figure out what do these people want instead first. Are you making such a request personally, or is it a hypothetical? |
|
@ribasushi It's hypothetical. See everything I said a few comments back after "CPAN is diverse." |
|
@rcaputo randomly hypothesising requirements with no use case, no user, and no proposed UI is something most people are only particularly fond of listening to when they're billing by the hour :) However, a general point of "there should be more options" is totally sane. Baaasically, I like how it currently looks, for any/all projects I'm involved with, because the prominence is a good thing. If other people would like to de-emphasise it for whatever reason, there's probably a way of doing that. Maybe we need "IRC", "Mail", and "preferred" or something? |
|
@shadowcat-mst I chose "hypothetical" because I didn't want to project my personal experience on the broader community. Your mileage certainly varies, but I have first-hand experience with people who have stressed that e-mail should be the canonical form of general support for serious projects. |
|
Just my 2 cents: when I was a beginner, I was too shy to join a chat. E-mail was the only communication medium imaginable. YMMW. |
You're equating IRC with community, where community is a lot more than IRC. There are many people in the Perl community who have no desire to use IRC. I agree that it's important to ensure that (a) Perl programmers are aware of IRC, and (b) that there are specific channels for some distributions.
I'm hoping you didn't intend it that way, but this was very condescending. That's not at all what I was saying. If something annoys me about the interface, then I've found that it often means that it annoys other people as well. I shouldn't need to preface every issue with "This is just my opinion, but I'm letting you know as others may think this too". I think MetaCPAN has to cater to all users. If it only caters to newbies, power users won't use it as much, or won't engage. I mentioned a newbie mode in a couple of places, and have raised a separate issue on that. |
|
@neilbowers
Allow me to rephrase this as "If users don't find the IRC channel, they won't end up joining that community nearly as easily". Happy now?
You started off by proposing regressing it back to near invisible. It might not have been what you were thinking, but it was absolutely what you said (edited to add: what I mean is that I think the original issue as filed was completely failing to look at the tradeoffs involved, and given your strong involvement with trying to encourage people into the community, I reacted strongly because it seemed like a really dumb thing to say compared to what I normally hear from you - I was aiming for 'disappointed' more than 'condescending') I would expect there to be a middle ground here of something that isn't quite so garish but still decently findable, combined with doing the same thing for mailing lists, and letting projects indicate which one they want to prioritise. Maybe we should start looking for that rather than trying to drag the design back to one extreme or another based on personal preference? |
|
My main problem with the current design is that it looks like an arrow, but it's not pointing at anything in particular. |
|
For the record I agree with @neilbowers that the current visual is too distracting. |
|
Given the generally understated look of metacpan (which I really appreciate) my personal preference would be for something far less garish but better placed. The left hand side bar is a jumble of things related to the project, the distro, the release, and the module in the release, but they aren't grouped in a way that would make it clear which is which. So I suggest rethinking that left sidebar with a view to regrouping related items with some visual separation between the groups. Then add a less garish 'get in touch with us' link into the project section. |
|
As @timbunce suggests here and @wchristian suggested on #1235, grouping project community contact links would promote each distribution's implementation of "community" without prejudice. On the other hand, it makes perfect sense for the IRC link to be the most prominent element on the page if the goal is to serve IRC ahead of everyone else. Another option might be to deprecate non-preferred links by making them less prominent. A normally styled canonical contact link would stand out without ornamentation. If grouping and subtly styling them is still too much clutter, there's always the option to remove non-canonical contact links if a canonical one is present. Fewer things on the page would simplify the design. |
|
Maybe if you title the section "Talk to the community" or "Talk to us" or something, with links titled "Join the mailing list" and "One-click IRC web chat", and some sort of way to indicate the preferred one, which could then be bolded or whatever. I feel like for the cases where more than one contact approach exists, there's multiple categories - at least the following:
and the key thing that drove the current design is that we're looking at trying to provide instant fixification for somebody who's on the page searching the docs about a bug, so we need to catch their eye because otherwise they may simply not realise that the option's there. The tension, I think, is between "eye-catching" being desirable for that case and "intrusive" being undesirable if the link isn't something that's useful to you. As ever, it's tradeoffs all the way down :) |
|
(Edited to add: I missed an important caveat, there's a second comment immediately below where I try and fix that.) As one of the people who originally provided input leading to this implementation, my opinion here has not changed yet: This absolutely needs to be disgustingly garish! This might feel like an overreaction to some of you, but to a group of people who include me, it is a matter of survival for Perl. There are three main factors that collide here:
Due to these two factors it is a must for all of us, as a community, to guide newbies in a hilariously strong manner to that place. I am absolutely confident that any disagreement with me here stems from a lack of information, and as such am happy to rectify that in a 1:1 manner. If any of you feel the preceding is wrong, please talk to me directly before posting here so we can try and work out a mutual agreement or disagreement that can be posted here in summarized form, without having a lot of back and forth on a github issue. Let's talk! That said, there is a separate issue that the current implementation might be improved. I take no issue with changing the shape of the banner, adding an explanatory tooltip or looking into what happens to the banner in browsers with different default font sizes (it looks a little broken to me). ¹ do note i said "mostly" |
|
As @shadowcat-mst pointed out to me, there is the issue that highlighting IRC will absolutely not work and be the wrong thing for some projects. I agree with this, since i know and love to use some where this applies, and consider it a very good idea to make a separate issue where it's discussed how dists can make a choice about this. |
Yes, on multiple levels. Thank you.
I read this and thought "that's not at all what I meant", but on going back and re-reading it, what I wrote can clearly be interpreted that way. Definitely up for looking for a trade-off that meets all needs, and isn't based on personal preference. I wasn't trying to push personal preference, but rather something that isn't going to put off a slice of the MetaCPAN users. It reminds me of the tag when it was originally introduced: people thought it was great for "this is the most important bit of the page", but the trouble is that "most important bit of the page" varies not only user by user, but visit by visit. And if the IRC link isn't the most important thing for you, then it's like it's "crying wolf". Waugh, I've been re-reading this wondering how this might be interpreted in ways other than intended ... :-) |
|
@wchristian Out of curiosity, how do you see StackOverflow fitting into all of this? Personally, I prefer IRC for a lot of communication, but for channels with no public logs, the solutions to problems are not publicly archived. Even for those channels with public logs, they may not be easy to find. Something like StackOverflow seems like a very good way to archive a lot of this stuff, even if it may take a bit longer to get a resolution. I'll also note that particularly Perl questions on StackOverflow get shut down very quickly, so it's not a good medium for a lot of questions that you're encouraged to ask on IRC. |
|
@oalders: StackOverflow has a chicken-egg problem: The people knowledgable about things rarely have the time to pay attention to StackOverflow, since there simply is no easy way (i hope i'm not lying here) to tell it "hey, send me a ping on email, irc, twitter" if someone there asks a question about Perl. And at this point, even if there was, it would be quite a piece of work to get people to actually use it. So, there are few people there who can give good answers. Secondly, and maybe as a consequence of that, the Perl questions asked there often (not always) suck, or are extremely specific. As for archival: I find that people on IRC don't mind answering repeated questions, and if the question comes up TOO often, the answer tends to finds its way into documentation. Also, as you mention, StackOverflow has a deeply flawed model of moderation that tends to promote the worst kind of answer. |
+1 |
You and I understand that IRC response times run the full gamut. The "newbies (the key audience)" generally have more immediate expectations of help chat. The novice who /quits before anyone can answer their question is an IRC trope. The way "chat" is generally portrayed on the web, especially juxtaposed against higher latency forms of "contact", feeds the wrong expectations.
I probably don't need to say this, but I can't assume: The current implementation is a common marketing tactic to channel attention and clicks through a particular option. I have every reason to expect clickthrough rates for alternative forms of assistance (colloquially known as "support") to reduce proportionally. The use of messaging consistent with immediate gratification will entice people. My assumption that IRC's role is relatively small is based on the current imperative that IRC participation must increase. After visualizing how the feature will most likely be used, I hope that chat can be an entirely separate window. That way, the user can continue to browse the documentation and other resources if IRC is quiet. Or if they get an "RTFM!" as is common on IRC, they'll have TFM already open. But I digress. I'll ping you on IRC for further discussion. |
|
@wchristian asked me on IRC to restate myself. This sums me up: Perl's community comprises a LOT of different preferences. A Procrustean implementation will rankle. Giving distributions the option to highlight what they want, or nothing at all, will shed more objections and fewer bikes. I personally don't mind whatever happens, even if that's a hard-coded preference for IRC. Perl's community is opinionated, and you will know if its members have been displeased. |
|
The "pointing" problem seems easy enough to solve without reducing the garishness, just flip the direction/bezel effect. I think the second of these two variations on the theme might appeal to more people :)
|
|
I'd like to move discussion about how to handle alternate contact points (mailing lists etc) to issue #1380, and leave one for changes to the visual style. The "looks like an arrow" issue has been resolved now. I'd welcome concrete proposals on how to change the ribbon to be less distracting, although we don't want to reduce it to just another link. |
|
Am closing as it looks like there is no more discussion on this. |
The IRC link is the sidebar is a really good idea, so kudos/thanks to those who had the idea and implemented it.
It jars visually though: it doesn't match the rest of the "MetaCPAN look", and it draws the attention, as if this is the most important piece of information on the page.
To be constructive:
The text was updated successfully, but these errors were encountered: