Goodbye (and good riddance) Bookmarks

I hop browsers. I admit it, readily. I find no shame in it; I’m not “flip-flopping”; I’m looking for the best tool for the job, and when it comes to web browsers, they are still rapidly evolving. This habit, though, is not without drawbacks.

Even the definition of what a browser should do is evolving; 20 years ago, your browser was either part of a comprehensive application for all things “online”, or itself a complete suite of online tools… think AOL or Netscape Communicator (which included a browser, mail client, news reader, a WYSIWYG HTML editor…). Today, the browser is more of an application framework (think Electron - which is based on chromium), and increasingly a tool for managing personal data (e.g. “privacy”). Both Mozilla and Google have built operating systems based, primarily, on hosting a web browser. Features like Chrome’s Incognito mode, and browsers like Brave, Iridium, and Tor Browser focus on limiting how you are tracked online, and how your information is shared (or preferably not shared). Opera and Epic boast built-in support for VPNs. As we’ve moved from ‘gateway’ to ‘platform’, superfluous features have been stripped out, and browser development has turned towards performance, consistency, and stability: Google’s V8 Javascript engine is at the core of Electron and Node.js, and the GNOME Desktop is built on Mozilla’s Spidermonkey; Firefox’s Quantum release boasted a massive rewrite of the rendering engine into new multi-threaded model. The downside is, that all the browsers move at their own speed, so it’s impossible to say, after any release, that there is a Lord of the Browsers, one browser to rule them all. Some releases are huge steps forward, some are shocking steps backwards.

The problem is, browsers are still clinging to some ‘gateway’ features, some unhealthy attachment to bygones that haven’t been clearly replaced by better, independent products, or so I thought. Bookmarks, password managers, start page content… blech. All these things are still carried around in every browser, and no browser handles them well, because they’re not the core function. They’re afterthoughts now, and they don’t play nice with each other. These appendices, this cruft, is what makes switching browsers harder than it ought to be.

My problem with this, simply, is I have a lot of bookmarks. Not a big heap of bookmarks, but carefully curated folders of folders of entries I use on a regular and daily basis. Hundreds of them. I maintain my bookmarks; I curate them. They keep my work organized, and I pay back the favor… you get the idea. Yet, every time I switch browsers, I end up fixing things up again. Firefox offers to import your bookmarks… into the “From [some other browser]” folder. Chrome relegates them to some position that’s not displayed on the bookmarks bar. God forbid you try using a few browsers together… the only plugin that made any earnest effort to keep things in sync was XMarks, and it’s been relegated to the trash heap. This is just on the desktop… I’ve not even touched on the mess that is getting those bookmarks to work on some mobile browser. Shudder.

Well, I had a lot of bookmarks. I couldn’t deal with the back and forth anymore. It’s enough just to keep the bookmarks neat and functional; trying to get browsers to play nice was just more than I was ready to deal with.

Side Note: I am actually pursuing a side project that will make those damn browsers play nice… but it’s a long way off

Well, I’m a developer. I make software, and I’d like to think I’m fairly good at it. So, I decided to look at this like any software problem… and the clear solution was to refactor my bookmarks; abstract them away from the browsers in a way that maintained usability. So… here we go… “Clean Code” meets “bookmark hell”:

1. There are two kinds of bookmarks. Applications one uses, and media one experiences (documents to read, videos to watch, you get the idea). Separate them.

2. Application bookmarks are redundant… with your password manager. So make use of it.

I work with public clouds, so I have had a top-level bookmark folder of all the cloud provider portals. But all the credentials for those unique portals are in my Lastpass vault as well, including the URL. It turns out most password managers have built-in functionality for sorting/grouping entries… this is a perfect place to keep all your application URLs. I duplicated my bookmark folder structure into Lastpass, and proceeded to delete all the bookmarks that are redundant. Lastpass plugs into every browser I care to use, from Firefox to Brave, and maintains it’s own sync behind the scenes. You may prefer another password manager, but I’m sure you’ll find that if it integrates with browsers, it integrates with almost all browsers; or it doesn’t integrate at all, and that’s exactly how you want it… you Luddite.

3. Media can be further subdivided into things you keep for reference, and things you just want to consume but haven’t had time for. Further sort these into two piles. This also a great time to reflect on all those blog posts you bookmarked four years ago, but never got around to reading. Discard what is obviously no longer relevant.

Now, there are two paths you can go down here… and I ended up going down both.

Pick out a “pinboard” app, if you don’t have one already. I decided to go with Pocket, and again it plays nicely with every browser I care to use and syncs nicely. Tags took the place of folders here, but that’s fine, it’s still searchable, and if one good thing has come out of Gmail, it’s that tags and folders can be interchangeable. Those docs you want to keep for reference? Favorite them. Star them. Make a ‘reference’ tag. Whatever.

