Obliquevision

Icon

Other ways of looking at things

Designing for Behavior Change Applying Psychology and Behavioral Economics By Stephen Wendel

The human decision making process is a complex mechanism. In Design for Behavior Change by Stephan Wendel we see how many of our assumptions about how individuals make day to day decisions may be flawed. The “decision change” in the context of this book is from the perspective on an individual who wants to make a change in behavior (e.g., financial nutritional, etc.) and has “opted in” to a system. The text give us an understanding of how to build systems that facilitate that behavior change based on behavioral science research.

If we understand the basic decision making process as Wendel lays out we can begin to structure our applications and systems base on this understanding. Wendel goes on to build a framework for understanding the phases of decision making and how to facilitate supportive strategies in application to aid the user.

Having a decision theory background a lot of the research presented was nothing new but what was helpful was the structure and strategies he layered on top of the research. Having a structures way to talk about the the phases of the decision process and strategies to the work with those phases is of great benefit when designing systems for behavior change. Even if you don’t build systems of this type ave a look, it will reveal a lot about how and why you make your day to day decisions.

APIs: A Strategy Guide by Daniel Jacobson, Greg Brail and Dan Woods

As the sub-title says this a a strategy guide and not a technical how to. If you are new to the world of APIs as a business strategy, need to evaluate and plan for the development and exposure of API’s both public and internal this is a valuable read. I you are a technical person and are planning on building out an API strategy this text will help you structure your thought and and consider the myriad of issues, both from the technical and business side of things.

The first sections discuss the whys of APIs development. This may be a bit obvious for those already engaged in the development and deployment but I have given this book to individuals who are not technically oriented but need to understand the rationale for their business and it has proven valuable, and a time saver.

The second half is more “nuts and bolts”considering things like operational issues, measures of success, and driving adoption. If you or you organization is involved in the development of APIs either public or private this book is a good quick read to structure a strategy and make sure you have the potential pitfalls covered.

Craftsmanship and High Level Patterns

imageOne of my favorite architects are the  Greene Brothers of Pasadena CA. They pioneered the ultimate bungalow style of the Arts and Crafts Movement around the turn of the century. When I started visiting their homes especially the Gamble House years ago I was impressed with their total control of all aspects of the design and execution. The Greene Brothers exerted control over all aspects of their projects from the building design through to the woodwork, textiles, leaded glass, landscaping, even dinner ware. They also had very close relationships with those responsible for execution such as the Hall brothers for millwork and furniture.

When you look at a Green Brothers project you realize very quickly they exerted control over the design and execution of projects through the extensive use of patterns that provide continuity and consistency throughout . For example, in the Gamble house there is the ever present “cloud lift” pattern that is repeated in all aspects of the designimage. Theses patterns not only provide for consistency but also efficiency in design and execution.  Thinking about the Greene Brothers also made me think about patterns in a different context. The role patterns play in how we conceptualize and execute complex web based systems. This is a natural connection since the computer science concept of using patterns was derived from architecture. When I first read the seminal work A Pattern Language by Alexander, I read it purely for an understanding of architecture. Years later it was the inspiration for the the design pattern moment in computer science. Design patterns in the computer science world traditionally have been used to provide structure at the architecture and code level.

Looking at The Greene Brothers use of patterns for control of the process from concept to execution can inform us as designers and developers of complex web bases systems.  The ability to execute and the tools they used are similar to those need to design and execute complex systems. First they they had control of a design language informed by patterns. These patterns allowed then to not only have consistency in design but also execute solutions eimageefficiently and cost effectively. They also had control of the execution of designs  through consistent use of patterns. There is a consistency across all of the execution, in the web design world this can result in consistent execution in architecture, UI/UX, marketing of the product, etc. if properly applied.

Recently I have begun to use patterns at the more conceptual level of complex system design. I have been working with a client  who has a business idea and begin to systematically apply conceptual patterns from the onset. I am not speaking of  patterns at the UI, structural or behavioral level but patterns that invoke core concepts of the system such as “invoke a sense of belonging” , “build long term coimagemmitment”  or “find the next thing.”  These are more psychological patterns which inform the fundamental goals of the system. These can be used at all levels, from business planning and marketing through to architectural, structural and detailed implementation. As someone who is regularly involved in all aspects of the design of systems from the conceptual design through to implementation, user evaluation and  long term system evolution having a consistent core set of patterns agreed upon by all stakeholders is extremely valuable.

In future posts I am going to explore in more detail the use of conceptual patterns in the early stages of design. In the mean time check out the Gamble House site for some stunning architectural photography.

All photos courteousy http://www.gamblehouse.org/photos/int/index.html

Learning Android by Marco Gargenta

Learning Android by Marko Gargenta

Learning Android by Marco Gargenta is what I would consider a high level introductory book for those well grounded in Java or have a strong OO development background and don’t mind coming up to speed in order to learn Android. If you like to learn by building out non-trivial applications in a style that mimic’s real world development then consider this book.

I have been writing Java code on and off since Java was considered one of those fringe languages for those a bit off kilter OO types. I also have a style of learning that is not book oriented. I seem to prefer the ad hoc “random walk in the woods” approach. Good for discovering a lot of interesting stuff, not so good at getting a well oriented systematic approach to developing in new areas. When Learning Android by Marco Gargenta was release I decided to have a go at a more direct approach. Since I had been developing in Android for several years this was not my traditional behavior.

The book is well suited to those with a solid Java background. Needless to say if you have a strong OO background and have developed in OO languages you will not have a problem, but I recommend you have a strong Java book at your side and a willingness to spend time in the Java references to get the most out of the book. The book covers a lot of ground and is defiantly not a “now push this button” style book.

