Press Ctrl / CMD + C to copy this to your clipboard.
This post will be reported to the moderators as potential spam to be looked at
I've played around with the current alpha of Umbraco V8 and I must say that it looks really good, love the progress!
One thing that me an my co-workers have been trying to "settle" with is the new way of presenting "Tabs" in the Content-section. Here's a node with two tabs "Grid Content" and "Content":
The "Tabs" are now stacked in one long page, I've heard that one of the reasons for this is an upcoming "side by side"-editing feature to be able to edit two variants side by side. That makes sense.
But I'm still not 100% sold on this UI design so I would just like to open a discussion around this. Would someone argue that a doc type has to many properties if it has 4-5 tabs? How do you guys work with tabs? Are we the only ones that would miss the them?
I'm also thinking that the layout could be configurable? Maybe with some switch on the document type? (Render with Tabs: True/False)?
thanks for raising this point and I also have some serious doubts how this will work on our websites. We sometimes just have some doc-types with a lot of tabs and properties, and I think it can become a mess/unclear quite fast.
But I didn't attempt to spin up v8 really serious and I don't know in which phase the design implementation is currently... So I don't want to bring in my thoughts too early on things that haven't been published yet.
I am also not completely sold on the accordion idea over tabs. My issue is that if on first load of a content node you only see the first open accordion you dont get a quick over view of all the tabs you are going to be working with, i.e SEO, Settings, Content etc.
With the accordion layout you wont see all of the sections you will be working with so dont get a quick overview or insight into everything that is involved in setting the content node up.
Good topic for discussing! I've not used v8 enough in anger or with clients to get a feel for what is going to work best, but I can see a few pros and cons already:
Couple of thoughts:
Maybe if all the Accordion panels where collapsed by default this would solve the "overview" problem (but at the expense of more clicks required to start editing).
Maybe we could have links that mimicked the tabs at the top, but anchors down to the Accordion item (which would open it)?
I know people hate change and then once they get used to the change its all good again. I just feel that tabs work, why change to accordions...
The interesting thing to consider here is the role of Content Apps...
And the different journeys that editors take when they interact with content
eg Creating Content vs Editing Content vs Comparing Content etc etc
If a standard content page might have on average 5 tabs? (yeah I've seen more...)
Then think how many of those properties on those tabs, are regularly updated for the content item, and how many of them are there for 'niche' functionalities...
So I pretty much always have a 'Page Settings' tab. that contains all the usual umbracoUrlName, umbracoInternalRedirect etc properties, at least 95% of the time these are ignored for a content item, but they are there, because every now and then its really useful on a node to be able to redirect or rename the slug, I provide them to the editor without really thinking... but come V8 I'm thinking these kind of properties are more suitable to a content app... or at least that is my understanding of what content apps might provide...
The SEO tab.... again all those SEO settings are they part of the content?
When I think about the regularly updates properties, for me they are usually spread across two tabs 'Main Content' and 'Related Content' usually picked - and the order of the properties reflecting how they fit into the editors mental model of the page, is the key.
Recently I've taken a more atomic approach, to organise smaller clumps of properties, across doc types, with compositions, eg no property is ever set on a document type directly, only on a composition, it's made me think alot more about when and where properties are combined... I think it's meant a less cluttered editing experience, although I'm not sure exactly why.
so I'm interested to see if V8 and content apps, will enable us to move of the 'meta' properties into more obvious content app sections, leaving the content properties with a better flow for creation, and comparison...
... however for 'editing' existing content 'journeys', the tabs probably get you to your place of update more quickly, I don't like trying to find things on accordions (remembering the old document type editor) ... but interesting to see how they are presented on first load, (eg all closed up) or whether there would be 'jump links'
I suspect in some journeys, for some content, the accordion single page of properties will win over the tabs, and for other types of content and updates, the tabs will feel better...
I would also argue that the new menu based solution for sections demands expensive real estate. About 90% of our clients use laptops in their daily work. About none of them has their Taskbar on the left, as Shannon had on his CG18 presentation ;). That said, their 16:9 or 19:10 resolutions are wider, and freeing up height over width is crucial!
Personally I don't care if it are tabs or accordions. It's just a way of grouping properties in the UI.
And I don't think editors will care as well. They just want to their job... edit content
What is more important is that you as a developer group this properties logically.
What we tend to do is group properties in a tab according to their functionality (eg. Content, SEO settings, Navigation Settings)
And then order the tabs on the editing frequency...So navigation settings and seo settings often are the last tabs.)
The first tab contains only the properties that are changed frequently eg. page title, content (grid or rte), ...
So in that way an editor can start editing immediatly when they open a item without changing tabs.
It would be nice in V8 to mark a tab as "Content App" for the properties that are not edited frequently. Like Marc already suggested as well.
But if I understand correctly the purpose of content apps is to have easy integration of third party data.
My knee jerk reaction would be to agree that accordions doesn't feel as user friendly as the tabs. That said, it would be good to get some HQ input if possible to know / understand the challenges that led to this decision.
Without knowing that, I don't think we can suggest viable alternatives as we just don't have all the information.
Perhaps some kind of accordion navigation could be added to let editors jump directly to the desired section for editing? I dunno, just thinking out loud here. My main concern would definitively be editors getting lost on a mile long page of properties.
Sitecore had accordion style editing last time I checked (maybe still has, it's been a while) and that quickly became a bit of a nightmare to navigate. And yes, I know it's not fair to compare the two. Just saying :)
I've got to admit, when I first saw that tabs had gone in v8, my gut reaction was people ain't gonna be happy about this! Like others are saying on here, let's wait & see what HQ say, to justify the rational.
After reading the first few replies on this thread, I took a look at some of our own recent Umbraco implementations, to see how we are currently using tabs ... and it turns out to be pretty much as Marc outlines above.
Of course, there are variations for specific page types, but overall, we've got a definite divide between "content" that is specific to a page/doctype ... and configuration/settings of that page/URL.
e.g. the actual thing and then things about the actual thing.
... and this is where I see Content Apps fitting in. Of course, we know very little about them at the moment... and can't wait to hear more!
I guess that some of our solutions might "over use" the tabs but we try to put all the content and settings that's related to a page on that content node. Ie generic "push/list"-texts, CRM-settings for leadforms, SEO-information, menu-overrides etc.
This is how one of our sites look, each tab have everything from 3 to 10 different properties.
A possible solution would be to combine the tab navigation from V7 with the accordion from v8, as Kenn Jacobsen proposed.
The accordion would still exist, but we would get an overview of the contents with the tabs on top and could scroll to each section easily by clicking a tab item.
The problem here is that it wouldn't play too nice with the Content/Info tabs...
Great points - high five for all the input. There's reasoning behind the madness - whether it's great and whether we hit a home run is too early to say.
First, a bit of background. Over the last couple of years we've seen two trends:
Managing websites is beyond just editing content. We've seen various hacks to accommodate this via either adding menu items to the Actions menu, creating property editors that don't edit content at all but acts as placeholders for other functionality, dashboards and custom sections. We wanted a solution that made managing beyond editing as friendly as editing content. That's why we're introducing "Content Apps" with v8.
Pages become more complex. Combined with how v7 allowed more flexible property editors, this has opened up a lot of new editing experiences that required fewer properties but more space and clearer navigation of what you're editing. That's why we've been working on "Infinite Editing" for v8 (which requires more horizontal screen real estate - we need further testing, but could potentially compensate for this by minimizing/collapsing the top navigation).
Both of these concepts means that we needed to completely re-think the overall grid system of the Umbraco back office (as in navigation, panels, headers, etc).
We've tried what Tobias Klika did in the screenshot above (high five for the great example, btw), but it steals too much screen real estate and it also becomes unclear what the priorities in the UX (tabs and "content apps" compete for focus).
In the end, we've concluded that tabs in the back office are slightly overrated. When implemented well, they definitely help giving an overview but they can also give a false promise when done less well (especially in larger projects and when compositions are overused).
When you've used v8 for a while, it's also surprisingly nice that you just scroll down the content tab and in the end, save or publish - no jumping back and forward between tabs that scream with validation errors.
The biggest UX issue right now with the tabs being removed is to ensure fast navigation between the field groups and an overview of the groups. We'll have a couple of ideas to test including local navigation when clicking a group header as well as navigation to the different groups when you click "Content" at the top.
Hope this brings more insight. Tabs definitely has its place and was a great navigation pattern when sites were more simple and it was all about editing content. And no doubt that for some cases this will be a step back. However, I'm strongly convinced that for the majority of sites now and even more going forward, this is a small tax for an otherwise huge step forward.
Thanks for the insights...one question remains unanswered for me.
Can we have properties of a doctype in a content app ? eg..all SEO related stuff, navigation settings etc...
Than the content editing area is really focused on managing content instead of settings.
And I also think it's important for UX consistency that it's clear where you edit content and where you manage content.
In 2018 what is "SEO" anyway?
I could see parts of navigation go into a more dedicated area, though (and also be less of magic strings and a more consistent way to handle urls, navigation, etc). But too early to change too many things and we need to learn more about how what we've done so far works in the wild.
Sorry if this is a stupid question but are content apps designed purely for displaying information or can they be used as an area to manage specific types of content.
With SEO the example would be meta titles and descriptions. Could this live in a content app or is this regarded as content as well?
Content Apps are not for editing content and is not a placeholder for content properties.
Okay cool, I really like the idea of Content Apps, maybe the name needs a rethink though as I think the name is causing confusion.
Thanks for sharing the progress around this Niels! It's always interesting to get insight in to why stuff are built in a certain way.
As far as I understand "Content Apps" might be used for something like an integrated Google Analytics-view for showing stats for just this page, a view that render some external SEO-audit or what ever. But it will not be a place to edit content right? The aim here being to not to be forced to implement a "Property Editors" just to render a "content aware" angular-view.
While I do agree with your points about error messages on multiple tabs and love the idea of "Infinite Editing" I still think that it's really important to find a way to navigate fast to a "Tab"/"Field Group". Ie if you have a Grid in the first Field Group and then some page-specific settings further down, you don't want the editor to scroll forever to come down to these settings.
If the solution is good old tabs or something else is really secondary. I also raised the idea of Tabs being a configuration-option on the Content Type - that would give us as implementors of the website the option to choose what fits best in different scenarios.
I guess I'm just scared =D I've seen some Wordpress implementations with lots of different controls and inputs in a long accordion and for me the Tabs in Umbraco is a lot better, more structured approach and provide a way to focus on "parts" of the content that I'm editing.
Correct, that "Content Apps" (name still working title) is not for editing content.
The most important thing in UX is consistency, thus a toggle for whether to show tabs or not something to strive for - it would be a symptom that what we have doesn't work.
I have started to look at V8 this evening and this is also the one area that has surprised me the most about the chance of UI.
The built in support for multi-lingual sites in v8 looks great, definitely #hi5yr for building this into the core.
Over the last 20 years I have built a LOT of website, however the number of multi-lingual sites is probably around 10, as it happens, I am currently building a bilingual site for a client.
The site I am currently building has a complex design for its homepage, it can logically be broken down into 8 sections ( this excludes the navigation & footer that are defined elsewhere )
The page also has 3 additional tabs for:
So in this current scenario, with logical groupings as far as the editor is concerned, we will end up with 11 tabs. It might seem a lot, however the page is reasonably complex and requires a lot of editable settings.
Before anyone suggests it, the site design is as far from a "grid" as you could get so using the Grid editor would not work for us.
My gut feeling is if the Accordion is now the way forward for Umbraco, there will need to be some way to allow editors to quickly see and navigate between the sections.
On pages like the one I just described, I think it's not going to be a great UX with a lot of vertical scrolling to find the content you need to edit, but for smaller pages I can see it could work well.
Like a couple of others have mentioned, it would be good to somehow separate the "page content" from the "page configuration", even if that was just some kind of visual difference in the accordion.
On the majority of sites, I would guess most pages will have properties that once set are never changed, so maybe being able to set the accordion default for each section ( i.e. open or close ) could work quite nicely?
Definitely something to discuss more and to test with some real world complex configurations.
Just some thoughts, I look forward to seeing how this pans out.
Great feedback, Chris. This is exactly the type of information we need.
Any chance you could e-mail me more information about how the homepage is setup so we can use this in our work (and get a better understanding of more "real world" projects)?
I would second that.
We need to figure out a way of hiding editable settings from editable content. On our sites we usually build recursive properties, a page gets its property values from the closest set value in the structure. Especially awesome when working with huge themed structural sites - I would say that's Umbracos big USP compared to other CMS'es. That said, we do need to put page specific settings somewhere. Not necessarily in tabs, but i would say not in an accordion.
This is really interesting and much more interesting than a focus on tabs vs accordions (which quickly ends up in a cheese is being moved / bikeshed discussion).
Ie. why (thus leading to what) is there a need to categorize and could Umbraco help with that, thus also adding more guidance and consistency ootb.
I know content apps are for 3rd party integration. But for me personally it would be a perfect fit to have content properties that control page settings in there. You could have for example a "Theming" content app that let's you manage all related properties to theming. I see info "tab" is also moved there.
Hmmm...seems the Last reply from me and Niels are gone...so posting again.
I know Content Apps are for 3rd party data integration. But for me it would be the best place to manage doctype properties for page specific settings. Eg...you could have "Theming" content app that let's you control all doctype properties related to that...I can thinkg of many scenario's that would fit in there.
I might be misunderstanding you, but to me, it sounds like they would just be tabs with an icon.
This is exactly the information/feedback we need, ie. a conversation about what people are using tabs for and why there could be a stronger need to group information (instead of tabs vs accordion which ends up in a moving cheese/bikeshed discussion).
Right now we have Content and Info. It could make sense to look into if other default categories could be needed. This would also help with guidance and consistency.
Yep...but in the same place where content apps will be placed..I see the Info "Tab" has been moved there as well.
Like others have mentioned most of the time you group your properties logically by functionality on a tab. Especially when you are using compositions.
We usually end up with 7 to 8 tabs (excluding the info one). But some times more, some times less. All depends on the requirements.
This would mean a lot of scrolling for editors to find the content..or collapsing accordeon and opening another one.
Hmm...something strange is going on....2nd time I posted a reply and that it's gone after refreshing
Yep you are correct that it will be a "Tab" with a icon, placed where the content apps go.
So you can free up the accordeon for properties that change regularly.
We often end up with at least 7 or 8 tabs because we group properties by functionality. Like the screen shot below
But SEO and opengraph are almost never changed by editors. It would be nice not having them in the accordeon, so that area is only focussed on changing page content.
I do understand the importance of, and appreciate, consistency in the product. And I would argue that the removal of noise for the editor should be of primary concern.
What about the possibility to label a property as an editable content or a page specific setting? Each of em having their static position in the UI? The content properties would be of primary importance, but the page specific settings would still be in reach for the user?
Yes, there seems to be a bug (caching) when you post to a signalr loaded comment (I'll create an issue and we'll look into it next week).
Maybe I should have posted a different screenshot because this an overview with a customized list view.
But on "detail" pages the first tab would be the "Page Blocks" tab where they manage the grid content for this website. All others tabs are sorted by editing frequency.
So with this kind of separation in properties this would mean a lot of scrolling using the accordeon.
Maybe a toggable quick navigation for the accordeon would be nice as well. So you would only enable it on doctypes with a lot of "tabs".
Like I mentioned before I don't care if are tabs or accordeons..it's just moving the cheese. But what I do want is a good editor experience.
I will check will my client and get back to you, I am sure it will be fine. Ideally I will be able to just share access to the Umbraco Cloud dev site :)
I'll get back to you ( probably on Monday )
I would echo some of the points made here:
In real life sites it is often necessary to have many tabs to logically divide content up. I get the impression the Core team think we should have less tabs, but this just results in a single tab containing unrelated content all thrown together. I think it's much better to have a single tab contain logically related content than have fewer tabs containing more content. This applies equally for accordions, if not more so.
The use of compositions actually makes it more likely you will have more tabs. In most cases it makes most sense to have a composition have it's own tab - this is partly because trying to merge tab content together (when two compositions have the same tab name and order) can result in random results. Plus it just seems neater to have one tab apply to one set of related content and not mix this up.
Also, sites evolve over time - you might initially start with a few tabs but then the client requests something new and it grows.
Also, as mentioned, a lot of sites will contain various "settings" that are required but less frequently accessed. This can be stuff like SEO settings, navigation settings (hide page, prevent deletion checkbox) and also, on the home page, site level settings. We tend to use the home page for any site level settings because this allows easy recursive access to them and also it works better when you have a multi-site set-up (ie. a multilingual site with four home pages).
I do fear that simple swapping tabs for an accordion is going to create a real usability problem for editors. Currently tabs are "sticky" so you always can quickly swap between them. This isn't the case in an accordion, where if you want to access the last tab you have to scroll down.
Late back to the game on this one, but just catching up on things.
I can't tell if we are saying tabs are inherently bad from a usability perspective? or, if we are simply loosing them to a) gain vertical real estate (seemingly because the sections nav has moved to the top to enable more horizontal space for infinite editing?) and b) because content apps now compete for focus?
It feels like it's mostly the later, which if that's the case, I do think the example from Tobias could be made to work better. How about we knock the tabs back so that they are clearly less significant than the content app?
From a vertical real estate perspective, the reality is we are talking 55 pixels difference from v7 so is this really a huge deal? I mean, it's not wasted space.
Also, when you consider the number of interactions accordions will create vs tabs ie, say you want to get to the meta data section, with accordions, this is either collapsing all accordions before this section, each being a click + mouse movement to the next collapse button in-between, or scrollwheeling multiple times to get there combined with the fatigue of attempting to identify the correct accordion as it scrolls past vs a positive single click action to get to a specific meta data tab.
Is this worth the compromise of 55 pixels? I think so. Especially when we are suggesting a lot of content will end up being edited in infinite editor windows anyway, in which case the vertical space is irrelevant because the modal opens over the top of all of this.
Just a few thoughts.
Ps, just to add to this, you already have the concept of knocked back (pseudo) "tabs" within the main editing area present in the doc type editor. Maybe this could be standardized as a pattern?
I think there needs to be some kind of quick way to get to the bottom accordions.
The grid is a perfect example of why accordions can be bad. I have a lot of pages, where the height of the grid editor (including content of course) is more than 5000 pixels.
Also the navigation between accordions is going to be a painful experience of random scrolling up and down.
The knocked back pseudo tabs showed by Matt could be one way of solving it, but also a dropdown nav from the Content tab (I'll see if I can make some mockups), or a floating flyout nav, or a minimap in the right side could work.
I think what will be essential is that this feature needs full end user testing with content editors. This would need to be with some real content that is representative of what a modern Umbraco site might contain.
A good way of doing this might be to convert an existing U7 site to U8 and then give a cross-section of editors time to use both and report back which they find easiest to use (alongside any other feedback).
We also need to consider that, initially at least, a lot of U8 editors will be people with U7 experience and the transition to U8 has to be as smooth as possible for them.
The primary goal of a user interface is simplicity. Always has been because it has to be for safety, in engineering terms. You should be able to sit an editor down in front of this thing and be able to follow their nose. The maxim "Don't make me think" still stands. So it's really important that the editor gets an easily accessible overview of the page estate and they can get to each bit with as little effort as possible. Try this thing out with a huge site, say editing 50 news items and see how your wrist is.
Just my 2 pen'th ;) (I haven't even opened V8 yet but common principles apply. KISS ;) ).
is working on a reply...
Write your reply to:
Image will be uploaded when post is submitted