Weblogs Forum - Think from the User In

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Think from the User In

13 replies on 1 page. Most recent reply: Mar 28, 2006 3:25 AM by Eric Armstrong

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 13 replies on 1 page

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Think from the User In (View in Weblogs)

Posted: Mar 23, 2006 7:10 AM

Summary
In his recent post, Bill Venners included a terrific quote from Ken Arnold. It crystallized my thinking on subjects as diverse as API design, interface design, and documentation (which many developers don't realize, is almost purely a design activity).

In Bill Venner's post on URL management in Rails, Ken Arnold was quoted as saying:

(Many developers) think from the implementation out, instead of thinking from the user in.

That is pure gold. It nicely encapsulates a variety of issues I've noticed, including documentation, API design, and interface functionality.

To transform that wonderful observation into a golden rule, I'd say:

Think from the user in, rather than from the implementation out.

The impacts:

Documentation: Describe how to drive the car, not how the steering system works. It's astonishing how many developer-authored whitepapers do the latter. That's good stuff for the design document, and something that other coders will want to hear. But 95% of the people who are looking at your stuff want to use it.
APIs: Design the best APIs you can think of. Do something else for a week. Then write some test applications from memory. When there's a difference between what you thought the API was as a user and what you thought it should be as the designer, favor the user perspective. Rename the API or refactor to match the way you thought it would work when you were using it. Whenever possible, build your application tests first.
Interface design: Don't build an interface for your technology, so it can be used. Build an interface that solves user problems. Set up use cases and design an interface that minimizes the number of steps the user has to take in the most frequent use cases, that makes less common cases possible, and that above all makes it easy to remember how to do things. Then use your technology to implement it. And if the APIs get in way, change the APIs!

Daniel Berger

Posts: 1383
Nickname: djberg96
Registered: Sep, 2004

Re: Think from the User In

Posted: Mar 23, 2006 2:25 PM

This is kinda how I do things - write the docs first along with little theoretical sample programs to see how I, as a user, would like to use the code.

There's nothing like eating your own dog food. :)

Also, I think TDD should get a mention here, since part of creating a good API is making methods testable, as well as pretty.

Ivan Lazarte

Posts: 91
Nickname: ilazarte
Registered: Mar, 2006

Re: Think from the User In

Posted: Mar 23, 2006 2:32 PM

Developers (and graphic designers for that matter) always love say to say "well, in order to make my life easier, the user should do this!"

I think the Google homepage is greatest example of providing the user with a steering wheel on the web. Too bad it resulted in a lot of similar looking steering wheels with poor engines ;)

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Think from the User In

Posted: Mar 23, 2006 7:54 PM

the universal problem with taking this notion ad extremum is that the developer ends up thinking like a COBOL coder in 1960: define the outputs, then define the inputs. this was fine for batch systems and file based CICS systems. it's not so fine for [R|O]DBMS based systems.

it also is opposite to the notion (and where did its momentum go?) of declarative programming.

which is not to say that the user is irrelevant, only that the UI is merely a fungible artifact of the database, and thus irrelevant (tm). folks who pound the drum for MVC always seem to fixate on the V, the UI. (they should explore P/A/C for a better way to think about the problem.)

but it's whatever the UI language (html + [php,javascript,java,vb]) will support. it can't do any more than that. i've suffered through countless Tree/Table developments that went that way Just Because that's what applets did. not because that was the intelligent way to define and manage the data relevant to the user's problem. phooey.

the (business) logic belongs with the data; don't strap it to some half-baked language. and never let the user tell you what the data structure should be or managed. this is what Dr. Codd so adroitly demonstrated. and what javBOL programmers still reject.

the au courant phrase goes something like "the intelligence of the masses". hmmm. don't think so.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Think from the User In

Posted: Mar 24, 2006 3:07 AM

To bring a little balance to this (also to Robert Young's posting): In "Domain-Driven Design" (see the book by the same name, one of the very best I've ever read on software development), the point is to model the application domain in the software, so that it's structured and works in the way that the users of the domain expect, from their own mental model of the domain.

Such a model should, as Robert emphasises in his posting, never be developed in a "vacuum": It should be developed with an eye to the implementation technology, and the implemented model may evolve with the developers' (and people's) understanding of the domain model.

