Guest post by How would I describe today’s GUIs? A mess. — A mess that grew as new features were needed, with lack of proper design, with a desire to keep backward compatibility, and with tools from the past trying to achieve future needs. I propose a new design philosophy for GUIs. We’ll call it Vermaden’s GUI. Note: This is the latest entry in our 2008 article contest.
At the beginning they were designed, but as time passed by they just grew. Most of today’s GUIs use a grid of dots on which other GUI elements are placed: menus, buttons, lists, draw areas, folder lists and everything that you can imagine. Today’s GUIs, such as GTK or QT toolkits can do almost everything we could want from a classic GUI — the problem is how all our wishes are realized under the hood of the interface. Speaking precisely, lots of different types of content, different combo boxes, different margins, borders … Many widgets have a scrollbar included, some need external placing of the scrollbar, or even two of them if we also need to scroll horizontally, like Anjuta’s IDE GUI for example, some scrollbars are outside widget content, some are placed inside content.
Anjuta IDE |
Anjuta IDE Created with Separators |
Displaying a lack of unification, today’s GUIs are not coherent. They are like a big bag of tricks that try to get the job done. The Nautilus File Manager, which, similarily to Anjuta, uses the GTK toolkit, “prefers” putting scrollbars inside widget content area, where Anjuta puts them outside. Some of you may say “what about QT?” Well, things are not better here; let me tell you why with Konqueror as an example: a widget with folders on the right has a border, a tab with that widget also has border, which also includes a status bar in the bottom part of the window … again with the border, don’t you think that there are too many borders around there? Well, you are not alone. It’s big waste of space and functionality (which border would you like to resize today?), not to mention ergonomics.
Nautilus File Browser |
Konqueror File Manager |
Of all available GUIs today, Apple’s Cocoa used in their flagship operating system Mac OS X is a jack-of-all-trades and looks better and more coherent then the two I just mentioned from the open source world, but it still has quirks in many places. Those quirks are not its major disadvantage though; the license is. It is a proprietary product that you cannot modify or even use without buying the whole Apple computer and even if you do you cannot use it as a GUI on your favorite UNIX system, like FreeBSD for example. You can only watch from a distance.
Apple’s Cocoa in Mac OS X Operating System
Under the Hood
Maybe these are just minor issues with displaying the content, and maybe these GUIs have brilliant design, but I must disappoint you even here, because there are architectural problems with some GUIs. QT for a great bad example, requires that to change your theme you need to compile it (!) among hundreds of libraries, which makes porting it to other operating systems almost impossible. That is why there are many themes for QT/KDE that work reliably only on Linux, where they were created.
GTK is a lot better here, where with a proper display engine installed, Murrine for example, you can have whole theme and colors in one simple gtkrc file. The idea and simplicity is great here, but as I mentioned earlier, GTK suffers from other display problems, like coherence of its GUI widgets.
Speaking in general, some GUIs use absolute positioning, where for example menu goes at x=0 y=0 position, status bar goes to bottom x=0 y=end_of_window, some use boxes for widgets, boxes with borders, or just plain borders, something like “containers” idea, but very limited and no matter how many methods today’s GUIs use, its all about dividing the window space into buttons, menus, status bars and so on. So why not make it the rule of the GUI, the core of the GUI?
I propose creating a whole GUI by separating the available content in a simple, sensible manner, managed by one simple efficient mechanism or algorithm responsible for efficient usage of available window space, responsible for placing all window items. Does that sound interesting?
Divide and Conquer
The central concept of my GUI is separators: one simple mechanism that can be tweaked to perfection without much hassle and time. An application window is nothing more than a small piece of workspace divided into small places with different roles. An example of this with separators used as GUI formatters is a simple window with buttons on top, status bar, small container on the left for list, and of course a place for main content, for example many window managers use a similar setup. To create that window we need just one recurrent function to draw whole GUI skeleton, one simple function.
Example Window Created with Separators
Good Defaults
A well thought-out idea can be ruined because of bad default settings. By default every content that will be placed in any container created by the separators is horizontally and vertically centered, with 1px border of free space between the content and separators, and if the separators are transparent, 0px border between content and separators, but transparent separators themselves serve as 1px borders.
1px Border Between Widgets in Containers
Using this rule there will never be a problem that any of the GUI elements will interfere with each other. As in the image above, these design rules, or should I say defaults, prevent future creators from one of the most common GUI faults: wasting window space with needless borders and margins, doubled borders, big paddings and so on, like 5px margin between content and scrollbar in Anjuta’s IDE.
Sonata with Design Errors |
Sonata Skeleton Created with Separators |
Sonata Created with Separators |
As you can see on image on the right side, Sonata can be easily recreated with separators and containers without losing any functionality. It also leaves a lot of space for options, margins and padding, around text for example, and all widgets are in their place, and, just as with the GTK toolkit, space is just better organized and less exposed to design faults.
So what about those ugly scrollbars that are so hard to place properly? Well it is more simple then you think. Every container has its own scrollbar placed, yes, in right place, and of course it can be turned on or off, or put on any side of the container, maintaining flexibility.
Container with Automatically Added Scrollbar
Graphics
GUIs are about drawing graphics and text on the screen, and in my honest opinion it would be best to keep all configuration and data in XML format. It is a fast and easy to parse language, and many minimalistic window managers use it to store their configuration, like Openbox or Firebox, for example. XML is widely known and well supported. It has served many times as a GUI formatter so it is also proven to deal with GUIs efficiently. Its also very simple, with no bloat or needless options in it. XML format seems almost a natural choice here.
But enough about configuration, settings and generally storing text data. What about the graphics themselves? Well, the answer is more simple then you can imagine: SVG. Yes, my friends, Scalable Vector Graphics is the best choice here. It has tons of advantages, along with the option of being animated and they are stored in … stored in XML format, another place where we have great unification, everything stored in one format, configuration, settings and all graphics. We just need one tuned parsing engine for graphics, text, separators, settings … everything!
Those who browse web pages a lot know good that increasing web page content size with images makes those images dirty and pixelized, but using SVG graphics we are not limited to one selected or designed size: we can size everything as we want keeping the best possible quality at the same time.
SVG and PNG Files Both Scaled to 400%
Using XML format for everything leaves a lot of places for optimization. Tweaking one engine improves the performance of everything, since everything is parsed through it. That is the whole idea of Vermaden’s GUI — unification of everything with inheritance in mind multiplied by good defaults. By having everything simplified and stored in one format, the optimization process focuses on optimizing one parsing engine and one display/drawing algorithm. Moreover, fixing bugs should be easier since you have to cope with one or two things instead of hundreds of modules like in the Apache Web Server, for example.
But I Want Options
The separators idea leaves a lot of room for customization and settings. For example, we do not need to set every container setting; we just set border to 10 pixels width for one container and all containers that are in that container inherit its settings. If we want to tune some of them, we also have no problems doing that. We can align everything as usual: top, left, bottom, with inheritance of containers it will be simple and efficient.
As you can see we have all the options that all other GUIs offer, but we can do much more in much less time, with coherence and simplicity.
Summary
My GUI design concept solves most (if not all) current design and usage problems. It’s fast, efficient, easy to scale and tweak, ergonomic, uses open and well documented standards such as XML or SVG images (also based on XML). This design is simple and clean, everything here is cut to parsing XML and using one simple algorithm to draw a GUI using Separators and Containers. At the same time with inheritance of settings in mind everything can be tweaked for anyone’s preference.
So let’s summarize Vermaden’s GUI in pros and cons:
pros:
- Everything based on the idea of unified separators and containers
- All data, configuration and graphics stored in XML/SVG format
- Drawing of the interface involves one parsing engine that parses everything
- Interface is scalable because of SVG graphics and containers idea
- Its extremely fast to parse XML content so its also ultra lightweight
- Ensures that theme/GUI does not have design flaws
cons:
- It only exists on the drawing-board. Somebody needs to implement it first
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSAlert.
You might want to check out Adobe’s Flex/AIR. Views/components are defined in XML, with CSS for styling (optional, you can also set properties in the XML). Everything is object oriented so you can create fully re-usable components that inherit behavior from a base class. Flex has a built-in vector graphics engine, thanks to the flash player, but also supports SVG natively.
I am not at all sure what you are on about with your “separators” idea. What you describe is simply nested containers with specific layout. Just about any GUI toolkit will allow you to do this. In Flex you can next Box, VBox, and HBox to get just about any layout you’d like – and the scrollbars behave as you want as well. I really don’t know of any GUI toolkit where the scrollbars are external to the content.
If you don’t like the way Flex’s native containers layout, you can simply override the method that is responsible for child component positioning – and create your “separator” – whatever that is.
Additionally much of Flex is open source. It’s cross platform (both the Flash viewer and the Flex development environment run on Windows, Mac, and Linux). AIR (for the most part) is Flex with a desktop installer, HTML widget, local “micro” database, local Flash player, and special classes that allow local file system access.
Oh yes, many thanks to the “Flash” player. Well, in fact, the IRIX interactive desktop had vector images in icons many years ago: “One of the most unique features about the IRIX desktop is that its icons are vector images instead of bit-mapped images. This means they can scale to any size in real-time without losing any quality.” See http://toastytech.com/guis/irix.html for further details. Not wanting to be impolite, but vector icons are nothing new.
Ok, let’s start at the beginning.
Most of your criticisms just come down to style. Your “improved” anjuta screenshot is basically just Anjuta with less space between widgets. In some cases that makes it looks better (like the tabs in the middle panes, which now look attached) and sometimes it makes things worse (the menu and toolbar at the top look horribly cluttered) but really this is just a matter of taste. You like minimalist styles, but not everyone does.
Then some of your changes I would consider downright misleading. The best example is your change to the vertical tab bar containing the items Help and and terminal. In the original design, it was clear that clicking these would replace the left dock widget (which contains Breakpoints and Dissassembly) with the tab you clicked on. In your redesign, the tabs are no longer logically connected to the left bar, they are only connected to the breakpoints sub-frame. It is no longer clear what will happen when they are clicked. In addition, if there are more than two tabs there your whole layout falls apart. Where will the third one go now that the tab bar is so short?
About borders, there is nothing in the toolkit that forces you to have a border. That’s just how the apps were designed. Different styles will do different things here, and they can be easily overridden. For example, have a look at the concept for the new Amarok UI (it’s not done, but have a look at the lack of borders) http://amarok.kde.org/blog/archives/656-A-wolf-in-designer-clothing…
I’m not familiar with how GTK’s theming system works so I won’t comment on that. But the reason you have to compile Qt styles is because they can modify everything about the look and feel of widgets. It’s not just changing colours and images, you can have animations and transitions, you can change how widgets behave, etc. It’s completely impossible to achieve that level theming without native styles. If you just want to change the colours, you can do that from a plain text file. Also Qt4 has extensive support for using stylesheets in applications, which gives you a ton of control over appearance without compiling anything.
>> I propose creating a whole GUI by separating the available content in a simple, sensible manner, managed by one simple efficient mechanism or algorithm responsible for efficient usage of available window space, responsible for placing all window items. Does that sound interesting?
You just described layouts. Which is the base of most UI toolkits I’ve used.
The choice of graphics is up the application devs. Nothing about the toolkits prevents the use of SVG. Yes SVG is cool, but it is also slow, and no matter what you do to the rendering engine, it will always be slower than raster graphics like PNG.
What you describe as separators already exist, just in the form of layouts. They can do everything you want them to. And they won’t stop you from creating a bad UI. The onus for that is still on the designer.
Edited 2008-05-21 22:00 UTC
That’s what I thought when I read through the article. He likes minimalist styles without visible borders, and prefers invisible 1px separators over fatter ones.
I personally like Anjuta the way it is and didn’t like the mockup with the separators. I found it too “cramped”.
Again, that’s just down to personal preference.
That gave me a WTF moment too. Layout managers already exist. They’re much harder to use than traditional NULL layouts, but they exist in GTK, Qt, wxWidgets, Java Swing, even AWT, and practically any semi-modern GUI toolkit.
I don’t know what the authors qualifications are, but my experience in the commercial world with regards to GUIs is that they’re like art. Show your GUI mockup to 10 people, and you’ll get 10 contradicting reports back. Some of the criticism is useful and constructive, but the majority tends to make you go WTF?
No its not, check out E17 (rather Evas/Ecore/Eet and Edje), there theming is completely unrelated to the application. You can do anything you want with you application, change layout, transitions, animations, behaviour etc, all without any change to the programs code, or any compilation.
Syllable (www.syllable.org) already offers a dynamic layout system, providing many of the benefits of separators. The HLayoutNode and VLayoutNode automatically arrange their child components (including other HLayoutNode/VLayoutNodes) horizontally or vertically, and neatly resizing the child components when the window is resized. Though the system isn’t quite complete yet, it already takes most of the manual positioning and layout work from Syllable GUI development.
See http://development.syllable.org/documentation/API/LibSyllable/class…
http://development.syllable.org/documentation/API/LibSyllable/class…
http://development.syllable.org/documentation/API/LibSyllable/class…
http://development.syllable.org/documentation/API/LibSyllable/class…
I like your article very much.
Flaw No 1: A Gui needs some air to breath. Your proposals are fixing the problems you mention but also create new ones. Please consider the question “where can I give some space to guide the user?” .. you removed clutter, but the slimmed down versions look confusing for most users, too. Esp. your Sonata example.
Flaw No 2: It’s true that vector graphics are lots better than their pixmap counterparts in regards of appearance (if done right). Still, if you do a comparison between two scalings, you have to do it fairly. You didn’t use one of the well established scaling algorithms which provide a much better quality than your simplest-possible-method.
Edited 2008-05-21 23:44 UTC
Some borders are serving purposes. I expect splitters between elements that i might move a lot to be wider. Why? Because i often use the touchpad on my Laptop when I’m not at home and using that to move an splitter that has a one pixel hitzone is frustrating at best.
Other wider splitters give visual grouping or simply make for an more pleasing to the eye appearance.
I think that in all cases, his modified versions looked nicer than the original.
With regards to the 1px borders, you could have then so that they become wider as the mouse passes over them so they are easier to hit. Or as he says the width of the separator border is customisable so it need not be 1px.
This concept is very similar to the Panels you get in C#. Have to say though that auto-resizing of Panels/Containers is not always desirable. If you have only a few widgits on the page and you maximize on a large screen, it can look pretty bad. In these situations I normally go for a fixed sized window.
Qt 4 supports SVG and CSS (or something similar to CSS) for themeing.
Preferences, preferences, preferences. I have no problem with “Vermaden’s GUI” as a concept (it works very well for Sonata), but to propose that it is a all-around better approach is foolishness. The look alternates between minamalistic and cluttered – one of those is a user preference, and the other is universally bad. Spaces are useful as visual cues to separation of elements: forexampletryreadingasentencewithoutthem. You may say they’re totally unrelated, but that’s the direction that this design heads in.
Wow. ok, first of all, get either VB6 or VB.NET, it is the world’s most used RAD IDE. Then try to do so like how you said.
It CAN be cone, it just comes down to someone creating new user controls to those specifications.
and i have bad news for him. he thinks that he is right, but every other developer out there also thinks the same thing.
So the good news is, it is a good idea.
the bad news is, no body gives a damn enough to put the time in to making new controls.
Yep. That’s because VB is a truly awful way to make GUIs. Yes you can make them quickly, but they will suck too many ways to describe. The lack of layouts is a huge one. Every other toolkit has those though, so unless you’re insane, you’ve got lots of choices that support doing UIs with layouts.
.NET(and thus VB.NET) have a implementation of panels and seperators so it’s completeley possible to use it.
However: it’s not forced, and VB.NET being a RAD-tool and I’m not really sure if anyone actually bothers using it.
I’m a C# developer and I use dynamic layout for all my user interfaces. I mostly use the TableLayoutPanel and the docking/anchoring system. One of the reasons why I think this is necessary is for people with different DPI-settings: all the controls get bigger and if you don’t use dynamic layout, you get overlapping controls and an ugly (sometimes unusable) UI.
Yeah I figured .NET would have them. Just gotta make people use them now…
The other reason is translations. In another language, labels will change size and layouts need to adapt.
Sorry, but as a graphic design consultant this article was quite frankly painful to read.
Your perceived problems with the state of GUIs at the moment are actually NOT problems with GUIs in general, but rather a result of the OSS’s community’s stubborn refusal to pick a single toolkit and stick with it. In fact, that’s been one of the primary barriers to widespread adoption on the desktop by consumers, as invariably when you plonk a user unfamiliar with Linux down in front of a Linux machine, their first comment is usually (well, after “where’s the Start menu”), “why does everything look so different?”.
They’re not reffering to the system looking different from Windows, but rather why none of the applications match. And whilst the DEVELOPERS who work in their little compartmentalized groups are quite happy to say to themselves “well our code is good, so what does it matter how it looks?”, the DESiGNERS at companies like Apple and Microsoft are sitting in their offices both cringing and laughing at the fact that the OSS community can’t get its act together.
As to your idea, it’s a typical example of backwards Linux styling. Cramped, flat, and “designed” with no regard to ease of use for end users or aesthetics. If it was ever put into play in a production environment it would drive potential user away in droves as their first thought would be “what the hell is going on? It’s too cluttered for me.”
If this was digg, then *buried*.
Edited 2008-05-22 04:07 UTC
Yeah as opposed to Windows where everything looks perfectly consistent.
Despite Mac OS X’ strides, it’s still Gtk+/GNOME that reigns supreme when it comes to graphical consistency. Windows is somewhere at the bottom of the chain, and Vista only made it worse.
…
I actually agree with Thom. o.O
GNOME is very good at consistency.
*If* … you only use GTK+ apps.
Likewise you could say Windows is relatively consistent if they just stuck with ONE of their numerous toolkits instead of using different at random…. oh well.
Amen
Amen! (for the most part)
I was with you until you put MS in the same category as Apple in-terms of UI consistency. There too many applications to list here that have major issues with consistency and look nothing like each other. So for a linux newb to ask why does everything look different is kind of ironic.
In my many years of development, I’ve yet to meet a good layout manager
That is basically what you are talking about here.
I don’t know what it is, but they always have problems when you get into the nitty gritty. Things don’t resize as you might want. Binding things to an edge just doesn’t look right when more space is available… When/how should a scroll bar pop up. What happens when you have a scroll pane inside a scroll pane
I’ve said screw it on more than one occassion and just resorted to a simple fixed position style 
All I can say is your ideas are interesting. Yet, I think the devil is in the details. I’d suggest just prototyping it first. Maybe it will end up being something very useful. Or you might realize why others have the problems they have.
1. SVG is not a silver bullet – Apple was wise in talking to its graphic design team and deciding to use a stack of raster/bitmaps rather than vector graphics for icons (one application of SVGs, but it’s relavant).
Please see “Icon Design: Bitmap vs Vector”:
http://www.firewheeldesign.com/sparkplug/2006/April/icon_design_bit…
2. Qt has had style sheets (~CSS) for widgets for a while now. They allow for a lot of flexibility, even at run-time. They can be used to get rid of extra borders with only a few characters of code. They have allowed me to easily polish up code to look like Apple’s apps.
Please see “Qt Style Sheets”:
http://doc.trolltech.com/main-snapshot/stylesheet.html
Let’s see: it seems as though the article is written with the intention for it to be a research piece, or at least that’s what it would appear was meant… at one point in time, on a LAN far far away.
But, for it to be a research piece as opposed to an opinion piece, it first of all needs to show that research has been done, and not so heavy on the opinion part, especially when it is horribly unbalanced.
1. You whine about how the OS X GUI isn’t a good license to a lot of people, and then you go expound on all the “goodness” of all the Linux theming/etc. stuff that exists. Why pick on the OS X GUI (Aqua, I presume you’re referring to) and then completely ignore the much larger audience GUI, Windows, with its also proprietary license? If you’re going to walk into a zoo, don’t ignore the biggest animals! Of course, perhaps that wasn’t mentioned because there’s absolutely no problem getting any variation of Windows GUI you want to use as a theme on Linux (or some other *ix) because Gnome has it, KDE has it, etc. and in fact, the Linux boxen I use at work are hard to distinguish without carefully checking to see they’re NOT Windows! Of course, more evidence that absolutely no useful research was done: Ok, so Apple doesn’t hand over the code to Aqua and say “Have fun, it’s on us!” but then, the same way the Windows GUI has been replicated (though perhaps not as well for usability) so, too, has the OS X Aqua GUI been themed: it took me zero effort with a search engine to find one available for Gnome: I didn’t bother looking for one for KDE or the other X Window managers.
2. You seem to go and insist that there’s “One GUI to rule them all” when the reality is that if you have actually checked with real people, well, like you, they’re unique, just like everyone else: there’s no such thing as the be-all, end-all “perfect” GUI that’ll work well for everyone. Not only that, but there’s simply no practical way a single GUI format works in all situations: I point you towards Windows Mobile (usually) needing a stylus, making it a clumsy PITA, and then there’s Cocoa Touch on the iPod Touch and iPhone: one of these GUIs was actually designed with the form factor clearly in mind, and the other one wasn’t.
3. You expound on the efficiencies of XML, with no apparent understanding of the reality that if anything, XML is so “enterprisey” it has a well-earned reputation for everything but efficiency: it lends itself better towards being human-readable in a raw form, but interpreters for any text-based file format will inevitably be slower than a file read/write solution for a binary file format. Certainly, binary file formats are more of a pain for a human to work with: XML (or other text file formats) are more of a pain for a computer to work with. That’s one of the reasons why interpreting Microsoft Office files is such a PITA for the older file formats: they were designed with binary formats setup for speed in rendering and loading, not for human readability. That’s also at least part of the reason why Open Office (for native formats) is likely to always be so much slower: interpreting verbose text file formats requires more I/O time to/from the disk, and also more CPU time parsing and verifying that they’re correct. Make the most efficient XML parser you can, and it still won’t be as fast as loading in a binary file that can be loaded in all at once and run from straight out of RAM as-is.
4. While SVG is (in theory) more standardized, it suffers from the result of what was mentioned above in my post, as well as that of the post of others: it’s slow to parse and render. I’d suggest you look into the Haiku-specific icon vector language used there: much faster to use in practice, and can readily enough be ported to other systems. Oh, the license is perfectly useable, too, even moreso than GPL.
Why didn’t I write an article (yet) for OSAlert? Because there’s too much overhead involved compared to what I’d get out of it, because I don’t feel like exposing myself to well-constructed criticisms if I choose to ignore doing my homework before I post
GUIs and window managers in general have far too much irrelevent visual bloat, too much distracting “eye candy” or skins, and basically too much of everything. Often the GUI seems to be designed as an end-in-itself, detracting significantly from its use as a productive interface.
I’m starting to think that the old-school, console-based, command driven interfaces were far more productive and far more efficient in their use of space, due in part to the constraints of the time.
I’d really like to see a nice balance of space and content that enhances productivity and information presentation. Anyone have any examples of window managers or application GUIs that you’d consider extremely well designed in this regard?
acme, and any of the tiling window managers (mostly dwm and larswm)
Thanks, after some googling, your suggestions eventually led me back to this earlier OSAlert article:
The Desktop Is Changing… But to What?
http://www.osnews.com/story/13974
Well, there’s nothing stopping you from using the command line.
For most people except the computery savvy geek(not meant offensive!) the socalled “bloat” helps them learn and understand the userinterface.
(Well there are exceptions such as the transparent menubar, and overglossy reflective dock in Leopard.)
Linus Torvalds setting the trend of calling his creation Linux. Vermaden and other follows.
Some could say it is a bit arrogant to call it Linux, or to start a conference speech with “I am your God”, or to… etc etc.
Stallman said “Well, I do not call it [my creation] Stallmanix”.
Actually, Linus Torvalds originally called his new kernel Freax, but his ftp administrator friend named the kernel directory “linux” on the server. From Wikipedia:
“Linus Torvalds had wanted to call his invention Freax, a portmanteau of “freak,” “free,” and “x,” an allusion to Unix. During the start of his work on the system, he stored the files under the name “Freax” for about a half year. Torvalds had already considered the name “Linux,” but initially dismissed it as too egotistical.
In order to facilitate development, the files were uploaded to the ftp server (ftp.funet.fi) of the Helsinki University of Technology (HUT) in September 1991. Ari Lemmke, Torvald’s coworker at the HUT who was responsible for the servers at the time, did not feel Freax was a good name. Consequently, he dubbed the project “Linux” without consulting Torvalds.”
http://en.wikipedia.org/wiki/History_of_Linux
Actually, I dont believe the story of Freax being renamed Linux by someone else.
Imagine you did a project and called it KazooBang. And then I am to host it, and I rename it to LattjoLajban. What would you think then? Would you accept someone renaming YOUR project? Hell no. Linus is the owner, and Linus approves any name changer. We all know how arrogant the Linux kernel developers can be. There is no chance in hell that Linus allowed someone else to rename his project, without Linus approval.
The problem is not with the toolkits (especially with modern toolkits): you can create a good or bad UI with any toolkit. The problem is that a lot of developers don’t know how to create a good UI. This doesn’t mean they’re bad developers, it’s just a lot harder to create a good UI than to create a bad one and creating a good GUI requires a different talent.
I do agree with some parts of the article (I also don’t like double borders), but most of it actually sounds bad to me. A good UI needs extra spacing and sometimes extra borders to be usable and pleasant to the eye.
Amen.
Developing and creating GUI-design are two quite different tasks.
Sure, there might be people who are good at both, but you can’t count on that most developers are good GUI-designers.
Userinterfaces is a art of it’s own. Something people like Jacob Nielsen proves.
It takes forever to create a good UI and im not even there yet with my own program. I imagine things to take really long time to get right no matter what GUI api that are being used. To make matters worse if there are inconsistencies between GUI apis/distos/themes it will take even longer time. Good things take valuable time.
Hi,
I’m using glade to design Gtk+ and i find that your separator idea looks just like Gtk+. See http://www.imagup.com/imgs/1210580685.html .
I don’t think that separators are a good idea. Container are enough. Because it’s a pain to manage all that separators. Then you’ll need SeperatorManager to layout those separator and you end up like Qt/Cocoa/AWT/Swing with those LayoutManager i hate.
Actually, the true problem of Gtk+ is consistency of widgets. It’s currently done using some helper, but that’s very limited. One big issue is for custom widget and canvas widget. Most of the time it’s hard to get something actually themable (except colors).
Regards,
~A‰tienne.
Of all available GUIs today, Apple’s Cocoa used in their flagship operating system Mac OS X is a jack-of-all-trades and looks better and more coherent then the two I just mentioned from the open source world, but it still has quirks in many places. Those quirks are not its major disadvantage though; the license is.
If you want a free, Cocoa-like GUI engine, use GNUstep. GNUstep’s default look isn’t that fashioned, but themeable. The widget set, coding methaphor and even the programming language is the same as in Cocoa.
“wasting window space with needless borders and margins”
As a designer-trainee I would say that borders and margins are anything but needless.
I also think my mentor would agree, and pretty much every designer I’ve worked with and learned from.
Since design-principles are universal this would apply too not only to typical graphic design studd such as ads, posters, booklets, etc…. but also to computer program GUI’s.
One thing is that using proper margins makes thing look good, but it’s also functional.
Now programs having glitches in GUI is bad of course and should be dealt with… but judging from the Anjuta mockup I’d rather use the one with margins than the one with seperator thing. It’s too thight. It’s unpleasant to look at, it’s hard to focus on stuff, its’ hard to get overview on it(margins help guide the eyes) and many of the elements now are so compact that you risk the user hitting another button than he inteded. (If there where margins and he missed he simply would not hit a button at all.)
You have some points:
– XML
– SVG (Allready implemented in KDE and planned for GNOME?)
– Have sane defaults (althought the extremely crammed default your mockup suggests is anything but sane.)
However, if you good cuse the seperator/containers scheme and come up with a tad more advanced and flexible concept that DOES use margins and borders but in a automated fashion, it might work out.
Very few want to work with apps that are crammed, hard to get and overview of with GUI-elements that are so small you risk missing them.
I was going to write a longer and more in depth comment with my criticism on this… but since the author didn’t feel like taking time to better research and polish his ideas and concepts, neither will I.
Go google on themeing, read the documentation on themeing for the toolkits you are concerned about, read the GNOME HID (google, again ;-), read past “studies” on GUI usage, read past research on designing GUIs and stop reinventing the wheel.
This is a news site not a forum, right? So less of these opinion pieces would be nice.
Thanks a lot for your contribution…
For a different way of laying out GUI components, check Edje:
http://homepages.pathfinder.gr/kazanaki/contrib/ch04.html
And, besides, open source graphic toolkits/framework are constantly changing. Anyway, it is nice to see how people react to the oportunities the uncertainty of GTK+ 3 offer.
By the way, when it comes to true peformance, text formats cannot beat binary formats. Of course, binary formats (unless well designed) are less interoperable and less flexible.
Remember, XML is a specification to design structured document formats, not the solution to every single computational problem.
The only part of this article that raises a legitimate issue is the lack of “border collapsing” between nested widgets (what vermaden calls “design issues” in Sonata).
i.e. the scrollbar widget has a 1px border, and the frame of a scrollable widget also has a 1px border. When the scrollbars are drawn inside the frame, one ends up with a 2px border. A similar issue happens when two widgets with borders are placed next to each other with no padding.
With stand-alone edje, one can get around this and make simple guis that are visually ‘correct’ (by carefully aligning parts). However, you have to reimplement the functionality of every widget you need. Move to an edje based widget library (e.g. EWL) and you will see the same issues reappear.
Its not an easy issue to solve. You need the theme to be able to tell the layout code to selectively apply negative margins in certain combinations…
So, although edje is nice, it doesn’t really solve many *toolkit* layout issues.
I like some of what the author pointed out, but it’s pretty obvious that he is NOT a graphics UI person, but someone who thinks logically. Unfortunately, my experience is that the two sometimes don’t mix very well.
I too am more technical, so I prefer things that “make sense”, which I think is what the author is attempting to say.
But if you look at the “good”, “award winning” UI’s out there, a lot of them do NOT make sense and suffer from the “wasted space” issues brought out in the article.
Shoot, all you have to do is visit one of those award winning websites with a large (possibly wide screen) monitor, and when you see the fixed width the page centered (very small) on your huge screen, you wish that people did things that “make sense” rather than what supposedly “looks good”.
Anyhow… some good points…. and I think that some applications might change, but the UI award winners will go to the apps that make use of “wasted space” to make things pretty.