Hi All - I've just updated the Ideas Exchange post here - https://community.anaplan.com/t5/Idea-Exchange/Hold-and-Release-functionality/idi-p/77486 - hold/release for breakback cells is currently being planned by our engineering teams.
... View more
Hi everyone. Just a quick note to let you know we've just enabled native support for multiple page-level selectors where you have many cards all with line items pivoted to pages. We're not changing how your pages currently look, so no need to worry about disrupting live users, but next time you go to edit the page you'll have the opportunity to update your page-level selectors and get any new ones for additional modules on the page. Have a great day. Dave.
... View more
We’re actually looking into this at the moment as part of some extensions to support notifying multiple recipients driven by a module. One of the module examples we’d like to support matches this idea quite closely with scenarios like “send a notification to all users in my selected region where the ‘forecast completed’ boolean is false”.
... View more
Unfortunately this isn't something we're able to support. When using a form, the new list item isn't created in the model until the form is submitted, meaning that until this point no data within the form exists in the model.
Things like dependent dropdowns and conditional formatting are driven by model calculations, and while the data in the form is yet to exist in the model we are unable to apply those calculations.
If we were to re-engineer forms to insert a new list item into the model when the form is opened then these model calculations could apply but this approach opens up the challenge of handling (potentially many) orphaned or no-longer-required list items within a production model.
The current suggested workaround is to use a form to capture the initial data about the new list item and then a combination of field cards and grid cards to capture additional data once the list item has been created within the model.
... View more
Hi All. Thanks for flagging this - we have a development team currently pushing through a fix for this which will extend the 100 character limit and we'll be releasing this as soon as possible. We'll also work on some improved UI for the builder and hope to get this change out shortly after. All the best. Dave.
... View more
Accessibility is something we in the Product Team are getting asked about more and more often—and not just from customers with a legal obligation to deliver accessible solutions to their users. Internal cultures have been changing, and organizations see inclusivity as a must when procuring solutions and building experiences for their users and stakeholders.
When you move an implementation over to the Anaplan UX, it can help you spread the use of Anaplan in your organization to more contributors, planners, and decision-makers. Democratizing your planning process in this way is a fantastic way to get faster inputs, more complete review, and increased confidence in your decisions. But, as you deploy your build to more and more users, your responsibility to deliver an experience that all of them can use becomes increasingly important.
Luckily, the Anaplan UX has been designed with accessibility at its core, and there's a range of features available to you to ensure that the pages you build are as accessible as possible.
What Do We Mean By 'Accessibility'?
Globally, around 1 billion people have some form of disability; that's around 15% of the population. To put this into perspective, this means that 1 in 4 people in the U.S. (61 million adults) and 1 in 5 people in the U.K. (13.9 million adults) have some potential need for assistance when using digital products.
Additionally, the retirement age continues to rise for working adults meaning more and more people are likely to work well into their late 60s. Nearly half of all people over the age of 60 (46%) have some type of disability.
When we talk about accessibility, we mean that we build products to be usable by everyone, including those with disabilities. We have to ensure that when designing products and services, we don't make it more difficult (or impossible) for them to be used by everyone.
Accessibility Creates Great Usability
The nice thing when thinking about accessibility first is that it results in creating great experiences that are useful for everyone. For example:
Have you ever wanted to check your messages on your phone in bright sunlight?
Have you wanted to read a newspaper, but an eye infection means you can't wear your contact lenses?
Have you ever tried to submit your voter registration or a tax return, but it's your first time using the website and it's confusing?
Have you ever tried to dial a phone number, but you're so cold that your hands are shaking?
Have you ever injured your wrist or arm, making it more difficult to use a mouse or trackpad?
If you can answer yes to any of these, then you have had a need for some accessibility feature—maybe without even realizing it.
How Can the Anaplan UX Help?
Accessibility has been baked into everything we do when it comes to the design and development of the Anaplan UX, and this can be traced back through the development process all the way to the definition of functionality and experience.
We use personas to help us design and validate our user experience against the key, known user types such as a "contributor," a "planner," and an "executive," but we also have a range of personas with additional needs that help us ensure that these needs are at the forefront of the entire design and development process.
In total, we currently have five accessibility personas, including Keith and Edith.
You can read more about how we use personas in this Medium article by our Anaplan Design System Lead, Mark Boyes-Smith.
Anaplan Design System
One of the challenges when designing experiences is providing consistency as users move across different aspects of the product. Think of a user moving from Anaplan.com to the UX and then to Anapedia. To help us solve this challenge we've built out an internal design system that provides a set of rules, guidelines, and shared components that we use across our product to ensure consistency.
One of the great things about the Anaplan Design System is that accessible components have been considered from the beginning; everywhere we use it inherits this accessibility support and helps us to deliver an exceptional experience for all of our users.
Accessibility in the UX
Having a fantastic range of user personas, coupled with a strong and accessible design system as part of the foundations of the UX, we can enable you with building accessible solutions for your users.
Interface Colors and Text Styles
We’ve been very careful with color selections and typefaces across the interface to ensure readability for all users, including those with a range of visual impairments. We’ve even used specific typeface variants for the display of numbers in grids to ensure that everything aligns in a readable way.
We’ve applied this thinking to things like the default chart colors as well. Not only do they contrast clearly against the background of the chart, but when they display next to each other (like in a pie chart), there’s sufficient contrast between them that differentiation is easy.
We’ve worked on keyboard navigation mechanisms to make it easier for users who don’t use a mouse or trackpad to interact with the product, and we’ve even added mouse-free interactions for things like pivoting, which would traditionally be a drag-and-drop experience.
Grid Zoom Options
When using worksheets, users can opt to show grid data in a range of sizes. Users who like loads of data and don't mind slightly smaller text can go for "small," while those that prefer larger text and a little more space can choose "large."
Design for Neurodiversity
We’ve also been very conscious to design for neuro-diversity. You’ll notice the use of animations and visual transitions is subtle and never without purpose, and where we do use animations and UI elements that automatically dismiss themselves, we’ve carefully timed these to be as accessible as possible for all users.
New, Accessible Features
We’ve even added some new features to the New UX that, as well as being awesome for all users, were born out of explorations in becoming more accessible. Take the new conditional formatting styles for example. “Border” allows you to use traditional conditional formatting with the reassurance that values will always maintain contrast and be readable, while “morse” is a unique feature that takes conditional formatting and makes it usable for users with a wide range of visual impairments making trend analysis and anomaly detection far easier.
Accessibility is a Journey...
...And we recognize we're not there yet. Accessibility support is a journey, and we're committed to doing more.
Over the coming months, we'll be working with a range of accessibility specialists to target the areas of the product where we can add more to support users with a range of needs. As we work through this process you'll see incremental enhancements available as soon as they're ready, and we'll drive towards both a more accessible product and a clear declaration of our intent in this area.
More importantly, this process will continue to arm us with all of the skills, knowledge, and expertise we need to make sure that when we say "all planning for all people" we can be confident that we really mean all people.
... View more
Thank you for all of your input into this one - we've just released a change this morning that implements this mechanism. When you click a grid using hierarchy sync, everything else on the page will update but the thing you've clicked on will retain its original view of the dataset.
... View more
Hi @kylavalley - the new Home experience doesn't replicate the background functionality that was previously available so this should no longer be an issue for you. We are looking at how we can provide more visual tailoring options in the future and this will likely be restricted to tenant admin users only.
... View more
Creating new list items and capturing data against them forms a critical part of many planning processes, especially those that seek to democratize planning by engaging end users in a wider range of planning activities. Forms are a new input mechanism added to the Anaplan UX that allow you to create simple, intuitive input forms that feel familiar to end users and submit data directly into your models.
Let's look at a simple example where forms can support a planning process:
Scenario: You've been tasked with creating a set of pages in Anaplan's UX to support a simple headcount planning process where department heads need to log their recruitment requirements for the next financial year. Your contributors (department heads) need to create new required team members within the correct teams, add a job role level, a ramp profile, and a start date. This data can then be used to get a complete picture of recruitment requirements and cost across the business for the next year.
While in reality, the model will be more complex, we'll focus on a couple of lists and a single module for this example.
For this example, we'll use a simple composite list to represent our team and requirements structure. We'll define a teams list to outline the structure of the organization and a requirements list to hold all of our headcount requirements.
Our teams list is a simple list set with a top-level item of All Teams.
We've set our requirements list up as a numbered list using teams as its parent hierarchy. To show the full range of forms functionality we've also added two properties to our requirements list to track the project we anticipate the new hire moving onto—and these are both set to text formatted.
The module we'll use to track our requirements across the organization will be relatively simple and will only be dimensioned with the requirements list and a series of line items.
We've also added a third, simple list that will help us to track headcount requirements across different years.
Creating Our Form
We'll start by building a simple worksheet in our new Headcount Planning app that will house our requirements module. This will be a simple, grid-focussed view that will let us track all of the incoming recruitment requirements in a single place.
We've made sure our view is pivoted with planning years on pages and our requirements list and line items visible within the grid.
We'll use this worksheet as our main headcount planning space, so we should now add a form to the page to allow our contributors to submit their requirements. We'll click into edit mode for the page and open the configure worksheet actions panel where we can decide what actions our end users can perform when working with this worksheet.
Opening up the forms section in the right-hand panel gives us the opportunity to reuse an existing form or to create a new one. As this page is a new requirement for our process, we'll click to add a new form.
We can give our form a name so we can track it as part of our app, and we'll choose the list we want the form to insert data into.
Adding List Properties
Before proceeding with list properties you should carefully consider the overall design of your model. You can read more about this in David Smith's best practice article on module design. In the example we're looking at we've decided to track a couple of bits of data as list properties, so we'll add those to our form.
By toggling the switches for our project name and project code list properties we can add those fields to our form for our end users to complete. Note the form preview update in real-time to show us what our form will look like.
List Item Parent Selection
In this example process, we want each department head to be able to choose the team their required recruit should be placed. We'll use the 'allow user to choose parent' toggle to add a parent selector into the form for them to fill out.
If we wanted to restrict where contributors can add data, we could leave this toggle in its off position and instead define the parent ourselves. By doing this, any new list items created by this form will be automatically assigned to that parent where a downstream process could be used to assign them to their correct location.
Populating Module Line Items
The majority of data we need to capture from our contributors in this form are actually mapped to line items in our module. Luckily, we can use forms to both insert a new list item and then proceed to fill in line item values in a chosen module.
First, we need to select the module we want to insert data into.
The 'choose module' dropdown lets us browse all of the modules in our model where at least one line item is dimensioned against the list we've chosen Once a module is selected we'll be given a list of available line items we can add to our form. Note that read-only line items, typically those driven by formulae, are excluded from this list ensuring we only ask contributors for inputs they can actually provide.
Each time we add a line item to our form we can see the preview update until we're happy that the form is capturing everything we need. As we're using a worksheet to launch our form, users can still edit values directly into the grid once their requirement has been added, but the form helps to minimize the need for manual grid editing as part of this process.
Validating Data Input
Our form is now structurally complete and ready to publish, but we've had some last-minute requirements from our Human Resources (HR) department:
Additional requirements: HR would like to insist that all project codes used for headcount requirements consist of uppercase letters and numbers only. In addition, please refrain from using numbers and special characters when providing job role information. Remember that project names and codes, as well as job roles, must be completed when requesting a new hire.
Luckily, we can use the inbuilt validation features of forms to help our users get this right first time. Let's start by selecting our project code field in the form preview and clicking its cog/settings icon.
Using the validation rules side panel we can configure this field to only allow the required characters—uppercase letters and numbers.
By setting these validation rules, if a user tries to add a new headcount requirement and their values for these fields do not match the required rules, then the user will be informed and told how to resolve the issues.
HR has also requested that a number of fields in the form are mandatory. We can use the validation rules to insist that users complete these fields before the form can be submitted.
For each of the required fields, we click the cog/settings icon and define the field as required. You'll see the form preview updated to show a red * next to all required fields so the user can clearly see what must be completed when using the form.
Note that validation rules can only be applied to text formatted properties and line items.
Using Context Filters
As our module, or at least one line item in our module, is dimensioned against something on pages you'll see that our form has detected this and given us a context filter within our form.
As a builder, we can decide what our users can do with this dimension (in our example, the year against which requirements are added) we can click the cog/settings icon for the context filter and decide whether the filter should be hidden in our form, visible but not editable, or fully editable by end users in the same way as with our existing board cards.
We can also decide whether or not the context filter should automatically set itself to match the context on the page. This is the default as it will ensure new line item values are submitted into the slice of data that's currently in view. If you want to default this to something else then you can select a default when designing your form and adjust the copy from page toggle.
Adding the Form to Our Planning Process
With the example workflow we're designing for, we're happy that users can land on the worksheet and use the form to add their data. Enabling this is easy as we can just switch the form on using the toggle in the right-hand panel after we've clicked configure worksheet actions.
Let's take a look at this from the perspective of an end-user...
As our contributors land on the worksheet, they can click the + button to launch the form. The form we designed then guides them through the process of logging their recruitment requirements.
Users are provided with relevant validation messages as they fill out their form, and when everything's ready, submitting the form adds list item and line item values directly into our module.
Forms on Boards
Our worksheet is now live and shared with our contributors (remember URLs in the New UX are all unique so you can copy and share links) and everyone's adding their requirements giving recruitment and HR great visibility for the coming year.
Things are going so well—in fact, you've just received this note from your director of operations:
Great news! The form you've built in Anaplan is working brilliantly, and we've got more visibility of upcoming hire requirements than we've ever had. Nice work. One last thing though, could we enable the creation of new requirements directly from our HR Ops dashboard? Let me know if this is doable.
The good news is that once a form has been built it can quickly be added to any of the boards in the same app.
We can quickly jump into edit mode for the board, and we'll add an action card that will let users launch our form. Editing the action card lets us choose which forms (or actions) we want to include as buttons. Here we've toggled our new form to on.
Our new action button has now unlocked our form for use on the HR ops board, and a whole new audience of end users can launch the form to add new hiring requirements.
Forms documentation on Anapedia
Best Practices for Module Design
... View more