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.
Permalink for comment 315198
To read all comments associated with this story, please click here.
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