Too often, "abstract" models (done in UML or whether) are created first, but the final implementation looks entirely different, because of realizations made during the implementation. As the author of the mentioned book emphazises: The domain model should evolve with the the model as it's expressed in the software, so that the two don't depart.

It typically requires a lot of refactoring to arrive at a good domain model in the software, but it makes the model _relevant_.

To tie this back to the blog and quote: It's not about only thinking from the user in, or from the implementation out, but to arrive at a domain model that works the same way that users think of the domain, and as such, taking care of both concerns (relevance for the user, and how it's modelled in the software).

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Think from the User In

Posted: Mar 24, 2006 7:33 AM

Robert Young wrote:

> and never let the user tell
> you what the data structure should be or managed.

You seem to be implying that because the interface provides a certain representation of the model that the underlying data must be structured as an analog of that view. If that's what you mean, I completely disagree. One of the keys to good interface design is providing a separation of view and the model. The value in this is that you can represent the same data in multiple ways. For my money, the worst interfaces are those that are convienient to the developer because they are an analog to the chosen data structure.

There is a limit to this separation, of course. Your underlying storage mechanism must be at least as expressive as your display structure. This (on a side note) is one of the reasons relational databases are so successful.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Think from the User In

Posted: Mar 24, 2006 5:23 PM

> Robert Young wrote:
>
> > and never let the user tell
> > you what the data structure should be or managed.
>
> You seem to be implying that because the interface
> provides a certain representation of the model that the
> underlying data must be structured as an analog of that
> view. If that's what you mean, I completely disagree.

i am asserting that allowing the users to step over the line from saying, say, "I want to see the order and all its line items", to "I want the line items stored in the file with the order. 100 items should be enough (nobody will ever need more than 640k)" is what leads to disaster. i think we agree on that point.

that's kind of extreme to make the point, but in my current CubeLand, that's pretty much what's happened. the infiltration of XML from data transfer to, increasingly, data store will lead down the same path.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Think from the User In

Posted: Mar 24, 2006 11:33 PM

Daniel Berger wrote:
>
> This is kinda how I do things - write the docs first along
> with little theoretical sample programs to see how I, as a
> user, would like to use the code.
>
Yes!! I write entire user manuals first, and pass them aroud for review before I write a line of code. Why bother with a spec when I can go straight to the user docs.

Of course, I am simultaneously keeping a design document where I specify *how* I'm going to do those things, and where I record the results of little "lab experiments" that taught me how things work. When I'm on my game, that design document gives me the core code for the new functions I'll be needing.

> Also, I think TDD should get a mention here, since
> part of creating a good API is making methods testable...
>
Dead on! TDD has probably done great things for API design simply by making sure people think about APIs from the standpoint of usage. (Thought I implied that in the post. It must have been so clear in my head that I neglected to put it on the page. :_)

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Think from the User In

Posted: Mar 24, 2006 11:40 PM

Serje wrote:
>
> It typically requires a lot of refactoring to arrive at a
> good domain model in the software...It's not about
> only thinking from the user in, or from the implementation
> out, but to arrive at a domain model that works the same
> way that users think of the domain...
>
Nicely said. And it does strike a nice balance between Robert's thoughts and my own. What was unstated in the article is that I also think about the design at the same time, so I'm figuring out what I want to do and how I want to do it at the same time.

There don't seem to be too many developers who have trouble with the latter. Hence the focus of the post. On the other hand, it's also possible to wave hands and expect a miracle. But even that has a point, if it defines the ideal we'd really *like*. Then we try to see how close we can come with the technology we have.

Users dictating data structures? I don't think so. But if they're not dictating what the software has to do, if the design isn't based on what they do in a day, and if it isn't expediting the things they do most frequently, then it's not serving their needs.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Think from the User In

Posted: Mar 24, 2006 11:43 PM

Robert Young wrote:
>
> allowing the users to say, "I want the line items stored
> in the file with the order. 100 items should be enough
> (nobody will ever need more than 640k)" is what leads to
> disaster.
>
I hear your pain. I've been there!
I clearly recall the early days, when *everything* was
a fixed size.
:_)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Think from the User In

