Just a Thought...: Tag interface

Naked Objects, Point - Counterpoint

Berin Loritsch — Fri, 18 Dec 2009 14:27:00 +0000

The Pragmatic Programmer folks have a new book out called Domain-Driven Design Using Naked Objects which caught my attention. The title caught my attention, and I figured the author was using Naked Objects in the same vein as Jamie Oliver as “The Naked Chef” (old series on Food Network). Essentially, the ingredients are used to their full potential, complimenting each other without the heavy use of spice. So I decided to do some research on where this came from. My suspicions were confirmed, and made even more sense when I found the original thesis came from someone at Trinity College, Dublin.

I found the original thesis by Richard Pawson entitled Naked objects where he details the principles behind the concept. The thesis is very readable, as theses go. It is broken up into an introduction, a case study, guiding principles, etc. What I found more interesting was the forward written by the pioneer of the MVC pattern, Trygve Reenskaug. The concept of Naked Objects isn’t exactly new, and it should be lauded for its intent of getting back to the proper intent of object oriented design and programming. Of course, as a technology, and as some of the design constraints of naked objects, the thesis is not without detractors. For example a short paper by Larry Constantine called The Emperor Has No Clothes: Naked Objects Meet the Interface .

The true value in something like Naked Objects is to get you to adjust the way you are thinking. The main concept is to build the complete logic of the system using a finite set of domain objects. The framework is designed to take care of database persistence and user interface. According to the forward in the thesis, the spirit behind MVC is that each view is mapped to only one object, although each object might be mapped to many views. The controller is responsible for mapping the events of the view (inputs, etc.) to the domain model. Essentially the domain model (or model) uses views for output and controllers for input. This is different from the way it was originally described to me and I originally understood the pattern. Pawson argues that the framework can generate the user interface views and controllers automatically. Further advances in the concept also automatically maps the domain model to a relational database using Hibernate .

The software developer side of me likes this concept. It’s less plumbing to worry about. I don’t have to know how to code a user interface. I can get my work done quicker. However, the user interface design side of me loathes the concept because the user interface (admittedly by Pawson) is not easily grasped without training, nor is it particularly accessible. The architect in me is thinking about how I can have my cake and eat it too. Ignoring the problem of database mapping for a moment, the real challenge is in the view/controller (VC) layer. Pawson sites arguments from advocates of Object Oriented User Interface (OOUI) design that there is only one true correct way of representing an object. Yet turns around and presents two: an icon to represent the object and a dialog box to represent the content in the object. In my own project I am working on now, there are at least two representations of every object: the view in a list, and the view of the full content of the object. Nevertheless, there still remains concepts I can leverage.

In some respects Wicket would be an ideal candidate for dynamic generation of VC code. Or at the very least, due to its attempt to treat the view layer in an object oriented manner, some extensions to the application can dynamically generate the controller side. I have some reservations about pursuing that too far at the moment. The real conundrum is in the presentation layer. Managing information and behavior is something that object oriented languages are designed to handle. It is right and good to take advantage of the features of your language to properly model the business domain. However, representing that same information to the user in a way that makes sense to the user is a completely different discipline. I can argue against the principles in OOUI till I’m blue in the face, but that doesn’t solve the fundamental problem.

What we need is a way for the programmers to create the functionally complete object oriented domain model, while your user interface specialists concentrate on their responsibility. While frameworks such as Wicket have tried to address that very problem, it is my personal opinion that they fall a little short. I don’t think the fault lies with Wicket. The fault lies within the current set of W3C standards and differing levels of browser compliance. The W3C is still stuck on a model that prefers static information. If the W3C were to truly pursue a model where the user interface layer is bound to certain objects and the browser makes calls to the server to render these objects we might have a better solution. We’ve already started down this path with AJAX and the myriad of Javascript frameworks to make this work. Needless to say that there is a lot of future work that has to be done in order to truly see a synergy from functionally complete domain models and an object oriented user interfaces.

The goal of such an endeavor should be to allow user interface designers these freedoms:

Create the representations of the objects as they see fit
Create the rules of how to select the correct view from the different possibilities.

The controller logic should be built into the browser already, in terms of invoking the domain model (or representations of a remote object).

