Re: Upcoming UI changes

[Michael Catanzaro]

Feel free to propose patches for moving menu items around; I think it'd
be OK to have more stuff in the window menu.

On Wed, 2016-10-12 at 02:14 +0800, 藍挺瑋 wrote:
> I am not sure why it had to flicker between the title box and the
> entry. If the reason was that we could not know the title immediately
> after it starts loading, can we show only the URL when the title is
> not
> available like what Evince does when opening a PDF file without
> title,
> and switch back to title and URL once the title is loaded?

It looks bad when the title is missing; someone would have to make it
look good. Switching back to location entry mode was the best we came
up with in two years of using the title box.

I'm not saying that we can't bring back the title box, just that I
personally don't know how to make it work well and look good at the
same time. Willing to consider patches here too.

Michael
___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[藍挺瑋]

於 週二，2016-10-11 於 08:57 -0500，Michael Catanzaro 提到：
> Hi,
> 
> On Tue, 2016-10-11 at 18:43 +0800, 藍挺瑋 wrote:
> > 
> > I think it is bad to show only the domain.
> 
> OK, enough people have complained about this aspect of the mockup
> that
> I have no plans to implement it.
> 
> > 
> > Is it possible to keep the web page title shown in the header bar?
> > Most
> > desktop browsers show the title at the top of the window or using
> > it
> > as
> > the window title. It will be nice if Epiphany can keep this feature
> > because the URL is not always readable or useful.
> 
> I don't think so, there's not really any room for page title anymore.
> Where would it go? Are page titles really important? I don't miss it
> at
> all.

I still like the old title box that packs the title and the URL in the
header bar because the URL usually provides less information to users
than the web page title. The old title box design is consistent with
other applications such as Evince and Gedit.

I am not sure why it had to flicker between the title box and the
entry. If the reason was that we could not know the title immediately
after it starts loading, can we show only the URL when the title is not
available like what Evince does when opening a PDF file without title,
and switch back to title and URL once the title is loaded?

> 
> > 
> > Moving important functions such as viewing page source to the
> > context
> > menu doesn't look good to me.
> 
> Funny story: when I started using Epiphany, I thought this feature
> did
> not exist, because other browsers have it in their context menus and
> I
> did not think to check the window menu!
> 
> But yeah, we can definitely rethink how options are scattered between
> the context menu and the hamburger menu.

So it seems it is better to keep some functions in both menus as long
as it doesn't make menus become too long.

> 
> > 
> > Some web pages disable the context menu
> > or replacing the context menu with their own menus. If we don't
> > keep> these functions in the hamburger menu, they becomes
> > inaccessible to> users unless there are keyboard shortcuts bound to
> > them, users
> > > 
> > >  remember> shortcuts, and web pages don't disable shortcuts.
> 
> On the rare sites that do override the context menu, you can always
> get
> the Epiphany context menu with a second right-click (sans bugs) so
> nothing should ever become inaccessible.

Thanks for the tip. I didn't know double right-click can do this.
However, it didn't always work for me. I tested it with Google Document
(https://docs.google.com/document/d/) and Google Drive (https:/
/drive.google.com). It worked with the former but not with the latter.
Even if double right-click works without problem, I think it is hardly
discoverable by most users.

> 
> > 
> > I even think we can
> > move 'Inspect Element' to the hamburger menu, so using the
> > inspector
> > on
> > web pages with context menu disabled can be easier.
> 
> Inspect Element can't move because it depends on the element
> selected,
> right? We could add a generic 'open inspector' menu item though.

I forgot that it is possible to move focus to selected things in the
inspector with right-click on the page. Yes, I mean 'Open Inspector'
here.

___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[Carlos Garcia Campos]

El mar, 11-10-2016 a las 11:06 -0500, Michael Catanzaro escribió:
> On Tue, 2016-10-11 at 17:21 +0200, Carlos Garcia Campos wrote:
> > 
> > I think they are important and I missed them a lot when we moved to
> > use
> > a header bar with the location entry only. And enough people
> > complained
> > at that time about it too.
> 
> I don't see where we can put it. :(
> 
> We do still change the window title, so it's visible in the shell
> overview, but the window title is no longer visible anywhere in the
> window itself. I don't see how to fix it without bringing back the
> title box.

