Subscribe: Atom or RSS

Charlie Seeks Friend, Open to Romance

by Alister Jones | Next up: And if you don’t know where you’re going… →

2 comments

----

I’ll Take What’s Behind Door Number Three

I have been in search of an interface convention for my application, Charlie. First I considered a conversational interface convention, then a PowerPoint interface convention, and then an explorer interface convention. My original plan was to evaluate many, many popular web applications such as Flickr and WordPress and the like. I have trialed both applications, but their usability pales against that provided by CityDesk. CityDesk gets it right because it builds on the Windows user interface, which also gets it right. This has convinced me that the third option, an explorer interface convention, is the right option for Charlie. I’m not going to trial more applications or come up with alternative interface conventions.

I have said before that my brain dines on Corn Flakes, so my challenge now is to break the Windows Explorer interface into its constituent parts. I started by skimming through the Apple Human Interface Guidelines, and immediately felt despair. Mac OS 9 was a fantastic operating system, and I miss it dearly. In the transition to Mac OS X, Apple seems to have put form over function.

I then attempted to read Microsoft’s Official Guidelines for User Interface Developers and Designers. What is ironic is that the documentation’s own interface is fucking awful! How about a “Next Page” link so I can go to the next page? In order to move to the next page, you have to find the current page in the treeview to the left, and click on the next leaf down. Worse, clicking on the link clears the screen and then loads up a whole new frameset, with a whole new copy of that same treeview. Why not just leave that bloody treeview there? Because I happen to be downloading Windows Vista in the background, it is taking about one minute to turn each page! (The Apple pages took a few seconds each to load.) Maybe it is deliberate that the documentation is impossible to navigate, to force developers to purchase the book with the same information? To hell with that resource.

The plan now is to learn about the new Windows Vista User Experience. With luck, I can get the Beta to work within Virtual PC, and I can see Vista in action. I’ll let you know how I go…

by Alister Jones | Next up: Charlie Seeks Friend, Open to Romance →

0 comments

----

Taking Scissors to a Web Page

In an attempt to find an interface style that would make Charlie easy to use, I first considered a conversational interface convention and then a PowerPoint interface convention. I very much liked the simplicity and user friendliness of the conversational interface convention, but a significant problem prevented me from saying, “That’s good enough. I’ll just run with that.”

The problem with the conversational and PowerPoint interface conventions is that they both see a webpage as being a single document. The user opens an entire webpage for editing, performs some edits, and then saves the entire document. The problem is that the webpage will be constructed from any number of separate plugins, and each plugin may need to present its own set of tools for the user to edit content. While it helps the user to see the webpage as a single document, it helps Charlie to see the webpage as separate pieces. There is a mismatch between the needs of the user and the needs of Charlie.

When I started thinking about the Windows Explorer and the Mac Finder, a solution occurred to me. Initially I thought that splitting a webpage into separate pieces (for the sake of Charlie) would cause confusion for the user. But then I thought about how users actually work with their computers. Office workers are used to working with Word, Excel, PowerPoint, and so on to create separate parts of documents. Designers are used to working with QuarkXPress, Photoshop, Illustrator, and so on to create separate parts of documents. The users employ Windows Explorer or the Mac Finder to keep the parts separate, and are used to firing up different programs to edit the parts separately. With the introduction of an explorer interface convention, website owners would be comfortable seeing the separate parts of their websites, and working on those parts separately, bringing the needs of the users in line with the needs of Charlie.

My only concern so far is that an explorer interface convention does not give Charlie a friendly face, which I have determined is important. But it may still be possible to integrate the best parts of the conversational interface convention with the new explorer interface convention. If the user fires up the Article Editor, the screen may look as follows.

When the user has finished composing or editing an article, he or she clicks on the Save and Publish command button. Charlie’s avatar can then report on what has occurred.

While the dummy screen above looks clumsy, I have not yet attempted to craft the interface. Still, I feel that I’m on the right path to an administration interface convention for Charlie.

by Alister Jones | Next up: I’ll Take What’s Behind Door Number Three →

0 comments

----

An Explorer Interface Convention

After reading through User Interface Design for Programmers by Joel Spolsky, I decided that I would give his CityDesk web creation program a whirl. While it has a few weak points, the program is delightfully easy to use.

The concept is simple. You have a treeview window that shows you files and folders, just like Windows Explorer. If you double-click on one of the documents an editor or viewer opens up, just like Windows Explorer. CityDesk is a desktop application for Windows; it is not a web-based application. Still, the simplicity, familiarity, and effectiveness of this approach got me to thinking about how it would work in a web-based application.

After scribbling a few ideas on paper, I fired up Photoshop. Here is the first screen I created. (All of these screens are dirt-simple, as I was just recording some ideas.)

Because this is such a familiar interface I am sure I don’t have to explain it. (I wouldn’t need to explain it to users, either.) But what will be transparent to users but of interest to us is that the folders with icons are not mere folders. Rather, they represent plugins. The Photos folder, when opened, will be handled by the Photos plugin. The Weblog folder, when opened, will be handled by the Weblog plugin. To test this idea, I next created the screen that the user would see if he or she opens the Photos folder.

The tasks area means that every plugin can provide different functionality, yet in a consistent way. Here is a further example of another plugin looking the same, but working differently. This example also shows the simple way in which draft documents can be handled.

If the user double-clicks on an Article document, the Article Editor opens and displays the document for editing, just as it would from Windows Explorer or the Mac Finder. What the following screen adds is the simple, text-only command bar. This would be added to the folder windows above, but I didn’t want to waste time reworking the above images.

There is a very important commercial benefit to using icons to represent functionality. Namely, the icons can be dimmed to show that the functionality is available but disabled, and the user must upgrade in order to enable that functionality. Alternatively, the dimmed icons can represent “demos”. A user with a basic-level membership can see the dimmed Blog icon, and can double-click it in order to create draft blog documents (remember, draft documents are dimmed too, so the consistency carries through). Creating draft documents allows the user to trial the additional functionality. Then, if he or she upgrades to a better membership level, the draft documents can be published.

Because I was getting a bit bored of Photoshop at this time, I threw together a quickie Control Panel in order to document the idea.

An explorer interface convention like this provides at least three main benefits. First, the convention is familiar to all computer users, so a user should be able to get going as quickly as possible. Second, the convention benefits from more than twenty years of user interface research performed by Apple and Microsoft. The third benefit is more involved, and I’ll chat about it in my next weblog entry.

by Alister Jones | Next up: Taking Scissors to a Web Page →

0 comments

----

A Word from Joel - Part 3

I’d like to comment on one final aspect of Joel Spolsky’s series of essays on User Interface Design for Programmers. At the end of Affordances and Metaphors, Joel explains that the tabbed dialog convention is incredibly successful in communicating with the user about how to transition between different option screens.

Why do I not adopt a tabbed interface convention? The following mockup, using the WordPress administration screen, shows why.

Firefox, Netscape, and soon Internet Explorer feature tabbed windows. The alisterjones.com website features tabbed navigation, which is a very popular navigation style. If Charlie’s administration screens adopt the same tabbed convention, then the user may end up viewing a screen featuring tabs within tabs within tabs. Users won’t be thanking me for that.

It is for this reason that I’d like for Charlie’s administration screens to clearly separate the browser from the contained website. This requires using an administration area that provides some visual space, and that features an interface convention that is different from the browser above and the contained webpage below.

