Responsible Entities - Introduction

When C# is my technology of choice to design a middle tier (and I have the chance to work it out from scratch) I often end up using an open source architectural framework called CSLA.NET (This post isn't about C# or CSLA though. Indulge me a few moments as I try to set the context.). Created by +Rockford Lhotka, CSLA.NET essentially helps you with building an object-oriented business layer by the means of standardizing the implementation of business objects. I usually build a hierarchy of CSLA based business objects for each domain entity in which I encapsulate business logic (business rules, validations, authorization rules if I use any, etc.) and data. CSLA is a lot more than just a series of base classes from which you'd inherit your business objects (its capabilities form a number of books). Suffice it to say that it offers distribution within the middle tier in an easy and configurable way and facilitates the UI interactions (e.g.: data binding, sorting, N-level undo) within the boundaries of Microsoft technologies (e.g.: ASP.NET MVC).
Mapping CSLA to EJB 3.0, each CSLA business object is an equivalent of a Session Bean (a distributed business object that doesn't contain data) and an Entity (a POJO with no business logic). To a lot of developers who work with EJB 3, creating data entities means using JPA. And that, to some extent, is understandable. JPA introduced a much leaner approach to data persistence compared to Entity Beans and is usable both within Java SE environments as well as within Java EE.
But then the question arises, what if one can't or doesn't want to use JPA? For instance, if you are required to adhere to the specification of Java EE 5 where JPA was initially introduced and thus, lacking the features you might need.
Based on the lessons learned from CSLA, I'd like to build a model for entities in which:

1. Similar to JPA, entities are annotated POJOs.
2. Unlike JPA, the core data-related tasks (Population, Validation, and Tracking and Reporting Changes) are delegated to the entities themselves (validation is introduced in Java EE 6 with JSR 303). The advantage of this approach is that you don't have to annotate the entities with the detail of data layer objects such as table or procedure names. Also, entities that track and report their changes not only fulfill data persistence requirements, but also prove useful in the implementation of UI interactions.

In the next few posts, I'll explain the implementation detail of different aspects (Tracking changes, Validation, and Data Population) of the model.

Preferences Need No Inferences

I decided to write this post when I came across a website with a background image in its homepage and the header part of each internal page! And not just any image, but children's hand-drawn ones (a skeuomorph of children's drawing notebook). Although a trend out of fashion, I'd like to use this opportunity to explain why this isn't such a good idea from both usability and technical points of view. In rare cases the background image is actually the content. Those cases are not factored in this post.

Usability

A research paper titled "Attention web designers: You have 50 milliseconds to make a good first impression!"¹ talks about 3 studies that were conducted to find out how quickly people form an opinion about web page visual appeal.

    In the first study, participants twice rated the visual appeal of web homepages presented for 500ms each. The second study replicated the first, but participants also rated each web page on seven specific design dimensions. Visual appeal was found to be closely related to most of these. Study 3 again replicated the 500ms condition as well as adding a 50ms condition using the same stimuli to determine whether the first impression may be interpreted as a 'mere exposure effect' (Zajonc 1980). Throughout, visual appeal ratings were highly correlated from one phase to the next as were the correlations between the 50ms and 500ms conditions. Thus, visual appeal can be assessed within 50ms, suggesting that web designers have about 50 ms to make a good first impression.

Although sensory (visual design) and the first good impression are highly correlated, but in order to get the visual design right you need to think about what the visual design is actually presenting. Visual design is where the arrangement of interface elements such as content and navigation (skeleton) is presented. And skeleton presents a much more abstract aspect of your website; interaction design. Interaction design, I believe, is best explained by Jesse J. Garrett in his excellent book called "The Elements of User Experience".

    Any time a person uses a product, a sort of dance goes on between the two of them. The user moves around, and the system responds. Then the user moves in response to the system, and so the dance goes on.
....
But every dancer will tell you that for the dance to really work, each participant must anticipate the moves of the other.

