Live data from Hacker News

Mozilla UX: Save For Later (why bookmarks are broken and how to fix it)

blog.mozilla.org

41–50 of 113 posts

Re: Mozilla UX: Save For Later (why bookmarks are broken and how to fix it)

#42
post #13

Generally I only bookmark stuff that's going to be useful to me at a later date. What I'd really like is for the bookmark to also cache the page locally so that even if I click the bookmark at a later date and the site has gone I can still read what was on the page.

Both Clipboard and Pocket can do that. Pocket is my personal favorite as it's available on all devices that I own: http://getpocket.com/ https://clipboard.com/

Re: Mozilla UX: Save For Later (why bookmarks are broken and how to fix it)

#43
post #12

I am one of the worst offenders of the "keep the tabs open variety". I have several hundreds of them open for months on end. For this rather unusual browsing habit, no other browser other than FF works for me. FF does fine even on my 512MB Pentium-M laptop, Chrome for instance will make such a box unusable . Am somewhat relieved/piqued to see that this behavior is not unique. I have been asked to defend my habit many…

I do the same. My hundreds of tabs are my memory "staging area".

If I revisit them ~3 times or more - they get "committed" to my long term "repository" (aka bookmarked and mentally memorized).

Re: Mozilla UX: Save For Later (why bookmarks are broken and how to fix it)

#44
Love the process, but not the final mock-up. While the grey boxes look neat, the visual format is inappropriate for bookmarks. If they use fav icons like the NY Times logo, you won't be ale to tell what the bookmark is about. Small screenshots of the pages also don't work since they become illegible and many times only ads can be recognized since they are made to stand out. So this concept should be validated with real content. I'd assume that a text-based version would be much more usable.

I'm looking forward to see what will come from this.

Re: Mozilla UX: Save For Later (why bookmarks are broken and how to fix it)

#45
Mobile devices are fantastically horrible objects, and you have to blame the deliberately hobbled, crippled nature of touch screens for many, many things that suck when (trying) to use one.

My fat fingers are too stupid to learn how to type on soft keyboards, and that's the end of it. Even when turning on pointer position feedback that shows the path and position of the cursor, to reveal what the interface THINKS I'm trying to do, it's usually a little off because my fingers are soft fleshy blobs. Soft keyboards are one of the more reasonable examples of touch screen software, and there are many varieties, and they get a lot of truly professional attention. Seriously, try using an ordinary desktop keyboard with a water balloon. It yields poor results.

Touch screen experiences suck. Add to the fact that many devices include resolution independent interfaces, and there becomes this hellish mix of software controlled guess work that stands as an insurmountable obstacle between me and the delivery of actual professional work, beyond typing an e-mail. They will never yield the pixel perfect pointing precision of a mouse.

Touchscreens are prompting the destruction and reinvention of lots of things that work fine with any Keyboard/Video/Mouse interface, are twisted into horrid mutant abominations that make me want to commit suicide on touch devices. Everyone is bending over backwards to coddle and baby people who own these status symbols du jour.

That being said, there needs to be a line drawn on re-designs of perfectly useful software, in the name of the holy tablet/smartphone/touchscreen complex.

Case in point: Bookmarks & RSS

In Firefox, this is one of the key features that has me hooked for life (while it remains in place). In every mobile device I have ever seen, RSS is an abomination, and I refuse to embrace it. Internet Explorer is too awful in general, so don't even bring it up (I won't get into why Chrome is also a non-starter, but I'll just mention that in-browser authentication is point-blank wrong, and I don't like signing into my browser). But it's perfect in Firefox, and they shouldn't touch it. If RSS ever disappeared from Firefox, I would simply never look at another feed again. I would not use a stand-alone RSS program to consume and digest RSS feeds.

RSS is a key component of bookmarability in Firefox, and it ain't broke. Not on desktops and laptops. I hope these kinds of details aren't lost in the rush to compete with amateur crapware that we find on mobile devices.

Re: Mozilla UX: Save For Later (why bookmarks are broken and how to fix it)

#46
post #12

I am one of the worst offenders of the "keep the tabs open variety". I have several hundreds of them open for months on end. For this rather unusual browsing habit, no other browser other than FF works for me. FF does fine even on my 512MB Pentium-M laptop, Chrome for instance will make such a box unusable . Am somewhat relieved/piqued to see that this behavior is not unique. I have been asked to defend my habit many…

