What's the purpose of the new iPad from Apple?

Posted by Berin Loritsch Thu, 04 Feb 2010 00:08:00 GMT

No new technology has stirred up consternation like Apple’s new iPad introduced last month since the release of the iPhone. Apple purports that there is a market for something in between a laptop and an iPhone/iTouch. I agree with them on that point; however, the market may or may not jump on the iPad. Time will tell, of course.

In the keynote, Apple compares the iPad to something called a “NetBook”. NetBooks users can be divided into two major camps: people who want a cheap way to do Windows, and people who just want to browse the web and check email. The current NetBook market has offerings with Windows and Linux. They are tiny, have cramped keyboards, and really aren’t that remarkable. The iPad would be a great alternative for folks who don’t care about Windows. But I don’t think that’s the market, really.

Amazon has this thing called a Kindle, and Barnes and Noble has their version of a competing product. The Kindle is pretty cool, it is designed to make reading electronic books an enjoyable pastime. I see commuters with Kindles all the time. The Barnes and Noble device is a direct competitor, and because it doesn’t do a whole lot more, they will have a hard time taking over the Kindle. The good points about the Kindle include battery life an Apple device can only dream of, and a display that is easy on the eyes. I noticed Apple’s new book store app with books you can download. I think Apple is aiming for this market with a vengeance—doing for books what they did to the music industry.

The kindle uses something called “liquid paper” which consumes very little energy and is very easy on the eyes. It’s not backlit, and has a similar contrast to what you get with a regular paper book. The liquid paper only consumes energy when the screen has to change. The downside? Only 16 shades of gray. We haven’t had limitations like that since the Commodore 64. However, for reading it is a superior technology. Because of it, the Kindle can hold a charge for more than a week with normal use. That beats iPad’s 10 hour limit handedly. The very thing that makes viewing pictures and watching movies great on the iPad is what makes reading books for extended periods of time a strain on the eyes. The contrast is too great for comfortable reading.

That said, the iPad’s market is bigger than just replacing the Kindle. Think about a commuter. They hop on a bus, run to a train, and take more than an hour to get to work. Many commuters keep themselves entertained watching movies, playing games, texting, reading, studying, and sleeping. Often times on the train you are lucky if you can sit down. A laptop is just a non-starter in this arena. Smart phones, iPods/iTouches, Kindles, newspapers, and physical books rain supreme. They have an advantage that they can be held with one hand while people are staring at them. The other hand comes in to play if the user is texting or interacting with an app. I think the iPad will work very well in this market.

People need something unobtrusive to take notes with, yet is natural and intuitive to use. Even better would be the ability to have your reference material (Bible, text books, etc.) open so you can reference parts of it in your notes. It’s a matter of time before there’s a really good note taking app for that. The casual internet user will prefer to have something like the iPad than a desktop or laptop hooked up in a room. If you have FiOS, they give you a wireless router in the package. Why not have a couple devices that make good use of it?

Consider going to a meeting where you are presenting. Now, if your iPad has your slide deck you can really limit the amount of cruft you have to take with you. With the right adapter, you can display the slides on a projector or large screen. However, if you forget the connector and you have a small number of people you are briefing, you still have a big enough display to work with. You can at least see your notes while you are presenting.

There’s going to be a lot more uses for this thing that have yet to be imagined. The exciting thing is that Apple has thrown down the gauntlet and created a new platform… again. What people choose to do with it has yet to be seen. The early adopters will be the commuters, and their enthusiasm will infect others.

Apple does consumer devices like this very well. Sure it lacks the ability to run multiple applications at once. It’s not designed for that to begin with. It’s designed for the user who is going to do one thing at a time. Did you notice that the iPhone/iTouch/iPad doesn’t have a window based UI? Each app takes up the full screen. You are supposed to do only one task at a time.

Am I going to buy one when it comes out in March? Maybe not. I’m going to stick with my iTouch until the iPad starts to really define its market.

