From the latest Open BeOS Newsletter: “Imagine this. GUIs designed completely outside of the realm of the application. Something like, say, SoundPlayer, coming with a default interface. You can do more than “make a skin”, you can redesign the whole UI, so long as you send the right messages. Applications basically become servers. The GUI becomes a client. It shouldn’t be too hard to make an add-on to a web browser that could display this hypothetical solution. And, if BMessages could be sent across a network, one could run their apps from anywhere in the world. Imagine that.” What are your throughts on the subject? Discuss.
Dreams of the Perfect UI Platform
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
this would be very nice. It shouldn’t be that difficult. Everything is already event driven. It would require a bit of infrastructure in the os. I have always thought this would be nice.
dan
Image in an application, instead of putting a dial in, you put this UI socket for any control. You simply state that the control must provide a integer between 5 and 100 in incriments of 5. Then the user can say, “I want a slider not a dial”. Another user says, “I want to hook up a volume socket for this app to ALT+UP/DOWN on my keyboard”. Perfect!
… think about how VisualBasic works. You have an app palette, which you can drag and drop control widgets, placing them where you want. With the Generic App/GUI Builder (GAG-B ?
, the editor would load in a list of the controls/inputs that the app expected, and you could have a palette of appropriate widgets that would fit the desired input range that you could drag and drop onto the location you wanted.
If the widgets and inputs all conformed to a standardized set of rules, it would be possible to design all sorts of cool-looking and useful ways to interface with the app.
Interesting …
.. overkill to me. There is something to be said for consistency.
<a href=”http://www.berlin-consortium.org“>Berlin does a lot of this. It’s vector based, too.
How do you know what’s a config setting and a play button? How do you tell the workflow of the app. For instance, an installer needs to know where to install before you can do an install.
You will need *lots* of metadata about the controls, and that will make making good / easy configured apps harder to make. Basically you will just give the user a halfdone app and tell em ‘You finish it’.
How many make did I put in that message?
>There is something to be said for consistency.
This could allow the user to make all his apps consistent. Even on MacOS, the apps all behave quite differently.
It somehow reminds me good ol X Windows. At least concept is the same.
This would break up any sort of UI consistency we could ever hope for. It’s bad enough as it is, even on fairly regulated platforms like windows. And, really, ask yourself just how often you expect to be running apps on another machine with the gui on yours. And if you say “why, all the time” then set up X11. It’s been doing that for years. And if you say “why, X11’s a big nasty mess” then you’d be right, but that’s why projects like GNOME & KDE exist.
My feeling? Don’t reinvent the wheel. Especially if you don’t need that particular wheel in the first place.
this is sort f like what jabber does, except it is a protocol not a server.
you can make a UI for it and still have full communication with every other jabber client out there……the only think is that you have to program the button functions and such….so……………nevermind 🙂
Sounds great! Take the concept of stdin and stdout, and apply it to every aspect of a gui app. I would like it more dynamic than just designing a new GUI for an app, but allow the user to plug output to any input. There would have to be a means to check that the plug fits the socket, but a simple tool to create a filter would work. Here’s an example:
You like to usr your computer to answe your phone, but you alwase have one mp3 or another blasting away. Rather than first turning the volume on the mp3 player down then clicking on the button to answer the phone, you reconnect the “AnswerPhone” button to a “filter” you make to first send a signal to the mp3 player to lower the volume (or pause) then pass the “AnswerPhone” signal on to the waiting port on the phone tool. When the “HangUp” signal is sent, mp3 player responds be returning to it’s good old blairing self. Neither app needs to specifically support this functionality, just allow dynamic redirection of their signals and listen for incomming signals.
This dynamic nature would have to be implemented in the OS os windowing system. A button along the title bar that exposes all known signals and slots (Qt terminology there) and allows you to drag and drop them to others. If the signal doesn’t fit the slot, create a filter to convert the singnal to the correct type, which can be cousomized by the user.
Would this lead to half-done apps with no GUI’s? No. You would still build your own GUI, maybe even a couple if you want. Let the user build their own or choose one that follows their desktop theam. Let users control functionality any way they want. That would be great!
This would not make an app any harder to use for the user, there would be the default GUI to use if the user wants consistancy. For the developer it would mean adding a bit of metadata (or alot, depending on the interface). Metadata would only be needed for dynamic redirection and alteration of signals to slots between apps.
Hmm. Security concern. How do you verify the password you are typing in is really going where you want? Downloading a different GUI for an app off the internet could be dangerous.
I still like the idea. I’ve liked it for a long time.
A GUI that caters to the technically inclined instead of protecting itself from the lowest common denominator. 
“Something like, say, SoundPlayer, coming with a default interface. You can do more than “make a skin”, you can redesign the whole UI, so long as you send the right messages.”
You can already do this with Athene. In fact, it was specifically designed to do this. It separates the interface from the application by forcing the developer to code the guts of the application in a standard language, while the interface itself is defined in an interface script (using DML). If you don’t like the developer’s interface, you can create a new one from scratch, or modify the existing one if you only want to make minor changes to it.
Of course it doesn’t stop there as you can also write your very own OS interface too. If that’s your idea of a dream GUI then hey, look no further 🙂
>A GUI that caters to the technically inclined instead of protecting itself from the lowest common denominator.
While I agree with your other comments, this one I whole-heartedly do not. Why would anyone want to cater to such a small percentage of the population? I believe that power != difficulty. Instead, I would like to see an interface that “scales” to the user. Take for example Artisan in Maya. It has such an intuitive interface, yet it is so powerful. It is easily handled by even my mother (a complete technophobe), and yet it has the power that someone more technically inclined wants. If you want more features, use the built-in scripting language Melscript. I sincerely believe that if an interface doesn’t scale to the user, it hasn’t been thought out well enough.
Kinda sounds like a “visual dynamic piping” system to me. Wasn’t there an article on Slashdot about a group already doing such a project? It was called Pigeon some other bird, I think.
I don’t like skins, The only program I use with a skin is powerdvd
because the default one is really really ugly.
But I prefer a clean default interface like mediaplayer on beos 🙂
mediaplayer in windows is getting uglier with every release…
<p>No, I don’t believe such an idea would break UI consistancy–I think if anything this would increase consistancy–well, assuming the end user cannot ‘find’ any low level config. (good god–the average user shouldn’t be allowed to choose what their gui looks like — we’ve all seen the 35X70 pixel images which have been stretched the size of the desktop simply because people don’t ‘know’ any better)–but, I think this ‘idea’ is a good idea–(assuming I know what I’m talking about)
<p>You see this is one good thing about windows–its gui consistent. (for the most part) The reason GUI stuff isn’t consistent on X is because developers cannot seem to sit down and agree on things. Open Source is a breeding ground for “splinter projects”. Which by the way–I think this is the Open Source community’s biggest flaw–nobody wants to comprimise.
What about mozilla’s XUL? I’m under the impression that a GUI specified as a XUL file can be reconfigured in all the ways the BeOS newsletter talks about.
Half of your vision (the univerally skinnable app framework) is realized in Mac OS X, and has been around since NextStep 1.0. While some Carbon programs are still hardcoded, most Mac OS X (and NeXTSTEP/OpenStep) apps have a GUI built using InterfaceBuilder, which outputs .NIB files. The spec for the UI comes along in the app bundle in the original form- it’s not compiled to a locked resource format. Anyone, end user or the app’s developer, can edit the UI as she wills.
For example, if you have Mac OS X, use InterfaceBuilder to open /Applications/Calculator.app/Contents/Resources/English.lproj/Calculat or.nib. Change some stuff around- colors and placement of calculator buttons perhaps. Save. Then run Calculator again- notice all of your changes have been made, with no programming at all.
X is not an opensource project. If you think it is, you dont know much. http://www.x.org try to get sources to X from there. X Free86 is an open source X compatible Window System. XF86 != X. They are mearly compatible. There are other X projects too, like Accelerated-X and others. There is also nano-X whose goal is to create a X-like (but not 100% compatible) Window System for machines with less memory (like embeded devices). You can run nano-X on your desktop machine too. X is quite possibly the most “message” oriented Window System out there. Every application is a client, and the local machine runs a server. The server sends messages (such as keypresses and whatnot), and the client in turn sends messages back to be able to draw the contents of its window.
I dont think its a waste of time ttyring to get remote applications going on a local system. I run my laptop’s X session off my “server” and so it can run the apps as fast as the server can, just at a lower res and color depth.
This would involve metadata to group UI elements into predetermined categories that would then be themed (placement, colour etc.). No UI has this kind of grouping to any granular level.
It would suit Mozilla’s XUL more than anything. Infact it could be implemented with other grouping tags and then 3rd party software rearranges them accordingly. I have messed a bit with XUL and believe this is quite possible.
Deciding the categories is the main bitch. Any ideas?
http://dpu.porosky.com/features/monthly/default.asp?article=7“ http://dpu.porosky.com/features/monthly/default.asp?article=7</a… – doesn’t deal directly with the themeing and skinning parts of this discussion, but touches on a potential future of the client/server side of things. i think. IMHO.
seu bando de chapados !!!!
The problem is that everyone is hooked into this separate application, separate UI thing. Is there a reason that applications have to deal with UI code more than just to state each command or view’s control preference? If someone created a GUI framework with a set of programmable controls that allowed those controls to be used independently of most of the other application controls, then a user could visually build a complete interface for every actual action they perform with their general purpose computing system.
For instance, one could code an mp3 player application with no user interface code at all. The idea being that it could just have an interface specification in the code that told the UI engine what each function needed for input. Each command could be linked in the UI engine to a specified button, dialog, hotkey,etc. With a little intelligent behavior from the UI engine, like asking what the user wants to have happen when the user does something unexpected and learning from it, this idea could work out quite nicely.
Basically, the application would just export an interface to the UI engine. It could suggest a default layout to the UI engine, but the UI engine would allow the user to dynamically modify the controls and their layout. Controls from different applications could be combined into a work theme that was appropriate for that individuals usage of several different application’s functionality.
As far as application installation goes, why not standardize that as well? The UI engine, being the main interface to the computer, should handle application placement and should allow for application specific scripting of important installation details. Installshield works pretty well, and most people just hit Enter through all of the screens anyway. Why is that not a part of the OS? The browser is…
The argument basically boils down to putting the functionality where it belongs. The application programmers should be responsible for coding the guts of the application and providing an interface for the OS to interact with the application. On the other end the OS should provide a way for users to easily install and manipulate their own interface to their available applications.
Just my $0.1010101010101010101010101010101010101010101010101010101010101010
It makes me really happy to know that the people working on the OpenBeOS project are approaching their work with imagination instead of just dogmatically attempting to reconstruct the OS as they know it.
Vision is a wonderful thing. I hope theirs takes them far.
Best of luck to you.
PS- make a PPC G3 port!! ;]
Miami on AmigaOS did exactly this — you could install a ‘MUI’ interface or a ‘Gadgtools’ interface, both completely different in look and feel but both interfacing with the underlying Miami program in the same way…
Bah, that’s ‘Gadtools’
I have to disagree with this entire thread – the biggest problem with Linux, in my very humble opinion, is that everyone’s Linux is different. While the internals of the system should be able to change, the visual part should only be partially customizeable – only in the sense that if you are a pro at one OS, you should be able to sit down at ANY computer running the OS and be a pro. By breaking all sections of an OS into many tiny pieces, it leaves too much to change and too little consistency. That means support is a nightmare. And that means you’re doomed to obscurity from the start.
Those’re just my thoughts as a non-programmer who probably wouldn’t utilize these functions anyway.
A bit of topic but anyway.
First of all I’m not a programmer but a flash-designer so don’t shoot me if what I suggest makes no sense.
Because of my experience with flash, I started to appreciate vectorbased images. These are resolution independent and not pixel based. For those who do not know the difference, simply said if you draw a red circle only the radius and the colour will be used to draw it, so when you scale it you simply recreate the circle with a different radius. Advantage number one extreme small filesizes number two very sharp images regardless their size. That’s why flash is so cool you can make animations of a few kb which can be enlarged without increasing the filesize.
Ok so what’s my point here, suppose you create a vectorbased gui, it would be extremely lightweight & resolution independent. The icons, toolbars, menus, buttons could be stretched or deformed to any size to fit everyone’s needs. You could have animated backgrounds of just a few Kb.
Maybe this doesn’t make sense, but it was just a thought from a designers perspective
BeAdingo, I’d go SVG if I were to build a vector-based GUI. The application programmer would build his app’s interface by hooking SVG message events to an event/message listener on the app core, and the OS would provide some mechanism to allow this kind of communication.
I really think UI consistency is not important at all; every application should expose its functions and capabilities in an obvious way. It’s all about having a logic, easy to use interface, and not conformance to some clumsy standard. Free unix clones suffer from this UI problem not because they lack consistency, but because they are obtrusive. I always thought GUIs should be designed by artists, not pizza-and-beer-powered programmers =)
Don’t get me wrong, I’m a CS student.
About being able to change any aspect of a given app’s UI, I think this is kind of what Replicants were all about, as they let you customize your application by melting other app’s functionality into a single (and hopefully consistent [read logically and intuitively organized, these concepts are sor of universal IMHO]) window. This is a different approach to a similar concept, only in another level of scope.
I hope I made myself clear, English is not my mother language =)
SVG has many strange/stupid? restrictions and sometimes weird syntax which would be a hazzle to every developer making a GUI. It would really increase the complexity of a HelloWorld GUI-app.
We’re supposed to make things SIMPLER not more complex.
How many CLI applications have a GUI front end? Is this not a good idea? What would be so wrong with a CLI based mp3 player that accepted basic commands? Make a GUI that when you click on a button it executes “mp3player -play”, or have it listen on a socket or use Hey to send a BMessage or whatever. What about a GUI that sends an HTTP request to a BIYS server, something like “http://biys/command.php?command=play“?
I think that this is a great idea and wouldn’t break application consistency unless the user chose to change the skin themselves or if the creator never created a standard skin.
A technology similar to this vision already exists and is part of the upcoming version, 0.17, of the X window manager Enlightenment.
The technology is called Ebits and can be found on this URL:
http://www.enlightenment.org/pages/ebits.html
Berlin is a vector-based ui with a highlevel semantic language. See http://berlin.sourceforge.net“>berlin.sourceforge.net… this” rel=”nofollow”>http://www.linuxpower.org/display.php?id=207″>this interview for an intro to the main UI advantages of Berlin.
You’ve already said this. I don’t want to appear rude, but I hope people won’t turn this forum into something “/.”-like featuring ie repetative advertisement (one time is enlightening – two+ times is ad’ing imo)
regards
1) Name those restrictions, please. I really am curious, no kidding.
2) SVG is my “model” because it’s an open, free format, and quite usable. Of course, you could create some custom format based on SVG or whatever, but I think this is a waste of time. SVG will evolve, and will evolve as a standard. This is important IMHO.
3) This said, I find SVG very well suited for this UI creation task. Open, well-documented enough be implemented by anyone interested (GUI builder, for instance, or even the standard graphic authoring packages, see below), and already comes with Javascript-style messaging/events.
4) SVG was NEVER meant to be edited by hand. Its internals are to be handled by graphic authoring programs, like the one from JASC (forgot its name =P) or Adobe Illustrator. Like I said, GUIs should be built by artists =)
(And I quite got that feeling from Mac OS X’s interface. Piece of art. Granted, it’s still full of bitmapped images, but it fully supports vector images because of its PS/PDF roots)
Another thing I’d I’d like to mention: I hope Berlin succeeds; I think it’s very well designed. I only hope it’s not tightly bound to unix internals, so it can be ported/implemented on top of other OSs, like OS/2 or OBOS (yes, I’d like to see some sort of “eye-candy Tracker”, but always keeping the “classic” Tracker for maximum responsiveness for those who find it absolutely necessary)
I heard once that the GUI takes up 80% of development time.
In my experience this is correct. The reason for it is the numerous interactions that are possible, the high number of states this causes and the effects that an interaction can have back on the GUI.
I agree that separating GUI and logic is a good idea, and this sounds like a reasonable way to make applications run remotely easily.
However, to believe that users will be able to create their own GUIs based on a simple interface is, IMHO, a foolhardy idea. A good rule of thumb with GUIs is to restrict options for the user – it makes things simple for them and simple for the developer. To allow for a generic interface is likely to cause extremely large problems in development – it is likely to be very hard to determine what combinations of interactions are possible.
Often the GUI is used to enforce logic. For instance, user can enter data into field A or field B. If they enter in A, field B becomes disabled, delete data in A, and B becomes enabled. Not being able to rely on these mechanisms would result in more complex validation code for the entered data, ok, fine, but where to put the focus when validation fails?
Specifying this information in an interface spec is going to be more work than developing the GUI, in my opinion.
An option (that someone mentioned) is to create UI slots where widgets can be entered, which is very similar to a skins approach.
The biggest problem you mentioned yourself: ‘SVG was NEVER meant to be edited by hand. Its internals are to be handled by graphic authoring programs, like the one from JASC (forgot its name =P) or Adobe Illustrator. Like I said, GUIs should be built by artists =)’
I (and many developers with me) want to do GUI’s on our own. SVGs ‘internals’ as you called it is far to complex and messy for a small/single/… developer to handle. If you restrict GUI design to artists there will be very few apps.
Webdraw (JASC) and other SVG apps treats documents different (currently), so switching from one app to another is a pain in the ass, xml-structures are trashed / handled differently. GUI-code bloat will be inevitable, SVG-apps like to add their own stuff, but usually don’t do removal very nicely.
You will also be forced to tweak somethings by hand if you:
a) want really fast drawing
b) squash that last GUI bug
c) the SVG-app has a different opinion than you.
Also SVG-apps like to add little ‘features’ of their own, so what might look good in Adobes app sucks on Webdraw etc.
But that’s just ONE problem why I wouldn’t use it.
Internally I might consider using SVG. You could transform to SVG from a more GUI-like language.
This is all my (not so) humble opinion.
would rule though.
Three words:
“It will evolve”.
Being a standard, SVG will eventually be well-supported by those misbehaving apps if they’re intending to be competitive.
Look what happened to Microsoft: they tried to introduce their own extensions to HTML back in the HTML3.x days, and falied miserably (<blink>, <markee>). The industry is, more than ever, supporting *open* *standards*.
Someday in the near future I’ll try to accomplish my own ideas and build a SVG-based-GUI-app (wow, dashes =). Hopefully in the next 4 years =D!
Now the comments blink. I agree that should use standards whenever possible, but sometimes things need to be simple and elegant. Especially when it is users who is gonna use the result.
I am SO sorry! I inserted the <blink> and <marquee> tags as examples of M$s idioticity…
Mozilla (and probably IE) are showing the blinking stuff also. I had no intention =P
Eew. Eew. I am absolutely disgusted. I am sorry. I really am.