I am also asked to defend my habit again and again. And so I have long struggled and meditated on this problem. What I ultimately decided is that a repository of bookmarks or open tabs, or of any kind of knowledge, is useless as a static collection and quickly degenerates into a backlog never to be accessed again. I abandoned my humongous Delicious account and have since been developing a little something that offers a different take on the subject. I have been saving dumps of my open tabs' urls into files for years now, to preserve my sanity, knowing I would one day get around to the right solution to my own ailment.

My take on the problem is action-oriented browsing. I think that anything you clip or save or note down must have an intended action, now or in the future. Maybe you are saving a bookmark because you want to refer to it when you tackle some personal project you want to do someday/maybe. It must then be triggered by that project when you finally get to it. If you never get to it, the bookmark will die with the project, which is just as well.

Most bookmarks will never be accessed again, but you don't know which ones yet. It's the long tail principle. We don't have time to do everything we want, but in the spirit of GTD, ideally we'd like to map out all that we could want to do, so we can always (say, weekly) review our priorities and be ready to pivot into new directions if situations, or our minds, change.

Even if you are only saving a cute picture of a cat, it is still actionable. Why are you saving it? That's the key question. It may be because you want to show it to some people, so it should be triggered in your next interaction with each of those people, and then you're done with that bookmark and you can let go of it.

Articles that you want to read or reread should by triggered by a reading list, or by study plans for particular subjects, or even by a blog post you want to write on the ideas you read on several of these articles.

It's all about what should trigger that bookmark to come into your attention again. You shouldn't need to remember to check it back on your own, or you may well never do.

Re: Mozilla UX: Save For Later (why bookmarks are broken and how to fix it)

#47
post #19

Earlier quoted context omitted.

> I hate to be That Guy, but maybe you should look into writing your own; extensions are fortunately just bundles of JavaScript. Javascript isn't the hard part here; it's trying to figure out how to extract anything like what I need from the places.sqlite databases that hold all the relevant data.

If you trust the cloud Mozilla's client side encrypted sync service will do this. If you want simple and dirty. 1. Create a backup of your bookmarks using the import and backup button on the Library window on each machine 2. Pick your favorite scripting language 3. merge the two json backup files using your script Import the resulting json file in a clean Firefox profile.

> Create a backup of your bookmarks using the import and backup button on the Library window on each machine

I've tried this. The tags are not in the JSON dumps. The Mozilla people apparently believe that backing up your bookmarks means to back up everything except the tags.

A corollary: The only way to actually back up your bookmarks is to back up the places.sqlite file. Nothing else contains all the relevant data.

Re: Mozilla UX: Save For Later (why bookmarks are broken and how to fix it)

#48
post #2

No mention of HN's "saved stories"! :)

Honestly, this is the main reason I always have a tab open to HN. There are so many items on here that I know I don't have the time to look into immediately but will return to, and having them saved just by upvoting feels really good. I very close attention to what I vote for, and when I go hunting for a link I know there's a good chance it'll be saved along with comments for context.

Re: Mozilla UX: Save For Later (why bookmarks are broken and how to fix it)

#49
post #25

Reasons why I bookmark pages: 1. I meant to type Ctrl+W and missed slightly 2. I meant to type Ctrl+F and missed slightly 3. I meant to type Ctrl+C and missed slightly My bookmarks are a mish-mash of random pages on which I accidentally pressed Ctrl+D, nothing more. I think I'm a particularly anomalous edge case on this particular issue because as a web developer I tend to flit around between browsers constantly so n…

>no single-vendor syncing service is ever going to be useful to me.

Ever tried Xmarks?

Re: Mozilla UX: Save For Later (why bookmarks are broken and how to fix it)

#50
My add-on https://addons.mozilla.org/en-US/firefox/addon/categorize/ combines bookmarks and tab-management. It lets the user group bookmarks into sets that a user can open all at once or singly. This approach almost completely eliminates the need for an address bar.

Another interesting feature of the add-on is that it unifies bookmarks and web-search. The two seem totally disparate but they can be integrated seamlessly in a very cool way. Check http://techuser.net/beyond-chrome.html for an overview of the approach.

Post reply on HN