Tableau describe web-authoring as:
A feature that gets the most mileage out of a view or dashboard published to Tableau Server is web authoring. Use web authoring to change an existing view or create a new view with the meta-data available in the workbook. Most Tableau customers use web authoring to create one-off reports.
Or let me put it another way, web-edit is an amazing aspect of the product that is, in my opinion, amazingly underutilised and underappreciated. It has the ability to empower your consumers, to democratise data well beyond the traditional relationship of analyst building content and stakeholders consuming it; and yet I can barely remember a blog post written about it, or a case study being written.
Why?
Maybe it is because web-edit lacks the glamour and instant appeal of the latest Tableau Public craze or maybe it is simpler than that, maybe it is because data leadership and changing the way an organisation uses data is hard and often a long journey and ensuring adoption is even harder.
So here is my promise to you. Based on my experience of successfully deploying Tableau web-edit, I am going to share my perspective of a Tableau web-edit playbook, an end to end strategy from vision and implementation through to an ongoing community and fostering your next generation of Desktop users. I promise you it won’t be right for everyone, but what I hope is, it will make you sit up and take note and appreciate the potential of one of Tableau’s ‘hidden’ gems.
Step 1 : Strategy
Consider Your Audience and Define Your Vision
This playbook is not going to describe the technical steps to enabling web-edit, I will leave that to those Tableau Server gurus far more qualified than me to describe the ins and outs of Tableau Server settings. Instead I focus on how you enable web-edit to be successful and to start I would encourage you, as with any strategy, to consider your vision and your use cases.
When I first think of web-edit I think of non-analysts developing agile, ad-hoc content, minimising the time from intrigue to insights. This is one use case, but I would challenge you to go deeper and take into account the following principles:
Not for everyone: If you have 2,000 users on your Tableau site I would passionately state you will not have 2,000 web-authors. Just because you can, does not mean you should. If you truly want web-edit to be well utilised, consider who really needs the ability to create content versus those who can happily gain insights through exploring production dashboard that are built for them. When deploying web-edit I would suggest start small, allowing you the time to support your web-edit users and then grow. Aim for an initial deployment of 1%-2% of the users registered on your Tableau site and then grow, do not under-estimate the effort it will take to educate users and inspire change.
Ask yourself what do you want to achieve from adopting web-edit? Will web-edit content remain short-term ad-hoc content or do you expect web-edit content to mature and flourish into pre-production dashboards? Yes, I said pre-production dashboards. Collaboration in the modern workplace is more important than ever and web-edit can play a big part in this.
Consider this; many of your web-authors will not be traditional analysts, rather the vast majority will be business experts with extensive knowledge of their subject matter, for example finance professionals, whose experience of building analysts extends little beyond Excel. If you empower business experts with web-edit you can allow them to create your prototype dashboards, to be the pioneers, who innovate, without worrying about the pixel perfect limits of an enterprise production dashboard. They can share their web-edit content with your enterprise Business Intelligence Team who then can evolve their creations into the governed content needed for wider deployment within a production environment.
All of a sudden your business experts have a voice in dashboard design, have a wider understanding of data and become your next generation of data champions.
This pyramid might help you understand where I see web-authoring sitting within a typical organisation's approach to BI:
Once you have assessed the data needs of your organisation and where web-edit can contribute to those needs, sell your vision to your stakeholders but do it in ways that resonate with them, that articulate the benefit it will bring to them and the business, rather than the technical process of how it will be achieved.
Finally seek a business sponsor. Of course your data leaders will understand the need for web-edit, but adoption and buy-in will be far greater and quicker if web-edit is sponsored by the business and it is the business knocking down your door to say they want it and they want it now!
Step 2 : Education and Support
Invest In Your Web-Authors
Vision defined, audience identified, time to crack on with activating web-edit on Server and letting the magic begin. Wrong. Before you allow your users access to web-edit consider their skills needs. Just because someone may have previously consumed data through a Tableau dashboard or built a pivot table in Excel does not mean they will understand data, the nuance of good design, or more importantly instantly be able to pick up web-edit and start to communicate with their data or build their first chart.
There are many things to consider before allowing someone loose with web-edit, do they;
Understand the principles of data fluency?
Demonstrate awareness of data ethics to ensure they portray data accurately, without bias and are open to other possibilities beyond their own instincts or beliefs?
Appreciate the importance of data quality and what poor data quality can mean in terms of the insights they wish to share through web-edit?
Know the principles of good dashboard design?
Possess the technical skills to connect to data and build content in web-edit?
Have a network that will continue to support their ongoing development and use of web-edit?
There is not one single training course of action you can take to tackle all of the above questions, as with everything related to people and adoption, it takes time, effort and a great deal of thought; not to mention patience and perseverance; but let us start somewhere and that somewhere is Tableau e-learning.
Introduce The Role and Foundational Pillars
Believe it or not there are people out there who do not live and breathe data; weird I know but they exist! When the business nominates their future web-authors the honest truth is most of these people would not have volunteered, many would have been told it is a great opportunity and the business would like them to take part.
With this in mind it is critical to take time, up front, to build a rapport with your web-authors and help them to understand the benefits of being to build their own content to help them and their colleagues to see and understand their data. Do this through personal messaging, whilst you may not be able to meet people in person, it does not stop you hosting virtual introductions where you can share your organisation's vision for web-edit and also some of your foundational pillars relating to how you approach data; this is where you tackle the topics of data fluency and data ethics. These terms will mean different things in different organisations so take the time to write your own content and share the messaging that needs to be shared for your organisation; and share it using stories, real-life examples, not technical speak and jargon.
Tableau Web-Author e-learning
If budget allows, I would encourage you to define a training programme that all web-authors must complete prior to gaining access to the functionality; and this is where Tableau e-learning comes into play.
Within Tableau’s e-learning platform there are Author Learning Paths, and one of those paths is that of Web-Author. This path will take your users through the journey of connecting with data, designing and creating views, how to analyse data with Tableau and how to publish it and share it with their peers.
In total I would suggest approximately 20 hours of time is required to be invested, which may seem a lot, but remember you are trying to implement change here and for any change process to be successful you must foster confidence in your user base and empower them to own the change; you achieve this by not simply rolling out functionality but by investing in their skills and enhancing their knowledge. Give them a sense of achievement.
In terms of the practicalities of completing the e-learning pathway I would recommend publishing Tableau’s Superstore data set to your web-edit Workbench (see site structure for more information). This will ensure your web-authors can easily connect to Tableau’s packaged data set and easily complete the e-learning exercises, saving a personalised Workbook to their individual Workbench and using this as their way of embedding learning, by allowing them to reference the output of their e-learning journey at any point in the future, should they need to.
Finally with e-learning ensure your future web-authors complete the assessments within the learning path so they can not only demonstrate their understanding of the content but also can gain a sense of achievement prior to being given access to the functionality. My personal advice would be to not provide access to your web-authoring curated data sources until an individual has achieved their skills belt through passing their e-learning assessments.
Support Network : A Web-Author 'Buddy'
Whilst e-learning is an important investment in your web-authors it is not the only way you can support their skills development. By providing your web-authors with a ‘buddy’ within your Business Intelligence Team, you are building trust and collaboration between your data professionals and your data enthusiasts.
A buddy can act as the helping hand, to answer the ‘stupid’ question when the individual gets stuck, or simply to be there as a support and to provide re-assurance and a nudge in the right direction when they need it.
Your buddy can also act as your eyes and ears for the deployment and ongoing use of web-authoring, identifying your Data Rockstars who are really taking to web-edit and can help evangelise about their new skills and capabilities to their peers.
Celebrate Success!
Finally, when it comes to skills development, celebrate successes! If fellow web-authors see their peers being commended for completing their e-learning they will be more likely to be spurred on to complete their own training. People want that warn fuzzy feeling of being praised, and if that praise is public praise they will associate your Tableau web-edit deployment with positivity and as such will embrace the change and be more driven to succeed in it.
Step 3 : Site Structure
Ensuring web-authored content is contained and easy to create and maintain
Hang on a minute I hear you say, I thought you said you were not going to touch the technical aspects? Sorry! There are some founding principles to setting up web-authoring that I felt had to be touched, again I will not go into the technical steps in a massive amount of detail, rather I will share why each aspect is important and how to consider your solution to set your web-authors up for success.
First up; how to structure your Tableau Site.
An important consideration when planning your web-edit implementation is how you want any web-edit content to be structured and managed. Remember a web-edit workbook can only be saved to Tableau Server and as such ask yourself do you want web-edit content in the same projects as your curated production dashboards?
I would suggest not!
By creating “Workbench” areas in Tableau you can give your web-editors a protected space where whilst also giving your site administrators the confidence that web-edit content is all contained in a governed space.
Just as every home workshop needs a quality workbench, so does every web-author to help them store and manage content efficiently.
You may notice I stated Workbench areas, with the emphasis on the plural. The reason for this is you may have multiple service lines using web-edit, for example users from Finance and from HR. To support you to maintain appropriate permissions I would encourage you to create individual Workbench projects for each service line. Furthermore, within each Service Line Workbench place the following sub-projects:
Workbench: Service Line
No content is stored in the main workbench project, this is your parent project where you place each sub-project, all web-edit content is contained within the sub-projects.
Workbench: Service Line – Data Sources
In the next section I describe how to approach creating curated web-edit data sources. Placing all web-edit data sources for a service line in a dedicated sub projects means you can ensure web-authors only see the data sources relevant to their service line; and enable permissions to be managed at a sub-project level as opposed to individual data source level.
In addition by placing curated web-edit data sources in a project you can also set permissions for web-authors to connect to these data sources once they have completed and passed their e-learning web-authoring assessments. This demonstrating their competency to use web-edit.
This is also where you can put a copy of the Superstores data source to support web-authors completing their e-learning exercises.
Workbench: Service Line – Web-author name 1
Each web-author gets their own dedicated sub-project to save their workbooks, this can include workbooks relating to their completion of e-learning exercises and newly created ad-hoc web-edit business content.
Workbench: Service Line – Web-author name 2
And so on for each of our web-authors
Step 4 : Data Sources
Ensuring a golden source of the truth and keeping it simple for your web-authors
In order to use web-edit you need to have published data sources available to your web-authors.
Web-authorsjjcannot connect to workbook extracts. As such you will need to build curated data sources that are available for web-authors to connect to.
Sounds simple enough, however I would challenge you as to whether web-authors should use the same published data sources as production dashboards and analysts use.
Due to the overhead of running web-edit and the live nature of building content within web-edit I would encourage you to scope the requirements of each web-edit initiative and build curated data sources that:
Only have the minimum number of fields required. If a field is not needed for ad-hoc analysis remove it! The more fields available in a web-edit data source the more risk there is of web-authors misunderstanding the structure of your data.
Have comments added to, ideally all, but if not then, key fields so your web-authors can understand what a field is showing and any logic to be aware of. This is a massively underutilised element of Tableau Data Sources!
Include the correct field formatting; have you set your default date formats correctly? Are percentages formatted as such, with the correct decimal placing or are they still showing as 0.95 instead of 95%?
Have hierarchies pre-defined. Imagine you have a set of geographical filters; Region, Country, City, Property. In reality Property, belongs to City, which belongs to Country, which belongs to Region. Set your hierarchies in your curated data source so that it is easy for web-authors to 'drill' through their data.
Define commonly used calculations. This is crucial! If you know a web-author will regular need to calculate a given percentage, sum or average, build these calculations in prior to publishing your curated data sources.
All of the above standards are set with the aim of ensuring a golden source of data for your web-authors. One of the biggest risks of web-authoring is someone building content that is incorrect or misleading in it's application or interpretation of the data. You will never been able to mitigate this risk completely, however you certainly can take steps to minimise the potential of it occurring.
Step 5 : Permissions
Trusting your web-authors whilst also safeguarding your production content
Setting permissions for your web-edit users is a critical step in ensuring governed use of web-edit. If you do not set permissions correctly you could have Tableau web-authors editing production dashboards, connecting to complex, production data sources and saving content in productions projects that may confuse or mislead your end users.
To mitigate these risks, think carefully about your approach to setting permissions at a project and data source level; and here is a wake up call for you all, you will not only need to consider permissions for your web-edit projects, but also for all other content on your Tableau Server.
Why?
Setting permissions on your web-edit workbenches will ensure these projects and associated data sources are used appropriately, however if you ignore the rest of your production content there is a risk web-editors will inappropriately use production content and impact your stakeholder facing content. For example if permissions for a production project are set in a “lazy” way and give “All users” full control of content, i.e. the ability to edit and modify, the moment you activate web-edit for a user, by changing their role on Tableau Server, they will technically be able to edit that content.
Step 6 : Community
Nurturing talent through collaboration and engagement
Ask 100 people what is the best part of Tableau and I would bet a sizeable chunk of money that the majority of people would say the Tableau Community.
Why?
For me it is the single greatest source of inspiration, learning and support you could possibly wish to leverage when learning a product or challenging yourself to continuous grow your knowledge and understanding of it.
Whether it be the Tableau Community or the most successful analytical teams, they share common principles or values such as;
Curiosity
Collaboration
Honesty
Integrity
A commitment to ongoing learning
Why shouldn’t your web-authors benefit from the same principles and the same commitment to invest in their ongoing growth and development?
You can support your web-authors through the following approaches, although I should note that every organisation is different so you should very much consider what will work for your teams and your organisation and flex accordingly:
Web-edit business intelligence buddy
Teams or collaboration site for web-authors
Regular data visualisation challenges
Regular user-group / meet-up for web-authors
Even with the above structures / approaches in place, don’t forget the value of the little things, the thank-you when a web-author does a great job, the ongoing raising awareness of their achievements and making them feel a virtual part of the business intelligence team.
Step 7 : Content Governance
Defining the ad-hoc adventure to production content
Remember web-edit content should not be considered in the same way as your governed production content.
Where as your production dashboards may go through quality checks and have standards applied to them, I would encourage you to consider web-edit content as being more ad-hoc; you are not looking for perfection you are empowering your web-authors to achieve fast, agile, insights and exploration of their data. As such allow your web-authors to publish content without any checks.
When you can apply checks and quality assurance is when a web-author requires their content to be moved to production. Red pen at the ready! No, only kidding, but in reality, there will be times when a web-author has created content that is incredibly beneficial for the business and as such should be moved from web-edit content to production content. If you have not considered this possibility you are massively under-appreciating the benefit web-edit could have to your organisation and the contribution it can make to true agile, collaborative working.
In this instance you can develop a process for a web-author to engage with your Business Intelligence Team and request their work is productionised.
How?
Consider the web-edit workbook as a prototype that you can use to understand business requirements and logic.
Once a web-author has developed a prototype dashboard that they require to transition into production, allow them to submit their dashboard for production development.
Have your business intelligence team review the prototype dashboard, testing the logic and build in terms of:
Filtering
Actions
Calculations
Adherence to any corporate viz standards you may have
This is also the opportunity for your business intelligence team to work in close collaboration with the web-author to make suggestions on design choices, such as chart types and flow of storytelling / insights.
Based on the above steps the road to production should be a lot quicker than one of your Business Intelligence Team starting with a blank dashboard, gathering requirements and building from scratch. Not only that but your stakeholders will feel empowered and as thought they “own” the solution the original product would have been directly developed by someone from within the business.
Step 8 : User evolution
Life beyond web-authoring
You’ve successfully deployed web-edit, you have supported your web-authors to grow their skills and create that curiosity about data which burns inside all of us, but you aren’t quite finished yet. It should be recognised that web-edit does have limitations, it doesn’t deliver the full suite of functionality that Tableau Desktop does. So, what happens when you have an amazing web-author Data Rockstar, someone that is beginning to live and breath data, someone who wants to go further?
My advice would be to consider a development pathway where-by a web-authors can transition to become a full Tableau Desktop user and is supported in their evolution of using Tableau. Obviously this step will not be applicable to all of your web-authors, Tableau Desktop does incur an increased cost (depending on your licensing model) and as such you have to justify a return on investment; consider soft assessments of your web-authors to identify your potential Desktop users. Nurture their talent and explain to them the potential benefits of evolving to Desktop. Repeat the same steps you did when it came to strategising web-edit; engage these users, sell them the vision of Desktop and then support their skills development through training, mentorship and embracing them into your internal Tableau community of Desktop users.
So, there we have it, my approach to taking a massive step into democratising your data. I appreciate it will not be right for everyone, but if you have ever considered deploying web-edit I hope it is either helpful or has sparked some ideas in you that will help you achieve a successful adoption.