I occasionally use www.istockphoto.com 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.
User Experience is about the total experience – not just the shop window and the catalog. Back to the drawing board, iStockphoto.
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. http://www.sail-world.com/USA/Americas-Cup:-Cheating-doesnt-pay-but-cheats-do/114036
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.
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:
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.
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.
Note that the enterprise architecture allows you to build several master applications and even use the same subsystem in two different applications.