Keeping the title box but making it discoverable, as already suggested
in this list.

> Michael
> 
-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get=0xF3D322D0EC4582C3

signature.asc
Description: This is a digitally signed message part
___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[Michael Catanzaro]

On Tue, 2016-10-11 at 17:21 +0200, Carlos Garcia Campos wrote:
> I think they are important and I missed them a lot when we moved to
> use
> a header bar with the location entry only. And enough people
> complained
> at that time about it too.

I don't see where we can put it. :(

We do still change the window title, so it's visible in the shell
overview, but the window title is no longer visible anywhere in the
window itself. I don't see how to fix it without bringing back the
title box.

Michael
___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[Carlos Garcia Campos]

El mar, 11-10-2016 a las 08:57 -0500, Michael Catanzaro escribió:
> Hi,
> 
> On Tue, 2016-10-11 at 18:43 +0800, 藍挺瑋 wrote:
> > 
> > I think it is bad to show only the domain.
> 
> OK, enough people have complained about this aspect of the mockup
> that
> I have no plans to implement it.
> 
> > 
> > Is it possible to keep the web page title shown in the header bar?
> > Most
> > desktop browsers show the title at the top of the window or using
> > it
> > as
> > the window title. It will be nice if Epiphany can keep this feature
> > because the URL is not always readable or useful.
> 
> I don't think so, there's not really any room for page title anymore.
> Where would it go? Are page titles really important? I don't miss it
> at
> all.

I think they are important and I missed them a lot when we moved to use
a header bar with the location entry only. And enough people complained
at that time about it too.

> > 
> > Moving important functions such as viewing page source to the
> > context
> > menu doesn't look good to me.
> 
> Funny story: when I started using Epiphany, I thought this feature
> did
> not exist, because other browsers have it in their context menus and
> I
> did not think to check the window menu!
> 
> But yeah, we can definitely rethink how options are scattered between
> the context menu and the hamburger menu.
> 
> > 
> > Some web pages disable the context menu
> > or replacing the context menu with their own menus. If we don't
> > keep> these functions in the hamburger menu, they becomes
> > inaccessible to> users unless there are keyboard shortcuts bound to
> > them, users
> > > 
> > >  remember> shortcuts, and web pages don't disable shortcuts.
> 
> On the rare sites that do override the context menu, you can always
> get
> the Epiphany context menu with a second right-click (sans bugs) so
> nothing should ever become inaccessible.
> 
> > 
> > I even think we can
> > move 'Inspect Element' to the hamburger menu, so using the
> > inspector
> > on
> > web pages with context menu disabled can be easier.
> 
> Inspect Element can't move because it depends on the element
> selected,
> right? We could add a generic 'open inspector' menu item though.
> 
> Michael
> ___
> epiphany-list mailing list
> epiphany-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/epiphany-list
-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get=0xF3D322D0EC4582C3

signature.asc
Description: This is a digitally signed message part
___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[Michael Catanzaro]

Hi,

On Tue, 2016-10-11 at 18:43 +0800, 藍挺瑋 wrote:
> I think it is bad to show only the domain.

OK, enough people have complained about this aspect of the mockup that
I have no plans to implement it.

> Is it possible to keep the web page title shown in the header bar?
> Most
> desktop browsers show the title at the top of the window or using it
> as
> the window title. It will be nice if Epiphany can keep this feature
> because the URL is not always readable or useful.

I don't think so, there's not really any room for page title anymore.
Where would it go? Are page titles really important? I don't miss it at
all.

> Moving important functions such as viewing page source to the context
> menu doesn't look good to me.

Funny story: when I started using Epiphany, I thought this feature did
not exist, because other browsers have it in their context menus and I
did not think to check the window menu!

But yeah, we can definitely rethink how options are scattered between
the context menu and the hamburger menu.

