I've had this too.
We build Web apps and now we never let the client see anything until it's been integrated with the design.

In one of my first projects I introduced the GUI as the first thing to my customers and hey they where totaly impressed - however it was just the GUI prototype without and backend coding done. I ended up with "Its done why cant we have it right now" and similar responses -I think its very hard to hit the right moment for such presentations.

Hi,
I've also seen this when demonstrating progress in a project. If we can demonstrate UI progress then the client is happy - we can clear 90% of the tasks, but if that last 10% is UI then we have a difficult meeting. On the other hand if we complete the 10% that they can see (the UI) then everyone is happy.

What I try to do now is make sure that we always deliver some UI changes at the same proportional rate as we deliver back office changes. Clients do seem to be able to better judge the progress of visible changes rather than back office stuff.

Best regards
Steve

No matter how good the product is - they will want a colour change.

I run a small software company, and I have such a high emphasis on "a good UI/looks", I have a graphics designer permanently employed.

It is obvious really. No matter what people say they understand, they usually only react to what they see. It is human nature. Even techies react well to a good UI.

I've been wrestling with this very problem lately, because I'm *trying* to get people to write an API and repeatable unit tests before going near the UI, but that conflicts with the desire of users and our alleged project managers for immediate gratification.

They assume that if there are no pretty pictures to look at then no work has been done.

I've made this comment here and other places and I'll continue to beat this drum: timing when to show your UI is at least one of the top 5 things that plague a software project. Too early: you get the "why can't we have it now?" like Jerry commented. Too late: you get the experience like you state Jeff. I've come to a place that I show UI concepts early, but intentionally "disable", like printed on paper or working inside Powerpoint. Then I don't run into the too early scenario. But I can engage the customer to avoid the too late situation too. The bottom line is that the UI to the customer is the application. Like the goalie in hockey or the QB in football, success or failure rides with it, regardless of how good (or bad) the "team" surrounding it is.

(great site, recently found)
the younger generation seems to buy into (and empower the silly by doing so) this notion. it is *wrong*. the *data* is the application. anyone (sigh, me) who has to deal with "legacy" (aka COBOL/VSAM) systems has found this out. folks who've been building RDBMS systems since, oh, 1990 also knows it.

(aside: when was the last time you saw code mess up the data?? and the last time you saw data mess up the code??? nuf said.)

not that the UI is irrelevant, but that the data structure determines the widgets. imagine a flat file with 10,000 rows that makes sense for monthly batch processing; think, business analyst spreadsheet. now, build a 3-tier system to maintain that. good luck.

despite the XMLFoolishness these days, a 3NF database has a very useful "side effect": it provides the smallest sets of independent, verifiable data strucutures. this is something that 3-tier (at least in the B2B sector) absolutely has to have.

KISS.

Robert - I do agree with you that at the end of it all, the data is the application. Absolutely, agreed. But you and I are not the users of the system.

You say that "the data structure determines the widgets" and to a large degree that is correct. 2D data really should be rendered in the UI by a table/grid, anything else would be crazy. The problem that I have with the line of thought that comes from "the data is the app" is where applications require the user to understand/feel how the data is arranged. I've seen many apps that were not thoughtfully put together that made the user first create the link table entries, then the master table entries and then the detail entries, mimicking the db schema. A more useful application obscures the database confines and allows the user to get things done, creating these things on the fly.

Again, I agree that the data is the most important. Data integrity is the key. But we understand the RDMS structure underneath and we should expose that unnessarily to the users. Unnessarily qualifies that statement because sometimes we need just a quick and dirty UI to drive tables....

Jeff: you have to check out Google Talk. There's an easter egg with your name on it. From www.forgetfoo.com : "First noted by a GoogleRumors commentor, if you add the buddy wumpus.game@gmail.com..."

and i guess there needs to be some agreement on what "UI" means in these sort of discussions. if one's language is C/assembler, then one can create widgets currently unimagined. if HTML, then less so; certain widgets fit certain kinds of data, even for the currently unimagined variety.

if you decide on the widgets first, you've constrained the data to what those widgets can support. you may at this point put the application/data in an untenable/unsupportable condition.

