Glass Elevator, Idea #1 (expanded): Extensions based UI

Here’s an expansion of the idea of extensions for the UI. Basically, you start with a clean UI. I think we can keep BeOS’ default look and behavior for this, because it’s very simple but unique (although certain things should be changed). However, the combination of themes and extensions could set it up so that it can look (and act) like any operation system GUI out there. This would make Haiku the most flexible GUI out there.

The core OS has a default behavior, and extensions add options to that behavior. These options, once installed, would override the default behavior. Deciding which behavior should be built-in and which behavior should be available as an extension should be determined with the following questions:

  1. Does this feature create no noticable hit to the basic performance of the GUI?

  2. Does this feature add easily recognizable benefits to the end user?

  3. Is this feature within the limits of an accepted end user experiences and does not radically diverge from what most users would expect?

    If you can say ‘Yes’ to all these questions, then you have a UI feature that should be added as default behavior. If you can’t say ‘Yes’ to all of them, then it’s best if this feature is available as an extension.

Here is the first picture, it’s a mockup of the system preferences window. I really like the Apple system preferences for Mac OS X, and the way it cleanly stays within the same windows, so I modelled it after that.

Now, in picture #2, let’s say we downloaded a plug-in which has a series of effects for minimizing and maximizing windows. This creates an option called ‘Window Effects’ to System Preferences->Desktop.

If you click on it, you get the settings for this plug-in, but you don’t necessarily know that it’s a plug-in. It might be good for plugin sections to have like a certain outline or subtlety that differentiates them from built-in system preferences. On the other hand, it might be better to make the whole thing seamless to the end user.

Also note, that the idea is if you clicked on ‘Behavior’ to manage extensions, chose the ‘Minimize/Maximize’ extension, and clicked ‘Configure’, it would take you to the same window.

Now in the fourth, let’s say that we downloaded another plug-in for drop shadow effects, which also puts it’s configuration in System Preferences->Desktop->Window Effects. These options will show up in the same section where the genie effects are.

So this is what I mean about an extensions based UI. The main obstacles are: How do you create a really clean way to manage a lot of extensions, as some desktops will eventually include. Also, how do you balance security concerns? Keep in mind that users downloading and installing extensions isn’t much different from people downloading utilities like Desktop Manager or Quicksilver. This just streamlines the process.

Also, should extensions use the scripting language, or should they use the Haiku API? Or maybe both? Simple extensions could use a built-in scripting or extension language, and more complex or performance oriented extensions could use the Haiku API.

That’s it for now. I’ve got a whole lot more ideas, so they’ll come with mockups and descriptions in the near future.

Hi, I’m a newbie, but I’d like to explain my idea too.

I think that the implementation of an extension system for UI is something not so easy, and could require developers and many hour of work. On the other side I don’t view many great adavantages for the user experience.

I prefer a MS Windows (and I think OSX too) approach: choose some defined guidelines and follow them. Intruduce some feature, don’t implement others that are not in line with guidelines. This makes a fast, usable and CONSISTENT OS, for user and also, very important, for developers.

The difference between Windows and Haiku is the source availability, so if someone else implements something new and useful, it can be integrated directly in the OS source tree.

And about the question “1. Does this feature create no noticable hit to the basic performance of the GUI?”, I think that if Haiku R2 wants to became one of the next generation OS it must introduce some features (i.e. full text search) that will speed down the system (against R1), and simply let users disable these new features (but set them active by default).

Thats only my idea…

Hiei

Hiei wrote:
Hi, I'm a newbie, but I'd like to explain my idea too.

I think that the implementation of an extension system for UI is something not so easy, and could require developers and many hour of work. On the other side I don’t view many great adavantages for the user experience.

I prefer a MS Windows (and I think OSX too) approach: choose some defined guidelines and follow them. Intruduce some feature, don’t implement others that are not in line with guidelines. This makes a fast, usable and CONSISTENT OS, for user and also, very important, for developers.

The difference between Windows and Haiku is the source availability, so if someone else implements something new and useful, it can be integrated directly in the OS source tree.

And about the question “1. Does this feature create no noticable hit to the basic performance of the GUI?”, I think that if Haiku R2 wants to became one of the next generation OS it must introduce some features (i.e. full text search) that will speed down the system (against R1), and simply let users disable these new features (but set them active by default).

Thats only my idea…

Hiei

I think it would definitely be a lot of work, but I think given Haiku’s design, it’s not an unthinkable task.

I think that people are going to create add-ons and hacks anyways, but if we create an extension architecture, I think it encourages elegancy as opposed to ugly hacks.

And while changes can be added to the source tree, that can add the headache of having to maintain even more code, most of which is not important for the basic functionality of the OS.

An extension architecture also creates a lower barrier to entry for new programmers to modify the OS without having to commit changes to the source tree. This will help a lot to attract programmers to Haiku.

I think that you’re definitely going to have features that will slow things down over the BeOS R5 days on similar hardware, but I don’t think that the GUI should be one of them. I think it’s best to have a very well scalable user interface, which can work smoothly on very old hardware, but still have a lot of cool effects for people who have the muscle to handle it.

