Deneb 1.6 Ready for Alpha Testing

Deneb 1.4 and 1.5 were small, incremental builds, to keep things moving along while 2.0 was being planned and developed. Well, here we are with 1.6 instead. It has a lot of things in it, but I’ll explain how you can find about the changes, what to expect for subsequent changes, but also importantly, how you as a community can help get 1.6 over the line and ready for AppSource submission.

Why 1.6 and Not 2.0? Does 1.6 Include Everything you Had for 2.0?

I’d originally planned to finish off the 1.x releases of Deneb and move over to the next major set of updates being done as version 2. I’d put a fair amount of time into this work and concluded that some of what I had done would result in breaking changes to the template functionality, but a lot could be delivered incrementally rather than as a big-bang approach. It was getting challenging to achieve this and as such I de-scoped what could be seen as an initial deliverable. Whilst it would be a significant step up from the current versions in terms of look and feel, it still wouldn’t be everything promised.

As such, I’m taking what I’ve learned and will be phasing in the changes gradually as releases under 1.x. The intention is to use this to prepare the codebase for any potential breaking changes to the dataset and templates so that these can be correctly migrated without friction for the end-user.

Version 2 will take effect when data or property-based changes that will affect template composition can be delivered. It’s also intended that Deneb will take care of migrating v1 templates to v2 format, but we will know more for sure when we get to that part. For now, we’ll try to spend the remainder of 1.x’s lifecycle focused on quality of life and productivity improvements that can be delivered independently of these restrictions.

The next few releases have the following high-level deliverables (amongst other things):

• 1.6: First set of major UI changes, performance enhancements and quality of life features originally intended for version 2.
• 1.7: Conversion of specification format from JSON to JSONC in readiness for 1.8, and improvements to field usage tracking.
• 1.8: New JSON editor component with comments support, auto-completion from Vega schemas, and documentation on hover (if a property has documentation info present in Vega schemas). Also: dark mode.
• 1.9: (Ideally) final quality of life changes and performance enhancements prior to 2.0.

It’s possible we’ll go beyond 1.9 if the roadmap calls for it, but at this stage it is anticipated that 2.0 will follow 1.9.

1.6 Overview

As noted above, 1.6 has some major UI changes and performance enhancements, but it’s fundamentally the same experience. As such, the documentation site will need a lot of updates, but I have already provided a reasonable amount of detail in the Change Log for anyone who is looking to assist with alpha and/or beta testing (more on that in a sec). A quick summary of the changes to expect is as follows:

• Vega and Vega-Lite updated to latest versions.
• Spec parsing is more performant.
• UI is more responsive.
• UI framework has been upgraded, with changes to make it more maintainable going forward. Some of these are cosmetic.
• Better onboarding guide on the landing page.
• Valid templates can be imported via drag & drop or pasting from the clipboard.
• Templates can be downloaded directly rather than copying to the clipboard (dependent on your tenant admin settings; copy still available for those who can’t download).
• Debug pane UI and components replaced (including asynchronous processing of the Data tab).
• Additional predefined preview zoom levels.
• Dynamic format string support fields in the dataset (for measures and calculation groups).
• Scrollbar appearance configuration.
• Bug fixes and other performance enhancements.

Call for Alpha Testers

Normally we’d have a pretty short window for alpha and beta testing before we submit to AppSource. However, the performance changes affect a lot of the underlying code and workflow. Really. A lot of it has been reviewed and re-written.

The resulting Deneb you see before you should work very much the same, or better. And it has done for me. But, we all think differently and have our own ways of approaching our solutions, so it’s hard for me to anticcipate every possible combination out there. If we submit to AppSource, it’s a very lengthy process to go through certification and deployment, and it’s very hard to wind things back if someone finds a breaking change after this point. We’d ideally like to try and find anything before it gets to that point and fix it prior to submission, so that the quality is as good as it can be when it goes live for everyone else. Therefore…

Here’s How You Can Help

Firstly, if you can help with this, thank-you! In addition to getting to play with the latest changes, you will be helping us to confirm that Deneb is going to be better for everyone else who uses it :)

1. Get Familiar with the Changes

Just in case you’ve skipped the details above ;)

2. Download the Latest Alpha Build

If you need more context or information about early builds and how to work with them (and help me to fix stuff), it can be worth reading the page about Early Access Builds on Deneb’s website (or this blog post).

Alpha (and beta builds) are like the Standalone version in that they are disconnected from AppSource and are a different visual to the AppSource version, according to Power BI.

