Fiber UI Experiments – Conclusion?

It’s been one heckuva road, but I think the dust is starting to settle on the UI design for Fiber, a new web browser which I’m developing for KDE. After some back-and fourth from previous revisions, there are some exciting new ideas in this iteration! Please note that this post is about design experiments – the development status of the browser is still very low-level and won’t reach the UI stage for some time. These experiments are being done now so I can better understand the structure of the browser as I program around a heavily extension-based UI, so when I do solidify the APIs it we have a rock-solid foundation.

Just as an aside before I get started; just about any time I mention “QML”, there is the possible chance that whatever is being driven could also alternatively use HTML. I’m looking into this, but make no guarantees.

As a recap to previous experiments, one of the biggest things that became very clear from feedback was that the address bar isn’t going away and I’m not going to hide it. I was a sad panda, but there are important things the address bar provides which I just couldn’t work around. Luckily, I found some ways to improve upon the existing address bar ideology via aggressive use of extensions, and slightly different usage compared to how contemporary browsers embed extensions into the input field – so lets take a look at the current designs;

tabsOnSide tabsOnBottom
By default, Fiber will have either “Tabs on Side” or “Tabs on Bottom”; this hasn’t been decided yet, but there will also have a “Tabs on Top” option (which I have decided will not be default for a few reasons). Gone is the search box as it was in previous attempts – replaced with a proper address bar which I’m calling “Multitool” – and here’s more about it why I’m a little excited;

Multitool

Fiber is going to be an extensions-based browser. Almost everything will be an extension, from basic navigational elements (back, forward), to the bookmarks system – and all will either disable-able or replaceable. This means every button, every option, every utility will be configurable. I’ve studied how other browsers embed extensions in the address bar, and none of them really integrate with it in a meaningful and clearly defined way. Multitool is instead getting a well-defined interface for extensions which make use of the bar;

Extensions which have searchable or traversable content will be candidates for extending into the Multitool, which includes URL entry, search, history, bookmarks, downloads, and other things. Since these are extensions with a well-defined API you will be able to ruthlessly configure what you want or don’t want to show up, and only the URL entry will be set in stone. Multitool extensions will have 3 modes which you can pick from: background, button, and separate.

Background extensions will simply provide additional results when typing into the address bar. By default, this will be the behaviours of things like current tabs, history, and shortcut-enabled search. Button extensions in mutitool will provide a clickable option which will take over the Multitool when clicked, offering a focused text input and an optional QML-based “home popout”. Lastly, “separateextensions will split the text input offering something similar to a separate text widget – only integrated into the address bar.

The modes and buttons will be easily configurable, and so you can choose to have extensions simply be active in the background, or you could turn on the buttons, or disable them entirely. Think of this as applying KRunner logic to a browser address bar, only with the additional ability to perform “focused searches”.bookmarkshome

Shown on the right side of the Multitool are the two extensions with dedicated buttons; bookmarks and search, which will be the default rollout. When you click on those embedded buttons they will take over the address bar and you may begin your search. These tools will also be able to specify an optional QML file for their “home” popout. For example the Bookmarks home popout could be a speed-dial UI, History could be a time-machine-esque scrollthrough. Seen above is a speed dial popout. With Bookmarks and Search being in button mode by default, just about everything else that performs local searches will be in “background mode”, except keyword-based searches which will be enabled – but will require configuration. Generally, the address portion of Multitool will NOT out-of-box beam what you type to a 3rd party, but the search extension will. I have not selected search providers.

We also get a two-for-one deal for fast filtering, since the user is already aware they have clicked on a text entry. Once you pick a selection from a focused search or cancel, the bar will snap back into address mode. If you hit “enter” while doing a focused search, it will simply open a tab with the results of that search.

Aside from buttons, all the protocol and security information relevant to the page (the highlighted areas on the left) will also be extension-driven. Ideally, this will let you highly customise what warnings you get, and will also let extensions tie any content-altering behaviour into proper warnings. For example, the ad-blocker may broadcast the number of zapped ads. When clicked the extensions will us QML-driven popouts.

Finally, the address itself (and any focused extension searches) will have extension-driven syntax highlighting. Right now I’m thinking of using a monospace font so we can drive things like bold fonts without offsetting text.

Tabs

Tab placement was a big deal to people; some loved the single-row approach, others wanted a more traditional layout. The solution to the commotion was the fact that there isn’t a single solution. Tabs will have previews and simple information (as seen in the previous round of designs), so by default tabs will be on the bottom or side so the previews don’t obstruct unnecessary amounts of UI.

tabsontop

