In the last few weeks, several minor bugs and enhancements have been made. Here are some notable ones:

Improved help text for tags, including on pressing “Enter” to add tags

Improved empty state messaging for adding contributors to a dataset

Consistent use of timestamps in alerts and notifications

Navigation tabs on various pages are now keyboard-navigable (left and right arrow keys) for ease of browsing and improved accessibility

“Share” button directly opens “Grant access” modal

Consistent use of display name in emails

Text truncation fixed for filter bars and the project workbench

Various layout, text, and navigational misalignments or inconsistencies

Need some quick feedback on your collaborative modeling project? Want to share your graphical view of the world with your customers or your team?

You can now share your Gra.fo model documents without requiring your audience to have a Gra.fo account or an individual invitation. Use the "Get link" option of the share menu to grant read-only access to your document to anyone you've shared the link with. 

🚨 Default behavior change coming next week 🚨

We have recently discovered that when executing queries, there are some cases where our DATETIME columns contain timezone information, and other cases where they do not. This is primarily an issue that arises with columns containing date/time information in uploaded files (we do not see this with live tables). We have decided to address this inconsistency. Starting next week, query result columns of type DATETIME will no longer contain timezone information, while columns of type DATETIMESTAMP will always contain timezone information.

The impact of this change shouldn’t be significant, and most users will see no change. However, if you have queries across ingested data which aggregate on DATETIME columns, or do DATE_ADD() style calculations, you may notice differences in your results depending on your current timezone.

If you are impacted by this change, here are some ways to clarify your intent w.r.t. timezones:

1. CAST the resulting column to a DATETIMESTAMP to force timezones, or DATETIME to strip timezones (documentation)
2. Use AT_TIME_ZONE() to explicitly state your timezone (documentation)
3. Ensure that the table column type is set to be of type DATETIMESTAMP or DATETIME (documentation)

Note: If timezone information is desired, but not defined, UTC is assumed. 

Please contact support@data.world with any questions or concerns. As always, we’re happy to help.

Head over the Gra.fo API Documentation to learn more about how to use the Gra.fo public API to export your model as TTL or OWL. The export API is designed for use with build scripts, version control tools, integrations, or to upload your model into other tools, like data.world.

Fun fact: Ever wonder why our adorable mascot, Sparkle, is an OWL? Now you know!

Looking for the API Documentation? We've added a link to the user menu in Gra.fo:

Gra.fo supports several additional export formats from the document page. These options can be found under the File menu.

Here is a roundup of some of the key features we released last month, February 2021 -- Looker metadata support, custom metadata field default edit behavior improvements, Gra.fo enhancements, and dataset sync webhook notifications.

Check out recent UX improvements to Gra.fo, our visual knowledge graph modeling tool. 

1. To quickly zoom out to see the full graph, use the keyboard shortcut:
   OPTION (ALT) + SHIFT + 0
2. To zoom to a specific concept:
   OPTION (ALT) + SHIFT + click concept
3. You can now deeplink directly to a concept in the graph using the Copy link to concept option in the concept menu. Watch the video to see how we use this feature to move fluidly between a data.world catalog and Gra.fo.

Gra.fo is a companion product to data.world with a 30 day free trial of premium team features. Visit Gra.fo to learn more, or reach out to help@data.world.

An update is coming soon for the following metrics tables.

Events - Pageviews - Last 90 Days: This table now includes all types of pageviews, whereas previously it was filtered to only include dataset and project views. In addition, the window has been extended from 30 to 90 days.

Events - Queries: This new table is a detailed audit of query events. This was previously already available for multi-tenant customers. Going forward, it will also be available for single-tenant or virtual private customers. More details are included in the data dictionary markdown file. 

Resources - Datasets: This table contains a new column called “notificationsEmail” which includes any additional email address associated with the notifications for the dataset, as set in the dataset settings.

Visits - New Users By Month: This table logic has been updated to be consistent with other metrics, namely Visits - Unique Visitors To Date and Visits - Unique Visitors - All Time List.

We're proud to announce a new metadata collector is now available for enterprise customer use in private beta -- Looker (business intelligence). Let us know if you'd like to get your hands on the early version of this collector.

As we get closer to general availability, we'll be releasing more information on these exciting expanded metadata and discovery capabilities!

Keep your eyes open for an exciting new feature in upcoming enterprise releases.
Soon, our standard search behavior will be expanded to include custom metadata associated with your catalog resources. This feature will enable users to execute generic searches such as "Smith" and find resources where "Jane Smith" is listed as "Steward" (a custom metadata property) for a given resource. This feature will be accessible to enterprise customers and will include public API support.

 🚨 Default behavior change coming soon! 🚨

data.world offers the ability to define custom metadata fields on resources like datasets, projects, glossary terms, dashboards, and metadata tables. Custom metadata field types include free text fields, drop-down fields, and multi-select hierarchical fields.

To provide a focused user experience while editing custom metadata, each field had a configuration option to either show the field during the editing process, or else put the field behind a drop-down, requiring a user to find the field in the drop-down before setting its value. The default behavior was to hide the field in the "Add new field" drop-down (pictured below), unless it was flagged as a primary field.

While we typically avoid changing the default behavior of features with widespread adoption, conversations with customers has led us to flipping the default — all fields will show up during the editing experience, unless they are now flagged a secondary field. Only if they are considered a secondary field will they ever be behind the "Add new field" drop down.

The benefit of this change is that users will more easily see all the fields available to edit or provide crowdsourced suggestions for, including fields that are empty and don't have a value set yet.

The edit experience, along with the "Add new field" drop down, in action:

Bottom line - this will result in more fields showing up by default when you click Edit (they won't be hidden under the 'Add new field' drop-down) - unless you mark them as secondary in your metadata configuration (which will hide them under the drop-down).

If you have any concerns or questions on how to implement the secondary setting, including if you'd like to implement it proactively prior to the feature being rolled out, please reach out to your customer success representative or support@data.world and we'd be happy to assist!