My apologies for the length, this has literally been bouncing around
the back of my head since the awesome bar mockups two years ago.
Here are a few early mockups:
http://people.mozilla.com/~faaborg/files/20091012-personalWeb/bookmarksLocationBar-i1.png
http://people.mozilla.com/~faaborg/files/20091012-personalWeb/historyLocationBar-i1.png
http://people.mozilla.com/~faaborg/files/20091012-personalWeb/bookmarksContentAreaFirefox4-i1.png
I'll also be following up with some more involved mockups of
navigating history ranges.
As always, we are eager to get feedback,
-Alex
Comments and points I would add:
1 - Please include open tabs also in the searchable lists. Please please!.
I spend more time looking thru 50+ open tabs for a window that I know is
there somewhere than any other task. I leave open tabs for pages I might
want to refer to for a couple of days but don't want to bookmark. Unless
you add a category in bookmarks for temporary bookmarked....
2 - The idea of a search/filter, with nicely formatted UI category results
is the best way to extract from a huge amount of data. As you say its the
way many things such as Google, Google desktop search, Vista and Windows 7
search etc and many programming IDE's, and help systems are going (there are
many help systems with a help index with a filter searching on keywords).
3 - Allowing search on bookmark folder names and showing the folder paths of
existing bookmarks is a big improvement.
4 - This has the best parts of the CTRL+TAB UI (thumbnails of open tabs)
addition that came into Minefield a few months ago and was withdrawn again.
While still needing polish it was a great idea and I was using it a lot
before it went away. (Bring something like it back please!!!)
John Bird
1 - Press Ctrl+D
2 - Drop down the list of folders
3 - Immediate crash/exit of Firefox.
Is this happening for anyone else? If it is it needs to be fixed! If not
I have something messed up in bookmarks and need suggestions to fix them up.
John Bird
Can you provide some crash reporter URLs? Is there a bug on file?
Mike
Is this what you need?
Report ID Date Submitted
bp-4d3cdd48-35ad-4772-8e26-3c9e82091013 14/10/2009 12:52 p.m.
bp-2a19f57c-ffcb-4e7d-a04e-1d6e52091008 9/10/2009 2:34 p.m.
bp-1497aab5-54c2-4490-a5c5-8dea12091008 9/10/2009 2:24 p.m.
bp-78f2bc01-671d-4ae9-a5de-80ab82091004 5/10/2009 4:36 p.m.
bp-d6cb07fa-ab14-408c-bca3-9e2cd2091004 5/10/2009 9:35 a.m.
http://crash-stats.mozilla.com/report/pending/4d3cdd48-35ad-4772-8e26-3c9e82091013
http://crash-stats.mozilla.com/report/index/bp-2a19f57c-ffcb-4e7d-a04e-1d6e52091008
http://crash-stats.mozilla.com/report/index/bp-1497aab5-54c2-4490-a5c5-8dea12091008
http://crash-stats.mozilla.com/report/index/bp-78f2bc01-671d-4ae9-a5de-80ab82091004
http://crash-stats.mozilla.com/report/index/bp-d6cb07fa-ab14-408c-bca3-9e2cd2091004
I have not filed a bug (mainly because I presumed I was not alone in this
and am not that familiar with how to).
John Bird
----- Original Message -----
From: "Mike Shaver"
Cc: <dev-apps...@lists.mozilla.org>
Sent: Wednesday, October 14, 2009 1:22 PM
Subject: Re: Bookmarks crash
The first one is likely the same crash, just happens to have a different
stack signature.
-Sam
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
> Excellent ideas and mockups. You are on the right track.
>
> Comments and points I would add:
>
> 1 - Please include open tabs also in the searchable lists. Please please!.
> I spend more time looking thru 50+ open tabs for a window that I know is
> there somewhere than any other task. I leave open tabs for pages I might
> want to refer to for a couple of days but don't want to bookmark. Unless
> you add a category in bookmarks for temporary bookmarked....
>
We're planning to add tab matching in the URL bar for 3.7, which should
solve that use case.
--
Alexander Limi · Firefox User Experience · http://limi.net
Please add something for Keyword shortcuts in Autocomplete (AwesomeBar).
As you already have (and appear in about:config browser.urlbar.* )
Autocomplete option to restrict to keyword shortcuts, as you already
restrict to Tags.
restrict -- * Bookmarks, ^ History, + Tags, ~ typed
match -- # Title, @ URL
! might be good, $ might be good as S in Shortcut ($hortcut)
(but some might use as a currency conversion shortcut)
? would be bad, and contrary to Google Chrome's combined use of search bar
and location bar, so would not be a good choice. (Easily implemented in Firefox
as a keyword shortcut to a single search engine.)
< > bad, can be used for Previous / Next shortcuts (lower / higher numeric in url)
--
HTH,
David McRitchie, extensions I use are briefly documented on my site
Firefox Custom: http://www.mvps.org/dmcritchie/firefox/firefox.htm
Keyword shortcuts: http://www.mvps.org/dmcritchie/firefox/kws.htm
In using the AwesomeBar bookmark, tags appear on the right and would like
to be able to use right-click to get to the bookmark "Properties" (and even history)
but there is no context menu. I would also add "Delete" to that as it may not be intuitive
that user can delete history only item or portion with Del key.
Besides adding a 'keyword shortcuts' classification to the autocomplete, would also
like to be able to identify those with 'JavaScript'.
Optionally include (as opposed to restriction)
Folders
Descriptions
Two little nuisances that have frustrated me.
If I "find" a bookmark with search, there is no easy way to figure out
where it is in fact bookmarked.
If I bookmark a link that is already bookmarked, the boomark is moved
rather than reproduced. I need to be able to choose.
Solution to first problem,, but they because they are extensions
or preferences they help a very limited number of people:
Install both of these extensions, and add the new column
to the View of the Library list.:
Go Parent Folder -- Add "Go Parent Folder" menu to context menu
in The Library list view and Search result in Bookmarks Sidebar.
(Also install "Show Parent Folder".)
https://addons.mozilla.org/firefox/addon/7377
Show Parent Folder -- show containing bookmark directory folder
https://addons.mozilla.org/firefox/addon/7372
The second problem of not being able to keep/retain newly created
duplicate bookmarks is extremely annoying, particularly if you lose
a bookmark already in a folder or that has keyword, modified name,
or a description, or javascript,, or substitution, or you just want them
in two folders. It may sound helpful to identify or to delete or to
prevent duplicates but it is not worth it. If you showed me both and
allowed me to modify a bookmark while looking through webpages
wouldn't have a problem but the stuck on the toolbar and disappears
from view/modification when you click elsewhere is very annoying.
You can create at duplicate bookmark by dragging to a bookmark
folder, but not through the Star or through Ctrl+D using either of
those will change an existing bookmark. If you do, and you attempt
to remove ONE of them later you remove BOTH. "Remove Bookmarks(2)".
If we display an interactive breadcrumb trail (similar to Nautilus,
the Finder and Windows Explorer), then this problem should be very
much solved. You won't just know the location of the bookmark, but
will be able to easily navigate up the hierarchy in which it is
contained.
> If I bookmark a link that is already bookmarked, the boomark is
> moved rather than reproduced. I need to be able to choose.
There isn't a great way to expose multiple paths in the small
bookmarks panel accessible through the star (or if there is a simple
way, we haven't come up with it yet). However, for dragging pages
around, I think this UI should improve things, since users will
(ideally) be able to drag pages into these bookmark meta folders
contained in another tab, or another window.
-Alex
I'm confused. AFAIK, when I open the star, even of an existing
bookmark, it just offers me a choice of targets. It doesn't "start" at
the current location. So what is needed, if I try to place something
that's already placed, is a move/copy choice. I see no place in the
above that requires showing two or more paths.
Is the problem that the underlying mechanism immediately "places" the
bookmark in unsorted, and always "moves" it? If so, that's a mismatch
between the external geshtalt of the interface and its internal
implementation, and should simply be fixed.
See a screenshot here for how things are currently mixed up: <
http://www.flickr.com/photos/ehsanakhgari/4025654943/>
--
Ehsan
<http://ehsanakhgari.org/>
On Tue, Oct 13, 2009 at 4:24 AM, Alex Faaborg <faa...@mozilla.com> wrote:
> I just put an initial post up detailing some ideas to improve access to our
> Bookmarks and History UI in Firefox 3.7 and 4:
> http://blog.mozilla.com/faaborg/2009/10/13/browsing-your-personal-web/
>
> My apologies for the length, this has literally been bouncing around the
> back of my head since the awesome bar mockups two years ago.
>
> Here are a few early mockups:
>
> http://people.mozilla.com/~faaborg/files/20091012-personalWeb/bookmarksLocationBar-i1.png<http://people.mozilla.com/%7Efaaborg/files/20091012-personalWeb/bookmarksLocationBar-i1.png>
>
> http://people.mozilla.com/~faaborg/files/20091012-personalWeb/historyLocationBar-i1.png<http://people.mozilla.com/%7Efaaborg/files/20091012-personalWeb/historyLocationBar-i1.png>
>
> http://people.mozilla.com/~faaborg/files/20091012-personalWeb/bookmarksContentAreaFirefox4-i1.png<http://people.mozilla.com/%7Efaaborg/files/20091012-personalWeb/bookmarksContentAreaFirefox4-i1.png>
>
> I'll also be following up with some more involved mockups of navigating
> history ranges.
>
> As always, we are eager to get feedback,
>
> -Alex
is this after a restart? we should fix names on library left pane init,
but not if you change the localization on the fly.
if we don't, i guess your left pane could be old/corrupt. but can't
tell. Does that happen with a new profile (persian profile, change to
english, restart)?
Marco
Yes, it is after a restart (several of them, actually!). If by on the fly
you mean using something like the Quick Locale Switcher extension, then I'm
not using it.
I was always under the impression that this happens because some of the node
names are stored in the Places database upon profile creation, and some
other are dynamically generated. Isn't that so?
--
Ehsan
<http://ehsanakhgari.org/>
Actually can just type "Javascript" to include those with JavaScript
and "%S" to include those with substitutions.
-- %S firefox javascript ( * wouldn't be needed unless there were searches)
Still would like to find those with keyword, and to include
description in location bar search and to include Folders.
unfortunatly yes, some name is saved in the db (like All bookmarks,
bookmarks menu, tags...), some is dynamically injected (like children of
History like "today", "yesterday"). but for names saved in the db we
have a code that walks nodes and fixes titles if the localization
changes. but actually that depends on those items to be correctly
decorated with a special query annotation.
So, either that code does not work as expected or your profile is
missing some annotation (that's why i ask if this is reproduceable in a
new profile).
That said, would probably be better to inject all names in the frontend
part if that does not end being a perf problem (but we cache left pane
queries so should be easy).
There is/was a bug about that, but can't find it atm.
Marco
> Il 19/10/2009 17.55, Ehsan Akhgari ha scritto:
>
>> On Mon, Oct 19, 2009 at 11:31 AM, Marco Bonardo<
>> mak77NO...@supereva.it
>>
>>> wrote:
>>>
>> I was always under the impression that this happens because some of the
>> node
>> names are stored in the Places database upon profile creation, and some
>> other are dynamically generated. Isn't that so?
>>
>
> unfortunatly yes, some name is saved in the db (like All bookmarks,
> bookmarks menu, tags...), some is dynamically injected (like children of
> History like "today", "yesterday"). but for names saved in the db we have a
> code that walks nodes and fixes titles if the localization changes. but
> actually that depends on those items to be correctly decorated with a
> special query annotation.
>
> So, either that code does not work as expected or your profile is missing
> some annotation (that's why i ask if this is reproduceable in a new
> profile).
>
I've actually seen this pretty constantly, since I switch between Firefox
languages a lot, but just to make sure, I tried it right now, and yes, it's
reproducible on a new profile.
> That said, would probably be better to inject all names in the frontend
> part if that does not end being a perf problem (but we cache left pane
> queries so should be easy).
>
> There is/was a bug about that, but can't find it atm.
Yes, as a user I would expect those folders to come in the language which
Firefox speaks.
--
Ehsan
<http://ehsanakhgari.org/>
Right now the star panel assumes for the most part only one instance
of a bookmark, so the folder choice is based around move operations.
The bookmark does start in the current location in that the default
location for stared bookmarks is a folder called unsorted bookmarks.
We created this folder to avoid having potentially thousands of items
placed in a browse-based UI like the bookmarks menu or toolbar (and
subsequently giving users an incentive not to bookmark too many items
because it quickly gets unwieldy).
-Alex
please file a bug i'll take a look to both why our current code does not
fix titles, and if doing that dynamically for all nodes is easily
feasible without perf loss.
Marco
That would be nice for sure.
Robert Kaiser
what are current Seamonkey needs and issues in this regard?
Even if we do this in frontend, you'd have to take our code and do the
same, would not come for free. I suppose you need a way to customize
history grouping and names?
-m
> Il 19/10/2009 19.39, Ehsan Akhgari ha scritto:
>
>> On Mon, Oct 19, 2009 at 12:06 PM, Marco Bonardo<
>> mak77NO...@supereva.it
>>
>>> wrote:
>>> So, either that code does not work as expected or your profile is missing
>>> some annotation (that's why i ask if this is reproduceable in a new
>>> profile).
>>>
>>>
>> I've actually seen this pretty constantly, since I switch between Firefox
>> languages a lot, but just to make sure, I tried it right now, and yes,
>> it's
>> reproducible on a new profile.
>>
>
> please file a bug i'll take a look to both why our current code does not
> fix titles, and if doing that dynamically for all nodes is easily feasible
> without perf loss.
>
Sure, filed https://bugzilla.mozilla.org/show_bug.cgi?id=523361.
--
Ehsan
<http://ehsanakhgari.org/>
No idea, as we're not having Places Bookmarks UI at all yet, we'll only
start to work on that for the next version (probably based on 1.9.3).
I was talking with the localizer hat on there, mainly. ;-)
> Even if we do this in frontend, you'd have to take our code and do the
> same, would not come for free. I suppose you need a way to customize
> history grouping and names?
Sure, I assume we need to port stuff that comes from you there, but that
should not stop toolkit from doing "The Right Thing (TM)" which IMHO is
to not store but "just" display localized names where possible.
I actually know too little about history grouping there to answer this
from a really technical POV.
Robert Kaiser
I think before you come up with ever new fancy ideas to improve the
bookmarks UI, Mozilla people should finally make up their minds and
first straighten out the quirks and deficiencies introduced with the
"revised" bookmarks of FF 3 which have annoyed so many users (judged
by the enormous amount of complaints I've seen on the web).
Having said this, I'm trying to switch off polemic mode; I see
three major groups of requirements to bookmarks handling:
(Disclaimer: some of my comments might be obsolete since I'm still
using FF 2 precisely to avoid my bookmarks handling getting worse.)
Support bookmarks management, navigation and orientation
* Support hierarchical structure as well as tags, don't oppress
established hierarchical management paradigm in favor of the tags
mechanism just because many people find it more modern.
* Support individual approaches to bookmarks structuring:
- Reintroduce labelled separators (from FF 2, Seamonkey) which
are
a good means of additional overview within a bookmarks folder,
see https://bugzilla.mozilla.org/show_bug.cgi?id=404983
I really have no understanding why Mozilla people are so
reluctant
to reestablish this useful simple feature.
- Improve presentation of bookmark descriptions which can now only
be
displayed in an additional column.
- Allow optional graphics in bookmark descriptions.
- Offer bookmarks management in web-page-like view, unifying
bookmarks organizer with bookmarks.html display as it used to
be offered by an extension (forgot the name, sorry) which could
only present them read-only, however, so it wasn't too useful.
* Support orientation in search results:
- Clearly associate search set with hierarchical structure;
The "Parent Folder" and previous "Locate in Bookmark Folders"
extensions as a core feature would be a minimum of appropriate
support.
- Better browse the search results in-place within the
hierarchical
structure as Netscape 4 used to do,
see https://bugzilla.mozilla.org/show_bug.cgi?id=171575
* Consistent handling: Allow folder option "Open All in Tabs" on
left
pane alike as on right pane of bookmarks manager.
Performance
Performance of bookmarks management operations has been poor for a
long time,
see https://bugzilla.mozilla.org/show_bug.cgi?id=427521 and
https://bugzilla.mozilla.org/show_bug.cgi?id=472343
Sorry I've not rechecked this recently, maybe it's fixed by
now, but it had been claimed fixed a number of times already
and wasn't.
Also performance of simply "Add a bookmark" is often poor on my
machine - is a 1.6 MHz single-core considered too slow for modern
FF?
Since that may be the cause, let me note that I've never seen a
convincing argument for putting bookmarks into a database with FF 3;
performance might be one if it worked, but in that case it was not
successful.
Interoperability
Committed support to import and export of the good old
bookmarks.html format:
* Don't go proprietary (the MS strategy); clearly support this as
an
exchange format.
* Its location should be easily configurable (not only in
About:config) in order to support dual-boot systems.
* Its default location should be intuitive; the cryptic "v5isns8q"
profile directory approach is a relic of single-user Windows
times
and should be abandoned.
Thomas Wolff