Linked by vermaden on Wed 21st May 2008 19:28 UTC
Graphics, User Interfaces 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.
Order by: Score:
This pretty much already exists
by joshv on Wed 21st May 2008 21:43 UTC
joshv
Member since:
2006-03-18

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.

Reply Score: 1

Doc Pain Member since:
2006-10-08

Flex has a built-in vector graphics engine, thanks to the flash player, but also supports SVG natively.


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.

Reply Score: 2

Well, not really
by leos on Wed 21st May 2008 21:58 UTC
leos
Member since:
2005-09-21

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

Reply Score: 12

RE: Well, not really
by evangs on Thu 22nd May 2008 06:12 UTC in reply to "Well, not really"
evangs Member since:
2005-07-07


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.


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.


>> 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.


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?

Reply Score: 3

RE: Well, not really
by glubamazing on Thu 22nd May 2008 14:59 UTC in reply to "Well, not really"
glubamazing Member since:
2008-05-05

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.


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.

Reply Score: 1

'Separators' in Syllable GUI
by Morph on Wed 21st May 2008 22:24 UTC
Morph
Member since:
2007-08-20

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...

Reply Score: 1

Two flaws
by Ford Prefect on Wed 21st May 2008 23:43 UTC
Ford Prefect
Member since:
2006-01-16

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

Reply Score: 5

I disagree
by Alleister on Thu 22nd May 2008 01:18 UTC
Alleister
Member since:
2006-05-29

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.

Reply Score: 3

RE: I disagree
by HappyGod on Thu 22nd May 2008 04:50 UTC in reply to "I disagree"
HappyGod Member since:
2005-10-19

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.

Reply Score: 2

SVG+CSS
by panzi on Thu 22nd May 2008 01:29 UTC
panzi
Member since:
2006-01-22

Qt 4 supports SVG and CSS (or something similar to CSS) for themeing.

Reply Score: 1

wow.
by jadeshade on Thu 22nd May 2008 01:40 UTC
jadeshade
Member since:
2007-07-10

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.

Reply Score: 2

NOT a software Dev
by SoloDeveloper on Thu 22nd May 2008 02:15 UTC
SoloDeveloper
Member since:
2008-03-16

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.

Reply Score: 1

RE: NOT a software Dev
by leos on Thu 22nd May 2008 04:02 UTC in reply to "NOT a software Dev"
leos Member since:
2005-09-21

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.


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.

Reply Score: 5

RE[2]: NOT a software Dev
by TLZ_ on Thu 22nd May 2008 11:35 UTC in reply to "RE: NOT a software Dev"
TLZ_ Member since:
2007-02-05

.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.

Reply Score: 1

RE[3]: NOT a software Dev
by TommyCarlier on Thu 22nd May 2008 13:27 UTC in reply to "RE[2]: NOT a software Dev"
TommyCarlier Member since:
2006-08-02

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.

Reply Score: 1

RE[4]: NOT a software Dev
by leos on Thu 22nd May 2008 14:14 UTC in reply to "RE[3]: NOT a software Dev"
leos Member since:
2005-09-21

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.


Yeah I figured .NET would have them. Just gotta make people use them now...

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.


The other reason is translations. In another language, labels will change size and layouts need to adapt.

Reply Score: 2

Yeah, no.
by Dev Corvin on Thu 22nd May 2008 04:02 UTC
Dev Corvin
Member since:
2007-04-20

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

Reply Score: 8

RE: Yeah, no.
by Thom_Holwerda on Thu 22nd May 2008 04:13 UTC in reply to "Yeah, no."
Thom_Holwerda Member since:
2005-06-29

"why does everything look so different?".


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.

Reply Score: 6

RE[2]: Yeah, no.
by evangs on Thu 22nd May 2008 06:15 UTC in reply to "RE: Yeah, no."
evangs Member since:
2005-07-07

""why does everything look so different?".


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

Reply Score: 3

RE[2]: Yeah, no.
by TLZ_ on Thu 22nd May 2008 11:40 UTC in reply to "RE: Yeah, no."
TLZ_ Member since:
2007-02-05

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.

Reply Score: 2

RE: Yeah, no.
by ddd_ on Thu 22nd May 2008 10:03 UTC in reply to "Yeah, no."
ddd_ Member since:
2007-03-29

