Re: [Epiphany] Bookmarks system
- From: Marco Pesenti Gritti <mpeseng tin it>
- To: Lee Willis <lwillis plus net>
- Cc: epiphany mozdev org
- Subject: Re: [Epiphany] Bookmarks system
- Date: 11 Mar 2003 11:16:57 +0100
On Tue, 2003-03-11 at 09:52, Lee Willis wrote:
> Marco Pesenti Gritti <mpeseng@tin.it> writes:
>
> > > ...if it's a dialog that obscures your browsing or is otherwise
> > > invasive (Because it has to be activated each time you want to use
> > > it) then it becomes less efficient than a menu IMHO ...
> >
> > Heh hard to make a call basing ourself just on our IHMO ;)
> > The dialog seem to even take less time here while providing a better and
> > more powerfull view of the collection, but I need to stop saying this
> > ... not very productive ;)
>
> Let's junk the "efficiency/speed" discussions - after all they're just
> implementation constraints - I'm sure you'll work your nuts off to make
> them go away if we need to :)
Oh, I was not clear. I was not talking of speed like implementation
here. I tried to change encoding (similar task to bookmarks not having
the real bookmarks menu) and to select a bookmark.
Not considering the Close step it took one second less for me.
Obviously this is a very unscientific test ;)
But I think I'm not the only one to think that submenus are phisically
hard to browse.
> I'll try to avoid points made on speed from now on ...
>
> > > What I'd like to see is the current bookmarks dialog be an always on
> > > docked sidebar (Think of the Favourites sidebar in IE). That gives us
> > > the following advantages:
> > >
> > > - Always available - doesn't need to be opened each time you need it
>
> This point still stands since it's not directly based on performance
> issues, but on whether I can start using bookmarks without an extra
> step. Currently I have to open the bookmark dialog before I can start
> doing anything - that's an extra step that I'd like to see go away. In
> it's place I'd like to see either a docked view, or the ability to say
> that I want a toolbar present that shows me all bookmarks matching a
> given keyword, or keywords. This also satisfies my requirement below.
Your second option is going to be implemented. It's really not something
hard to do also.
I certainly see how the dock would solve the problem but ... it wouldnt
work for me for the reason below.
> > > - Doesn't obscure the browsing view (My problem is I check several news
> >
> > I thought to that too a pair of time but I dont think it would improve
> > the thing much for me. I dont like to browse with clutter around my web
> > page so I'd keep closing the sidebar.
>
> It's only "clutter" if it gets in the way of what you're trying to
> do. For me the current dialog is clutter since it obscures pages that
> I'm trying to interact with -
Certainly the dialog is more clutter that the dock. The point is that I
hide it when looking at the page.
It's not true that only something gets in you way is clutter though. A
big menubar is clutter too or lots of toolbars ...
Another reason because some people doesnt like to browse with sidebar
open is that it takes a lot of space, and on small screens that's a
problem.
> toolbars or docked views don't have that
> problem - the page flows around them (Of course both can have their own
> problems if you're on a small screen - I'd like to solve this in a
> similar way to how galeon used to do it - ie the bookmark interface
> [However we define it] should be either a docked view, or a dialog (As
> we currently have it now), This way the user can put in place the right
> solution for their environment constraints. The default I think should
> be docked though since my *guess* is that enough people can afford the
> screen real-estate ...
The double view could solve the problem. I sort of prefer the toolbar
approach though.
> > It wouldnt make it worst though .... The conflict is in the close
> > behavior. Sidebar or not I'd prefer the thing to close automatically
> > when I selected a bookmark.
>
> For a dialog that makes sense - it makes no sense for a docked pane ...
Yeah I agree here. With the sidebar I couldnt have autoclose ;)
> > Looking at the design as a whole there are two ways to do what you was
> > describing (open all your favourite news sites): bookmarks toolbars
> > (with the keyword dnd still not implemented)
>
> Yes that sort of solves my problem, although not really efficiently
> since I can't middle clik a toolbar item to open in new window/tab.
I dont think there are problems to make middle click behave that way ...
> > and autocompletion (ctrl+l lin get me to linuxtoday very fastly).
>
> Ooh - putting keywords in the URL bar solves completely my point
> later[1] - although it should be case-insensitive - do you want a bug on
> that?
There is already one posted. It's a pain to fix it with current
autocompl implementation. Maybe I'll wait we pass to EggCombo to solve
this :/
> > If we move bookmarks in a sidebar we will have some more problems for
> > editing
>
> Why?
There is less horizontal space ... this is just a feeling, I ever had
some problems with history dialog dock ;)
> However - if we allow the bookmark UI to be in it's own window [As I
> suggested above] then you still have major problems about how the user
> selects their "active" window.
>
> The GIMP also has these same issues in the same way, ie you have several
> document windows, and a window that can change things (The toolbox in
> GIMP - bookmark UI in epiphany) - but no clear way to tie the changing
> to a specific window. They built a whole "active window" management
> system to get around this (IIRC something like a single click of Ctrl in
> the window you want to be active and a small indicator area in each
> window which showed whether it was the "active" window). I don't think
> we want to do that [Unless their code is easily re-usable], and I don't
> particularly think we can build the "right thing" without it. If you
> decide to implement the ability for the bookmark UI to be in it's own
> window I think you just have to come up with a basic rule and live with
> it not being perfect :(
Personally I think we should use set_transient like we do now.
> > Prolly META would make the keywords list useless. I dont read pages
> > source very often but I have the impression designers put tons of words
> > there to be more visible on search engines. Am I wrong ?
>
> Depends how much porn you browse I s'pose ;) I think most serious sites
> use sensible keywords that are actually relevant - perhaps an
> implementation would help us guage how useful this actually is though
> ... If it never crops up on its own I may try myself to see how far I get!
Haha. Yeah this seem the sort of thing that needs to be tried to see how
it's good.
Marco
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]