Fiber will have 3 tabbing options; Tabs on top, tabs on bottom, and tabs on side. When tabs are “on side” it will reduce the UI to one toolbar and place the tabs on the same row as the Multitool, and should also trigger a “compressed” layout for Multitool as well.

There will be the usual “app tab” support of pinning tabs, but not shown here will be tab-extensions. Tab extensions will behave like either app tabs or traditional tabs, and will be QML-powered pages from extensions. These special tabs will also be home-screen or new-tab options, and that is, largely, their purpose; but clever developers may find a use in having extension-based pages.

Tabs can also embed simple toggle-buttons, as usual, powered by extensions. Main candidates for these will be mute buttons or reader-mode buttons. There won’t be much to these buttons, but they will be content-sensitive and extensions will be required to provide the logic for when these buttons should be shown. For example, “reader mode” won’t be shown on pages without articles, and “mute” won’t be shown on pages without sound.

Current Progress

The current focus in Fiber is Profiles, Manifest files, and startup. Profiles will be the same as Firefox profiles, where you can have separate profiles with separate configurations. When in an activities-enabled environment, Fiber Profiles will attempt to keep in sync with the current activity – otherwise they will fall back to having users open a profile tool.

The manifest files are a big deal, since they define how extensions will interact with the browser. Fiber manifest files were origionally based on a slimmed down Chrome manifest with more “Qt-ish” syntax (like CamelCase); but with the more extensive extension plans and placement options there’s more going on with interaction points. There’s a decent manifest class, and it provides a reliable interface to read from, including things like providing missing defaults and offering some debugging info which will be used in Fibers extension development tools.I’m using DBus for Fiber to check a few things on startup; Fiber will be a “kind of” single-instance application, but individual profiles will be separate processes. DBus is being used to speak with running instances to figure out what it should do. The idea behind this setup is to keep instances on separate activities from spiking eachother, but to still allow the easier communication between windows of a single instance – this should help things like tab dragging between windows immensely. It also gives the benefit that you could run “unstable” extensions in a separate instance, which will be good for development purposes.I wish I could say development is going quickly, but right now my time is a bit crunched; either way things are going smoothly, and I’d rather be slow and steady than fast and sloppy.Development builds will be released in the future (still a long ways away) which I’ll be calling “Copper” builds. Copper builds will mostly be a rough and dirty way for me to test UI, and will not be stable or robust browsers. Mostly, it’ll be for the purpose of identifying annoying UI patterns and nipping them before they get written into extensions.

Advertisements