I found I also had a few documents I wanted quicker access to than with Pocket… so I added those to Lastpass as favorites as well. Now, whether I start searching in Lastpass, or Pocket, I always have my Circus Music youtube video readily accessible.

4. Hide your bookmarks, and test things out.

You may find that your password manager isn’t making searches easy, or that your pinboard just takes too long to load. Fine tune your folders & tags until you find and arrangement that works. If you’re trying out a new tool and it’s not working out, try another one before you get too invested! I ended up flattenning things a bit in Lastpass, to make navigation easier, and made my Pocket index my “home” page and “new tab” page, so things were quickly within reach.

5. When it works, delete your bookmarks.

Avoid the temptation to go back and get stuck in that rat trap again. Delete all your bookmarks in each browser, and hide the bookmarks bar as far away as you can. Disable the feature if you can. Make sure you’re living in your new bookmarkless world for real. (It’s okay to keep that backup you made before you started. You did make a backup, right?)

6. Bonus: win at mobile!

I found, as a bonus, that it was now easier than ever to also do things on my smartphone, when I needed to. The tradeoff there was relatively simple; I just needed to stop trying to use a single browser on my phone, and accept the browser component built into apps. Lastpass on Android lets me add fingerprint security, and still get to things quickly (and wipe out my sessions when I’m done.) Pocket makes it super easy to read some of those blog posts I’d been sitting on when I’m otherwise just sitting.

Vice versa, when some app wants me to register, I can generate the credentials in Lastpass, instead of resorting to “that one password I can remember” - it will also fill them in again after I wipe the data out. That site I want to check out mentioned in a podcast? Pocket’ed… for reading later.

Final thoughts.

So here I am, a month into not having bookmarks, and I’m just as happy with the decision as the moment I figured out it would work; all the trepidation about deleting my bookmarks.html files is gone, and I’m not looking back. What I am looking at is why I’m seeing some rendering glitches in Brave that I don’t see in Chromium; Google Chrome (and it’s weird relationship with online ads) are just handling those janky DRM-laden media sites, and Firefox 61 has solved most of the performance issues I saw in early Quantum releases. Multi-browser living is easy!

BLUG: Developer Tools for Desktop Users

On Thursday, Nov 2, 2017, I presented for the Bellingham Linux Users Group “Developer tools for Desktop Users”.

We talked about using git for versioning documents & configuration, using diff tools like meld to analyze system logs, and did a little Q&A on some deeper topics.

Of course, no presentation is truly complete without a failed demo - I tried to post this last night (showing Jekyll + github pages for quick, easy, free web hosting) and totally failed. I’ve spent a little time this morning digging through, and as far as I can tell, the problem was upstream at github… but the error message is sufficiently vague to prevent ever knowing why.

Your site is having problems building: unable to build page. Please try again later.

Oh well. One day later, here are the slides. Thanks to those who attended!

Firefox Klar

TL;DR: Firefox Klar (a.k.a Focus) is free enough to hit F-Droid

I’m trying harder to protect my personal privacy, and in order to guarantee that I’m trying to use more open source apps.

I was really excited about Mozilla’s launch of Firefox Focus on Android, a mobile browser designed around privacy. Ironically, Firefox Focus was not avialable on F-Droid, because it contains non-free, binary tracking libraries(here’s the report). sigh. Back to Lightning I went.

SIDEBAR: check out Lighting, if you’re looking for a lightweight, but more conventionally featured browser. It’s got really cool tab & bookmark interfaces!

Well, apparently the Germans wouldn’t stand for that, and Firefox Klar was released, sans trackers. It’s Focus, just without all the tracking binaries… and it’s in F-Droid. W00t.

Blog, v2.0

Time for a fresh start.

I’m done with Blogger, and I don’t even have to link over to the old blog, as jekyll-import did a dandy job of bringing it all along.

Hopefully, now that I can write in my editor of choice, review locally, and post as easily as git push, I’ll actually get back around to doing the short, semiregular content I’ve always wanted to post here. Wish me luck!

'Web' applications and the circle of life.

