CONFLICT in HCI Field: Computer Science vs. Psychology
Yarone Goren
touched upon:
"Donald A. Norman" <d...@jnd.org> wrote in message
news:eUIW7.7217...@rwcrnsc51.ops.asp.att.net...
>
> The user should need to learn the tasks, not the tools. (This is actually
> more complex, but to explain would take a book. (e.g., we spent a lot of
> time as kids learning to use pencil, crayons, and pens.)
>
More specifically, I see a huge conflict in the HCI field between the role
of Computer Science and the role of Psychology. Most HCI courses, programs,
or research I run into invloves coming up with newer, novel, and more
"effective" software strategies. Usability Tests are conducted in order to
test the effectiveness of one particular strategy vs. another (Example,
Browser-based interface vs. Native Windows Interface).
Although these things are important, I feel that the REAL issue at hand is
largely being ignored. THE BOTTOM LINE: The purpose of technology is to
make life easier. More specifically, to simplify a particular task or set
of tasks.
As such, software is not very interesting. It is merely a tool for
accomplishing the goal; a tool for IMPLEMENTING the goal. What's more,
history has shown as that the tools we use for accomplishing our goals
constantly change, and I predict that they will continue to do so.
So, what is REALLY interesting, and what is REALLY important, is discovering
(or should I say, "working towards") the IDEAL way to accomplish our goals.
FORGET ABOUT THE IMPLEMENTATION! It is absolutely SECONDARY! It should be
of no interest to us; what's more, we should make a conscious effort to
completely block it, and it's inherent set of limitations, out of our mind.
Only later, after we have meticulously (with solid engineering methodology)
beaten the hell out of IDEAL solution, tested it using all known human ways
and means, should we even think about adapting our IDEAL solution to the
constraints of the implementation (which, in our case, is usually software).
SO, exactly HERE is where I see the conflict between Computer Science and
Psychology in the field of HCI.
Computer Science focuses way, way, way too much on the implementation!
Computer Science students who take HCI courses, or even Computer Science
PROFESSORS who teach HCI courses, LIVE in the world of software. Their
brains are immersed in the idea of software. When they are asked to develop
a program, they start off in the world of software and try to make their way
into ADAPTING the WORK DOMAIN (the set of tasks they are trying to simplify
or automate) INTO their world of SOFTWARE.
Psychology students and professors work precisely in the opposite direction.
Their brains are immersed in the idea of understanding human behavior and
thoughts. As such, they start off with a solid conceptual model of the WORK
DOMAIN, and try to make their way into the world of SOFTWARE.
So, in brief:
Computer Science moves from Software --> Work Domain.
Psychology moves from Work Domain --> Software.
Clearly, the field of Psychology takes the correct and logical approach,
while the field of Computer Science does not. The fact that poor
requirements analysis is the primary reason why most software projects FAIL,
serves to prove this point. (I can also give you a laundry list of reasons
why Programmers, by nature, "support" this continual failure...)
HCI is unfairly weighted into the realm of Computer Science. Instead, it
should be leaning more towards the world of Psychology.
Computer Science students do not know what HCI really means. Their
curriculum and professors push them towards the process of "coding." The
ongoing "crisis" of consistant failures in the software industry will
continue until computer science professionals stop thinking, myopically, in
terms of software all of the time.
What we need are Software Engineers, whose first and foremost goals and
obligations are to understand the dynamics of the work domain.
Secondly (and less importantly) they must know enough about the different
implementation strategies in this world in order to make good decisions.
Looking forward to your thoughts on the issue,
Yarone Goren
yar...@yarone.com
BACKGROUND INFO (FOR PERSPECTIVE)
I have had a huge interest in software usability, HCI, and Human Factors for
my entire life, following the work of HCI professionals very closely. I
have been programming for about 8 years, 4 of which I did so professionally
(= actual engineering principles). More recently, I have worked as a
Business Development Consultant with start-ups and venture capital firms,
both in the U.S. and abroad, emphasizing to them my above stated "purpose"
of technology. I am looking to get my Masters in psychology, with a heavy
emphasis on HCI)
Terry Eden
"Yarone Goren" <yar...@yarone.com> wrote in message
news:e2176f53.02020...@posting.google.com...
> What we need are Software Engineers, whose first and foremost goals and
> obligations are to understand the dynamics of the work domain.
That's only half the solution. One of the problems I've encountered is that
most people (users and, to an extend, designers) are socially conditioned to
believe that tasks should be difficult. They expect a learning curve that
isn't always logical. It stems from childhood when we don't understand
something and are told "that's just the way it is".
Users have become conditioned into accepting a hundred page manual for
toaster ovens because, often, underlying tasks are complex and so they
expect the method to accomplish such tasks require complexity.
Take writing a letter. The actual business which counts (the thinking of
what you want to say, ordering it into sentences etc) is fairly difficult
for most people. The business of learning to write takes a few years to
master. So, why should using a radically different paradigm (Word
Processor) be any different?
As for designers, ignoring the fact that we are usually designing for people
unlike ourselves, we have to work within the existing framework of
usability/acceptability.
Take the usability difference between Windows, Mac and Linux - the uproar if
someone develops an application based on the usability of a different system
is immense. Now imagine if you develop an entirely new way of working that
is radically different but, technically, easier to use? Transition scares
people.
At the moment I'm working on a research project looking into ubiquitous
computing. One of the things I've found is that people:
a) Can't focus on the task rather than the tools - they've been conditioned
that the tool is the task.
b) Find change, even for the better, scary - The tool is the task
I think what needs to happen is a gradual progression. Even if every
developer in the world suddenly got turned on to the idea of HCI - the shock
to the system would be incredible! Two examples
1) Windows - I find it gets easier to use each version. But it also retains
an [annoying] amount of legacy usability to help wean people into a new way
of working.
2) Palm Pilot. A fairly different approach to computing which symbioses
nicely with existing technology.
As for your "Code Focused" schools. I couldn't agree more. Most schools
separate students into either Code Monkeys or Grad Students. One day,
everyone's first lesson in CompSci will be "Usability 101"... one day!
Terry Eden
--
"What kind of world only has two Beatles?"
To reply, replace deadspam.com with uea.ac.uk
Yarone Goren
I completely agree with you.
Also, in regards to the following:
"Terry Eden" <T.E...@deadspam.com> wrote in message
news:<a3usoq$1b6smb$1...@ID-89774.news.dfncis.de>...
> One of the things I've found is that people:
> a) Can't focus on the task rather than the tools - they've been
conditioned
> that the tool is the task.
> b) Find change, even for the better, scary - The tool is the task
Kim Vicente, in his book "Cognitive Work Analysis" discusses this point. He
goes into detail explaining that although Information Technology spending
has increased steadily for the last 30 years, increases in PRODUCTIVITY have
not. In fact, he argues that productivity has DECLINED.
He makes the same point, as you did, that user's will often conform to the
tools. Given the general outcome of most software projects, this clearly
can be bad.
Kim, however, offers a bit of optimism. He suggests that if we can develop
excellent software products, the user's tendency to conform to the tools can
serve as a huge advantage to increasing productivity.
- Yarone Goren
- yar...@yarone.com
Jeff Chapman
YG> The purpose of technology is to make life easier. More
specifically,
YG> to simplify a particular task or set of tasks.
Hmmm. Well, perhaps ideally. Human sociology can be quite a bit more
complex than this, however. Many places where I've worked have
developed a culture of "technological snobbery," where the use of
technology confers higher "status" to those folks who are most
"technological." BTW this is true in many fields (without the
"technological") -- that is, humans have a tendency to place value on
/something/ (say, mathematical ability), and then folks with the same
inklings congregate together and end up promoting their skills as the
"ends", rather than the "means." I can think of places where I've
worked where traits such as "compassion," "wealth," "looks," "wit," et
cetera actually took precedence over legitimate business objectives.
YG> As such, software is ... merely a tool for accomplishing the goal
...
Again, thousands of folks are pundits for the particular software they
use -- it becomes much more than a tool and more of a religion. The
same is true for languages -- there's a giant discussion currently
occurring in soc.culture.indian (see:
http://groups.google.com/groups?hl=en&th=3d5757e9e7621eff&rnum=1)
about the use of English in India; extreme feelings on all sides.
After all, language is only a tool. Or is it?
Best regards,
Jeff
R.Mayers
news:333edd34.02020...@posting.google.com...
> Many places where I've worked have
> developed a culture of "technological snobbery," where the use of
> technology confers higher "status" to those folks who are most
> "technological."
> Again, thousands of folks are pundits for the particular software they
> use -- it becomes much more than a tool and more of a religion.
Hi Jeff,
Let me look at this from a distance.
Should we, as designers, just conform to the 'snobbery' you mentioned above?
Should we conform to the 'religion' you mention? Indeed, people tend to
attach value to belonging together and to things they have from the past.
But should that stand in the way of new developments? Should people get
(from the past) what they don't want (but already got used to) or get (from
the future) what they do want (but are maybe not yet used to)?
Yes, change causes resistance.. But then again, maybe people are just
unaware of what they really want.
I'm sure of one thing: if designers in the past had conformed to these
phenomena, we would not have a lot of the technology around we have today
(yes, this also holds in territories other than technology).
My point: the author who started this thread makes a point; think twice
before conforming to the world as it is accepted now.
Greets,
Rob
Sharon Curtis
Terry Eden <T.E...@deadspam.com> wrote:
>As for your "Code Focused" schools. I couldn't agree more. Most schools
>separate students into either Code Monkeys or Grad Students. One day,
>everyone's first lesson in CompSci will be "Usability 101"... one day!
*grin*
We've just put usability in as a substantial part (1/3rd) of
our 1st programming course that we teach to Computing Science students.
You may be interested to know that part of the reason why was a
consideration of "Know Thy User" - typical students for the
programming course include not only computing students but also those
studying computing as a second or third subject, some of whom might
have chosen computing as a "least worst" option. The idea is that
even if they don't get on with the programming part of the course,
the usability part of the course will give them something that they
can get their heads round, and will be useful to them whether they
end up computer programmers, journalists, managers, or whatever.
It's the first year we're doing this, and I'm the one implementing it.
Should be fun!
Terry Eden
news:a48vu4$82t$1...@peseta.cs.stir.ac.uk...
> *grin*
> We've just put usability in as a substantial part (1/3rd) of
> our 1st programming course that we teach to Computing Science students.
Wow! I hope it goes really well, just think... in 3 years time an army of
graduates who'll design things well... the world will never be the same
again :-)
> It's the first year we're doing this, and I'm the one implementing it.
> Should be fun!
Well, if you want any help.... Gisajob! Soon to graduate Applied Computing
student looking for a home, low mileage etc ;-)
Terry
Yarone Goren
touched upon:
"Donald A. Norman" <d...@jnd.org> wrote in message
news:eUIW7.7217...@rwcrnsc51.ops.asp.att.net...
>
> The user should need to learn the tasks, not the tools. (This is actually
> more complex, but to explain would take a book. (e.g., we spent a lot of
> time as kids learning to use pencil, crayons, and pens.)
>
More specifically, I see a huge conflict in the HCI field between the role
of Computer Science and the role of Psychology. Most HCI courses, programs,
or research I run into invloves coming up with newer, novel, and more
"effective" software strategies. Usability Tests are conducted in order to
test the effectiveness of one particular strategy vs. another (Example,
Browser-based interface vs. Native Windows Interface).
Although these things are important, I feel that the REAL issue at hand is
largely being ignored. THE BOTTOM LINE: The purpose of technology is to
make life easier. More specifically, to simplify a particular task or set
of tasks.
As such, software is not very interesting. It is merely a tool for
What we need are Software Engineers, whose first and foremost goals and
obligations are to understand the dynamics of the work domain.
Secondly (and less importantly) they must know enough about the different
Yarone Goren
John Yen
experience at apple computer and elsewhere on everything from firmware
to application UI:
- not all software has a UI. i'd even go so far as to say more software
modules have no UI than do
- requirements analysis usually has more facets than understanding user
interaction: understanding the other software your system works with,
hardware and cost requirements, how the software may affect the
organization's processes...
- well-written software's nontrivial even if there's a good user
interaction spec. after training my share of new hires and having been
project lead rather more than once, may i suggest a focus on code may be
necessary for someone to learn computer science essentials, and that a
focus on human factors instead may leave college graduates unprepared
for some entry-level software jobs?
sorry if those seemed trivially obvious, but from the viewpoint i think
i see in this thread it didn't seem to be. as important as i think human
factors are, they're not the only consideration. sometimes they're not
even the main consideration. ask a firewire driver engineer how much
human interface is a factor in their driver design beyond being implicit
in the firewire spec
Terry Eden
news:quapprentice-CDDA...@nnrp06.earthlink.net...
> hmm. a few comments from someone with over a decade of software
> experience at apple computer and elsewhere on everything from firmware
> to application UI:
>
> - not all software has a UI. i'd even go so far as to say more software
> modules have no UI than do
I'd have to disagree there! Every software module has a UI, how else could
you code to use it?
eg. Poor UI - Foo.doThingthatDoesstuff();
Good UI - Foo.CalculateMedian().
It's the classic case of code readability and commenting, I look back on
some of my earlier non-trivial programs and it gives me a headache to try
and read them, mostly because my understanding of how I work was incomplete.
> - well-written software's nontrivial even if there's a good user
> interaction spec. after training my share of new hires and having been
> project lead rather more than once, may i suggest a focus on code may be
> necessary for someone to learn computer science essentials, and that a
> focus on human factors instead may leave college graduates unprepared
> for some entry-level software jobs?
I don't think we're talking about soley teaching HCI in place of coding, I
think it's both to have them run similtaneously. HCI doesn't just cover
"end-users" it also covers other users of your code. If you can teach
people about mental models, it should drip through into their coding. If
you look at undergrad group projects at University, much of the cause of
failure is different people having different models of how they perceive the
problem, convincing people to write usable code is the first step to having
them write usable programs :-)
Hmmmm - waffelled on a bit... sorry!
Terry
Bradley K. Sherman
>most people (users and, to an extend, designers) are socially conditioned to
>believe that tasks should be difficult. They expect a learning curve that
Balderdash! The biggest problem is that managers and users
believe that tasks can be made simple.
Can you tell me how these items should sort?
John Q. Public
John Q. Public
J.Q. Public
J0000PUBLIC
J000public
j0000PUBLIC
j000public
J001public
J1public
J01public
0001jpublic
1jpublic
01jpublic
1-jpublic
01P
001P
90
0090
109
0109
Public, John Q.
Public Jean-Marie
Jean-Marie, Public
Jean Marie Public
Public, Jean Marie
Now, can you write down the rules by which you sorted them?
Surely sorting a list of items using just ASCII characters
is not a problem! Shall we add Unicode or the egregious
Microsoft character set?
--bks
John Yen
computer software strictly as a black box tool so they don't write code.
that's the vast majority of people who use software. in that sense i
stand by my statement
also, i meant what i wrote: a -focus- on human factors, not an exclusive
interest in human factors alone. i say even focusing primarily on human
factors may be too much
i freely agree clear requirements are necessary and nontrivial to
achieve for any nontrivial software. i also agree one facet of good
source code is that it's readily understood by others. i would suggest
these are software engineering issues, not necessarily human factors per
se
understand, i'm kind of bemused by my position here. i've been an human
factors advocate with my fellow engineers, possibly to the point of
exasperation ;) i just don't think it's always the center of software.
mathematics aka algorithms, hardware requirements, etc also matter,
possibly more than human factors for some software components
In article <a5cvrk$6ciqd$1...@ID-89774.news.dfncis.de>,
Terry Eden
"Bradley K. Sherman" <b...@panix.com> wrote in message
news:a5e6k5$o1j$1...@panix2.panix.com...
> In article <a3usoq$1b6smb$1...@ID-89774.news.dfncis.de>,
> Terry Eden <T.E...@deadspam.com> wrote:
> >
> >That's only half the solution. One of the problems I've encountered is
that
> >most people (users and, to an extend, designers) are socially conditioned
to
> >believe that tasks should be difficult. They expect a learning curve
that
>
> Balderdash! The biggest problem is that managers and users
> believe that tasks can be made simple.
>
> Can you tell me how these items should sort?
*Ouch*! I stand corrected. Although, when I talked about "tasks" I was
refering to the task of using software as opposed to the task of doing
"something".
But, it's very true, complicated problems often have non-trivial solutions.
Terry