Cheers

Colin

Also, regarding #10, I agree, but have a preference for the term "negative space" over "white space" as not all uncluttered design has a "white" background (Semantics. I'm aware I'm splitting fine hairs. Just pointing it out).

Chauncey Wilson
==================================================================
Chauncey – completely agree.

I was trying to address the fact that in so many cases programmers and designers pack things
together as tightly as possible without any regard for visual hierarchy and “breathing room”.
You can create an information dense interface but still design it in such a way so that the
user’s eye can at least follow a path.

Thx for the feedback!
Russell Wilson
==================================================================
> Why do you have a “niggle” with item 5, “Ease of use over of ease of
> coding”? One of the biggest problems I encounter is with
> applications and web-sites that are built according to the coders
> world-view and because of that make little sense to the ordinary user.

Two niggles really… and minor interpretational ones at that

1) The problem is often not ease of implementation, but world view (as
you said)

I find dev/ux issues are often nothing to do with ease of
implementation. It’s the developers not understanding what users find
easy / difficult – the “whys” behind the design that’s been handed
down. Generally I find that ease of use and ease of implementation are
not particularly tightly coupled. That’s obviously not always the case
- but fairly common.

It’s not that the implementation is hard. It’s that the developers
don’t understand the design in it’s fullest sense – so they don’t
_really_ understand what/why they’re implementing it.

The problem I’ve seen is that some UX folk take this as developer
laziness rather than bad communication/understanding of the models and
abstractions in the design. Trying to convince a team to do something
with that in their head often causes problems.

(Saying “do it this way coz it’s better – no matter how hard it is” –
rather than “we need to do it this way because the user is expecting X
and Y, because of Z which represents the underlying Q”. )

Because they’re not addressing the underlying problem – getting the
developers to understand the user model – we continue getting a lousy
implementation.

I find that communicating those models well mean that the developers
can implement the solution more easily – since they now understand the
abstractions that need to be embodied in the code more effectively.

2) Ease of implementation == money.

Projects have budgets. As a (hopefully) responsible designer I need to
be involved in building the best project I can for the money available.

What “Ease of use over of ease of coding” is saying from a budget
perspective is “Ease of use over money”.

If I’m metaphorically wringing my hands and going “Boo hoo – this
wouldn’t be rubbish if we could spend a bit longer implementing my
wonderful design – not my fault!” then I’m abrogating my responsibility.

I need to work with all of the stake holders and all of the team to
build the best possible product in the time/budget available.
Sometimes that will be spending more time the product a joy to use.
Sometimes that will mean getting that vital feature implemented no
matter what in the best way we can in the time available.

Now – there are certainly good arguments to be had about the impact of
a badly implemented feature on a product – short and long term. But
that’s not an really about ease of implementation (or otherwise). The
same issues arise from badly implemented features (from a UX
perspective) whether they were easy or hard from the developer
perspective.

Hopefully that makes some sort of vague sense

Cheers,

Adrian Howard
==================================================================
I also agree with Chauncey and Russ. I work with many programs for Travel Agents, who want to be able to see as much information on the screen as possible. These screens are very densely packed.

The agents hate scrolling. They prefer to scan and keyboard input rather than use the mouse.

>From what I have seen, the travel agents really use the mouse almost as an extension of the keyboard with very small movements, using the wheel more than gross hand movements with the mouse.

Still, they prefer to scan. White space is a secondary concern. They actually prefer the density.

Thanks,
Brian Sullivan
==================================================================
> Still, they prefer to scan. White space is a secondary concern. They actually prefer the density.

Do you think there’s some sort of “complexity appeal”? I’m wondering if some people prefer the
oscilloscope over the iPhone? I know some engineers who like to tinker – they like complexity – wires,
gauges, messiness…

hmmm…

Russell Wilson
==================================================================
> Adrian – what are your thoughts on 1, 3 & 5?

Heh

Hopefully you’ve already seen my ramblings on (5)

> 1) Understand the problem before solving it (and
> avoid “design on the spot”)

I’m not 100% of the intent behind it. To me it seems to be saying the
ideal is:

1) Do the understanding
2) Do the designing
3) (implicitly – do all the implementing).