and, yes, if the user really, really wants to always see those 10,000 rows, then any data structure will do that. but the 3NF approach allows much more parsimonious presentation. simpler is better. even without this, the UI should present only the data needed at its point in the process (which doesn't imply Procedural Programming).

and if the UI is mouse based, then it should be fully moused based. all choices are click-driven. nothing drives folks nuttier (even when they don't quite know why), then having to futz back forth from the mouse to the keyboard. if that's not possible, then segregate the key-ed input into a contiguous interaction.

and so on. btw, Stever Krug's "Don't Make Me Think", 2nd is just out.

> you have to check out Google Talk. There's an easter egg with your name on it.

LOL: an IM version of Hunt The Wumpus..

http://jesterace.com/?p=9

Just what I didn't need, though: Yet Another IM Client. Sigh.

> Stever Krug's "Don't Make Me Think", 2nd is just out.

Oh wow, my favorite book! Thanks for letting me know!

http://www.sensible.com/secondedition/index.html

I think you've got Matz' name spelled wrong.

This post from Creating Passionate Users explains how to strike the balance between back end functionality and GUI completeness to show progress.

http://headrush.typepad.com/creating_passionate_users/2006/12/dont_make_the_d.html

I reall canot belive that this is really something that someone has made up "somethings just should be kept sceret" you really spoiled that one for me!

I don't agree, the data is not the application. The data adds value to the application, but it's the applications job to work with that data. It's like arguing that gas is the engine, one is needed to utilize the other. That being said, the entire point of this is that the end user judges everything based on the UI, and really cares very little (at first, let them use it for a while though) about the guts of the application. The user is sold on the app based on the UI, and they're initially (and potentially) only opinion of it is based entirely on how the UI *looks* and not particularly how it functions. Once they actually start working with it of course the behavior becomes the critical component, but you've got to get them to that step first.

I strongly agree with Yukihiro Matsumoto's statement. You can have the best software program in the world, but if the end users can't use it, it might as well be the worst. There are a lot of good products out there that I won't even touch because they're too difficult to use.

I spend a lot of time making good UI's, even for engineering tools at my work. It makes a difference - even a geek will appreciate not having to figure out how to get it to work.

Could this be an indication of developers' failure to communicate to end users? If you show the GUI too eary, you need to tell them it's basically "smoke & mirrors". Maybe let them play with the UI to help them understand why a finished ui != finished app.

There must be some way of communicating to non-techies the difficulty of the back-end stuff - helping them to understand that the core of the app is in what they don't see. Is this possible?

Perfect application needs UI, functionality, and data to be fine. Even if the users are happy with a good interface, everything breaks as soon as the rest doesn't work ok.

The application and the users are part of the system. The real user of the system is the corporation that the system is installed into. If the system doesn't work fine as whole, its a disaster.

Surely Microsoft Word is very widely used. But I really hate it. Why? Is it not the king of all usable software? Well, its full of buggy features. Users like Word because it has lots of features, but sad is that Word is still annoying. Like if I want to select a part of a word, Word selects the whole word for me, and I try to figure out how to select only the part I want. So I end up doing twice as much work as I would have to in many cases. Surely there are options in the settings, but I don't want to go through them all before I can conveniently use the application.

Also creating new styles that have numbering in them is tedious in Word. I have trouble adjusting the space between the number and the actual text. That is partly because there is some tabs, but if I change it to space, it still doesn't work. And its difficult to see what effect has paragraph settings versus numbering settings. I just try them all one by one and the style goes even worse all the time. Then I change the settings pretty much as they were in the beginning and it works. Now I don't dare to touch them, because I hope it won't break again.

So even as Word has lots of features that are supposed to make it easy to use, the features themselves are many times hard to use.

I have to agree that UI first is essential... Though I don't think it is the end of the story.

I have been an agilest for quite a while now and I consider an application to be made of different user stories. Each of these stories can be developed within isolation to a point, but the key point is that I do the following for each story...

1. Paper prototype the way the user works along the story from their point of view (UI)
2. Convert the prototype into a 'usable' part of the system... i.e. it knows how to interact with the domain/service layer to do what it needs
3. Implement the business logic to satisfy the UI, while keeping an eye on the bigger (and currently implemented) picture.
4. Finalise the artwork of the UI for the story so that when a user sees it... it is actually the finished thing.

I never ever create any UI in the system for a story that hasn’t been started, so when the sponsors see the demo system, what they see is what they would get in they insisted on a production release there and then ;)

You will also notice that I ALWAYS place just as an important emphasis on the backend as I do on the front end, it’s like having an MP3 player without a set of headphones!!!

Everyone is raving about the Napkin look and feel for Java, but it completely misses the point it's trying to convey: the whole app looks like that, so you can't tell what's done and what's not.

(unless you can easily switch look and feel at the widget level, which I don't think is possible, but my Swing development days ended at Java 1.4, so I welcome corrections).