While the above is still far from perfect, I do sense that the conversational interface convention has a lot to recommend it.

Still, my research on interface conventions is far from over.

by Alister Jones | Next up: An Explorer Interface Convention →

0 comments

----

A PowerPoint Interface Convention

When I first talked of my search for an interface convention, I mentioned that my original plan was to mimic Microsoft PowerPoint. I then dismissed this approach as being too limited. However, Joel Spolsky’s Consistency and Other Hobgoblins essay has made me reconsider this interface.

Here is the interface I came up with about 18 months ago, when I first started thinking about webpage editors.

To state the obvious, the benefit of this interface is that it is consistent with the Microsoft Office software with which most users are familiar. By adopting this interface convention I could, in one move, provide Charlie with an interface that behaves exactly how the user thinks it would, which is the definition of a good interface. Still, I do have concerns about this design.

First, a webpage is presented within a separate browser application. That means that the browser application will have its own set of drop down menus and toolbars, and then there’d be another set of drop down menus and toolbars within the child web application. This does not occur in any other desktop software, so such an interface convention is not as immediately familiar and externally consistent as it may first seem.

Second, I am not sure how far you could take this interface convention in a web application. The menu above includes an Insert Page option. What happens when the user clicks on it? The plan at the time was to present a set of page templates (such as Weblog Page, Article Page, Photo Gallery Page, and so on), exactly as PowerPoint does when you click on Insert Slide. That may be okay, but where in the site map would the new page appear? How would you give it a URL address? Can this interface support the concept of draft pages? While mimicking Microsoft PowerPoint provides the benefit of familiarity, I wonder whether it does so at the cost of simplicity and flexibility.

Still, there it is, another possible interface convention.

by Alister Jones | Next up: A Word from Joel - Part 3 →

0 comments

----

A Word from Joel - Part 2

In the second part of Joel Spolsky’s User Interface Design for Programmers series, a few more interesting ideas are raised.

The first idea is that users do not read manuals, and they do not read instructions. This was one of the forces behind my conversational interface convention. With only a few exceptions, it is not always clear what pressing a button will do. The “Edit” button edits what? Edits the whole page? Edits the photo above? Edits the text below? Given that users do not read manuals or instructions, how can we educate the user? My current resolution is to put the button within a sentence.

Placing a button within the context of a sentence supports both new users and frequent users. New users can skim the text and be sure of what that button will do. Frequent users will “tune out” the surrounding text and will just see the three clickable buttons. Sure, this takes up more vertical space than if three unadorned buttons were placed side by side. But a webpage is a document with virtually unlimited vertical space, unlike a desktop application where the screen space is limited. I feel that the user-friendliness of this approach is worth the price of the vertical space it requires.

A second interesting idea put forth is the following:

“An important rule of thumb is that user models aren’t very complex. When people have to guess how a program is going to work, they tend to guess simple things, rather than complicated things.”

If you’ve been following my ramblings for a while, you’ll know that I agree with this rule of thumb in the strongest possible way. But let me tell you a concern that I have. I am so astonished at the complexity that developers introduce to interfaces that I have started to wonder whether I am actually a bit stupid. There’s only two possible truths. Either 99% of developers are right—users accept complexity—and I’m wrong. Or, I’m right—users expect simplicity—and 99% of developers are wrong. If you think I’m being modest, I’m not. This truly worries me. So that I don’t fall into another sea of doubt, I’m going to presume that Joel is right, most other developers are wrong, and I should aim to make Charlie as simple to use as possible.

by Alister Jones | Next up: A PowerPoint Interface Convention →

1 comments

----

A Word from Joel - Part 1

I have come to the point in the development of Charlie where I need to decide upon an interface convention. Without researching the topic, a from-the-heart approach occurred to me which I have named a conversational interface convention. (By the way, I had to name it simply to give the weblog entry a title—not because I think it’s worthy of an official name.)

The plan now is to properly investigate interface conventions, to evaluate any conventions I find, and decide upon a convention for Charlie. I have decided to start with Joel Spolsky’s User Interface Design for Programmers. I love this guy’s writing, and I believe in what he writes about. If it’s not immediately apparent, this weblog is fashioned after Joel’s own website. The pictures of Marilyn that pepper my posts? Inspired by the “break this page up” photos that Joel adds to his posts. The poor attempts at humour? Inspired by Joel’s suggestion that technical writing need not be boring. The analogies to popular culture? Inspired by Joel’s own stories. I’ll never be as good a programmer or as interesting a writer as Joel, but I’m doing my best.

After a funny story about a skinny kid and a blob of dough in a bathtub on wheels (one of which is wonky), Joel arrives at the following golden rule of interface design.

“A user interface is well-designed when the program behaves exactly how the user thought it would.”

It would be easy to dismiss this rule as being so common-sensical that it does not warrant consideration. But you need only look at virtually every bit of software and every website to know that this golden rule is very rarely achieved. So let’s give this rule some consideration. Or, more accurately, let me give you my take on it.

It is my interpretation that a user interface will behave exactly how the user thought it would if it is both externally consistent and internally consistent.

A user interface is externally consistent if it behaves the same way as other programs. Jakob Nielsen promotes this idea very heavily and, while I don’t agree with everything he says, I reckon he’s right on the money about this. If you come up with a completely new interface paradigm, then you’re free to make your own rules. But if you are working within a known interface paradigm, then if behooves you to make your application externally consistent. I think most web applications get this very, very wrong, and I’ll look at specific examples when I review existing web applications.

A user interface is internally consistent if it keeps behaving the same way in response to the same user actions. If a similarly-styled hyperlink sometimes takes you to another page, sometimes submits a form, sometimes executes some JavaScript, sometimes pops open a new window, and sometimes scratches your nose, then the web application provides no internal consistency. Again, I’ll look at specific examples shortly.

So that’s the first lesson from Joel. But class is still in progress…

by Alister Jones | Next up: A Word from Joel - Part 2 →

0 comments

----

A Conversational Interface Convention

Over the last few days I have been thinking a lot about a possible interface convention. So far, I have come up with one possibility, which I will call a conversational interface convention. The idea is that Charlie talks to the user, and the user replies. Let me illustrate.

Here is what an administrator would see if she logs into my own website and navigates to an article page. The dog avatar is not what I would use, but I like the casual illustration style of Steve Barr. The avatar always provides feedback on what is happening. If an AJAX-type callback is in progress, the avatar would say something like, “Please wait while your updates are saved.” Following the speech bubble, the user can say what she would like to do in response to what the avatar has said.

If the user clicks the Edit button, the process moves into Edit mode and the user will see the following page.

While it’s not especially relevant to the topic at hand, I envisage using MarkDown.NET rather than a rich text editor, but I’ll talk about that at some later point. What is notable is that the speech bubble has been updated, and the user has new options. If the user updates the content, she clicks the Preview button. The process moves into Preview mode, and the user will see the following page.

What you may notice is that the process is presented in a Wizard-like back and forth series of pages, but without the limits of a true Wizard implementation. The same conversational interface convention extends to other parts of the administration pages, such as the Control Panel:

What I like about this interface convention is that it puts into action the two decisions made about the ghost in the machine. That is, Charlie is given a friendly face and is brought to the fore. (Again, I would not actually use a dog.) Additionally, each button press results in a consistent and predictable full-mode change. The ability to have the avatar provide feedback, and then show the user a list of possible responses, is very simple yet infinitely flexible. This interface convention could, I believe, be extended to every possible administration page.

