980607 - Advanced search needs succinct post. Do not need all lines/full text of a large topic

Status: RESOLVED WONTFIX

(support.mozilla.org :: Questions, task)

Description

[Wayne Mery (:wsmwk)]

looks nice https://support.mozilla.org/en-US/search?q=crash&num_voted=0&num_votes=&asked_by=&answered_by=&q_tags=&product=thunderbird&created=0&created_date=&updated=0&updated_date=&sortby=0&a=1&w=2 

page 2 (next) does not look nice https://support.mozilla.org/en-US/search?num_voted=0&a=1&product=thunderbird&created=0&updated=0&q=crash&sortby=0&w=2&page=2

Comment 1

[Michael Cooper [:mythmon]]

I think this is just a weird set of search results. Consider this page 2 of search results for another query: https://support.mozilla.org/en-US/search?a=1&num_voted=0&product=thunderbird&created=0&updated=0&q=something&sortby=0&w=2&esab=a&page=2

I think page 1 would do the weird thing you saw too. Maybe instead we need to try and truncate descriptions better.

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

Before doing anything, do a git blame and figure out why we're doing what we're doing because I'm almost positive it was bug-driven and I think I changed it to the current behavior.

Comment 3

[Will Kahn-Greene [:willkg] ET needinfo? me]

The current behavior is related to bug #904443.

What's going on is that we show the full post with the search terms highlighted--it's not truncated. It's not truncated because of another bug where people were confused and frustrated that sentences would end in the middle.

The particular questions you're having problems with are questions where the user copy and pasted long error message dialog text. It's not related to which page in the search results it is.

Given that this is an aesthetic issue and I don't think this is a problem with most questions, I don't think this is something we should fix.

Comment 4

[Wayne Mery (:wsmwk)]

Will, thanks for the references.

I'm happy to revise the summary to be more accurate and perhaps this is not a problem with most topics.  But it probably will be more common with Thunderbird topics because users are encouraged to submit their troubleshooting information - which, if nothing else, becomes a bad mashup on SUMO's rendering. 

This is more than mere aesthetic. But I'm not yet sure what the solution is. So I ask that this be kept open until a way to further improve the behavior is identified.

Comment 5

[Wayne Mery (:wsmwk)]

Attachment: sumo with troubleshooting info.png

screen shots are always nice :)

Comment 6

[Will Kahn-Greene [:willkg] ET needinfo? me]

Can you be more specific as to how this is more than just an aesthetic problem? You've said it was "wonky" and "does not look nice", but those are both aesthetic statements.

Comment 7

[Wayne Mery (:wsmwk)]

a) it is too long
b) (more importantly) it is mashed to the point of being unreadable, zero formatting, etc 

perhaps someone else can provide more elegant words if those above are inadequate, but I think it's fairly obvious

Comment 8

[Matt]

See this thread https://support.mozilla.org/en-US/questions/989028  Original poster was unable to post the entire content and to quote "the message system would not let me put the full-length of the troubleshooting document. So I hacked out things it seemed irrelevant."  Sad days when those seeking support decide what is relevant.

Comment 9

[Will Kahn-Greene [:willkg] ET needinfo? me]

(In reply to Matt from comment #8)
> See this thread https://support.mozilla.org/en-US/questions/989028  Original
> poster was unable to post the entire content and to quote "the message
> system would not let me put the full-length of the troubleshooting document.
> So I hacked out things it seemed irrelevant."  Sad days when those seeking
> support decide what is relevant.

That sounds like a different problem and not related to search results. You should open up a different bug for that.

Comment 10

[Will Kahn-Greene [:willkg] ET needinfo? me]

(In reply to Wayne Mery (:wsmwk) from comment #7)
> a) it is too long
> b) (more importantly) it is mashed to the point of being unreadable, zero
> formatting, etc 
> 
> perhaps someone else can provide more elegant words if those above are
> inadequate, but I think it's fairly obvious

