Developer-designed UIs
This one is for all you developers out there: developer-designed UIs. Luckily I haven’t seen anything as bad as the wget interface in any of the FOSS stuff I use in a long time. Sometimes I wonder if the reason why a UI for GRUB has not yet been designed because people are afraid it would turn out like aforementioned interface.
Lately, I’ve been thinking of some of the issues with developers as designers. Developers are very text- and system-oriented, and feel more comfortable changing a config file they have complete control over than trusting an interface to do it for them. Users, on the other hand, are more visually oriented and often have no concept of the text- or system-based world the developers are so familiar with.
The barrier is well before placing widgets on the screen, during the conceptual phase where a translation of system functionality and graphical representation happens. Developers have a difficult time making this translation because they are so system oriented. Conversely, I have seen designers with the opposite problem; they have no idea how the system works and design difficult or impossible to implement interfaces.
So, I see two possible solutions in helping developers be good interface designers without relying on a designer to call on with questions (of which is not always readily available). One solution is to provide some kind of educational resource in basic HCI concepts so developers can be more aware of important human factors. This solution isn’t very realistic because training is expensive (time, money, resources), however, more and more computer science students have a human factors, HCI, or user interface requirement in their studies. My second solution (which is more practical), is to create very descriptive, heuristic-based guidelines which will help developers translate functionality without having to think like a designer or a user. This is perhaps a very ambitious goal for future revisions of the still-under-development KDE4 guidelines, but one can always plan for the future.
It makes you wonder what the world would be like with fewer FOSS designers than we already have. Then again, a designer is only as good as their ability to communicate with a developer.
“a UI for GRUB has not yet been designed” Is not strictly true. SUSE has had one for many years, I believe other distros like mandriva and probably fedora do too.
Now SUSE’s bootloader configuration module (which also works with lilo as well as grub) is not a great UI, It’s still too close to the text files for one thing, but it is also not as terrible as the examples you linked.
Designing a UI for something as complex as grub will no doubt be challenging.
It would probably be worth your while looking at it in your research. It does allow you to configure everything from the Location grub is installed to, to the resolution of the splash screen, to the order of the OSes to boot.
A live cd/dvd would allow you to look at it properly, and I’m sure the results of your research would be helpful to those maintaining it, and other existing GUIs for grub.
Here are some screenshots:
http://benjiweber.co.uk/screenshots/suse/yast/bootloader/
Ah, right. I was aware of that but it slipped my mind at the time. AFAIK there is no QT GRUB interface — hence why the effort :)
Well, yast is written in Qt :)
Have you taked a look at this book:
Designing Interfaces ?
I find it very interesting because it uses design patterns to teach how to build a correct user interface from an usability point of view, the design patterns are a very common tool and developers can build interfaces without thinking as an usability expert, just problem->pattern->solution. Very interesting approach.
I just know that there is an ui for wget !
I see that it is not included in ubuntu repositories.
=(
It’s a little ugly and seems incomplete, but its fine 4 me.
THANK YOU SEELE =)
Good Job!
“Developers are very text- and system-oriented, and feel more comfortable changing a config file”
Well it’s not completely true, I for myself dislike changing a config file, you usually have to go through a lot of doc or spend some time on google to find the basic stuff you want. On the other hand I am probably as bad as the wget GUI developer, while I won’t probably have produce a GUI as cluttered as the one in a first version, it would have been by laziness, but it’s very likely that the number of options would have increase following my needs.
I vote for your second option, a good HCI and easy to read would be a real help. But don’t throw away the first option either, a couple of good reference (books or links) in the introduction, or in a bibliography of the HCI is also a good idea.
Bah, everytime I read anything from HCI or Usability people it’s always a feels like a slow barrage of insults.
If you took an ordinary user and got them to design a form even just on paper, then they’d probably do a fairly poor job.
Given this quick thought experiment, and the thought-answer I thereby conclude that it has nothing to do with conceptual phase translation matrixes thingies, but simply that it’s just a bit hard to do and that it’s no more or less than any other bug.
UI experts complain that coders sometimes can’t help but think they are UI experts. But I think sometimes UI experts sometimes can’t help but think they are psychology experts.
That said, I always respect Celeste’s views and I think I might be reading a bit too much into the article.
Obviously there are some horrid GUIs out there I’m not going to deny that, what I would like to deny, or at least try, is that this is somehow the developer’s fault, or if not “fault” at least a lack of insight into the problem most of them have in common somehow.
Now, from experience I can tell that there are developers who fit the stereotype of the pimple-faced hacker who never sees any sunlight and who really wouldn’t waste a second of his life thinking about “users” (yech).
But speaking from that same experience I can also say that most developers I know are just normal guys who lead normal lives and try to do whatever they do to the best of their knowledge. This includes thinking about the users, strange as that may seem.
So how come that there still are so many GUIs where it seems obvious that the developer didn’t think about the user?
Well, that’s because making a GUI take a lot of time. Just think about any spreadsheet program for example. I wouldn’t be surprised if someone could fit all the functionality in a couple dozen KB of code. Of course nobody except a small group of experts would use it. So it’s the other 90+% of the code that is needed just to make it useful for the average user.
That is a pretty big commitment in time and effort to make. For someone “scratching an itch” it might be too much, but the same is true for companies trying to juggle a budget. (I’ve been in enough situations where my project manager said “it works, leave it like that”, it’s also why I don’t believe in “prototypes” anymore, they always wind up being the final product)
And _good_ GUIs are bloody hard to make!
In the examples you link to you have this Find/Replace dialog (I’m not going to talk about that monstrosity below it) which for me is a perfect example of a dialog that exactly what it should do with as little work as possible. If the problem is only with the fact that it is a “portrait” dialog I must admit I don’t see the problem, I’ve been in a number of usability programs studying the mice…ehh users and I’ve never heard anyone say “I don’t understand this window, it’s too vertical”.
Of course in a perfect world we’d have a) very clear user interface design guidelines and b) a system that easily supports making GUIs that adhere to those guidelines.
@JohnFlux
“But I think sometimes UI experts sometimes can’t help but think they are psychology experts”
Actually.. most traditional usability engineers are psychologists. Ellen is a pyschologist, I have training in cognitive psychology, and two of my coworkers (out of a company of four) have formal degrees in psychology (PhD and Masters). The industry has started to spread a bit as designers try to grab whatever they can to make themselves marketable, so you see a lot more practitioners without this kind of background.
@Alberto Ruiz
Designing Interfaces is actually a really good book for interface design, sortof like a dictionary of best practices. Another good book, if you’re interested in learning more about design, is Universal Principles of Design. It includes a lot of basic and random information which is applied to different types of design problems.
Seele, ah sorry. :-)
I agree fully with Quintesse. There’s always “this software is unusable because of just this bug - why don’t they fix it?” or “obviously the developers don’t care about disabled” or “they don’t care about performance” or “they don’t care about startup time” or “just this one extra feature would make it usuable” or “they don’t care about newbies since there’s no documentation” and so on.
Doing a nice GUI is one of a long list of things we have to do. But I have people send me bugs fixes, file wish reports, and even an artist sends me art occasionally.
But I don’t recall any usability experts filing any bugs or specific changes. The occasional (a few percent a maximum) bug report is about changing some default to make it more usable but that’s about it.
I think the solution is:
a) Stop blaming the developers. I’m sure it’s their fault, but so are the other hundred of thing. We know there are flaws
b) Stop mentioning developers that don’t care about users etc. I’m sure they exist in the minority, but they aren’t going to be caring what the blogs say, and frankly I’ve never met one of them.
c) Come up with a UI guide. File bugs against apps which violate it.
d) Encourage others to look for apps with violate the UI guide and file bugs/wishes/
e) If there’s a dialog that you (you being anyone) don’t like, then check with the developer (Help->about in the app) if you can improve it. If they agree (which they will) then find a UI person or whatever and design something better. Send the new design as a drawing if you have to, or better a .ui file. File a wish report with the picture / .ui file.
Of course, the problem as always is a lack of resources :-) Not enough Seele’s and Celeste’s and the other wonderful people.
@JohnFlux
I completely agree with you for the most part. Blaming developers for poor design is like blaming your sister for a bad haircut. Sure, some sisters might be good at cutting hair, but its not really their job so you can’t blame them when you don’t get what you want.
@everyone
The thing I’ve seen come up lately is the lack of bug reports. So I ask everyone: why do you like bug reports? Is it because they’re easy to manage with all the other stuff on your TODO list? I’ve heard complaints of usability people dropping reports in your lap and disappearing, and I’m interested to know what the difference is between an email and a bug report.
Bug reports make sure that each bug/feature is separate. If a user wants multiple changes then they have to file multiple bug reports. This tends to mean each request is self contained and has it’s own reasoning etc behind it.
There is the tracking side of it. Users can discuss and comment on requested changes. Developers can add notes on the technical difficulties, and so on. If the developer(s) decides not to implement/fix it, then they can at least mark it “WONTFIX” or some such.
It’s also easier for new developers. I’ve spent the last week fixing bugs from bug reports that are 4 years old! Disgraceful that they stayed unfixed that long perhaps, but the reports and comments survived several changes of developers.
Also there is a psychological side to it. Everyone likes to decrease the number of open bug reports. Whereas an email can be more easily ignored and then forgotten :-)
Hmm, just to add something to that separate thing..
If you find that you can’t really break down your report into separate bug/wish requests, then I think there’s a good chance it won’t be implemented.
It’s too easy to get burned with large commits. If I haven’t committed changes after a few days or a week at max, then it’s too long. And I want the code to be fully working and almost-shippable after every commit.
Whenever I break this rule, it always ends in tears
I disagree with that approach of dividing people into “developers” and “designers”. To become an excellent developer you just have to educate yourself about user interface design and usability. It’s not optional, every piece of software somehow interacts with it’s outside world, and most likely the outside world is composed of humans.
User Interfaces are a vast field, that goes down even to API Design IMHO. A poor API is a poor User Interface, and no “Designer” can help, because it’s the developers job to fix it.
Additionally, seperating the task of system development and user interface design into two different processes can be outright dangerous for the success of a concept, because UI and backend can interact intensely. You’ve mentioned the gap between “system functionality” and “graphical representation”, I agree that this is a problem, especially if there is nobody that knows both sides. I don’t want to sound negative, but a guideline will not likely bridge that gap.
This is of course only my opinion, but I think I’ve observed that poor systems translate into poor interfaces, because slapping a nice GUI on a crappy backend will not work. And I do not think that creating a userinterface, that is too far off the internal representation of the application-state, is a good thing. The user interface and the backend should be designed together, and often the interface dictates certain aspects in the backend, and the other way around. If a certain approach does not work in the backend for whatever reason, it’s a bad idea to try to let the UI pretend it can work.
Never the less, it’s good to know that people care, and I think that I generally agree to your definition of the problem. I just think that education and training is the right way to go, if you strive for excellence. And as a proud free and open source developer, I do. ;-)
Richard,
I think you are taking what was said as too strong.
Noone is suggesting that the GUI should work on a totally different model as the code underneath. That would indeed just be silly. I don’t really know where you got that from.
If a designer decides that the current GUI is just not fixable without a complete design model change, then well they’ll have to convince a developer to make large design changes :-)
A designer can help a lot, and I’ve already given lots of ways that designer experts can help.
I just thought of a feature that I think would be very nice for the GRUB front-end. Version Control. It would be nice to be able to go back a week ago to view a configuration option I had set. Actually this would be a great feature for all of KDE. Then I could search for configuration options and how I had them set at certain times. For a command line junkie who uses a SVN repository for configuration management, I know I would appreciate this feature handling all the dirty work for me.
@Benjamin Weber: Thank you for your screenshots. If you don’t mind I’ll use them on the https://wiki.ubuntu.com/KubuntuGrubconfig specification page for comparison. I know there are several GRUB configuration tools already (one for SUSE as a part of YAST2, one for Mandriva ) but ours tries to be simple, lightweight and comprehensible for the average user (the whole Ubuntu tries to be that way). It will also provide some features that other tools haven’t got. Furthermore, in my opinion porting the YAST2 tool to the Kubuntu environment would be quite difficult.
@everyone: Thanks for your comments and suggestions. Feedback is very important in every development cycle and your opinion is really important for me. (And yes, I’m trying to be the kind of developer who cares about user opinion as much as possible.)
what about adept graphical interface?
it looks horrible to me
http://img120.imageshack.us/img120/6846/pilt1iq1.png
@Seele
Please, can you talk about sketching tools?
Sorry if this message seem out of context.
see:
http://www.google.com.mx/search?hl=es&safe=off&q=sketching+tools+SILK&meta=lr%3Dlang_en
btw. for me, the worst GUI is that that doesn’t exists yet.
and the first one is ever ever ugly. =)
Good job Seele.
Plase, have a nice day.
=)
Martin J. Ponce
(spam not intended)
On Grub: It’s interesting how Grub operates differently from Lilo. It only has to be installed to the MBR once and it has the ability to read filesystems. I’m a fan of just leaving it alone. I like how Debian manages the configuration when i install a new kernel.
On blaming developers: I agree with John. It’s very easy to point a finger at developers and say, You’re doing it wrong. Developers know their software isn’t perfect. But on a project there are so many places that it can be improved beside the UI: features / functionality, installation process / integration with distributions, integration with other programs, documentation (of code and usage), security audits, and general bug fixes. So while it’s their responsibility to create good UIs, keep in mind that they got a lot of other stuff to do. I’ve filed over 200 bugs on my own project and it’s not even been published yet :)
On bug tracking: As a developer, i love it. It is the best system for users to communicate issues to developers. One reason for this is because it semanticly identifies things like category, version of software, environment, priority, resolution, attachments, severity. Developers can create reports base on this. And they can prioritize which bugs need to get fixed first.
On UI designers: My big hang up with UI designers is that sometimes they don’t understand the essence of a project. A UI designer must understand the prime-aspects [1] of an app; the parts that make it as complex as it has to be, but no more. I would say the prime aspects of wget are downloading, recursion, throttling, and spanning hosts. A designer should understand these concepts and the usage of wget intimately. What we see in the screenshot above is a 1 to 1 mapping of checkboxes to command line options. Nmapfe and wireshare are similar. (I’m so adamant about this because i’ve been tasked with designing a telecom web app, and i’m having difficulty because i don’t understand telecom yet.)
[1] Based on Roy Maddux’s concept of prime programs.
I agree with Richard here. A UI guideline is necessary but not sufficient.