Suggestions from Jim Hall:

* The first time Epiphany "hides" the URL, it could display a little infobox next to it that says "click here to enter another location" or something similar.
* Also, I suggest a tooltip when you hover your pointer over the page title (where the URL should be) that says "click here to enter another location" or similar. That should help with discoverability.

From: http://opensource-usability.blogspot.com/2015/03/hands-on-usability-improvements-with.html (which has yet another comment suggesting we do a border)

Created attachment 300414 [details] [review]
Display a tooltip when hovering over the title box

Tooltip first because it is easy. Note, string freeze break.

I think we could do a GdNotification the first time Epiphany hides the URL. That answers the question of whether or not we should bundle libgd, since GdTwoLinesRenderer is not the only thing we need, and also should hopefully avoid the crash Yosef reported the other day. That should look good and also be pretty easy to implement.

Maybe we can also use GdNotification when asking to save passwords, and eventually for codec installation, since I think the designers like replacing info bars with in-app notifications.

are there any css styles we can add to get something like a button frame around the edge on mouse hover? (similar to prelight on buttons)

(In reply to Christian Hergert from comment #3)
> are there any css styles we can add to get something like a button frame
> around the edge on mouse hover? (similar to prelight on buttons)

That's what I came to suggest. Just making the whole title a .flat button that raises on hover should aid the understanding of the behavior.

Maybe we can ditch the tooltip if it's .flat, since it doesn't look terribly good.

I'd also try moving the downarrow from the subtitle url side to the title side.

(In reply to Lapo Calamandrei from comment #6)
> I'd also try moving the downarrow from the subtitle url side to the title
> side.

Do you mean: instead of appending it to the end of the subtitle, append it to the end of the title?

(Aside: since I have your attention here, remember bug #734119!)

Created attachment 300437 [details]
screenshot of raised button

I'm not sure that using a raised button looks quite right....

(In reply to Michael Catanzaro from comment #8)
> Created attachment 300437 [details]
> screenshot of raised button
> 
> I'm not sure that using a raised button looks quite right....

I think any kind of button there, it look really bad.

Oh but I'm only supposed to do it on hover, like Jakub said. Maybe that would work.

Yosef, Michael, ouch that would look ugly whatever, the button needs to be the same height as other headerbar buttons, and as stated it needs to be visible just on hover (the "flat" style class should do that for you).

(In reply to Lapo Calamandrei from comment #11)
> Yosef, Michael, ouch that would look ugly whatever, the button needs to be
> the same height as other headerbar buttons, and as stated it needs to be
> visible just on hover (the "flat" style class should do that for you).

It can't have the same height as the other buttons, since the title+subttile
takes more pixels then the buttons (height).
So either you wants to make the title+subtitle smaller, or I not see well?

(In reply to Yosef Or Boczko from comment #12)
> (In reply to Lapo Calamandrei from comment #11)
> > Yosef, Michael, ouch that would look ugly whatever, the button needs to be
> > the same height as other headerbar buttons, and as stated it needs to be
> > visible just on hover (the "flat" style class should do that for you).
> 
> It can't have the same height as the other buttons, since the title+subttile
> takes more pixels then the buttons (height).
> So either you wants to make the title+subtitle smaller, or I not see well?

True about the sizing, shirking both to make it the button the RightSize(TM) would result in way too tiny text so it's not an option :-/
Apart being ugly like that it doesn't look like a button much, which defeat the purpose. Other ideas?

uhm, showing the entry on hover istead that on click and leaving that visible for a set time on pointer out? A bit too bold maybe, not sure.

Sounds good to me, why not?

Created attachment 300469 [details] [review]
Switch the title box mode on hover, not on click

This is a WIP since I don't have time to debug it more right now. I actually really like the behavior of changing mode on hover, but I'm getting a bunch of spurious leave_notify events which ruins this patch.

Michael the patch doesn't apply cleanly to master, is that against master + your tooltip patch?

Applying the patch here makes the entry "blinking" on hover, maybe is my build system tho, anyway w/o testing I think the behaviour I proposed should make it pretty discoverable, it sports the following CONS:

- it's visually pretty bold
- it makes window dragging more difficult/confusing
- doesn't help on touch

Jakub, what do you think?

Yes, it's on top of the tooltip patch, sorry about that. And it's blinking because GTK+ is sending leave_notify events even though the cursor stays put. At first I thought it was related to the stack changing the visible child, but now I'm not sure. So pretend it's not blinking. :p

Those are big cons though; I hadn't considered those.

(In reply to Lapo Calamandrei from comment #17)
> Michael the patch doesn't apply cleanly to master, is that against master +
> your tooltip patch?

I try to apply this patch, which tooltip patch exactly?

(In reply to Yosef Or Boczko from comment #20)
> (In reply to Lapo Calamandrei from comment #17)
> > Michael the patch doesn't apply cleanly to master, is that against master +
> > your tooltip patch?
> 
> I try to apply this patch, which tooltip patch exactly?

The one above, in this bug... note these are for debugging only, it doesn't work

Hmm, I don't like this behaviour, to say the least.
It flash in hover, but idealy I still can't d&d from the title etc.

Created attachment 300532 [details] [review]
Switch the title box mode on hover, not on click

OK, this patch actually works. It depends on the patch in bug #741808 and no other patch.

It has the cons Lapo mentioned above. I think it's better than the status quo for mouse users. No clue what happens on a touchscreen....

What do you think on making the uri as link button?

I'm not sure I'm visualizing that properly... you mean make the subtitle (and only the subtitle) into a button? That doesn't seem right either....

Anyway, we *could* go back to just showing the location entry at all times, like in 3.10, but it would be really nice to display only the domain of the website in the subtitle (and if the site uses an EV certificate, we can even hide that and display just the organization name!) which is only possible to get away with if the full URL is still available via the location entry.

(In reply to Michael Catanzaro from comment #25)
> I'm not sure I'm visualizing that properly... you mean make the subtitle
> (and only the subtitle) into a button? That doesn't seem right either....
> 

Yes, make the subtitle (only) to look like a link button, but allow clicking
all the title area (title+subtitle).

> Anyway, we *could* go back to just showing the location entry at all times,
> like in 3.10, but it would be really nice to display only the domain of the
> website in the subtitle (and if the site uses an EV certificate, we can even
> hide that and display just the organization name!) which is only possible to
> get away with if the full URL is still available via the location entry.

I don't understand, why do you want to go back to 3.10's behaviour, it was
really worst, you lost the website's title in too many cases.
What we try to do in this bug is to make it more clear/eayse to discover the
location bar, whitout lost the benefit in the current behaviour.

With the current patch, it really annoying to see the flash all the time (with
the patch from bug #741808) (I'm talking on the time I move the cursor to the top bar, to show the calendar/messeges etc).

We also lost the ability to show the certifction information from
the title (we needs to move the lock icon in the title mode to the
other side, so the user don't try to click the lock icon in the left
side and than needs to move the cursor to the right side in the location
bar for the lock-icon).

Michael, the patch still works kinda unrealably, anyway even with a perfect implementation, taking care somehow of window d&d and stuff, the countereffects are too much imho, to summarize this causes more harm than benefit.
So what about a less creative solution? We could just exploit an in-app notification which chimes in every time the app is launched with something like:

(up arrow) Click the title for the text entry (better wording needed)

[ ok ] [ gotcha, don't show this again ]

Something like this would work on touch

Yes, I was planning to do that anyway :p

I think that alone would fix the issue, we could be pendatic with that to be sure the user get it, showing another in-app notification on start up when "don't show this again" has been clicked, with some humor which doesn't hurt, something like:

(up arrow) Click the title for the text entry

[ ok ] [ really, I got it, GO AWAY ]

(In reply to Lapo Calamandrei from comment #30)
> I think that alone would fix the issue, we could be pendatic with that to be
> sure the user get it, showing another in-app notification on start up when
> "don't show this again" has been clicked, with some humor which doesn't
> hurt, something like:
> 
> (up arrow) Click the title for the text entry
> 
> [ ok ] [ really, I got it, GO AWAY ]

I just thinking how to translate it ;-)

...and a third time,

(up arrow) Click the title for the text entry

[ I UNDERSTAND, GO TO HELL ] <- in red

Created attachment 309059 [details]
Proposal from Alessandro

Alessandro says this is similar to what Safari does. He applied this CSS to the title box:

.test {
background-color: rgb(253, 253, 253);
border-radius: 4px;
}

Doesn't look good to me. Also it communicates that something is going on, but not looking consistent with the other buttons we have it's not totally clear it's clickable. I'm still for communicating the clickability of the title by other means.

I think we can do without the page title in the header bar. And if that goes away, two options become available:

 1. Show button relief on hover, keeping the button the same height as the others in the header bar.

 2. Always show the URL entry, and don't hide it.

If we went for option 2, I think we should try and reduce the amount of noise in the URL bar: only the domain could be shown when the entry isn't focused, for example.

(In reply to Allan Day from comment #35)
> I think we can do without the page title in the header bar. And if that goes
> away, two options become available:
> 
>  1. Show button relief on hover, keeping the button the same height as the
> others in the header bar.
> 
>  2. Always show the URL entry, and don't hide it.
> 
> If we went for option 2, I think we should try and reduce the amount of
> noise in the URL bar: only the domain could be shown when the entry isn't
> focused, for example.

And what you think of the solution(s) in Bug 755518, Allan? (mockup v3).

Removing the page title would bring us back to the pain again, see bug #711408

There's a bunch of wireframes that I did for this. I added some more details to them today, specifically for web app header bars:

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/web/web-bookmarks-and-header-bar-wires.png

(In reply to Allan Day from comment #38)
> There's a bunch of wireframes that I did for this. I added some more details
> to them today, specifically for web app header bars:
> 
> https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/web/
> web-bookmarks-and-header-bar-wires.png

Please note this latest iteration requires us to keep EphyTitleBox for web app mode.

Allan's wireframe (see Comment 38) with the "text box" address line looks good to me, EXCEPT FOR hiding the full address in the header bar. I believe that's a mistake. Without the full address, users will feel lost.

For example: In the wireframe, I didn't realize the mock-up page was about Ada Lovelace; it looked like it was for the front page. (I was confused why bookmarking the Wikipedia front page had an "Ada Lovelace" title.)

Can we not display the full URL and perhaps "gray out" the URI, the part past the domain?

Alternatively, display the full URL but highlight the domain (such as a box or highlight color or some other method)?

However, showing just the domain in "Web App" mode seems acceptable to me, because (1) the user will have set up the web app, and (2) the website is meant to appear as an application anyway.

(In reply to Jim Hall from comment #40)
> Allan's wireframe (see Comment 38) with the "text box" address line looks
> good to me, EXCEPT FOR hiding the full address in the header bar. I believe
> that's a mistake. Without the full address, users will feel lost.

There are plenty of precedents for not showing the full address. It's the standard behaviour in Safari, as well as mobile browsers.

> For example: In the wireframe, I didn't realize the mock-up page was about
> Ada Lovelace; it looked like it was for the front page. (I was confused why
> bookmarking the Wikipedia front page had an "Ada Lovelace" title.)

A mockup isn't the same as the real thing - you have no context for what you're seeing, and the scale is intentionally inaccurate.

> Can we not display the full URL and perhaps "gray out" the URI, the part
> past the domain?

That's an option, although it's not going to be as effective at focusing the UI as hiding the URI.
 
> Alternatively, display the full URL but highlight the domain (such as a box
> or highlight color or some other method)?
...

That's introducing more noise, when the point is to reduce it.

Hiding the full URL isn't a core part of this design, so we can certainly leave this detail until the other parts are implemented.

(In reply to Allan Day from comment #41)
> Hiding the full URL isn't a core part of this design, so we can certainly
> leave this detail until the other parts are implemented.

I'm fine with graying out the URI except for the domain.

I kinda wanted to get rid of the protocol, because I don't want to show https://, because some users have been trained to think the s means secure, but in the near future our browser will know better than that. And if we don't show the protocol, it doesn't make sense to show anything past the domain and maybe port. But Carlos was skeptical of not showing the full address, and it certainly complicates the implementation, so... I'm kinda leaning towards showing the full address now too.

We can save this for last and reconsider at the very end, because it's indeed not a core part of the design.

How about something like the current nautilus path bar but two boxes only for the url, without the steppers, and a go/stop/reload after that?
It would be something like this:

https://domain.com/category/myimages/birds.jpg
is represented as:
(https lock icon)[domain.com][category/myimages/birds.jpg] [go|stop|reload]


This means I can click on first box, [domain.com] the whole address bar becomes editable (second box disappears).
But when I click on the the second box, only the second box becomes editable.

If the width or the path is too long, it would look like this:
(https lock icon)[domain.com][category/myimages/dir1/dir2/dir3/dir4/di]

And then more of the url is shown when the user resizes the window.

After the address bar, there is a button that shows a [go] icon if the bar is in editable state, a [stop] icon if the website is in the middle of loading, and a [reload] icon if the website is already loaded but address bar is not in editable state.

(In reply to Hussam Al-Tayeb from comment #43)
> How about something like the current nautilus path bar but two boxes only
> for the url, without the steppers, and a go/stop/reload after that?
> It would be something like this:

It's an interesting idea, but at least for now let's just go back to a normal address bar, to keep things simple. Nobody will complain about that.

Yes, normal address bar good :)