Death to GUIs

A lot of the big boys provide shiny pretty tools to ‘help’ you do stuff. It’s rare to find a really expensive server/application that doesn’t give you ‘value-added’ gui’s that help you interact with the complex systems they have built. These gui’s of course ensure that there is a low barrier to entry, that you’re ‘empowering’ your business users, and allowing them to increase their ‘time to market’ and push up their ‘ROI’.

While these tools do provide a good selling point, more often than not they’re in direct conflict with the people expected to work with said system. I’m heartily sick of vendors pimping their latest gizmos with shiny demos and hordes of marketers squealing that ‘people buy with their eyes’. I’d like to stab those people in their eyes with a butter knife. Let’s see them buy ‘with their eyes’ then.

To me, any suite that mandates or ’strongly recommends’ a gui management tool is basically saying ‘look, our underlying configuration format sucks, it’s convoluted, awkward, and endlessly tedious to work with, if we let you use it, you will either laugh at us or want to murder us in our sleep’. Witness the call for struts consoles, that happened since people started to realize how retarded and obfuscated struts configuration is. Of course, products like JBoss have configuration that is so hopelessly fucked that even a config tool won’t save you there.

While working with a mouse and ineffectually faffing about with options and pictures to accomplish stuff is enjoyable and satisfying to effeminate developers, the manly developers are more likely to feel rage at being made to jump through hoops and treated like an invalid 3 year old. It’s insulting and offensive to be treated this way. Give me a simple set of configuration files that are human readable and editable so that I can stick to using a keyboard like god intended.

GUI Culprits include the horrific weblogic workshop, websphere’s I’m-going-to-chew-off-my-arm-now-to-distract-myself-from-the-pain deployment tools, and my current cross to bear, tibco’s just-stab-me-in-the-face-now-to-end-it-all schema designer tool. Why oh why can’t these tools be advertised as something that is available but very definitely not required? Why can’t there be clear documentation on how to accomplish stuff without these tools, or documents for the underlying mechanisms these tools use so that you can do things your own way if you wanted to? Admittedly, it’s a bit unfair bundling weblogic with the others as the workshop is a latecomer so the config files have had to be coherent and sensible previously, and life can move along reasonabely smoothly without the workshop.

So have your filthy gui tools for your sales force to pimp to gimboid managers, but if you want good will from the trenches, make sure you don’t insult the intelligence of the developers and document all your formats. That way they can use whatever they feel enhances their productivity the most, and thank your app for helping them do it. If you’re REALLY kind and loving, then spend some effort simplifying your configuration, so that the call for a big fancy gui simplify it never arises.

