![]() Originally a content app with the sole purpose of manipulating the HTML in the backoffice to get our beloved tabs back. ![]() Sebastiaan Janssen came to the rescue with his Cultiv.Tabify package. That way the user had a quick way of navigating to specific parts of the document. Right before the 8.0 release, HQ was kind to put a band-aid on the problem, by adding a dropdown navigation to the Content app. And since Content Apps can't edit the content (parts of the community call them Context App for the very same reason), they are really not a good fit for that use case. Usually the content inside those properties are needed when rendering eg. ![]() The first two is right - they really should just be content apps. Analytics graphs, static content information, SEO properties and settings were mentioned. Where I previously had a Settings tab for things like URL naming, visibility and other stuff, I could now have a group for each thing.Īnother argument for the groups, was that a lot of the properties we were used to create in earlier versions, didn't belong in the document type anyway, but in a Content App. The thing I liked the most about the groups, is that you could create more focused groups of properties, without sacrificing horizontal real estate on the screen. In addition to that, you were almost certain to get arm injuries resulting from extra vertical scrolling through the properties you need to edit. The groups were especially supposed to aid the new split view feature, for editing multiple languages at once, and while it probably does that, you still end up with two editor panes out of sync, as the scrolling isn't synchronized, and the onscreen height of the different properties could still differ between languages. And of course, the argument to rule them all, tabs was what "we" were used to. But the were equally good when it came to the overview of the structure the document, and easier navigation to the different parts. Tabs might have been flawed in the potential tab overflow, where you have more tabs than your viewport width can contain, or when you have validation errors buried inside of "unused" tabs. After all most document types I build are simple in terms of the amount of properties, and I didn't want to let edge cases decide the design. A huge thread on Our was started, in which community members giving their input on pros and cons about the new and the previous document type navigation.įor my own sake, I was unsure about the change, but willing to give it a chance. Long before the official release, discussions on this change started. A decision probably made with all the best intentions. Instead Umbraco opted for a single view of properties separated into distinct groups. ![]() With Umbraco 8, the notion of separating document properties into tabs were no longer. But another big change has since kept the community discussing. Language variants, infinite editing and content apps. With that release, 3 new features were key the selling points. It has been almost a year since Umbraco 8 got released. ![]()
0 Comments
Leave a Reply. |