I am currently reading About Face 3: The Essentials of Interaction Design. This book speaks to me, it really does. Not because I am a design-oriented guy frustrated with bad software, but because I am a programmer by trade and I am guilty as charged of taking shortcuts in implementing prototype interfaces and then coming back and having to re-architect the code to implement the other 20%. Often times the popular programming patterns are the direct opposite of user friendly, even with object oriented languages, true object oriented design often takes a back seat to the demands of the implementation. I am inexperienced and haven't been working in the industry long though, so that might be one factor.

Some problems are just so difficult and timelines are so unrealistic that there is no choice. Recently I had to implement a sort of token field (like what you find in mail clients, Mac has a build-in control called NSTokenField iirc) in C# WPF and in the end the solution that actually worked was to serialize a RichTextBox to XAML, edit the XAML using basic string manipulation, and serialize the control again to be rendered. This implementation is so radically different than the correct "programmer" way of doing it, which would be to define a special control with special behaviors from scratch, but it doesn't seem to interfere with usage so in this case we dodged the bullet.

Anyways, has anyone else read this particular book? What are your thoughts/opinions and have you applied any of the techniques described in the book?

If concerned about interaction design, then asking whether a token field is a suitable solution would be a better question. How it's implemented is a technical detail and not something that ID or UX does.

true object oriented design often takes a back seat to the demands of the implementation[/quote]

OOD is said to be sound if it suitably models the target domain. Current frameworks, such as WinAPI, WinForms or similar model the WIMP paradigm, which is essentially unchanged since it was invented in 1960s. That one in turn was influenced by interfaces of the time - boards of switches and dials.

Once upon a time, there was VisiCalc. It wasn't great, it ran on 8-bit hardware on 40x25 screen, in monochrome. Yet it was an instant hit among population that never saw a computer before. Why? Because people got it. They didn't need training, they knew what a spreadsheet was, they used them every day and now it was on screen. Between many radical and improved approaches to spreadsheet software, Lotus 1-2-3 eventually took over, despite being the "poorest" of alternatives. Again - users just got it. It didn't try to pretend to be something different, it simply was a spreadsheet.

Today's APIs arose around such expectations. We still have windows, icons and pointers.

Web changed a few things. Despite having probably the most broken development model and lacks any kind of standardization, it iterated into usable and familiar from. Single, two or 3 column layouts, expectations on navigation, content density as well other details about how documents are presented and navigated, it eventually built upon the newspaper layout. It can be argued that it's not the best we could do and better alternatives exist, but it's familiar to users.

Of more radical changes, Apple is the clear winner. They are first to successfully break the WIMP concept through introduction of touch and gestures, completely redesigning what users expect from applications, yet managed to deliver it in, again, familiar form.


Note that in none of these cases the APIs matter. Computers still do the same basic things. They read inputs, then render either shapes, text or blit squares. So the fundamental APIs are perfectly fine.


An important aspect of usability is also in details. Controls provided by frameworks today do a lot. Stuff many never heard about and wouldn't unless they try to implement them. How is a font defined, the impact of kerning, line breaks, word wrap. When to overflow, when to truncate. What about other languages, BiDi, top down, symbol selections, various IMEs, the proper scaling depending on DPI setting of desktop synchronized to mouse or other input DPI, proper alpha blending based on monitor gamma profile, lcd/led specific aliasing, .... the list goes on and on - and to make use of all of this, the combined effort of decades of experience provided by hundreds of millions of users, all you have to do is type "new TextBox()".


It's a big but mostly "soft" field. There are no absolutes, emotions and impressions matter as much as marketing and price and depend on each other.

Simplified and approachable forms of interaction design are present in progressive web development today in forms of designer templates and metrics analysis. Desktop has been somewhat stagnant, but at least it offers vast array of pre-packaged controls out-of-box, which offer a familiar experience to typical users.

What are your thoughts/opinions and have you applied any of the techniques described in the book?[/quote]

I listened to a presentation given by people from a company that specializes on these topics as part of marketing efforts on web. One of the points they raised was that a requirement is to be lacking hair. Or - it's a field for seasoned veterans with 15+ years of cross-disciplinary experience. It's simply not something you walk into, write a few lines of code and call it a day.

I don't remember which site exactly, might be NYT, might be some other similar site has 50+ department dedicated to nothing but UX. Some companies have hundreds employed in similar roles and they aren't even classified under IT or programming, despite being concerned primarily with web design.