The preface mentions that the book evolved from years of the authors teaching Android in Bootcamp style classes. This shines through in the book with little snippets of knowledge that pop up at the right moment, almost anticipating reader questions and not relying on the reader to research the issue. This is obviously the byproduct of teaching many classes and occasionally watching students flail.

The theme of the book is to incrementally evolve a “twitter like” application. Not my favorite domain but very enjoyable and an excellent vehicle for covering a lot of Android functional ground. Each chapter covers a broad Android functional area such as UI, Services, Broadcast Receivers, Content Providers, file and DB systems, etc. With each chapter new functionality is introduced to the application based on these core functions, the application is refactored and in the process the reader incrementally understands the relationship of the components. While the incremental enhancement approach can be a risky proposition for a book, as opposed to books that develop limited demo capability on a per chapter basis, it works well and keeps the reader engaged. Going through the book had the feeling of developing a real world application with all the success and failures one would anticipate.

The book does a good job of introducing the Android stack, Libraries, and the general concepts required for Android development. There is good treatment of the development environment setup, Eclipse, DDMS, appropriate API’s, etc. and along the way introducing the reader to debugging techniques and tricks. The author provides a “twitter like” site with the appropriate API for development purposes. This gives the developer a real world site to experiment with and provides great feedback as the project evolves.

I enjoyed how the book incrementally evolved core functions that was not simply adding on to existing code, but required refactoring of large chunks of code. This juggling of the allocation of core functions helped with the learning process of how to really “wire up” a non trivial application. While I learn by banging in code and flailing with the debug process (as opposed to cut-and-paste), the provided sample code, segmented by chapter, was nearly flawless and provided a fantastic backup.

As a side note, in the first week of work with the book there were some minor issues with the “twitter site” used for development. The author was incredibly helpful and responsive in resolving the issues. I liked this, having experienced books where promised code or documentation never materializes. The errata site on O’Reilly was active but the majority of the issues discovered by the first couple readers through the book were minor and would in no way stall a new reader.

I very much enjoyed working through this book. If you have a good grounding in Java you will really appreciate the pace of the books and its focus on Android specific functions. If you are new to Java but are comfortable with other OO languages and want to get up to speed with Android fear not, I think you will be OK with a little slogging. The book served my purpose by filling in little holes in my knowledge that I may have missed over the years and understanding new patterns and approaches.

Context

Context is a funny beast. It can be hard to define and even harder to “implement.” Over the next several posts I am going to go down a path that advocates for contextual frameworks for the development and deployment of situated applications, mostly mobile, but any application that requires a rich sensor/source mix to solve an end users problem. I hope to explain why context is important and demonstrate how it can be used to build better applications faster.

Over the years I have worked with many technologies to deliver various forms of multi-sensor/source decision support and situational awareness systems for a broad range of problem domains and delivery mechanisms. As our technology evolves (mainframe, client-server, web-app, mobile) the sophistication of the solutions also has evolved. We now have commodity based hand held sensor/source platforms (smart phones, etc.) that only several years ago were all but unattainable by all but the most sophisticated organizations.

A common aspect of the majority of the non-trivial systems I have been involved in share a common theme which involves some notion of the context of both the “systems” and the user. By non-trivial systems I mean they consume many sources of information (both sensor based and data) and have sophisticated user interaction and visualizations. Many times the system is responsible for winnowing down a vast information space and creating visualization and interactions that are apropos to the situation at hand which an be very fluid and dynamic.

Context is a challenging thing to characterize. It has been argued that context is a “social construction” and while this may be an interesting debate to engage in from a philosophical point of view it won’t get you very far if you want to design and build pragmatic solutions. Believe me, I’ve been there. The notion of context is not something I ever overtly set out to design into systems, until now. It just evolved as users adopted and adapted systems in more sophisticated ways and began to express how their “situated” needs drove the user experience, from how data sources were consumed and processed to how the information was presented and interacted with.

At about this point you are asking, who cares, why do we need some sort of contextual framework for our systems. There are several arguments for why having some notion of a contextual framework is important. From a purely architecture, design and engineering perspective it provides a mechanism for the integration and interaction of the sources of information in a more formal way directed at solving a particular problem. It allows for the specification of tangible qualities of the sources that impact the quality of the solution. For example, I need spatial accuracy of less than 2 meters, I need sub-second delivery of a certain piece of data from a specific set of sources(with a specific accuracy), I need to know how the individual or device is moving (direction, velocity, acceleration), and on and on.  We may be building a urban e-commerce mobile coupon app, an emergency response system, a field maintenance application here or an application for the elderly. The context of the problem at hand will dictate the data source(s), source quality, interaction, presentation, etc.

Another rational for contextual frameworks is they provide for a mechanism to frame the “user experience” and I define that very loosely at this point. We have now jumped up from how we “plumb” our systems to how they interact with the user (or other agents). Understanding the contextual needs of the user is paramount to providing the proper information, user experience and visualization that is appropriate to the current situation. To date, in the current generation of mobile application solutions, we see hand crafted and hard wired solutions focused on very specific problems and solutions. While this is a viable approach, experience has shown from both a design and rapid agile delivery perspective not to be a very effective approach. The solutions tend to be narrow focused not very adaptable and many time brittle.

Over the next several posts I will expand on these Ideas and demonstrate how context can be formalized and used to architect complex mobile applications that can not only be developed fasted but also provide better end user solutions.

Site Migration

ov2ObliqueVision is moving to a new hosting infrastructure. I have migrated my development infrastructure to the RackSpace Cloud for greater flexibility and capacity. In the process I am moving my blog and other site infrastructure over. This is a good opportunity to do a little house cleaning and with any move throw superfluous detritus in the virtual dumpster. Hold tight while the migratory process unfolds.

Good Stuff

Flickr Stream

My Linkedin Profile

Steve Hansen