Posted: Mar 27, 2006 7:12 AM

> i am asserting that allowing the users to step over the
> line from saying, say, "I want to see the order and all
> its line items", to "I want the line items stored in the
> file with the order. 100 items should be enough (nobody
> will ever need more than 640k)" is what leads to disaster.
> i think we agree on that point.

Absolutely. One of my pet peeves is when requirements are written down by without any filtration/refinement by technical people. In addition to the kind of problem you mention, they often don't know how to ask for what they really want. However, if the developers ignore reasonable requests because of laziness/ineptitde the users will become more combatative and harder to reason with.

> that's kind of extreme to make the point, but in my
> current CubeLand, that's pretty much what's happened.

As a fellow Cubelander, I see a lot of issues on the general theme but I can't always blame the user. As I said above, they don't really know how to ask for what they want. They need help and sometimes they are being failed in that regard.

> the infiltration of XML from data transfer to, increasingly,
> data store will lead down the same path.

In my current life, my primary role is with B2B transaction processing so the breadth and depth of our xml use is substantial and I cannot understand how anyone would think it's a good primary storage format. But I guess since we support so many different ways of rendering the same basic messages this would be more obvious than if you have one format for each message.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Think from the User In

Posted: Mar 27, 2006 9:40 AM

James Waston wrote:
>
> As a fellow Cubelander, I see a lot of issues on the
> general theme but I can't always blame the user. As I
> said above, they don't really know how to ask for what
> they want.
>
That brings up an important point. People think in concrete terms. We all do--that's why need examples to understand new concepts. Once we have them, the "abstractions" become concrete. So we can talk about things like "device drivers", because we have seen enough examples (or used them enough) to know what they are.

Thanks to desktop computers, many more end users have some sense of basic concepts, but the fact remains that users, like all of us, think in concrete terms. So they will /always/ express their needs in terms of what they want the program to do, how they want it to work, and the mental they have of its internal operation.

That's normal. It's natural behavior. One of the goodnesses of the Agile methodology is that both respects that fact and takes advantage of it, by having a user in the room as coding is going on.

In the days before Agile came along, my version of that as a designer was to listen deeply--to hear what they /said/ they wanted, but to move beyond that to what they really needed. I could tell I was successful when I could restate their request in the form, "so what you really want is the ability to ....", where the restatement was in the form of a more general conceptual view.

Basically, a user's vision is limited by what they see, just as a designer's vision is limited by the concepts they have been exposed to. But the designer has a wider pallete, of course. So user requests can generally be expanded on.

For example, I've been in the situation where a user said they would like to see this and that record side by side. "Why is that?", I asked, "What do you do with them when you have them?" And the answer comes out like: "I add this and that number", or "I compare this number to that one". Immediately, a variety of possible solutions come to mind.

The conversation then goes on until the /real/ need is identified, after which a design can be worked out to satisfy it. But it is important to understand that the realy need is almost /always/ hidden, embedded in a request for some concrete operation.

James Britt

Posts: 21
Nickname: jbritt
Registered: Mar, 2003

Re: Think from the User In

Posted: Mar 27, 2006 9:42 AM

Developers (and graphic designers for that matter) always love say to say "well, in order to make my life easier, the user should do this!"

I've never heard a designer or developer say anything like that. Most designer and developers I've worked have been quite concerned with the end user.

A big problem, though, is adopting the "beginner's mind". A developer's perspective is distorted by his or her understanding of how things (could) work, so it can be difficult to appreciate when a suggested UI is inherently geeky.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Think from the User In

Posted: Mar 28, 2006 3:25 AM

James Britt quoted
> Developers (and graphic designers for that matter)
> always love say to say "well, in order to make my life
> easier, the user should do this!"
>
And then wrote:
> I've never heard a designer or developer say anything like
> that. Most designer and developers I've worked have been
> quite concerned with the end user.
>
+1

> A big problem, though, is adopting the "beginner's mind".
> A developer's perspective is distorted by his or her
> r understanding of how things (could) work, so it can be
> difficult to appreciate when a suggested UI is inherently
> geeky.
>
+1

Flat View: This topic has 13 replies on 1 page

Previous Topic

Next Topic