Interaction Design is one of the many facets of User Experience Design. The Encyclopedia of Interaction Design defines it as “shaping digital things for people’s use.” It’s a complex and wide ranging field that covers nearly all aspects of cognition, emotion, and behavior.
Over the past month, I had a few opportunities to talk to our clients about customer experience (CX) and user centered design/user experience (UX) and their role in application development. At Online we see how customer experience is fundamentally changing how business operates, but the question was: do our clients see it the same way?
Our past shapes how we see the future.
It's easy to forget how far we've come as application builders. In 1994, my strongest programming language was a dBase variant called Clipper. In fact, I was able to do such great things with Clipper that they called me “The Wizard.” (OK, one person said that one time, but it was still pretty great.) For those who have never been a Clipper wizard, here is a quick rundown of what Clipper could do:
This is the final installment of a two-part series on what you can do to ensure your project's code base is following the SOLID design principles as closely as possible. In Part 1, we looked at the Single Responsibility Principle and the Open-Closed Principle. Here in Part 2, we will look at the final three principles: the Liskov Substitution Principle, the Interface Segregation Principle, and the Dependency Inversion Principle.
When starting a new project, nobody intends to write poor code; yet without vigilant watch and a practice of refactoring, every code base eventually descends into chaos. Often the damage is done before anyone realizes it. One day you are looking through the code to make a change and you think to yourself, “This code is terrible! Who wrote this anyway?” You pull up the history on the file and realize… oh, it was me! Not a good feeling.
In my previous blog post, I explained SharePoint Content types. Taking that one step further, let’s now examine SharePoint’s out of the box capability of defining content types on external data in SharePoint. Once the external data is in SharePoint, we can leverage SharePoint’s standard set of functionality, such as defining an out of the box workflow, or the referential relationship between lists, etc.
This is a simple representation of the SharePoint Object Hierarchy. Each of the constituents is described below.
A common complaint in organizations is that people can’t find stuff. We are at an interesting point in time because this problem can get significantly worse or significantly better.
Defining a Mobile Application Strategy
In “Enterprise Mobile Applications: You Need a Strategy – Part 1,” I discussed the need for an overall Mobile Application Strategy when considering the development of an Enterprise Level Mobile Application for your organization and presented five key organization and business oriented questions to help define the strategy. In Part 2, I’d like to continue to provide some insight into the technology-based impacts a Mobile Application Strategy should address.
Are you contemplating building an Enterprise Level Mobile Application? I’m talking about an application requiring authentication, integrated to Enterprise Information systems, with a host of other business and non-functional requirements. Perhaps you have built many applications and believe you have a good handle on what it takes to create an Enterprise Level Mobile Application for your organization. But did you know that introducing it will have significant impact on how your current business and technology organizations function, requiring a Mobile Application Strategy?