Odysseus Plans for 2018

It is New Years day for me, and while I do have other New Year’s resolutions (not that it’s a thing I tend to be very big on), I thought I’d celebrate in part by laying out my plans for Odysseus here and now.

As it stands Odysseus is a provides a great experience for viewing and navigating between webpages, but it does nothing to help you find the pages you want to (re)visit. Well there are hardcoded recommendations, but that’s only part of the solution. So if Odysseus has a New Year’s resolution, it’s to help you find and rediscover webpages.

Design Constraints

As it stands Odysseus does it’s primary job very well and I’d hate to ruin the gorgeous simplicity I’ve achieved in 2017. Besides I’ve heard plenty of studies and personal anecdotes stating that the bookmarks and history facilities offered by other browsers are terribly under-utilized, and maybe the elementary design philosophy can help to rectify this.

The relevant points of this philosophy includes:

• An aversion to configuration settings, particularly those that must be set before the app can be used.
• Having computers micromanage things rather than the end-user.
• And building minimal and modular applications

So a true accomplishment is if I can obtain similar functionality to other browsers without adding very much at all to Odysseus’s toolbar and without adding a settings panel. However it won’t be hard to get rid of most of the settings pane, as most of the settings present in Chrome or Firefox can be either hardcoded or defer to the operating system.

Design Vision

I’ve already documented many details of my plans in the Odysseus wiki, so I’ll just share in this blogpost my overarching vision. In one year almost nothing will be added to Odysseus’s toolbar: the app will still look basically the same. Instead a number of independant navigation aids would be integrated into the newtab page and/or the addressbar autocompletion (in addition to the application menu), both of which are controls for going somewhere. The individuality of these aids is intended to allow users to easily grasp how to interact with each one, rather than how to interact with them as a whole.

Furthermore to reduce perceived complexity I’ll render any UI for these navigation aids as simple webpages. This should work well both because the Web is an inherent part of Odysseus’s UI, and because it is already a large and complex graph so adding a few extra Odysseus-specific pages should make no difference.

All of this would allow Odysseus’s surfers to quickly understand the new navigation aids piece by piece, while dedicating near no screenspace to each one. However what it doesn’t do is really change how surfers interact with these components once they’ve got their pages up.

Moving beyond simpler navigation to navigation aids

In my design process I’ve found that simply by changing how bookmarks are organized I could bring great changes to the rest of Odysseus.

The issue is that traditionally browsers organized bookmarks hierarchically, and not only is it often challenging to decide where to organize a webpage in such a scheme but such schemes grow out-of-date very quickly. It’s especially hard when trying to organize bookmarks into someone else’s hierarchy, which precludes groups, computers, and websites from helping you out. So instead Odysseus will switch entirely to using tags for organization.

This makes a sea-change of difference, as not only are surfers given a more natural and less pigenholed way to organize pages, but:

• it becomes natural to search for bookmarks by tag from the addressbar
• webpages can more easily set good defaults for how their pages should be organized in their reader’s favourites
• Odysseus can suggest additional tags to apply, and maybe imply others.
• with some webhosting technology (say, IPFS), it becomes practical to share your bookmarks.
• etc (more to be discussed below)

Most of these benefits will be particularly strong if people can publish and save “vocabularies” of tags, which brings us to…

Why Extensions?

For some navigation aids, it becomes useful to allow third-party datasources to be integrated into an Odysseus install. This is particularly so if I don’t want to presume anything about the surfer’s interests (like I do with the recommendations site).

On the otherhand plugins in all the mainstream browsers tend to both make those browsers slower and clutter their chrome. Needless to say, these are not apsects I want to bring to Odysseus. As such I will insist on taking control of the experience of any Odysseus plugin, simply by making them declarative and existing data formats.

Specifically I want to help surfers use the sites they have visited to search for pages, help organize their bookmarks, share other pages they visit with their freinds, and more.

Extensions UX

To accomplish those goals for extensions, the addressbar will be extended to indicate the presence of extensions (in addition to extension-like RSS feeds, as well as a readable mode for pages and how secure the connection to the site is). A gray icon would indicate an extension or mode is available but not installed, while a blue icon indicates it’s installed, and an orange one would indicate an installed plugin or page mode is active on this page.

Clicking a plugin will either toggle it on or off, or bring up a menu of togglable extensions of the same type. However so as to not require users to revisit the pages they’ve installed plugins on, surfers would also be able to manage their plugins as favourites. This is yet another benefit of tagging and shared vocabularies, as it allows extensions to reuse existing UI rather than requiring their own settings pane.

However when it comes to search engines there is a catch: this interface won’t on it’s own allow you to select a default search engine, so I’ll need to have different solution. Or two:

1. Every search engine that can will be combined into a single search page.
2. For the remaining, the last used one will intelligently be the default next time.

As for whether I’d have an addons directory like the big boys: I don’t plan on implementing one myself (well, maybe a discovery mechenism for vocabularies). But if I were to integrate one, I’d do nothing more then recommending it on first-launch and maybe integrate it as a default search engine. Installing addons would work exactly the same, all of which would be done to avoid extra perceived complexity.

How did this design come about?

While the above is a nice narrative that convinces me that I’m on the right path, it’s not the narrative I took to these ideas. It’s just what I encounter when building a browser from relative scratch. The truth is that I’m curious about how one might redesign how we discover information online, and whether by doing so we can make it embrace Ethical Design. The ideas I have around this is to essentially encourage the success of smaller, domain-specific search engines.

Towards this end I wanted to use SKOS to help users to combine their bookmarks into larger and larger domain-specific catalogues, as well as to use OpenSearch to get away from requiring users to have a default search engine set. Ofcourse to encourage the success of these domain-specific search engines more roadblocks between those two needs to be addressed, but this provides a solid base and requires a browser willing to explore these ideas. So I created one.