1048223 - Breakdown: change what is displayed in the awesomebar on search result pages

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, defect)

Description

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Bug 1040392 specified a behavior for the location bar on search result pages (mockup is here: http://phlsa.github.io/ff-search-callout-2).
This is the breakdown bug for the implementation work.

Comment 1

[Dão Gottwald [:dao]]

(In reply to Philipp Sackl [:phlsa] from comment #0)
> Bug 1040392 specified a behavior for the location bar on search result pages
> (mockup is here: http://phlsa.github.io/ff-search-callout-2).
> This is the breakdown bug for the implementation work.

Changing the identity icon to a magnifying glass seems problematic, as it eradicates the unencrypted/encrypted/validated-owner distinction.

Comment 2

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Dão Gottwald [:dao] from comment #1)
> (In reply to Philipp Sackl [:phlsa] from comment #0)
> > Bug 1040392 specified a behavior for the location bar on search result pages
> > (mockup is here: http://phlsa.github.io/ff-search-callout-2).
> > This is the breakdown bug for the implementation work.
> 
> Changing the identity icon to a magnifying glass seems problematic, as it
> eradicates the unencrypted/encrypted/validated-owner distinction.

Good point!
Let's only keep the lock/identity block in this case and only show the magnifying glass when
- the page is not encrypted
- the user has changed the query

I updated the mockup accordingly.

Comment 3

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Marco, what is the reason for marking this as UX work, given that there is a spec?

Comment 4

[Marco Mucci [:MarcoM]]

My mistake, I've updated accordingly.  Thanks Philipp.

(In reply to Philipp Sackl [:phlsa] (on PTO Aug 11-17) from comment #3)
> Marco, what is the reason for marking this as UX work, given that there is a
> spec?

Comment 5

[Marco Bonardo [:mak]]

we almost finished implementing the request in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1034382 that was what we supposed being the final UX mockup on how to style urls for recognized searches.

I don't understand if this is overlapping with that, so suggesting a completely different style for the same thing, or if it's something that should be built on top of that, so search urls are hilighted, but in some very specific case they are instead styled like this.

If this is suggesting a completely new stying for serch urls in autocomplete field, we just wasted many development hours on an outdated mockup... That would clearly show the need for a ux repo so that we have access to most recent mockups of each feature and avoid working on forks.

Comment 6

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Marco Bonardo [:mak] (needinfo? me) from comment #5)
> we almost finished implementing the request in bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=1034382 that was what we
> supposed being the final UX mockup on how to style urls for recognized
> searches.
> 
> I don't understand if this is overlapping with that, so suggesting a
> completely different style for the same thing, or if it's something that
> should be built on top of that, so search urls are hilighted, but in some
> very specific case they are instead styled like this.
> 
> If this is suggesting a completely new stying for serch urls in autocomplete
> field, we just wasted many development hours on an outdated mockup... That
> would clearly show the need for a ux repo so that we have access to most
> recent mockups of each feature and avoid working on forks.

Yes, this was handled poorly.
The mockup in this bug shows the desired end state. We haven't done any UX work beyond that.

For context, here's why things went the way they went:
The main objectives for both of these mockups were to make search terms clearer and allow the user to edit them. The ideas for highlighting the terms in the URL and removing the URL entirely came up around the same time. However, there were lots of unanswered questions around the latter which we thought needed a lot more prototyping and possibly user testing (both take a lot of time). So the idea was to move forward with the less controversial highlighting proposal first.
Then two things happened: First, the prototyping work on the URL replacement went down much quicker than we anticipated and second, the development work on the highlighting got delayed because of other priorities. Suddenly we were in the place we are in now, where one thing is almost finished and the other one is ready for implementation at the same time. I'm to blame for not jumping in and shouting »stop the ceremony« on the highlighting implementation work as that situation became clear.

From here, I think there are two ways to move forward:
- Don't land the highlighting and move straight to implementing this solution
- Land highlighting and work on this as a follow-up

Which of them makes more sense depends on how much time implementing the mockup from this bug is and on how far away from landing the highlighting work still is.
What's your sense there Marco?

As for a UX repo – that would be great. We don't have anything like this internally though. Let's continue figuring this out, but let's also have that discussion outside this bug.

PS: Whoever takes this bug, let's have a quick vidyo conversation before you start working on it to make sure we are on the same page.

Comment 7

[Marco Bonardo [:mak]]

So, we actually have hilight in Nightly, but we hit bug 1075069 that is basically impossible (or possible with bad hacks) to handle with hilighting.

I think this approach is a good solution to handle that case, so likely we should backout current hilight and proceed with this.

Comment 8

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #7)
> So, we actually have hilight in Nightly, but we hit bug 1075069 that is
> basically impossible (or possible with bad hacks) to handle with hilighting.
> 
> I think this approach is a good solution to handle that case, so likely we
> should backout current hilight and proceed with this.

I'm fine with that.

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Screenshot of spec

Comment 10

[jaramat]

This is a very, very bad idea. Obscuring the URL of a web page is always a very, very bad idea. And also very pointless.

Not to mention that if I, as a user, want to edit my search query, I do NOT go back to the search bar nor the address bar. Every search provider has a search field on the top of their results page, displayed in a big font, to catch the user's attention should they decide to correct their search term. Every single person I know - no matter how old, young, tech savvy, stupid, or the I-just-want-to-get-my-work-done type, all of them correct/change their search query in the provider's search field. None of them ever looks for it for longer than half a second, they just know where it is.

I'm being seriously serious. This is the worst of all the bad ideas I've seen here for a long time.


In case this actually does get implemented (for whatever reason), there definitely needs to be a config pref to turn this evilness off - just like the http:// trimming, because this is going to anger a lot of people.

Comment 11

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.