31 Responses to “Death to GUIs”

  1. Loke Says:

    Let’s thank Orion for not falling into the tarpit of GUI configurations. It’s the perfect configuration.

    All you weblogic/jboss/whatever users, do yourself a favour and drop it. :-)

  2. Gabriel Mihalache Says:

    WebSphere Studio is not all that bad once you associate certain file types with the XML editor (instead of their default form-based one).

    Noone is stoping you from editing struts-config.xml or EJB descriptors in text-mode. As far as I’m concerned, WebSphere Studio/Eclipse have done the right thing vis-a-vis of “accesibility tools”, perhaps due to the flexibility of the Eclipse workspace.

  3. Bob Lee Says:

    I haven’t even finished reading this yet, but right on, Hani! Gabe, you’re an idiot. Just kidding. WSAD sucks. It actually slows you down (a lot), but many people don’t know any better.

  4. Anonymous Bastard Says:

    It’s called “incapsulation”. You may have heard of it.
    They are trying to hide the actual implementation from you, so you can’t complain when they change it. The GUI is your interface. Deal with it.

  5. Anonymous Bastard Says:

    Websphere also has a full command-line admin scripting setup where anything that can be done with the gui can be done via command line.

    As far as dropping it, some of us have no choice in the matter ;)

  6. Lee Says:

    Bring back punch cards and, that’s what I say!

    Those damned GUI’s make it too easy for people without a phd in compsci, sandals, and a beard to operate their machines.

    Seriously though, looking at WSAD in particular, if (like Bob Lee) people are finding that they are slower using WSAD than without it, then they really just don’t understand the tool, and should probably stick to pen and paper. At the end of the day, you can just use it as a damned text editor. No one makes you try and use all the bells and whistles. You don’t need it for deployment.

    However, Websphere App Server is a different matter, and the mysteries of wsadmin or wscp (depending on your version) do take time to master… but at the end of the day, once you’ve managed to find the information, they’re pretty simple too, and allow you to do anything from the command line that you can from the GUI.

  7. Anonymous Says:

    Two points:

    First: half the problem is not GUI tools per se, be they web-based or Swing apps, but that since The Great J2EE Server Side Migration, the world is full of monkeys who don’t really have half a clue about what building decent [G]UI is all about, so we end up with half-assed clunky crap with various Swing controls slapped in a panel.

    Secondly: So GUI tools make you feel all limp and demasculated, whereas hand-editing config files makes you feel all pumped up and testosterone fueled?? YEAH! FUCK THAT GUI! Jeez, you have some issues. Maybe you should stop blogging and get outside - try interacting with the female half of the species. They can provide far more effective ways of feeling manly.

  8. Anonymous Says:

    Screw human-readable configuration files! Give me configuration via a compiled Java class, loaded using its dedicated classloader. I want configuration to be checked by compiler! I want code-assisting in my IDE to be there to help, too!

  9. Kristopher Schmidt Says:

    That’s _decrease_ ‘time to market’ not increase, Hani. you need to listen more closely during marketing sales pitches.

  10. Andy Says:

    I’m working on a tool to immasculate developers, satiate “effeminate developers” and make JBoss easier to configure. http://superlinksoftware.com/cgi-bin/erswiki.pl?JBossConsole

  11. Neil Says:

    And one *huge* advantage of config files over configuration UI’s is that one can document why the configuration is as it is. With config files one can temporarily comment out lines or sections.

  12. Alex Says:

    Absolutely true. Also, whoever did not see the ad on the serverside about bea workshop should go and see it. The company is way off in it’s marketing tactics, i find the ad outright offensive.

  13. Anonymous Says:

    Do you mean “incapsulation” like “incest”? Or “encapsulation”? Try out Viagra for free today.

  14. Anonymous Bastard Says:

    So what if I accidently hit the I key instead of the E. They’re right next to each other.
    On my DVORAK keyboard, BWAHAHA

  15. Says:

    Yah baby …

  16. Glen Stampoultzis Says:

    The ultimate bastard GUI configurations tools are they ones they aim at “business users” to enable them to model “business processes”. Of course the fact that a programmer can’t even understand how to use the friggin things should be a hint that a “business user” has no chance. DISCLAIMER: No products names were harms in the making of this message.

  17. http://www.jroller.com/resources/gstamp/websphere.gif Says:

    I’m not sure what you’re talking about the websphere GUI has great attention to small details.

  18. http://www.jroller.com/resources/gstamp/websphere.gif Says:

    I’m not sure what you’re talking about the websphere GUI has great attention to small details.

  19. Anonymous Says:

    First post!

  20. Says:
  21. Danny Says:

    The idea behind GUIs is to make the system easier to use, particularly when you have no prior knowledge. If a GUI fails to achieve this, it’s more likely to be due to poor implementation rather than a problem with GUIs per se.

    Personally I find the GUI of OpenOffice far easier to use that hacking through config files.

    btw, I realise this is the BileBlog, but it’d be interesting for a change to hear about some products/tools/services/furry animals that you actually *like*.

  22. boxed Says:

    Danny: obviously you do not realize this is the bileblog.

  23. Jason Carreira Says:

    The problem with GUIs is that once they have a somewhat usable GUI they assume they don’t have to make things easy for editing by hand. The problem with this is, of course, SCRIPTING. Yes, it’s faster for me to do something in the GUI (just go with me here, it’s not really), but if I have to do it 100 TIMES A DAY, then it’s going to be WAY faster for me to script it.

    WebSphere (the app server, not the crappy tools) is the worst about this, and makes it VERY difficult to script setting up a development environment, etc.

  24. HappyPappy Says:

    What a bunch of hooey….no matter how good or clean your configuration format is there comes a point where the size of your application may require a GUI to make sense of all of it.

    Probably not for your average forum or cart application but when you have and ERP system with thousands of objects, millions of lines of code, and god knows how many different contexts in your J2EE app I’ll thank god for a good gui.

  25. GuiSMooey Says:

    What a bunch of hooey. I your BIG app needs a gui to understand the configuration you need to rethink the configuration setup! I’ve maintained large system with both GUIs and CLIs. The CLIs by a large margin have better thought out configs. Plus I can script my config, nothing like having to login to 12 system GUIs to do what one expect script could do in seconds.

  26. Anonymous Says:

  27. HappyPappy Says:

    >I your BIG app needs a gui to understand the
    >configuration you need to rethink the
    >configuration setup!

    Riiiggght I’ll take advice from a guy who’s idea of a large system is running the company guest book.

    I do run a large system whichs has over 1500 config items and to find/add/edit/delete any of them is a PAIN IN THE ASS. Even in a well thought out config when the size of the system gets too large eventually a text based configuration of whatever format becomes un-sustainable….accept it!!!

    I went to a JUG meeting where James Gosling spoke and someone (else) asked him what he’s working on….turns out he’s working on a GUI interface that attempts to make sense of large system(s) of any kind (not specific to configurations)…point being that if he and others recognize the need to try and manage complexity with the proper gui tools you should also.

    I’m not advocating the use of guis for every tool/idea/system….just the right tool for the right job and in certain circumstances a GUI is the right tool for the job.

    Conversely I agree with Hani that GUIs should be an adjunct to good configs, not a replacement for good documentation.

  28. Anonymous Cowturd Says:

    As long said big ass GUI configurer writes a human readable text file that can be checked into the source control system, then we won’t have any problems.

    If it writes a binary blob to a database, then there are going to be issues.

  29. Drew McAuliffe Says:

    I have also maintained complex config layouts for large systems, and GUIs actually make my life harder. The thing is, you need intelligent config file setup, and then config files work MUCH better. If you have the option of breaking config files out, then you introduce organization into your config file structure. You can use file search tools, which generally run a lot faster than GUIs, especially since most GUI config managers I’ve ever worked with start to slow down A LOT once you have a lot of configuration to manage. In the long run, the config file option is MUCH preferred by me, especially as the system gets larger and more complex. I’ve had the misfortune of managing complex systems with a lot of config elements to update and change. When those elements can’t be expressed in files, and those files can’t have scripts work on them, things get really nasty really fast. Try updating 100 workflow layouts with a Swing config app and you’ll see what I mean.

  30. Phlip Says:

    If you like TDD, and you like GUIs, you will >love< my forthcoming book on using TDD for GUIs. ;-)

  31. Catamount Says:

    The trouble is not about GUI as a concept. By itself, it was a revolution in human/computer interaction. All these rants about GUI tools come, in my view, for three reasons:

    1) There are many GUIs that are clumsy, counter- intuitive and inconvenient. They’re designed by people who have no clue about ergonomics/ usability and can do nothing meaningful except using a GUI builder and mindlessly cloning someone else’s solutions.

    2) Many GUI development/administration tools are designed with entry level IT/business user in mind. In combination with 1, it creates a bewildering, unusable UI with very limited capabilities. However, such products, bundled with right buzzwords are easier to sell to corporate decision- makers. As an example, compare the market success of Visual Basic to the small niche market of Borland Delphi despite of the latest product’s evident superiority.

    3) Handling CLI and large configuration files requires very strong ability to rote- memorize command line options and file entry syntax and fast- type long directory paths. Some of IT folks, administrators especially, have not too much to offer beyond this. They feel theatened by the GUI because it makes possible for every person with normal or above normal intelligence to take care of the administration functions without kneeling before a BOFH, and threatens that BOFH’s well- paying sinecura and status. It’s much like the marginalization of many DOS/assembly language/video memory programmers that happened with the advent of Windows and C++/Pascal development tools in early 90s. Sorry guys, this world is moving forward, and someone is gonna be left behind:-(

    Have fun, folks

Leave a Reply