This is just the first interface convention that has occurred to me. I felt that creating a rough draft in Photoshop would provide a “taste” of the idea, and allow my pending interface research to have a point of reference. Even better, I’d love to know what you guys think of the concept.

by Alister Jones | Next up: A Word from Joel - Part 1 →

2 comments

----

Getting Real. Get It!

by Alister Jones | Next up: A Conversational Interface Convention →

0 comments

----

One Interface or Two?

The authors of Getting Real recommend that a web application provide just one interface. Any administration tasks should be incorporated into the same interface that the public sees. This is an implementation of the half-mode change that I discussed in the previous weblog entry. Well, I disagreed with the concept of a half-mode change, and I certainly disagree with the concept that a web application should provide just one interface.

To incorporate the administration screens in the public interface means to extend the administration plumbing out into the public areas, which is about as appropriate as extending the plumbing of a house out into its living rooms and placing a toilet beside the lounge. There are many reasons why a toilet belongs in a bathroom, and privacy is just one reason. There are mechanical and architectural reasons too.

It is my contention that a website requires exactly two interfaces, and that both interfaces are very, very different. One is the web site interface and the other is the web application interface.

To put it another way, the web site should be free to use the simplest and most effective approach possible for the website’s owner to communicate with its customers. The web application should be free to use any amount of complexity necessary to carry out administration tasks. The web site and the web application have different purposes, different requirements, and different forces. What good can come from trying to mesh the two together?

Charlie will not attempt to achieve a single interface by incorporating administration functions in the public website. The public website and the private web application will be kept separate.

by Alister Jones | Next up: Getting Real. Get It! →

0 comments

----

Should the Ghost in the Machine be Invisible?

For anyone new to this weblog, I am developing an application named Charlie. At this point in time, I am seeking an interface convention to ensure that all administration screens act in a consistent and predictable way. To this end, I have been thinking a lot about interfaces and how users interact with software applications. Right now, I am considering two separate but related aspects of interface design. First, should Charlie itself be invisible to the user? Second, should Charlie’s mode changes be invisible to the user?

Now, should Charlie itself be invisible to the user? I have said earlier that software should stay out of the way while the user performs a task, but that is not the same thing as being invisible software. The original Mac operating system provides a great example. The OS never got in the way, but Apple did not hide it, either. To start with, the operating system had a face:

This is no mere gimmick. This is a message to the user: “I am here. Know me. Love me.” Apple did not hide the OS away; it brought it to the fore and made it a friend. Microsoft does not take this approach with its Windows operating system. The operating system is kept in the background, and makes no attempt to befriend the user. Both operating systems stay out of the way, but Windows walks behind the user, and the Mac walks beside the user. It is my opinion that the Mac approach brings with it two real benefits that I’d like for Charlie to exhibit too.

One benefit to making software a friend is that it enables the user to forgive the software if it displays any shortcomings. It is easy to get mad at Windows, because it operates like it has a bunch of goblins running about, out of sight, causing mischief. Windows is quite unapologetic about its screw ups. But it is hard to get mad at the Mac, because it operates like a friend who, on occasion, gets things a little wrong. The Mac will show you its face, tell you what’s gone wrong, and effectively says, “Look, I messed this one up. But we’re still friends, right?” Right!

Another benefit to making software a friend is that it makes the user reluctant to let it go. You just don’t discard friends. (Or if you do, I don’t want you as a friend or as a customer.) If the users of Charlie form an emotional attachment to the software, then they will not switch to another application just because it is a little cheaper or because it offers a few more features. Friends stick together.

Say that the owner of Homunculus.com wants to edit his Carla Gugino page, because he wants to let the world know that she gets naked in Sin City. He opens his browser and navigates to Carla’s page. Right now, he’s in View mode. How should he switch to Edit mode?

If the change from View mode to Edit mode is invisible (which can almost be done), he’d simply place the cursor at the end of the page, and start typing the new content. If he navigates away, some Ajax trickery can send the updates to the server to be saved to the database. We might say that this is a zero-mode change.

If the change from View mode to Edit mode is explicit but occurs without fetching a new page (get a free account with BackPack to see this in action), he’d click on an “Edit this Content” button which replaces just a part of the page with a textbox. The website owner can add his comments about Carla’s curves and then click on a Save button. The textbox disappears and the new content is displayed (more Ajax trickery). Since a part of the page changes mode while the rest of the page stays the same, we might say this is a half-mode change.

The final main option is that the website owner can click on an “Edit this Content” button which fetches a whole new page which makes no attempt to look like the live page, and attempts only to present a form with which the owner can update his website. Since the entire page changes and there is an explicit switch between View mode and Edit mode, we might say that this is a full-mode change.

The question is, which type of mode change is best? Zero-mode, half-mode, or full-mode? The answer to this question means deciding just how transparent a mode change ought to be.

It is my belief that zero-mode changes are dumb. How many times have you been bothered by users who become completely confused because they mistakenly undocked a toolbar, or moved or resized the taskbar? The need to undock a toolbar or move a taskbar is so rare that it is dumb to make it a zero-mode-change operation; all it leads to is confused and annoyed users. Without an explicit mode change, the user has no idea where they are in the task they want to perform, what they can do at this point, and what they can do next.

It is also my belief that half-mode changes are an inadvisable goal for software. To start with, it can be disorienting for the user. There is no sense of “location within the task,” since a part of the screen is performing one task (showing content) and another part of the screen is performing another task (editing content). Another problem is that not all tasks can be undertaken with a half-mode change. That means that sometimes the Edit button will initiate a half-mode change, and sometimes the Edit button will initiate a full-mode change. This unpredictable behaviour provides for a poor user experience. A further problem is that such “in-place editing” provides no opportunity for draft content, because all changes are made to the live content. That’s okay for a narrow range of software, but for a website framework it is important that the owner can start to create a new page and then change his mind. If the website owner suddenly finds that he doesn’t have enough information to finish the content, then he should have the option to save the content in draft form, and finish it later.

It is my belief that full-mode changes are the only realistic target for an interface convention. By making full and explicit mode changes, the user will always know where he is within a given task, and what he can do next. Also, if the same full-mode change is made every time an Edit button is clicked, this will provide the user with consistent and predictable behaviour. Finally, full-mode changes allow for complete control over what to do with the data on the “edit this content” page; that data can be discarded, or saved in draft form, or published to the live website. Sure, full-mode changes are clunky and uncool, but they are flexible, predictable, and consistent.

Unless further investigation shows that my beliefs are mistaken, Charlie will be visible to users, and its administration pages will involve a full-mode change.

by Alister Jones | Next up: One Interface or Two? →

0 comments

----

The Interface. The Chicken or the Egg?

In my previous weblog entry, I disagreed with the advice in Getting Real about getting to “Done!” as soon as possible. In this entry, I will disagree with another piece of advice, which is that you should design the application’s interface before you start programming. Hogwash!

Every software application is created to solve a problem. Even a game is created to solve the problem of, “I’m bored.” Surely it stands to reason that if a software application is created to solve a problem, then the first thing you should do is solve the bleeding problem! You could design the sexiest interface in the world, but if it is not attached to software that solves the problem, then the software will fail. You could design the fastest database in the world, normalised to the tenth normal form, but if it is not attached to software that solves the problem, then the software will fail.