> Some web pages disable the context menu
> or replacing the context menu with their own menus. If we don't
> keep> these functions in the hamburger menu, they becomes
> inaccessible to> users unless there are keyboard shortcuts bound to
> them, users
> > remember> shortcuts, and web pages don't disable shortcuts.

On the rare sites that do override the context menu, you can always get
the Epiphany context menu with a second right-click (sans bugs) so
nothing should ever become inaccessible.

> I even think we can
> move 'Inspect Element' to the hamburger menu, so using the inspector
> on
> web pages with context menu disabled can be easier.

Inspect Element can't move because it depends on the element selected,
right? We could add a generic 'open inspector' menu item though.

Michael
___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[Michael Gratton]

On Sun, Oct 2, 2016 at 6:04 AM, tev...@gmail.com  
wrote:
So if anyone has anything to say about the design and functionalities 
that are wished for the overview, please take your turn.


A few times I have accidentally removed pages from it, and had to go 
editing the config files to get it back. Having an undo toaster would 
be great.


--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[Michael Catanzaro]

On Sat, 2016-10-01 at 19:04 +, tev...@gmail.com wrote:
> So if anyone has anything to say about the design
> and
> functionalities that are wished for the overview, please take your
> turn.

The main feature I'd like to see is the ability to pin arbitrary sites
to the overview.

It'd also be nice to make it prettier. Firefox uses bigger icons;
that's probably the right approach.

Michael
___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[tev...@gmail.com]

I think I'll take a ride in this thread... My name is Estêvão and I'm
willing to contribute to epiphany development. Talked to Michael Catanzaro
at IRC and he told me that the overview UI needed some love. So I want help
with that, but I have seen a lot of designs and I'm not sure about which
one is the current. So if anyone has anything to say about the design and
functionalities that are wished for the overview, please take your turn.

Thanks!

Estêvão Samuel Procópio Amaral
___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[Michael Gratton]

On Sat, Oct 1, 2016 at 6:32 AM, Iulian Radu  
wrote:

On Tue, Sep 27, 2016 at 10:41 AM, Michael Catanzaro
 wrote:

 On Tue, 2016-09-27 at 14:13 +1000, Michael Gratton wrote:

 How do the set of tags in the Add Bookmark and Bookmark Properties
 popovers scale when you have a lot? Using a scrolled window? I have
 around one hundred.


 Iulian, can you answer this?


Yes, we are using a scrolled window.


Hmm, that's going need a lot of scrolling to find the tags I want 
there. Is there any way to retain the existing method of type-to-find? 
Using autocomplete or type-to-filter or something?


//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[Iulian Radu]

I don't know why, but I was thinking at the page menu button
(hamburger button). Sorry!

That's true, the gear button is only accessible on hover so I assume
there's no way that could work on touchscreens at the moment. I hope
you don't mind if I went ahead and opened a bug here [1]. I'm not sure
if displaying all buttons simultaneously is the best idea but any
suggestion is welcome.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=772268

Thanks,
Iulian
___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[Jérémy Lal]

2016-09-30 22:43 GMT+02:00 Iulian Radu :

> On Tue, Sep 27, 2016 at 10:44 AM, Michael Catanzaro
>  wrote:
> > On Tue, 2016-09-27 at 09:26 +0200, Jérémy Lal wrote:
> >> - is the gear button accessible even on touchscreens ?
> >
> > Iulian, can you answer this too?
>
> Yes, it should be accessible on touchscreens as well. I haven't tested
> it, but I don't see why not.
>
> Iulian
>

Because as the mockup shows it, it is only displayed on hover, something
that's not easily accessible on touchscreens.
For example, gpaste menu shows delete icon on each item to avoid the "hover
is not accessible" issue.

Jérémy
___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[Michael Catanzaro]

On Tue, 2016-09-27 at 14:13 +1000, Michael Gratton wrote:
> How do the set of tags in the Add Bookmark and Bookmark Properties 
> popovers scale when you have a lot? Using a scrolled window? I have 
> around one hundred.

Iulian, can you answer this?

> It always confuses me that Send Link is in a context menu, rather
> than 
> the header bar menu. Not many of the items in Ephy's context menu
> are 
> really context-specific - most are in fact tab/page-specific.

