Editing Application Roles in Oracle Process Cloud Service

The other day I was working on my demo of Oracle Process Cloud Service (PCS) for UKOUG Apps 2016.  After creating the application, I wanted to start working on the process. My use case fits an out of the box pattern nicely, so I started with "Form Approval with Integration Pattern" and PCS created a default process for me; with two swimlanes and a number of activities. The resulting process is shown below.

Process created based on "Form Approval with Integration Pattern"

Every PCS application is provisioned with three standard roles:

1. Process Owner. Users with this role have access to process activity history, can take actions, alter the process flow etc. Process owners typically manage deployed business processes and use metric analysis tools such as dashboards to monitor the business process. 
2. Process Reviewer. This role gives access to process activity, but process reviewers can not take actions on tasks or alter tasks flows.  Process reviewers are not participating but typically responsible for reporting on current process instance status. 
3. Analytics Viewer. assigned this role can create and view business analytics dashboards associated with the specified application.

In this example, I don't want to use these global application roles, I want two other roles:

1. Expense Submitter. An employee that submits an expense because of traveling or other reasons
2. Expense Approver.  The manager of the employee that approves the expense items on the expense report.

You can edit the swimlane by clicking on the pencil icon next to the swimlane and select a role. 

Assigning an application role to a swimlane

I did not see the role I was looking for in the list, but that is not a problem: I can add an Application Role to the list by clicking the "+" icon.

So far so good. I added a role "Expenser" and assigned the first swimlane to it. Then I did the same for the second swimlane: I edited the swimlane and added a new role "Expense Approver".

Unfortunately, I made a mistake....

Editing the role

I wanted to call the first swimlane/role "Expense Submitter", remember? I accidentally named it "Expenser". I want to change this name, because I don't like it.

My first attempt is in the current screen. I have the pencil next to the swimlane, so probably I can edit the role here, right? Wrong.

It will bring me back to assigning a role to a swimlane. I can assign it to a different role or a new role. But not edit it. 

So let's look at another option, there is another place to manage roles, on an application level.

Click on the tab "Application Home". This will bring you back to the Application Home. When you click on the "Organisation" link, you will get a pop-up that allows you to delete or add roles. However, you can't edit roles. 

Because I really wanted a new name, I deleted the role and added a new one.

Remember, adding a role will not only impact the swimlane, but also adds an application role for the application. This role will be available for all processes in this application.

Application Home with Dialog to add and remove Application Roles

Of course this makes you wonder what happened with the swimlane that was using the role we just deleted?

Let's see:

Unassigned role after deleting a role from the application

It results in a swimlane with a 'Unassigned role'. So I assigned the newly created role and continued with implementing the process. 

Conclusion

From a functional perspective, the ability to create a process based on a pattern is very powerful. The responsiveness of the process composer is very good. It is a pleasure to work with it, it feels like a modern application. However from a user experience perspective, I see plenty of room for improvement: 

1. Navigation
• Buttons versus links. Why is 'Organization' a link, not a button at the right hand side of the Application Home? Why is closing the application implemented with a link and not a button? There are multiple levels of navigation, and it is not always clear why which pattern is used for what level.
• Moving from the Workspace to the Process Composer. It is unclear to me how to get back to the workspace once you have entered the process composer, apart from saving the link as a favorite in your browser.
2. Internationalization
• Some concepts are translated, some are not. 
• Consistency. It seems that in the Dutch version, a project role is edited (see illustration), in the English version the dialog is called "edit Application roles" (the correct concept) . 
3. Concepts. 
• The name of the Swimlane is the same as the role you assign to it. The role is defined on an Application Level, not a process level. This is not clear from the way it is presented to the user and will only occur to the process developer, once (s)he will develop more than one process
• It is not possible to edit the name of the role. You have to delete it and then add a new role. This will result in swimlanes with unassigned roles in existing processes. 
• It is unclear for the process developer what a role entails, the pop-up window does not show where the role is used or what permissions are associated with it
• By default the submitter of a form is defined as the process owner. In most cases this will not be the case: the receiver of the form is typically the process owner, who will approve or deny the request and has the ability to change the process etc.