Putting this in the context of 50 ms rule, visual design ought to be clear enough for user to quickly figure out the first or the next move. To know how, is beyond this post. Suffice to say that typography, choice of colors, consistency, and contrast are the elements of visual design to which you need to pay close attention.

Using background images will limit your choice of colors throughout the page to a great degree. It will also distract user's attention from the major tasks made available to him (e.g.: navigation menu, call to action boxes) to figure out the next move. Another word, it decreases the contrast of those tasks. However, if the image is not in the background then it can be cleverly placed and used as a mean to increase the contrast of major tasks with a lot less distraction. Let's consider Skype as an example.

Skype - An example of using image to increase the contrast of major tasks

The image in Skype's homepage isn't designed to captivate user's attention but to redirect it to important elements of the page:

1. Navigation bar on top with major tasks for users who have used Skype before
2. The "Join" circle (with the help of big blue circle) to, I guess, emphasize an important goal and increase the chance of conversion
3. And the immediate element below the image ("Learn about Skype") for users who have an idea what Skype is but haven't used it before and want more information. In this case, the page that follows "Learn about Skype" link does the justice. 

Moreover, the image is toned well and is not distracting.

Above picture shows Skype's homepage in a PC browser. The image below, however, shows how it looks like in tablets and smart phones.

Skype uses Responsive Web Design

Note the design uniformity and the emphasis on "account creation" goal. Interestingly, “Buy Skype Credit” is chosen to be one of the visible elements in this mode. Perhaps their analytic data shows smartphone users are more interested in making long distance phone calls (Skype To Go) or using Skype’s Wi-Fi hotspots both of which require Skype credit.


Technical

If you are using HTML5 along with scalable vector graphics, you are probably fine. Looking at IE's HTML5 score card (being the lowest and thus the least supportive of HTML5) it can be seen that SVG is supported.
But that's a big "if". Using HTML5 limits your browser and device support. So if you have to support broader (not necessarily older) set of browsers² then it's likely that you can't use HTML5. As a result, you need to select an image big enough that looks relatively sharp in all possible (or acceptable) resolutions which means heavier pages. It also have to look right in different orientations.

---

<sup>1. GITTE LINDGAARD, GARY FERNANDES, CATHY DUDEK and J. BROWN - Human Oriented Technology Lab, Carleton University, Ottawa, Canada - Behaviour & Information Technology, Vol. 25, No. 2 ↩
2. Your Mental Model (or any derived artifact) could clue you in on how IT-savvy you users are and consequently what sort of devices or browsers they might use. Or you might've already profiled the existing users (e.g.: Google Analytics). ↩</sup>

Microsoft hurt itself with Windows 8 (or did it?)

IDC's press release on April 10^th suggests a decline of almost 14% in PC shipments in the first quarter of 2013 compared to the same quarter in 2012 and, at the same time, the increase in the sale of tablets and smart phones. It also suggests that even the introduction of Windows 8 hasn't made any difference and, on the contrary, has slowed the market. The report continues to explain why:

The radical changes to the UI, removal of the familiar Start button, and the costs associated with touch have made PCs a less attractive alternative to dedicated tablets and other competitive devices. Microsoft will have to make some very tough decisions moving forward if it wants to help reinvigorate the PC market.

Now, those of you whom follow Adaptive Path's UX Week might have come across "Story of Windows 8" by +Jensen Harris, director of program management for the Windows user experience team. His presentation is about design principles behind Windows 8. The core presentation starts with a key question that product managers of Windows asked themselves back in 2009 that "is familiarity always the element that keep a product relevant; a winner" (paraphrasing, of course) while admitting Windows (arguably) is the most familiar experience in the world. The presentation continues to demonstrate examples that suggest otherwise.

It doesn't take a market research expert to connect the dots in this case. Microsoft, I believe, had realized that the PC market was (and will be) challenged by emerging markets and in order to remain a major player it had to recognise the differences of experiences such as those between PC and tablet users. Whether they've predicted this loss is not known to me. I'm only going to guess that they have and have been working with their partners to innovate further, but maybe not so much in the PC market.