Yeah, that's a bit confusing indeed. The logic there is that the
context menu contains both actions in the context of the page, plus
actions in the context of what you're clicking on in the page. But we
have other page-specific actions like Text Encoding and Save As Web
Application in the window menu, so it's not really consistent. Not sure
how we should handle this.

>  In fact, 
> with the exception of Inspect, the only ones that are context-
> specific 
> and that a non-developer would actually use (cut/copy/paste) seem to 
> have been removed in the mockup. Wouldn't it be better to put 
> cut/copy/paste back and move the rest to the header bar menu, where 
> they are actually discoverable?

The mockup does indicate that cut/copy/paste should be in the page
context menu, but they're not pictured... hm. Anyway, certainly they
should be there; we have to have UI for them somewhere, and the window
menu isn't a good place.

Michael
___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[Jérémy Lal]

- is the gear button accessible even on touchscreens ?
- not showing url path doesn't look right to me, it levels down user
knowledge about the web page, it's so scary.

otherwise it's an exciting ui !

Jérémy

2016-09-22 18:56 GMT+02:00 Michael Catanzaro :

> Hi,
>
> We're working on some major UI changes for Epiphany 3.24, based on [1].
> I should have mailed this list to solicit feedback when we got the
> mockup, we've had it nearly a year now. Sorry, I just didn't think to
> do so. Anyway, we still have five months to make changes before UI
> freeze, so there's plenty of time to complain if you see something you
> don't like. Almost everything in the mockup has already been
> implemented, except for some details (the lock icon isn't green yet,
> and we're currently showing the full URL in the address bar), though
> the bookmarks stuff is on a sidebranch still. The exceptions are the
> hamburger menu popover (which Iulian is going to work on very soon) and
> the page context menu (not currently planned, it might not even be
> possible with the current WebKit API, not sure).
>
> Michael
>
> [1] https://raw.githubusercontent.com/gnome-design-team/gnome-
> mockups/master/web/web-bookmarks-and-header-bar-wires.png
> ___
> epiphany-list mailing list
> epiphany-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/epiphany-list
>
___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Re: Upcoming UI changes

[Michael Gratton]

Hi Michael,

On Fri, Sep 23, 2016 at 2:56 AM, Michael Catanzaro 
 wrote:
We're working on some major UI changes for Epiphany 3.24, based on 
[1].

I should have mailed this list to solicit feedback when we got the
mockup, we've had it nearly a year now


The mockups in general look good — I'm a fan. I would only make two 
minor comments, however:


How do the set of tags in the Add Bookmark and Bookmark Properties 
popovers scale when you have a lot? Using a scrolled window? I have 
around one hundred.


It always confuses me that Send Link is in a context menu, rather than 
the header bar menu. Not many of the items in Ephy's context menu are 
really context-specific - most are in fact tab/page-specific. In fact, 
with the exception of Inspect, the only ones that are context-specific 
and that a non-developer would actually use (cut/copy/paste) seem to 
have been removed in the mockup. Wouldn't it be better to put 
cut/copy/paste back and move the rest to the header bar menu, where 
they are actually discoverable?


//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list

Upcoming UI changes

[Michael Catanzaro]

Hi,

We're working on some major UI changes for Epiphany 3.24, based on [1].
I should have mailed this list to solicit feedback when we got the
mockup, we've had it nearly a year now. Sorry, I just didn't think to
do so. Anyway, we still have five months to make changes before UI
freeze, so there's plenty of time to complain if you see something you
don't like. Almost everything in the mockup has already been
implemented, except for some details (the lock icon isn't green yet,
and we're currently showing the full URL in the address bar), though
the bookmarks stuff is on a sidebranch still. The exceptions are the
hamburger menu popover (which Iulian is going to work on very soon) and
the page context menu (not currently planned, it might not even be
possible with the current WebKit API, not sure).

Michael

[1] 
https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/web/web-bookmarks-and-header-bar-wires.png
___
epiphany-list mailing list
epiphany-list@gnome.org
https://mail.gnome.org/mailman/listinfo/epiphany-list