I got a comment on Avoid user interface refactoring. Andrés Taylor brought up a few questions, in essence it was:

How do you work iteratively with UI?How do you incorporate new and changed user demands into the upfront UI work?How do you give developers enough UI vision to work on?

Now this is getting interesting. I am convinced that there are a way to combine upfront and agility. There are always different views of the problem and the combination provides different perspectives that complement each other.Just one thing, it's not upfront requirements we are talking about, it's upfront understanding, not a document or a list of requirements, but an understanding of the user, the context in where he lives and meet his problems his needs and goals. You can't just listen to a user requests, you have to grasp the context they come from. Henry Ford is supposed to have said: "If I had asked my customers what they wanted, they would have asked for a faster horse."The understanding comes first. You cannot just dive in and start building. What Interaction designers do is parted in two activities. The first part, and this is where I put the big upfront part, is to observe and listen to the user. Interpret the user’s surroundings and his problems. Interaction designers have the training to note what the users struggle with, not what they say they have problem with. This is also the time when the vision, metaphors and design guidelines are formed. They are not finalized, hopefully they never will be, but they are stable enough to start build upon. But you should not start build before this stability is in place.The next part, the iterative work, this is when the agility begins. I am convinced that you cannot just hand over a document with interaction requirements. You have to continue to work with and be a part of the team. Ready to guide and share your knowledge of the user. The personas that interaction designers create are a great focal point for this sharing. The scenarios and user stories are the described problem and the design guidelines are the blue print. But you have to be there as Interaction designer to be able to transfer your knowledge and vision. And more important, keep the personas and vision alive. Only then you are able to give developers enough UI vision to work on.As the application evolves, and it will, the interaction designer keep with the basic idea, make sure the interaction stays within the vision but gives freedom to creative solution where possible. They have the knowledge to make sure the separate features fit together and hopefully this knowledge will transfer to developers. (I would love to try out pair programming with designer/developer and see the result.)Requirements should not only be evaluated in developer customer perspective, but also in interaction perspective what basic user problem it solves. Often it could be re-written to another requirement that actually solves the root cause instead of the problem that is perceived by the user. This will also make sure it stays with in the vision.The most important thing here is communication and participation. Interaction designers will have to work together with the developers. And the developers have to actively participate, agile development has opened the door between the developer and customer (I would rather have it to be the user), but I am convinced that you will have to include the Interaction designers in this mix as well.

So you want Silverlight on Linux? Well the mono guys are incredible. In 21 days they created their version of Silverlight, named moonlight. You can no fire up FireFox in Linux and are able to view a Silverlight application using moonlight. Read more about what Miguel de Icaza have to say about it in Implementing Silverlight in 21 Days.I just say: 21 days - wow...

Gadgets and Silverlight - it was bound to happen, a better way to build richer gadgets. There are of course other solutions to build .NET gadgets. But I think that with the upcoming Silverlight 1.1, with its compact .NET CLR and the possibility to use the expression suite for design you have a great set of tools to build gadgets.If you want to know more about gadgets, the available solution and, of course, how you can use it with Silverlight. My Dotway colleges in Stockholm is having a session around this together with Microsoft and InUse, Sidebar Gadgets - Nya möjligheter.InUse will attend this session to talk about gadgets from the usability perspective and seeing quite a few gadgets I think to you should really look into this. It's too easy to get carried away into the cool effects, loosing the sight of the user.So go ahead and sign up for this event!

Often you hear that you can't compare software to building houses. You cannot change houses the way you change software, YAGNI and all that stuff. However, when it comes to software from an UI perspective it is somewhat like building a house. It all has to fit together smoothly. If you work with the interaction and UI using YAGNI or similar concepts you may head in a really bad direction. It may work for the first few features added, but as well as in the object model you may end up being forced to refactor your UI.Well, this is where you hit the brick wall. On the underlying architecture, if you get into this situation you typically start refactoring using small steps, slowly remodeling the parts that you really have to refactor and leave the other stable parts as they are. They are still well tested, work good and have a clean interface but they don't match the current thinking anymore. But that’s not a problem in itself. You will get to those parts when you bump into them often enough to need a refactor like in Three strikes and you’re out.However, if you find that a metaphor in the UI don’t work for some of the new features you work on in this iteration, sprint, or [insert agile hype here] you have some work to do, you cannot just change the metaphors for the new parts. You are really forced to do a full refactor of the UI. Go over every piece to make sure it’s consistent. If you don't, you are really not doing your job. The user will end up confused by the UI and interaction pointing in different metaphorical directions.So in the UI you are really building your house, if you make a hole for a door and suddenly find that it should be a window you have a lot of work to restore the lost parts. If you rip out one part of the UI the other parts has to be correctly connected. The UI has to be planned around all features and point in the same direction - not only the task at hand. This means up front design and architecture, it doesn’t have to the be scary type of the past. But if you don't keep the vision in clear view, you will end up with a lot of good building pieces but they won’t fit together. But with the bigger picture to lean back on you can still work out the details in all its agility.