This is a common complaint about games released in the last few years. They look great, run fast, but are simply boring to play. The actual problem of, “I’m bored, entertain me,” has not been solved. In contrast, check out Boom Boom Volleyball. This game looks poor, runs slow, but is fun to play. Since it solves the stated problem, is it not successful?

by Alister Jones | Next up: Should the Ghost in the Machine be Invisible? →

0 comments

----

The Power of Two

So far I am enjoying reading Getting Real. The authors take a very pragmatic approach to most of the problems of software development, which is a refreshing change from the stringent approach taken by most authors. What is interesting is that Getting Real presents many of the same arguments as Agile evangelists, but without the zealous fervour of those evangelists. With the zealots, it is very hard to see passed bullshit and through to the ideas. With Getting Real, there is no bullshit, so the ideas are right there to be learned and applied. It is a great book and I recommend it highly.

What I cannot recommend, however, is the advice on the page entitled, “Done!” The idea presented on this page is that decisions are temporary, a poor decision is not the end of the world, so just make a decision and move on. I think this is poor advice.

Earlier in the same book, a quote is presented from The Pragmatic Programmer by Dave Thomas. The quote is as follows:

“As the designer or developer of a new application, you’re faced with hundreds of micro-decisions each and every day: blue or green? One table or two? Static or dynamic? Abort or recover? How do we make these decisions? If it’s something we recognize as being important, we might ask. The rest, we guess. And all that guessing builds up a kind of debt in our applications—an interconnected web of assumptions.”

I feel that if a developer accepts that all decisions are temporary and relatively unimportant, then the developer is just going to start making guesses so that he or she can get to “Done!” as quickly as possible. As Dave explains, this builds up a kind of debt in the application. And like all debts, it will become due for payment at some later date.

During the development of Charlie, I have noticed that I have evolved my own approach to making a decision. First, I will read just enough about the subject so that I understand the issues involved. Then, I will read how Microsoft recommends that a particular problem be solved. Next, I will put pencil to paper and see if I cannot come up with a simpler solution. Only after comparing Microsoft’s recommendation against my own ideas will I make my decision. That is, I end up comparing two recommendations: Microsoft’s and my own.

Throughout this weblog, you will have noticed that I often say, “There are two main approaches,” or “There are two possible solutions.” Often they are salt-and-pepper options; one will be direct and one will be indirect, one will be simple and one will be complex. Again, I end up comparing two approaches.

I feel that two is a good number. If you don’t evaluate at least two alternatives, then you’re really just relying on gut instinct, which is little more than an outright guess. Conversely, if you try to evaluate more than two alternatives, then you probably haven’t yet distilled the problem down to its core. At the core, most problems have two forces pulling in different directions: direct against flexible, simple against complex, developer against user, and so on. If an issue does involve more than two forces, I reckon the issue qualifies for being broken down further, again and again, until you end up with a set of easily-stated problems, each with just two main solutions. Then, you need to decide between the two. That will be a true decision, not a guess masquerading as a decision.

So this represents a different approach to that recommended in Getting Real. Rather than getting to “Done!” as quickly as possible, I will aim to get to “two” as quickly as possible, and then make a decision.

by Alister Jones | Next up: The Interface. The Chicken or the Egg? →

0 comments

----

Opinions and Preferences

In an episode of Seinfeld, we see the interaction between Jerry and his assistant. His assistant annoys him about the smallest little details; so much so that he sometimes forgets what he’s doing.

Software can be like that. A great example is provided by Joel Spolsky when he talks about the Find Setup Wizard.

Have you seen this dialog? Sure you have. What was your response? My initial response, and every response since, has been, “What the hell are you asking me? Why are you asking me this? What happens if I make a poor choice? Go away!”

To ensure that your own application does not become like Jerry’s annoying assistant, the authors of Getting Real recommend that you make opinionated software. An application should have its own opinions, and apply those opinions wherever possible, thereby leaving the user to concentrate on whatever it is he or she is doing. I think that’s sound advice.

Another section of the book recommends minimising the number of preferences that your application makes available to the user. Or in the words of the book, “Decide the little details so that your customers don’t have to.” This is another take on making opinionated software.

It would seem that to make software with more opinions and fewer preferences is to remove control from the user. But does it? Why is the user sitting at the computer in the first place? To mess around or to get something done? Remember that most users are not developers who will feel cheated if they cannot control every little aspect of the application. Most users just want to get something done without the software getting in the way. And that is not to say that most users do not care about the software. I don’t mean that at all. I mean that most users truly want the software to stay out of the way while they concentrate on the matter at hand.

One of the most powerful, most popular, and most productive software applications is Adobe Photoshop. With this software, users can do anything. Every magazine you read, every movie you watch, and every website you view has probably been touched by Photoshop. Yet if you look at the number of preferences it makes available, you will wonder if you mistakenly bought Photoshop Lite. If Adobe Photoshop can provide infinite flexibity with so few application preferences, you will see that opinionated software really does empower the user, not limit the user.

What does this mean for Charlie? That no preferences will be made available? No, not at all. Good software is flexible, and I’d like for Charlie to be deemed good software. What I will attempt however is to minimise the number of preferences that are exposed to the user. The flexibility will still be incorporated into Charlie, but I will set as many preferences as possible, leaving only the most important to be set by the user. In that way, I hope that Charlie will be the helpful assistant that Jerry truly wanted.

by Alister Jones | Next up: The Power of Two →

0 comments

----

Love the Little Guys

An important idea that Getting Real discusses (in just two paragraphs—that’s how simple the book is) is to find the right customers. The corollary is that if you try to please everyone, you will not please anyone.

While that is well-known wisdom, how often is it forgotten in designing software? Because I have chosen DotNetNuke as Charlie’s enemy, I will use this software as an example. DotNetNuke attempts to be all things to all people. Its core and its modules support the development of small websites and the development of large websites. If you view the forums for this software, you will see that it does not provide the simplicity for small websites nor the flexibility for large websites. It attempts to please everyone, and ends up pleasing no-one. Well, the only people it pleases are gimmick-loving developers, but I have already argued that that is the wrong target for a website framework application.

Who will Charlie target? Charlie will target the websites created for individuals and small businesses.

The first and most important reason that Charlie will support individuals and small businesses is that this is what I enjoy. I enjoy having a small part to play in the individual’s life or the small business’s growth. If I were to target large companies, I would be a dispensable contractor, and where’s the fun in that?

The second reason that Charlie will support individuals and small businesses is that this is a market with little support. For large companies, DotNetNuke or Community Server would fit the bill. But both applications are overkill for the little guys.

The first market is photographers. I have one personal reason and one professional reason for targetting photographers. The personal reason is that I adore photography. I find it such a beautiful form of art that it pains me to see some of the awful websites used to present such beauty. I want to do it better, for the sake of the photographer. The professional reason that I want to target photographers is that photography represents one of the hardest parts of a website framework. Any noodle can create an interface by which a website owner can add and edit the text of the webpage. But how to create an interface by which a website owner can upload an image, work with that image, and place that image on the webpage? I feel that if I can solve that challenge, the resulting interface convention can then be applied to both simple and complex administration challenges.

The second market is wine makers. Once again, I have one personal reason and one professional reason. The personal reason is that many wine makers are individuals who have a vineyard as a business on the side. These are the sorts of small businesses that I enjoy working with. The professional reason is that to provide a website framework for wine makers requires proper business objects including a bottle of wine and its tasting notes. I want Charlie to provide the wine maker with the option to “Add a new wine product,” and then properly present an interface by which the wine maker can add the product’s title, volume, bottling date, acidity, and so on. This is in stark contrast to giving the wine maker a rich text editor and telling him, “Type whatever you like.” This is where I see that I can make Charlie different from the rest. Most website framework applications effectively say to the website owner, “Look, we don’t give a shit what your business is about. We’ll just provide you with some tools so that you can write whatever you like.” I think that sucks, so Charlie is going to care about the business of the website owner.