I personally like what Microsoft has done with Windows 8. Although the tactile experience is missing in PCs with traditional means of input (Keyboard and mouse), the craftsmanship as well as efficiency of Windows 8 is enough for me to have at least one copy at home.

Mental Models

One of the companies I'm associated with is going through a major website redesign project. My responsibilities, as an architect, are divided between back-end duties (e.g.: design reviews of enterprise components) and participating in review sessions of many artifacts of Information Architecture and Content Strategy delivered by an external vendor. I realized then that it might be worth to write a brief for project members about the origin of these artifacts and some of the decisions around user experience; a Mental Model.
Two books were used as primary sources of this brief which I definitely recommend to every information architect, web designer or project manager; Mental Models by Indi Young and The Elements of User Experience by Jesse James Garrett.

"The deepest form of understanding another person is empathy which involves a shift from observing how people seem on the outside to imagining what it feels like to be them on the inside".¹

Empathy with a person is distinct from studying how a person uses something. In the context of application design, empathy extends to knowing what the person wants to accomplish regardless of whether he/she is aware of the solution.
Mental model gives one a deep understanding of people's motivations and thought-processes, along with the emotional and philosophical landscape in which they operate. It's simply an "affinity diagram"² of behaviors made from data gathered from audience representatives.
Most research techniques can be categories into three groups (Table 1). Mental model is a generative research technique that allows researcher to create a framework based on data from participant. This framework can be used to guide information architecture and interaction design. Aligning functionalities in a proposed solution with mental model will depict gaps and how well features and functions support users to achieve their goals.

Research Method	Techniques used	What is it good for?
Preference Opinions, likes, desires	Survey Focus Group Mood Boards Preference Interviews Card Sort Customer Feedback	Visual Design Branding Market Analysis Advertising Campaigns
Evaluative What is understood or accomplished with a tool	Usability Test Log Analysis Search Analytics Card Sort Customer Feedback	Interaction Functionality Screen layout Nomenclature Information Architecture
Generative Mental environment in which things get done	Non-directed Interviews Contextual Inquiry Mental Model Ethnography Diary	Navigation and Flow Interaction Design Alignment and Gap analysis Contextual Information Contextual Marketing

Table 1 - Research Types matrix

To create a mental model, one needs to collect actual users' perspective and vocabulary. Essentially, you interview users and analyze the conversations to create a diagram called Mental Model Diagram; a process of Interview-Comb-Group in which audience representatives³ are interviewed, interviews are combed for tasks⁴, and eventually grouped⁵ to form a diagram.

Why use mental models?
Three main reasons: Confidence in your design, Clarity in direction, and Continuity of strategy (3 Cs).

Confidence in your design
Mental model gives your team the confidence that what they design is founded on research. Management knows that product of that design will be a success. And since it respect some of users' philosophies and emotions it'll makes sense to them.
Mental model can be used to validate ideas and requests for change. If a change request doesn't match a behavior in mental model it can be adjusted or respectfully rejected. A mental models also helps in avoiding politics. It can be used as an impartial evaluator when it comes to discussions over design decisions; solid data replacing one's circumstantial interpretation of problems.
Moreover, mental models represent the entirety of each audience segment's environment. That is, mental model becomes a mean to distinguish among solutions that are required to provide good enough coverage and support to those segments. If there are a lot in common among audience segments, a single solution might suffice. On the other hand, distinctively different segment demands its own solution.

Clarity in direction
While designing a solution or product, not only you should care about user experience but also align design decisions with organization's business strategies. Another word, a potential design idea can't evolve in isolation. Thus, decisions about user experience ought to be part of a bigger scheme; the "Whole Experience". Essentially, a design decision should be assessed for its impact on all the ways an organization interacts with its users. Jesse James Garrett describes the phrase Experience Strategy accordingly: Experience Strategy = Business Strategy + User Experience⁶. Mental model helps you discover the gaps in existing user experience considering your business strategy and, vice versa, find out what your business strategy looks like with existing user experience.