This is not an extensive list, but just the issues I ran into while trying to change the name of a process role after having created a process based on a pattern. 

From a functionality perspective PCS is becoming more and more powerful. However, it is very important to keep the User Experience that comes with the functionality consistent within itself and with the other Oracle products as well. Including the Oracle Applications. Because for users, the difference between PaaS and SaaS is inconsequential, they just use the tools. In the end, to users it does not matter whether Oracle calls these tools a 'Platform' or 'Software'. What matters is that they are productive and that the tools are easy to understand. 

I think it is time that Oracle repositions the Oracle Usable Apps group to a higher level to include the PaaS products. And please, as a first recommendation from a UX perspecive, let me edit roles 🙏

Experiencing Interaction '14

Last week I visited Interaction ’14 which was held in Amsterdam. Interaction is the annual interaction design conference built around a global community. As User Experience Expert I attended several Computer Human Interaction conferences before, but never this one. And I must say it was a very inspirational experience.

Context influences perception

One of the key takeaways was that context influences perception. This was shown in the talk by Bernard Lahousse (Partner at Foodpairing.com). He stated that the perception of food changes by the context in which it is served. To prove this, he asked a volunteer on stage and let him rub a rough object and simultaneously taste a drink, a minute later this subject had to taste another drink while rubbing a soft stuffed animal. The subject stated that the 1^st drink tasted sharp/bitter and the 2^nd drink more creamy/sweet. In fact he drank the same drink twice. So a tactile context influences perception of food.

The same goes for a bottle of wine you take home with you after a great holiday in Greece, because it tasted so well in a Greek tavern after a day of sunshine in Mediterranean air. Drinking the wine at home on a drizzling Saturday evening is perceived totally different.

The message of this talk matches very well with the talk by By Thomas Küber (Design lead at Groupon) and Christian Drehkopf (User Experience Evangelist and Mentor) in which they stated that we, as interaction designers, should not design for devices but “we should deliver experiences that create superb value for the users in their personal situation/context”.

Design motivation and curiosity

In order to inspire users to use the applications or products we design, we have to motivate users and make them curious. At Interaction ’14 there were 2 talks which gave some insight in how to do this.

There was Ellis Bartholomeus (Game- & Design consultant). She explained that motivation can be designed via play. To play you need a game (= the definition of the rules and goals) and a player (= the person interacting). To motivate the player to play the game, the player needs to feel safe and trust the game. The game should be hard to play, but not too hard. If the player barely completed the level, he will be curious about himself in the next level and be very loyal to play it again. A player will be motivated by a game if it contains wonderment, engagement, frustration, reward, surprise, irritation, freedom competence and joy.

Jan Willem Huisman (founder of IJsfontein Interactive Media) talked about how “curiosity and playfulness are deeply embedded in our mind and feed the urge for learning and exploring”. Users need structure, and must always feel in control.  By nature users also are curious and motivated and these characteristics should be fed by the applications/product they use. Curiosity is the urge to fill the information gap and curiosity can be designed among others by:

• leaving room for experiments
• telling what to expect and then hiding it
• creating violation of expectations
• creating a sequence with an unknown ending
• introducing novelty
• introducing information that is possessed by others.
• creating collaborative curiosity

However, the user should always be in control. “If we take control of the user, we kill curiosity” says Huisman.

Onlyness & Design Loneliness

I attended two talks pleading that good user experience design always involves a team.

Tash Wong (independent product designer) talked about Onlyness by which she means the fact that “we all have our own perspective and own unique feminine or masculine point of view from which we design. We are social engineers that design for behavior and communication.” To be able to design products/applications for others we need empathy and look at things from different points of view. Tash Wong developed a method containing a set of 16 cards which is designed to help UX designers better articulate their perspectives and priorities. The cards can be used to communicate the direction for a project, figure out why we do, what we do, or generate new ideas and then ‘Think Bigger to Make Better’.