After Charlie has successfully supported photographers and wine makers, it will be evolved to support other individuals and small business. Charlie will love the little guys.

by Alister Jones | Next up: Opinions and Preferences →

2 comments

----

Charlie’s Enemy

At this stage in the life of Charlie, I am following the teachings of Getting Real. The book advises that a new software application should have an enemy. The book states, “Sometimes the best way to know what your app should be is to know what it shouldn’t be.”

Throughout this weblog I have picked on DotNetNuke like it was a snot-nosed little kid who put his pants on backwards. Technically, DotNetNuke is a cleverly architected application that many, many developers use to earn good income. Moreover, DotNetNuke will forever be more advanced than Charlie could ever be. If anything, Charlie will be the 90-pound weakling who will have sand kicked in its face by the mighty DotNetNuke. So why do I use DotNetNuke as Charlie’s stated enemy?

The reason I dislike DotNetNuke so much is that it is software created by developers for developers. That is wrong. We developers, we’re just middlemen. Our task is to provide a medium through which a website owner can talk to its audience (which may be friends, business partners, customers, or others). A website framework should target one or both of those principals—the owner or its audience—and not the middleman.

To provide an example, have a look at the following web address:

www.DotNetNuke.com/About/ProjectOwner/tabid/822/Default.aspx

That web address is clearly created by developer for developers. It has crap in the address that is designed to support developers, but that penalizes the website’s owner and the website’s audience. Such a long address cannot be added to the owner’s marketing material, and cannot be easily described over the phone. Such a long address cannot be easily typed by a visitor. If the software was created for website owners and its audience, that sort of crap would never find its way into the software.

If a gimmick comes out of Microsoft, it is immediately added to DotNetNuke. A Data Access Application Block was released by Microsoft and—slap!—in it goes to DotNetNuke. The new concept of Themes was released by Microsoft and—bang!—in it goes to DotNetNuke. What does a website owner care if the site is styled by CSS, a Theme, or a monkey with a paintbrush? The only reason this stuff goes into DotNetNuke is to appease developers; it is software created by developers for developers. To my mind, a feature should be added to an website application only if it adds value to the website’s owner or the website’s audience.

So Charlie has found its enemy.

by Alister Jones | Next up: Love the Little Guys →

0 comments

----

In Search of an Interface Convention

Those of you who have followed this blog for a little while will know that I recently stated that Charlie was on track, and was successfully serving simple, secure, localized, and configurable webpages. I then stated that I was moving on to design the administration interface. So what happened? Why am I suddenly stumbling about like a lost soul or a drunken teenager?

The reason is that I am in search of an interface convention. Not a code convention, but a presentation convention. I will nonetheless use a code convention to illustrate the problem. A popular code convention is the Model-View-Controller design pattern. This is an extremely versatile convention that works for simple interfaces and for complex interfaces. If you introduce this code convention into your Interface layer, it is unlikely you’ll ever need to replace it with something else. Similarly, I am seeking a presentation convention that works for simple interfaces and for complex interfaces, making it unlikely that I’ll ever need to replace it with something else.

My initial plan with Charlie was to create an interface that mimicked Microsoft PowerPoint. Say what you will about this program, it enables even the most technophobic person to create a slideshow presentation. Everyone can use this program without ever having to read its instructions. That’s good software. I felt that the slide-by-slide nature of PowerPoint mapped neatly to the page-by-page nature of a website. I also saw other analogies between the two. The problem with this approach is that it would be fine for a simple text-based website, but it would not scale to anything else. It does not provide a convention that would work for simple interfaces and for complex interfaces.

I am desperately keen to avoid a situation where to edit the text of a website the owner “edits in place” (like PowerPoint), and to edit the graphic of a website the owner needs to “open a new window”, and to change the settings of the website the owner needs to “use the control panel”. Such a situation would mean that the software behaves differently depending on what button the owner has pressed. This mutating behaviour means that the website owner must come to terms with the software’s quirks, rather than using the software as though it were not even there. In describing usability, Joel Spolsky tells us that, “Something is usable if it behaves exactly as expected.” Interface consistency—that is, an interface convention—has a large part to play in whether software behaves exactly as expected.

The development of Charlie has been put on hold while I search for an interface convention.

by Alister Jones | Next up: Charlie’s Enemy →

2 comments

----

The Secret of Life - Continued

In my last weblog entry, I opened with some advice presented in the movie City Slickers. I then waffled on about what might be important, without coming to any conclusion.

Well, another line from the same movie has Curly saying to Mitch, “You city folk, you sure worry about a lot of crap, don’t you?” (Something like that, anyhow.) That’s me, worrying about a lot of crap.

In a draft of a weblog entry that never got published, I said that DotNetNuke is complex software that produces ugly websites. I then said that Charlie is to be simple software that produces beautiful websites. Well, that’s good enough. It defines what Charlie is—simple software—and what it does—produce beautiful websites. That’s good enough.

by Alister Jones | Next up: In Search of an Interface Convention →

0 comments

----

The Secret of Life

In the wonderful movie City Slickers, Mitch is lost in his life, and takes a cattle-driving vacation in order to find some meaning. Curly takes Mitch into his confidence and explains that the secret to life is just one thing. Mitch desperately wants to know—needs to know—what is the one thing that is the secret to life. Curly tells Mitch that it is up to him to figure it out himself. Not because it is inexplicable, but because it is personal. The secret to life will be different for each and every person, but for everyone it will be just one thing.

At the start of Getting Real, the authors advise that a new software application should aim to do less, not more, than its competitors in order to gain an advantage.

The advice in the movie and the advice in the book really say the same thing: ignore what’s unimportant, and find what’s important. Find what is important, get it right, and your life or your application will be successful.

I have given this quite a bit of thought, and I have asked myself what is the one thing that Charlie should do? Looking at the elevator pitch and the feature list, there is no identifiable driving force. I have not discovered the one thing that is the secret to Charlie’s life. If I wanted an application that allows a website owner to edit his or her own website, I could have chosen DotNetNuke. But the fact that I have avoided DotNetNuke means that while my head doesn’t know what that one thing is, my heart knows that DotNetNuke will not satisfy it. The elevator pitch and the feature list were products of my head, and DotNetNuke would have satisfied them. So, what did my heart want?

My heart wants for my business, Edition3, and my product, Charlie, to help others achieve what they want. That may sound like a sales pitch. I guess that it is a sales pitch, but it is not an empty one. Dale Carnegie has said that if you want to succeed, help others to succeed. Well I do want to succeed, and I do want to help others to succeed. How can Charlie help?

Let me tell you that I have just spent two hours trying to answer the question. The truth is, I don’t yet know. Many ideas occurred to me, and I started explaining each one. But each one felt a little bit wrong. My heart knows that I can create an application to help others to succeed (even if just in a small aspect of their lives). But my head cannot yet articulate how that can happen. So I will work my way through Getting Real, and will use this weblog as a way of documenting what I discover along the way.

If you think that all of my doubt and worry and indecision means that I should not be doing this, you are probably right. But another lesson from Dale Carnegie is, “Don't give up.”