34 thoughts on “Fiber UI Experiments – Conclusion?

  1. Any one contemplating/following this development, must really keep abreast of the Vivaldi Releases,
    as Lots/Many, of the requests will follow in the same way.
    Accept that ‘most’ of the concepts have already been established, it is how they are compiled within
    the Browser Engine, where the Magic exists.

    Like

  2. I think that a good option could be have tabs, and when I click on a tab, change/opens/expand a textbox for input uri or something to search in the same place of the textbox (maybe expanded), and when I press intro or click on “go”, change/close/reduce the textbox to the tab (how originally was)
    I hope I transmit my idea.

    Like

  3. I’m a QT developer, do you have any interest in open sourcing it and getting some help developing it? I’d love to help out.

    Like

    1. This will definitely be an open-source project, and the code is already marked for LGPLv3.

      For source code release I’m waiting to hit the first milestone, which is just finishing the blueprint I laid out for the bare-bones stuff. The blueprint gets to the point of launching Fiber with one core extension running, one user-defined extension running, a primitive “console” API, and all the basic faculties between launching the profile manager through looking at a WebEngine to get there. I’m just talking ‘hello world’ stuff, but I’m not taking short-cuts so I’m adding plumbing for things like extension permissions, etc.

      When that’s done I’ll be putting the source onto a repo, and I’d happily take you up on any help you’re willing to provide. Yourself and a couple others have already expressed interest. When this point comes I’ll attempt to woo as many developers as I can get. I can email you when that time comes if you’d like, but it’s still a little while off.

      The big things will be designing and fleshing out the first APIs, expanding the UI hooks, and writing the first extensions. The goal will be to get something roughly as capable as the QtNanoBrowser, but with UI hooks, bookmarks, history, basic navigation, and search all running through extensions – at which point it should be good enough to put a “0.0.1”. I would like the UI to be somewhat close to the target renders.

      At the “0.0.1” mark I’ll put up a simple website aimed at developers. We’ll also start determining what APIs are stable, and provide online documentation while discouraging use of unstable APIs. Additionally, I’d like to put up a dead-simple extensions page where authors can submit extensions.

      From there, it’s mostly going to be round-table discussions about how the APIs should work, getting feedback, fleshing out a wider array of modules, and preparing for a 1.0.0 release aimed for public consumption.

      Like

  4. A sidebar for tabs is definitely something people like once they use it. There was a discussion about this on Hacker News a while ago. Most websites need only part of the horizontal space anyway. Whereas the vertical space is much more precious (smaller means less content and all screens are already less high then wide).

    Do not just copy the ui other use only because they do so for 10 years already. All our mobiles would still have keyboards if Steve Jobs had not decided there was better way 😉

    I currently use extensions that allow the full vertical space for viewing websites.

    Like

  5. I have been following the newly evolving Vivaldi Browser, and I can assure AGUI that there is
    a LOT of dissatisfaction with most/all, current Browsers; Do your homework, and you will
    discover just how Resource Hungry the Chromium/Blink based, Browsers are.
    Security and added Proprietary Software, seriously concerns MANY users.
    KVER, I would pledge you to continue, even solicit help if needs, for in some respects, you
    seem to be a bit of a visionary, and for THAT reason you should complete your Project.

    Like

    1. To answer your comment as you are naming me directly: Fiber will not have its own web engine but will be built on top of an existing one (QtWebEngine I guess), so it will be as resource hungry as any other. I don’t say there is no need for innovation in the browser space, I say that Kver on his own (and even if a lot of developers from the KDE community join him) will never be able to compete with the teams developing Chrome and Firefox. As good as Fiber might be, it will always have to catch up on functionalities with the big ones. And even if it is really innovative and bring a real improvement compared to Firefox and Chrome on a few specific features, a lot of people will stick to their current browser because it lacks some other features. There are a lot of KDE applications where design work is needed, and it would benefit every Plasma users. I am afraid Fiber will be used only by a niche. But again, I respect Kver’s right to work on whatever pleases him, and I would be happy to be proven wrong about Fiber’s fate.

      Like

      1. Why do you think that the QtWebEngine will ALSO be Resource Hungry?
        From my experience with QupZilla, that is certainly not the case; And what do you perceive to be
        the existing Browsers; Opera, Chrome & Firefox? Well, follow the newly evolving Vivaldi, and you
        will then realise that there exists a NEED for a Good Browser, which performs as well as the Opera12.xx, many of its features, still requested by many users.

        Like

        1. I just wish it is not based on qt webkit. It just takes away all the potential out of an otherwise very planned effort. Anthing except it, gecko or even blink should do it.

          Like

    1. A big goal will be keeping on the cutting-edge of KDE technologies, which would include DWDs in some form when they are eventually fleshed out.
      I’ll need to see how the specification evolves to know how it may be used.
      The extension-based widgets will be incompatible with the DWD specification, but the tab bar is rigidly defined and would be the candidate for DWD implementation. In this case the options for tabs would be “system tabs”, “tabs on top”, “tabs on bottom”, and “tabs on side” for a DWD-enabled environment – with “system tabs” becoming the new default.
      Extensions would need a specific API to offer DWD-oriented controls.

      Like

  6. ¿What about if you let an omnibar on top and a bottom bar like icon task only for managing tabs like apps? In that case you can pin webs, group similars, and show an indicator for opened web pages.

    Like

    1. With the current plan (as I understand your question – sorry if I miss the mark) I think I’ve already got you covered. For an Omnibar, if you want search and bookmarks integrated into the address bar, you would simply set them to run in “background mode”. Thomas has already brought up web shortcuts, and I already plan to offer that as part of a search extension. I’ll probably run web shortcuts as a protocol-like syntax, such as “gg:my search terms” or “ddg:foo bar baz”.
      For web apps, those will be handled in the tab bar; in the designs you can see I have “Google Drive” set as a web-app. Also, extensions could offer app tabs as well; for example it might be neat to offer RSS as a page you could just go to.
      Although it’s not shown here, I’m looking into tab grouping, and how that might be treated/run. I’m one of those people who will launch 13+ tabs in a single shot, so it’s important to me personally to have some form of organisation, preferably one that can be ‘smart’. But I make no guarantees, tab grouping is currently just an idea – I have a lot to handle first.
      I hope I answered your question!

      Like

  7. Tabs definitely above the addressbar.

    The IE7 main problem was that the tabs were on left. Your addressbar was small and you couldn’t have more than 2-3 tabs open before they were crushed together.

    The tabs below addressbar and controls is the main UX problem that Google fixed well, there is good presentations from that how it is simpler to understand how address and controls are per content (per page) instead changing just randomly based tabs.

    What I would take is something like this:

    Tabs are at center (thanks to Breeze style) and above address bar.

    Like

    1. The main reason I’m going “tabs on bottom” or “tabs on side” by default is because hovering over tabs will show thumbnails. My reasoning here is that the previews will cover the browser UI which could be annoying if you’re a sloppy mouser, especially if interaction points are put into the preview popout. There will be the popouts from the various toolbar items, but since those are click-activated there’s less chance that you’ll cover desired UI by accident.
      This is still a debate I’m having, but I’m ultimately going to lean towards whatever “casual users” might prefer. I’ll eventually run a poll or survey later when the capabilities of Fiber are more firmly cemented to gauge how I should roll out defaults.

      Like

      1. I don’t think that that is a good reason to use inferior tabs on bottom/side. I used to use an extension with Firefox that would show previews with tabs. Edge also does it and it is not a problem. You simply are not looking at other parts of the UI when hovering over tabs.

        Tabs should be on the top and in the title bar (“system tabs” with DWDs as you have described them) for several reasons:
        1. This saves precious vertical space.
        2. Tabs at the top screen edge of a maximized window are extremely easy to switch between swiftly on most desktop layouts due to there being an “infinte” edge there where the mouse pointer can travel no further. (i.e. Fitt’s Law – you only have to care about moving your pointer to the left and right and don’t have to care about vertical position).
        3. Logically the back and forward buttons only apply to the current tab. Placing tabs on the bottom will imply that back and forward actions apply to all tabs.
        4. The potential for web applications drawing their own UI is better with tabs on top. See https://blog.mozilla.org/faaborg/2010/06/24/why-tabs-are-on-top-in-firefox-4/ for old Mozilla conceptual designs from Alex Faaborg (he left Mozilla when IMO they had good UI design prior to Firefox’s “Australis” disaster, and now works on Android).

        Like

  8. A lot of your ideas are really interesting, but the amount of work necessary to achieve such design seems to me tremendous. For sure if you develop it on your own it would take you years to get to that result.

    In my opinion, the browser is a type of software very different from the others. The market is already well covered with Firefox, Chrome and Opera. It would be nice to have a browser well integrated in Plasma, but I think even if you make an awesome one, most people will stick to one of the big ones, because it will be very difficult to reach the same amount of features and they are also available on their phone, tablet, and on other operating systems.

    Making an extensible browser is a good idea, and you seem to want to push the concept even further than the competition, but even Microsoft chose to make its browser compatible with Chrome and Firefox extensions as they were aware that they wouldn’t be able to attract enough extension developers with a specific format.

    I apologise if I sound too critical of your idea and you are absolutely free to spend your time on whatever pleases you. At the same time, I think a browser compatible with existing extensions while well integrated with Plasma (but maybe less innovative and ambitious) would have more chances to be used by a higher share of Plasma users, and would leave you time for enabling other KDE software to benefit from your talent.

    Like

    1. Totally agree. I am more user than developer for KDE. As a KDE fan I regret a lot that I had to stop using rekonq because it did not hold up with others like chrome and firefox. For this decision it wasn’t very relevant that these had more features through extensions. I would prefer one which is well integrated even if it has only basic features. Crucial for a browser are stability, speed and quality of the page rendering. I think that KDE can only succeed in the competition with other browsers if components are reused heavily. Nevertheless I appreciate a lot that not everyone has given up on KDE browsers.

      Like

      1. This is a huge issue, and there’s been a lot to consider about what I should do. It’s not an easy set of choices (what will I base my work on, why am I doing this work, why not use existing browsers, what is the long-term plan?)
        I fully expect it to be a year before a functional browser is in peoples hands; I’m not even saying a good or complete browser – I’m just saying a browser which you can reasonably expect to open and browse the web with.
        I had considered simply replicating the Chrome API for compatibility, but after a debate and pro/con list I realised that implementing Chrome extensions would too rigidly lock me into a Chrome-style browser. It doesn’t allow anything “unique” to come to the table, and it doesn’t take any advantage of Qt in a meaningful way. There’s no QML in Chrome, and Chrome doesn’t allow plugins to overhaul how you may want to use your browser. There’s no value proposition there, no identity, and if I disagree with an implementation I don’t have choices.

        There is the concern that Fiber will wind up like Rekonq; unmaintained or ‘stuck’ on old tech. That’s my fear, and it’s also my motivation for making “everything an extension”.

        When you have a hardcoded browser like Rekonq, it requires developers to have much more investment in the project and repositories; to make the smallest change you need to download the source, change it, successfully compile it, and submit the patch. If the maintainer is asleep at the wheel that patch may never see the light of day anyway.
        When everything is extensions, it changes things enough to justify creating a whole new browser. It’s actually super-easy to toy around with them. Just open up the extension, modify it, and zip it back up. Done. Moving parts are fewer, and individual extensions are more contained. When you have examples it’s even easier and the entire browser will be the examples.
        Probably the biggest upside is the fact that, at its core, Fiber will be 90% API and only 10% functionality. Just enough to get extensions going. When QT++ comes out, or if WebEngine is replaced, it’s hopefully going to be far less damaging to the project because the functionality is abstracted from the underlying system. Only major changes to QML will break plugins reliant on it, and I’ve already set compatibility guidelines internally to cover that scenario. It will just be the job of Fiber to connect extensions to the system and web engine.

        That’s why I believe this project will have more survivability; because the browser itself won’t have much to it. The march of technology will be less of a concern, because the only thing to port is the API.

        Like

  9. food for thought : what about basing multitool on KRunner? You’d get many things (like online search) for free, plus interesting integration options.
    As for tabs : have you considered using kwin window tabs as a base for tabbing? It turns some design assumptions upside down, but I think it could be very interesting…

    Serafean

    Like

  10. Nice! More competition for Konqui can only be good ;-). As for extensions: may I propose to have a look at the real good work of the QupZilla developers with supporting multiple saved account-password-combinations on website login forms? A key is shown in the address bar where you can choose the account to be filled into the site.

    Oh, and please don’t go the same road as rekonq and kill the menu bar. Dolphin is fine, f.ex.! Hamburger menu by default, easy to switch to a permanent menu bar if the user wants. 🙂

    I’m really looking forward to a native QML based KDE browser. Good luck and thank you!

    Like

  11. I like this new concept of web browser. Great work.
    The only detail that I don’t like too much is the “Back” button bigger than the rest.

    Sorry for my bad English.

    Like

  12. These sound like some really nice and thought-through ideas, great work so far!
    Only two things that came to my mind:
    1. I think there should be another option for tabs placement: In a sidebar. I know users who would never touch a browser that doesn’t support this because they find it so comfortable.
    2. (related): Are there plans to offer Australis-like flexible UI layout at some point? I find that much more useful than just being able to choose between a fixed set of positions for certain UI elements to choose from.

    Like

    1. For the sake of my sanity I’m going to write tabs to be a horizontal strip; but (and I make no promises here) I’ll work towards allowing an extension to take over the tab system. If the tab drawing API is super-easy I might do it – I plan to use custom draw code for fancy reasons – but I won’t make that promise. Unfortunately – without outside contributions – sidebars just aren’t on my priority list. It’ll make sense to have a sidebar extension API, so that’s your light of hope, but I doubt you”ll see vertical tabs unless Qt offers an easy solution.
      But there is good news on flexible UIs in general! When it comes to button placement and toolbars, I’m hoping to have very good customisation. That’s one resounding thing I’ve seen from the feedback – there is no ‘one size fits all’ browser UI, and where I don’t have to hard code it I want this to be as customisable as Firefox used to be.
      At first the browser might not be particularly flexible while I’m trying to get things running in the initial versions, but I plan to use kxmlgui for customisation (of course). Granted, the 4 foundational widgets (address, menu, tabs, and transient status) will be positioned in code for functionality reasons, and to help me optimise layouts for different form-factors as development progresses.

      Liked by 1 person

      1. It would be really cool if the whole plugin system is flexible enough to support something like tree style tabs, where tabs are in a sidebar and hierarchically structured. I’m not touching a browser that doesn’t have similar functionality as I’ve grown to depend on it. That (sadly) means I’m currently stuck using Firefox which is quite horrible on (at least my) KDE.

        Like

        1. Alright, so maybe I’ll elaborate one of of my plans for extensions; Aside from directly adding things to the browser, I’m going to have extensions able to register “services” which they may provide. The idea behind services is to extend core functionality of the system, much in the same way Android allows you to swap the keyboard.
          Now, services are planned to be more of a back-end thing, I haven’t put any thought into services replacing core UI elements. The main difference between a service and anything else is that services will have explicit APIs and will be more likely to break from version to version, since they are much more closely tied to how the browser will work.
          With all that in mind, as I build out the tab API, I will try to keep things separate enough that we could eventually replace the “tab service”, and I’ll see if there’s any chance tabs could be treated as a plugin… I see no reason why it’s not technically possible, but I’ll need to progress more before I know how feasible running tabs as a browser service will be.

          Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s