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) 😜

[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.