by Alister Jones | Next up: The Secret of Life - Continued →

0 comments

----

When the Student is Ready…

…the Teacher will Appear.

I was drowning in a sea of doubt. I was flailing about, trying to find a guide. The problem was, I was looking in the wrong direction.

If you look about the software development landscape, you will see a crowd of nerds standing on the hill, chanting like possessed men. “UML, UML, UML,” intone the nerds around their disciple Scott Ambler. “Charts, charts, charts,” hum the nerds around their disciple Craig Larman. “Statistics, statistics, statistics,” recite the nerds around their disciple Jakob Nielsen. Walk into that crowd of zealots, and they will pound you over the head with the heavy books they carry.

If you turn your back on the crowd of nerds, you will see a few guys sitting quietly beneath a tree. They don’t chant. They don’t beckon you over. But if you go to them, they will provide you with words of wisdom. They will talk from their heart, and not from their head. They will not force their own ideas upon you, but will encourage you to have faith in your own ideas, and show you ways to bring those ideas to fruition.

I was ready for these teachers. I had my own ideas, but the zealets kept telling me I was wrong, and I fell into that sea of doubt. I would never have seen these teachers if it were not for Milan Negovan pointing me in their direction. The teachers are the guys at 37signals. Their blessed teachings are passed on in their little book, Getting Real.

What makes these teachers so great? I desperately want to say, “They keep their message simple,” but I think if I mention the s-word one more time you will all scream. Instead, I will demonstrate by using a couple of icons of popular culture.

Sergio Aragones is an artist who can tell a story in a single tiny drawing. He’s the guy who creates the little illustrations in the margins of Mad Magazine. He can tell a funnier story in one basic drawing than most writers could tell in a whole page of prose.

Bruce Springsteen is an artist who can tell a rich story in a few verses. In a single line he tells of the passage of time:

But now there’s wrinkles around my baby’s eyes

If you’ve ever read a book by Jean Auel, you will know that many authors need a whole page to say the same thing.

Well, the guys from 37signals are in the same league as Sergio and Bruce. They can say in one sentence what would take Scott Ambler and the other disciples on the hill an entire page to say. (By the way, I am not unaware that these rambling weblog entries mean that I, too, am just as verbose.)

As I write this, I have only read a few dozen pages of Getting Real. But already it has told me to have faith in my ideas, and to not listen to the fools on the hill. Starting with the next weblog entry, I am going to work through this book, and apply its wisdom to Charlie.

by Alister Jones | Next up: The Secret of Life →

0 comments

----

Lesson: Show Simplicity, Hide Complexity

I know, I know, I rabbit on about simplicity as though it were the only thing of importance. Because I rabbit on, you’d think that you could look at my codebase and marvel at the tiny number of files and the small number of lines of code. However, if you were to view Charlie’s codebase, you’d see just as many files and lines of code as you’d find in a complex software application. The fact is that any non-trivial software application will require code, and lots of it. Where is the simplicity?

Simplicity comes from avoiding unnecessary complexity, and hiding necessary complexity.

First, simplicity comes from avoiding unnecessary complexity. And what is unnecessary complexity? It is complexity that is there “just in case” you might need it, even if the chance of needing it is about as likely as Kermit the Frog ever realizing the love of Miss Piggy. When I was creating the security infrastructure for Charlie, I had to consider anonymous users. Should I implement the equivalent of ASP.NET 2.0’s Profile object, allowing Charlie to store information about anonymous users, just in case I ever found the need? No. That would be unnecessary complexity. When I was creating the ability for Charlie to host multiple websites from a single installation, I had to consider the possibility of “mini-sites”—a website within a website, like the child portals in DotNetNuke. Should I provide the infrastructure for child websites, just in case I ever found the need? No. That would be unnecessary complexity.

Second, simplicity comes from hiding necessary complexity. And what is necessary complexity? As much as I’d like to come up with an impressive-sounding definition, I think necessary complexity is anything that makes you groan and say, “Fuck, there’s no simpler way to solve this.” While this complexity is necessary, it can still be hidden away in the depths of the application. In my last weblog entry, I described how I was able to add security and globalization to Charlie by tweaking the deep-down Entity System. Here is the bulk of the Article business object before I added security or globalization to Charlie (and using fields rather than properties, just to keep the code sample simple):

public class Article : Entity
{
    public String Title;
    public String Summary;
    public String Content;
}

I then added the security infrastructure to Charlie, and here is how the Article business object had to be refined:

public class Article : Entity
{
    public String Title;
    public String Summary;
    public String Content;
}

I then added the globalization infrastructure to Charlie, and here is how the Article business object had to be refined:

public class Article : Entity
{
    public String Title;
    public String Summary;
    public String Content;
}

Unless my cut-and-paste skills are hobbled, you’ll see that the business object never changed. The hundreds of lines of code needed for security and globalization is necessary complexity, but it is hidden away in the base Entity System.

Sure, this is a simple application of fundamental object-oriented programming, but that is exactly my point. If you take the time to apply simple OOP concepts, the resulting base classes provide fertile soil for your application. From that soil solutions can emerge, which was the topic of the last weblog entry. Into that soil complexity can be buried, which is the topic of this weblog entry.

The lesson is when you discover necessary complexity, see if you can hide that complexity. Bury it in the soil of your application.

by Alister Jones | Next up: When the Student is Ready… →

0 comments

----

Lesson: Objects Allow Emergence, RAD Does Not

By RAD, I mean Rapid Application Development. And by that, I mean the drag-and-drop-and-think-no-more approach taken by many users of Visual Studio. Need a navigation bar for your website? Drag and drop an XML-based sitemap source onto your page, drag and drop a Menu control onto your page, bind the two together, and think no more about it.

By emergence, I mean the concept put forth by Andrew Hunt. An emergent property is one that grows out of a base that was not intended to provide that property. If you look at your backyard you will, I hope, see some lawn. The intention is that it provides a nice green patch that the kids can run on and, if they fall over, not hurt themselves. But if you drop in a seed, a flower will emerge. If you drop in an acorn, a whopping great tree will emerge. The flower and the tree were not intentional properties of the lawn, but they evolved because the lawn provided a fertile base. (This is my own interpretation of Andrew Hunt’s use of the term. If this analogy does not match what Andrew meant, then the error is all mine.)

Let’s return to the example of the XML-based sitemap source used by the RAD developer. This solution requires a SiteMapDataSource control in the Interface layer, a SiteMapNodeCollection in the Business layer, a SiteMapProvider in the Data Access layer, and an XML source file. So here is the solution:

Next up, the RAD developer needs a bit of localized text. .NET accommodates the developer by providing a ResourceManager that manages separate Resource files, each of which is drawn from satellite assemblies. Here is the solution:

Finally, the RAD developer needs to store some information about the current user of the website. .NET provides a Profile object, with its own Provider, and stores the information in a self-configured SQL 2005 database. Here is the solution:

Each of these is a forced solution, designed to support RAD developers. They are designed separately and differently, they are implemented separately and differently, and they are used separately and differently. Why does localization use a Manager when the others do not? Why does localization not use a Provider, when the others do? Why does one use an XML store, one use an assembly store, and one use a database store? And I have provided just three examples. Consider the variety of separate and different approaches across the full ASP.NET framework. (I’m sure there’s a tautology in that last sentence, but I don’t think any English lecturers read this blog.)