Dijoantonycj (https://commons.wikimedia.org/wiki/File:8-UX-Pitfalls-To-Avoid-In-Mobile-App-Design.jpg), „8-UX-Pitfalls-To-Avoid-In-Mobile-App-Design“, https://creativecommons.org/licenses/by-sa/4.0/legalcode


Web technologies are a funny thing.  There's no doubt that web applications have improved far beyond what was imagined in the early days of the web... everything is more performant, more interactive, and designs are more immersive. JS engines have gotten faster, HTML specifications have embraced more resources, including local integration, and CSS has grown to allow rich, robust styling. We continue to push the envelope with technologies that will serve the web faster, like HTML 2 and websockets. Web development has become a huge field. The combination of fast moving technology, developed by a growing workforce has, inevitably, allowed "web" technologies to migrate into other areas: node.js runs many server-side applications; the gnome desktop relies heavily on CSS and JS for implementing basic UI elements; HTML documentation pervades.

It's natural, then, that user-facing applications would escape the browser frame. In multiple different iterations now, "web applications" have become just "applications" on the desktop or mobile platform. Somehow, though, they're never 'good enough' for general adoption by both the consumer and developer communities: adoption rises and falls like waves on the sea, each wave a new round of applications driven by advances in web technologies, only to be eclipsed by 'native' (C++, CLR/.net, Objective-C, GTK/Qt) applications, over and over. Why? And when will web applications truly be 'good enough'?

I noticed, as I installed yet-another Electron app, that I'm sitting at the top of another wave, while simultaneously, a prior wave of web applications is being eclipsed, and it made me reflect on just how many times we've been through this.

In 2007, Apple released the iPhone, with the expectation that developers would use mobile Safari to build apps, for which 'installation' meant, mostly, adding a shortcut on the phone. Steve Jobs has been quoted[1]:

The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. They can make a call, they can send an email, they can look up a location on Google Maps.
And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today. So developers, we think we’ve got a very sweet story for you. You can begin building your iPhone apps today.

The App Store is largely viewed as a response to early jailbreakers, and complaints from a developer community that did not want to embrace web technologies, and since, the volume of (native) apps in the App Store has been a regular measure of the success of the platform.

In 2012, Mozilla once again brought web-based applications to the forefront, launching FirefoxOS which was described as "powered completely by Web technologies and offer everything you expect from a smartphone"[2]. In 2016, Mozilla demoted the project, although this is typically associated with the lackluster sales, and continuous stream of negative reviews, as Mozilla pushed toward their ultra-low price point goal of a $25 smartphone.

Google has found much more success with ChromeOS, and the broad market of Chromebooks available with the lightweight, web-centric OS. While early announcements appeared in 2009, the first hardware didn't ship until mid 2011, the CR-48 from Google. ChromeOS may have had a slow start, but it quickly picked up steam, and hasn't slowed, despite having, basically, one native app: the Chrome web browser. Chrome apps, which run on both desktop Chrome and ChromeOS, "let you use HTML5, CSS, and JavaScript to deliver an experience comparable to a native application."[3].

Despite accelerating sales of Chromebooks[4][5], fed by their low price points, security improvements based largely on their small footprint and native image delivery systems, and their ease of administration, Google still felt pressure to bring 'native' apps to ChromeOS. This is, ironically, a complete inversion of the native application. With Chrome as the foundation, and the Android marketplace chosen as the source for a larger application pool, we've seen an evolving series of Android emulation layers be bolted onto Chrome... while this does pave the way for the larger pool of Android apps to run on Chromebooks, Chrome remains the native environment here, and Android apps will, for the near term at least, be burdened by the performance losses inherent in any emulation layer.

The newest wave of Chromebooks feature much beefier specs than their web-centric predecessors, driving up price points from the $200 range on average to the $500 range[6][7], largely in support of Android apps, but also to meet the needs of power users who like the basic design principles of an OS with a smaller attack surface, simplified maintenance, and easy access to developer tools, over increasingly expensive Macbooks[8] or Windows machines whose resources are ever-more consumed by the OS itself[9].

And yet, simultaneously, web applications are rising again. Github's Electron[10] project paves the way for desktop applications based on chromium (the open source upstream of Google Chrome) and Node.js, with tooling and instructions around packaging for Windows, MacOS, and Linux (!!!). Electron grew out of the Atom project[11], an effort to provide an open-source, extensible code editor based on web technologies. (Full disclosure... Atom is my IDE of choice... for now.) Electron, serendipitously, released in the midst of a wave of next-generation communication tools, and has found it's killer app in providing an easy way for Slack[12], rocket.chat[13], Riot[14], Wire[15] and Discord[16] to easily move their web-based applications to the desktop. Today, I installed yet-another Electron app just recently: Simplenote[17], an open-source tool for jotting quick notes and syncing them _everywhere_. I stepped back and realized that nearly all the new apps I'm trying, and most of the apps I'm using, are web-based. Either packaged Electron apps like Atom and rocket.chat, or Chrome apps/frames like Trello[18], Signal[19], and Autodesk's TinkerCAD[20]. And the native apps on my desktop? Web browsers mostly (both Chrome and Firefox), along with a couple of 'legacy' apps: Pidgin for old-school chat, and Evolution, for connection to my work mail.

So, where are you in the lifecycle of web applications? Riding the crest of Electron apps, or waiting for that shiny new Chromebook that lets you run emulated Android apps? Or, do you live in iOS or Android, and just can't even tell (or care) what technologies are underneath the hood of your apps? Are you surprised to find more web technology on your desktop than you expected? I'd love to hear!


[1] https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-iphone-no-third-party-native-apps/
[2] https://blog.mozilla.org/blog/2013/07/01/mozilla-and-partners-prepare-to-launch-first-firefox-os-smartphones/