UI design for developers and/or designers?
March 09, 2010 by Andreas Aardal Hanssen | Comments
When I started working with Qt back in 2003, what appealed the most to me was the network and GUI parts. The network part because I love network programming and have ever since I started with programming. The GUI part because of my demo scene background, but also because I never managed to get a working GUI for my apps, I just didn't have the patience to learn all the different platform specific (horrid!) APIs. I'm a bit lazy in that way. Being a huge Linux fan didn't make the situation better. And there was Qt, making it easy and consistent. For a C++ programmer, GUI programming with Qt on the desktop was and is just wonderful. There's a problem though, and I'll make a bold claim. Most programmers aren't that much into making good and fancy GUIs. We can cope with assembling them, perhaps, and it feels great to present a functional GUI to your grandma ("I made it, 'ma!"), but at least I get a headache whenever somebody suggests that I redesign the GUI because of this and that principle. I'm a programmer. Fiddling with a GUI just isn't my thing.
These days we are seeing a paradigm shift in the way UIs look, and how they are written. Yes, I used the term "paradigm shift" ;-), kudos to Thomas Kuhn ;-). One of the most misused terms in our times, it's a typical manager buzzphrase that doesn't make sense unless you really don't care (just translate it into "awesome new stuff", now it makes sense) or if you know what it means. In this UI context it actually works though ;-). I don't know if I know what it means but I'll explain what I think it means. If this interpretation changes, then that will just lead to infinite terminology recursion but enough about that. People talk about paradigm shifts when you change your entire view of how something works. It's really about leaving your comfort zone and looking at things with completely different eyes, and then maybe wondering how on earth you could have seen things differently in the past. "I want to be a lumberjack!!" These shifts happen at different levels of impact but you see them all around you. I think they are often seen in places where the world takes a huge leap forward somehow. I can think of a number of examples ("fatherhood") but I'll leave that as an exercise to the reader ;-).
On the UI front, designers are taking over. Tools and languages are improving, and the graphical designers, who have been at the mercy of programmers in the past, are not going to be anymore. As for programming languages, we're going to see less need for compiled code and traditional APIs. Less of the imperative way of thinking (the programmer's way) and more declarative. Who cares which button is added to the layout first or second, in whatever order? Nope, it's about how the designer wants it to look, and behold, it ends up exactly as the designer wants it. Also, the designer doesn't expect his UI to perform badly. That's going to seen as a bug in the framework.
I'm a programmer, and us programmers aren't ending up unemployed. ;-) I don't think designers can or should go much beyond the design. What I do think is that programmers will be forced to write even more UI-agnostic code than they have in the past. Instead of writing C++ code that toggles the connection between objects and enables/disables and hides/shows GUI elements based on events, we'll have to write APIs that expose the properties, the knobs and handles that affect them. This is not yet another MVC movement, this is about writing beans; library code with no UI whatsoever. There's a huge difference. And the designer will have perfect freedom to redesign the UI based on just that. Developers will have no control over the UI. In particular accessing elements in the UI shouldn't really be allowed at all (e.g., calling findChild() on a QFileDialog, ugh!). Instead we expose objects and properties to the UI layer, and cross our fingers and hope that the designer makes use of our functionality. Having less UI features exposed that we can use from C or C++, will for some be quite a painful change.
I cannot convince everyone. As a programmer, you really have to see what happens when you make the change. But I warn you, it will be hard to look back. The designers will suddenly feel like an integral part of the development team, making iterations upon iterations of their UIs and testing them in real-time on the target platform, using the _real_ features instead of just faking them. The "compiled code" doesn't change at all while the UI is evolving. The designers won't even need to talk to programmers at all. ;-) I honestly think we'll see a lot more designers emerge from their dark caves and join software projects. This, of course, is seen from a programmer's point of view. The designers will maybe think "Finally, I don't have to deal with those... interesting programmers!".
It's a paradigm shift. What a wonderful world :-).
PS: Qt 4.7 will be the first version of Qt that incorporates Qt Quick, a feature that moves us closer to the world-as-described-above. Search for QML, Declarative UI, Kinetic, Qt Quick and so on with your favorite search engine, text, images and video. We're keeping our cards close (a bit too close perhaps) for the first release but this technology will evolve rapidly after its first release.
Blog Topics:
Comments
Subscribe to our newsletter
Subscribe Newsletter
Try Qt 6.8 Now!
Download the latest release here: www.qt.io/download.
Qt 6.8 release focuses on technology trends like spatial computing & XR, complex data visualization in 2D & 3D, and ARM-based development for desktop.
We're Hiring
Check out all our open positions here and follow us on Instagram to see what it's like to be #QtPeople.
It's an excellent sentiment and I fully agree from the perspective of a UI designer, but I'm sort of a "UI designer who codes Python because a UI without code is useless" and if, when it comes to PyQt or PySide, it is notably more effort than "the old way", I'll probably burn myself out trying to reconcile conflicting desires to "make it perfect" and to "maintain a certain level of subjective productivity". (It has happened many times already. I solved those by recognizing that my mind seems to mistakenly default to "depth-first optimization" (Perfect each component far beyond the point of diminishing returns) and adapting accordingly.
Of course, my other big concern is whether you guys will complete the set of Qt Designer-available widgets. It's a general rule for my projects that they not contain anything requiring a compiler or admin rights to setup (part of a larger portability plan) so no designer plugins may be installed... so I often end up reverting to writing in-code dialog definitions whenever Qt Designer or Glade Designer for GTK don't offer the desired widgets. (I'm not willing to compromise my UIs, so I compromise my architecture instead. Typical "Mac-minded Stallman-alike on Linux" behaviour, as I understand it)
I have heard that it's possible to write Glade widget definitions in Python and then adjust the Glade search path via an environment variable though... so, despite my preference for Qt, unless Qt Designer offers something similar, I suspect I'll end up using GTK+ more once I've finished figuring out the details. (I still need to confirm that the libglade/GtkBuilder system doesn't also require a search path modification to load dialog definitions successfully)
Whatever method is used to create a UI, it still needs to be a usable UI. One of the best books that helps programmers understand how to create a usable GUI is "GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers" by Jeff Johnson
I'd been using QML now for ~1 Month, and I already feel that:
- This paradigm blows everything away
- This is the way to go
- That I managed to learn it very quickly while using it
For sake of honesty, though, I must say that I had a web-developer past: QML feels a bit like HTML with Javascript all over. Even though there is no HTML grammar whatsoever (except for the text formatting of Qt ;) ).
Stefan: http://qt.nokia.com/doc/qq/...
@Stephan To get Designer/uic to load plugins from non-system locations: Set QTPLUGINPATH in your environment to point to a directory somewhere you have write permission. That directory needs to have a designer subdir that contains the plugin shared objects. Sorry you didn't know about it earlier, it's been around since 4.0.0. Good Luck!
The problem I see is that every "designer" (or UI/QML programmer, actually), will invent its own set of widgets with its own style. As long as Qt does not allow standard widgets to be used from QML we will ruin the consistency users need to fluently use the software.
You know, Andreas, I also foresee another positive result by your described "paradigm shift". It will make Qt programmers interested in becoming better designers, and Qt designers in becoming better programmers. This is an interesting corollary which imho should NOT go unpublicized. Here lies the true power of the future Qt Creator: making you a better, more productive, and more complete developer (as programmer-designer).
The critical point is, of course, for Nokia to succeed in providing us a v4.7 which is really mind-blowing as far the possibilities go.
I gave up on QT Designer a couple of years back because it lacked the ability to connect to "knobs" outside of the GUI. This is a critical issue for your vision, because it makes it pointless for a application implementor to provide "knobs" that the GUI designer can use to drive the application. It was one of the best features of NeXTStep back in the day and I still miss it.
Andreas,
Can't agree more with your article!!
Every time I read this blog, I conclude that.....great software like QT has great people behind; this is not just a mere coincidence.
Leandro Gentili
Nice post. But more abstraction often has a performance cost. In certain practical situations, this might be a problem.
I also second Carina Denkman's mind above.
>> (e.g., calling findChild() on a QFileDialog, ugh!
I see I'm not alone on that ;-)
You are right about that: GUI programmers rarely have good design skills. We are good at making the mechanics of a GUI, but polishing it to make it look good is what most of us cannot do. This is where the designers come in.
But, and this is really important, a good designer is not necessarily (may I say rarely) good at usability. This is where most designers need help - be it from a GUI programmer who does have some usability background or from a pure usability specialist. Looking at the great majority of web sites today I find design comes first and usability often gets lost in the process (just look at all those awful flash web sites - unreadable fonts, stuff flickering and flashing all the time). This is not good. We should avoid the same thing happening to Qt GUIs.
A good GUI needs three kinds of people:
In my 20+ years of UI programming, I have yet to come across the first designer who knows anything about usability - or even who would admit that he doesn't.
Just my €0.02.
Heh. Paradigms. Well, here's my 20 cents (someone should get a groan out of that):
Excuse me, but "proactive" and "paradigm"? Aren't these just buzzwords that dumb people use to sound important?—The Itchy & Scratchy & Poochie Show.
Of course, I was also slammed back in the day for using paradigm correctly as well (sort of a funny story). Anyway, a paradigm is a "convention" or "way of doing something." Therefore your shift means that you are doing something different, contrary to the current way.
I guess you are talking about graphic designers here? "Designer" is a dangerously overloaded word, almost as overloaded as "user." Besides what is named above, I think you need good people dealing with interaction and usability, and also good user-testing or something sort of evaluation. It's quite amazing to see how such tests uncover so many "issues" you don't think about, just like using an API.
I expect the advantage of this is that you can try out more things faster, which should make applications having more power (and keep complexity low). For example, it was entirely possible to do animations in Qt before the animation framework, but making it easier to do makes it possible to add animation to things that you normally wouldn't think about or to aid in the user interface.
Finally, to your rhetorical "Who cares which button is added to the layout first or second, in whatever order?" I can tell you who cares. People who won't use your application visually. Like CSS separates appearance from the structure of a document, I hope applications still have good structure even when all the paint is scraped away. Basically, I hope this new paradigm is accessible to as many or more users than the current one. :-)
Exciting times.
Great stuff, I'm to try Qt Quick with the new Qt 4.7 alpha. By the way, that transition effect in which widgets fly around and fade that I keep seeing on every QML demo, well, it's just plain ugly. Someone had to say it.
I agree. I spent many years working on User Interfaces the old way. The designer sends a list of images and a screenshot of the UI and you spend the time to layout all the controls and skin the UI just so. But at the end of the day as a developer small things get changed for performance optimization and such and then the Designer finally sees the UI and informs you it is not what he wanted. Then he makes changes and things get re-coded .. repeat .. and so on. The development process takes much longer and everyone is frustrated. Having the Designer integrated into the development process and not just on the sidlines feeding images is where things are going.
Brian
Yeah, my comments are worth only 0.001 cent... as you will not like them...
1) Thomas Kuhn was interested in The Structure of Scientific Revolutions, and not in UI design.
2) The field of computer science in itself does not constitute a science.
3) Very funny, those who are studying computer science are not called scientists, but software engineers, software architects, programmers, etc.
4) A lot of programmers, the author of the above blog not being an exemption, have big egos, while they are having word diarrhea in proving their worth.
5) It appears to me that the blog's author skipped a course in UI design, which probably he thought too boring for born geniuses like himself.
6) I hope that Nokia employs top-notch graduates and not a bunch of primadonnas.
@Stephan, @Carina: Indeed most designable widgets are missing - however this will be version 1.0 and we'd like to get the general framework and primitive features right before we move onto the higher level components. I hope our early adopters will help us figure out how to proceed with reusable components.
@detro: Awesome! :-)
@Kensai: Yes, probably. If you make the design job easy, it will make life easy for designer-developers too. And QML is quite pleasant to work with for developers too.
@Philippe: That's true, but there's also a benefit to making a high-enough-level framework for it to be hard to make slow user interfaces. I think QML strikes the balance well, it can run 60fps UIs while still making good use of JavaScript. In perhaps a year or two or so I expect HTML engines to do the same.
@Tim: ;-) Actually we've got one more free spot for primadonnas.