The point is that none of these solutions emerged naturally. They are each banged in place to support RAD developers, with no rhyme or rhythm connecting them.

When I designed the Entity System for Charlie, I did so only because I had read Expert C# Business Objects, and I kind of liked the idea of a few base classes on top of which I could create my business objects. In other words, I went to the effort of creating the Entity System just so that I could be lazy later, and do a minimum amount of work to create business objects. That was the sole motivation for the Entity System.

What is interesting, however, is that this Entity System allowed other solutions to emerge—solutions that the Entity System was not designed to provide. When it came time to globalize Charlie, I did not have to implement all the separate pieces shown above. Rather, I just added a Culture property to the base Entity class, added a Culture property to the base EntityCriteria class, and added a Culture parameter to the base EntityMapper class.

When it came time to provide security, I did not have to implement all of the separate pieces shown above. I simply gave the base Entity class a set of CreateRoles, RetrieveRoles, UpdateRoles, and DeleteRoles, and told the EntityManager class to check whether the current user was in the appropriate role collection.

Most recently, I had to implement a sitemap for Charlie. I looked into the sitemap system in ASP.NET version 2.0, and ended up thinking, “To hell with that.” I already had a DocumentCollection class based on the EntityCollection class. I simply created a new DocumentMap entity, and gave it a property that exposed a DocumentCollection. And with that, I was pretty much done.

Before you think that I am patting myself on the back, I’m not. The Entity System was a simple thing created so that I could be lazy. Yet because it was simple and flexible, solutions emerged from its fertile soil. No foresight on my part—the emergence of these solutions has surprised me.

The lesson for the day, then, is that a little bit of object-oriented design leads to a surprising amount of emergence. Feel free to ignore ASP.NET’s own complex solutions, and let simple solutions emerge from your own codebase.

by Alister Jones | Next up: Lesson: Show Simplicity, Hide Complexity →

0 comments

----

A New Day Dawns

I’m tempted to remove the previous weblog entry and pretend it never happened. But that would be a lie, and I do not want to lie. The truth is that I had become drowned in a sea of doubt. I had spent nights doubting whether I was doing the right thing with Charlie. I will explain my doubts, not to put my heart on my sleeve, but to put Charlie in its context.

It is well known that to create a good product, in any industry, you must do the right thing, and do the thing right. Sure enough, I had doubts about both aspects of Charlie. Was I doing the right thing? Was I doing the thing right?

First, was I doing the right thing? Why was I creating a new website framework? If I create a simple website framework, it will forever lag behind the likes of DotNetNuke, Community Server, WilsonWebPortal, and others. I have said before that I hate DotNetNuke, and that has not changed. But what about the others?

Community Server is created by some of the smartest cookies in the ASP.NET jar, and it has been used to create some truly impressive websites. I have the strongest sense that I should be using it and, to use a cliché, stand on the shoulders of giants. The problem with Community Server is that it failed my litmus test. Specifically, I could not understand its licensing, I could not find where to download it, and I could not understand whether I could extend it and, if so, how. My litmus test says that if a product is presented in such a way that I cannot shake its hand, then there’s little chance of me being able to work with it. Community Server has gone into the too-hard basket.

The Wilson WebPortal is a release I have been looking forward to ever since I hear a whisper of it. Paul Wilson is a guy for whom I have an enormous amount of respect. He is very smart, but softens his intellect with a healthy dose of modesty. He respects simplicity and eschews needless complexity—forgive the redundancy. And he is very open, providing heaps of source-code components for anyone who spends just $50 to subscribe to his website. That’s not a sales pitch, but if you look at what others charge for crappy .NET stuff, you appreciate Paul’s openness and willingness to share. The reason I am not keen on using Wilson Web Portal is that it is very ASP.NET 2.0-centric, and I have grave concerns about ASP.NET version 2.0, which I will address next.

But it seems that the current version of ASP.NET was created by Microsoft pinning ASP.NET version 1.1 to the wall, and inviting all its engineers to throw things at it. If any logic went into its design, the logic is opaque to me. If there’s any consistency in the new framework, that too is opaque to me. The poles of simplicity that supported ASP.NET version 1.1 have been broken under the weight of the gimmicks added to ASP.NET version 2.0. It is a bloated and unattractive thing.

Now it can be argued that if I don’t understand ASP.NET version 2.0, then maybe the problem is with me, and not with ASP.NET. Believe me, that is one of the things that has contributed to my doubts about Charlie. Maybe I am simply not smart enough to work with ASP.NET. Maybe Java Server Pages, or PHP, or Ruby on Rails, would be more agreeable to this dumb koala bear. But I do like ASP.NET version 1.1 very much, and I understand it quite well, so there seems to be no immediate gain to switching to another technology and facing the same bloody learning curve that I have just finished climbing.

Still, the fact is that I am simply not comfortable with the direction that ASP.NET is taking. I have been tempted to target Mono and not .NET. But that seems to be another example of Charlie Brown’s philosophy: the secret to life is to replace one worry with another. I am very tempted to look at Ruby on Rails, but that too seems to suffer the same philosophical argument.

Do I have a current resolution? Nope! So I’ll just move on to the second problem: am I doing the thing right?

This whole weblog has been following my attempts to do the thing right. Have I succeeded? I think so. I have so far met the main goals I set forth in my software specifications; namely that Charlie is simple, secure, globalized, and configurable. As the running software meets the initial software specifications, then it would seem that I am doing the thing right.

So there you have it. I think I am doing the thing right, but I don't know whether I am doing the right thing.

Does that largely explain the preceeding, and very negative, weblog entry? If so, I am going to carry on and finish telling you of the lessons I have learned so far. Then, I am going to tell you of the teacher who has come to my rescue and lifted me out of this sea of doubt.

by Alister Jones | Next up: Lesson: Objects Allow Emergence, RAD Does Not →

1 comments

----

Silently into the Night

by Alister Jones | Next up: A New Day Dawns →

0 comments

----

Lesson:
A Dummy’s Approach to Agile Development
(or, “If You Can’t Draw It, Don’t Code It”)

I have an admission that I must make. While I have criticised authors like Scott Ambler and Craig Larman for pushing Agile development so forcefully in their books, I must admit that they are on to something. The problem, in my opinion, is that these authors present Agile development in such a monstrously complex way that it would only make sense to someone who has already used that development process.

Let me provide an example. Please imagine that motorbike racer Valentino Rossi has thundered down a racetrack’s straight, and is about to turn into the first corner. From Valentino’s perspective, the corner goes to the right. Which way does he turn the handlebars on his bike in order to turn right?

Let’s ask a nerd. “The front wheel of a motorbike at speed is a gyroscope that will roll about the output axis in opposition to the input axis.” So there you have the right answer. However, that description only makes sense to someone who has already experienced turning a motorcycle travelling at speed. For anyone who has not had that experience, the description is meaningless.