One thing to remember about extensions, as I visualize them, is that they deal only with interface, not with functionality. To put it another way, they describe how to do something, not what you can do. It’s up to Haiku to define the functionality, the extension just defines the interface.

I really think that extensions + themes would create an incredibly flexible interface, while keeping the core Haiku lean and mean so that developers could focus on the really important part. Look at firefox, instead of the firefox/mozilla developers having to deal with mouse gestures, mass downloads, bookmark managers, etc., those are all taken care of in extensions.

With extensions, Haiku developers wouldn’t have to care about drop shadows, window effects, transparency, etc., and could focus on the more important stuff. Heck, we could even see really gifted programmers take things in directions we could never imagine.

As far as consistency, it would be a consistant OS, the basic setup would be consistant across everything. Part of the UI guidelines could be that application developers could only assume the basic setup and default behavior, and couldn’t require any specific extension. Then, it’s up to the programmers creating the extensions to create them in a way that doesn’t interfere with the way applications expect the desktop to basically operate.

I realize that this is a unique concept for an OS, but I think that the success of firefox really speaks to the idea of having a clean, simple default interface which can be easily modified and extended in an infinite number of ways.

Michael Chisari
michael.chisari@gmail.com

michael.chisari wrote:
One thing to remember about extensions, as I visualize them, is that they deal only with interface, not with functionality. To put it another way, they describe how to do something, not what you can do. It's up to Haiku to define the functionality, the extension just defines the interface.

I really think that extensions + themes would create an incredibly flexible interface, while keeping the core Haiku lean and mean so that developers could focus on the really important part. Look at firefox, instead of the firefox/mozilla developers having to deal with mouse gestures, mass downloads, bookmark managers, etc., those are all taken care of in extensions.

OK, but firefox extensions deal on functionality (mouse gestures, mass downloads, bookmark managers, etc.), and changes to UI are only a consequence…

Quote:
With extensions, Haiku developers wouldn't have to care about drop shadows, window effects, transparency, etc., and could focus on the more important stuff. Heck, we could even see really gifted programmers take things in directions we could never imagine.

I can’t understand what could be done with an extension system like this; some window transition effects, some kind of shadow effects, and then? The apparence of controls and windows depends on skins, right? Also they doesn’t add controls to windows, icons on toolbars and menù commands because they can’t add functionalities… so what can they do?

Quote:
I realize that this is a unique concept for an OS, but I think that the success of firefox really speaks to the idea of having a clean, simple default interface which can be easily modified and extended in an infinite number of ways.

Here you are talking about firefox extensions, but they add functionalities… I don’t understand…

Hiei

Hiei wrote:

Here you are talking about firefox extensions, but they add functionalities… I don’t understand…

Hiei

You’re right, I didn’t explain that right. It would add functionality, but it would be limited in the kind of functionality it could add. An extension would not be the same as a Haiku application, and would not have the same kind of access to the OS.

I think, anyways. Maybe it would be fine to give extensions almost full access to the OS (they’ll only be installed in userspace, anyways).

The main advantage I see is that it keeps Haiku very flexible for different situations, and different possibilities that will come up in the future, all while not bogging down the developers with having to maintain a huge set of UI configurations and possibilities and options.

michael.chisari wrote:
The main advantage I see is that it keeps Haiku very flexible for different situations, and different possibilities that will come up in the future, all while not bogging down the developers with having to maintain a huge set of UI configurations and possibilities and options.

Now I’ve understand what you are meaning, but create a thing like this is very “expensive”… It will depend on how many “man-power” will be available after R1.

Hiei

Hiei wrote:
Now I've understand what you are meaning, but create a thing like this is very "expensive"... It will depend on how many "man-power" will be available after R1.

Hiei

It might be really expensive. The goal is to design it so it isn’t. Personally, I think that once R1 is released, Haiku is going to get a lot of new developers getting involved. Of course we can’t assume that, but that’s what I suspect.

I’m gonna be taking some time to learn how the app/interface servers work (which is where I would assume an extension architecture would go, unless it would require it’s own server), and try and come up with a proposal.

Michael Chisari
michael.chisari@gmail.com

Interesting concept!
i have two questions though…
1)i would like some examples on this which would prove there are unlimited possibilities for this…
2)these addons should be able to cooperate with each other to avoid any loss of efficiency

I dunno about complexity of this; but im thinking of how much memory it may eat…we all know firefox hogs loads of this…

What i can see as addons would be:
1)Stuff that BeOS missed out in its interface; example the address bar in teh file manager
2)Stuff that connect to internet; am not really too curious though
3)Stuff like pie menus and mouse gestures; which i like a lot and tenfold the efficiency

But im wondering about how far this might be useful in improving the EFFICIENCY. Im not really fan of flashy effects (unless they’re useful; such as the zoom-into-dock of apple is great for visual feedback to end user)

Oh, btw, this is my first post.