Amen

Reply Score: 1

RE: Yeah, no.
by TLZ_ on Thu 22nd May 2008 11:41 UTC in reply to "Yeah, no."
TLZ_ Member since:
2007-02-05

Amen! (for the most part)

Reply Score: 1

RE: Yeah, no.
by apoclypse on Thu 22nd May 2008 12:49 UTC in reply to "Yeah, no."
apoclypse Member since:
2007-02-17

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.

Reply Score: 2

Try and implement it
by Yamin on Thu 22nd May 2008 04:09 UTC
Yamin
Member since:
2006-01-10

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.

Reply Score: 1

SVG, Borders, Qt
by aidan on Thu 22nd May 2008 04:19 UTC
aidan
Member since:
2008-05-22

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

Reply Score: 1

JonathanBThompson
Member since:
2006-05-26

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 OSNews? 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 ;)

Reply Score: 4

GUIs and Visual Bloat
by Meridian on Thu 22nd May 2008 05:42 UTC
Meridian
Member since:
2007-12-18

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?

Reply Score: 1

RE: GUIs and Visual Bloat
by yiyus on Thu 22nd May 2008 07:16 UTC in reply to "GUIs and Visual Bloat"
yiyus Member since:
2006-02-27

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)

Reply Score: 1

RE[2]: GUIs and Visual Bloat
by Meridian on Thu 22nd May 2008 07:35 UTC in reply to "RE: GUIs and Visual Bloat"
Meridian Member since:
2007-12-18

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 OSnews article:

The Desktop Is Changing... But to What?
http://www.osnews.com/story/13974

Reply Score: 1

RE: GUIs and Visual Bloat
by TLZ_ on Thu 22nd May 2008 11:46 UTC in reply to "GUIs and Visual Bloat"
TLZ_ Member since:
2007-02-05

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.)

Reply Score: 1

Vermaden's GUI
by Kebabbert on Thu 22nd May 2008 05:56 UTC
Kebabbert
Member since:
2007-07-27

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".

Reply Score: 1

RE: Vermaden's GUI
by kolmyo on Thu 22nd May 2008 07:06 UTC in reply to "Vermaden's GUI"
kolmyo Member since:
2005-07-11

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

Reply Score: 4

RE[2]: Vermaden's GUI
by Kebabbert on Thu 22nd May 2008 18:48 UTC in reply to "RE: Vermaden's GUI"
Kebabbert Member since:
2007-07-27

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.

Reply Score: 1

Not a toolkit problem
by TommyCarlier on Thu 22nd May 2008 06:28 UTC
TommyCarlier
Member since:
2006-08-02

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.

Reply Score: 1

RE: Not a toolkit problem
by TLZ_ on Thu 22nd May 2008 11:29 UTC in reply to "Not a toolkit problem"
TLZ_ Member since:
2007-02-05

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.

Reply Score: 1

Time
by neoneye2 on Thu 22nd May 2008 07:10 UTC
neoneye2
Member since:
2008-05-22

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.

Reply Score: 1

Something new ?
by bersace on Thu 22nd May 2008 08:37 UTC
bersace
Member since:
2008-04-02

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,
Étienne.

Reply Score: 1

Comment by Traumflug
by Traumflug on Thu 22nd May 2008 09:21 UTC
Traumflug
Member since:
2008-05-22

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.

Reply Score: 1

Margins are important. Don't remove them.
by TLZ_ on Thu 22nd May 2008 11:06 UTC
TLZ_
Member since:
2007-02-05

"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.

Reply Score: 1

Comment by fresch
by fresch on Thu 22nd May 2008 11:28 UTC
fresch
Member since:
2006-09-12

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...

Reply Score: 1

What about E17?
by C2H5OH on Thu 22nd May 2008 14:59 UTC
C2H5OH
Member since:
2008-05-22

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.

Reply Score: 1

RE: What about E17?
by rephorm on Sat 24th May 2008 21:03 UTC in reply to "What about E17?"
rephorm Member since:
2006-07-20

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.

Reply Score: 1

Some good points
by cjcox on Thu 22nd May 2008 15:46 UTC
cjcox
Member since:
2006-12-21

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.

Reply Score: 1