Then there was Christopher Noessel (Managing Director at Cooper) talking about Design Loneliness and ‘Pair Design, Why You Need It’. In Agile developing software development pair programming is common. In UX design working in pairs also leads to better results. What you need is a pair of 2 designers: a generator (who generates ideas and sketches) and a synthesizer (who analyses and connects). Co-working like this results in a better design, a more efficient way of working and a happier team. While co-working like this, 3 rules should be taken into account:

1. There can only be one marker in the room

2. Ideas should be visualized, not only talked about

3. Feedback is given (mainly by the synthesizer)

    - What’s good

    - Questions?

    - Suggestions for improvement 

At Vennster we already work like this and from experience I can tell that it works.

Last week I have been listening to many experts in the field of interaction design and I gained a lot of inspiration which I definitely can use in the projects I’m currently working on as a User Experience Consultant for Vennster and in the ones I will be working on in the future.

If you want to read more about the lectures given at Interaction ’14 just visit their site http://interaction14.ixda.org

Mobile for business users

As I mentioned in a previous blog, Oracle Fusion Apps breaks with Oracle's past in the sense that the user interaction is built from a user perspective. Rather than exposing a datamodel or a business process to the user, they have designed the user interface based on information they have gathered about their user. Their website tells this compelling story, go check it out (after finishing this blog ;).

The world goes mobile

These days you can't just design for the desktop anymore. People use other devices like tablets and mobile phones and these devices are showing up in the workplace more and more. On top of that, people are working from different locations: from the office, from home, en route, or wherever they happen to be. This creates a new challenge when creating services or application. Take for example a HR self service application or an expense report application. Employees expect this functionality to be available everywhere, and on all devices.
At the other hand, organizations are struggling with the application of 'apps'. When I started programming, every piece of software had to have an API. Then the world realized that you want to integrate systems in heterogeneous landscapes and every piece of software needed to have a 'service interface'. Now that we have apps, every piece of software I realize needs to have a REST API so that people can create an app for that. The problem with this approach is that creating a service interface on every piece of software does not create a good service oriented architecture and creating a mobile interface for every piece of software does not create a good mobile user experience for your customers, employees and partners. So how should you approach this?

Oracle Fusion Applications User Experience Patterns and Guidelines 

The ADF User Experience patterns and guidelines site is a very good starting point for organizations that want to start using mobile for their applications. The site has four sections:

1. Design guidelines. This section explains that mobile design differs from designing for desktops. It  then states 10 mobile design guidelines. The most important ones are at the top: know your user and define the essential mobile task
2. Know your user is a separate section that talks about getting to know your user. You have to revisit your idea of your user and determine who will use your application on a mobile device and in what context this will happen. Creating personas is a very good technique that you can apply. The site has some references to this technique at the bottom. 
3. Create a mobile task flow. This section explains how your mobile tasks fit in the overall business process. Unfortunately this section is rather short and uses flow charting to show the flow in the user interface, and not the overall business process. It is very important that the business process and the (mobile) user interaction that is designed from the perspective of the user are aligned: otherwise you get into trouble with rules and regulations that exist in your organization for the business process that people are accessing using their mobile device.
4. Mobile design patterns. Users may not be used to using mobile applications for work, they use it at home and in their personal lives all the time. So using patterns that people are familiair with is important. You as a developer doesn't have to re-invent the wheel when creating the mobile tasks and your users are happy because the application works the way they expect. This will save money because there will less calls to the helpdesk, less errors and your application will actually be used ;)

OBUG Connect

Ultan Ó Broin and me will present some mobile design patterns that are defined in the process of designing mobile applications for Fusion apps at OBUG connect 2013, this afternoon. We will explain the importance of patterns and show some of the patterns that can be built with either ADF Mobile, or the native platform of a device.

Next: apply!

The next step is that projects start using these techniques to built user interaction for professional users, like we have been doing for consumer software for a long time. It is time that professionals get the user experience they deserve and need to be productive and happy while doing their job!

DOAG 2012

This week the German Oracle User Group, or DOAG as it is called in German, held their yearly conference. Like other years, the location was the conference center in Nuremberg, a beautiful city in the south.