Continuity of strategy
Since mental model provides a clear direction, it naturally becomes a mean to prioritise solutions. Now that you know how your business strategy should look like to support users better and sustain⁷ (or what the gaps are in users' whole experience with your organization) new ideas will begin to emerge and some solutions no longer make sense or pushed further down the solution stack. In summary, a mental model with which solutions are aligned becomes a strategy roadmap.
Furthermore, a mental model becomes a place where decision history and rational is recorded. It helps you to preserve internal knowledge and becomes a foundation of decisions to come.

---

<sup>1. "Difficult Conversations" by Douglas Stone, Bruce Patton, and Sheila Heen ↩
2. http://en.wikipedia.org/wiki/Affinity_diagram ↩
3. You'll have to start with finding what's called "Task-Based Audience Segments". The process involves finding groups of people in your audience who do similar things. From each group, depending on research project's scope and stakeholder's priorities, a few types of personalities are chosen to represent it. That follows a series of recruitments to find actual people who meet the criteria and are elaborate enough for interviews.↩
4. Finding tasks is not as simple as finding verbs in sentences. People aren't always specific in conversation and use things like tone of voice and gesture to depict a meaning. In this context, "task" refers to everything that comes up when a person accomplishes something; actions, thoughts, feelings, philosophies, and motivations.↩
5. Tasks are then grouped to towers and towers are grouped to mental segments of a mental model diagram.↩
6. http://blog.jjg.net ↩
7. Sustainability may not always be a very important criterion. However, the cost of support for an organization without clear experience strategy could bring it to its knees. In the context of application development and maintenance the cost of support includes frustration and job satisfaction rate of staff at all levels and consequently innovation rate. For example, in public sector related businesses, lack of innovation and use of modern technology is recognized as an important issue (Citizen Experience: Designing a New Relationship with Government).↩</sup>

Fact checking of an Agile development exercise

Recently I have been working with a development team on various sub-projects of a bigger project. New features were being introduced in form of new sub-projects and the team was eager to adopt Agile development. So we decided to do so in one of those sub-projects in order to get them familiar with the concept and hopefully apply it to all the future development projects.
I’ll briefly elaborate the conditions in which the development of the agile sub-project and a similar non-Agile project have been carried out, list their outcomes and leave the judgment to you. 

Project A:

• Scope is small.

• Requirements are captured in form of detail writing; provided by the Product Management team. (Took them one week to finish). This was the usual practice in the entire company. That is, no development starts without a written spec.

• The development team goes through the document (which is at least 50 pages) to find out the areas that are not very clear and clarify them with the PM team. They also estimate the development time for the features requested in the sub-project and negotiate the features with the stakeholders (A lot of buffer is used in estimates to mitigate risks).

• The development team shares the requirement with the Q.A team and starts development. Whenever a major feature is developed (iteratively) development team releases the unit-tested code to the Q.A team. This goes until the sub-project is complete. No change request is accepted while development is ongoing.

Project B:

• Scope is small.

• Requirements are captured in form of Sketches and Domain Models along with a list of identified functions (the preliminary copy was ready in three days). The development team and Q.A team have a couple of meetings with the Product Management team afterward to make sure they understand the models and the priority of the features. They start then designing the overall architecture with the help of Architecture team, finding the reusable components and developing the required base code while the Product Management works on the detail of some of the high priority features. Q.A team develops test plan and required test cases. These three teams constantly update each other during this process.

• Product managers evaluate the prototype and come up with a list of adjustments. In the meantime, Dev and Q.A teams study the detail document of the high priority features provided by the PM team to come up with more accurate estimate for high priority features.

• Teams discuss the changes, the detail document and the estimates.

• Dev team continues the development to solidify the architecture and frequently releases the developed and unit-tested code to the Q.A team to integrate and test. When all the bugs are resolved for each build, it will be released to the product managers for evaluation and assessment.

• Product managers can ask for change before the architecture is frozen which usually happens after the second release. In contrast, the Dev team has the opportunity to negotiate features.

Outcome of Project A:

• Some features could not make it to the deadline and some were not accepted by product managers as they were misunderstood by the Dev team.

Outcomes of Project B:

• Estimates were ready earlier and more accurate, too, as they were provided based on the actual development work that the Dev team had done.

• More angles of requirements were clear to Dev and PM teams because of the presence of the Q.A team in all the discussions from the beginning. Amazingly in some cases Q.A team members knew more about requirements than even PMs. That’s mainly because they have been testing other sub projects and are as familiar with overall requirements. Besides, they always ask the best questions. I believe that’s because they think about test cases and scenarios in advance.
• PM team was very happy about the outcome since all the important and high priority features that could finish in the given time and were agreed upon, were present and entirely tested. They were also happy about the fact that clients could start adoption of new features earlier.

I don’t think I need to explain which project was more successful. 

Before closing this post, I'd like to highlight a few of the pitfalls of agile development that I see or hear frequently.

• Pure modeling and sketching is not always a suitable way of requirement gathering. If you have distributed teams, challenging stakeholders or very complex requirements then you might want to spend a bit more time digging and documenting.

• If you are using TDD (Test Driven Development), it doesn’t mean that you don’t need a Q.A team or downstream black box testing; no matter how much developers may write unit tests and run white box testing.

• Change Adoption doesn’t mean that after every release stakeholders can come up with change requests. Change can be accepted and handled before the Architecture is stable. So it’s the development team’s responsibility to release the code as frequent as possible in form of an executable application to the stakeholders and it's stakeholders’ responsibility to assess the released application and come up with change requests as early as possible. That means, if you have a stakeholder that has no idea what he wants (and believe me, there are such stakeholders) you need to spend more time building prototypes and exploring requirements before you stabilize the Architecture.

• The project that was chosen for the team to exercise Agile development was relatively small. That’s because it was their first time doing iterative development in Agile manner and I wanted to mitigate potential risks imposed by failure of the project. Also, they had an agile practitioner in their team; me! Don't do this without a coach.

IT Architect Regional Conference ends

I wanted to write a quick one about the IT Architect Regional Conference SEA which was over yesterday. One of the questions I got a few times was that how one becomes a software architect.
Well, the quick answer would be that you need to realize that architecture design imposes different kinds of challenges compared to software development. If you become a senior developer it doesn't necessarily mean that you can get promoted to become an Architect. Today that forms one the IASA's missions; to tell everyone in the IT industry that Architecture is a profession of its own.
I, personally, started by reading a lot of books about software architecture or the industry in which I was working. That is, if I worked for a company in supply chain industry, I not only read a lot about SOA (widely used in that industry) but also about SCOR. This was happening when I was doing development works as well. While I was developing applications, I thought about various aspects of the architectural work behind it; its component design, development processes in place, risk mitigation, chosen technology(ies) to develop that application with, the roadmap that was set in place to realize the benefits of that application, user experience, etc.
If you are a developer and want to become a Software Architect, invest in it. As I mentioned being a senior developer doesn't make you a Software Architect.
This doesn't mean that being a Software Architect should keep you away from the details of development works. In fact one of the important things that a software architect should do in "Proper" iterative and incremental development approaches (which are perceived to be the right approach in developing software applications) is to build application's architecture in early stages of development in form of an executable application (sometimes a throw away). A software architect can build an application only if he/she possess development expertise and is familiar with technologies.

W.C.I.T 2008

Hi

I'll be a delegate in W.C.I.T 2008 (World Congress on Information and Technology) which is being held in Kuala Lumpur, Malaysia this coming May.

See you all there.