Perhaps a tad bit off the intended topic, but...

On 11/7/2011 at 5:00 PM, BryanCroteau said:

I am guilty as charged of taking shortcuts in implementing prototype interfaces and then coming back and having to re-architect the code to implement the other 20%

I have come to the opinion that "re-architect[ing] the code to implement the other 20%" is a very legit and valuable skill.

The ability to skimp on one area of functionality in order to focus on another, and then come back and completely restructure to push another front, is exactly what it takes to develop quickly, and dynamically, with evolving goals and requirements. Almost always having just the structure needed for current functionality, not carrying the burden of constructs that are too forward looking, or feeling inhibited by legacy limitations, is indispensable to efficient development. Freedom to restructure and re-architect on the fly (within reason, and during the right phases of development, of course) is one of the things that really allow functionality and quality to flourish.

We now return you to your regularly scheduled programming.

If concerned about interaction design, then asking whether a token field is a suitable solution would be a better question. How it's implemented is a technical detail and not something that ID or UX does.

true object oriented design often takes a back seat to the demands of the implementation

OOD is said to be sound if it suitably models the target domain. Current frameworks, such as WinAPI, WinForms or similar model the WIMP paradigm, which is essentially unchanged since it was invented in 1960s. That one in turn was influenced by interfaces of the time - boards of switches and dials.

Once upon a time, there was VisiCalc. It wasn't great, it ran on 8-bit hardware on 40x25 screen, in monochrome. Yet it was an instant hit among population that never saw a computer before. Why? Because people got it. They didn't need training, they knew what a spreadsheet was, they used them every day and now it was on screen. Between many radical and improved approaches to spreadsheet software, Lotus 1-2-3 eventually took over, despite being the "poorest" of alternatives. Again - users just got it. It didn't try to pretend to be something different, it simply was a spreadsheet.

Today's APIs arose around such expectations. We still have windows, icons and pointers.

Web changed a few things. Despite having probably the most broken development model and lacks any kind of standardization, it iterated into usable and familiar from. Single, two or 3 column layouts, expectations on navigation, content density as well other details about how documents are presented and navigated, it eventually built upon the newspaper layout. It can be argued that it's not the best we could do and better alternatives exist, but it's familiar to users.

Of more radical changes, Apple is the clear winner. They are first to successfully break the WIMP concept through introduction of touch and gestures, completely redesigning what users expect from applications, yet managed to deliver it in, again, familiar form.


Note that in none of these cases the APIs matter. Computers still do the same basic things. They read inputs, then render either shapes, text or blit squares. So the fundamental APIs are perfectly fine.


An important aspect of usability is also in details. Controls provided by frameworks today do a lot. Stuff many never heard about and wouldn't unless they try to implement them. How is a font defined, the impact of kerning, line breaks, word wrap. When to overflow, when to truncate. What about other languages, BiDi, top down, symbol selections, various IMEs, the proper scaling depending on DPI setting of desktop synchronized to mouse or other input DPI, proper alpha blending based on monitor gamma profile, lcd/led specific aliasing, .... the list goes on and on - and to make use of all of this, the combined effort of decades of experience provided by hundreds of millions of users, all you have to do is type "new TextBox()".


It's a big but mostly "soft" field. There are no absolutes, emotions and impressions matter as much as marketing and price and depend on each other.

Simplified and approachable forms of interaction design are present in progressive web development today in forms of designer templates and metrics analysis. Desktop has been somewhat stagnant, but at least it offers vast array of pre-packaged controls out-of-box, which offer a familiar experience to typical users.

What are your thoughts/opinions and have you applied any of the techniques described in the book?[/quote]

I listened to a presentation given by people from a company that specializes on these topics as part of marketing efforts on web. One of the points they raised was that a requirement is to be lacking hair. Or - it's a field for seasoned veterans with 15+ years of cross-disciplinary experience. It's simply not something you walk into, write a few lines of code and call it a day.

I don't remember which site exactly, might be NYT, might be some other similar site has 50+ department dedicated to nothing but UX. Some companies have hundreds employed in similar roles and they aren't even classified under IT or programming, despite being concerned primarily with web design.
[/quote]

A very well-written and intriguing response. I suppose it's what they call "standing on the shoulders if giants."

And VReality, is that a complement?