As recently announced, an effort has been started for closer cooperation between the KDE and GNOME usability teams. The effort was announced in a message sent to the
[email protected]
mailinglist that was created for this purpose.
Original announcement by Aaron J. Seigo:
Seth Nickell (GNOME Usability Project), Havoc Pennington (Free Desktop, GNOME), and JP Schnapper-Casteras (Free Desktop Accessibility Working Group) and myself have been discussing the possibility of co-locating the KDE and GNOME Human Interface Guides (HIGs).
The plan as discussed thus far is to have the two documents co-inhabit one XML
document. Within this document, each HIG will have its own sections as
appropriate and will remain available for separate viewing. The goal is to
have one URL (on www.FreeDesktop.org) and one document for developers to go
to for KDE and GNOME Human Interface Guidelines. We hope this site can
eventually house guidelines for multiple desktops and graphical toolkits.
The easier we can make it for developers to discover and follow such
guidelines the better it will be for Open Source desktops in general. Since
KDE apps are often run on GNOME and vice versa, developers should be able to
easily reference the guidelines for all the desktops they expect their app to
be run on.
Having a shared document will also allow us to start looking at commonalities
between the documents and perhaps create common chapters or sections on basic
guidelines and lessons that are desktop and toolkit-independent (e.g.,
accessibility and internationalization tips, general usability principles).
It will take some work to merge the documents, create a web site, and raise
awareness about the site for developers and people working on other non-KDE
non-GNOME HIGs. If you wish to join us in these efforts, please subscribe to
the [email protected] email list via the web interface at:
https://listman.redhat.com/mailman/listinfo/open-hci/
Best wishes to everyone!
Comments
Only over my segfaulted body!
Being able to exchange documents correctly - any time !
Common file formats - heaven!
Idiocity-hooks for Gnumeric, GNOME-Office (wazzat?!), OO and KOffice -
are you nuts?!
Does this mean KDE will adopt double-clicking or that GNOME will adopt single-clicking?
Does it mean that KDE will switch around the button ordering on the dialog box or that GNOME will?
Really, I'm curious... How will those sorts of issues be resolved exactly? It would really suck for KDE to change its default behaviour... :-)
It will mean, that the groups will cooperate and discuss these issues in the future.
In the mean time, the differences will be documented. It will be easy to see what both HIG have in coimmon and what is different. Then application programmers can choose which one they follow.
The only possible disadvantage to single-click is the problem of selecting individual files. Yes, one can simply hold a modifier key and click but the beginning user is not going to know this.
KDE should enable the auto selection of icons by default.
Selection of a single file is a largely useless action, performed very rarely.
Launching (or however it is called nowadays) is the action most commonly performed, and the most useful.
Why bind the common and useful action to the hard-to-do, unintuitive double-click?
It would be like binding "save" to crtl-alt-shift-s and "search in all documents in the disk" to ctrl-s.
IMHO, it would even be a better idea (although still bad) to use double-click to select ;-)
I think you misread my comment. I am a supporter of single-click. However, under our current setup, auto selection is not enabled, making it harder for a user to pick an icon w/o holding down a modifier key.
I personally don't like it but since most newbies would benefit, KDE should enable auto select by default.
Oh, but why would anyone want to select ONE file?
Independently on what you like, activation should be done with
a double click because this is how Windows does it and 99% people are
used to Windows. Whether you like it or find it an Evil Conspiracy
from Redmond is irrelevant.
I will abstain from answering in the same tone you used, just because I'm a happy guy.
Perhaps you are oblivious to the concept of having two factors in a decision. In this case, there is one factor: familiarity, and there is another one, "rightness".
By familiarity, of course, we mean that if the user is familiar with double-click, he wants to keep on using it.
By "rightness", that double-click has problems which single-click lacks.
Now, familiarity here is, for example, less of a factor than in the case of button ordering, since most users use interfaces with single-click=launch every day, in the form of webpages, not to mention single-click being the KDE default since ever.
So, unlike the case of button ordering, we would not alienate our current user base by keeping single-click, but by changing, and it could be argued that the alienating factor of users coming from windows is diminished to some point.
On the other hand, the "rightness" factor for single-clicking is pretty obvious. I never saw someone fail to single-click, but I see them fail to double-click often. I see people single-click on icons and wait. Making single and double clicks do the same action erases any source of confusion. Have you ever seen a user double click a link in a webpage? I haven't (I know amaya uses double-click to open a link, but wea re talking sane software here).
So, this "rightness" factor seems to be clear, even if unmeasured so far.
Now, the whole decision about switching to double-click can be defined thus:
Is the alienating factor involved on switching now to double-click larger than the alientating factor involved on keeping single-click, plus the rightness factor of keeping single click?
That is the whole decision, and so far, we can only argue one side or the other based on personal guesses, informed or not.
Now, where did conspiracies enter? Nowhere. And I had made no mention of conspiracies in my previous posts.
So, I suggest you stop arguing with voices in your head and start arguing with actual people, me included.
This post presents, in a rational and comprehensible manner, the factors involved in the problem. Now hopefully it can be discussed properly. The problem with your post is that you take one side of the equation and declare it larger without even, apparently, understanding there is another side.
Well, this whole thing is very interesting. Keep in mind that I'm not some psycho, sitting at home and brewing government conspiricies, but one's gotta wonder, where did double click originate? My theory is that the government, which branch i don't know and don't care cause it's inconsequential, the "damage" is done, took interest in the home computer buisness shortly after it had built the frist internet like system. Shortly after this the "PC" or personal computer, which, might I add, is an acronym that the common person doesn't know what it stands for, came out on the market. Yes, so anyways, the government then influenced what we all know as the mouse. Gates, b4 he was mega sucessful recieved funding from the government to do research on the mouse. when they finally decided that it would be a sucessful thing to add to computers the government decided to mess with it. I mean really, think about it; who, in their right mind, would name a computer product after a vermin that is hated by the majority of the population? so anyways, the double click was born. I think that the government was just trying to see if they could get people to do something completely un-necessary. Might I note that this boarders on brain-washing. So that's what i think, tell me what ou think of my idea.
your whole theory on the double click makes sence, but did you really do all your research because it sounds like you are shalowly educated on what you are talking about. i do beleave that Gates is involved in the government, obviousley. but does he even know? i dont know there is just to much to think about when talking about the government and conspiricies, it is better to just not think about it because YOU WILL GO INSAINE.
It means that one should think about those issues.
It must be noted that you can pretty much change the button order in KDE with a one line patch :) In fact it is literally a matter of changing a 0 into a 1.
Hey, this makes a great contest, whoever posts the above patch first wins a virtual bottle of Beerenburg (tm)
Cheers,
Waldo
Aha, so it should be run-time dependent.
When running in KDE, all apps should use a certain button order, as expected by the user. When running in GNOME, all apps should use the expected order as well.
Good call.
It would be even nicer if the button order were configurable via the UI in both desktops. After all it's already possible to switch between single-click and double-click in KDE.
Do I win?
--- kdelibs/kdeui/kdialogbase.cpp.orig 2003-01-29 13:07:26.000000000 -0500
+++ kdelibs/kdeui/kdialogbase.cpp 2003-02-04 13:24:11.000000000 -0500
@@ -62,7 +62,7 @@
{
box = 0;
mask = 0;
- style = 0;
+ style = 1;
}
KPushButton *append( int key, const KGuiItem &item );
And the winner is..... Ravikiran Rajagopal!
Cheers,
Waldo
Except even parts of kdelibs don't use KDialogBase.
What about using the native (running desktop manager) dialogs? For example, the kde printing dialog. Why not have the apps call a 'system' routine that brings up the native one?
This would simplify things enormously. For a 'best of breed' desktop', one would probably run applications from all the different desktop managers.
I think this alone would create a much easier to use system.
Why is the mac held up as the paragon of ease of use? I have found it frustrating and counterintuitive. For example, I spent 10 minutes trying to find a terminal window with no success. Easy to use? Bah!
Derek
> Does this mean KDE will adopt double-clicking or that GNOME will
> adopt single-clicking?
My god, this is so ridiculous. I use single click
in GNOME, which has been available since Nautilus
started being GNOME's file manager.
Anyway, KDE doesn't own single click, nor GNOME
double click.
The whole thing about single/double click is ridiculous.
It's all about the *default* values. Nobody cares about clever hax0rs like you who can change the defaults, because most people don't.
Double-clicking is something that's pushed by Red Hat and is the default in GNOME. Single-clicking is the default in KDE.
> It's all about the *default* values. Nobody cares about
> clever hax0rs like you who can change the defaults,
> because most people don't.
Where did I say I´m a "clever hacker" ?
Don´t be ridiculos, putting words on
someone else´s mouth.
>
> Double-clicking is something that's pushed by Red Hat
> and is the default in GNOME. Single-clicking is the
> default in KDE.
Distributors are free to do what they want
with free sofware, as long as they comply
with the licenses used (GPL, etc).
If "single click" (wow!) is so important to
the KDE community, please, make an ammendment
to the KDE licenses saying so, and then you wont´t
need to be whining about it anymore.
I take back the assumption that you possess intelligence. Apologies... now go troll somewhere else.
You raise a very good point. On the one hand, Red Hat and its associates want the OK button in the bottom right based on "usability research." Yet most usability research DOES show that double-click is a skill that is quite difficult (and even impossible for some) to aquire. Yet, GNOME uses double-click. Makes no sense. Sounds more like aping Apple (pun not intended).
Really, folks, Apple is not THE source of all good design. The Dock is a piece of crap compared to the replacements one can find on the Internet.
Remove last year to reply...
It does? I'm running stock garnome, not tweaked single vs double click at all, and everything is single click.
Interesting to hear that. I haven't been able to get GNOME to compile recently so I haven't been keeping track.
Can anyone else confirm if this was changed in GNOME2.2?
i thought that you could change kde to support double clicking obviously kpersonaliser was lying ;-) - what would be the point if all wm's acted the same by default?
it's really encouraging to see the acceptance of this project here, on the GNOME discussion boards and even more importantly on the open-hci list itself.
it is very nice when people like Moritz, Waldo, Navindra, etc... understand what people are trying to accomplish. i was very disheartened by the noise on slashdot (we're trying to get a correction statement posted by them, btw), but when it comes to those actually involved it is very, very encouraging!
for everyone who is excited about this, please don't expect results immediately. give the project time to find its feet and actually get some work done. usability related discoveries are VERY slow going in my experience, often orders of magnitude slower than the actual coding required.
There have been enough problems with bad communication between the HCI people (some of whom have a clue, and some of whom...) and the developers. Do we really want to compound it by adding in a whole new bunch of HCI people who know nothing about the framework they're talking about? There are certainly areas where cooperation will help, but don't think this is cost-free exercise. It should be noted that I have seen similar problems in the communication between the Gnome HCI team and the Gnome developers, so it is by no means unique to KDE.
Another major issue, is avoiding designing a set of guidelines that simply lead to the lowest common denominator. This would be stupid as they would simply be ignored.
On balance, I tend to think this has the potential to be an unmitigated disaster. I hope to be proved wrong, but I have a lot of doubts.
Rich.
all things have the potential to be an unmitigated disaster. so we need to recognize the risks and try and avoid it.
i don't think ANYone thinks this is a "cost free" excersize. it takes effort; if it was cost free it would've been done ages ago. but this isn't an excersize in throwing "a bunch of HCI people into the mix who know nothing about the framework they're talking about". this is more like an online version of a conference where the topic is usability. we'll discuss usability from our own perspectives and frames of reference and draft commonly accessable documents reflecting that.
as for creating a "lowest common denominator" document, i think what you stated is a truism and quite obvious. we've already covered this issue and understand that we all prefer (documented) divergence in our guidelines over stupid comprimises. open-hci is grounded in reality, not pie-in-the-sky dreaming.
as for communication between KDE "HCI people" and KDE developers, i'm actually quite happy at how well it has gone. there have been very few problems and a lot of progress made. nothing is perfect, but i think there has been a great effort/results ratio. that ratio is improving as we learn how to make things work. remember that many of the people on kde-usability were KDE developers first and *then* joined the usability discussions. this is a key issue.
the GNOME HCI efforts have apparently been a little less effective, but that seems to be because the GNOME HCI people aren't GNOME developers, which is where kde-usability is quite different. on the other hand, they have more HCI professionals and greater access to usability labs and testing. hopefully both teams will be able to benefit from the other's strengths.
note that already there are offers for usability reports from actual labs that have been posted. we are expecting the first such set of material within the next few weeks. this is very, very encouraging.
I haven't noticed much of a tendency to CC maintainers when people start discussing their apps on kde-usability, so I don't think you can say there aren't communication problems
did i say there aren't communication problems, or did i say that it isn't perfect and that there have been problems but that the rate of such problems has been happily low in light of the results? i apologize if i tried to phrase it in an upbeat and optimistic manner.
you're right that often the maintainers aren't brought into discussions right at the start. it usually takes a lot of discussion, revision and time to get to a place where there is something worth looking at by the maintainer. it was decided that it would only annoy, discourage and/or consume the time of a maintainer if they sat through the discussion from the very start.
there is a policy of bringing in the maintainers once there is something resembling usefulness as most of us respect the time of volunteer developers. unfortunately some times this step has been skipped (either inadvertently or due to lack of experience), but kde-usability tries not to make that the case.
if you say, "but the maintainer might have important input to offer right from the beginning" i'd suggest that if they did they'd have done so ... there are those who do just that, after all.
> it was decided that it would only annoy, discourage and/or consume the time of
> a maintainer if they sat through the discussion from the very start.
Maybe so, however at least let them know there *is* a discussion, that way they have the opportunity to take part in it.
> i'd suggest that if they did they'd have done so ...
Again, that's fine if they have the opportunity. If you don't let them know there is a discussion though, they are denied that.
Rich.
ps. In theory this could even be done by a bot which monitored the number of times an app is mentioned.
> Maybe so, however at least let them know there *is* a discussion, that way they have
> the opportunity to take part in it.
fair enough. i'll let every developer know whenever there is a discussion concerning their code is being discussed (not mentioned, but discussed; i don't want to annoy people w/this after all). we will see how it goes.
as a related aside, several times after having been informed that there is discussion going on in kde-usability i've been told "cool. well, let me know how it turns out."
> In theory this could even be done by a bot which monitored the number of times an > app is mentioned.
heh... the suggestion of a true software developer! =)
> fair enough. i'll let every developer know whenever there is a discussion
> concerning their code is being discussed (not mentioned, but discussed; i don't
> want to annoy people w/this after all). we will see how it goes.
Thanks
> i've been told "cool. well, let me know how it turns out."
I can understand that attitude, but I think a lot of developers are interested in the disucussion, as well as the result.
Rich.
I have to agree with Rich on this, which I always felt put me in good company. ;-)
It would be very frustrating to have a laundry list presented to me on usability of Quanta when it's a closed discussion. In particular it would be frustrating because I use the program every day, sometimes all day and key design decisions have been made on the basis of expediting professional development. It would be more than a bit upsetting to have someone who is not actually coming from that level of use to offer suggestions, particularly if they ended up being in some way detrimental to our design decisions.
While I would like the program to be as usable as possible it could be useful to be able to make the case as to why some design decisions were made. That might make for a more useful outcome.
"closed discussion". ok, let's not start spreading FUD here. last i checked, kde-usability is open for subscription and archived. if you aren't sub'd to kde-devel and someone mentions quanta, does that make it a "closed discussion"? look at the threads on kde-usability where the maintainers/programmers are involved in the discussions. often these discussions continue AFTER a usability report is finished. this is not something that is discouraged, but encouraged.
a usability report is not a final destination, it is a step in a process. by itself it is just text and largel useless. to be useful it needs action taken, which includes further discovery and discussion as necessary as well as coding effort. a usability report is not the end of the line, it's somewhere in the middle.
often being very close to the program is a problem and it can (and often does) prevent one from seeing usability issues. a full history of a program isn't necessary to understand the usability of it, either. use cases, common guidelines and user testing are as well. do you need to know the whole history of a program to make a patch against a functionality bug? finally, suggestions are just that: suggestions. not edicts. not "you must now do this. NOW!".
it really surprises me how uptight some developers are about others discussing and forming opinions on their work without them be right there to hold everyone's hand.
it also really surprises me how some developers who will gladly accept a patch fixing a functionality bug as a sign of usage and support will shun a usability patch as an insult if they weren't in it from the begining.
perhaps it's because some developers lack a concept of the process involved. would it help if a document explaining how it works was drafted up to alleviate worry about "closed discussions" and other non-issues?
Let me start off by saying that I have a great deal of respect for you and appreciate what you're doing. Having said that I can say that you seem to have taken what I said out of context and then used it as a platform to make some less than flattering observations about "some developers" of which I am not entirely sure I'm supposed to fit it. Perhaps a little more diplomatic caution might safeguard that "respect equity". ;-)
First off by closed discussions I did not mean, closed as in shut out. That would be absurd. This is after all open source and one would have to be a bit touched not to know the lists were open and reactionary to make such a statement. I can't even begin to think of responding to the absurdity of mentioning FUD here so I will pass on that. By closed I meant the entire process of review and forming an opinion by many had begun and ended and moved on by the time a developer knew about it. It only takes a little reading the news to see how opinions can take on a life of their own with mob mentality in the Linux community. While I have a great deal of respect for the people involved with KDE I also recognize the dynamics of mental and communication processes.
While these discussions may be open I have several lists I already subscribe to. I also am self employed and run a business (actually two) and manage a project that can easily add 20-30 hours to a work week that can easily consume my waking hours. I don't know why this is so hard to grasp... I don't have time to subscribe to every list that might at some time discuss my project! You would know this and more if you subscribed to our list. ;-)
I feel your other statements are quite unfair too regarding uptight developers and a supposed perceived need for a history of a program. My concerns are that I want to be a member of the community with a good reputation for being a team player while I also want to be sure key areas of my vision for our project are preserved. My thinking was that usability implies use. What may appear more usable on a cursory examination may or may not stand up under heavy use. If I were observing the discussion I could provide input in such cases that might affect the recommendation and this could in turn affect further parts of the review for all we know. It is after all reasonable to assume that interface changes would have an affect on usage. Hopefully a good one, but if elements of use of the program were not understood it is logical to assume the recommended changes could be detrimental to the program objectives. That would place me in the position of having to take time to defend my thinking... It seems rational to tomake the case, should one need to be made, early on.
I've not been aware of any usability studies of our program but I would find them interesting reading. We have already made usability changes to Quanta based on user feedback. I believe my attitude would be very similar to what I've read of yours regarding such things as single click/double click, a point I happen to be very much in agreement with you on. In fact I have overseen the interface design of Quanta for some time and our critera are as follows:
1) Interface operations MUST allow for maximal user throughput. Efficiency is rule one.
2) Interface operations must provide the highest level of control that can be reduced to the most simple presentation.
3) Standard interface conventions are the goal.
4) Any new interface feature is juried on whether it brings significant benefit or adds unneeded complexity. Quanta is *very* user extensible.
5) All design operations must allow maximum control to the user and must not unduly constrict their usage WRT behavior or focus.
As far as the process goes, I think I can sum it up like this. It would be good if the process brought out good and useful ideas and was relatively efficient so as not to take away from other areas. It would not be so good if the process resulted in a number of suggestions that were in contradiction to our interface criteria and we ended up looking like we were unresponsive to our users for not accepting them. We must also remember that we are also dealing with a large user base now that is accustomed to how things are and that has lots of fun scenarios as well.
I look forward to the advancement of our common cause and I ask that in the future you give me a little more benefit of the doubt.
> By closed I meant the entire process of review and forming an opinion by many
> had begun and ended and moved on by the time a developer knew about it. It
as i noted, usability reports are not the end of the process, but somewhere in the middle of the process. a usability report is not a finished item of work, it is a living document that requires input from the stakeholders and ongoing review and revision.
an example is the kopete usability report i'm currently maintaining. some of the issues raised were dropped or modified after further discussion with the developers involved. some issues have been addressed. the usability report needs to be updated in a timely fashion to reflect that.
so no, it is not a closed discussion.
> only takes a little reading the news to see how opinions can take on a life of their
> own with mob mentality in the Linux community. While I have a great deal of
> respect for the people involved with KDE I also recognize the dynamics of mental
> and communication processes.
which is why i'm concerned when developers start saying things like "the usability process results reflect closed conversations". we already deal with enough resistence from various people when it comes to usability issues (though it is getting better and better all the time) without encouraging those behaviours.
as for my statements regarding "some developers", those are reflections of actual experiences. it is a vocal and difficult to deal with minority of developers whose attitude usually can be summed up by "don't change things. users should be smarter. i like it the way it is. usability studies and published research don't match my instincts."
> but if elements of use of the program were not understood it is logical to assume
> the recommended changes could be detrimental to the program objectives. That
> would place me in the position of having to take time to defend my thinking... It
> seems rational to tomake the case, should one need to be made, early on.
can we discover the "elements of use" of a program as well as an author? this can be accomplished by observing people using it for the first time as well as those using it for the 100th time. i do understand and appreciate your position of authority when it comes to how the program is (supposed to be) used, since you probably are more intimate with it than anyone else. it may occur over the course of exploring Quanta that i come up with the exact same use cases and patterns you have while developing it; or one of us may have missed something.
starting with fresh eyes allows one to explore without the prejudice of prior knowledge, and that often leads to new perspectives that are equally valid to those currently held.
it also takes time for me in concert with others looking at the program being examined to arrive at useful conclusions. those useful conclusions may arrive at the same place you, the author, already have. which is good as that likely means those patterns should be reinforced and noted for further application elsewhere.
you say you have limited time to describe your thinking ("defend" implies a confrontation that does not exist) and i respect that. which is why i usually don't bother with dragging the maintainer into threads that span several weeks or with the day-to-day status of user testing that i'm doing. the maintainer gets a work-in-progress report once it's at a point that their input will be the most efficacious. it's much like presenting a patch once you've thought through the implementation of it, compiled it and debugged it locally. do you prefer to see half-baked concepts or fully thought out concepts?
perhaps ask the kopete developers if having the usability report delivered once i had a completed draft to show them resulted in lots of wasted time? actual experience trumps theory, so i think we should look at actual experience.
also remember that action resulting from a usability report takes place only after consultation with the maintainer (if they are interested and can be found). i know of a couple cases where unfortunately this didn't happen and it resulted in bad things and i think everyone on kde-usability learned from it.
as for your 5 point list, i agree with each and every one of them. it is great when developers put such care and thought into their interfaces. this is happening more and more and is a great thing.
> It would not be so good if the process resulted in a number of suggestions that
> were in contradiction to our interface criteria and we ended up looking like we
> were unresponsive to our users for not accepting them.
agreed. so the question is: does this actually happen? i think most usability work to date has been in agreement with rather than at odds with the design of the software in question. and you are free to ignore anything you wish, just as with any development suggestion/patch. this is not user -> developer communication, but developer <-> developer communication.
a usability report isn't the result of a popular opinion poll, but the result of examination from an HCI perspective that is often (if not always) coupled with user testing. this means taking the technical implications into consideration, knowing that it may be up to the reported to provide patches for some items, etc..
> We must also remember that we are also dealing with a large user base now that
> is accustomed to how things are and that has lots of fun scenarios as well.
then it's good thing that we take that into consideration when examining usability and trying to improve it. i'd LOVE to see the bookmarks menu in KFD go away, but the user base that relies on it's specific use pattern is too large and valuable.
as i said, i think a lot of the reservations some developers have regarding the process are a result of not understanding the process we take. and that's understandable as i've never actually formally communicated that process. and that probably adds to the fear, uncertainty and doubt that some developers hold towards usability efforts.
whether or not "some developers" includes you, i don't know. i think it is best if each is left to examine themself.
> > By closed I meant the entire process of review and forming an opinion by many
> > had begun and ended and moved on by the time a developer knew about it. It
> as i noted, usability reports are not the end of the process, but somewhere in the
> middle of the process. a usability report is not a finished item of work, it is a living
> document that requires input from the stakeholders and ongoing review and revision.
Obviously that would make a difference. Not having been involved in the process and given the record of some projects ebb and flow of energy it is not unreasonable in the absence of other information to assume a report would be issued, findings made and that's it. If it can't be closed then it would not fit either definition. As sensible as it seemed it appears by your definition I'm in error. If that is the case I apologize.
> which is why i'm concerned when developers start saying things like "the usability
> process results reflect closed conversations". we already deal with enough resistence
> from various people when it comes to usability issues (though it is getting better and
> better all the time) without encouraging those behaviours.
Obviously you caught me in an assumption, which was also based on comments from Rich. It certainly appears to me that there may have been some assumptions in both directions looking at some of the generalizations used.
> > but if elements of use of the program were not understood it is logical to assume
> > the recommended changes could be detrimental to the program objectives. That
> > would place me in the position of having to take time to defend my thinking... It
> > seems rational to tomake the case, should one need to be made, early on.
> can we discover the "elements of use" of a program as well as an author? this can
> be accomplished by observing people using it for the first time as well as those using
> it for the 100th time.
That's a good question. We try to push the envelope in capabilities and frankly I am not sure how much is usability or how much is just wanting to fall into familiar patterns and avoid what is new. I've yet to see a review of Quanta that did not miss features primarily because the reviewer did not get in depth. Does that mean they are not clear? I doubt that as users often mention those features. I suspect it is more that people don't actually use a number of features until they really get to the point where a need pushes them there. Features like templates, scoped toolbars, programmable actions and such. I think we've done a fairly good job here but the truth is I think what is needed would be more definitive examples and samples of use to get people to think into higher possibilities... something we are looking to do. How would usability fare in these less used areas? It's a good question. a better one is if it would make a difference. Of course some areas we just have not gotten to optimizing too but that doesn't mean suggestions would not be interesting.
So in reality you could put a newbie in front of Quanta and make an assessment and come up with lots of data. However one of my larger concerns is with implementation of some of the newer more powerful features that only an activly involved entrenched web developer would need or explore. I'd hate to have the process miss points. If anything when your feature set grows there is little you can do to avoid people missing somethinng that is right in front of their face.
All I want is good data. In fact one of my challenges is having a feature set large enough that I need more people developing with our CVS version and feeding back. It is only getting more challenging and time consuming... so rather than being uninterested i'm interested in thorough and complete data and useful suggestions. We're only human.
> starting with fresh eyes allows one to explore without the prejudice of prior
> knowledge, and that often leads to new perspectives that are equally valid to those
> currently held.
Certainly, but I want to be sure a representative user spectrum is covered. As we expand our features and scripting and markup languages this becomes more and more difficult.
> it also takes time for me in concert with others looking at the program being
> examined to arrive at useful conclusions. those useful conclusions may arrive at the
> same place you, the author, already have. which is good as that likely means those
> patterns should be reinforced and noted for further application elsewhere.
That would be be an honor I'm sure, but I chose KDE because it was apparent that both architecture and interface design considerations were easily among the very best I'd ever seen. That and the people are why i'm so proudto be affiliated with this group.
> you say you have limited time to describe your thinking ("defend" implies a
> confrontation that does not exist) and i respect that. which is why i usually don't
> bother with dragging the maintainer into threads that span several weeks or with the
> day-to-day status of user testing that i'm doing. the maintainer gets a
> work-in-progress report once it's at a point that their input will be the most efficacious.
In light of what you've revealed about the process that seems to make more sense. however to take it a step further I would think you would still contact a developer first and ask if they have areas of concern where they want to be sure adequate focus is given. In my case I think it is possible some exhange here might be beneficial and also help to expedite your process. If it is a two way process then this seems logical.
> as for your 5 point list, i agree with each and every one of them. it is great when
> developers put such care and thought into their interfaces. this is happening more
> and more and is a great thing.
Thank you, but frankly if not for that core thinking I wouldn't even be bothering to produce a program. My objective is to create the first killer app on KDE that has web developers coming en masse. Given that it's hard to know everyone in the community and follow everything I hardly expect you'd know that. However given that perspective you would tend to expect I wanted to make any rational improvement possible... that or I was delusional. ;-)
> > It would not be so good if the process resulted in a number of suggestions that
> > were in contradiction to our interface criteria and we ended up looking like we
> > were unresponsive to our users for not accepting them.
> agreed. so the question is: does this actually happen? i think most usability work to
> date has been in agreement with rather than at odds with the design of the software
> in question. and you are free to ignore anything you wish, just as with any
> development suggestion/patch. this is not user -> developer communication, but
> developer <-> developer communication.
Again this just supports the fact that I want to get through the "hoops of process" looking like a great guy without internally conflicting myself. Unfortunately I'm operating in a vacuum until I step in and find out if it's a dentist chair or somethig a little more fun.
> as i said, i think a lot of the reservations some developers have regarding the
> process are a result of not understanding the process we take.
I suggest you convert that from a hypothetical to an absolute. ;-) I would suggest the "usability" of your usability program would be better served by a brief description of the process which you can make available, perhaps including testimonials if you think they are good. When the currency of open source is the pride in what you do there is an obvious, but not insurmountable, element of diplomacy in your work.
> whether or not "some developers" includes you, i don't know. i think it is best if each
> is left to examine themself.
Clearly I was not the developers from past experiences. Being a pragmatic business owner in my 40s with substantial marketing experience makes me an odd duck among developers. Many of the people I greatly admire are young enough to be my son. Given that my sole objective all along has been to create the best of class application I would maintain the "some developer" comments fell short of your usual high standards. Usually when I begin generalizing at people I take a break get some air and then do the diplomatic thing. Of course I can be cantankerous the rest of the time. ;-)
Hopefully what you will take away from this is that I am not "some developers", I probably think very much like you in terms of usability and I am totally committed to excellence. I am probably as committed and accessible as anyone heading up an app/package in KDE. I'm certainly aware of the immense benefits KDE provides me in my effort.
Thanks for your efforts and addressing my concerns.
I am pretty sure you know pretty well how hard it is to keep track of all development lists -- after all you've edited the KC KDE. And thus surely, you can't expect everyone to be subscribed to kde-usability (and now also open-hci !); and if they aren't, how will they be aware of the discussion from the beginning until they are told of it?
i don't expect them to be aware of the discussion on kde-usability.
it's simply a fact that some developers don't have much interest in examining the usability of their interface or don't have enough time to look into it too deeply. those that do often discuss it either on the respective -devel list or in a usability forum. and that's what i meant: those who care to spend a lot of time on this topic do. those who don't, don't. i don't expect me sending emails to each maintainer is going to change that very much. it may help alert those who do find it interesting and do have the time to get involved, though.
I think you're mistaken Aaron. On the contrary,the Gnome HCI developers have been extremely effective. They've managed to streamline common GNOME interfaces and are respected by the GNOME hackers. In fact, increasing numbers of GNOME projects ask for UI guidance during their development process in order to make life easier for _users_.
hey, i'm just repeating what i've been told by GNOME HCI folk themselves. you may note that i didn't say they were innefective, nor are the less effective in all things. i note they have more HCI professionals and that i see that as a benefit. rather, the approach of "engineers write code, HCI-interested people document and provide feedback" is different than the approach of "developers write code, developers examine and provide patches" and that the latter seems to result in changes more quickly.
i'm aware that many GNOME developers are interested in and are taking an active part in usability issues, as are Free Software developers in general it seems. and this is Good. open-hci wouldn't exist without that sentiment.
i also noted that i think both groups can learn from and take advantage of the strengths of the others.
(starting to get off-topic)
so is my writing that bad, or are people just that uptight about these topics? and is this why so little has been done usability-wise in the Free Software world?
(fully diverging)
someone pops up with eye candy feature #40020, or yet another app feature and people ooh-and-ah. but try working on refining what exists rather than slapping down new code and see how much more difficult and unrewarding it is due to the people issues involved.
'creating a "lowest common denominator" document, i think what you stated is a truism and quite obvious' - you may think that, but looking at the people on the list, aren't they the same ones who broke KDE on RedHat? I'm told they also removed a lot of good UI features from the RH KDE in the name of consistency. This is hardly a good start.
'as for communication between KDE "HCI people" and KDE developers, i'm actually quite happy at how well it has gone.', as you know the people on the UI list have managed to infuriate me a number of times (and have consistently failed to look at the discussions of the kde-look list that preceeded kde-usability) so I am a lot less happy than you are. That said, the signal to noise ratio coming out of the list has improved, so perhaps there is hope.
'the GNOME HCI efforts have apparently been a little less effective, but that seems to be because the GNOME HCI people aren't GNOME developers'. I agree they have been less effective, but I think you've got the wrong reason. KDE has made a lot of progress in it's UI design by writing the libraries in such a way as to make the default behaviour correct - for example XMLGUI, KStdAction, KDialog and to a lesser extent KDialogBase. This approach has made it easy for developers to do 'the right thing' and has made things work such that doing the wrong thing is more work. The Gnome framework I AFAIK has not been designed this way.
I remain skeptical, but I have joined the new list to see what happens.
Rich.
> you may think that, but looking at the people on the list, aren't they the same ones
> who broke KDE on RedHat? I'm told they also removed a lot of good UI features
> from the RH KDE in the name of consistency. This is hardly a good start.
waldo and i broke KDE on RH? *snicker* seriously though, some of the GNOME people on that list aren't in RH's employ and had literaly nothing to do with KDE anywhere, let alone in RH. some people on the list don't have involvement with either project. yes, there are people on that list who are directly responsible for KDE in RH. but rather than seeing that as a negative thing, i see it as a potential means to help shorten the gap between their decision making and KDE's best interests.
> as you know the people on the UI list have managed to infuriate me a number of
> times
let me reassure you that it goes both ways. i've run into some very uncooperative and uncaring developers. so shit happens. that's what beer, music and other such things are for. =)
> That said, the signal to noise ratio coming out of the list has improved, so perhaps
> there is hope.
i'm glad that this trend is apparent to others besides myself... it means i may not be as completely loopy as some might think ;-)
> KDE has made a lot of progress in it's UI design by writing the libraries in such a way
> as to make the default behaviour correct
>The Gnome framework I AFAIK has not been designed this way.
agreed 110%. i think that at all the people who have worked on KDE's framework over the last 5 years deserve a HUGE amount of respect for how well they designed things. it can be, and is being made, better in all sorts of ways, but the foundation is a solid one and there is a LOT that is very good about it. this is a slightly different issue than what i was refering to, however.
> i've run into some very uncooperative and uncaring developers.
I think one reason for this is likely to be that the developers are often brought into the discussions much too late. If they were included earlier, I think the majority would be happy to work with the UI list. At the moment though, things don't seem to work that way.
> it means i may not be as completely loopy as some might think ;-)
No, no don't take one isolated example to mean that! :-)
> the foundation is a solid one and there is a LOT that is very good about it. this is
> a slightly different issue than what i was refering to, however.
What I was trying to say was that I think designing the framework to make common standards the defaults was why we reached the current (fairly high IMHO) level of standardisation on accepted UI designs. I think *that* has been the crucial factor in making UI design work effective.
Rich.
I think it's a very good idea. My suggestions for an agenda:
1) Common agreement as to mimetype data and where they're stored
2) Creation of uniform theme plugin structure, just like the Netscape standard can be used by Motif, Qt, GTK. All pixmap themes must be destroyed, or at the very least, a uniform widget set agreed upon.
3) Agreement on what icon theme format. SVG must become standard.
4) Move to single-click with automatic individual icon selection. This is more important than OK/Cancel debates. The research clearly indicates superiority of single-click.
5) Display of mountable devices. KDE still is buggy WRT this. Nautilus has a better implementation. Mod-click desktop, choose device you want. KDE should copy.
6) In-place menu editing.
Would KDE users be willing to "trade" single-click in GNOME for OK in the bottom right in KDE?
1) Out of scope for an HCI group.
2) Out of scope for an HCI group (and wouldn't work very well anyway).
3) Why /must/ SVG become standard? I see some advantages to it, but for small icons + low powered machines I think bitmaps will be a lot more efficient.
4) We already use single click. We don't use automatic activation though (and personally I hate it).
5) What on earth are you talking about?
6) I'm still not convinced this is the best way to handle menu editting, but at least this is in scope.
Regarding your last point, you seem to have totally misunderstood the idea. It is not a forum for horse trading UI elements (and if it becomes one then it has failed IMHO).
Rich.
1&2: As far as the mimetype stuff goes, while it isn't exclusively (or even mainly) the province of an HCI group, a common infrastructure must be fitted into the UI so that a user can modify mimetypes in both environments.
3: I agree that low-powered machines should not use SVG. But for anyone running about a Pentium II 300, it should be default. There is no reason why we cannot ask the user (or administrator) to specify which to use. Perhaps one theme for low-powered devices can be created but it is too much of a hassle for artists to have to create PNGs for five different sizes.
4: _We_ use single-click but GNOME (last time I checked which was a while ago) is still on double-click. This should be changed.
5: You don't know what I mean by mountable devices? I am talking about the function where user is able to mount any device he has permissions to according to the systems fstab. Right now, it is a lot more convenient to mount stuff in GNOME than in KDE since all mounted volumes show up on the Nautilus desktop. Unmounted volumes can be mounted simply by right-clicking on the desktop and choosing it from a submenu. The KDE way is not as intuitive.
6: Granted not everyone likes in-place, however, it should be there as an option for quick editing and for those accustomed to it in other operating environments.
7: I agree that autoselect is irritating. (I never use it myself.) However, the newbie user will NEVER figure out that she needs to hold down a modifier key and click an icon to select it w/o activating it. The power user can disable it but it is very nice for the beginner.
7. Why would a user need to select a single icon?
And he can also select it by boxing it.