Monthly Archives: September 2013

Sorry, the lawyer ate my user experience

I occasionally use for finding and buying images to use in my presentations. They have a nice, user-friendly interface for selecting images. There is a good keyword search, the option to search by color, orientation and even available space for your own text. So far, so good.

But once you come to the actual purchasing, the lawyers killed the usability. When I have selected 7 images I want to download, I want to be presented with a page with links where I can ask my download manager to pull down my images. Instead, I have to click through the “Terms of use” dialog every time.

User Experience is about the total experience – not just the shop window and the catalog. Back to the drawing board, iStockphoto.

When strong incentives meet weak oversight

Team Oracle was just caught cheating in the America’s Cup.They’ve been penalized some money (but Larry won’t notice), but also won’t get points for the first two races they win. And they’ve lost some expelled crew members.

The CEO basically said: “It was just some crew members and we didn’t know they did it”. This kind of inappropriate behavior is what happens when incentives are very strong, but oversight is weak.

The same situation of strong incentives and weak leadership can be seen in the Oracle Sales organization. Some people will rather force superfluous licenses down a customer’s throat or perform questionable license audits than listen to what the customer needs. This kind of behavior will only work for a limited period of time and is one reason Oracle’s famously aggressive sales force is now having a hard time meeting its numbers.

ADF Architecture Made Simple: Small, Medium, Large

There are lots of ways of building ADF applications, so there is a very large number of possible architectures. I’ve found that three good architectures are:

  • Simple
  • Modular
  • Enterprise

In a simple architecture, you build the entire application in one workspace. Business components go into a model project in the workspace, and task flows and pages go into a view/controller project. This approach works well for small applications that will be built by one or two developers.

If your application is larger than 5-10 bounded task flows and/or more than two people need to work on it, a modular architecture is a good approach. In this approach, you place common elements (templates, visual identity, entity objects and view objects for value lists) in a common application workspace and then use the output of that workspace in a number of subsystem workspaces. The subsystems then each contain a specific subset of the total application functionality (view objects, task flows and page fragments), and all the subsystems are collected into one Master application workspace.

ADF Modular Architecture

If your organization is going to be building many ADF applications, it makes sense to extend the modular architecture to the enterprise architecture. In this approach, you keep enterprise common objects (base-level templates, visual identity, possibly entity objects and view objects for global entities) in an enterprise common workspace and then use the output from this workspace in a number of application common workspaces. These application common workspaces add features that are specific to each application (entity objects and value lists specific to the application). Each application is then built like in the modular architecture with a number of subsystems that are collected into one or more master application workspaces.

ADF Enterprise Architecture

Note that the enterprise architecture allows you to build several master applications and even use the same subsystem in two different applications.