Vennster was well represented in the SOA/BPM Space, we did the following sessions:

• SOA Made Simple: service design (Ronald van Luttikhuizen)
• SOA Made Simple: creating a roadmap for your SOA (Lonneke Dikmans) 
• Effective Fault Handling in Oracle SOA Suite 11g (Ronald van Luttikhuizen)
• Introduction in Eventing in SOA Suite 11g (Ronald van Luttikhuizen)
• Using the B2B Adapter in a Dutch government project (Ronald van Luttikhuizen)
• Securing heterogeneous systems using Oracle WebServices Manager (Ronald van Luttikhuizen and Jens Peters)
• Deployment in Oracle SOA Suite and Oracle BPM Suite (Lonneke Dikmans)
• Stop generating your User Interface! Start designing it (Lonneke Dikmans)

You can find the slides by Ronald and me on slideshare:

• http://www.slideshare.net/lonneked
• http://www.slideshare.net/rluttikhuizen

Of course there were also other presentations by other presenters ;) DOAG is a big conference, with over 400 presentations. Most of them cover cases, others explain the latest developments. There is a number of tracks that are of interest if you are working in the 'middleware space': BPM, Middleware & SOA, development, Java and Strategy and Business.  The English spoken sessions are not as popular as the German language sessions, but both are well visited. 

I visited three sessions, one case study titled "Dynamische Benutzer-Workflows mit SOA und BPM-Suite" by Arne Brüning, one about the new developments in EclipseLink called "The Evolution of Java Persistence" by Doug Clarke and the last one was a session titled "NoSQL and SQL: Blending the Best of Both Worlds" by Andrew Morgan. All three happened to be presented by Oracle. They were very different in nature. The workflow session discussed a customer case. It was interesting from that point of view. I would have preferred more technical depth, but the presenter was well prepared and had an interesting story to tell. The session by Doug about Eclipse gave a nice overview of the latest developments and put them into perspective of the history of TopLink and EclipseLink. I think that this is a good strategy: it shows that EclipseLink is both proven and modern: it has been around for years and part of the original team is still working there PLUS they have solutions for new developments like JSON, REST services, NoSQL and multi-tenancy. The final presentation was an example how not to do that. The presenter put NoSQL in the title in an attempt to attract a crowd. But the session was really about MySQL clusters. A lot of people left the session while he was talking, because it was completely off topic. The presentation itself was not bad, but the title was misleading.  

Unfortunately I did not have time to see more sessions, because of all the presentations we were doing ourselves. There certainly was a lot more I would have liked to listen to and I hope we will be back next year!

User scenarios | why & how

Designing Vennster.nl | part 3

In my last 2 blogs I explained that in the life cycle of experiencing the services/products of your company, users of your website can be visitors, customers or relations.

I also explained the importance of knowing the needs, wishes, knowledge level and habits of the users of your website and how to personalize this information by creating personas.

In this blog I will explain how stories of how a persona interacts with a website/application (scenario), puts the persona in motion and how this helps you to design a website in which the navigation steps are obvious to a user.

Writing scenarios

Scenarios put personas in motion. Scenarios are stories of how a persona interacts with a website/application. The persona is the character, a scenario is the plot. I wrote scenarios for each persona visiting the Vennster website-to-be.

In the scenarios I described:

• The most important situation in which the future users of the Vennster website,  Afra, Bernice or Carl would use Vennster.nl – I set the scene
• What Afra, Bernice or Carl want to achieve while visiting our website
• Which steps they would take including their thoughts and considerations at each step
• What feedback or guidance they expect from the website.

Underneath 2 parts of a scenario I wrote for Carl – the persona representing the Vennster relation.

The benefits of scenarios

 

