In today’s world, information is available to anyone with a simple swipe on a smartphone. With this ease of interaction, customers are increasingly rejecting traditional brand touchpoints, such as print media, and focusing their time on personalized interactions that are designed with the customer in mind. A future filled with digital experiences is closer than we think and we need to adapt, or be lost, to this new reality.
What does it mean to have a hit product? Think about the last time you downloaded an app that you felt excited about using. Then actually used it, regularly. An app that you found useful, yes, but also pleasurable. You’re probably going to be hard-pressed to come up with an example outside of Angry Birds, right? Well that’s the goal that we set for ourselves here at Online. We don’t just want to make apps that are useful, we want to build apps for our clients’ that are a hit with their users.
The final entry of a three-part blog on building secure solutions using Online’s Secure Solution Delivery Life Cycle (SSDLC).
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.