This is a great Google Tech Talk on Functional Programming and GUI Development. These are of course 2 things that are near and dear to my programming heart.

The basic concepts are that I liked:

• Functional programming = value oriented programming
• UIs are visualizations of values.
• You expose the parameterization of the functions to users.
• You want to use the unix pipe concepts to pipe inputs/ outputs to each other.

Essentially, the difficult bit for me is that much of the work that I do is about passing around an ‘entity’, editing, maintaing and persisting its state. I am sure there is a good FP answer to this, but I need to see how to fit it into my mental development model.

If I view Excel as the de-facto FP app – I am sure that I can find a way to map my world to a more pure FP stance.

The things randomly rattling around in my brain – vaguely related are:

• Column oriented databases (Bigtable, HBase, etc)
• Google AppEngine’s data model – especially expando types (basically each row may have different or extra columns)
• I am increasingly interested in concepts from Lisp – like the fact that types are just lists of attributes.

Putting together those ideas gets you something like bigtable for persisting potentially sparse-ish, or versions of, or extended type hierarchies of values sets. Value sets are basically attribute lists.

All of that gives a different world than I have today. I cannot say where it is going for sure, but all of this gives me a scent of the next set of dominant paradigms. Learning, building, advancing, etc.

-Chris

I know, WinForms is soooooo 2006, but we will not start WPF for real until there are non-beta tools available (orcas/ blend).

Jeremy has a post few a few days back on writing testable win forms apps. My answer is a simple one. Minimize the stuff in the “hard to test” user controls.

• * User Controls/ Composite user controls often – implement some interface. The purpose of this interface is partitioning, NOT for someone else to extend it per se.
• Let’s say we are writing a “trade blotter”, our interface might have methods like:
• Trade[] GetSelectedTrades();
• void MarkTradeInEdit(int tradeId);
• void SelectTrades(int[] tradeIds);
• etc.
• * We externalize the “automation” of the calls to the UI using 2 kinds of “commands”.
• Presenter Commands – their job is to intersperse calls to the UI interface and calls to the “Background Commands”.
• Background Commands – the commands that have nothing to do with the view. These commands often act agains services like:
• BookTradeCommand
• SaveTradeCommand
• GetTradeCommand
• * The view has a reference to s single Presenter that it gives “named gestures”. If someone wants to Click a button and ask to load some trade data, we say something like:
• presenter.HandleGesture(“loadTradeClick”); 
• * The Presenter ”wires together” buckets of commands to a View. This means that for any named gesture, you can “wire it” to some command in the presenter’s bucket. If the View is some winforms implementation of ITradeBlotter, so be it, the commands will automate it. If it is a mock ITradeBlotter, so be it. In the past Spring has been the main device to do this all and it has worked out great – the wiring together commands to named gestures.

Generally, this model is very simple. You can have some developers go off and write a UI component according to some interface you talk about. This helps the team decide what the UI component should do. Before, after or during that process other people can be writing commands to automate the UI via some commands that just talk to an interface that is their view. You get extreme reuse out of the “background commands” that simply do units of work. Whenever you need to change a behavior, add a behavior, etc, you can often just create some new commands and the view stays the same. It is all very very testable in this case. The big win of testability is one, flexability is another, and the ability to work well in a team environment – partitioning the work is a huge win as I see it.

There is lots more I could say about all this. This is certainly NOT 100% automation of the UI tested. It has been in the past “the best we could get”. I would love to have a more complete answer, but this has proven useful to me. I have yet to see a more testable UI development methodology.

-Chris

 

Powerful and Simple

Common Controls

How to Design a Great User Experience

All excellent links from Microsoft’s area on designing apps for vista. In fact – they are just good UI Design guidelines. I have long said that MS spends the most $ on user experience studies, research and has the biggest user base in the world – so follow their guidelines !

-Chris