While I’m on the subject of Naked Objects and domain models, I’d like to make a minor rant on Object/Relational Mapping tools. One of the problems is that ORM tools tend to require accessor and mutator methods (getters and setters) for every field that is going to be persisted to the database. While you are technically encapsulating the internal state of the object, in 99.44% of the cases there is no difference in using the accessor and mutator methods and directly accessing the underlying attributes of the class. In a properly designed object, you only need to expose information via accessors that the user is allowed to see, and you only provide mutator methods for what the user is allowed to change. ORM tools require you to violate those principles if you want to persist the information down to the database. Some ORM tools (ActiveRecord) generates these accessors and mutators dynamically for you. That’s great for convenience, but terrible for a properly designed domain model. For the time being, there really is no alternative unless you write the ORM layer yourself. Not recommended if you can help it.

Designing an Interface for Large Datasets

bloritsch — Fri, 11 May 2007 13:31:00 +0000

In the past we had to worry about how to deal with the data we had, but it was a manageable task. You could do it with a small, personal database, and manage your collection of movies and CDs. Now, we have so much stuff, and thanks to the internet, access to so much information we have a different kind of problem. Now that we have the information from just about every kind of source, how do we separate the wheat from the chaff? How do we find what we need at the time. There are all kinds of theories for how best to deal with it which range in usefulness.

If you are to listen to Google, all you need are powerful search algorithms and you can always find what you want. If you are to listen to some Web 2.0 proponents, all you need are tags and RSS feeds. The real answer is more complex than that. The best tool for the job depends on what you need to do with the data. I think that the social web has made possible some really fun uses of information. If you are in a blue mood, you can look at pictures or listen to music tagged with “blue“ and you are all set. What happens when you need to research political environments and collect certain kinds of information? The problem is finding the so called “more serious” data. Depending on the type of data you have, you can learn from other sites that deal with large amounts of data. The trick is taking something that someone else did and applying it to your project in a meaningful way.

Don‘t get me wrong, RSS feeds are an invaluable tool and they are being used in some very interesting ways. Additionally, the folksonomy tags of the Web 2.0 world is a very useful way to mark data that is meaningful to the user. Flickr’s technique of normalizing the tags is also very useful to bring together similar data (in this case pictures) that is related. Google probably has the best search tool in the world, but after all that, each one on their own is just a small piece of the puzzle. Don’t forget that with really large sets of data, you also have to figure out what the best way is to find the exact information you need. Sometimes you need something like blogs to provide some commentary to bring out the significance of what you are seeing. The trick is tying everything together. Things like Del.ico.us help, but at the end of the day is only so useful for the casual user.

You have to know your users, and how they plan to use your information. If you have a site that organizes communications, you need to know if you have users that use that communication for business intelligence, or if it is just faster than the normal communication system. If your experience is anything like mine, you learn from emerging patterns of how your users use the application. Getting feedback from the user community is the key to see if you are on the right track. The question is how do you get meaningful feedback?

You‘ve got some options. You can have someone who goes out and talks to the users, training them and listening to how they use the system in new and inventive ways. The advantage of this approach is that you get high quality feedback that has already been distilled into something you can make sense from. The obvious disadvantage is the cost of paying for this kind of resource. You can offer a feedback link, which will usually give you a bunch of disgruntled responses. You can offer a testimonial link, which will give you glowing reports for the people who take the time to write in. The disadvantage being that you are at the mercy of whoever decides to take the time to send you the feedback. Of course, you can always examine the raw usage patterns by storing the details of a user‘s session to the database. However, unless you have a way of making sense of what the person is doing, you are missing out on some critical bits of understanding. Someone may be doing something for a perfectly valid reason, or they may be doing it because they really don‘t know a better way of doing it.

Over a period of time you get to know your users, and you can anticipate their needs to a certain degree. It‘s actually a fun place to be in. When you get to that place, you are engineering the social economy of your site. You are are guiding your users by opportunity, rather than coercion. It‘s the place where your users think “these guys really kick butt!“ It‘s never about you, but what you enable.

As to the bits and snatches of approaches I‘ve found useful, I pull a lot from Flickr. I like the way they do tags, and I like the way they do pagination. It makes sense for our users. Although I also pulled Ebay style sorting, and del.ico.us style tag clouds. The browsing was an evolution of something unique to our system. It helps by limiting the user‘s set of information they have to look at by dividing the information along geographic or political lines — not to mention the defined set of TAGs that have been in place for decades. The search feature is also an evolution. We had an “advanced search” page, that let someone find messages by reference number, tag, or searching just the subject line, as well as limiting the dates. Now we just have a drop down box to ask if the user wants to search those things directly. There really wasn‘t a need for a separate page altogether. Another evolution was that any scope a user can navigate to, they can subscribe to an RSS feed that just gives them anything that fits that profile. I‘m pretty pleased with where the system is evolving. There‘s some newer and more exciting evolutions coming out, but that‘s a secret — shhhh….