• By writing down in a scenario what a persona wants and expects from your website/application what he thinks, assumes and how he acts, you create:
• A story which makes the persona come to live for all people involved in the design/development process of the website/application. – This helps them to reason from the user context instead of their own context
• An indication of the navigation structure: the user takes steps in a certain sequence to achieve his goal – make sure the website/application supports this.
• Ideas for new functionality which is needed by the user; he wants to accomplish something - the application should provide him the means for this.
• Recognition and acknowledgement from users. When confronting them with the right scenarios you will receive remarks like: “Yes I see…, this is what I meant, I only couldn’t find the right words for it myself.” You actually help users to formulate or order thoughts they sometimes even aren’t aware of.

• Scenarios also include what can go wrong by describing typical problems that occur and how the characters in the scenario solve these problems.
• Scenarios contain information about what feedback a user expects at which moment when using the website/application. Make sure you supply them with this feedback.

Personas give you an indication of who the users are. User scenarios provide information on how users will be interacting with the website/application you intent to design.  Therefore personas as well as scenarios are crucial to be able to develop a website/application for visitors/users to achieve what they really want/need.

N.B. The scenarios describe the most probable cases that the user will need and that you want to support. Keep them in mind when designing and developing your website or application. However, as Alan Coopers states in one of his design axioms:  “Design for the probable; provide for the possible.”  In other words, the use of scenarios shouldn't result in a restricted user interface. It should result in a structure that is optimized for the most probable usage scenarios. The more exotic or less frequent scenarios should obviously still be possible and accessible. Think for example about changing your personal data on an e-commerce site. This is less important than the ordering of products, but you still make it possible for users to execute this task.

With the personas and scenarios for Vennster.nl, I gathered crucial content for the User eXperience Design Quadrants model (XDQ copyright 2009 by Akendi) which I use as a guideline to great UX-design.

In my next blog I will tell you more about the XDQ-model and how I use it while defining the UX for Vennster.nl 

Personas | what, why & how

Designing Vennster.nl | part 2 

In my last blog I explained that in the lifecycle of experiencing the services/products of your company, users of your website can be visitors, customers or relations.

In every phase of the lifecycle, a user has different needs regarding the website.

To be able to create a successful, user-friendly website or application, every decision you take, whether you are part of the marketing team, the design team or the development team, should be based on what you know about the user.

But be aware of the fact that YOU are NOT the users/visitors of your website/ application.

For example:

A manager is looking at an application which is designed to be used by the customer service department within his company. He judges it and says: “I don’t understand this button!” He himself will never use the tool. His service people are working with the tool every day, therefore they have different expectations and requirements than their chief executive. For them this criticized shortcut key is one of the features they like most about the application, saving them time in processing the calls.

It is important to realize that:

• Your visitors have different goals than you have.
• Users/visitors don’t care about the way the product is created as you do. They have no interest in how the carefully crafted navigation system that you are selling them works, as long as they can accomplish their goals.
• User/visitors have different skills, background, education and interests.

As you can see from this, you are not the (target) visitor of the application or the website, and… the users/visitors of your website aren’t all alike!

Creating a realistic character sketch which represents one or more segments of the website’s or applications target audience (a persona) helps you visualizing the user(s) of your website. This then helps you focus your effort on certain personas and aides in your decision-making during planning, design and realization.

Creating personas

During my search for user needs, - characteristics and their behavior regarding our own website I learned about them through direct contact. For example by doing user research like: 

• User interviews and field studies; 
• User surveys.

If you don’t have the opportunity to meet your user(s), doing desk research can also provide you with the necessary information to collect information about users.

I came to know about the goals, the behavior and the attitude of the different users and found information about their background and knowledge level regarding the website we want to design and develop.

With the information I gathered from the research, I was able to create 3 realistic character sketches (personas) which represent the different users of our Vennster website.

Personas put a face on all the user research. Each persona has a name and a face (by means of a photo), a profile and a quote from the persona that captures his/her essence and serves as one of the initial things to get a quick sense of that persona. A persona also includes personal information, domain specific information, and information about his or her computer and internet usage.  In addition to all this information it’s key to also add the business objectives you have for the persona.

For Vennster.nl I created 3 personas:

• the visitor (Afra - Looking for Vennsters experience);
• the customer (Bernice - Satisfied with the Vennster consultant);
• the relation (Carl – How can Vennster and my company cooperate?).