Here are some items from the Test Driven Development and Mocks developer session I did a few weeks ago in NYC. I excerpeted lots of people -see the refs at the end of the slide deck. The main things I wanted to hilight were #1 – how important unit tests are. How much better they work when they are done with other core development practices (IoC, etc), How useful mocks are – and a core mock pattern to use.
BigFatGuyTests.cs
TickTests.java
TDD Dev Session.ppt

Enjoy;
Chris

MSDN has a great set of articles on the 2007 Office Suite. I have never been an ‘office’ developer – but, I thought that being a UI designer – a good place to get ideas on UI design – would certainly be the office team.

This article -Developer Overview of the User Interface for the 2007 Microsoft Office System got me into this series of articles (Office 12 Technical Articles) …

Read these articles – they are great. In essence, they are good reference for principals and practices regarding User Interface design. I snipped the following bit here for your reading pleasure. These key points can take you a long way. I believe that the ‘art’ of user interface design needs to be pursued. SO many business applications are developed with little interaction design expertise that it is amazing. Broken metaphors, awkward operations, confusing dialogs etc are the NORM unfortunately. So – I believe this MUST change. Leave it to the folks @ MS to spend LOTS of $ on RnD/ Focus Groups to sort out the ways that users like to interact with software. This very spending is valuable to all of us software developers.

UI Design Philosophy

• Focus. The user’s attention should be on the content, not on the UI. The results-oriented approach allows the user to perform sophisticated formatting and advanced tasks without diverting their attention from the document or content on which they are working.
• Context. The contextualization of as many commands and properties as possible is crucial. Increase the user’s sense of mastery by reducing the number of choices presented at any given time. Reduce the command space by eliminating redundant or seldom-used features.
• Efficiency. Focus on efficiency rather than scope. Users must be able to find the most powerful features for the task quickly and easily. A small gain in the scope of features used is not worth a significant loss in the efficient use of the features.
• Consistency. A results-oriented user experience is best accomplished by clearly providing intuitive ways to solve different problems. When applying tools to tasks, flexible consistency is desirable; homogeneity is not.
• Permanence. Clearly defined access to tools ensures better usability. Ambiguity is reduced by establishing permanent homes for groups of features. A consistent-location UI is favored over a “smart” UI.
• Predictability. The Microsoft Office applications offer a long and rich legacy of acceptance, upon which you can build successful UI innovation. Straight-forward design ensures continued user comfort and maximized results. Favor the predictable over the novel.

A big thing for the new office suite is the whole ‘ribbons’ thing. Bye bye file, edit, view menus. Bye bye toolbars with commands repeated from the sub menus etc. Enter – ribbons…

Results-Oriented Design

These ribbons are there to work according to the above ‘UI design Philosophy’. I am just now installing the new office beta for myself – simply for the ’study’ of their UI principals in practice. Hopefully – I will add to my practices and knowledge of REALLY designing UIs for people to accomplish things. This is key – a core tenant of their latest UI Design philosophy is “results oriented design” – building applications for people to get things done.  May they accomplish this – may we all!

Enough blabber -I am off….

Chris

Aah – I spend so much time trying to make the Presentation Layer of my applications as ‘thin’ as possible – one might think that I believe it to be unimportant. Alas- I believe the opposite is true. While I think of myself as sort of an enterprise software guy – I think that end users CARE about the usability of their software. 9 times out of 10 – there are non-technical end users for my software. These people have some goals. They try to meet these goals by doing some tasks. The ability for the users to understand how to accomplish these tasks to meet their goals is what matters.
Since I tend to believe that the UI is actually very important for software applications – I tend to think about it a lot. I have spent lots of the time on the server – building web services. I have spent lots of time on the server building servlet like services. I have spent lots of time in databases. I have spent lots of time building web UIs. I have spent lots of time building Windows Desktop App UIs. I have had to build service daemons, agent like thingys, and all things in between. All of that said – end users care about their ability to get their goals met and about not being made to feel dumb.

