Self Expression

Hi

I was just watching a Channel 9 session about Open Space, an idea where attendees to a conference come together to discuss topics they find interesting. The thing about this is that it’s about the audience providing the content rather than the key speakers and that means the audience get to express their selves.

It reminds me of how important it is to people to have an avenue of self expression. Whether it is the colours we wear, the music we listen to, or what we say, pretty much every part of our lives is impacted by this almost primal desire to express ourselves. The same is true within software.

In software, many people are influenced. Whether it be the development team, the business people who fund it, the customer, or the end user. Hey, even the people who have nothing to do with the software but are affected by the business processes the software supports, everyone is affected in some way by software. But this is where these two ideas come together.

How are people expressing themselves through this software? Thinking about how people will express themselves while using the software is so very helpful in making great software. Why? Because it allows people to do things their way, to demonstrate their understanding, and to allow others to know who they are.

How does your software allow your customers to express themselves? Does your software allow your company and the people within it to express themselves? Human beings are relational and expressive. Keep this in mind when designing your next user experience.

Kind Regards
Glenn

MVP Pattern

Hey!

I haven’t been blogging as much as I’d like to because I’ve been busy writing my Wedding Application. You can find more about it in my previous post but if you’d just like a quick synopsis, in my spare time, I’ve started writing an application around my coming wedding. Being busy with this is not all bad because it’s helped me to revisit a technology I learned about on-site. Let me tell you more…

If you don’t already know about design patterns, they’re essentially descriptions of what works most frequently in programming. They’re based on a lot of the work by Christopher Alexander with his architecture patterns. Now, before you go googling for “software architecture patterns by Christopher Alexander”, you might like to know his patterns are for buildings, suburbs, and other general living spaces: i.e., not software. Although Christopher Alexander’s work wasn’t designed for software, it’s inspired a generation.

Anyway, this post isn’t about all patterns, I don’t have that much spare time; it’s a very large topic. Instead, I want to talk about the pattern I’ve been using for the GUI of my wedding application. This particular pattern is called the MVP Pattern or Model View Presenter.

So, the whole idea behind this model is to decouple the UI controls from the UI logic and from the business model. It doesn’t do this by burying the UI logic with the business model, that would be a step in the wrong direction, but instead, it introduces a new layer. Let me explain more…

The MVP pattern is really about three parts. The first is the Model, the business model. This is where your business logic exists. It’s not unreasonable for the model to be a complete module containing all the non-UI stuff: business logic, persistence logic, etc, etc. It knows how to do stuff, like create records and apply business rules.

The next part of the MVP pattern is the View. This is what you get to see, literally. This is your forms and windows, your dialog boxes and your console screens. Now, what I need to mention here is that it is developed as an implementation of an interface. This is because it decouples so greatly, it allows you to swap and change your views: think of one application with one UI logic yet interchangeably displayed on Windows Forms, WPF, Console, ASP.NET, or Silverlight. The application isn’t changed, the IView (typically) interface is simply implemented differently.

Lastly, the MVP pattern introduces the Presenter. This is where your UI logic exists. It’s actually the driver for the UI and the main conduit between the view and the model. It’s responsible for updating data displays, formatting displays, and notifying the business model of user commands.

What I like most about the MVP pattern is that it makes your UI logic testable. Unlike UI drivers that send window messages to your application, MVP allows you to unit test your UI logic and that’s what I like about it. It’s really early in the development cycle, meaning less cost to fix any defects that are injected in the product at that stage.

You might like to look at more here. You will definitely want to know that Martin Fowler has decided to split the pattern in to two separate patterns called Supervising Presenter and Passive View. Definitely worth the read.

If you haven’t already, I really urge you to get in to design patterns. They really do help with software architecture and enough people know them that you can use them by name in conversation with other software engineers. If you’d like another great resource, try Do Factory, it doesn’t include MVP but it is good none the less and reflects the GoF (Gang of Four) design patterns.

Kind Regards
Glenn

Unfamiliar

Hello again

I didn’t write all weekend or yesterday; Monday for those of you on the other side of the dateline. It’s not that I didn’t have thoughts of writing, it’s just that my thoughts didn’t become something I felt was good enough for this blog. Again, quality exists everywhere.

Anyway, today I want to talk about the milk in the fridge here at DWS. “Milk?” I hear you say; yes, milk.

Here at Quality in Software, anything can inspire a talk about quality, even milk. Anyway, enough of this ranting and on with today’s post…

Last week, I think it was on Thursday (5 days ago), a 1 litre carton of milk appeared in the upstairs fridge. What is odd about this is that we always have either a 2 litre or a 3 litre milk bottle. So what does it mean to software quality?

You see, no one has opened this poor carton of milk. It has been left there while bottles after it have been opened, emptied and replaced. So why has this poor carton of milk that sits faithfully in the fridge not been opened and used?

It reminds me of how people often don’t use great features in software. Often, great features in software can sit faithfully unused in our products while some common-place feature gets used again and again, even if it does mean more effort on the part of the person using the software. The question is why?

People are habitual beings. They tend towards the familiar and often avoid the unfamiliar. So does that mean this poor carton of milk in the fridge and the great features in software all go unused largely because they’re unfamiliar to their habitual human users? Yup! It does.

Now, I know not everyone is so habitual as this but I only comment on the results I see. And yes, I am one of these habitual users, which is why I can say that when I look at that poor carton of milk, I think, “Someone must have bought it for themselves and simply haven’t taken it home yet.”

One of two things will happen. Either people will continue to avoid the unfamiliar until the unopened milk goes bad and the great features of software get removed, or, just their constant “being there” will provoke a certain level of expectation, of familiarization. Either way, the milk won’t always be there: it will get consumed or thrown away. Now, while you’re thinking of how much of a waste this is while children go hungry in other lands, remember this is a software quality blog, not a human rights blog but I can understand your thoughts on this line.

Anyway, the idea from this is to be careful when adding fantastic features that will change the world. If they aren’t familiar to people or use basic principles that people already know, they will avoid it. It’s not because it’s bad or it doesn’t work, it’s just because it’s unfamiliar. When you do your designs and review quality, try considering the 1 litre carton of milk in the upstairs DWS fridge and present your feature in a way that is familiar to people.

Kind Regards
Glenn

p.s. no cartons of milk were wasted in the writing of this blog.