After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 739634 - Implement new design for title bar (location entry is hard to discover)
Implement new design for title bar (location entry is hard to discover)
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: Interface
3.16.x (obsolete)
Other Linux
: Normal enhancement
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks: 755518 767585 767625
 
 
Reported: 2014-11-04 19:03 UTC by Michael Catanzaro
Modified: 2016-11-26 18:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Display a tooltip when hovering over the title box (1.72 KB, patch)
2015-03-27 03:02 UTC, Michael Catanzaro
none Details | Review
screenshot of raised button (138.49 KB, image/png)
2015-03-27 12:32 UTC, Michael Catanzaro
  Details
Switch the title box mode on hover, not on click (13.93 KB, patch)
2015-03-27 15:32 UTC, Michael Catanzaro
none Details | Review
Switch the title box mode on hover, not on click (15.43 KB, patch)
2015-03-29 03:14 UTC, Michael Catanzaro
none Details | Review
Proposal from Alessandro (84.50 KB, image/png)
2015-08-11 12:28 UTC, Michael Catanzaro
  Details

Description Michael Catanzaro 2014-11-04 19:03:44 UTC
It's not at all clear that the title box is clickable. We should draw a border around the title box on hover, to indicate clickability.
Comment 1 Michael Catanzaro 2015-03-27 02:30:51 UTC
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)
Comment 2 Michael Catanzaro 2015-03-27 03:02:04 UTC
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.
Comment 3 Christian Hergert 2015-03-27 04:06:14 UTC
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)
Comment 4 Jakub Steiner 2015-03-27 11:00:20 UTC
(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.
Comment 5 Michael Catanzaro 2015-03-27 11:30:55 UTC
Maybe we can ditch the tooltip if it's .flat, since it doesn't look terribly good.
Comment 6 Lapo Calamandrei 2015-03-27 12:05:36 UTC
I'd also try moving the downarrow from the subtitle url side to the title side.
Comment 7 Michael Catanzaro 2015-03-27 12:32:17 UTC
(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!)
Comment 8 Michael Catanzaro 2015-03-27 12:32:44 UTC
Created attachment 300437 [details]
screenshot of raised button

I'm not sure that using a raised button looks quite right....
Comment 9 Yosef Or Boczko 2015-03-27 12:38:50 UTC
(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.
Comment 10 Michael Catanzaro 2015-03-27 12:44:07 UTC
Oh but I'm only supposed to do it on hover, like Jakub said. Maybe that would work.
Comment 11 Lapo Calamandrei 2015-03-27 12:56:36 UTC
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).
Comment 12 Yosef Or Boczko 2015-03-27 13:01:13 UTC
(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?
Comment 13 Lapo Calamandrei 2015-03-27 13:33:34 UTC
(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?
Comment 14 Lapo Calamandrei 2015-03-27 13:36:54 UTC
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.
Comment 15 Michael Catanzaro 2015-03-27 13:46:05 UTC
Sounds good to me, why not?
Comment 16 Michael Catanzaro 2015-03-27 15:32:02 UTC
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.
Comment 17 Lapo Calamandrei 2015-03-27 18:28:10 UTC
Michael the patch doesn't apply cleanly to master, is that against master + your tooltip patch?
Comment 18 Lapo Calamandrei 2015-03-27 18:33:37 UTC
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?
Comment 19 Michael Catanzaro 2015-03-27 20:23:23 UTC
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.
Comment 20 Yosef Or Boczko 2015-03-28 22:27:08 UTC
(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?
Comment 21 Michael Catanzaro 2015-03-28 23:12:47 UTC
(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
Comment 22 Yosef Or Boczko 2015-03-28 23:20:05 UTC
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.
Comment 23 Michael Catanzaro 2015-03-29 03:14:22 UTC
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....
Comment 24 Yosef Or Boczko 2015-03-29 21:03:48 UTC
What do you think on making the uri as link button?
Comment 25 Michael Catanzaro 2015-03-29 21:41:39 UTC
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.
Comment 26 Yosef Or Boczko 2015-03-29 21:51:01 UTC
(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).
Comment 27 Yosef Or Boczko 2015-03-29 21:55:32 UTC
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).
Comment 28 Lapo Calamandrei 2015-03-30 11:15:01 UTC
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
Comment 29 Michael Catanzaro 2015-03-30 12:56:50 UTC
Yes, I was planning to do that anyway :p
Comment 30 Lapo Calamandrei 2015-03-30 13:04:00 UTC
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 ]
Comment 31 Yosef Or Boczko 2015-03-30 13:10:03 UTC
(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 ;-)
Comment 32 Lapo Calamandrei 2015-03-30 13:12:11 UTC
...and a third time,

(up arrow) Click the title for the text entry

[ I UNDERSTAND, GO TO HELL ] <- in red
Comment 33 Michael Catanzaro 2015-08-11 12:28:31 UTC
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;
}
Comment 34 Lapo Calamandrei 2015-08-11 12:35:04 UTC
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.
Comment 35 Allan Day 2015-10-07 12:44:25 UTC
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.
Comment 36 Diogo Campos 2015-10-07 16:57:06 UTC
(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).
Comment 37 Carlos Garcia Campos 2015-10-07 18:00:09 UTC
Removing the page title would bring us back to the pain again, see bug #711408
Comment 38 Allan Day 2016-03-24 15:47:36 UTC
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
Comment 39 Michael Catanzaro 2016-03-31 17:42:04 UTC
(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.
Comment 40 Jim Hall 2016-04-01 15:19:36 UTC
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.
Comment 41 Allan Day 2016-04-01 16:37:41 UTC
(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.
Comment 42 Michael Catanzaro 2016-04-02 01:17:51 UTC
(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.
Comment 43 Hussam Al-Tayeb 2016-06-29 06:30:34 UTC
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.
Comment 44 Michael Catanzaro 2016-06-29 13:58:30 UTC
(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.
Comment 45 Hussam Al-Tayeb 2016-06-29 14:25:42 UTC
Yes, normal address bar good :)