If you are testing a production report, it is strongly suggested that you save a copy of your workbook and work with that for testing purposes before converting a visual over to an alpha build instance. This means that you don’t have to worry about reverting your existing production visual back to 1.5 and losing any functionality that may be present in 1.6.

The latest Alpha build is always available from the Alpha release in the GitHub repository. A direct link is here:

https://deneb.link/alpha-build

The visual is a downloadable asset at the bottom, e.g.:

Alpha builds can be loaded by importing the .pbiviz file manually into your report.

Working with an Alpha Build Already?

• It’s always good to check and see if a newer build is available than your current one.
• The release page will tell you when the latest alpha build was made (underneath the heading).
• The file name also has the (UTC) date of the latest build, after the version number, so for example, if the file name is ALPHAdeneb7E15AEF80B9E4D4F8E12924291ECE89A.1.6.0.20230828.5beaa6a2.pbiviz, the build date is 2023-08-28 (or 28th August, 2023).
• If you’re using an alpha build currently and importing a newer version, any visuals on the page won’t automatically update. You can force this by navigating away from the current page and back again to make Power BI reload them.

3. Confirm All your Stuff Works

With your alpha build of the visual in your report, you can swap out your existing visual by clicking on it and then changing it over to the alpha version.

It is anticipated that your visual should continue to work as designed, and that you can continue to edit it as normal. Be sure to check any interactivity features, such as tooltips, cross-filtering and/or cross-highlighting. Be sure to check other things that you might normally do as part of your workflow, such as if you made a template from your visual previously, does this still work as expected?

If things aren’t as you expect, then refer below on how you can help let me know about this.

4. Confirm All the New Stuff Works

While point #3 is important, it’s also very important that all the new features work as you expect based on what you see in the Change Log.

Please test these features and enhancements, and be sure to look out for any behaviour that takes you off the happy path.

5. Report Issues (but Check First)

If you find something wrong, please don’t assume that someone else will report it. We are incredibly reliant on anyone who can help find potential issues to let us know about them so that we can find them and (hopefully) fix them. And even if someone has raised an issue, you are welcome to add your voice to it so we can get a better idea as to how important something might be to folks using Deneb.

Master Known Issues List

I’m consolidating a master list of known issues with the builds here on GitHub (issue #322).

All being well, I will add new issues as soon as I can to here and keep this list organised, but you can check this list for whether what you’ve found is known about and if not, you can raise a new issue. Once I’ve had a look, I’ll link it to this main one. Each issue then becomes its own thread so that we can have a more targed discussion around what you’re seeing and how (or when) we can resolve. Other folks are welcome to add their voice, too.

I understand that duplicate issues can and do get raised. If multiple issues are raised for a feature but are sufficiently different, I’ll likely keep them separate but if there is significant overlap, I will likely close the latest one and direct any further discussion to the original one, just to keep things focused.

Accurately Describing Issues

If you have something to report, it’s going to be a fantastic help if you’re able to articulate the problem as much as you can, so that I can spend as little time as possible trying to contextualise it and as much time as possible working on it.

For bugs, this should include sufficient detail to help me reproduce from my end, and confirm that it’s no longer reproducible once I’ve worked on it. The following things help a lot:

• Prescribed steps to reproduce the issue.
• Expected outcome.
• Actual outcome.
• Supporting screenshots or short video.
• Specification and/or sample workbook that can reproduce exactly. If you want to attach a workbook to your GitHub issue, unfortunately .pbix files aren’t a valid type, but you can change the extension (e.g. to .zip) and this will work. I can also take workbooks in confidence if needs be, but publicly available data that can reproduce your issue is the ideal outcome for all.

For improvements, again it’s great if you can be as descriptive as possible as to how you think this should work. Again, the following should help provide you with some ideas for helping me get on your wavelength:

• User stories or short narratives.
• Mockups (taking existing screenshots and annotating them is totally fine).

I know this is asking a lot of you, but I’m honestly not sure what kind of volume to expect from users when it comes to feedback, so I may have a lot to organise and work through (and do the development on), so this detail will really help to keep things moving along.

Updates to Issues

If any issues get resolved in subsequent builds, I will provide this detail, and the associated build that will have the new changes. You can then use this as a means to compare your version and download/test an updated one.

When is Testing Done?

It’s going to depend on what we find, but hopefully we can move to beta testing and then submission as soon as possible after that. Ideally, I’d like to get alpha testing confirmed by 20th September, beta testing done by 27th September and submission ASAP after that.

As always, thanks very much for reading and especially to those of you who are willing and able to provide your time and expertise to make Deneb better for everyone. I really appreciate it :)

All the best,

DM-P