Why I Hate Writing Microsoft Programs

bloritsch — Wed, 21 Feb 2007 18:11:00 +0000

First off, I don‘t dislike Microsoft for religious reasons or claim that the only true software is open source. I dislike Microsoft because they have made my life difficult on many occasions when it could have been easy. The one area where Microsoft is the most painful to use is when you write software. The first problem is the horrendous API documentation and how to articles. Before I provide anechdotal evidence, let me provide something to contrast against.

As a Java developer, there are a couple things I have come to appreciate about the Java‘s contributions to the world. The first is the first rate JavaDoc tool. If Sun did nothing else right, they spent the right amount of time to flesh out the JavaDocs for the core API, and even provided links to tutorials to help you understand how things are supposed to work together. Second, the Java community as a whole has contributed excellent articles on how to solve different problems with Java. I‘d love to see another community surrounding a language match the level of quality of the articles. As a result of all these rich resources, developing Java programs is far less of a pain than any language supported by Microsoft.

As a Visual C++ developer, there are a couple of things that I have come to loath about Microsoft‘s contributions to the world. The first is the abysmal API documentation, which has gotten worse with the advent of the .NET framework. The descriptions are barely useable and there is no clear idea of how to use some of the parts of the API. It might be forgivable if the remainder of the Microsoft community (including magazines and such) picked up the slack, but rarely can you find what you need and everyone wants money. You can‘t even evaluate if the magazine will be good for you without spending money on it. The second is the lagging IDE technology. Things that I take for granted in any Java IDE like refactoring tools are not to be found in Visual Studio (unless you pay for a third party plugin or a new version finally includes limited support for it). You can‘t really build anything without the IDE, but it is a pain when you do something as simple as rename a method to clean up the class signature.

One of the first events that really helped me to dislike programming Microsoft programs was when I had an assignment to add features to the print dialog. I searched the IDE help for how to do this, and all I could find was that it was “possible” but that was it. I had a coworker look through his several hundred dollar thick reference guides and they gave the same answer as the online help. I searched the internet and came up with the same answer. Eventually, I ended up just creating a new dialog box with just the controlls I needed and secretly controlled the printer settings behind the scenes. The printer settings are set by the dialog box which is required by Microsoft to exist — but you can instantiate it without making it visible. After I created the custom print dialog with just the controls we needed I finally found the answer I originally needed, sort of. It turns out you need to copy the Print Dialog resource descriptor from the API source code included with Visual Studio into your project and manually edit it with a text editor to add the controls you need. There were no instructions on how to edit the resource file, but at least there was some description of the process. Events like this repeated themselves ad nauseum .

Another event that solidified the fact that I didn‘t want to do .NET programming and spend time learning C# had to do with a copy of Visual Studio 2003 given to me by my company. Despite the fact that this IDE is supposed to be Microsoft‘s cutting edge offering, they didn‘t learn a thing from the success of Java. Java‘s success has nothing to do with the language! It has everything to do with the community surrounding it, and the attention vendors pay to making our lives easier. Visual Studio 2003 had zero refactoring tools. None, zilch, nada. The open source community did help in some respects by providing NANT and NUnit, but no refactoring plugins. Eventually JetBrains created one, and perhaps Microsoft has licensed it for the next version of Visual Studio. I asked the Microsoft rep about it the response was, “No, it doesn‘t have anything like that… but don‘t you think that being able to display a screen on the desktop or on the web with the same code is a useful thing?” I couldn‘t believe it. How many people do that? You either develop for the web or you develop for the desktop. Worse, despite the cool factor that might have, it doesn‘t make my life easier for what I do each and every day. Refactoring tools are useful even when there is no UI and you are writing a library.

There are some very clever things that Microsoft has done, but they are lost in a sea of irrelevant features and horrendous documentation. The documentation problem is made worse by the community of money grubbing publications filled with articles that are no better than what Microsoft provides. Will things get better? Not if they continue to stick their heads in the sand when truly useful innovations come around. Is Java the bees knees? No, but it is a useful tool if only for the fact that you can find a real solution somewhere on the web without having to shell out money just to look at it. For the record, I‘d really like someone to implement something as elegant as Microsoft‘s web service solution in Java. Of course, you lose that very elegance if you don‘t use the overpriced and underpowerd Visual Studio….