 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> There *are* cases where high performance needs to be taken into
> consideration - yet the area where user interaction is *really* important
> (games), you get both high performance *and* good user interaction design
> - at least in games that are successful. Game players have plenty of
> choices for where to spend their time, and if a UI is too complex,
> they'll move onto something that entertains rather than something that
> frustrates them.
What annoys me most (as a user) with game menu UIs, actually any UI that
involves different "screens", is when switches from one screen to
another takes more than an instant for no reason. In this day and age,
if my fingers are waiting for your code to catch up then you're doing it
wrong. Take Gran Turismo 5 on the PS3, the whole menu system is
*painful* to use, if it was instant then it would feel like a totally
different game to interact with and I'd be far more inclined to spend
more time with it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I have a friend who knows someone at Microsoft involved in this - his
> comment (the friend of a friend) basically was "we disclose pretty much
> exactly what we do in the privacy policy - so I'm not sure what the
> problem is. How do you provide services like the ones in Cortana
> *without* gathering private information, and how do you disclose that
> without it sounding Orwellian?" While I'm not a fan of Microsoft, he's
> got a point. Google and Amazon also do the same thing, but there's no
> significant outcry over what they're doing (though arguably, there is
> some, particularly in Linux communities).
That's probably good enough justification for MS that the risk is low.
Most people use Apple and Google mobile products that harvest plenty of
data, it would be strange if all those people rejected Windows doing the
same.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> It's a bit like the way you can drive a way without having a clue how an
>> internal combustion engine actually works.
>>
>> Is that "dumbing down"? Or is that "removing unimportant implementation
>> details"? Where do you draw the line?
I would say you provide the information to allow the user to do what is
expected in normal situations. In the past it was expected a car might
not start at some point, not anymore. Therefore there is no need for a
user to know how to diagnose an engine that won't start (beyond being
told there's no fuel left!).
Or take a photocopier. It's still expected that paper might get jammed
somewhere, so there is provision to explain to the user how to open the
correct panel/drawer to unjam the paper. The user doesn't need to know
how it works to do that.
If everyone took the time to learn how everything worked that they used
we'd have a world full of curious engineers and nobody with any time to
do other tasks :-)
> I think that is the crux of the problem.
> I don't have an answer.
The difficulty with software like MS Office it is used by a huge range
of people with very different requirements. My mum wants to type a
letter and struggles to change the line spacing to make it look right.
My gf wants to make a form in Word with boxes for people to check and
type in. I want a complex workbook in Excel with macros. Designing a UI
that works well for all those people cannot be easy.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/6/2015 8:15 AM, scott wrote:
>>> It's a bit like the way you can drive a way without having a clue how an
>>> internal combustion engine actually works.
>>>
>>> Is that "dumbing down"? Or is that "removing unimportant implementation
>>> details"? Where do you draw the line?
>
> I would say you provide the information to allow the user to do what is
> expected in normal situations. In the past it was expected a car might
> not start at some point, not anymore. Therefore there is no need for a
> user to know how to diagnose an engine that won't start (beyond being
> told there's no fuel left!).
>
> Or take a photocopier. It's still expected that paper might get jammed
> somewhere, so there is provision to explain to the user how to open the
> correct panel/drawer to unjam the paper. The user doesn't need to know
> how it works to do that.
>
> If everyone took the time to learn how everything worked that they used
> we'd have a world full of curious engineers and nobody with any time to
> do other tasks :-)
>
>> I think that is the crux of the problem.
>> I don't have an answer.
>
> The difficulty with software like MS Office it is used by a huge range
> of people with very different requirements. My mum wants to type a
> letter and struggles to change the line spacing to make it look right.
> My gf wants to make a form in Word with boxes for people to check and
> type in. I want a complex workbook in Excel with macros. Designing a UI
> that works well for all those people cannot be easy.
>
Yes to all of that.
The problem is exacerbated by the "religious conviction" of the
different sides.
I freely admit that I am on the side of knowing what you are doing. But
then I work with a seriously complex program and tech savvy people.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/08/2015 07:50 AM, scott wrote:
>> There *are* cases where high performance needs to be taken into
>> consideration - yet the area where user interaction is *really* important
>> (games), you get both high performance *and* good user interaction design
>> - at least in games that are successful. Game players have plenty of
>> choices for where to spend their time, and if a UI is too complex,
>> they'll move onto something that entertains rather than something that
>> frustrates them.
>
> What annoys me most (as a user) with game menu UIs, actually any UI that
> involves different "screens", is when switches from one screen to
> another takes more than an instant for no reason. In this day and age,
> if my fingers are waiting for your code to catch up then you're doing it
> wrong.
I played Saints Row IV recently. Every single time you want to buy a
weapon upgrade, you have to OK a confirmation. Which, when you're
drowning under a sea of money and you want to buy every upgrade in the
game... takes a while.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/08/2015 08:15 AM, scott wrote:
> The difficulty with software like MS Office it is used by a huge range
> of people with very different requirements. My mum wants to type a
> letter and struggles to change the line spacing to make it look right.
> My gf wants to make a form in Word with boxes for people to check and
> type in. I want a complex workbook in Excel with macros. Designing a UI
> that works well for all those people cannot be easy.
Where I work, we have this exact problem.
Half of our customers barely know how to operate a computer, and are
utterly baffled by our product. They just want a big black box with a
massive "find the file I need" button in the middle. (Because, you know,
software is telepathic.) And then the *other* half of our customers want
more and more sophisticated searching capabilities. People have asked
for stuff like regex searching and a search predicate builder wizard.
Wanna take guesses how a person who barely knows what a "file" is will
react to a "regular expression engine"?
The problem is trying to build a single product that does everything for
everybody. That is an extremely hard problem. It's almost impossible to
keep *everybody* happy...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 06 Aug 2015 08:15:46 +0100, scott wrote:
>>> It's a bit like the way you can drive a way without having a clue how
>>> an internal combustion engine actually works.
>>>
>>> Is that "dumbing down"? Or is that "removing unimportant
>>> implementation details"? Where do you draw the line?
>
> I would say you provide the information to allow the user to do what is
> expected in normal situations. In the past it was expected a car might
> not start at some point, not anymore. Therefore there is no need for a
> user to know how to diagnose an engine that won't start (beyond being
> told there's no fuel left!).
>
> Or take a photocopier. It's still expected that paper might get jammed
> somewhere, so there is provision to explain to the user how to open the
> correct panel/drawer to unjam the paper. The user doesn't need to know
> how it works to do that.
>
> If everyone took the time to learn how everything worked that they used
> we'd have a world full of curious engineers and nobody with any time to
> do other tasks :-)
>
>> I think that is the crux of the problem.
>> I don't have an answer.
>
> The difficulty with software like MS Office it is used by a huge range
> of people with very different requirements. My mum wants to type a
> letter and struggles to change the line spacing to make it look right.
> My gf wants to make a form in Word with boxes for people to check and
> type in. I want a complex workbook in Excel with macros. Designing a UI
> that works well for all those people cannot be easy.
The thing that I'm learning is that designing for all the different use
cases is a pretty intractable task.
If you design for a particular use case, though, then you have a design
that you can use as a basis to deal with other use cases.
But it requires time with people and understanding how they use a system,
rather than bolting a UI onto code when the internals are done.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 06 Aug 2015 07:46:08 +0200, clipka wrote:
> Am 06.08.2015 um 03:40 schrieb Jim Henderson:
>> On Wed, 05 Aug 2015 21:51:12 +0100, Orchid Win7 v1 wrote:
>>
>>> Is that "dumbing down"? Or is that "removing unimportant
>>> implementation details"? Where do you draw the line?
>>
>> Back in the olden days, computing resources suffered from scarcity -
>> you had to be concerned about every byte of memory you used, and often
>> implementations of data structures included obscure bitfields in order
>> to conserve memory.
>>
>> These days, computing resources *generally* are not considered scarce,
>> yet programmers generally behave as though they are, and implement code
>> in that way, at the expense of a user interaction model that users can
>> actually use.
>
> They do? Srsly?
>
> Last time I was in the software development business, conserving
> resources is exactly what programmers absolutely, positively /don't/
> these days.
>
> Except for, indeed, ...
Well, valid point - the conservation doesn't go to that extreme, as
language choices like Java demonstrate.
But I still see a fair amount of software development that's focused on
performance over everything else, even when performance isn't a primary
requirement.
>> There *are* cases where high performance needs to be taken into
>> consideration - yet the area where user interaction is *really*
>> important (games), you get both high performance *and* good user
>> interaction design - at least in games that are successful. Game
>> players have plenty of choices for where to spend their time, and if a
>> UI is too complex, they'll move onto something that entertains rather
>> than something that frustrates them.
>
> ... game developers.
>
> (Them, and embedded systems developers.)
True.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 06 Aug 2015 07:50:03 +0100, scott wrote:
>> There *are* cases where high performance needs to be taken into
>> consideration - yet the area where user interaction is *really*
>> important (games), you get both high performance *and* good user
>> interaction design - at least in games that are successful. Game
>> players have plenty of choices for where to spend their time, and if a
>> UI is too complex, they'll move onto something that entertains rather
>> than something that frustrates them.
>
> What annoys me most (as a user) with game menu UIs, actually any UI that
> involves different "screens", is when switches from one screen to
> another takes more than an instant for no reason. In this day and age,
> if my fingers are waiting for your code to catch up then you're doing it
> wrong. Take Gran Turismo 5 on the PS3, the whole menu system is
> *painful* to use, if it was instant then it would feel like a totally
> different game to interact with and I'd be far more inclined to spend
> more time with it.
One thing that drives me bonkers is in Destiny, when you pull up your
character info, it seems to take *forever* to get the equipment list
loaded. If I'm looking to make a quick switch to a different secondary
weapon, I don't want to be waiting 20 seconds for the screen to load. My
equipment list didn't change *that much* (if at all) since the last time
I opened it.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I played Saints Row IV recently. Every single time you want to buy a
> weapon upgrade, you have to OK a confirmation. Which, when you're
> drowning under a sea of money and you want to buy every upgrade in the
> game... takes a while.
Yes this is exactly the problem in GT5. You buy (or win) a new car and
want to upgrade it with a load of stuff. It would be acceptable if it
took 5 seconds to open the "Garage" menu, but it also takes a few
seconds to open every category menu (brakes, engine etc) then a few
seconds to open each item, then you have to click the item, click Buy,
"do you want to apply to the car?", click yes. Then click back. Now
realise that each of those prompts takes a second to appear, and that's
just for one item, you want 20 items. It's ridiculous, don't they get
people to test this? Or are they just Japanese testers that are too
polite to complain about the speed of the menu system?
The other thing I could never understand is why it took so long to leave
the race and go back to the menu. I can understand loading the race
takes a while (it must load all the geometry and textures for an entire
race track and all the cars), but to go back to the menu, surely it's
only a couple of fonts and textures needed, it should be pretty
instantaneous.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