I DO think that prototyping UIs is a good plan. I do think that making the UI as SIMPLE and CLEAR as possible is very important. I DO NOT think that putting zillions of rarely used features into UI applications is useful. I DO NOT think that this is at all ‘hard’ I just think it needs to be considered. Anyhow – here are a few decent links to read some tidbits about designing for usability. Much of this is ‘web geared’ but do not be thrown by that – it is all relevant in any UI environment.
Sites
welie.com
designinginterfaces.com
Yahoo! Patterns
asktog

Books
the design of everyday things
the inmates are running the asylum
user interface design for programmers

Enjoy!

Chris

I finally got to reading through many folks blogs this evening. Here are several interesting posts that I eventually drilled through to:

Is Static Typing a Form of Bad Coupling? – More static/ dynamic language stuff

Finlabs – REAL COOL Algorithmic Trading
The 48 Laws of Power

Development Abstraction – go Joel – this is a great article. As Jeremy put it – I had almost given up on Joel – but this IS a great article – I particularly like this:

Management, in a software company, is primarily responsible for creating abstractions for programmers. We build the yacht, we service the yacht, we are the yacht, but we don’t steer the yacht. Everything we do comes down to providing a non-leaky abstraction for the programmers so that they can create great code and that code can get into the hands of customers who benefit from it.

That is just great. I call this idea “Building Boxes”. We try to – in essence, build boxes for the development teams. We build non-leaky abstractions – and they fill up the boxes. I talk about this all the time – well said Joel!

Go Obie – A web-based IDE for Ruby on Rails

Oh yes – SharpRobo – I am a FIT fan – so this ROCKS -

SharpRobo is a Functional Testing and Recording tool for WinForm applications written in .NET supported language. It supports all the standard WinForm controls. SharpRobo records the tests in FIT format which can be played back using Fit (File or Directory Runner).

More cool stuff via Obie – ActiveMessaging – for Ruby.

Lots of interesting stuff in the world as always

-Chris

Inspired by an article linked @ SlashDot …

I got to thinking about developing software for end users, as I often do….

My current project is a desktop credit derivatives trading application that ~900 users globally use (not too many I realize – but enough to be interesting). When I 1st came on the project the 1st thing that struck me was how poorly designed the user interfaces was – it was NOT apparent how to use it at all. We did have the opportunity to work on that… I have spent the recent time working on a new ‘trade blotter’ and general UI application architecture. One of my primary goals is, and will continue to be – making the UI feel like home to the end users. Making the UI really support the habbits, quirks and needs of the end user in a way that is not just ’some fluff atop the “real” program’. The UI is the real program as far as a user goes. All the nice ‘backend processing’ in the world is great – 100% needed, but the UI is where you can get strong percieved wins from your end users.
Here are a few links for those folks that want to keep up on UI design practices and patterns. So many software developers consider the UI tier to be the fluff part that means the least. Unfortunately – the users (that pay for the development generally) think the opposite

welie.com
designinginterfaces.com (book site with refs)
Sari Laakso’s patterns
..newer Yahoo!s UI patterns site

I will also mention that after a few years of doing larger class desktop application/ smart client development – I have seen the same issues and constructs come up over and over. 2 frameworks abstract smart client/ rich client/ desktop applications extremely well.

The 1st is the latest Microsoft CAB (Composite UI Application Block). This specifies excellent abstractions for common rich client application needs. When I was going over the internals – again and again I found myself saying ‘yes – we did that too’ or ‘wow – we solved that issue differently – you guys did it better!’. I will also note the Infragistics 2006.1 works directly with the CAB. Excellent move on their behalf!

The other is the Eclipse RCP (Rich client platform). I have been really studying out the guts of eclipse – the RCP in particular (while reading – The Java Developer’s Guide to Eclipse, 2nd Edition). What an excellent set of APIs these folks have come up with. The plugin architecture and the notion of ‘contribution based extension’ are particularly excellent.

-Chris

Rich Internet Application post

Someone else talking about post-browser apps. He is more focused on talking about ’social networks’, ‘FOAF’, ‘Tagging’ and (_so_called_) Web 2.0-ish stuff. My point in refereing this is – the post-browser era is coming….

-CD