Odysseus 1.1.0 Released, Now With Browser History

Yesterday I completed the development of browser history, which is now available on the elementary AppCenter!

But this work was less about supporting browser history than it was about preparing to be a fully featured web browser and the experience I wanted to deliver for that. Because if I just wanted to deliver browser history, it might’ve (maybe) been easier to make this a GTK TreeView or ListView. But I wanted a different, possibly simpler, experience.

The Design Vision

Just about any site you visit today works by “fetching” data from a “relational database”¹ and inserting it into webpages, filled with text and links, it generates on the fly. I want my browser to function the same way, for the vital navigation aids it is just beginning to offer to become more a part of the Web (see?) than a part of it’s browser chrome².

This isn’t really that different from how other browsers work (at least for Midori, GNOME Web, and Firefox; Safari and Edge are not near as trasnparant about how they work). The only difference is I’m rendering to webpages, not native-ish UIs (Chrome and Firefox before Quantum didn’t look that native to me though).

Furthermore I like my simplistic toolbar and wish to avoid extending it as I add these new features. But at the same time I really appreciate how elementary’s desktop and it’s apps keep most everything they do within reach of a single click, and I want Odysseus to replicate that. So I’ll enjoy figuring out how to deliver these features whilst not compromising these principles, and that’s why I had to add a link to history from the newtab page.

That keeps it within reach when surfers are most likely to need it (a second click otherwise is acceptable given it’s not needed all the time), whilst using a link for the main means to access it reinforces the idea that it’s part of the web.

The Focus

Upon releasing Odysseus I adopted a policy of addressing issues raised by you, the people who use Odysseus to experience the Web, before I address the larger roadmap. But in recent discussions with you guys I hear that there’s a desire for that roadmap to be implemented, so I’m changing tack.

From now I’ll move my focus towards implementing my vision of Odysseus. Of a browser that not only bridges the elementary and web UX, but one that:

• Gently guides you to where you want to go no matter where that is,
• Helps you take control of your privacy no matter your skill level,
• And avoids favouring centralized webservices with it’s UX over decentralized or even distributed ones.

It saddens me that this’ll leave the smaller issues you’ve raised unaddressed. But I suppose this is the nature of free/libre software, if you want those issues addressed you’ll just have to implement them yourself or pay someone else to do so for you.

What’s That About Not Favouring Centralized WebServices?

This really comes down to a fascinating example of how as UI developers we cannot get away from manipulating those who utilize our software. One which I’ve come to from a long consideration of what it’d take to build decentralized search (where there’s less temptation to censor), though in discussions with others I’ve learnt that federated social networks face similar problems.

In the early days of the Web (I don’t know when) browsers realized their job wasn’t just to show you web pages but to help you find those pages (again), and as part of that it is very helpful to integrate webservices we now call “search engines” that address that need. However they evolved to do so by creating a “searchbox”, which since Google Chrome was merged with the addressbar, which sent non-web addresses to a preconfigured search engine. This is a problem as it excerbated a push for web surfers to choose a single search engine, rather than to go to whichever search engine best suits their purposes in the moment.

Thankfully Firefox and Opera have now improved things somewhat, so that their UI is almost as kind to domain specific search as an interface which doesn’t integrate websearch. And to be clear that interface isn’t particularly kind to domain specific search, as websurfers need to know about the search engine before hand.

To undo the harm a browser must not prompt surfers to choose a default search engine, and to be kind to federated/domain-specific search it must build in a metasearch engine and use that to make it seamless to add new search engines.

For Odysseus I’ve found these UI decisions go hand-in-hand with delivering a minimal and elementary experience, and they can only enhance your surfing of the sites you’d go to anyways.

The Direction / Summary

After hearing from some of you, I’ve decided to dedicate my time developing Odysseus to making it a fully featured yet minimal web browser. One that not only bridges the Web and elementary UX, but one that gently guides you wherever you wish to go whilst giving federated webservices equal footing (if that’s what you want to use with Odysseus). If you want smaller issues fixed, you’ll regrettably have to either do it yourself or pay someone else.

Making Odysseus fully featured involves adding several navigation aids, which I’ll design and implement like websites independant from each other. Not only will this allow me to keep Odysseus’s chrome almost as minimal as it is now, but it will embrace the UX best suited to the link heavy nature of these aids and help you learn them as individual pieces rather than as a complex whole.

I hope you like what’s coming, as I’m certainly looking forward to it!

1. Relational databases are developer tools for saving and querying highly structured data.
2. By “chrome” I mean the controls placed around the webpage you’re viewing, rather than Google Chrome which is named after that term.