Naked Objects, Point - Counterpoint 2

Posted by Berin Loritsch Fri, 18 Dec 2009 14:27:00 GMT

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.

Wicket Impressions 1

Posted by Berin Loritsch Fri, 04 Dec 2009 14:02:00 GMT

I chose Wicket for this project, partly because I met some people who were very enthusiastic about the framework, and partly because I wanted something that was easily tested. My client requires a Java solution, so Ruby on Rails was out. I did a quick little shoot out between three Java framework options, and Wicket passed the first impression stage.

Now I’ve got a couple of iterations of software development with it under my belt and I’m starting to feel a bit more comfortable with the framework. As far as Java web frameworks go, its pretty good, but… I would do things a bit differently. The application is written in a style that would actually better fit Ruby, SmallTalk, Lisp, or some language that supported passing in procedures or lambdas (as the language gurus call them) natively. Take for instance the Link class. In order to do anything useful, you need to subclass and implement the onClick callback method—even if all you want is to go to another page. Here is an example:

add(new Link("wicketId") {
    @Override
    public void onClick() {
        // do fancy logic
        setResponsePage(new IncidentPage(incident));
    }
});

If this were Ruby the code would look like something like this:

self << Link.new("wicketId") do 
    // do fancy logic
    respond_with(IncidentPage.new(incident)
end

So am I complaining about semantics? Possibly. However, there are more “Java” ways of accomplishing the same class—particularly if you want to manage all business logic in a few classes. The more “Java” way would be something like using the java.lang.Runnable interface. That would allow you to set up an enum to include all your business logic like this:

enum IncidentLogic implements Runnable {
    EDIT {
        @Override
        public Page run() {
            // do fancy logic
            return new IncidentPage(incident);
        }
    }
}

and it would be used in your page like this:

add(new Link("wicketId", IncidentLogic.EDIT));

I’ve also experimented with using a dynamic proxy to bind any method to an interface. That would let you set up a logic utility class and reference it like this:

add(new Link("wicketId", Linker.link(IncidentUtility.class, "edit"));

It’s not as pretty but it works. Now here’s the nice thing about Wicket. If I feel strongly enough about it, I can create my own subclass of the Link object to implement that approach myself. My DynamicLink would look something like this:

public class DynamicLink extends Link {
    public static interface Executable {
        Page do();
    }

    private final DynamicLink.Executable click;

    public DynamicLink(String wicketId, DynamicLink.Executable action) {
        super(wicketId);
        this.click = action;
    }

    @Override
    public void onClick() {
        setResponsePage(click.do());
    }
}

In fact, I think I may just do that. It’s better than having bits and pieces of behavior spread throughout the Pages and panels defined in the application. I think I find it a bit frustrating when i need to do things like that just to format dates the way I want. Why can’t the provided DateFormatter let you set the pattern you wanted to use? Why do I have to subclass the one in Wicket just to get that feature?

At the end of the day, my complaints are minor and the Wicket community is helpful. I’m fine with that. The Wicket framework is probably one of the leaders in providing a test harness that can be used easily in your JUnit tests. That is a much bigger selling point to me.

Wicket, Spring, Hibernate, Testing... Yeah, it's like that.

Posted by Berin Loritsch Tue, 10 Nov 2009 16:57:00 GMT

I have to deliver a product using Java. Due to politics and approved baselines, etc. I can’t use Ruby on Rails. I’ve done my own thing in the past, and so this time I decided to save some time by incorporating Wicket, Spring, and Hibernate using auto-wiring, and attributes. Getting it all to talk together took the better part of a day, but I got it to deploy and run fine.

I’m an avid unit tester, so I was happy to learn that Wicket has some facilities to make testing a bit easier without forcing you to create your own Servlet mock objects. I was really happy about that, so I decided to try it out. Unfortunately, I ran into a rather nasty roadblock. Spring was complaining about the ContextLoaderListener not being loaded. It’s defined in my web.xml file, but the autowiring requires the spring context to be loaded in a particular location. Finding out how to fix that problem took me the better part of half a day.

The problem is that Wicket hides the ServletContext object away from you. You can’t add values, because the test framework is initialized on construction. Attempts to obtain the ServletContext and manually add the Spring web application context just weren’t working. That’s because it is configured when the WicketTester object is constructed and ignored after that. I needed to be able to inject my own ServletContext with the Spring integration taken care of. I finally figured it out here, because the forums just working for me. Please note that this is tested with Wicket 1.4 and not any of the earlier versions:

final MyApplication app = new MyApplication();
tester = new WicketTester(app) {
    @Override
    public ServletContext newServletContext(final String path) {
        // web context
        ServletContext context = new MockServletContext(app, path);
        // spring context
        XmlWebApplicationContext spring = new XmlWebApplicationContext();
        spring.setServletContext(context);
        // configure spring
        spring.setConfigLocation("classpath:application.xml");

        // put spring where Wicket can find it
        context.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, spring);
        return context;
    }
};

So let me explain what I did. I created an anonymous subclass of the WicketTester class so I could override the factory method “newServletContext” to inject my spring configuration. Done properly, the wicket folks can take care of this by providing a SpringWicketTester subclass in their spring integration library. The SpringWicketTester would let you specify the location of your Spring configuration file, and it would override that method for you. For now, you’ll have to do it yourself.

I put the WicketTester initialization in a subclass of the JUnit TestCase class. That way I don’t have to repeat myself for setting up my Wicket testing.

Ruby IDEs Come of Age 2

Posted by Berin Loritsch Fri, 16 Oct 2009 02:07:00 GMT

Aptana logo
RubyMine 2.0
There’s nothing better than finding that sweet spot with developing your software where your tools work with you, and all is right with the world. With Java that started when JetBrains introduced their IntelliJ IDEA product. That product changed the way we think about integrated development environments, and even the open source alternatives like Eclipse imitated the features included in the IDEA product. At some point they specialized differently, each with their own set of pros and cons.

The Ruby development environment lagged seriously behind with people content to use glorified text editors.

Ruby on Rails brought a whole new community of developers to the Ruby platform, many who were curious malcontents from the Java arena like me. For folks who were used to the IDE integrating with your version control system, and even your issue tracking system, going back to text editors alone wasn’t going to cut it. Yet, so strong was the pull from Rails that some enterprising folks started creating a Ruby IDE: RadRails. RadRails is now a plugin for the Aptana web development platform, and Eclipse based tool. Aptana was my IDE of choice for quite a while. Since I was already used to Eclipse, and I had a set of plugins that I already enjoyed using, there really wasn’t much reason to switch. Except for this nagging feeling things could be better. I was still sorely missing refactorings, decent intentions, and working type-ahead for the Ruby API. Sure I was aware of the technical limitations, but I knew it could be done.

I limped along until I noticed that the Ruby Language had made Ruby 1.9.1 the new official Ruby. It had Rake and RubyGems as standard components, so there will be no issues with the stinking Linux distros that refuse to make an RPM for RubyGems. It’s all included. Of course, there are still some growing pains with some gems. Check out Is it Ruby 1.9 for details (they have a sister site for JRuby in case you are interested). I had an upgrade project ahead of me that required some features from Ruby 2.3.x, cleaning up, and security enhancements. Since I had to re-implement the site anyway, Ruby 1.9 was measured to execute faster, and I had the liberty of doing so, I decided to make Ruby 1.9.1p243 the new baseline.

That’s where my troubles began. It wasn’t just the Gems either. The IDEs just couldn’t handle it. They turned into glorified text editors with the ability to track commits. The debug feature was broken.

I remembered the Zen like experience that I had with JetBrains IDEA from the Java world, and knew they also had a product for .NET. I hoped they had a product for Ruby, and sure enough they have the RubyMine product. If you are looking at Ruby 1.9, or Rails 2.3.3+ don’t look at RubyMine 1.1.1. Look at their new RubyMine 2.0-beta. This is what Ruby programming should be. The price point is currently $79 USD with the current promotion, but normally it is $99. That puts it in the range that mere mortals like me can afford. It works quite nicely with Ruby 1.9, and even Rails 2.3.4 (although that wasn’t the version they developed against). I have my refactorings, my intentions, my effortless subversion integration. Formatting works. It’s fast. Type-ahead doesn’t flake out. Debug works (made possible with coordinated efforts between myself, the debug-ruby-ide gem maintainer and the JetBrains team—the latter two doing the heavy lifting). Let me tell you, JetBrains is as good and responsive as they always were, and the Ruby community is like the Java community used to be, but better and more pragmatic.

Aptana and RadRails will catch up, it’s a matter of time. However, JetBrains RubyMine works now, and it works better and faster than Aptana. On Windows, RubyMine performance is acceptable (on par with Eclipse), but on Mac it sings. Eclipse/Aptana’s performance doesn’t change no matter what platform you are on.

While I’m at it, I do have a major gripe with the Eclipse baseline. As a developer, I have a list of plugins I depend on because those features don’t come out of the box with Eclipse. However, the Eclipse developers who are ever moving forward, break the plugin API and the plugins I need to use. I can’t download a version of Eclipse and expect it to work properly. Then, if I have to hunt around for an older version, God help me. At least Aptana goes through great efforts to provide a stable and usable baseline. OK Eclipse, how is it that you provide an IDE for developing enterprise applications, and you don’t bundle the plugins for Subversion, CVS, and GIT? If Aptana can do it, why can’t you? It’s unthinkable that a responsible developer will touch code without the safety net of a version control system. Give them tools out of the box so they don’t have to separately install these plugins. Support the open source projects around you, so open source version control systems should have preferred status. And don’t release a version of Eclipse until you’ve got those plugins working with it. Really. I mean it. It helps you out in the long run.

Web Accessibility

Posted by Berin Loritsch Tue, 04 Aug 2009 15:08:00 GMT

I’ve been spending a lot of time looking into accessibility for web sites to finally get a grip on what needs to be done. Sadly, it is overlooked by the big guys when it doesn’t really have to be so hard. There are several types of disabilities including:

  • Visual (full, partial, or color blindness; Photo-Epileptic Seizure [PES] susceptibility)
  • Motor control (full or partial disabilities preventing the use of a mouse)
  • Cognitive disorders (dyslexia and the like)
  • Auditory (full or partial deafness)

The main issue with accessibility is the lack of knowledge and reasonable resources available to help. In particular, the tools that are needed to support people who have the disabilities are expensive and complicated. There are tools available that everyone can have at their fingertips that will help. Most are Firefox plugins, some require you to use an external site. Below are a few of the resources I’ve found:

The folks at WebAIM have several good recommendations. For example, you know those “edit in place” controls on Flickr? You can make them keyboard accessible by applying the attribute “taborder=’0’”. The control will be in the page’s natural tab order. I did a little experimentation and the control supplied by Script.aculo.us can take care of all these things for you. The only issue is that IE 6 won’t put the control in the tab order unless it is in the original markup. Dynamically changing the DOM to put it in won’t put the control in the tab order with that browser.

Web Design 101 1

Posted by Berin Loritsch Fri, 17 Jul 2009 19:25:00 GMT

This is a departure from the film and darkroom printing posts, so apologies and I’ll be back on that later.

I’d like to think I’m a pretty good application designer, although some of the things that I’ve seen on other sites have left me a bit jealous. Face it, I didn’t have a background in web design. I know what I should be able to do, and what it ends up looking like. The problem is familiar to anyone who has designed for the web: IE and non-standard implementations of HTML, JavaScript, CSS, etc. The way it’s supposed to work is you whip open the standards, see what CSS can do for your style, and do it. When you see impressive use of CSS from the CSS Zen Garden you start thinking, why can’t I do that?

I come from an application development background, where we can design our desktop apps with nice grid based layouts and do all kinds of fancy things. From there I went on to web development, and have always been frustrated with my inability to escape using tables for layout. Tables are great for lining things up, but they can cause their own issues when you start incorporating AJAX and other goodies. Then you have to worry about what your client’s browsers can do and what they can’t do. At least I don’t have to worry about Netscape 4 and it’s 30 second lag time to sort out nested tables anymore.

So, I think I’ve solved the worst of my problems. I solved the nonstandard JavaScript implementation problem by using Prototype.js which really made it easy to take care of AJAX support for tags and made some of my complex form handling easier. I was still doing my own JavaScript implementations of type-ahead controls and the like. Then I discovered Scriptaculous which took the pain out of 90% of the more advanced control issues I had.

But what could be done between the presentation hell that Internet Explorer puts me through compared to other browsers on the market? IE positioned things just a bit off, and handled the positioning of divs a little crazy as well. If I was going to both have a nice visual grid layout and use markup the way it was intended, I needed a solution like prototype and scriptaculous to help me out. Enter Blueprint CSS to take away the pain and suffering of using divs to align your content. Now blueprint provides some nice little “plugins” that use CSS to do pretty buttons or decorate links with graphic icons all with pure CSS. The graphic icons degrade gracefully as IE 6 does not support the type of selectors it uses. However, the library included a couple PNGs with transparencies. So what does one do about the fact that IE 6 does not render that nicely? Fix it up with Unit PNG Fix of course.

Now my header looks like this:

    <head>
        <title>My Site</title>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
        <link rel="stylesheet" href="css/screen.css" type="text/css" media="screen, projection">
        <link rel="stylesheet" href="css/print.css" type="text/css" media="print">
        <!-- Fix nonstandard IE spacing -->
        <!--[if lt IE 8]><link rel="stylesheet" href="css/ie.css" type="text/css" media="screen, projection"><![endif]-->

        <!-- Site CSS -->
        <link type="text/css" href="css/mysite.css" rel="stylesheet"/>

        <!-- Fix IE6 PNG transparency issues -->
        <!--[if lte IE 6]><script type="text/javascript" src="lib/unitpngfix.js"></script><![endif]-->

        <!-- Prototype.js/Script.aculo.us  -->
        <script type="text/javascript" src="lib/prototype/prototype.js"></script>
        <script type="text/javascript" src="lib/scriptaculous/scriptaculous.js"></script>
    </head>

It seems like a lot, but it makes my life so much easier. I highly recommend Head First Web Design as it covers all these wonderful concepts and more.

Print a Month Project

Posted by Berin Loritsch Fri, 26 Jun 2009 12:44:00 GMT

Starting in July, I’m starting a new project to help sharpen my skills and maintain a consistent production. The basic principles are as follows:

  • Every month I take a new picture
  • That picture is then manipulated and prepared to the best of my ability
  • The final result is a matted print

The goals are to fine tune my process, try new techniques, and increase my proficiency. The reason for dealing with a print is is for the work to reach its full potential.

Why every month, and not every week or every day? Mainly because I want to have an attainable goal. Something that is reasonable for me to do, yet will push me. Due to my schedule between work and church, I have far less time than I really want in the darkroom. I’m trying to make better use of my time in the darkroom. Additionally, the goal of one print a month allows me to really dig deep into a print and experiment with ways to make it better through dodging, burning, toning, or more creative approaches.

"Beyond" the Zone System

Posted by Berin Loritsch Mon, 22 Jun 2009 12:14:00 GMT

In the process of trying to coerce a working system in my darkroom, I purchased the book “Beyond the Zone System” because I know it has a lot to help understand sensitometry. What appeals to me is the ability to both test the speed of your film and the development time within 6 sheets. Since Ansel Adam’s film speed test takes seven sheets and an unknown amount of sheets for the dev test (at least one but in practice a few more), I’m all about conserving resources. The cost of the sheet of film is only one part of the cost—it’s the investment in time that I’m most concerned about.

BTZS starts out with a nice little overview of how paper and film work together to make the finished image. It also has a review of all the types of math and graphing theory that pertains to this testing process. The math’s not that hard, but the problem is in the way it’s presented. You can tell the author has a wealth of information, and he tries to make it accessible all in one or two chapters, but you almost end in confusion.

Where my head really starts swimming is when he gets in to calculating film speed. With Ansel Adams, it’s simply a density of 0.1 over film base+fog. The author covers the history and the pros and cons of how film speed was calculated over time, instead of just choosing one and teach how to do that one. It’s useful information, but the alternatives could be moved to an appendix to make that section more accessible.

With a proper handle of the basics of how the film and paper relate to each other, you can intelligently make decisions on exposure, development, and printing decisions. The road to understanding taken in the BTZS approach is very technical, which is not for the feint of heart. However, once you’ve learned the basics, you learn useful bits of information. For example, changing development times is similar to changing apertures—they both follow the same geometric progression of numbers (4, 5.6, 8, 11, 16…) to produce the same changes in final density. Shutter speed times and film speed numbers follow the same progression of numbers.

If you are serious about understanding more about how your materials work and respond to light, this book is definitely something you should have in your library. It will take time to “get it”, but once you do it will help you with your final results. You have a better understanding of why you choose a particular density for your print materials. You also have a better understanding of how zones don’t equal stops of exposure—yet the two still relate predictably.

Confronted with Concept Art

Posted by Berin Loritsch Tue, 16 Jun 2009 12:35:00 GMT

I’ve been going through Jeff Curto’s History of Photography podcast which has been very good and educational. Not surprising since this is Mr. Curto’s lectures from the class he teaches at the College of DuPage. I did get out of it what I wanted, which was exposure to history’s famous photographers. However, there is one thing I can’t wrap my head around; which is not Mr. Curto’s fault. It’s this whole thing with concept art. The music world has an equivalent called “performance art”. I don’t think it’s so much that I don’t get it, but more that I don’t want to get it.

To me, concept art or performance art is what happens when your left brain attempts to do the job that belongs to the right brain. In essence you as the viewer or artist are supposed to thrust your own intellectual ideas on the object of art rather than allow the art to speak for itself. In essence, it seems to me like the mental masturbations of someone pretending to be an artist telling the world that this boring or non-existent thing is art. For example, someone sits at a piano for 30 seconds in an outdoor setting, closes the piano and takes a bow. Someone erases another person’s painting and calls it art. It takes no skill to do these things. You are supposed to contemplate the ingenious mastery of perception or some other such nonsense.

Sure I come to art with a preconceived notion that art is supposed to be beautiful. I can get abstract art. Art is always introduced by folks like Michelangelo, DaVinci, etc. We then learn about impressionism such as the wonderful works of art by a Claude Monet. I can even get Picasso. So when I see photographic art in the same style I can wrap my head around it. I can understand it. I can see the beauty in the subject, even if I may not particularly enjoy the subject.

What I don’t get is how something that looks amateurish is supposed to be a modern interpretation of art. It almost seems to me as if the art community has become so inbred on its own philosophies and community that it has lost touch with the world. The people who buy these pieces of “art” don’t do it because they enjoy what it looks like, but rather because they look at it as an investment. I have to wonder if the concept art will truly be remembered a hundred years from now?

Do I consider myself an artist? Hardly. Sure I am pursuing photographic art, but I don’t count myself to arrived. In many ways, I want the art to challenge me and impress me. Not to challenge my understanding, but to challenge my skill and knowing what is possible with the medium. I’m forced to deal with left brain functions all day with my job, when I view art I want to exercise the other half of my brain. Concept art (and in the same vein performance art) fails to challenge me or impress me. My daughter created better work when she was nine.

Older posts: 1 2 3 ... 11