Bookmarks not even close to ready for prime-time
Ben Bucksch
The places bookmarks management is still not ready for general use. I am shocked about the state it is in.
Problems:
- Migration from bookmarks.html
- Keep stable
- bookmarks.html is a common,
well-known format that's supported by many third-party apps, both read
and write. All non-Firefox apps which want to access the user's
bookmarks have to be changed. I don't mean spyware, but other browsers
(Konqueror, Epiphany, ...), enterprise migration tools, desktop search
/ datawarehouse / research apps,
user-written backup scripts/rules. - It wasn't a bad format. It's not binary, but most content (url, title) is text anyways.
- A neat feature was that I could load
bookmarks.html directly into any browser and use my bookmarks like
that, as a fallback.
- Why something as fragile as a relational database? What if the database schema needs to change for history, bookmarks, new feature ABC, speed-improvement D? Breaks compatibility again. The situation here is *not* comparable with a enterprise database, where there is only a single instance, and it's operated by tons of admins and developers and the point of migration is scheduled by managers. A completely different situation from user files.
- Essentially, user data is the by far most valuable resource on the computer, 100 times more expensive than the CPU or disk, so it is extremely important to keep it reliable, stable, accessible to the user. "To the user" means not just this particular application in this version, compare Microsoft Word documents.
- The bookmarks are the *only* important user data for a browser. Is it so hard to keep it stable? We managed to keep it stable from Netscape (1?, 2? 3?) 4 to 2007, so why do we need to change it now?
- Not forward-/backward compatible
- I in fact somehow lost a big deal of bookmarks by switching between Firefox 2 and 3. I had to recover an old, manual backup of my bookmarks.html and start from there
- If user switched from Firefox 3 back
to 2, the new bookmarks will not be there. If he adds bookmarks in FF2
and later goes to FF3, will the new bookmark.html be re-imported?
Merged?
- Are you going to stick with sqlite forerver?
- Proposal:
- Keep bookmarks.html as master storage
- Use a copy in sqlite, or something
similar in RAM, to make quick queries on.
- Slow
- The idea to switch to sqlite was to be faster, I guess. In effect, it's noticably slower.
- On first start, takes *minutes* to
import my bookmarks (10000 or so). No UI *at all*, no hint at what it's
doing, not even any window up, just 100% CPU in background.
- The day-to-day UI is extremely sluggish
- Bad UI in Add bookmark
- Why not a modal dialog? This is a *classic* case for it. I edited a web form, accidently hit Ctrl-D instead of Ctrl-C, and wondered why nothing in the form changes, until I noticed the bookmarks "dialog" in the upper right and took my input.
- Clicked "Done" to get the dialog away.
Later I wondered about a strange bookmark on the top level. I should
have clicked "Delete" to Cancel the dialog. How unintuitive is that?
Delete sounds destructive, it implies that I remove something that
existed before I opened the dialog. "Nevermind" = "Get me out here and
forget that I opened the dialog" is called "Cancel", not "Delete"! To
actually create the bookmark already before the dialog opens is a
violation of GUI principles ('no changes until OK').
- I have no way to create a folder when I
add a bookmark! That's very essential for bookmark management and this
missing feature alone makes FF3 unusable for me.
- It does not remember the open/close state of the folders. It's annoying enough that I have the tags field there (I'm not going to use it, but I understand why it was added), but why do I have to open the folder twisty *every time* I use the dialog? Every bookmark I file is going to go in a folder, I never add bookmarks at the top level, doing so is an error. It should also remember which folder was open.
- Bookmarks Mangement
- I can't drag and drop a bookmark in a
different folder! How basic a feature is that? I tried and tried and
couldn't believe it's not working. Neither in right nor left pane. Took
me many minutes to grock that I have to click the pseudo-menu / button
Organize|Move...|, then from a dialog select open a folder (potentially
the whole hierarchy) that I already saw in front of me. Again, this
alone makes bookmarks management unusable in FF3.
- Why this More/Less thing in the details
pane? It already has a scrollbar, so there's no need. The scrollbar is
far more intuitive than a "Unhide me, I'm a scary, scary, advanced
feature - like description! - buuuhuuuuu" button.
Please, this whole Places was misdesigned from the start, endangers the user's browser data, is slugglish and slow, has bad UI and misses critical features like folder management and import progress notification. I don't think it will be improved enough for FF3 - this would take many months.
Currently, I feel like I'm better off with FF2, and I don't think this feeling will be any different for FF3 final. This is a serious, noticeable step back, and completely shadows all the other, countless nice improvements (including in the layout engine) that went in FF3. I only feel that FF3 is sluggish, has terribly UI and lost my data several times and will probably do so a few more times.
Ben
Mike Beltzner
There are some good points in here about backwards and forwards compatibility, and lack of progress UI for large import implications. However, they're overshadowed by a lot of FUD, and removing the Places infrastructure at this point in the release cycle is an absolute non-starter.
Your points about the new Add Bookmark panel element are well taken, and also known. We're going to be modifying that dialog in ways that should address almost all of those concerns. The infrastructure is there, it's just some XUL hacking that needs to be done.
The thing I'm most concerned about is speed, and to ensure that your claims are valid, I'd encourage you to sanitize and link to some large bookmark files so that we can make sure we're running tests with real-world cases. We've been working hard for the past 4 months on improving the speed in importing, exporting, and cleaning, and from what I've been seeing in the bugs, we're making pretty signifiant improvements.
cheers,
mike
----- "Ben Bucksch" <ben.buck...@beonex.com> wrote:
> Sorry for the flame, but....
>
> The places bookmarks management is still not ready for general use. I
> am
> shocked about the state it is in.
>
> Problems:
>
> * Migration from bookmarks.html
> o Keep stable
> + bookmarks.html is a common, well-known format
> that's
> supported by many third-party apps, both read and
> write. All non-Firefox apps which want to access
> the
> user's bookmarks have to be changed. I don't mean
> spyware, but other browsers (Konqueror, Epiphany,
> ...), enterprise migration tools, desktop search /
> datawarehouse / research apps,
> user-written backup scripts/rules.
> + It wasn't a bad format. It's not binary, but most
> content (url, title) is text anyways.
> + A neat feature was that I could load bookmarks.html
> directly into any browser and use my bookmarks like
> that, as a fallback.
> + Why something as fragile as a relational database?
> What if the database schema needs to change for
> history, bookmarks, new feature ABC,
> speed-improvement
> D? Breaks compatibility again. The situation here
> is
> *not* comparable with a enterprise database, where
> there is only a single instance, and it's operated
> by
> tons of admins and developers and the point of
> migration is scheduled by managers. A completely
> different situation from user files.
> + Essentially, user data is the by far most valuable
> resource on the computer, 100 times more expensive
> than the CPU or disk, so it is extremely important
> to
> keep it reliable, stable, accessible to the user.
> "To
> the user" means not just this particular
> application
> in this version, compare Microsoft Word documents.
> + The bookmarks are the *only* important user data for
> a
> browser. Is it so hard to keep it stable? We
> managed
> to keep it stable from Netscape (1?, 2? 3?) 4 to
> 2007,
> so why do we need to change it now?
> o Not forward-/backward compatible
> + I in fact somehow lost a big deal of bookmarks by
> switching between Firefox 2 and 3. I had to recover
> an
> old, manual backup of my bookmarks.html and start
> from
> there
> + If user switched from Firefox 3 back to 2, the new
> bookmarks will not be there. If he adds bookmarks
> in
> FF2 and later goes to FF3, will the new
> bookmark.html
> be re-imported? Merged?
> o Are you going to stick with sqlite forerver?
> o Proposal:
> + Keep bookmarks.html as master storage
> + Use a copy in sqlite, or something similar in RAM,
> to
> make quick queries on.
> * Slow
> o The idea to switch to sqlite was to be faster, I guess.
> In
> effect, it's noticably slower.
> o On first start, takes *minutes* to import my bookmarks
> (10000 or so). No UI *at all*, no hint at what it's
> doing,
> not even any window up, just 100% CPU in background.
> o The day-to-day UI is extremely sluggish
> * Bad UI in Add bookmark
> o Why not a modal dialog? This is a *classic* case for it.
> I
> edited a web form, accidently hit Ctrl-D instead of
> Ctrl-C,
> and wondered why nothing in the form changes, until I
> noticed the bookmarks "dialog" in the upper right and
> took
> my input.
> o Clicked "Done" to get the dialog away. Later I wondered
> about a strange bookmark on the top level. I should have
> clicked "Delete" to Cancel the dialog. How unintuitive is
> that? Delete sounds destructive, it implies that I remove
> something that existed before I opened the dialog.
> "Nevermind" = "Get me out here and forget that I opened
> the
> dialog" is called "Cancel", not "Delete"! To actually
> create
> the bookmark already before the dialog opens is a
> violation
> of GUI principles ('no changes until OK').
> o I have no way to create a folder when I add a bookmark!
> That's very essential for bookmark management and this
> missing feature alone makes FF3 unusable for me.
> o It does not remember the open/close state of the folders.
> It's annoying enough that I have the tags field there
> (I'm
> not going to use it, but I understand why it was added),
> but
> why do I have to open the folder twisty *every time* I
> use
> the dialog? Every bookmark I file is going to go in a
> folder, I never add bookmarks at the top level, doing so
> is
> an error. It should also remember which folder was open.
> * Bookmarks Mangement
> o I can't drag and drop a bookmark in a different folder!
> How
> basic a feature is that? I tried and tried and couldn't
> believe it's not working. Neither in right nor left pane.
> Took me many minutes to grock that I have to click the
> pseudo-menu / button Organize|Move...|, then from a
> dialog
> select open a folder (potentially the whole hierarchy)
> that
> I already saw in front of me. Again, this alone makes
> bookmarks management unusable in FF3.
> o Why this More/Less thing in the details pane? It already
> has
> a scrollbar, so there's no need. The scrollbar is far
> more
> intuitive than a "Unhide me, I'm a scary, scary, advanced
> feature - like description! - buuuhuuuuu" button.
>
>
> Please, this whole Places was misdesigned from the start, endangers
> the
> user's browser data, is slugglish and slow, has bad UI and misses
> critical features like folder management and import progress
> notification. I don't think it will be improved enough for FF3 - this
> would take many months.
>
> Currently, I feel like I'm better off with FF2, and I don't think
> this
> feeling will be any different for FF3 final. This is a serious,
> noticeable step back, and completely shadows all the other, countless
> nice improvements (including in the layout engine) that went in FF3.
> I
> only feel that FF3 is sluggish, has terribly UI and lost my data
> several
> times and will probably do so a few more times.
>
> Ben
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Mike Beltzner
Dietrich Ayala
> Sorry for the flame, but....
Constructive criticisms are not flames. However, given that Places has
been in development for a year and has been in 6 public releases, and
you've never joined in any facet of development, nor community
conversation until now, it's difficult to see this as otherwise. That
said, thanks for input. I'll always take criticism if it'll improve
the product :)
>
> The places bookmarks management is still not ready for general use. I am
> shocked about the state it is in.
>
> Problems:
>
> * Migration from bookmarks.html
> o Keep stable
> + bookmarks.html is a common, well-known format that's
> supported by many third-party apps, both read and
> write. All non-Firefox apps which want to access the
> user's bookmarks have to be changed. I don't mean
> spyware, but other browsers (Konqueror, Epiphany,
> ...), enterprise migration tools, desktop search /
> datawarehouse / research apps,
> user-written backup scripts/rules.
1. Bookmarks.html is still available in your profile directory. It's
currently written to disk at shutdown. In the future we might not do
that by default, but in that case there will certainly be a pref to
allow the old behavior to continue. Also, you can still manually
export and import bookmarks.html.
2. In the last 8 months that Places has been driving bookmarks, we
haven't yet heard complaints from any of these 3rd party apps.
However, I've consistently heard that using SQL and the new Places
APIs is easier and more intuitive than RDF and having to parse HTML.
We're in #places every day, available via email and all the usual
channels if any 3rd party consumers want help migrating!
> + It wasn't a bad format. It's not binary, but most
> content (url, title) is text anyways.
> + A neat feature was that I could load bookmarks.html
> directly into any browser and use my bookmarks like
> that, as a fallback.
The benefits of using it extend to those you've enumerated:
1. We already using it
2. It's neat to view it in your browser
The downsides of using this format outweigh those upsides.
1. Wrong tool for the job: HTML was not designed to be a
high-performance data storage container. We want users to be able
store large quantities of information, along with internally used
metadata, along with extension-driven metadata. The performance of
HTML import falls far short of SQL's in it's ability to parse and
ready this information in a reasonable amount of time.
2. Difficult to parse: I know "it's just HTML", but have you looked at
our serialization? It's awful. Unclosed tags, and favicons shoved into
attributes.
3. We're bolting this already-crazy mixed metaphor of "bookmark inside
a folder" on top of publishing-oriented markup. If using a markup
language as the canonical storage format for this data, it should at
least be a domain-specific XML vocabulary like XBEL or something
similar.
4. Not extensible: Even if we did choose XBEL as the "native format",
what if we then wanted to add more features outside of it's scope?
We'd end up with ad-hoc extensions to the format and even more
franken-markup nonsense. I far prefer using SQL as a general purpose
storage mechanism, and serializing to domain-specific markup formats
as needed.
> + Why something as fragile as a relational database?
> What if the database schema needs to change for
> history, bookmarks, new feature ABC, speed-improvement
> D? Breaks compatibility again. The situation here is
> *not* comparable with a enterprise database, where
> there is only a single instance, and it's operated by
> tons of admins and developers and the point of
> migration is scheduled by managers. A completely
> different situation from user files.
This is not a bookmark-specific argument. Bookmarks, history, tags,
phishing data, cookies, downloads, content preferences, form history,
and offline app data are all stored in SQLite databases in Fx3.
I don't agree that the ideal scenario for application integration is
that all interested parties should read directly from each other's
internal datastores, and subject to each other's implementation
details. I would rather move to model of standardized interfaces
exposed via communication mechanisms such IPC, DBUS, HTTP, or whatever
native domain-specific tools are available for the OS for the need.
> + Essentially, user data is the by far most valuable
> resource on the computer, 100 times more expensive
> than the CPU or disk, so it is extremely important to
> keep it reliable, stable, accessible to the user. "To
> the user" means not just this particular application
> in this version, compare Microsoft Word documents.
Do you watch the Bugzilla component for bookmarks? The "Firefox lost
my bookmarks" bug is one of the most-reported long-standing bugs in
Firefox 2 and earlier. This was one of the biggest factors in the
choice of SQLite for this purpose (and likely this extends beyond
Places): It is far more robust in problematic conditions, with regards
to dataloss.
> + The bookmarks are the *only* important user data for a
> browser. Is it so hard to keep it stable? We managed
> to keep it stable from Netscape (1?, 2? 3?) 4 to 2007,
> so why do we need to change it now?
See above for why bookmarks.html on disk is not stable (in either the
dataloss or 3rd party integration sense).
> o Not forward-/backward compatible
> + I in fact somehow lost a big deal of bookmarks by
> switching between Firefox 2 and 3. I had to recover an
> old, manual backup of my bookmarks.html and start from
> there
I have not seen any "firefox lost some of my bookmarks when migrating"
bugs yet, so it'd be great to follow up with you on this. Feel free to
file a bug and CC me, or just mail me directly with your STR.
> + If user switched from Firefox 3 back to 2, the new
> bookmarks will not be there. If he adds bookmarks in
> FF2 and later goes to FF3, will the new bookmark.html
> be re-imported? Merged?
We do have a bug open for detecting changes in bookmarks.html, and
automatically merging in that case.
> o Are you going to stick with sqlite forerver?
Of course not! Once the Mayan calendar ends in 2012, and humankind
experiences the ultimate harmonic convergence, we'll likely switch to
holographic cartoon wormholing as the canonical storage format, as
that is the native tongue of our self-transforming machine elf
overlords.
Seriously though, we don't have plans to change. If it becomes overly
problematic, we will of course explore other options. I hope you will
join us in doing so :)
> o Proposal:
> + Keep bookmarks.html as master storage
> + Use a copy in sqlite, or something similar in RAM, to
> make quick queries on.
> * Slow
> o The idea to switch to sqlite was to be faster, I guess. In
> effect, it's noticably slower.
That was one of the benefits. However, lets make clear the distinction
between SQLite and Places. If there's a poorly performing query in
Places, it does not mean "SQLite is BAD!!".
I've heard (and experienced) that in some areas Places is much faster,
and others much slower. History is far faster for some queries, slower
for others. But the range and richness of the queries are by far
improved from Fx2. We've done a lot of work on performance for Beta 3,
and that work is ongoing. Please file bugs for specific bottlenecks
you encounter. If possible, it'd be great to get a cleaned version of
your bookmarks.html file that we can test with.
> o On first start, takes *minutes* to import my bookmarks
> (10000 or so). No UI *at all*, no hint at what it's doing,
> not even any window up, just 100% CPU in background.
Can you please provide your build id and system specs? Is this initial
migration you're talking about? or manual import? or regular startup?
We have relevant bugs for:
- improving transactional speed
- show a progress window when importing
> o The day-to-day UI is extremely sluggish
Can you please be more specific? Opening the bookmarks menu, or
sidebar? Clicking on the toolbar? Adding a bookmark?
> * Bad UI in Add bookmark
> o Why not a modal dialog? This is a *classic* case for it. I
> edited a web form, accidently hit Ctrl-D instead of Ctrl-C,
> and wondered why nothing in the form changes, until I
> noticed the bookmarks "dialog" in the upper right and took
> my input.
> o Clicked "Done" to get the dialog away. Later I wondered
> about a strange bookmark on the top level. I should have
> clicked "Delete" to Cancel the dialog. How unintuitive is
> that? Delete sounds destructive, it implies that I remove
> something that existed before I opened the dialog.
> "Nevermind" = "Get me out here and forget that I opened the
> dialog" is called "Cancel", not "Delete"! To actually create
> the bookmark already before the dialog opens is a violation
> of GUI principles ('no changes until OK').
Here's the bug Alex is using for the design of this dialog:
https://bugzilla.mozilla.org/show_bug.cgi?id=393509
The instant apply approach is very problematic for some users and
use-cases. IIRC, Alex mentioned that he had new mockups coming up that
resolve some of these issues. That bug is the one to watch for
updates.
> o I have no way to create a folder when I add a bookmark!
> That's very essential for bookmark management and this
> missing feature alone makes FF3 unusable for me.
> o It does not remember the open/close state of the folders.
> It's annoying enough that I have the tags field there (I'm
> not going to use it, but I understand why it was added), but
> why do I have to open the folder twisty *every time* I use
> the dialog? Every bookmark I file is going to go in a
> folder, I never add bookmarks at the top level, doing so is
> an error. It should also remember which folder was open
> * Bookmarks Mangement
> o I can't drag and drop a bookmark in a different folder! How
> basic a feature is that? I tried and tried and couldn't
> believe it's not working. Neither in right nor left pane.
> Took me many minutes to grock that I have to click the
> pseudo-menu / button Organize|Move...|, then from a dialog
> select open a folder (potentially the whole hierarchy) that
> I already saw in front of me. Again, this alone makes
> bookmarks management unusable in FF3.
> o Why this More/Less thing in the details pane? It already has
> a scrollbar, so there's no need. The scrollbar is far more
> intuitive than a "Unhide me, I'm a scary, scary, advanced
> feature - like description! - buuuhuuuuu" button.
>
I believe there are bugs for most, if not all of the issues you've
described. Some are P1 blockers (like the dnd bug), and will be fixed
before shipping. I encourage you to file bugs when you experience
them, so that we can work together to fix them.
>
> Please, this whole Places was misdesigned from the start, endangers the
> user's browser data, is slugglish and slow, has bad UI and misses
> critical features like folder management and import progress
> notification. I don't think it will be improved enough for FF3 - this
> would take many months.
>
> Currently, I feel like I'm better off with FF2, and I don't think this
> feeling will be any different for FF3 final. This is a serious,
> noticeable step back, and completely shadows all the other, countless
> nice improvements (including in the layout engine) that went in FF3. I
> only feel that FF3 is sluggish, has terribly UI and lost my data several
> times and will probably do so a few more times.
I'm sorry you feel that way, and I hope you'll work with us to resolve
these issues. Generally the feedback, in published reviews and from
countless users, is that we've made vast improvements. Yes, replacing
a 10 year-old system with a new one is difficult, and I'll be the
first to say it's not perfect. However, I do feel that with Places and
SQLite, we've built a platform that is more extensible, more
approachable for developers, and provides a better foundation to build
on than the RDF+HTML solution we previously had.
Ben Bucksch
thanks for the calm response. Again, please don't take any of this
personal, it's not.
Dietrich Ayala schrieb:
> Constructive criticisms are not flames. However, given that Places has
> been in development for a year and has been in 6 public releases, and
> you've never joined in any facet of development, nor community
> conversation until now
That's because I've been busy creating a whole commercial application,
TomTom HOME 2.
I looked at Places shortly after it landed on trunk the first time, and
it got backed out pretty quickly.
I thought back then and still think the idea of persistent storage of
user data in a relational database is inherently flawed, for the reasons
given and outlined below. It's impossible to keep it stable enough for
the time periods and given the diverse software that users want to work
with their data.
> That said, thanks for input. I'll always take criticism if it'll improve
> the product :)
>
That's my goal, yes. I'd be happy with parity with FF2 in terms of data
stability, functionality and performance, and it's far from that.
>> o Keep stable
>> + bookmarks.html is a common, well-known format that's
>> supported by many third-party apps, both read and
>> write. All non-Firefox apps which want to access the
>> user's bookmarks have to be changed. I don't mean
>> spyware, but other browsers (Konqueror, Epiphany,
>> ...), enterprise migration tools, desktop search /
>> datawarehouse / research apps,
>> user-written backup scripts/rules.
>>
>
> 1. Bookmarks.html is still available in your profile directory. It's
> currently written to disk at shutdown.
OK, that's great news! I hadn't noticed that, sorry.
(IMHO, it should be written whenever I add a bookmark, like in FF2.)
Reading bookmarks.html is mentioned below.
> In the future we might not do that by default
Please don't. I hope I gave and give enough theoretical base to support
that it's critically important to always keep that enabled.
At least until we have an even more stable format, e.g. based on XML and
maybe agreed-upon with other browser vendors, that would be ideal.
> but in that case there will certainly be a pref to allow the old behavior to continue. Also, you can still manually export and import bookmarks.html.
>
None of that fulfulls the requirements. A third-party tool cannot enable
the pref (it would have to enable it, shut down firefox, potentially
while the user is working, start firefox, shut down firefox again).
"Export bookmarks.html" is a manual user action which a) I am too lazy
for and b) a third-party tool cannot do automatically (unless it's a
firefox extension, which it often is not).
> 2. In the last 8 months that Places has been driving bookmarks, we
> haven't yet heard complaints from any of these 3rd party apps.
>
Well, I think a lot of them will just break, see below.
> However, I've consistently heard that using SQL and the new Places
> APIs is easier and more intuitive than RDF and having to parse HTML.
>
I don't know which apps you mean when you say Places API, but I mean
non-XUL apps and tools like MSIE->Firefox migration tool, the Opera,
Konqueror etc. bookmarks import, or search / personal information apps
like Google Desktop.
That said, sure, HTML was not the ideal format. I'm all for a new,
stable format. I just do not believe that the current on-disk
representation a) is easy to read and b) can be kept stable for the next
10-20 years. Any DB schema changes which would affect the SQL statements
you'd use to get all the information out are a file format change which
break things *again*.
That's why relational databases are fundamentally unsuited for data
storage of important personal data.
> 1. Wrong tool for the job: HTML was not designed to be a
> high-performance data storage container.
Sure. But you don't have to do full-blown HTML parsing, just what's used
here. In the end, it's just a text file with certain tagging and
escaping rules which are not terribly complex.
Most of the content is text anyways, so the textual container is not
that bad, esp. if you read it only on startup.
FWIW, my bookmarks file is about 2 MB large with 6000 bookmarks in 1000
folders, and FF2 starts in 2-3 seconds from 0 (not running) to 100
(browser window up), including reading the bookmarks.html. So, it can't
be that bad. FF3 takes *longer*, IIRC.
> 2. Difficult to parse: I know "it's just HTML", but have you looked at
> our serialization? It's awful. Unclosed tags, and favicons shoved into
> attributes.
>
Yes, I have IIRC in fact fixed a bug in the write and read functions,
where some smartie forgot about escaping <>&.
But that's not the fault of the format, for sure.
> This is not a bookmark-specific argument. Bookmarks, history, tags,
> phishing data, cookies, downloads, content preferences, form history,
> and offline app data are all stored in SQLite databases in Fx3.
>
It is, because bookmarks are all that the user cares about, after a week.
And passwords, yes.
> I don't agree that the ideal scenario for application integration is
> that all interested parties should read directly from each other's
> internal datastores, and subject to each other's implementation
> details. I would rather move to model of standardized interfaces
> exposed via communication mechanisms such IPC, DBUS, HTTP, or whatever
> native domain-specific tools are available for the OS for the need.
>
I disagree here. You then need the application code running, which is
often impossible. An IPC mechnism is fine and useful while the app is
running, but important data must always be readable without the app.
What when I switch from Windows with Firefox to Linux with Epiphani?
Firefox is not even installed. Should Epiphani not be able to import my
bookmarks?
What about backups? I find an old bookmarks collection from 10 years
ago, and I want to see what I was doing and thinking back then. Firefox
may not even exist anymore, or I am using a different browser now, and
even if it does, surely there were so many changes that it now uses a
completely different format. How can I read them?
Important user data exists in a different sphere than applications. Left
data, right apps. Apps read and modify data, but data exists on its own.
If the data format that changes with app versions, this does not work.
And sqlite is such a format.
> The "Firefox lost my bookmarks" bug is one of the most-reported long-standing bugs in
> Firefox 2 and earlier. This was one of the biggest factors in the
> choice of SQLite for this purpose (and likely this extends beyond
> Places): It is far more robust in problematic conditions, with regards
> to dataloss.
>
Understood. (That was a really simple handling of parsing errors, though.)
I did lose several months of bookmarks due to the FF2<->Places
migration, though. I don't know the exact circumstances.
I could imagine that the following happened:
1. Use FF3 with Places once, e.g. a year ago. Drop FF3 because of
Places. Have sqlite database in profile.
2. Switch back to FF2. Use it for a year.
3. Try out FF3 again. It does not read bookmarks.html, but uses the
(old) sqlite database, and writes its contents to bookmarks.html
on shutdown.
4. Boom, all bookmark changes from the last year lost, unless there's
a backup.
5. I happened not to have a backup, because I noticed too late, so
the backup was overwritten.
Now, this should not surprise any programmer (but surely a user). I can
only hope that you considered and guarded against scenarios like this.
>> + If user switched from Firefox 3 back to 2, the new
>> bookmarks will not be there. If he adds bookmarks in
>> FF2 and later goes to FF3, will the new bookmark.html
>> be re-imported? Merged?
>>
>
> We do have a bug open for detecting changes in bookmarks.html, and
> automatically merging in that case.
>
But it is not yet implemented? Do you plan to do so for FF3.0?
The lack of this could well have been the reason why I lost a few
thousand bookmarks as described above.
> distinction between SQLite and Places. If there's a poorly performing query in
> Places, it does not mean "SQLite is BAD!!".
>
Agreed :).
> Please file bugs for specific bottlenecks you encounter. If possible, it'd be great to get a cleaned version of your bookmarks.html file that we can test with.
>
For both, see response to Mike.
> Can you please provide your build id and system specs?
Gecko/2008010504 Minefield/3.0b3pre
Athlon 3500+
4 GB fast RAM
> Is this initial migration you're talking about?
Yes.
> We have relevant bugs for:
> - improving transactional speed
> - show a progress window when importing
>
I'm sure you have bugs for everything, the question is whether they'll
be fixed. No, I don't volunteer. :-)
>> o The day-to-day UI is extremely sluggish
>>
> Can you please be more specific? Opening the bookmarks menu, or
> sidebar? Clicking on the toolbar? Adding a bookmark?
>
- Autocomplete (see below)
- Opening of Add bookmark dialog, and closing it, including cancel
(covered in initial post)
Autocomplete:
Esp. the fact that for the *first* typed character in the location bar,
search results are already built and displayed makes the whole browser
feel sluggish, because I can type 3 characters like "tvi" faster than
Mozilla can build the list for the first and display it. I tried it
several times, and in fact this particular detail causes noticable
slowdown for autocomplete. I would suggest giving the first 2 characters
a delay of 100ms before they trigger a search. "www." does not count,
i.e. "www.i" counts as 1 character. "www.ial" or "ial" would have no
delay and immediately trigger the search. It should also be aborted
(including attempt to draw) when a new character is typed - this does
not seem to happen either, when I type "tvi" and wait, it shortly
displays results for "t", just to immediately replace them with results
for "tv" and "tvi".
>> * Bad UI in Add bookmark
>>
> Here's the bug Alex is using for the design of this dialog:
> https://bugzilla.mozilla.org/show_bug.cgi?id=393509
> The instant apply approach is very problematic for some users and
> use-cases.
Thanks for the reference.
> I believe there are bugs for most, if not all of the issues you've
> described. Some are P1 blockers (like the dnd bug), and will be fixed
> before shipping.
>
Thanks, but "there is a bug open" does not mean all that much, as we all
know. The point of this point was to give a high-level idea of the
impression the whole system makes, and the concrete reasons. I hope that
all of these will be fixed before FF3. For me, all of these are hard
shop-ship bugs - FF3 can't ship with them, it's simply not usable and
will be highly embarrassing. Frankly, I think FF3 may the first release
were we get flagged for its quality.
> I'm sorry you feel that way, and I hope you'll work with us to resolve
> these issues. Generally the feedback, in published reviews and from
> countless users, is that we've made vast improvements.
People who saw the first versions of Places will of course be thrilled,
so will enthusiasts. The shock for me coming from FF2 was large, though.
> Yes, replacing a 10 year-old system with a new one is difficult, and I'll be the
> first to say it's not perfect. However, I do feel that with Places and
> SQLite, we've built a platform that is more extensible, more
> approachable for developers, and provides a better foundation to build
> on than the RDF+HTML solution we previously had.
All that is good, but means nothing for users. You're in beta stage,
you're about to release to 50 million users, and they don't care about
extensible, they care about whether their bookmarks are safe, whether
they can use them in Safari and whether it works smoothly.
I'm glad to hear that you want to improve it still. I just want to make
sure the important areas mentioned actually do get fixed properly before
FF3.0 release.
Thanks,
Ben
--
When responding via mail, please remove the ".news" from the email address.
Ben Bucksch
thanks for the rational response.
I already generated a large bookmarks file back in 1999 or so for the
first bookmarks implementation:
http://www.mozilla.org/quality/browser/front-end/testcases/bookmarks/hugebookmarks.html
Most of the problems could be resolved without ripping out Places
altogether, but with a few rather brave changes which undo some design
choices taken:
* Continue to use bookmarks.html as primary storage and source. Read
that in on startup and build a searchable DB in RAM only
(preferred), or write (additionally) to sqlite DB on disk, but use
it only for search. Any added bookmark should be immediately added
to bookmarks.html like it was in FF2, and outside changes to
bookmarks.html should be picked up at startup. The sqlite database
should be deletable without effects apart from having to rebuild
the DB, no important information loss in bookmarks.
* Make Add bookmarks a normal modal dialog again, and remember
open/close state of folder UI
* Implement drag&drop for Bookmarks Manager
* In Autocomplete, do not search for 1 or 2 characters, and not for
"www". See response to Dietrich.
Re your second post: While Places may have many advantages in theory,
which surely were the reason to do it in the first place, all I can see
right now is a bookmarks management that is so much inferiour to FF2
that it's barely usable. I think the reasons were clear enough: No way
to properly file bookmarks in folders, and serious huge data loss once
(I lost many months of bookmarks = thousands of bookmarks).
Ben Bucksch
>> 1. Bookmarks.html is still available in your profile directory. It's
>> currently written to disk at shutdown.
>>
>
> OK, that's great news! I hadn't noticed that, sorry.
>
I just checked, and that's not the case for me.
I also notice that shutdown of FF3 takes *ages*, specifically 48
seconds, with 60-100% CPU. FF2 needs a fraction of a second for
shutdown. FF2 startup: 2s. FF3 startup: 1-2s.
Ben
David McRitchie
> Here's the bug Alex is using for the design of this dialog:
> https://bugzilla.mozilla.org/show_bug.cgi?id=393509
Missing of course the ability to create a bookmark folder,
and to select among the most recently used folders.that were
there before, and doesn't include keyword: and description:
and missing "Load this bookmark in the sidebar", and I don't
want to have to use a More key either to see that when adding
or viewing/changing a bookmark's properties. And a Cancel
key so that no change actually takes place, "Delete" means
nothing to me in that box. Also want some kind of indication
as to what would be changed if accepted.
The internal structure converting from bookmarks.html to
SQLITE database for use then converting back to a bookmarks.html
type of file when done may be more efficient internally but the
user interface with bookmarking a file is not good.
The interface provided with the three extensions below is far better, and
with the old version 2 framework you could go to another tab
or elsewhere even to bookmarks, and finish filling in the dialog
later as it doesn't disappear if you blink or hunt for more information.
I can't really point you to decent pictures at addons since the March 2007
massacre at addons.mozilla.com took place. This is what you might
see using OpenBook on my web site, picture shows some modification to
use the %S to allow it to bring up specific file and fragment id. (firefox.htm#fx3)
http://www.mvps.org/dmcritchie/icons/ff_ext_openbook_addbookmark.jpg
actually if modified to include tags automatically from HTML metatag keywords
you would also see: Firefox, setting up, customizing, extensions, problems
and hopefully exactly as shown, no horrible rounded sectional display
of each tag.
OpenBook only thing missing is the Tags, and hopefully if updated,
will automatically extract them from the HTML and subject to editing.
Naturally as some webpage include I imagine 300 tags needs
extensive editing -- rejecting all of them would also be very quick,
before I would use such a bookmark (though with such misuse like
putting in names of 300 towns in a county, I'd probably never
be interested in bookmarking such a site nor hiring such a painter anyway).
https://addons.mozilla.org/firefox/42
Enhanced Bookmarks Search
https://addons.mozilla.org/firefox/494
Locate in Bookmarks
https://addons.mozilla.org/firefox/42
So am disappointed that these extensions in their entirety are not in Firefox 3
and of the divergence from a cleaner layout is becoming worse with less utility
and distractive graphical features with "more" buttons to show what should
always be visible. If the extensions are updated for Firefox 3,
at least no features would be left out, but really wouldn't be able to do
anything in Safe Mode to see what others are suffering with or to help them
get organized.
But I will be happy if each of those extensions at least can and will be updated
without loss of any features before Firefox 3 comes out. Without them
Firefox 3 would be a giant leap backwards.
=== Not too pleased with the Direction of Tags ===
The direction of a list of all of the tags to select from, you've
got to be kidding I would expect 8K to 20K or more word lists
if that were the case, but in reality people are going to try to choose
unique words so maybe only a thousand, I guess you can get an
ideal by looking at del.icio.us and keeping in mind that they are
really only trying to specialize in a few areas per person not also create all
of their bookmarks. Then again loss of bookmarks from going
from one system to another and the emergence of Deja and Google
has made a lot of bookmarking unnecessary, but if you were to
gather all of the keywords from the sites for the bookmarks that
I do have I'm sure that the numbers would astound you.
What is needed for tags and descriptions is the ability to search
with AND and OR and parens and NOT rather than looking at
humongous lists of tags.
== Looking Forward to being able to produce Documentation from Bookmarks ==
Think this will be possible, but not sure. to create essentially what is
in Bookmarks.html exposing any parts of it for a selection (maybe even
with a folder as you might select from bookmarks.html) say
title:, keyword: (not tag), url, description:, date created, favicon
and in any order/format.
BTW, I do not use del-icio.us other than that they show up
in searches.
--
David McRitchie,
Firefox Custom: http://www.mvps.org/dmcritchie/firefox/firefox.htm
Michael Lefevre
> Dietrich Ayala schrieb:
>> 1. Bookmarks.html is still available in your profile directory. It's
>> currently written to disk at shutdown.
>> In the future we might not do that by default but in that case there
>> will certainly be a pref to allow the old behavior to continue. Also,
>> you can still manually export and import bookmarks.html.
>
> None of that fulfulls the requirements. A third-party tool cannot enable
> the pref (it would have to enable it, shut down firefox, potentially
> while the user is working, start firefox, shut down firefox again).
> "Export bookmarks.html" is a manual user action which a) I am too lazy
> for and b) a third-party tool cannot do automatically (unless it's a
> firefox extension, which it often is not).
I don't disagree with your point, but the situation is the same with IE.
Various third party tools I've used handle IE import by giving the user
instructions on how to export their bookmarks to an HTML file, and then
reading that file. It's clunky, but it works (I'm not saying "clunky, but
it works" is a good standard to aim for with FF3, of course...)
Michael
David McRitchie
news:slrnfomh8a.ba8...@msgid.michaellefevre.com...
As I understand it that part is taken care of, though I haven't checked it out
to verify contents of files, there is bookmarks.html that may or may not be
updated based on a configuration variable and there is bookmarks.postplaces.html
which is updated upon close, so if the bookmarks.html file is updated then
there should be no problem.
"Bug 381216 - prevent bookmarks dataloss when a user goes from Firefox 2, Firefox 3 beta, Firefox 2, and then back to Firefox 3
[was: After initial import, minefield with bookmarks-on-places throws out Firefox 2 bookmarks changes]"
Marked as Verified Fixed. -- but it has Bug 406114 as details and the fix which is marked assigned
https://bugzilla.mozilla.org/show_bug.cgi?id=381216
Bug 406114 - when automatically importing from bookmarks html format, use bookmarks.postplaces.html, if it exists
Marked status is Assigned
https://bugzilla.mozilla.org/show_bug.cgi?id=406114
<<note, by default, browser.bookmarks.overwrite is false (as we don't overwrite
fx 2's bookmarks.html. instead we write to bookmarks.postplaces.html)
with browser.bookmarks.overwrite to false (which is the default)>>
Don't know why another file is not created/archived upon initial contact with version 2
file, of course at 1.5MB for the orginal and 2MB for postplaces they will add up
even on a a new system.
Benjamin Smedberg
> None of that fulfulls the requirements. A third-party tool cannot enable
> the pref (it would have to enable it, shut down firefox, potentially
> while the user is working, start firefox, shut down firefox again).
> "Export bookmarks.html" is a manual user action which a) I am too lazy
> for and b) a third-party tool cannot do automatically (unless it's a
> firefox extension, which it often is not).
I do not think that we should be predicating the design of Firefox bookmarks
around third-party tools. Format stability has high costs that I don't think
we should be paying. Third-party tools can use SQLite to access the
bookmarks store; it is an open format. Of course third-party tools will then
be subject to future variations in the sqlite code and our schemas, but
that's no different than the promises we make to extensions.
> It is, because bookmarks are all that the user cares about, after a week.
> And passwords, yes.
This may be true for a subset of users which actually create large bookmark
hierarchies. I know I don't, and never have. The new ability to find pages
just by typing in the urlbar beats any explicit bookmarking to death, for me
at least.
> What when I switch from Windows with Firefox to Linux with Epiphani?
> Firefox is not even installed. Should Epiphani not be able to import my
> bookmarks?
If you are switching from Windows -> Linux explicitly exporting bookmarks is
not a huge burden. Neither is getting Epiphany to write a SQLite-aware importer.
> What about backups? I find an old bookmarks collection from 10 years
> ago, and I want to see what I was doing and thinking back then. Firefox
> may not even exist anymore, or I am using a different browser now, and
> even if it does, surely there were so many changes that it now uses a
> completely different format. How can I read them?
1) Firefox cannot "not continue to exist"... you can certainly run Firefox 3
in a VM to view the data... in a VM, if the world has moved on so much that
it won't run Firefox directly any more.
2) Writing a little XR app to export the data to some other random format is
a relatively trivial exercize: writing a C app that uses SQLite directly is
also pretty simple.
> Autocomplete:
> Esp. the fact that for the *first* typed character in the location bar,
> search results are already built and displayed makes the whole browser
> feel sluggish, because I can type 3 characters like "tvi" faster than
> Mozilla can build the list for the first and display it. I tried it
I definitely agree with BenB here: if there were a way to cancel the urlbar
autocomplete code as soon as a typed a second (or third) character, that
would make the browser much more responsive.
--BDS
Foteos Macrides
> [snip] there is bookmarks.html that may or may not be
> updated based on a configuration variable and there is
> bookmarks.postplaces.html
> which is updated upon close, so if the bookmarks.html file is updated
> then
> there should be no problem.
The profile directory also has a bookmarkbackups sub-directory in which
files of the form bookmarks-date.html are being added every day that the
browser is used, and by virtue of the date field become daily additions in
that sub-directory rather than replacements, so that for those of us with
decades-worth of bookmarks it's progressively sopping up megabytes of disk
space with no apparent end in sight. What is that all about?
Fote
--
David McRitchie
"Benjamin Smedberg" > I definitely agree with BenB here: if there were a way to cancel the urlbar
> would make the browser much more responsive.
If it is anything like FIND that would be the opposite. I find that
with FIND if I don't type the first three characters real fast that
it will take a long time to come back as it searchs for every single
"a" in the HTML documment. Doesn't seem to slow things down
on the search bar ("show search suggestions") as much as I would
expect where it sends each letter you tupe to Google -- though I
turned it off, partly because it doesn sometimes slow down and
because I don't need it there. (must be really bad on dial-up)
Martijn
> > It is, because bookmarks are all that the user cares about, after a week.
> > And passwords, yes.
>
> This may be true for a subset of users which actually create large bookmark
> hierarchies. I know I don't, and never have. The new ability to find pages
> just by typing in the urlbar beats any explicit bookmarking to death, for me
> at least.
Not for me. And I think most users create bookmarks, instead of
relying on the url bar.
Regards,
Martijn
David McRitchie
It's actually only 5 in the folder plus the archive from when that started.
I meant if there is an additional archive everytime something major
is chnaged in Firefox there can become a lot of undocumented large
bookmarks files..
David McRitchie
for the quick bookmarks
interestingly I was bookmarking a Firefox configuration file and the
default was "Humor" but I haven't put anything there for months.
B. Polidoro
> FWIW, my bookmarks file is about 2 MB large with 6000 bookmarks in 1000
> folders, and FF2 starts in 2-3 seconds from 0 (not running) to 100
> (browser window up), including reading the bookmarks.html. So, it can't
> be that bad. FF3 takes *longer*, IIRC.
I don't think you can say Places is the only possible cause for a
slower startup. It may not be any slower than the previous system.
Startup is being investigated in this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=406810
Brian Polidoro
Alex Faaborg
> and also known. We're going to be modifying that dialog in ways that
> should address almost all of those concerns.
A new iteration of the bookmark contextual dialog has been posted to
bug 393509, and is available here:
http://people.mozilla.com/~faaborg/files/granParadisoUI/places_NewBookmarkDialog_i8.png
Changes in this iteration:
-providing better feedback
-supporting undo
-making it clear that this is an instant apply interface with by no
longer
having delete/done that sort of matched to ok/cancel, but not really
-new folder button
-visual tweaks (just one example of the styling, I'll post another
mockup with a bunch of options)
Please feel free to comment in the bug or this thread with feedback,
-Alex
On Jan 13, 2008, at 1:40 PM, Mike Beltzner wrote:
> Hey Ben,
>
> There are some good points in here about backwards and forwards
> compatibility, and lack of progress UI for large import
> implications. However, they're overshadowed by a lot of FUD, and
> removing the Places infrastructure at this point in the release
> cycle is an absolute non-starter.
>
> Your points about the new Add Bookmark panel element are well taken,
> and also known. We're going to be modifying that dialog in ways that
> should address almost all of those concerns. The infrastructure is
> there, it's just some XUL hacking that needs to be done.
>
> The thing I'm most concerned about is speed, and to ensure that your
> claims are valid, I'd encourage you to sanitize and link to some
> large bookmark files so that we can make sure we're running tests
> with real-world cases. We've been working hard for the past 4 months
> on improving the speed in importing, exporting, and cleaning, and
> from what I've been seeing in the bugs, we're making pretty
> signifiant improvements.
>
> cheers,
> mike
> ----- "Ben Bucksch" <ben.buck...@beonex.com> wrote:
>
>> Sorry for the flame, but....
>>
>> The places bookmarks management is still not ready for general use. I
>> am
>> shocked about the state it is in.
>>
>> Problems:
>>
>> * Migration from bookmarks.html
>> o Keep stable
>> + bookmarks.html is a common, well-known format
>> that's
>> supported by many third-party apps, both read and
>> write. All non-Firefox apps which want to access
>> the
>> user's bookmarks have to be changed. I don't mean
>> spyware, but other browsers (Konqueror, Epiphany,
>> ...), enterprise migration tools, desktop search /
>> datawarehouse / research apps,
>> user-written backup scripts/rules.
>> + It wasn't a bad format. It's not binary, but most
>> content (url, title) is text anyways.
>> + A neat feature was that I could load bookmarks.html
>> directly into any browser and use my bookmarks like
>> that, as a fallback.
>> + Why something as fragile as a relational database?
>> What if the database schema needs to change for
>> history, bookmarks, new feature ABC,
>> speed-improvement
>> D? Breaks compatibility again. The situation here
>> is
>> *not* comparable with a enterprise database, where
>> there is only a single instance, and it's operated
>> by
>> tons of admins and developers and the point of
>> migration is scheduled by managers. A completely
>> different situation from user files.
>> + Essentially, user data is the by far most valuable
>> resource on the computer, 100 times more expensive
>> than the CPU or disk, so it is extremely important
>> to
>> keep it reliable, stable, accessible to the user.
>> "To
>> the user" means not just this particular
>> application
>> in this version, compare Microsoft Word documents.
>> + The bookmarks are the *only* important user data for
>> a
>> browser. Is it so hard to keep it stable? We
>> managed
>> to keep it stable from Netscape (1?, 2? 3?) 4 to
>> 2007,
>> so why do we need to change it now?
>> o Not forward-/backward compatible
>> + I in fact somehow lost a big deal of bookmarks by
>> switching between Firefox 2 and 3. I had to recover
>> an
>> old, manual backup of my bookmarks.html and start
>> from
>> there
>> + If user switched from Firefox 3 back to 2, the new
>> bookmarks will not be there. If he adds bookmarks
>> in
>> FF2 and later goes to FF3, will the new
>> bookmark.html
>> be re-imported? Merged?
>> o Are you going to stick with sqlite forerver?
>> o Proposal:
>> + Keep bookmarks.html as master storage
>> + Use a copy in sqlite, or something similar in RAM,
>> to
>> make quick queries on.
>> * Slow
>> o The idea to switch to sqlite was to be faster, I guess.
>> In
>> effect, it's noticably slower.
>> o On first start, takes *minutes* to import my bookmarks
>> (10000 or so). No UI *at all*, no hint at what it's
>> doing,
>> not even any window up, just 100% CPU in background.
>> o The day-to-day UI is extremely sluggish
>> * Bad UI in Add bookmark
>> o Why not a modal dialog? This is a *classic* case for it.
>> I
>> edited a web form, accidently hit Ctrl-D instead of
>> Ctrl-C,
>> and wondered why nothing in the form changes, until I
>> noticed the bookmarks "dialog" in the upper right and
>> took
>> my input.
>> o Clicked "Done" to get the dialog away. Later I wondered
>> about a strange bookmark on the top level. I should have
>> clicked "Delete" to Cancel the dialog. How unintuitive is
>> that? Delete sounds destructive, it implies that I remove
>> something that existed before I opened the dialog.
>> "Nevermind" = "Get me out here and forget that I opened
>> the
>> dialog" is called "Cancel", not "Delete"! To actually
>> create
>> the bookmark already before the dialog opens is a
>> violation
>> of GUI principles ('no changes until OK').
>> o I have no way to create a folder when I add a bookmark!
>> That's very essential for bookmark management and this
>> missing feature alone makes FF3 unusable for me.
>> o It does not remember the open/close state of the folders.
>> It's annoying enough that I have the tags field there
>> (I'm
>> not going to use it, but I understand why it was added),
>> but
>> why do I have to open the folder twisty *every time* I
>> use
>> the dialog? Every bookmark I file is going to go in a
>> folder, I never add bookmarks at the top level, doing so
>> is
>> an error. It should also remember which folder was open.
>> * Bookmarks Mangement
>> o I can't drag and drop a bookmark in a different folder!
>> How
>> basic a feature is that? I tried and tried and couldn't
>> believe it's not working. Neither in right nor left pane.
>> Took me many minutes to grock that I have to click the
>> pseudo-menu / button Organize|Move...|, then from a
>> dialog
>> select open a folder (potentially the whole hierarchy)
>> that
>> I already saw in front of me. Again, this alone makes
>> bookmarks management unusable in FF3.
>> o Why this More/Less thing in the details pane? It already
>> has
>> a scrollbar, so there's no need. The scrollbar is far
>> more
>> intuitive than a "Unhide me, I'm a scary, scary, advanced
>> feature - like description! - buuuhuuuuu" button.
>>
>>
>> Please, this whole Places was misdesigned from the start, endangers
>> the
>> user's browser data, is slugglish and slow, has bad UI and misses
>> critical features like folder management and import progress
>> notification. I don't think it will be improved enough for FF3 - this
>> would take many months.
>>
>> Currently, I feel like I'm better off with FF2, and I don't think
>> this
>> feeling will be any different for FF3 final. This is a serious,
>> noticeable step back, and completely shadows all the other, countless
>> nice improvements (including in the layout engine) that went in FF3.
>> I
>> only feel that FF3 is sluggish, has terribly UI and lost my data
>> several
>> times and will probably do so a few more times.
>>
Ben Bucksch
> A new iteration of the bookmark contextual dialog has been posted to
> bug 393509, and is available here:
>
> http://people.mozilla.com/~faaborg/files/granParadisoUI/places_NewBookmarkDialog_i8.png
>
I find it interesting that you ignore all the concrete UI critizism and
just post your new mockup.
I also find the following sentence there very telling: "Force the user
to learn...".
You are going in the completely wrong direction. You follow the users'
expectations, which are often subconcious / burned in their minds, and
use the common UI patterns to work for you, instead of trying to invent
completely new patterns which go against all long-standing, basic rules
like "no operation until OK" or how a dialog looks like and operates,
and "Force the user to learn" your new patterns.
You have me, somebody who lives in and breathes computers, thoroughly
confused and annoyed with the new UI. I'm sure normal users will be just
as confused, just not know *why*.
Please stick to standard UI patterns. You can achieve most of what you
want to achieve *with* them.
Ben
Ben Bucksch
> I do not think that we should be predicating the design of Firefox
> bookmarks around third-party tools. Format stability has high costs
> that I don't think we should be paying. Third-party tools can use
> SQLite to access the bookmarks store; it is an open format. Of course
> third-party tools will then be subject to future variations in the
> sqlite code and our schemas
... which is exactly what makes it completely unsuited in practice. Not
just for third-party tools, but even for my own use with Firefox, see
the backup scenario I gave in a different post.
>> It is, because bookmarks are all that the user cares about, after a
>> week.
>> And passwords, yes.
>
> This may be true for a subset of users which actually create large
> bookmark hierarchies. I know I don't, and never have. The new ability
> to find pages just by typing in the urlbar beats any explicit
> bookmarking to death, for me at least.
You're saying that there is *no* data in the browser that you'd need
after a week?
You are using bookmarks differently, then. For me, they are an index of
a library of interesting documents. A lot of times, I need the document
a year later. I cannot remember any part of the title or URL. I
typically do find them in my bookmarks folder structure, even years
later, because it's organized logically for me.
That's why the bookmarks collection is so valuable to me. Loosing it is
the equivalent of a book reader losing his whole library due to a fire
or similar.
That's also why stability of the format and access to it is so critical.
> If you are switching from Windows -> Linux explicitly exporting
> bookmarks is not a huge burden.
As said, it means either installing Firefox or rebooting twice. This
*is* a burden.
> Neither is getting Epiphany to write a SQLite-aware importer.
Format changes, see above. Consider that ubuntu releases have 3 year
support, with no upstream feature updates.
>> What about backups? I find an old bookmarks collection from 10 years
>> ago, and I want to see what I was doing and thinking back then. Firefox
>> may not even exist anymore, or I am using a different browser now, and
>> even if it does, surely there were so many changes that it now uses a
>> completely different format. How can I read them?
>
> 1) Firefox cannot "not continue to exist"... you can certainly run
> Firefox 3 in a VM to view the data...
Yes, that's the ultimate nightmare of data recovery. Having to install a
VM, an old operating system, for which I may not even have a license key
(Windows) or disk (Linux) handy, and find the right version of Firefox
(which one?), just to be able to read one file.
Perfect catastrophe.
Alex Faaborg
> and
> just post your new mockup.
I replied to your specific points in the tracking bug for the mockup.
I've also spent a reasonable amount of time justifying the design
decisions I'm making in 6 different lengthy comments in 393509 and
412387 over the past 3 hours. I'm hardly ignoring criticism, and if
anything I'm spending too much time carefully explaining rationale.
> Please stick to standard UI patterns.
This pattern currently appears in Mail.app for To Do items, and in
iCal for appointments. The data detector interface in Mail.app isn't
persistent, but is still reasonable similar. Since I'm a designer at
Mozilla and not Apple, I'm unfortunately not going to be able to
update their documents to include a new chapter on the benefits of
instant apply contextual dialogs.
-Alex
Ben Bucksch
I find it interesting that you ignore all the concrete UI critizism and
just post your new mockup.
I replied to your specific points in the tracking bug for the mockup. I've also spent a reasonable amount of time justifying the design decisions I'm making in 6 different lengthy comments in 393509 and 412387 over the past 3 hours. I'm hardly ignoring criticism, and if anything I'm spending too much time carefully explaining rationale.
This pattern currently appears in Mail.app for To Do items, and in iCal for appointments.
E.g. when I clicked the star, nothing happened. I actually had to go search around, go to Bookmarks Manager and guess at "Unfiled Bookmarks" and look there to know what actually happened and where the bookmark was placed. The new mockup gives feedback about what happened, which is good, but in a dialog (it is a dialog, because it has widgets), and it still doesn't tell me where it went.
Since I'm a designer at Mozilla and not Apple, I'm unfortunately not going to be able to update their documents to include a new chapter on the benefits of instant apply contextual dialogs.
The new UI throroughly confuses us and is against *everything* that people learned about how GUIs work, and you want to go ahead and "update the guideline".
Forcing users to learn that the have to click *outside* the dialog is exactly contrary to what they know about normal dialogs. There, clicking outside either is invalid (modal) or triggers an unrelated action elsewhere (non-modal). Here, you create a third class of dialogs, where clicking outside is the only way to get rid of it. It is not clear whether the click may also trigger an unrelated action (e.g. when clicking on a link in the page) and I have to find a free space or whether it will only close the dialog and only the next click triggers the action. Either way, I have to click, because the dialog is disturbing.
Please, use what people are familiar with from everyday use:
- Use normal dialogs
- When I bookmark something, open a dialog, allowing me - actually *encouraging me* - to change the label/title and picking a folder and/or tag. This is not more clicks that in your proposal - with your proposal, I also have to click to get the flyout dialog away. I just have a smaller, but at least a clear spot to click.
- Only apply the bookmark after OK was clicked. No action at all when "Cancel". Everything else is surprising and left me with unwanted bookmarks that I had to clean up manually via Bookmarks Manager in just a few days. There is also no real advantage in immediately applying it. It also allows to clearly mark the buttons "OK" and "Cancel", which needs no processing in my brain anymore, but "Undo" does, and "Delete" is something else entirely (as discussed in previous posts).
Ben
Ben Bucksch
Either way, I have to click, because the dialog is disturbing.
Please, use what people are familiar with from everyday use:
All this is very simple and has no serious disadvantage over your proposal. It does have the huge advantage of being very familiar and common to users.
- Use normal dialogs
- When I bookmark something, open a dialog, allowing me - actually *encouraging me* - to change the label/title and picking a folder and/or tag. This is not more clicks that in your proposal - with your proposal, I also have to click to get the flyout dialog away. I just have a smaller, but at least a clear spot to click.
- Only apply the bookmark after OK was clicked. No action at all when "Cancel". Everything else is surprising and left me with unwanted bookmarks that I had to clean up manually via Bookmarks Manager in just a few days. There is also no real advantage in immediately applying it. It also allows to clearly mark the buttons "OK" and "Cancel", which needs no processing in my brain anymore, but "Undo" does, and "Delete" is something else entirely (as discussed in previous posts).
- Unfiled Bookmark:
- Your proposal:
- Star (or via menu)
- Click elsewhere
- My proposal:
- Star (or via menu)
- Click OK
- Filed bookmark:
- Your proposal:
- Star (or via menu)
- Edit...
- Type to change title, or select folder
- ? (Click elsewhere? Does it apply every keypress to disk?)
- My proposal:
- Star (or via menu)
- Type to change title, or select folder
- Click OK
In *all* cases, the action is not clear in your proposal, but it's clear with standard dialogs. E.g.
- I don't know how to close the dialog
- I don't know whether and when my title changes are applies when I just click outside the dialog.
- I don't know that Cancel keyboard key = Undo (and I have to check with Manage Bookmarks that it's the case)
- I don't know what "Remove Bookmark" does when I already have the page bookmarked elsewhere in a different folder for some reason.
Nikitas Liogkas
what it's worth, I think Places is an excellent idea; it's about time
someone built a better history/bookmarks revisitation system. Migrating
to SQLite is a good idea too; the previous Mork format was horrendous.
I think Firefox is a great browser, albeit with much space for
improvement. For Firefox 3 though, just speed up address Autocomplete
and you will be fine. This specific feature is on the critical path of
every user, so it's important to make it fast. I should know...
Thanks,
nikitas
> * Use normal dialogs
> * When I bookmark something, open a dialog, allowing me - actually
> *encouraging me* - to change the label/title and picking a folder
> and/or tag. This is not more clicks that in your proposal - with
> your proposal, I also have to click to get the flyout dialog away.
> I just have a smaller, but at least a clear spot to click.
> * Only apply the bookmark after OK was clicked. No action at all
Thomas Stache
>
> Please stick to standard UI patterns. You can achieve most of what you
> want to achieve *with* them.
>
I think we heard your point loud and clear, but still I want to express
that I don't agree with it. There are more long-time computer users
here, and not everyone is against progress in UI patterns as you are.
I'm not for one.
Firefox is the window to the web, and the modern web [1] - with ajaxy
sites like Flickr, Gmail - gives precedent to many of these interactions
Alex wants to bring to the desktop application world now.
At this time and during the lifetime of Firefox 3 more and more users of
the Firefox will be exposed and get used to these new interactions
throughout the everyday web, so there's no point in ramming our heels in
the ground. We had menus/toolbars/dialogs for 25 years, and are familiar
with them. But these elements are not, and should not be, written in
stone prohibiting progress and/or exploration.
Robert Kaiser
> Migrating
> to SQLite is a good idea too; the previous Mork format was horrendous.
Bookmarks were never in Mork, they were in HTML. History was using Mork.
Robert Kaiser
Peter Weilbacher
> I think we heard your point loud and clear, but still I want to express
> that I don't agree with it. There are more long-time computer users
> here, and not everyone is against progress in UI patterns as you are.
> I'm not for one.
>
> Firefox is the window to the web, and the modern web [1] - with ajaxy
> sites like Flickr, Gmail - gives precedent to many of these interactions
> Alex wants to bring to the desktop application world now.
>
> At this time and during the lifetime of Firefox 3 more and more users of
> the Firefox will be exposed and get used to these new interactions
> throughout the everyday web, so there's no point in ramming our heels in
> the ground. We had menus/toolbars/dialogs for 25 years, and are familiar
> with them. But these elements are not, and should not be, written in
> stone prohibiting progress and/or exploration.
But how the UI works isn't and shouldn't defined by an app and certainly
not some websites that a large part of the user base never visits (the ones
you mention are certainly US centered). Instead it is defined by the system
the app runs on. You should definitely not try to bring click-outside-to-
close to Linux and Windows because (apparently only one?) app on MacOSX
and some webpages do it that way.
Peter.
P.S.: Am I happy that I am still using SeaMonkey where the UI still works
the way it should.
Martijn
Yeah, I agree with this 100%. It's really strange seeing these MacOSX
type dialogs here on windows.
Regards,
Martijn
Martijn
> Mozilla and not Apple, I'm unfortunately not going to be able to
> update their documents to include a new chapter on the benefits of
> instant apply contextual dialogs.
Are those Mac applications?
I hope you're not trying to fit Mac UI patterns into Windows, I don't
think that works out well.
Regards,
Martijn
> -Alex
>
>
> On Jan 14, 2008, at 8:32 PM, Ben Bucksch wrote:
>
> > _______________________________________________
> > dev-apps-firefox mailing list
> > dev-apps...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-apps-firefox
>
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
--
Martijn Wargers - Help Mozilla!
http://weblogs.mozillazine.org/qa/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Benjamin Smedberg
> You're saying that there is *no* data in the browser that you'd need
> after a week?
Who said anything about a week? We now save history for... 90 days by
default, it seems. If there is a document I might need after 90 days, I
might remember to star it; otherwise I really don't care.
Note that I'm not trying to minimize your usage of bookmarks, with deep
hierarchies and many thousands of bookmarks; it's important to get that
use-case right. I just don't think it's the common case that we ought to
optimize for by default.
> That's also why stability of the format and access to it is so critical.
"My data is important" and "stability of format and external access" are not
the same thing, and I don't think it helps matters to conflate them.
>> If you are switching from Windows -> Linux explicitly exporting
>> bookmarks is not a huge burden.
>
> As said, it means either installing Firefox or rebooting twice. This
> *is* a burden.
>
>> Neither is getting Epiphany to write a SQLite-aware importer.
>
> Format changes, see above. Consider that ubuntu releases have 3 year
> support, with no upstream feature updates.
Are you saying that it is a blocker feature for older versions of Epiphany
that aren't aware of Firefox 3 to still be able to import Firefox 3
bookmarks? I think that's a ridiculous burden to place on Firefox
development. The fact that we have an "export" feature which enables
backwards-compatible import is already enough.
>>> What about backups? I find an old bookmarks collection from 10 years
>>> ago, and I want to see what I was doing and thinking back then. Firefox
>>> may not even exist anymore, or I am using a different browser now, and
>>> even if it does, surely there were so many changes that it now uses a
>>> completely different format. How can I read them?
>>
>> 1) Firefox cannot "not continue to exist"... you can certainly run
>> Firefox 3 in a VM to view the data...
>
> Yes, that's the ultimate nightmare of data recovery. Having to install a
> VM, an old operating system, for which I may not even have a license key
> (Windows) or disk (Linux) handy, and find the right version of Firefox
> (which one?), just to be able to read one file.
>
> Perfect catastrophe.
Oh, come on. If the data is important enough to you that you might want to
see what you bookmarked 10 years ago, then export the data to a stable
format and save it on a CD. Or write/install an extension which will do that
for you automatically. That's not the common use-case that we ought to
optimize development efforts around.
--BDS
Martijn
> Ben Bucksch wrote:
>
> > You're saying that there is *no* data in the browser that you'd need
> > after a week?
>
> Who said anything about a week? We now save history for... 90 days by
> default, it seems. If there is a document I might need after 90 days, I
> might remember to star it; otherwise I really don't care.
>
> Note that I'm not trying to minimize your usage of bookmarks, with deep
> hierarchies and many thousands of bookmarks; it's important to get that
> use-case right. I just don't think it's the common case that we ought to
> optimize for by default.
Well, I do think that is actually the common case.
Regards,
Martijn
Simon Paquet
>> Note that I'm not trying to minimize your usage of bookmarks, with
>> deep hierarchies and many thousands of bookmarks; it's important
>> to get that use-case right. I just don't think it's the common case
>> that we ought to optimize for by default.
>
> Well, I do think that is actually the common case.
Can you qualify this assertion in any way? I can only speak for myself
here, but I have perhaps 10-15 bookmarks in my FF2 installation. For the
rest I rely mostly on urlbar autocompletion.
Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Martijn
> Martijn wrote on 15. Jan 2008:
>
> >> Note that I'm not trying to minimize your usage of bookmarks, with
> >> deep hierarchies and many thousands of bookmarks; it's important
> >> to get that use-case right. I just don't think it's the common case
> >> that we ought to optimize for by default.
> >
> > Well, I do think that is actually the common case.
>
> Can you qualify this assertion in any way? I can only speak for myself
> here, but I have perhaps 10-15 bookmarks in my FF2 installation. For the
> rest I rely mostly on urlbar autocompletion.
Why would one have to type something in the url bar, when you can just
bookmark the link and click on it?
Much more convenient, because you don't have to leave the mouse.
Regards,
Martijn
> Simon
>
> --
> Calendar l10n coordinator
> Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
> Calendar developer blog: http://weblogs.mozillazine.org/calendar
>
Benjamin Smedberg
> On Jan 15, 2008 5:21 PM, Simon Paquet <web...@babylonsounds.com> wrote:
>> Martijn wrote on 15. Jan 2008:
>>
>>>> Note that I'm not trying to minimize your usage of bookmarks, with
>>>> deep hierarchies and many thousands of bookmarks; it's important
>>>> to get that use-case right. I just don't think it's the common case
>>>> that we ought to optimize for by default.
>>> Well, I do think that is actually the common case.
>> Can you qualify this assertion in any way? I can only speak for myself
>> here, but I have perhaps 10-15 bookmarks in my FF2 installation. For the
>> rest I rely mostly on urlbar autocompletion.
>
> Why would one have to type something in the url bar, when you can just
> bookmark the link and click on it?
> Much more convenient, because you don't have to leave the mouse.
The question was which one is the dominant use-case... having seen beginner
and intermediate users using Firefox, my general sense is that they don't
bookmark sites using the keyboard or the mouse... they just search for them
again in google, or if they are more aware, they type the address again in
the url bar. So I conjecture without the weight of scientific study, that
the current bookmarking system is under-used and people who have more than a
few bookmarks (maybe 5-10) are the vast minority.
The "problem" with bookmarks for me (and for other users I have coached) is
that you have to take an explicit action to remember that a page was
important to you. With places you don't have to take any explicit actions to
remember pages: the browser will remember your history and make it available
in an easily searchable form. I will often remember to star a page the
*second* time I visit it, having found it again via the urlbar.
--BDS
Martijn
> Martijn wrote:
> > On Jan 15, 2008 5:21 PM, Simon Paquet <web...@babylonsounds.com> wrote:
> >> Martijn wrote on 15. Jan 2008:
> >>
> >>>> Note that I'm not trying to minimize your usage of bookmarks, with
> >>>> deep hierarchies and many thousands of bookmarks; it's important
> >>>> to get that use-case right. I just don't think it's the common case
> >>>> that we ought to optimize for by default.
> >>> Well, I do think that is actually the common case.
> >> Can you qualify this assertion in any way? I can only speak for myself
> >> here, but I have perhaps 10-15 bookmarks in my FF2 installation. For the
> >> rest I rely mostly on urlbar autocompletion.
> >
> > Why would one have to type something in the url bar, when you can just
> > bookmark the link and click on it?
> > Much more convenient, because you don't have to leave the mouse.
>
> The question was which one is the dominant use-case... having seen beginner
> and intermediate users using Firefox, my general sense is that they don't
> bookmark sites using the keyboard or the mouse... they just search for them
> again in google, or if they are more aware, they type the address again in
> the url bar. So I conjecture without the weight of scientific study, that
> the current bookmarking system is under-used and people who have more than a
> few bookmarks (maybe 5-10) are the vast minority.
Yeah, that might very well be the case. My father does it that way.
But I very much doubt they'll use the address bar.
In any case, I don't see why improving the url bar case has to
undermine the bookmarking case.
> The "problem" with bookmarks for me (and for other users I have coached) is
> that you have to take an explicit action to remember that a page was
> important to you. With places you don't have to take any explicit actions to
> remember pages: the browser will remember your history and make it available
> in an easily searchable form. I will often remember to star a page the
> *second* time I visit it, having found it again via the urlbar.
Well, I don't agree it's an easily searchable form.
And isn't the starring of a page simply bookmarking?
Or am I misunderstanding now what the starring of a page is?
Regards,
Martijn
> --BDS
Tony Mechelynck
Well, yes; but once a user learns how useful bookmarks are, he'll use them,
and from then on, the number of his bookmarks will increase steadily over
time, even if they do so slowly. ATM I have 78 bookmarks organised in 16
folders and subfolders; I don't believe that's "unusually high" for someone
who's been browsing the Web for as long as I have; and when I bookmark a page,
I want a chance to tell the browser in which bookmarks folder I want that page
to land.
For me, URL bar autocompletion and bookmarks menus (with folders) are not an
"either-or" thing; rather, they're complementary: when I load a page using
"Bookmarks -> Mozilla Project -> Community & Support -> Mozillazine ->
Knowledge Base -> keyconfig" (using bookmarks folders, at least some of which
I created myself, and doing a menu choice at each step), I'm using a quite
different "logic" than when I type part of a URL then select from the
drop-down list. Compare it to finding a page in a book using the table of
contents, or using the alphabetical index: a "good" reference book ought to
come with both, and both of them "usable".
And, it's true that I often "forget" to bookmark a page the first time I visit
it; but once I want to see it again, fail to remember the URL, don't find it
in the autocomplete drop-down, then finally get back at it by following links
from page to page, you can be sure I _will_ bookmark it if I think there's the
least possibility that I'd want to see it again.
Best regards,
Tony.
--
YOW!! Everybody out of the GENETIC POOL!"
Nikitas Liogkas
Mike Beltzner
> Alex Faaborg schrieb:
>>> I find it interesting that you ignore all the concrete UI critizism and
>>> just post your new mockup.
>> I replied to your specific points in the tracking bug for the mockup.
>> I've also spent a reasonable amount of time justifying the design
>> decisions I'm making in 6 different lengthy comments in 393509 and
>> 412387 over the past 3 hours. I'm hardly ignoring criticism, and if
>> anything I'm spending too much time carefully explaining rationale.
>
> Just "justifying" and "explaining rationale" is not a reaction to
> critisim, because you change nothing. We (not just me, but many people
> there) are trying to tell you that the approach is not good, and
> violates user expectations and GUI rules, but you go ahead anyways.
Open source projects mean that we ask for our community to contribute
and collaborate, and that code changes are reviewed and discussed
publicly, but it does not mean that we design by committee.
Allow me to guarantee you that Alex reads *every* ounce of feedback he
can find and considers it all *very* carefully. Accusing him of ignoring
you and not explaining why he's doing what he's doing is a complete
process foul, and bordering on a personal attack that's unwarranted.
Violating user expectations is serious, and we've heard loud and clear
that the instant-apply stuff is strange, especially for Windows users.
While I personally blame "Apply" buttons (which have been mostly no-ops
since Windows 95) for this, I think what Alex is trying to do here is
move us to a model that's more efficient and effective.
Violating HIGs and Guidelines is something we should be less concerned
about. HIGs were created to ensure consistency of metaphors when
computers and their users were new, and it was important to standardize
on terminology like "New..." and "More...". They're excellent resources
for new developers starting out to ensure that they understand the work
that's gone before; but like all technological innovation, they're not
meant to bind creativity or innovation. They should be understood and
respected, but not held as gospel. I do not feel like the violations in
question are worse for the user, but trust me, it's not being ignored.
Alex and I talked more about this today and agreed that it's important
to include clear paths to both removing a bookmark, undoing the changes
that were made, and completing an edit action. At the same time, we'd
like to retain the instantApply nature and make things so that the panel
is non-modal and will disappear when the user clicks outside of it.
>> This pattern currently appears in Mail.app for To Do items, and in
>> iCal for appointments.
>
> I don't remember seeing that (which is a hint that it's not a common UI
> pattern), but I don't remember ever being as confused in a Mac as the
> new Bookmarks UI left me.
Instant-apply is all over the place in OSX; just open your System
Preferences.
> E.g. when I clicked the star, nothing happened. I actually had to go
> search around, go to Bookmarks Manager and guess at "Unfiled Bookmarks"
> and look there to know what actually happened and where the bookmark was
> placed. The new mockup gives feedback about what happened, which is
> good, but in a dialog (it is a dialog, because it has widgets), and it
> still doesn't tell me where it went.
Alex's mockups addressed this explicitly, and he's acknowledged several
times that it's always been intended for user feedback to be given.
>> Since I'm a designer at Mozilla and not Apple, I'm unfortunately not
>> going to be able to update their documents to include a new chapter on
>> the benefits of instant apply contextual dialogs.
>
> Phew. Again, it's not about "updating guidelines", but *following* them.
...
> The new UI throroughly confuses us and is against *everything* that
> people learned about how GUIs work, and you want to go ahead and
> "update the guideline".
Disagree entirely. Apple routinely violates their own HIG, as does
Microsoft. The innovative "Ribbon" design in Office 12, a lot of slick
AJAX UIs online ... all routinely try to innovate in ways that mash up
familiar UI interactions with ones that are better tailored to the task
at hand.
People are remarkably adaptable, especially if they're introduced to new
concepts in ways that build on known concepts.
> Please, use what people are familiar with from everyday use:
>
> * Use normal dialogs
> * When I bookmark something, open a dialog, allowing me - actually
> *encouraging me* - to change the label/title and picking a folder
> and/or tag. This is not more clicks that in your proposal - with
> your proposal, I also have to click to get the flyout dialog away.
> I just have a smaller, but at least a clear spot to click.
I've proposed to Alex that we add "Other folder..." to the folder drop
down which would do the same thing as the expando-widget. This has been
a long standing issue, though, which existed in previous issues of
Firefox as well.
cheers,
mike
Mike Beltzner
>> But how the UI works isn't and shouldn't defined by an app and certainly
>> not some websites that a large part of the user base never visits (the ones
>> you mention are certainly US centered). Instead it is defined by the system
>> the app runs on. You should definitely not try to bring click-outside-to-
>> close to Linux and Windows because (apparently only one?) app on MacOSX
>> and some webpages do it that way.
>
> type dialogs here on windows.
Look-and-feel is dictated by the OS, and we've taken great pains to move
to more native look and feel where-ever we can within our platform's
constraints.
Allowing our UI to be shackled by outdated and restrictive HIGs, on the
other hand, especially when those OS vendors are not restricting
themselves, is totally wrongthinking.
cheers,
mike
Ben Bucksch
> "My data is important" and "stability of format and external access"
> are not the same thing, and I don't think it helps matters to conflate
> them.
One follows from the other. If my data is important, then access to the
data becomes critical, and on the desktop that means stability of the
format and third-party applications (compare Microsoft Word, and the
problems we got into due to the format changes).
>> Format changes, see above. Consider that ubuntu releases have 3 year
>> support, with no upstream feature updates.
>
> Are you saying that it is a blocker feature for older versions of
> Epiphany that aren't aware of Firefox 3 to still be able to import
> Firefox 3 bookmarks?
No, but I am saying that if you use a new format now, that format should
be the one for the next 10 years, without breaking reader code in other
browser's import functions *again*.
> I think that's a ridiculous burden to place on Firefox development.
> The fact that we have an "export" feature which enables
> backwards-compatible import is already enough.
We didn't consider the "Export to HTML" feature in MSIE sufficient, we
wrote an importer which imports from MSIE without user interaction. I
think it's just fair to allow other browsers like Opera, Safari,
Konqueror and SeaMonkey the same with Firefox.
Ben Bucksch
> With places you don't have to take any explicit actions to remember
> pages: the browser will remember your history and make it available in
> an easily searchable form.
I think we can all agree that including bookmarks in the autocomplete
search is a good idea.
--
When responding via mail, please remove the ".news" from the email address.
Ben Bucksch
> For me, URL bar autocompletion and bookmarks menus (with folders) are
> not an "either-or" thing; rather, they're complementary: when I load a
> page using "Bookmarks -> Mozilla Project -> Community & Support ->
> Mozillazine -> Knowledge Base -> keyconfig" (using bookmarks folders,
> at least some of which I created myself, and doing a menu choice at
> each step), I'm using a quite different "logic" than when I type part
> of a URL then select from the drop-down list. Compare it to finding a
> page in a book using the table of contents, or using the alphabetical
> index: a "good" reference book ought to come with both, and both of
> them "usable".
Exactly. That's pretty exactly how I use bookmarks and the browser.
Bookmarks are my table of contents of the world.
And a TOC is useful, if I don't remember the exact name/title, but I
know the concept discussed.
Autocomplete (only) helps when I know the title or url.
Alex Faaborg
fit different use cases. One of the interesting ways we are starting
to merge the two is by allowing you to enter tag names into the
location bar. For instance, I can't remember the name of my
electrical company, but if I enter "bills" into the location bar, all
of the sites that I pay my bills at appear in the results (because
they have this tag). This is essentially a hybrid search/browse
operation, and is more efficient than going to my bookmarks menu and
navigating Home Stuff > Finances > Apartment > Bills
-Alex
Alex Faaborg
On an only tangentially related note, the author of that article Aza
Raskin will be joining Mozilla tomorrow along with two of his
colleagues from Humanized [1]. They are some of the most creative
people I have met when it comes to rethinking interaction design, and
they will be innovating in ways that are way outside of traditional
HIGs. We are incredibly lucky to have them joining, and this is a big
win for Mozilla Labs.
-Alex
[1] http://www.techcrunch.com/2008/01/15/breaking-mozilla-buying-humanized/
Martijn
> Martijn wrote:
> > Yeah, I agree with this 100%. It's really strange seeing these MacOSX
> > type dialogs here on windows.
>
> Look-and-feel is dictated by the OS, and we've taken great pains to move
> to more native look and feel where-ever we can within our platform's
> constraints.
>
> Allowing our UI to be shackled by outdated and restrictive HIGs, on the
> other hand, especially when those OS vendors are not restricting
> themselves, is totally wrongthinking.
I was already afraid you were going to say that :(
But I hope that is being kept in mind that most users are on a Windows
environment and that a lot of them might be coming from IE6 or IE7.
Regards,
Martijn
> cheers,
> mike
Peter Weilbacher
> And isn't the starring of a page simply bookmarking?
> Or am I misunderstanding now what the starring of a page is?
I'm confused about that, too. To me the star didn't really mean anything
until I saw it discussed in this thread where people now use "starring"
as something of a synonym for "bookmarking".
Peter.
P.S.: I also recently saw a "star" column in Thunderbird (2.x even) and
didn't know what to do with it.
Michael Lefevre
> Benjamin Smedberg schrieb:
>> With places you don't have to take any explicit actions to remember
>> pages: the browser will remember your history and make it available in
>> an easily searchable form.
>
> I think we can all agree that including bookmarks in the autocomplete
> search is a good idea.
Although, and I guess I should find/file a bug for this in case it gets
lost in this thread, there is a bit of an issue with this...
I have 2 URLs for different reports bookmarked, like:
Bookmark 1:
URL: http://gamestatssite.com/report/jf8234b28gbfwe
Page title: "Game stats"
Bookmark name: "Stats report foo"
Bookmark 2:
URL: http://gamestatssite.com/report/98f92fifbiu32b
Page title: "Game stats"
Bookmark name: "Stats report bar"
At the moment, if I put "stats" or something similar into the box, I get a
dropdown list like:
Game stats
http://gamestatssite.com/report/jf8234b28gbfwe?1234-5678
Game stats
http://gamestatssite.com/report/jf8234b28gbfwe *
Game stats
http://gamestatssite.com/report/8923h9wbf328la
Game stats
http://gamestatssite.com/report/98f92fifbiu32b *
Game stats
http://gamestatssite.com/report/nwefu327f9wefw
The stars just about help me to pick out the bookmarks, but seeing the
name I gave it rather than (or as well as) the page title would work much
better. Having that bookmark name searchable would be even better (I
don't think it does that but I don't have FF3 in front of me to check...)
--
Michael
Foteos Macrides
> Why would one have to type something in the url bar, when
> you can just bookmark the link and click on it? Much more
> convenient, because you don't have to leave the mouse.
I agree that I can get to a desired bookmark much faster and more
conveniently by using only the mouse via the toolbar's Bookmarks
drop menu system, and similarly feel that leaving the mouse to type
into the urlbar is a reasonable choice only when there is not such a
quicker and more convenient alternative.
In that regard, it would be nice if the Bookmarks drop menu also had
a Tags item, which on hover spins out additional menus for quickly
getting to bookmarks via their tags (as via their Bookmarks directory
structure). One can do it by clicking on Show All Bookmarks to get
the Library module as a window, but typing the tag into the urlbar can
(validly :<) be claimed to be faster than that alternative.
If this is already a bug, I missed it and would appreciate being pointed
to it.
Fote
--
David McRitchie
I expect you meant keyword as you would only want to go to one place
to pull up the folder, which you can do:
places: chrome://browser/content/places/places.xul
In other words a keyword of "places:" and location
of the chrome shortcut "chrome://browser/content/places/places.xul"
But certainly people have been clamoring to be able to use keywords
to get to folders. Except that some people want every bookmark
to be be opened in the folder. An excellent example of why that would
not be desirable -- but they counter by saying you have limit on how many
tabs would open at once. Anyway see
http://wiki.mozilla.org/Bookmarks_Use_Cases#Keyword_Option_for_Bookmark_Folders
https://bugzilla.mozilla.org/show_bug.cgi?id=213402
--
David McRitchie, (additional pages added for this post)
Firefox Custom: http://www.mvps.org/dmcritchie/firefox/kws.htm
Firefox Custom: http://www.mvps.org/dmcritchie/firefox/places.htm
Firefox Custom: http://www.mvps.org/dmcritchie/firefox/firefox.htm
Foteos Macrides
> Foteos Macrides wrote:
>> In that regard, it would be nice if the Bookmarks drop menu also
>> had a Tags item, which on hover spins out additional menus for
>> quickly getting to bookmarks via their tags (as via their Bookmarks
>> directory structure). One can do it by clicking on Show All
>> Bookmarks to get the Library module as a window, but typing the
>> tag into the urlbar can (validly :<) be claimed to be faster than that
>> alternative.
>
> one place to pull up the folder, which you can do:
> places: chrome://browser/content/places/places.xul
>
> In other words a keyword of "places:" and location of the chrome
> shortcut "chrome://browser/content/places/places.xul"
I've set up keyword shortcuts for searches at other sites via the urlbar,
and that's a nifty feature, but searches typically require typing into an
input box (so it may as well be my urlbar instead of having to go to the
site and use its input box). Keyword shortcuts for particular bookmarks
reduce how much needs to be typed, but still involve leaving the mouse.
What I'm after in this thread is ways to minimize having to leave the
mouse and type into the urlbar. The native Fx3 bookmarking dialogs
(through Alex's latest iteration:
http://people.mozilla.com/~faaborg/files/granParadisoUI/places_NewBookmarkDialog_i9.png
in: https://bugzilla.mozilla.org/show_bug.cgi?id=393509) offer ways
to place items in a Bookmarks directory tree, plus tag them with one
or another tagname that has semantic significance for me of a sort that
is different from that for my directory names in the Bookmarks tree.
For example, a number of my tagnames indicate bookmarks for
documents which import a particular CSS or javascript file or file
set, and which I want to check whenever I make changes in the
imported file(s), but they are not grouped that way in my Bookmarks
directory tree.
The current Bookmarks drop menu system lets me whizz to items
based on its naming logic.
What I'd like is a complementary ability based on my tag naming
semantics. So if I've set any tags, then the Bookmarks drop menu
would include a Tags entry with a right-arrow. On hover that would
invoke a menu with my current tagnames and right arrows. On hover
over one of those I'd get a menu with the bookmarks which were
assigned that tagname. So based on either the Bookmarks directory
tree placements and naming logic, or the tagname assignments and their
different naming semantics, I could get to and click on what I want in
less than 237 msec (or thereabouts :<) via the drop menu systems,
without having to leave my mouse and start pounding on the keyboard
to use the urlbar.
I'm getting optimistic that I've learned enough about using overlays
and extending bindings, etc., to make an add-on for this as a "fun
project" during the next holidays. :<) But I suspect I'm not unique
in this regard and many others might like this feature included in
Fx3 without need to generate an add-on for it.
Fote
--
Foteos Macrides
> [snip] What I'm after in this thread is ways to minimize having to
> leave the mouse and type into the urlbar. [snip]
>
> The current Bookmarks drop menu system lets me whizz to items
> based on its naming logic.
>
> What I'd like is a complementary ability based on my tag naming
> semantics. So if I've set any tags, then the Bookmarks drop menu
> would include a Tags entry with a right-arrow. On hover that would
> invoke a menu with my current tagnames and right arrows. On hover
> over one of those I'd get a menu with the bookmarks which were
I just discovered that what I'm seeking for tags is available in the
Bookmarks Toolbar as a Recent Tags item via the Smart Bookmarks
item.
What exactly is meant by "Recent" (i.e., under what circumstances
might some of my tags not appear in that drop menu system)?
I don't display the Bookmarks Toolbar, as part of maximizing my
viewport area, and instead have been using the Bookmarks
Toolbar Folder item in the Bookmarks drop menu. It's gone in
Minefield, and that's I why checked the Bookmarks Toolbar today.
If the Bookmarks Toolbar Folder item were still in the Bookmarks
drop menu, I'd also now have rapid drop menu access to my tagged
bookmarks based on their tags, without having to give up any
viewport area. Why was that item removed?
Also, in the Library window, the folder bar at left has three folder
hierarchies whose top members had their names left as null, and thus
have (no title) displayed. Based on what's in their hierarchies, I gave
them the names Tags, Unfiled Bookmarks, and Bookmarks Toolbar
Folder. That doesn't seem to be causing any problems. Why were
they left null?
Fote
--
Ben Bucksch
> URL: http://gamestatssite.com/report/jf8234b28gbfwe?1234-5678
> Page title: "Game stats"
> Bookmark name: "Stats report bar"
>
> At the moment, if I put "stats" or something similar into the box, I get a
> dropdown list like:
>
> Game stats
> http://gamestatssite.com/report/jf8234b28gbfwe?1234-5678
>
Yes, please file a bug about that.
Michael Lefevre
I'm not sure if there is/was a bug on file, but in Firefox 3 beta 3 rc 3,
it does now seem to show the bookmark name instead of the page title from
history.
--
Michael
Philip Chee
Err. Perhaps the trouble is actually this?:
Searching for gamestatssite.com A record at h.root-servers.net
[128.63.2.53]: Got referral to b.gtld-servers.net. (zone: com.) [took 40 ms]
Searching for gamestatssite.com A record at b.gtld-servers.net.
[192.33.14.30]: Reports that no A records exist. [took 178 ms] Response:
No A records exist for gamestatssite.com, and gamestatssite.com does not
exist. [Neg TTL=900 seconds] Details: b.gtld-servers.net. (an
authoritative nameserver for com.) says that there are no A records for
gamestatssite.com, and that the hostname gamestatssite.com does not exist.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]I'm sure it's clearly explained in the Zmodem documentation.
* TagZilla 0.066.6
Michael Lefevre
> On Sat, 09 Feb 2008 14:55:19 +0100, Ben Bucksch wrote:
>> Michael Lefevre schrieb:
[snip]
> Err. Perhaps the trouble is actually this?:
>
> gamestatssite.com, and that the hostname gamestatssite.com does not exist.
Sorry - I guess I should have used the real URL or made clear I was making
up the example. The site I was think of was http://wowwebstats.com/ , but
the same issue applied to any site without page titles for each page
(actually quite a few sites with content generated dynamically don't seem
to bother creating unique titles for each page...). Anyway, as I said,
seems to have changed for the better in Firefox 3 beta 3 (rc3)...
--
Michael