v14 RC4 - Backoffice nitpicks / potential bugs

[OwainJ]

Thought I'd write down some of my nitpicks with the new backoffice:
Posting this now so I don't lose what I've written, but will look to update more when I test again tomorrow.

1. Create DocType Menu spacing

The spacing around the icons and the text sizing, on the Create DocType (and other types) blade menus, looks off to me:

The spacing looks much better on v13 imo:

2. Add tab bar spacing

The spacing on the Add tab bar, of the DocType creation dashboard, lacks spacing and looks very squished; especially around the Compositions and Reorder buttons:

Whereas on v13, the spacing looks much better:

3. Inherited properties seem to be missing styling

Properties that are inherited from a composition, seem to be missing styling when editing a DocType:

vs how inherited properties look in v13:

4. Backoffice Node URLs now use the node's key instead of it's numerical ID

This is more of a personal annoyance, I quite often need to quickly find a node in the backoffice by it's numerical ID, and it's really nice being able to simply edit the ID in the URL to quickly go to the node.

5. Numerical IDs are no longer shown on the node's info tab

I get it, we're moving to using the GUID Keys instead if the numerical IDs; but since the numerical IDs are still present and used all over the place, then we should still be able to find them easily in the backoffice. (I don't want to have to query the database to find the ID)

[leekelleher]

Thanks @OwainJ, we very much appreciate the feedback! 🙏

A few quick thoughts of my own...

1. Create DocType Menu spacing

I agree, it niggles me too, (and I built that part!) The difficulty I had at the time was wanting to reuse UUI components for UI/UX consistency... and the uui-ref component was the closest fit.

I'm totally open for alternative UI suggestions, (that are consistent with the backoffice, of course) 😃

2 and 3. Document Type UI

You're right, those need some styling TLC. 💯

4 and 5. Numerical IDs

Interesting to hear this, as the shift from int IDs to Guid keys has been progressing over several years. To the stage where Bellissima has zero concept of the numeric IDs, the Management API doesn't return them (or shouldn't, if there's a rogue one still around). 🤔

I'm curious what you use them for @OwainJ? (I mean to the point where you'd query the database for them.)

[skttl]

Re: create doctype

I think this could be improved alot, by some styling TLC eg:

• The alignment of the icon feels off. There is either too much padding on the left, or the right.
• There should be some whitespace between the individual headlines and the descriptions.
• The descriptions could be toned down a bit, and maybe increase their line-heights.
• The separator lines could be removed, IMO they don't add any value, and they are not necessary to tell the different options apart.
• The surrounding box is unnecessary, would be nicer if it was just on the white background like before.

[OwainJ]

Re: 4 and 5
These aren't important, it's just me being nitpicky about change lol
But by "still used" I'm mostly referring to the database, e.g. the cmsContentNu, umbracoContent, umbracoContentVersion, umbracoDocument etc... all still mostly use the int IDs instead of the Guid Keys, so it would be really nice to be able to still be able to view a Node's int ID in the backoffice. I know I could just query the umbracoNode table to find out it's int ID, but that's just another layer of effort that wasn't previously there. (and the int id's where easier to type into the backoffice url, if i needed to navigate to a specific node, without crawling through a couple thousand nodes tree lol) 😜

[enkelmedia]

@OwainJ I also missed the numerical ids :) But slowly getting used to the new "Guid only" approach. I think that the background for this is that the numeric ID could be different between environments when using Deploy/uSync to push content between environments - but the Guid is consistent.

The fact that numerical ids are used in the DB is probably about perf? It's (a liiiitle) bit faster to join based on a int vs a guid as far as I understand. You also get the clustered index "for free" with an incrementing numerical id.

But. If the frustration grows too big. Let's make a package! The `Our.Umbraco.Navigate.Numeric.Id" 🤣🎉

[DanDiplo]

I'd agree about numerical IDs. I defy anyone to be able to remember a GUID. Numbers are much more human friendly and much easier to input.

[enkelmedia]

@OwainJ btw. I would encourage you to create issues for 1-3! 😊

[eqtr-ab]

+1 for showing node IDs in the back office. It's nice that there's a goal to replace them with UDIs eventually, but until such a time as they're deprecated wholesale, it makes no sense to arbitrarily restrict what information we can view in the back office.

[enkelmedia]

For the ”numeric id”-discussion. I was in that team but I found that I could just use the backoffice search and search for the numeric id which works great :) Considering the complexity involved in supporting both - I would say that the most pragmatic approach is to change the habit of pasting numeric id in the adress bar with searching for it :)

[eqtr-ab]

That's not my use case - I use the node ID as a parameter in a custom controller method to specify where to retrieve content from, and being unable to find the node ID within the back office interface is a significant obstacle to efficient testing. If the intention is for node IDs to not be used for development purposes with a view to eliminating them entirely, then the field in the API should be marked as such.

[enkelmedia]

I feel you! For you info and from what I've heard: The path forward is to have a little as possible depend on the numeric ids because it will not be consistent between environments (e.g pushing content using Umbraco Deploy, uSync etc.), all references to nodes in the core are not GUIDs and the new Management API (that the backoffice used) does not expose the numeric ids. Afai understand it the only reson they are still there is for database query performance.

But... if you really need to expose the ID in the backoffice a potential workaround would be to build a workspaceInfoApp extension that would be mounted in the same area as the URLs on the info-tab for a document. Query your own a custom controller passing in the GUIDs and then have the controller return the numeric id. Not optimal but would work.

All the best!