Here's where I'm coming from: search works the way it works because we have a series of requirements that we designed the current behavior to meet. We show the entire blob of text because when we were showing fragments it was confusing users who were using search to find information because there weren't complete sentences. We don't truncate the blob of text because the highlighted results portion could be in the truncation section plus it's difficult to accurately truncate HTML-formatted text (which is what we get out of ES). Those requirements were user-driven and we've gone through several iterations over the last few years to get to where we're at.

My problem is that I don't understand the impact of the symptoms you're describing. I'm trying to understand why "it's too long" and "it's mashed up" are important beyond it not being aesthetically pleasing. What does it prevent you from doing? What problems is it causing? Is it impacting users who are searching for answers?

So given that, can you please elaborate on what the problem is and its impact? Assume it's not obvious to me.

Comment 11

[Wayne Mery (:wsmwk)]

Attachment: tbird gsfn managmeent view.png

I appreciate your POV, and the goals/history.

From an end-user POV, I haven't fully formed an opinion. But my gut thought is most of what is found after "Application Basics" isn't of interest to most end-users.

From a triager's POV (the POV from which I filed this bug), I want to to be efficient and effective with my time. I want to see as many topics as possible, with useful info, in the shortest amount of space. Put another way, if I were being paid, I would be quoting "time is money", and time in this case is taken by scanning text and scrolling web pages - time X pages per day, times Y pages per week.  The time over a week adds up.  And triage of user support topics is not the only place where I spend my time for mozilla.

That said, perhaps what you provide is OK for the casual reader. And perhaps what I really want is something totally different. By way of example, attached is a "management view" search result from getsatisfaction.com, which is what Thunderbird was using previously.  In approximately two web pages I can see 30 topics, their status, etc. SUMO doesn't compare well here. 

Note also the column layout which enables quick scanning. Not also the area I've marked in red, which facilitates bulk handling of topics. (They also support searching by date range, which I very much need.)

Comment 12

[Will Kahn-Greene [:willkg] ET needinfo? me]

Now that I know what the problem is, I contend you're using the wrong page. You're using the search page and the search page is not designed to show you the status of everything, but to show you enough of the results to let you find the thing you're looking for. It's not meant for the use cases you're trying to use it for.

I think you want this page:

https://support.mozilla.org/en-US/questions

That page shows you the status of things and lets you filter down.

Does that fit most of your requirements?

Comment 13

[Wayne Mery (:wsmwk)]

https://support.mozilla.org/en-US/questions results list is cleaner, but it still doesn't cut it because
a) it doesn't let me search
b) it's only the prior 24 hours
c) it only displays 3 topics per screen on a laptop

Comment 14

[Will Kahn-Greene [:willkg] ET needinfo? me]

Changing the summary for this bug to match the problem statement defined in comment #13.

Comment 15

[Wayne Mery (:wsmwk)]

regarding comment 12, I believe I'm using the tool closest suited to my needs, which are, in simplified terms:
1. finding similar posts (opened, closed, and both) as a group 
2. possibly grouped by date ranges and other factors

For example, I might want to find all postsmentioning "crash" starting 6 months ago.
It is impossible to do these things with https://support.mozilla.org/en-US/questions/thunderbird

In short, as someone stated in bug 904443 "showing whole posts makes it hard to skim search results". My attachment 8387536 [details] is a good example (35 lines of blob).  We must somehow strike a balance or provide some mechanism for supplying a summary of a post.

As I understand bug 904443, you are using the search backend for more than one set of users. And I'll admit I do not understand the usecase where a user would want to full text.  But i nmy case we need a searched tuned to each set of users, or a UI that allows the user to tune their results, for example show me max NN lines of each topic.

Comment 16

[Wayne Mery (:wsmwk)]

That said, I'm happy to have some other search mechanism morph to my needs :)

phillip also mentions on IRC, that large text blobs are not nice on small screens, which prompts me to add I do must of my SUMO triage on a 15.6 laptop screen - relatively large by laptop standards.


When I get a better grasp on what I want to ask for, I'll file a separate bug about attachment 8388137 [details] "summary view"

Comment 17

[Seburo]

Closed as per https://blog.mozilla.org/sumo/2019/06/07/sumo-platform-roadmap/