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

I have been speaking with one of the gents over at SpringFramework.net. I am considering starting a project that would be in the same space as the Microsoft CAB - as a sub-project or sister project for SpringFramework.net . In short - CAB is fine - but I am not the biggest fan. I have spent the past several years working on so called ’smart client’ applications, ‘rich client’ applications, etc.

.Net applications are on the desktop. In most places on wall st - there are .net desktop apps with backends written in Java - this is how it is. That said, many applications still lack the fundamental framework or basic structure for abstracting constant features. They also lack the general seperation of concerns/ tiers that enable applications to scale out.

In no particular order - some important elements to an effective DAF (desktop application framework)

-Binding model objects to view elements
-Grid binding specifically with distinct ‘gridy’ features
-Client side data cache
-Plug in model
-Logging
-Object Factory/ service locator
-Common ways to work with menus
-Seperate persistence tier
-Add in mechanisms for views
-UI extention points
-Resource repository
-Workspace abstraction
-Model/View/ (presenter, controller, some variation of one of these many)
-Testability

I will continue to blog on this project as I am considering features to shoot for and some basic constructs.

RANDOM THOUGHTS…

• I also need to consider what external dependencies I will have - spring code, spring aop, log4net, rhino mocks and nunit to auto-generate tests.
• I would like to mimic some of how rails does code generation - like create a view - you get a controller, some tests, some mocks, etc.
• In chatting with Mark from Spring.net team - enhancing the Event Broker to make it more complete would be key. The Event Broker is one CAB element that I DO like. We need to consider the intra-app event broker and it’s recommended usages.
• consider Db4o for client side cache - and potential mapping to DB for real persistence.
• Build in UI testability in addition to testability for other tiers.
• Establish extention point APIs/ configurability (menu XML schema and interfaces that you have exposed).
• Need to provide concept similar to Perspectives in Eclipse for organizing view elements
• Context menu factory based on selected elements
• Static is evil - avoid it and still be convenient
• Focus on simplicity for developers
• Must be able to add and see a view in seconds without doing tons of work.
• Need repository repository
• Use UI application context
• Use Presenter Command notion
• Use Business Facades to hide business domain services. Commands orchestrate these
• Menu configuration
• Name, place in heirarchy, which menu, keyboard shortcut, Command referenced

Plenty more rambling to come as I am chattering about basic thoughts and trying to formulate my real goals.

-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

While reading Sam Gentile’s blog today I came across an article regarding the SCBAT (Smart Client Baseline Architecture Toolkit) and GAT (Guidance Automation Toolkit). I was also discussing this stuff this morning with my friend and collegue Marc. In any case - this stuff reminds me of something I had advised doing (and have begun doing) for a current project. It also reminds me of something in Rails.

The essence of all of this stuff:

You have some application patterns, structures and practices. You want to create all the ’stuff’ you need to use the architecture pattern effectively and efficently, with as little confusion as possible.

For example:

In the now famed Rails web development framework - when you want to create a new project, new view/ controller etc, you just issue some command line .. commands.

For example - to create a new application you can issue a command like:

rails path/to/your/new/application

This will create the folders, base files, etc for your new web application: folders for views, controllers, models, etc. You can also use the rails generate command to create new controllers etc. like:

rails script/generate controller SomeController

Now you have the basics of your Rails application.

SCBAT with GAT

Now - looking at the SCBAT - these great fellows are trying to do is to allow you to enter some data - and it will spit out all of the folders, code etc to make a compliant CAB application. This automates away all of the grunt work, it makes it clear what is needed and it provides the guidance needed to use the frameworks. This is what Sam is talking about in his post here. Cool stuff - making it easier for the team to work effectively with the frameworks.

Frameworks/ System architectures for non-trivial applications are complex. It is a fact of programming life. That being said - doing as much ‘Guidance Automation’ as possible sets the team up for success and takes away increasing amounts of potential error.

Prototype Spiked for a current project as Guidance Automation

I will be leaving my current project (a credit derivative trading smart client application) in 6 weeks. I will be going to a new project (FX options trading stuff). As I have been trying to set up the team I am leaving behind up for continued success using the application infrastructure we have developed - I considered making a custom sort of code generator that functions as these other GAT type things/ Rails type things do… it would take the basic data and go create all the classes, events, folders, etc needed to use the framework effectively.

A screenshot of the basic code generator.

In a few hours I was able to create an application that would take in the information about what the View was to do - and to automate the creation of many classes needed. Since we are using a Model/ View/ Presenter pattern where the View communicates with the Controller via events, there is a set of pattern classes that we can simply create if we know what the view/ controller are trying to do. Hopefully before I leave here - I will be able to leave the team with their own custom Guidance Automation type applicatio that will help keep them on track. This was in truth inspired by how rails works. I am looking forward to using CAB, SCBAT and enabling more and more code generation and other types of guidance automation.

-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