Let’s ask a teacher the same question. “A motorbike at speed is carrying a lot of momentum and, once it is going fast in a straight line, it will be very difficult to change its direction. Still, let’s say that Arnold Schwarzenegger is riding the bike, and has the physical strength to overcome the bike’s resistence to turning. Now, let’s say that he turns the handlebars to the right in precisely the same way as if he were on a pushbike travelling at 5kph. If he were on a pushbike, he’d turn the handlebars to the right. But on a motorbike weighing 150kg and travelling at 150kph, the front wheel (20kg) of the bike would go momentarily to the right, while the rest of the bike (130kg plus rider) will continue travelling straight ahead. The bike would literally trip over its own front wheel, just as surely as if someone had stuck a pipe through its spokes. Because the front wheel has moved slightly to the right, the bike would fall onto its left side, and Arnold will be nursing bruises for two weeks. What this means is that if the motorbike’s handlebars are turned to the right, the bike will fall to its left. If the handlebars are turned abruptly (as you would do on a pushbike), this will result in a crash. But if the handlebars are turned gently to the right, the bike will start to fall away gently to the left. Now, if the center of gravity of the bike is slightly to the left of its wheels as a result of this gentle falling, then the centrifugal force will mean that the bike steers to the left. The bike is literally falling gently into the corner. Hence, when Valentino approaches that right-hand corner, he will be push the right handlebar gently forward, which will momentarily turn the front wheel to the left, which will result in the bike falling to its right, and falling into the right-hand corder."

Once you have broken the problem down into small pieces, take a piece of paper, and draw one square for each problem. Put each square anywhere on the page, it does not matter where. What that square represents is the class that solves that particular problem. This is a very simple relationship. For each little problem you have discovered, you will have one class that solves that problem.

Next up, give each square a name that looks a little bit like an American Indian name in Noun-Verb format. For this globalization example, names might be “TextSaver,” “TextGetter,” and “TextSorter.”

With a new sheet of paper, place the squares in some arrangement that shows which squares talk to which other squares. If one square needs to talk to another square, draw a line between those two squares. Work with this arrangement until you minimise the number of joining lines.

When you have arrived at an arrangement that looks good to you, consider how these different squares will talk to each other. Do they pass simple messages (“Give me the text for a SaveButton”) or do they pass complex messages (“For an authorized user that is in the Administrator role, give me each of the pages that he can edit”)? If the message is complex, draw a circle that will represent the passed message. Consider this to be like the ball that is passed between players in a game of sport. The ball will end up being another class in your application.

The idea is that you read a bit, draw a bit, read a bit more, draw a bit more, back and forth until you arrive at a diagram that feels “right”. It doesn’t even matter if the diagram is right or not. What matters is that it feels right to you, and that it provides a map of what you actually need to code. Did I really just say that it does not matter if the diagram is right or not? Yes. You see, there is no such thing as “perfect” code, so it’s pointless to strive for it. Without perfect code, there’s only two types of code: crap code and good code. This Dummy’s Approach is a way to ensure that ours is always good code, and never crap code. Unless you’re involved in launching rockets to the moon or controlling medical apparatus, then good code is good enough. The time it would take to move the good code to excellent code would be time better spent with your family or friends.

Once you have your final diagram, you can fire up your text editor or IDE and actually create the code for those classes.

Is this a long way to go about creating code? No! It is the short way. If you follow this process, then you will know precisely what classes you need, and what those classes must do—so you will code by knowing. If you do not follow this process, you must guess at the first class you need, then have a guess at the second class you might need, then have a guess at the third class you might need, then change the first class because it is wrong, then remove the second class because it is now useless, and so on—you will code by guessing. In the process of creating Charlie, I have used both approaches. I can tell you honestly that the components I first illustrated on paper are still in Charlie. The components where I just “had a go” have been ripped out of Charlie. I cannot overstate the importance of describing the problem, then researching and drawing, researching and drawing, back and forth, and then, only then, finally coding.

Is this really based on the Agile approach? Who cares! Let me just say that this approach has been the basis of everything that has gone right with Charlie. Research and draw. Research and draw. And if you can’t yet draw it, don’t yet code it. Research more and draw more. When you can draw it, then you can code it.

by Alister Jones | Next up: Silently into the Night →

1 comments

----

Lesson: Don’t Forget .NET

In an earlier weblog entry, I noted that I get frustrated by writers who discuss only the “how” of software programming, without discussing the associated “why” of software development. To redress this—if only in the little world of Charlie—I am trying to discuss why I have made certain design decisions, and the consequences and limitations of those decisions. Am I doing any better than the writers I have implicity criticised? I have no idea, since only one person responded to my request for feedback (God bless you, Garbin). Even so, I’ll persist with my efforts to talk about development from a slightly different perspective.

Well, another thing that frustrates me in reading about software development is the common feeling that, “Boy, I must be dumb.” I may read an article where a developer provides a little component, and then describes that component. If the article is written by a first-rate developer, the code looks so clean and so effective that I end up feeling a bit depressed—feeling sure that I’m simply not smart enough to ever write such good code.

The thought that gets me beyond such self-doubt is the image of a graceful duck. To a person standing on the shore of a pond, the duck appears to glide gracefully and effortlessly across the surface of the pond. What the observer does not see is that, below the surface, the duck is paddling like mad. It helps me to think that below the surface of code presented by a first-rate developer, the developer had to paddle like mad to arrive at that final code.

While I am not a first-rate developer, I’d still like to share some of the mad paddling that has gone into the development of Charlie. Specifically, I’d like to share some of the mistakes I made, and the lessons learned from those mistakes.

public abstract class Presenter
{
    public abstract ????? LoadModel(Int32 id);
    public abstract View GetView(ViewMode viewMode);
    public abstract Controller GetController(ViewMode viewMode);
}

public abstract class Entity
{
}

public abstract class EntityCollection : CollectionBase
{
}

The Entity class had no base class; it is a brand new class. The EntityCollection, on the other hand, derives from the existing CollectionBase class. What do these two classes share in common, such that the Presenter has a known type to work with? This had me scratching my head and ultimately putting pencil to paper. I thought about introducing a new Model class that contained one Entity and one EntityCollection, and the consuming Presenter would have to test which item was not null. I then thought about introducing an IModel interface, and force both the Entity and the EntityCollection classes to implement that interface. I then come up with other ideas too, but got so confused that I ended up taking a long ride on my motorbike:

The answer to this problem is embarrassingly obvious. However, I was so focused on Charlie that I had completely forgotten the reality that I was developing against the .NET Framework Class Library. While I was out riding the obvious answer became, well, obvious. I had clear forgotten that every single object in a .NET application derives from the base System.Object class. While it appeared that the Entity class and the EntityCollection class shared nothing in common, that was untrue. Both derive from the base Object class.

public abstract class Presenter
{
    public abstract Object LoadModel(Int32 id);
    public abstract View GetView(ViewMode viewMode);
    public abstract Controller GetController(ViewMode viewMode);
}

Having written the above description, I am very tempted not to publish this weblog entry. The fact that I had forgotten the base System.Object class is truly embarrassing. Who would ever trust a .NET developer that forgets this fundamental class? So, while I am deeply embarrassed by this gaffe, I did promise that this blog would be a true account of “the trials and errors of a self-taught developer creating his first web application.” So there you have it: the dumbest mistake I have made so far, and an example of this duck paddling madly beneath the surface.

by Alister Jones | Next up: A Dummy’s Approach to Agile Development →

0 comments

----

Recent Posts

• Russian Dolls and X-ray Specs
• A Bucket Full of Plugins
• Charlie’s Own Two Feet
• Implementing Raw Templating - Part 2
• Implementing Raw Templating - Part 1
• Recursion is not a Dirty Word
• The Raw Approach is Extensible
• The Raw Approach is Simple and Flexible
• A Raw Approach to Styling Webpages
• Olive, Teal, Peach, and Mauve

The Archives

• January 2006
• March 2006
• April 2006
• May 2006
• June 2006
• September 2006