That may be me wilfully misinterpreting your words of course

I don’t work that way at all.

I understand a bit. I design a bit. That sparks of some more
understanding. Which leads to some more designing. Which leads to a
bit of implementation. Which highlights an issue that I hadn’t
spotted. Which leads to a rethink of a bit of the design. Which points
to a new area of understanding which…… I’m sure you get the
drift….

For me design is a incremental process of creative refinement – and
(1) seemed to be saying that was a bad idea.

I’m not anti research. Research is great! It’s just that I often find
that the fastest way of clarifying my understanding of a problem is to
build and try something.

I have found folk who try and do all the understanding of the problem
up front tend to miss something – usually a big something – that
causes problems later on in the project. If they’d done a bit more
solve it / build it earlier it wouldn’t have happened.

For me there is a fantastic and thoroughly enjoyable dance between
understanding, design & implementation. Doing all of one before the
others is less useful (and less fun

> 3) Validate designs before investing in (production)
> code

I’m niggling again…

I want to validate the designs in the fastest most cost effective way
possible. Sometimes that’ll be a scribbled sketch in a notebook.
Sometimes that’ll be a vaguely formal paper prototype. Sometimes
that’ll be a quick HTML mock up or something in Omnigraffle. Sometimes
that’ll be a quick code spike.

Sometimes that’ll involve writing production quality code.

It – as they say – depends!

Validating the design and getting feedback in the quickest and most
effective way is the important issue. Throwing one of the ways of
doing that out of the window coz some people do really dumb things
seems counterproductive to me

I’ve many problems with designs that come down to not validating
practicalities with real production code early. Equally I’ve seen a
whole bunch of problems where folk have gone down one particular
design path too and have wasted a whole bunch of time and money.

Understanding the costs and benefits and making an informed decision
seems better than an absolute statement.

> Thx!
> Russ

And thank you for the thought provoking post

Cheers,

Adrian Howard
==================================================================
I can’t speak for everyone, but personally I prefer the density because
it’s more efficient. It provides the information I need to do my job,
without hunting and scrolling.

Kathryn Grant
==================================================================
> Do you think there’s some sort of “complexity appeal”? I’m wondering
> if some people prefer the
> oscilloscope over the iPhone? I know some engineers who like to
> tinker – they like complexity – wires, gauges, messiness…

I think that can certainly appeal to some folk.

But for data entry/comparison it’s often a case of a more effective
workflow. Not having to scroll can make some tasks easier.

Also – I remember talking to one guy when doing some user testing who
was really anti-scrolling because he had to touch the computer.

With the old system he could bring up a page of information and then
have an interaction with the customer, glancing at the screen when
necessary. With the new system he had to turn, tweak the mouse, turn
back. Since he had to do that several times during each interaction he
felt that it broke the rapport between him and the customer. The quote
on the usability report was “This will cost me f**king sales” I seem
to recall

Cheers,

Adrian Howard
==================================================================
I think it is both a complexity appeal and they want to be very
efficient. On one hand, Travel Agents want people to see them as
experts (and they truly are experts–the general public does not know
what happens behind the scenes).

So, the complexity appeal makes them feel like experts. Yes, it is an
ego thing.

And…I do think it is related to efficiency. Time is truly money. The
agents need to book revenue to make a living. With the advent of online
travel sites, the vast number of travel agents are becoming very
specialized.

You do not have a travel agent really in strip malls too much. Just 15
years ago, there was a travel agency in every other strip mall. To make
money, they must book revenue faster–screen density makes that
possible.

The agents see density as enabling them to book $$$.

Brian Sullivan
==================================================================
>> I think it is both a complexity appeal and they want to be very
efficient. On one hand, Travel Agents want people to see them as
experts (and they truly are experts–the general public does not know
what happens behind the scenes).

>> So, the complexity appeal makes them feel like experts. Yes, it is an
ego thing.

It all really goes back to ‘know your user’. I have an application I’m working on that is used by both the very barely computer literate salesman and the guru computer user in operations. What they want and how they interact with the same information is very different. So I have two different UIs to help each user role be productive.

Thanks,
Jeanne Hallock
==================================================================