Underneath for example part of the description of Carl - the persona representing the Vennster relation.

Besides the information about the characteristics and an indication of their lifestyle and identity, the description of what motivates them, their experience with computers, internet and which websites they prefer helps to give the character more depth in areas that are relevant for our website. 

Prioritizing personas

Sometimes you find personas have conflicting needs with regards to the website. In our case the technical persona (Carl) knows the jargon but the business user (Afra) is not familiar with the technical terms. A way of dealing with that conflict is to prioritize the personas.

Together with Vennsters management I figured out which persona is the most important to satisfy by deciding which one is the most (financially) valuable to Vennster as a company.  This primary persona is the one for whom we will optimize the site.

Furthermore we as Vennster decided what we will do with the needs of the other personas. Possible solutions are micro sites, a blog for the more technical user, etc. 

The benefits of personas

As this example shows, personas have the following benefits:

• Personas bring focus.
• Personas build empathy, not only because of the fact that they have a face and a name, but also because it is as if you really know them personally.
• Personas encourage consensus. They bring the marketing-, design-, development team together and create one shared vision of exactly whom the team is designing for and what the users want:
• Business development; developing a strategy that fits the client.
• Marketing; seducing the user/visitor.
• Technical development;  developing with the user in mind.

• Personas create efficiency. They help the whole team to decide what to create in the first place.
• Personas lead to better decisions; every decision the team makes can be linked to users in a defensible way.

Source of information: 'The User Is Always Right' by S.Mulder with Z.Yaar.

Above mentioned benefits indicate the role of personas in the UX design process. Using personas ensures that marketers, copywriters, designers and developers during the development of the site do not lose sight of the users/visitors when taking crucial decisions.

In my next blog I will tell you more on how to put personas in motion by making them the main characters in user scenarios - stories of how a persona interacts with Vennster.nl - and why doing this helps you design and develop a usable website/application.

 

Website users in different stages of the experience lifecycle

Creating Vennster.nl - Part 1

As you might know we as Vennster are an independent company since the beginning of 2011. As part of the process, we changed our name and our branding style. Now it’s time to develop our own website - Vennster.nl. Of course we do that in a way we also would when designing a website for one of our customers using the appropriate methods and tools.

The first and most important step is to determine who the target audience of our website is.

In the lifecycle of experiencing the services/products of your company, users of your website can be in different stages. They can be…

…Visitors

• Don’t know you (very well)
• Become aware of you: the company & the people
• Explore your services/products
• Compare your company with similar companies
• Might become a customer

…Customers

• Are already making use of your services/products
• Wonder what more you have to offer
• Want to know what there is to benefit

…Relations

• Know you very well – are loyal fans
• Need information in more depth
• Want to know about new things
• Want to share knowledge
• Might recommend your services/products to others

All three user types…

• ...have different needs when visiting the site.
  Relations are familiar with your way of doing business, the methods you use. Visitors might not be, they need more explanation.
• ...look at the information from different points of view.
• ...might enter a website via different channels. Therefore you need to be sure that your website is findable in all different ways. Visitors will use Google, customers might use (part of) the URL and relations may have (a certain page of) your website in their list of favorites. Therefore users will not always land on your homepage but will very likely end up somewhere else in your site. This means you have to make sure that it is easy to navigate from anywhere in the website. If you want to know more about ‘the Total Experience Lifecycle’ check out the website of Akendi, partner from Vennster in UX-design from Canada: http://www.akendi.com/end-to-end-experience-design-process/akendi-experience-lifecycle.php.

First we determined who we want to target with our website. Due to the nature of our services our target audience consists of people with very different professions and skills. In order to find out who these users of our Vennster.nl-site really are, we used a common technique: describing personas; a realistic picture of a person that represents a specific part of the target group for the service/product/website we have to offer them. In our case there is a need for personas in different stages of the relationship describing the visitor, the customer and the relation.

In my next blog I will explain how we created such a realistic picture and why this is necessary.